From owner-linux-xfs@oss.sgi.com Sat Jun 1 04:46:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g51Bk7nC020326 for ; Sat, 1 Jun 2002 04:46:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g51Bk7jU020325 for linux-xfs-outgoing; Sat, 1 Jun 2002 04:46:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g51BjxnC020297 for ; Sat, 1 Jun 2002 04:45:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA47716 for ; Sat, 1 Jun 2002 06:47:33 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA42522 for ; Sat, 1 Jun 2002 06:47:33 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g51Bhx215941; Sat, 1 Jun 2002 06:43:59 -0500 Message-Id: <200206011143.g51Bhx215941@jen.americas.sgi.com> Date: Sat, 1 Jun 2002 06:43:59 -0500 Subject: TAKE - build xfs as a module To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk merge in more Make changes from Kai Germaschewski and get xfs to build as a module again. There is now only a top level makefile for XFS. Steve Date: Sat Jun 1 04:45:23 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:120634a linux/arch/mips/boot/Makefile - 1.10 linux/arch/i386/boot/compressed/Makefile - 1.9 linux/arch/i386/boot/Makefile - 1.13 linux/arch/arm/boot/Makefile - 1.14 linux/Rules.make - 1.22 linux/Makefile - 1.199 linux/arch/sh/boot/Makefile - 1.4 linux/arch/mips64/boot/Makefile - 1.7 linux/Documentation/DocBook/Makefile - 1.30 linux/arch/s390/boot/Makefile - 1.7 linux/fs/xfs/Makefile - 1.140 linux/fs/xfs/linux/Makefile - 1.51 linux/fs/xfs/support/Makefile - 1.10 linux/arch/s390x/boot/Makefile - 1.6 linux/fs/xfs/pagebuf/Makefile - 1.10 linux/arch/x86_64/boot/Makefile - 1.3 From owner-linux-xfs@oss.sgi.com Sat Jun 1 05:30:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g51CUGnC020888 for ; Sat, 1 Jun 2002 05:30:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g51CUGVe020887 for linux-xfs-outgoing; Sat, 1 Jun 2002 05:30:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g51CU7nC020859 for ; Sat, 1 Jun 2002 05:30:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA47215 for ; Sat, 1 Jun 2002 07:31:42 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA40045 for ; Sat, 1 Jun 2002 07:31:42 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g51CS7919910; Sat, 1 Jun 2002 07:28:07 -0500 Message-Id: <200206011228.g51CS7919910@jen.americas.sgi.com> Date: Sat, 1 Jun 2002 07:28:07 -0500 Subject: TAKE - add a readpages method to xfs in 2.5 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Use more of Andrew Morton's new I/O work - baby steps for now, lots more to do here. Date: Sat Jun 1 05:30:35 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:120635a linux/fs/xfs/linux/xfs_iops.c - 1.147 - Add a readpages method to xfs From owner-linux-xfs@oss.sgi.com Sat Jun 1 09:18:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g51GIInC022706 for ; Sat, 1 Jun 2002 09:18:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g51GIIYd022705 for linux-xfs-outgoing; Sat, 1 Jun 2002 09:18:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bird.iucha.org (IDENT:2593-ident-is-a-completely-pointless-protocol-that-offers-no-security-or-traceability-at-all-so-take-this-and-log-it!@florin.dsl.visi.com [209.98.146.184]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g51GI7nC022674 for ; Sat, 1 Jun 2002 09:18:08 -0700 Received: by bird.iucha.org (Postfix, from userid 1000) id ACD16D3B; Sat, 1 Jun 2002 09:48:17 -0500 (CDT) Date: Sat, 1 Jun 2002 09:48:16 -0500 To: Steve Lord Cc: linux-xfs@oss.sgi.com, Paul Schutte , theo@bl0wfish.org, c.pascoe@itee.uq.edu.au Subject: Re: Problems with 2.4.19-pre9 Message-ID: <20020601144816.GA16443@iucha.net> References: <20020531115832.GA1401@iucha.net> <3CF76A46.3FEC1553@up.ac.za> <1022856397.27212.1.camel@jen.americas.sgi.com> <1022857695.28497.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <1022857695.28497.8.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.28i X-message-flag: Outlook: Where do you want [your files] to go today? From: florin@iucha.net (Florin Iucha) X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,SHORT_RECEIVED_LINE,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 31, 2002 at 10:08:15AM -0500, Steve Lord wrote: > Can someone who experiences this problem (and is using the debian 2.95 > compiler) try this patch on a current tree and see if the problem goes > away please? >=20 > Thanks > Steve With this patch, 2.4.19-pre9-xfs compiled with Debian 2.95.4 prerelease survives a simultaneous kernel compile, cd burning, md5sums, mail reading and web browsing. This is my "heavy" workload. Thank you Steve and XFS team. florin --=20 "NT is to UNIX what a dougnut is to a particle accelerator." 41A9 2BDE 8E11 F1C5 87A6 03EE 34B3 E075 3B90 DFE4 --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8+N6vNLPgdTuQ3+QRAiYqAKCTLU+PUe4v1KRvHlhKxx42PQ8YmwCfZ316 HlyROwsBNPl4VtIoLbkTqqQ= =XkCD -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS-- From owner-linux-xfs@oss.sgi.com Sun Jun 2 02:34:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g529Y9nC002938 for ; Sun, 2 Jun 2002 02:34:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g529Y9W0002937 for linux-xfs-outgoing; Sun, 2 Jun 2002 02:34:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta01bw.bigpond.com (mta01bw.bigpond.com [139.134.6.78]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g529Y1nC002909 for ; Sun, 2 Jun 2002 02:34:02 -0700 Message-Id: <200206020934.g529Y1nC002909@oss.sgi.com> Received: from there ([144.135.24.87]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw Apr 29 2002 13:22:02) with SMTP id GX2NZF00.5N3 for ; Sun, 2 Jun 2002 19:35:39 +1000 Received: from CPE-144-137-136-199.qld.bigpond.net.au ([144.137.136.199]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V3.0m 62/9563708); 02 Jun 2002 19:35:38 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-xfs@oss.sgi.com Subject: Re: Problems with 2.4.19-pre9 & XFS/DMAPI kernel config logic problem Date: Sun, 2 Jun 2002 19:35:35 +1000 X-Mailer: KMail [version 1.3.1] References: <20020531115832.GA1401@iucha.net> In-Reply-To: <20020531115832.GA1401@iucha.net> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was following the problem with 2.4.19-pre9-xfs originally on irc.openprojects.net #xfs but because of other issues had to leave; therefore, I'm not currently aware of where this issue ended up. I have compiled using kgcc the XFS CVS 2.4.19-pre9-xfs obtained on the 20020602-0003 and I have not seen these problems. I havn't tested it into the ground but it seems to work quite well copying files around, deleting the files, untaring kernel sources as well as kernel compiles. What I did come across though is that the kernel config logic for XFS & DMAPI doesn't really do what it should (AFAICT) from the TAKE message from a while ago. This problem I discussed with Eric & Chris Pascoe on #xfs but I'm not sure what the outcome was. What happens is that make oldconfig doesn't pick up on the fact that DMAPI should not be compiled as a module when XFS is compiled into the kernel. Everything compiles correctly - however when a depmod is run it fails because of missing symbols in the dmapi module. I'm not sure what the outcome of the discussion on #xfs came to - but if anyone needs further info just tell me. On Fri, 31 May 2002 21:58, Florin Iucha wrote: > I have noticed the same problems with 2.4.18 from XFS CVS from May 25. > > They do not occur with 2.4.18 from XFS CVS dated Apr 17. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Sun Jun 2 05:49:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52CnFnC012807 for ; Sun, 2 Jun 2002 05:49:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52CnFqC012806 for linux-xfs-outgoing; Sun, 2 Jun 2002 05:49:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52Cn9nC012775 for ; Sun, 2 Jun 2002 05:49:09 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA52590 for ; Sun, 2 Jun 2002 07:50:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA67560 for ; Sun, 2 Jun 2002 07:50:48 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g52Cl4S07605; Sun, 2 Jun 2002 07:47:04 -0500 Message-Id: <200206021247.g52Cl4S07605@jen.americas.sgi.com> Date: Sun, 2 Jun 2002 07:47:04 -0500 Subject: TAKE - switch xfs perag log to a rw_semaphore To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Switch type used for this internal lock to the more efficient rw_semaphore. Improves allocator performance a few percent. Date: Sun Jun 2 05:48:46 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120640a linux/fs/xfs/xfs_ialloc.c - 1.156 linux/fs/xfs/xfs_itable.c - 1.104 linux/fs/xfs/xfs_mount.h - 1.142 linux/fs/xfs/xfs_mount.c - 1.285 linux/fs/xfs/xfs_alloc.c - 1.150 linux/fs/xfs/xfs_fsops.c - 1.77 linux/fs/xfs/xfs_bmap.c - 1.283 From owner-linux-xfs@oss.sgi.com Sun Jun 2 08:28:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52FSYnC013919 for ; Sun, 2 Jun 2002 08:28:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52FSYgv013918 for linux-xfs-outgoing; Sun, 2 Jun 2002 08:28:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52FSLnC013885 for ; Sun, 2 Jun 2002 08:28:21 -0700 Received: from alfanett.no (mail1.alfanett.no [195.134.40.22]) 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 IAA06722 for ; Sun, 2 Jun 2002 08:29:59 -0700 (PDT) mail_from (carll@online.no) Received: from jollyjumper (kunde4213.alfanett.no [195.134.62.189]) by alfanett.no (8.9.3/8.9.3/alfaNETT1.0) with ESMTP id RAA03150 for ; Sun, 2 Jun 2002 17:11:22 +0200 Received: from carll by jollyjumper with local (Exim 3.35 #1 (Debian)) id 17EX14-0007mT-00 for ; Sun, 02 Jun 2002 17:11:34 +0200 To: linux-xfs@oss.sgi.com Subject: State D with 2.4.8, XFS-1.1 and GCC-3.0.4 on Debian Sid From: Carl Lunde Date: Sun, 02 Jun 2002 17:11:34 +0200 Message-ID: <87elfpiul5.fsf@online.no> Lines: 82 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk First I want to say that the contents and of this machine is not important, but I assume you are interested in any problems. I do not know if this is XFS-related, but $ mount /dev/hda1 on / type xfs (rw) proc on /proc type proc (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) it's the only file system I use. I noticed the following process; USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 6172 0.0 0.1 1464 496 ? D May30 0:04 find / (..) and I found out that this problem isn't new, this had happened to every updatedb-job started by crond, and it happened to my `find /' process too. Further checking showed; # ls -l /proc/6172/cwd cwd -> /usr/share/texmf/fonts/tfm/cg/ # ls -l /proc/6172/fd/ ... 4 -> /usr/share/texmf/fonts/tfm/cg/times/ # strace ls -l /usr/share/texmf/fonts/tfm/cg/times/ open("/usr/share/texmf/fonts/tfm/cg/times/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 brk(0x8059000) = 0x8059000 getdents64(0x3, 0x8056848, 0x1000, 0 ^-- end of output So - this happens to every process doing that there, I haven't found anything similar elsewhere so far. These processes does not respond to kill -9, and I assumed you wanted to know about this before I'll reboot and see if the problem persists. System info: $ uname -a Linux jollyjumper 2.4.18-xfs-1.1 #6 Fri May 24 23:33:01 CEST 2002 i686 unknown $ cat /var/log/dmesg | important-stuff(?) Linux version 2.4.18-xfs-1.1 (root@jollyjumper) (gcc version 3.0.4) #6 Fri May 24 23:33:01 CEST 2002 CPU: AMD Duron(tm) Processor stepping 01 SGI XFS with ACLs, quota, no debug enabled ^- ouch XFS mounting filesystem ide0(3,1) XFS: WARNING: recovery required on readonly filesystem. ^- hmm[0] XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: ide0(3,1) (dev: 3/1) Ending XFS recovery on filesystem: ide0(3,1) (dev: 3/1) [0] Hmm; $ uptime 16:56:16 up 7 days, 15 min, 3 users, load average: 10.28, 10.10, 9.65 $ last | magickfilter reboot system boot 2.4.18-xfs-1.1 Sun May 26 16:40 (7+00:14) I cannot remember why I rebooted, but I think it shut down as normal but not completely, it froze for more than 30 sec without making a sound so I `pulled the plug'. At least this[1] shows the problem didn't start directly after the unclean shutdown. [1] $ ps aux |grep D USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND [..not State D..] root 6172 0.0 0.1 1464 496 ? D May30 0:04 find / -xdev ( -false ) -prune -o ( -type f -perm +06000 -o ( ( -type b -o -type c ) -a -not ( -false ) ) ) -printf %8i %5m %3n %-10u %-10g %9s %t %h/%f?n [...] Cron probably started several similar find-processes before without any problems. $ dpkg -l xfsprogs ii xfsprogs 2.0.6-2 Utilities for managing the XFS filesystem Full logs, config files etc. are available at request - I can put them out on the web if you want, I'm available on IRC as Plante, #xfs@OPN at least today, sunday, and monday. -- best regards Carl Lunde From owner-linux-xfs@oss.sgi.com Sun Jun 2 09:20:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52GKvnC014462 for ; Sun, 2 Jun 2002 09:20:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52GKvAa014461 for linux-xfs-outgoing; Sun, 2 Jun 2002 09:20:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52GKbnC014420 for ; Sun, 2 Jun 2002 09:20:37 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id 6B499C00BFA for ; Mon, 3 Jun 2002 00:22:21 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 0210EC00BD2 for ; Mon, 3 Jun 2002 00:22:12 +0800 (PHT) Received: from 192.168.0.1 ( [192.168.0.1]) as user jijo@127.0.0.1 by horde.leathercollection.ph with HTTP; Mon, 3 Jun 2002 00:22:11 +0800 Message-ID: <1023034931.3cfa4633e5fa3@horde.leathercollection.ph> Date: Mon, 3 Jun 2002 00:22:11 +0800 From: Federico Sevilla III To: linux-xfs@oss.sgi.com Subject: Re: State D with 2.4.18, XFS-1.1 and GCC-3.0.4 on Debian Sid References: <87elfpiul5.fsf@online.no> In-Reply-To: <87elfpiul5.fsf@online.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.0 X-Originating-IP: 192.168.0.1 X-Organization: The Leather Collection, Inc. X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Quoting Carl Lunde : > First I want to say that the contents and of this machine is not important, > but I assume you are interested in any problems. I do not know if this > is XFS-related, but > $ mount > /dev/hda1 on / type xfs (rw) > proc on /proc type proc (rw) > devpts on /dev/pts type devpts (rw,gid=5,mode=620) > it's the only file system I use. On a server I maintain I experienced this problem awhile back, too. Unfortunately I could not isolate the problem, nor successfully reproduce it, despite the fact it happened maybe four times on various snapshots of 2.4.18-xfs, all compiled with gcc-3.0, on various states of uptime (two days, five days, and some other times even more than ten days already). I also use Debian Sid (crazy, I know). The server is now on a CVS snapshot of 2.4.18-xfs checked out on 2002-05-13, with RML's preempt-4 patch, compiled with gcc 2.95.4, and it's been up and running stably since. It's either something that made it to CVS before 2002-05-13, or the fact that I'm back to using gcc 2.95.4 from gcc 3.0.4. I haven't tried using gcc 3.1 for the kernels of any of my XFS systems, yet, and don't plan to until the coast seems clear enough. I'm sure it wasn't the preempt patch's fault. The first time things froze I had the preempt patch so I pulled it out right away (keeping the CVS snapshot of that date... which unfortunately I did not jot down). And things still froze. The system now has the preempt patch in and things have been working really well, so far. Uptime has been 12 days, and that's because of a blackout that our UPSs didn't have enough to see things through. > I noticed the following process; > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > root 6172 0.0 0.1 1464 496 ? D May30 0:04 find / (..) > and I found out that this problem isn't new, this had happened to every > updatedb-job started by crond, and it happened to my `find /' process too. The server here used to run X, and our only sign of trouble would be a completely cold freeze. No logs. No errors. Nothing. Which is also why I hadn't reported anything to this list. It could have been anything under the sun. I thought it might have been hardware, specifically something with X and my video card. I dropped X and got myself a workstation to use, instead. The "lockup" happened once when X was not running. Although thankfully (?) because X was not running it didn't freeze cold. Instead I noticed state D processes creeping in slowly. My "ps ax"'s would freeze, and later on a "ps ax" would not freeze and showed a growing number of state D processes. Most of them at the time were hung "ps ax"'s of mine, or instances of uvscan scanning mail, stuck way beyond their expected run time. Lately (with my new kernel) I notice that my uvscan calls modprobe to do some sort of scan every time it's run. This causes a delay with my current box but is no major problem with our loads. However it is possible, in hindsight, that it's these modprobes, and not the uvscan's themselves, that made the uvscan processes get stuck in state D. Just maybe. Like you, all these state D processes could not be killed. This last "creeping death" happened in mid-day so I had all users (thankfully we're a relatively small firm) save their work and I issued a "shutdown -r now". The shutdown did not complete successfully. It froze while attempting to kill all processes. A reboot required recovery of the partitions, but this thankfully went well. > Further checking showed; > # ls -l /proc/6172/cwd > cwd -> /usr/share/texmf/fonts/tfm/cg/ > > # ls -l /proc/6172/fd/ > ... > 4 -> /usr/share/texmf/fonts/tfm/cg/times/ > > # strace ls -l /usr/share/texmf/fonts/tfm/cg/times/ > open("/usr/share/texmf/fonts/tfm/cg/times/", > O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 > fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 > fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 > brk(0x8059000) = 0x8059000 > getdents64(0x3, 0x8056848, 0x1000, 0 > ^-- end of output I'm glad you were able to get stuff like this. I wasn't. Does the XFS team have any suggestions for standard debugging tasks to do when things go wrong (without a kernel oops or anything like that, but these hung processes) to see what's goofing up and help you help us all? > So - this happens to every process doing that there, I haven't found > anything > similar elsewhere so far. These processes does not respond to kill -9, and > I assumed you wanted to know about this before I'll reboot and see if the > problem persists. With me I would get random uptime but it would eventually happen again. The "creeping death with state D's" only happened once, though, before I upgraded my kernel with a new snapshot and a downgraded compiler and got things to work thus far. Before that all we had were cold freezes. > I cannot remember why I rebooted, but I think it shut down as normal > but not completely, it froze for more than 30 sec without making a sound > so I `pulled the plug'. At least this[1] shows the problem didn't start > directly after the unclean shutdown. This sounds similar to what happend to my box. And the three-finger-salute didn't do the job. Neither did the Magic SysRq. I had to hit the reset button. It was a server (still is) so I couldn't take my time. Unfortunately that also means I was quiet until you came along and all I had to do was add on more info. :( > [1] > $ ps aux |grep D > USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND > [..not State D..] > root 6172 0.0 0.1 1464 496 ? D May30 0:04 find / -xdev > ( -false ) -prune -o ( -type f -perm +06000 -o ( ( -type b -o -type c ) -a > -not ( -false ) ) ) -printf %8i %5m %3n %-10u %-10g %9s %t %h/%f?n > [...] > Cron probably started several similar find-processes before without any > problems. Yes. You can't just reproduce them, or at least from my experience. But when the "creeping death" came, things just started getting stuck. Now it's procedure for me to do "ps ax" and check for state D stuff that stay in state D for too long. --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Sun Jun 2 09:33:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52GX0nC014960 for ; Sun, 2 Jun 2002 09:33:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52GX0PL014959 for linux-xfs-outgoing; Sun, 2 Jun 2002 09:33:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52GWpnC014925 for ; Sun, 2 Jun 2002 09:32:52 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id DF0D3144B8; Sun, 2 Jun 2002 18:34:31 +0200 (MEST) Received: from aj by arthur.inka.de with local (Exim 3.34 #1) id 17EYJJ-00011T-00; Sun, 02 Jun 2002 18:34:29 +0200 Mail-Copies-To: never To: nathans@sgi.com, a.gruenbacher@computer.org, linux-xfs@oss.sgi.com Cc: drepper@redhat.com Subject: xattr API question From: Andreas Jaeger Date: Sun, 02 Jun 2002 18:34:29 +0200 Message-ID: Lines: 42 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm one of the glibc developers and we considered adding support for the *xattr syscalls to glibc. Ulrich Drepper mentioned: > - the various *xattr syscalls which were introduced in the 2.5 kernel > might need libc support. I guess they do. But somebody should contact > whoever wrote the code and ask them about the API which should be > provided. Can you tell me a bit more about the API? Is it stable? Should we define it in glibc? Which constants/flags should be added? Do you have some more documentation for the interface? Is it used in other OSes and which header files define all the stuff? I guess, we have these interfaces to implement and at least briefly document: setxattr(char *path, char *name, void *value, size_t size, int flags); lsetxattr(char *path, char *name, void *value, size_t size, int flags); fsetxattr(int fd, char *name, void *value, size_t size, int flags) getxattr(char *path, char *name, void *value, size_t size) lgetxattr(char *path, char *name, void *value, size_t size) fgetxattr(int fd, char *name, void *value, size_t size) listxattr(char *path, char *list, size_t size) llistxattr(char *path, char *list, size_t size) flistxattr(int fd, char *list, size_t size) removexattr(char *path, char *name) lremovexattr(char *path, char *name) fremovexattr(int fd, char *name) Some questions: What's the meaning of the size parameter? What can be given for flags? What does getxattr return? Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-xfs@oss.sgi.com Sun Jun 2 09:51:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52GpgnC015218 for ; Sun, 2 Jun 2002 09:51:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52Gpgfe015217 for linux-xfs-outgoing; Sun, 2 Jun 2002 09:51:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from alfanett.no (mail1.alfanett.no [195.134.40.22]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52GpXnC015189 for ; Sun, 2 Jun 2002 09:51:33 -0700 Received: from jollyjumper (kunde4213.alfanett.no [195.134.62.189]) by alfanett.no (8.9.3/8.9.3/alfaNETT1.0) with ESMTP id SAA16199; Sun, 2 Jun 2002 18:53:08 +0200 Received: from carll by jollyjumper with local (Exim 3.35 #1 (Debian)) id 17EYbW-0008A7-00; Sun, 02 Jun 2002 18:53:18 +0200 To: Federico Sevilla III Cc: linux-xfs@oss.sgi.com Subject: Re: State D with 2.4.18, XFS-1.1 and GCC-3.0.4 on Debian Sid References: <87elfpiul5.fsf@online.no> <1023034931.3cfa4633e5fa3@horde.leathercollection.ph> From: Carl Lunde Date: Sun, 02 Jun 2002 18:53:18 +0200 In-Reply-To: <1023034931.3cfa4633e5fa3@horde.leathercollection.ph> (Federico Sevilla III's message of "Mon, 3 Jun 2002 00:22:11 +0800") Message-ID: <87k7phd3lt.fsf@online.no> Lines: 46 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g52GpYnC015190 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Federico Sevilla III writes: [...] > "/usr/share/texmf/fonts/tfm/cg/times/", >> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 >> fstat64(3, {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 >> fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 >> brk(0x8059000) = 0x8059000 >> getdents64(0x3, 0x8056848, 0x1000, 0 >> ^-- end of output > > I'm glad you were able to get stuff like this. I wasn't. Does the XFS team have > any suggestions for standard debugging tasks to do when things go wrong (without > a kernel oops or anything like that, but these hung processes) to see what's > goofing up and help you help us all? > It could be interresting to look at /proc//, to get a overview of what the process was doing. The fd-directory shows all file-descriptors, cwd current working directory, etc. My next kernel will have kdb, magick sysrq and xfs-debugging ;) >> [1] >> $ ps aux |grep D >> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND >> [..not State D..] >> root 6172 0.0 0.1 1464 496 ? D May30 0:04 find / -xdev >> ( -false ) -prune -o ( -type f -perm +06000 -o ( ( -type b -o -type c ) -a >> -not ( -false ) ) ) -printf %8i %5m %3n %-10u %-10g %9s %t %h/%f?n >> [...] >> Cron probably started several similar find-processes before without any >> problems. > > Yes. You can't just reproduce them, or at least from my experience. But when the > "creeping death" came, things just started getting stuck. Now it's procedure for > me to do "ps ax" and check for state D stuff that stay in state D for too long. > What I meant was that `this was the first State D-process, but not the first time that particular directory was getdents'ed[0], because cron runs find / every morning.' This problem is reproducable - all processes doing that syscall gets stuck in State D. [0] getdents(2) - get directory entries getdents reads several dirent structures from the direc­ tory pointed at by fd into the memory area pointed to by dirp. From owner-linux-xfs@oss.sgi.com Sun Jun 2 12:23:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52JNknC016982 for ; Sun, 2 Jun 2002 12:23:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52JNkJq016981 for linux-xfs-outgoing; Sun, 2 Jun 2002 12:23:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost (IP-213157011078.dialin.heagmedianet.de [213.157.11.78]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52JNWnC016948 for ; Sun, 2 Jun 2002 12:23:38 -0700 Received: from dreamind by localhost with local (Exim 3.35 #1 (Debian)) id 17Eay7-0001EB-00; Sun, 02 Jun 2002 21:24:47 +0200 Date: Sun, 2 Jun 2002 21:24:47 +0200 From: Stefan Pfetzing To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with 2.4.19-pre9 Message-ID: <20020602192447.GA1431@dreamind.de> References: <20020531084828.GA2328@dreamind.de> <1022844809.1146.15.camel@snafu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1022844809.1146.15.camel@snafu> User-Agent: Mutt/1.3.28i Organization: private X-PGP-Algorithms: RSA and DSA/EG keys are available X-Operating-System: Debian GNU/Linux 3.0 (Kernel 2.4.19-pre9-xfs) X-Cool: http://dreamind.de X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, * Stephen Lord [020531 13:33]: > On Fri, 2002-05-31 at 03:48, Stefan Pfetzing wrote: [snip] > Which compiler are you using? We were looking into this problem > yesterday, we sent that person a new kernel built with a > different compiler and the problem went away. Well I use 2.95.4 as it comes with debian. I compiled _every_ XFS enabled kernel before with this compiler version without _any_ problems. Today I noticed that the filesystem seemed to lock totally and I had to hard-reset the machine. bye Stefan From owner-linux-xfs@oss.sgi.com Sun Jun 2 12:32:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52JWtnC017217 for ; Sun, 2 Jun 2002 12:32:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52JWs8C017216 for linux-xfs-outgoing; Sun, 2 Jun 2002 12:32:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dc-mx04.cluster1.charter.net (dc-mx04.cluster1.charter.net [209.225.8.14]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52JWnnC017185 for ; Sun, 2 Jun 2002 12:32:50 -0700 Received: from [216.207.95.43] (HELO there) by dc-mx04.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with SMTP id 21147946 for linux-xfs@oss.sgi.com; Sun, 02 Jun 2002 15:34:29 -0400 Content-Type: text/plain; charset="iso-8859-15" From: Raymond To: linux-xfs Subject: RAID Controller Caching and XFS Date: Sun, 2 Jun 2002 12:35:20 -0700 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have enabled write-backing caching on a MegaRAID 1500 with battery back-up. Two other cache options exist: Read-Ahead and I/O Caching. Any potential problems enabling these options with XFS 1.02? Raymond From owner-linux-xfs@oss.sgi.com Sun Jun 2 13:36:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52KalnC017681 for ; Sun, 2 Jun 2002 13:36:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52KakB1017680 for linux-xfs-outgoing; Sun, 2 Jun 2002 13:36:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52KaenC017652 for ; Sun, 2 Jun 2002 13:36:40 -0700 Received: from mail.pronto.tv ([62.70.58.70]) 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 NAA02645 for ; Sun, 2 Jun 2002 13:38:20 -0700 (PDT) mail_from (roy@karlsbakk.net) Received: from localhost (roy@localhost) by mail.pronto.tv (8.11.6/8.11.6) with ESMTP id g52KInB26945; Sun, 2 Jun 2002 22:18:50 +0200 X-Authentication-Warning: mail.pronto.tv: roy owned process doing -bs Date: Sun, 2 Jun 2002 22:18:49 +0200 (CEST) From: Roy Sigurd Karlsbakk X-X-Sender: To: Raymond cc: linux-xfs Subject: Re: RAID Controller Caching and XFS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I have enabled write-backing caching on a MegaRAID 1500 with battery back-up. > > Two other cache options exist: Read-Ahead and I/O Caching. > > Any potential problems enabling these options with XFS 1.02? Shouldn't be a problem as long as he battery backup works. Given a power failure, the data should be written back to disk as fast as the system is being brought on-line. That is - if the battery backup works. I'd check for how long the battery will last. Contact the vendor and try to get the guarantied values. Also - how long the battery will last under normal and extraordinary conditions. roy -- Roy Sigurd Karlsbakk, Datavaktmester Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Sun Jun 2 14:45:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52LjLnC018185 for ; Sun, 2 Jun 2002 14:45:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52LjL1N018184 for linux-xfs-outgoing; Sun, 2 Jun 2002 14:45:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52LjFnC018149 for ; Sun, 2 Jun 2002 14:45:15 -0700 Received: from npi39.com (116.106-30-212.9massy1-1-ro-as-i2-2.9tel.net [212.30.106.116]) by smtp4.9tel.net (Postfix) with ESMTP id 62C0D5C5A0; Sun, 2 Jun 2002 23:09:59 +0200 (CEST) Message-ID: <730420026022170347@npi39.com> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: callme@npi39.com.sgi.com To: "-" From: "Appellemoi !" Subject: Quelqu'un t'aime en secret Date: Sun, 2 Jun 2002 23:07:00 +0200 MIME-Version: 1.0 X-Spam-Status: No, hits=1.7 required=5.0 tests=X_EM_VER_PRESENT,FROM_AND_TO_SAME version=2.20 X-Spam-Level: * Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sun Jun 2 16:19:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52NJfnC018958 for ; Sun, 2 Jun 2002 16:19:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52NJfau018957 for linux-xfs-outgoing; Sun, 2 Jun 2002 16:19:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52NJSnC018929 for ; Sun, 2 Jun 2002 16:19:28 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA07263 for ; Sun, 2 Jun 2002 16:21:11 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04499; Mon, 3 Jun 2002 09:19:30 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA28436; Mon, 3 Jun 2002 09:19:28 +1000 (AEST) Date: Mon, 3 Jun 2002 09:19:27 +1000 From: Nathan Scott To: Andreas Jaeger , a.gruenbacher@computer.org Cc: drepper@redhat.com, linux-xfs@oss.sgi.com, acl-devel@bestbits.at Subject: Re: xattr API question Message-ID: <20020603091927.Y207538@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from aj@suse.de on Sun, Jun 02, 2002 at 06:34:29PM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi there Andreas, On Sun, Jun 02, 2002 at 06:34:29PM +0200, Andreas Jaeger wrote: > > Hi, > > I'm one of the glibc developers and we considered adding support for > the *xattr syscalls to glibc. > > Ulrich Drepper mentioned: > > - the various *xattr syscalls which were introduced in the 2.5 kernel > > might need libc support. I guess they do. But somebody should contact > > whoever wrote the code and ask them about the API which should be > > provided. > > Can you tell me a bit more about the API? The best source of info is probably the man pages - they are part of the "attr" source package, and are also online at: http://acl.bestbits.at/man/man.shtml > Is it stable? Yes, the interfaces are essentially unchanged since their initial inclusion in 2.5.3. Marcelo has told us this will be included in 2.4.20. > Should we define it in glibc? I think so, yes. There is a libattr.so which also exports the system calls, so provided the two can coexist that would be great. > Which constants/flags should be added? The attr package installs the header /usr/include/attr/xattr.h which defines all the interesting macros, etc. > Do you have some more documentation for the interface? The attr package contains several man pages (in addition to the system call interfaces), and AndreasG's web site also contains extra docs on extended attributes -- http://acl.bestbits.at/. > Is it used in other OSes and which header files define all the stuff? There are extended attributes interfaces on other OSes, but there's no standardisation in this area, and no two interfaces are really alike. > ... > Some questions: What's the meaning of the size parameter? What can be > given for flags? What does getxattr return? These last few questions are answered in the syscall man pages. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jun 2 16:53:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g52Nr8nC019289 for ; Sun, 2 Jun 2002 16:53:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g52Nr8qD019288 for linux-xfs-outgoing; Sun, 2 Jun 2002 16:53:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from uni01du.unity.ncsu.edu (uni01du.unity.ncsu.edu [152.1.2.65]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g52Nr4nC019260 for ; Sun, 2 Jun 2002 16:53:04 -0700 Received: (from pmkasodh@localhost) by uni01du.unity.ncsu.edu (8.8.4/EC02Jan97) id TAA16652; Sun, 2 Jun 2002 19:54:48 -0400 (EDT) Date: Sun, 2 Jun 2002 19:54:48 -0400 (EDT) From: Palash Mohanlal Kasodhan To: linux-xfs@oss.sgi.com Subject: XFS client software Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I intend to deploy XFS over Linux as a network file system. I wanted to know where can I get the XFS client software, so as to allow access from both Windows based and Linux based clients. Thanks Palash Kasodhan From owner-linux-xfs@oss.sgi.com Sun Jun 2 17:23:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g530NHnC019664 for ; Sun, 2 Jun 2002 17:23:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g530NHHu019663 for linux-xfs-outgoing; Sun, 2 Jun 2002 17:23:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g530NCnC019634 for ; Sun, 2 Jun 2002 17:23:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA02470 for ; Sun, 2 Jun 2002 17:24:54 -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 KAA99639; Mon, 3 Jun 2002 10:23:34 +1000 (EST) Date: Mon, 3 Jun 2002 10:23:34 +1000 (EST) From: Nathan Scott Message-Id: <200206030023.KAA99639@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - setxattr man page X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Jun 2 17:22:06 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/xfs-cmds The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/xfs-cmds Modid: xfs-cmds:slinx:120646a attr/man/man2/setxattr.2 - 1.3 - update from AndreasG - missing some uses of const in function prototypes. From owner-linux-xfs@oss.sgi.com Sun Jun 2 18:01:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5311RnC020013 for ; Sun, 2 Jun 2002 18:01:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5311RE3020012 for linux-xfs-outgoing; Sun, 2 Jun 2002 18:01:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost (mail@IP-213157011009.dialin.heagmedianet.de [213.157.11.9]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5311JnC019984 for ; Sun, 2 Jun 2002 18:01:20 -0700 Received: from dreamind by localhost with local (Exim 3.35 #1 (Debian)) id 17EgFN-0000oS-00; Mon, 03 Jun 2002 03:02:57 +0200 Date: Mon, 3 Jun 2002 03:02:57 +0200 From: Stefan Pfetzing To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with 2.4.19-pre9 Message-ID: <20020603010257.GA3015@dreamind.de> References: <20020531115832.GA1401@iucha.net> <3CF76A46.3FEC1553@up.ac.za> <1022856397.27212.1.camel@jen.americas.sgi.com> <1022857695.28497.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1022857695.28497.8.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.28i Organization: private X-PGP-Algorithms: RSA and DSA/EG keys are available X-Operating-System: Debian GNU/Linux 3.0 (Kernel 2.4.19-pre9-xfs) X-Cool: http://dreamind.de X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk * Steve Lord [020531 17:08]: > On Fri, 2002-05-31 at 09:46, Steve Lord wrote: [snip] > Can someone who experiences this problem (and is using the debian 2.95 > compiler) try this patch on a current tree and see if the problem goes > away please? I just tested it with a just checked out CVS version and this patch, but still getting almost the same thing... For example when extracting a kernel tar.bz2 it mostly hangs when creating directories (at least it seems so) for about 5-10 seconds. Removing also hangs sometimes for some seconds. bye dreamind P.S.: still using 2.95.4 -- http://www.dreamind.de/ Oroborus and Debian GNU/Linux Developer. From owner-linux-xfs@oss.sgi.com Sun Jun 2 18:43:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g531h7nC020510 for ; Sun, 2 Jun 2002 18:43:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g531h7Tx020509 for linux-xfs-outgoing; Sun, 2 Jun 2002 18:43:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@[216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g531h3nC020481 for ; Sun, 2 Jun 2002 18:43:03 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 90D544C303D; Sun, 2 Jun 2002 21:44:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 87D7FC0EE0F; Sun, 2 Jun 2002 21:44:55 -0400 (EDT) Date: Sun, 2 Jun 2002 21:44:55 -0400 (EDT) From: Mike Burger To: Palash Mohanlal Kasodhan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS client software In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Samba...NFS...or both. On Sun, 2 Jun 2002, Palash Mohanlal Kasodhan wrote: > I intend to deploy XFS over Linux as a network file system. I wanted to > know where can I get the XFS client software, so as to allow access from both Windows > based and Linux based clients. > > > Thanks > Palash Kasodhan > From owner-linux-xfs@oss.sgi.com Sun Jun 2 20:43:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g533h2nC022076 for ; Sun, 2 Jun 2002 20:43:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g533h2iN022075 for linux-xfs-outgoing; Sun, 2 Jun 2002 20:43:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g533grnC022044 for ; Sun, 2 Jun 2002 20:42:54 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id UAA03658 for ; Sun, 2 Jun 2002 20:44:31 -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 NAA55215; Mon, 3 Jun 2002 13:43:10 +1000 (AEST) Date: Mon, 3 Jun 2002 13:43:10 +1000 From: Tim Shimmin To: Nathan Scott Cc: anmar@canada.com, linux-xfs@oss.sgi.com Subject: Re: retrieving exteneded attributes speed issues Message-ID: <20020603134310.C1852610@boing.melbourne.sgi.com> References: <3CF7DB07.2060205@merlintechnologies.com> <20020601125351.X207538@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020601125351.X207538@wobbly.melbourne.sgi.com>; from nathans@sgi.com on Sat, Jun 01, 2002 at 12:53:51PM +1000 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jun 01, 2002 at 12:53:51PM +1000, Nathan Scott wrote: > hi, > > On Fri, May 31, 2002 at 01:20:23PM -0700, Anmar Oueja wrote: > > What's the best way of efficiently retrieving all extended attributes of > > a file on an XFS partition? > > > > Now I'm doing what the utility getattr does: > > [...stuff deleted...] > There is another solution as well, as Steve has pointed out - xfsdump > uses some XFS-specific ioctl's to get back multiple attribute values > at once. Such a program would only work on XFS filesystems though, > where as getfattr will work for all filesystems supporting EAs. > On IRIX and old linux-xfs, a low syscall count solution for what you want is attr_multi (and attr_list). It would for instance, allow you to get all the values for a list of names in 2 syscalls. However, with the syscall reorg, attr_multi is now done as multiple syscalls. xfsdump uses jdm_attr_list and jdm_attr_multi (these have been retained). jdm_attr_list is used to get the list of names and valuelen's to put into a multi struct, and jdm_attr_multi is used to get all the values in one syscall. These are done as single ioctls so retain the efficiency. I'm not so famiiliar with the jdm_*() calls, but I think one would need to call jdm_getfshandle(mntpt) to get an fshandle, and one also needs an xfs_bstat_t (for an ino#/gen#) which one normally gets from a bulkstat ioctl (XFS_IOC_FSBULKSTAT, XFS_IOC_FSBULKSTAT_SINGLE). --Tim From owner-linux-xfs@oss.sgi.com Mon Jun 3 00:26:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g537QenC024111 for ; Mon, 3 Jun 2002 00:26:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g537QeOW024110 for linux-xfs-outgoing; Mon, 3 Jun 2002 00:26:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g537QNnC024079 for ; Mon, 3 Jun 2002 00:26:23 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 272ACC21B; Mon, 3 Jun 2002 09:03:09 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id JAA06603; Mon, 3 Jun 2002 09:03:08 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 7904457307; Mon, 3 Jun 2002 09:02:08 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 8651425836; Mon, 3 Jun 2002 09:02:03 +0200 (CEST) Message-ID: <3CFB146B.163BEFD4@ch.sauter-bc.com> Date: Mon, 03 Jun 2002 09:02:03 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Joseph Mesterhazy Cc: linux-xfs Subject: Re: Saving ACL's References: <3CF77639.4090805@iastate.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joseph Mesterhazy schrieb: > > Hi, > > I have a simple question. Are there any ACL aware commands for linux? It seems > like the simple tools, eg. cp, tar, etc. do not preserve ACL's. This throws a Star is the tar you may want to use. Simon > wrench in my plans somewhat as I am serving to windows via samba, with ACL's > enabled, and I have no way to backup in a way that preserves ACL's. > > Joe > > -- > Joe Mesterhazy > ECpE UNIX Administrator > 2101 Coover Hall, Iowa State University > Ames, IA 50011. (515) 294-7359 > http://joe.mesterhazy.net/ From owner-linux-xfs@oss.sgi.com Mon Jun 3 02:13:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g539DunC025472 for ; Mon, 3 Jun 2002 02:13:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g539DuLc025471 for linux-xfs-outgoing; Mon, 3 Jun 2002 02:13:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g539DnnC025441 for ; Mon, 3 Jun 2002 02:13:50 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g539FVx1067736; Mon, 3 Jun 2002 11:15:33 +0200 (CEST) Message-Id: <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Jun 2002 11:16:35 +0200 To: Raymond , linux-xfs From: Seth Mos Subject: Re: RAID Controller Caching and XFS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:35 2-6-2002 -0700, Raymond wrote: >I have enabled write-backing caching on a MegaRAID 1500 with battery back-up. > >Two other cache options exist: Read-Ahead and I/O Caching. > >Any potential problems enabling these options with XFS 1.02? I have not found any using caching IO. Read ahead can safely be used, but the readahead under linux itself is probably more usefull. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jun 3 02:15:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g539FDnC025611 for ; Mon, 3 Jun 2002 02:15:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g539FDJP025610 for linux-xfs-outgoing; Mon, 3 Jun 2002 02:15:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g539F6nC025580 for ; Mon, 3 Jun 2002 02:15:07 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g539GUx1068408; Mon, 3 Jun 2002 11:16:42 +0200 (CEST) Message-Id: <4.3.2.7.2.20020603111702.03831978@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Jun 2002 11:17:32 +0200 To: Roy Sigurd Karlsbakk , Raymond From: Seth Mos Subject: Re: RAID Controller Caching and XFS Cc: linux-xfs In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:18 2-6-2002 +0200, Roy Sigurd Karlsbakk wrote: > > I have enabled write-backing caching on a MegaRAID 1500 with battery > back-up. > > > > Two other cache options exist: Read-Ahead and I/O Caching. > > > > Any potential problems enabling these options with XFS 1.02? > >Shouldn't be a problem as long as he battery backup works. Given a power >failure, the data should be written back to disk as fast as the system is >being brought on-line. > >That is - if the battery backup works. > >I'd check for how long the battery will last. Contact the vendor and try >to get the guarantied values. Also - how long the battery will last under >normal and extraordinary conditions. 72 hours at most. Probably less. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jun 3 03:11:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53AB8nC026443 for ; Mon, 3 Jun 2002 03:11:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53AB80G026442 for linux-xfs-outgoing; Mon, 3 Jun 2002 03:11:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.pronto.tv ([62.70.58.70]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53AB2nC026413 for ; Mon, 3 Jun 2002 03:11:03 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by mail.pronto.tv (8.11.6/8.11.6) id g53ACgj31318; Mon, 3 Jun 2002 12:12:42 +0200 Message-Id: <200206031012.g53ACgj31318@mail.pronto.tv> Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: Pronto TV AS To: Seth Mos , Raymond Subject: Re: RAID Controller Caching and XFS Date: Mon, 3 Jun 2002 12:12:42 +0200 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs References: <4.3.2.7.2.20020603111702.03831978@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20020603111702.03831978@pop.xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g53AB4nC026414 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > >I'd check for how long the battery will last. Contact the vendor and try > >to get the guarantied values. Also - how long the battery will last under > >normal and extraordinary conditions. > > 72 hours at most. Interesting.... Compaq once told me their battery backup on the SMART raid controllers could stand sevaral weeks -- Roy Sigurd Karlsbakk, Datavaktmester Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Mon Jun 3 04:49:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53BnHnC027956 for ; Mon, 3 Jun 2002 04:49:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53BnH52027955 for linux-xfs-outgoing; Mon, 3 Jun 2002 04:49:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53Bn4nC027923 for ; Mon, 3 Jun 2002 04:49:05 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id E279014618; Mon, 3 Jun 2002 13:50:47 +0200 (MEST) X-Authentication-Warning: gee.suse.de: aj set sender to aj@suse.de using -f To: Nathan Scott Cc: a.gruenbacher@computer.org, drepper@redhat.com, linux-xfs@oss.sgi.com, acl-devel@bestbits.at Subject: Re: xattr API question References: <20020603091927.Y207538@wobbly.melbourne.sgi.com> From: Andreas Jaeger Date: Mon, 03 Jun 2002 13:50:46 +0200 In-Reply-To: <20020603091927.Y207538@wobbly.melbourne.sgi.com> (Nathan Scott's message of "Mon, 3 Jun 2002 09:19:27 +1000") Message-ID: Lines: 72 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) XEmacs/21.4 (Artificial Intelligence, i386-suse-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan Scott writes: > hi there Andreas, > > On Sun, Jun 02, 2002 at 06:34:29PM +0200, Andreas Jaeger wrote: >> >> Hi, >> >> I'm one of the glibc developers and we considered adding support for >> the *xattr syscalls to glibc. >> >> Ulrich Drepper mentioned: >> > - the various *xattr syscalls which were introduced in the 2.5 kernel >> > might need libc support. I guess they do. But somebody should contact >> > whoever wrote the code and ask them about the API which should be >> > provided. >> >> Can you tell me a bit more about the API? > > The best source of info is probably the man pages - they are part > of the "attr" source package, and are also online at: > http://acl.bestbits.at/man/man.shtml > >> Is it stable? > > Yes, the interfaces are essentially unchanged since their initial > inclusion in 2.5.3. Marcelo has told us this will be included in > 2.4.20. > >> Should we define it in glibc? > > I think so, yes. There is a libattr.so which also exports the system > calls, so provided the two can coexist that would be great. We would add those interfaces to libc.so. It would help then if you would send any API changes also to the libc-alpha@sources.redhat.com list (we might not notice them otherwise). >> Which constants/flags should be added? > > The attr package installs the header /usr/include/attr/xattr.h which > defines all the interesting macros, etc. > >> Do you have some more documentation for the interface? > > The attr package contains several man pages (in addition to the system > call interfaces), and AndreasG's web site also contains extra docs on > extended attributes -- http://acl.bestbits.at/. > >> Is it used in other OSes and which header files define all the stuff? > > There are extended attributes interfaces on other OSes, but there's no > standardisation in this area, and no two interfaces are really alike. > >> ... >> Some questions: What's the meaning of the size parameter? What can be >> given for flags? What does getxattr return? > > These last few questions are answered in the syscall man pages. > > cheers. thanks a lot! I'll look soon in more detail into this, Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj From owner-linux-xfs@oss.sgi.com Mon Jun 3 05:42:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53CgGnC029339 for ; Mon, 3 Jun 2002 05:42:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53CgGPB029338 for linux-xfs-outgoing; Mon, 3 Jun 2002 05:42:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53Cg1nC029308 for ; Mon, 3 Jun 2002 05:42:02 -0700 Received: from erbenson.alaska.net (170-pm15.nwc.alaska.net [209.112.141.170]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g53Chm089657 for ; Mon, 3 Jun 2002 04:43:48 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 8D85D3939 for ; Mon, 3 Jun 2002 04:43:47 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 87B3410294; Mon, 3 Jun 2002 04:43:47 -0800 (AKDT) Date: Mon, 3 Jun 2002 04:43:47 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: acl_extended_file() broken? Message-ID: <20020603044347.I13201@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1E1Oui4vdubnXi3o" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --1E1Oui4vdubnXi3o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I was attempting to compile patched fileutils 4.1.8 for acl compatibility and finally got it working, except ls -l shows a + for all files/dirs on acl capable filesystems.=20=20 afaict it uses the libacl function acl_extended_file() to check whether a file/dir has an actual acl associated, it appears to use this function correctly so i wrote a test program and found this function appears to be lying: eb@dogbert ~$ getfacl /etc/passwd getfacl: Removing leading '/' from absolute path names # file: etc/passwd # owner: root # group: root user::rw- group::r-- other::r-- eb@dogbert ~$ getfattr -m . /etc/passwd eb@dogbert ~$ ./ckacl /etc/passwd acl_extended_file returned 1 errno: Success eb@dogbert ~$ src/fileutils/fileutils-4.1.8acl/src/ls -l /etc/passwd -rw-r--r--+ 1 root root 1408 05-23 04:36 /etc/passwd eb@dogbert ~$ am i missing something? the way i read the man page it should return 0: The acl_extended_file() function returns 1 if the file or directory referred to by the argument path_p is associated with an extended acce= ss ACL, or if the directory referred to by path_p is associated with a default ACL. The function returns 0 if the file has neither an extended access ACL nor a default ACL. eb@dogbert ~$ dpkg -s libattr1 | grep ^Ver Version: 2.0.8-1 here is my simple test program: #include #include #include int main(int argc, char **argv) { int ret; errno =3D 0; if (argc =3D=3D 2) { ret =3D acl_extended_file(argv[1]); printf("acl_extended_file returned %d\n", ret); perror("errno"); return ret; } else { printf("usage: ckacl filename\n"); return 1; } } --=20 Ethan Benson http://www.alaska.net/~erbenson/ --1E1Oui4vdubnXi3o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjz7ZIMACgkQJKx7GixEevxmTQCff9NUJfK4ssf+IjvpyIQFfnfG QpYAnRS+3m4LyWMdP2DzkM7ezfFjBYPH =uYRR -----END PGP SIGNATURE----- --1E1Oui4vdubnXi3o-- From owner-linux-xfs@oss.sgi.com Mon Jun 3 07:01:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53E16nC031634 for ; Mon, 3 Jun 2002 07:01:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53E16YA031633 for linux-xfs-outgoing; Mon, 3 Jun 2002 07:01:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp4.9tel.net (smtp4.9tel.net [213.203.124.147]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53E0xnC031595 for ; Mon, 3 Jun 2002 07:01:00 -0700 Received: from litou.com (228.103-30-212.9massy1-1-ro-as-i2-1.9tel.net [212.30.103.228]) by smtp4.9tel.net (Postfix) with ESMTP id 5D8775C490; Mon, 3 Jun 2002 15:02:45 +0200 (CEST) Message-ID: <55452002613125950641@litou.com> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: surprise@imp20.com To: "*" From: "Appellemoi !" Subject: Quelqu'un t'aime en secret Date: Mon, 3 Jun 2002 14:59:50 +0200 MIME-Version: 1.0 X-Spam-Status: No, hits=1.7 required=5.0 tests=X_EM_VER_PRESENT,DIFFERENT_REPLY_TO,FROM_AND_TO_SAME version=2.20 X-Spam-Level: * Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Jun 3 08:02:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53F2onC032360 for ; Mon, 3 Jun 2002 08:02:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53F2ofF032359 for linux-xfs-outgoing; Mon, 3 Jun 2002 08:02:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53F2hnC032328 for ; Mon, 3 Jun 2002 08:02:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA58289; Mon, 3 Jun 2002 10:04:23 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA32526; Mon, 3 Jun 2002 10:04:23 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA46850; Mon, 3 Jun 2002 10:04:22 -0500 (CDT) Message-Id: <200206031504.KAA46850@slobber.americas.sgi.com> To: Adrian Head cc: linux-xfs@oss.sgi.com Subject: Re: Problems with 2.4.19-pre9 & XFS/DMAPI kernel config logic problem Date: Mon, 03 Jun 2002 10:04:22 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Adrian Head >What I did come across though is that the kernel config logic for XFS & DMAPI >doesn't really do what it should (AFAICT) from the TAKE message from a while >ago. This problem I discussed with Eric & Chris Pascoe on #xfs but I'm not >sure what the outcome was. > >What happens is that make oldconfig doesn't pick up on the fact that DMAPI >should not be compiled as a module when XFS is compiled into the kernel. >Everything compiles correctly - however when a depmod is run it fails because >of missing symbols in the dmapi module. When xfs_support was merged back into the xfs directory, the dmapi module build was broken. You're missing symbols for things like sv_wait and kmem_* stuff. I'm working on it from time-to-time. At the very least, this pointed out a few more dependencies between XFS and DMAPI that I can work on. Someday DMAPI won't need XFS... Dean From owner-linux-xfs@oss.sgi.com Mon Jun 3 09:35:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53GZDnC001532 for ; Mon, 3 Jun 2002 09:35:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53GZDnw001531 for linux-xfs-outgoing; Mon, 3 Jun 2002 09:35:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from saiya-jin.flinthills.com (postfix@fh-dialup-202118.flinthills.com [64.39.202.118]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53GZ2nC001501 for ; Mon, 3 Jun 2002 09:35:04 -0700 Received: from localhost (localhost [127.0.0.1]) by saiya-jin.flinthills.com (Postfix) with ESMTP id 6E94E1459F0; Mon, 3 Jun 2002 11:36:09 -0500 (CDT) Date: Mon, 3 Jun 2002 11:36:09 -0500 (CDT) From: Derek J Witt To: Dean Roehrich Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with 2.4.19-pre9 & XFS/DMAPI kernel config logic problem In-Reply-To: <200206031504.KAA46850@slobber.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean, I am able to build dmapi directly into the kernel, but it doesn't build as a module. Just my 2 cents. :-) ** Derek J Witt ** * Email: mailto:djw@flinthills.com * * Home Page: http://www.flinthills.com/~djw/ * *** "...and on the eighth day, God met Bill Gates." - Unknown ** On Mon, 3 Jun 2002, Dean Roehrich wrote: > Date: Mon, 03 Jun 2002 10:04:22 -0500 > From: Dean Roehrich > To: Adrian Head > Cc: linux-xfs@oss.sgi.com > Subject: Re: Problems with 2.4.19-pre9 & XFS/DMAPI kernel config logic > problem > > > >From: Adrian Head > >What I did come across though is that the kernel config logic for XFS & DMAPI > >doesn't really do what it should (AFAICT) from the TAKE message from a while > >ago. This problem I discussed with Eric & Chris Pascoe on #xfs but I'm not > >sure what the outcome was. > > > >What happens is that make oldconfig doesn't pick up on the fact that DMAPI > >should not be compiled as a module when XFS is compiled into the kernel. > >Everything compiles correctly - however when a depmod is run it fails because > >of missing symbols in the dmapi module. > > When xfs_support was merged back into the xfs directory, the dmapi module > build was broken. You're missing symbols for things like sv_wait and kmem_* > stuff. > > I'm working on it from time-to-time. > > At the very least, this pointed out a few more dependencies between XFS and > DMAPI that I can work on. Someday DMAPI won't need XFS... > > Dean > From owner-linux-xfs@oss.sgi.com Mon Jun 3 09:35:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53GZYnC001577 for ; Mon, 3 Jun 2002 09:35:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53GZYdq001576 for linux-xfs-outgoing; Mon, 3 Jun 2002 09:35:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from scrye.com (IDENT:81C2sadqAWah5K91oLdYdeJhnenUVV+M@brand.scrye.com [216.17.180.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53GZRnC001544 for ; Mon, 3 Jun 2002 09:35:27 -0700 Received: (qmail 21253 invoked by uid 10); 3 Jun 2002 16:37:14 -0000 Received: (qmail 28817 invoked by uid 500); 3 Jun 2002 16:35:32 -0000 Message-ID: <20020603163532.28816.qmail@scrye.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 3 Jun 2002 10:35:29 -0600 From: Kevin Fenzi To: linux-xfs@oss.sgi.com Subject: interest in XFS in KRUD (Redhat Based distro) X-Mailer: VM 7.03 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-Spam-Status: No, hits=-2.1 required=5.0 tests=PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, We are considering merging in the XFS support in our distribution, KRUD (http://www.tummy.com/krud/). KRUD is based on RedHat with all the errata packages and a number of extras merged into the distribution. New releases come out monthy with the last months errata already merged in (great for new installs and people with limited BW for downloading upgrades). Anyhow, we would like to know how much interest there is out there in us adding XFS. We have had several requests... If you would be intersted in us adding XFS, please mail sales@tummy.com with "KRUDxfs" in the subject, or reply to me... I am not on the list, so if you want to ask me anything, mail me direct... thanks, kevin -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard iD8DBQE8+5rU3imCezTjY0ERAtl6AJ9a+s7p3m/T+NF5/uTgc8rB4jzhiwCaA1M/ nwlSCSBf6XIjY2XwoYxksRs= =itjm -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jun 3 09:52:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53GqenC002135 for ; Mon, 3 Jun 2002 09:52:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53GqegV002134 for linux-xfs-outgoing; Mon, 3 Jun 2002 09:52:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhost.idcomm.com (mailhost.idcomm.com [207.40.196.14]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53GqVnC002102 for ; Mon, 3 Jun 2002 09:52:31 -0700 Received: from idcomm.com (IDENT:Rr8AvdgxrzqO1FaxUtjf/rn/6coIi+iD@tnt01-ppp-148.idcomm.com [216.98.194.148]) by mailhost.idcomm.com (8.10.2/8.10.0) with ESMTP id g53Gtvt23029 for ; Mon, 3 Jun 2002 10:55:57 -0600 Message-ID: <3CFB9FAA.537C8054@idcomm.com> Date: Mon, 03 Jun 2002 10:56:10 -0600 From: "D. Stimits" Reply-To: stimits@idcomm.com X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.6-pre1-xfs-4 i686) X-Accept-Language: en MIME-Version: 1.0 To: "XFS: linux-xfs@oss.sgi.com" Subject: Re: interest in XFS in KRUD (Redhat Based distro) References: <20020603163532.28816.qmail@scrye.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kevin Fenzi wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Greetings, > > We are considering merging in the XFS support in our distribution, > KRUD (http://www.tummy.com/krud/). KRUD is based on RedHat with all > the errata packages and a number of extras merged into the > distribution. New releases come out monthy with the last months errata > already merged in (great for new installs and people with limited BW > for downloading upgrades). > > Anyhow, we would like to know how much interest there is out there in > us adding XFS. We have had several requests... > > If you would be intersted in us adding XFS, please mail > sales@tummy.com with "KRUDxfs" in the subject, or reply to me... I am > not on the list, so if you want to ask me anything, mail me direct... I am on the XFS list, and have been for a long time. I really recommend KRUD, and in fact have asked Kevin for a long time to add XFS support to it. KRUD itself is updated often, available in subscription format at a low price relative to Redhat, or in single CD's at a price comparable to that of CheapBytes. But bugs and errata, and things that make it just work right from the start, are applied (which is what the monthly update subscription does, it keeps up on security and other issues). KRUD and tummy.com are not a fly-by-night setup, the distro is actively used in their consulting business. Having officially and actively updated KRUD (redhat) could make a big difference. D. Stimits, stimits@idcomm.com > > thanks, > > kevin > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: Processed by Mailcrypt 3.5.6 and Gnu Privacy Guard > > iD8DBQE8+5rU3imCezTjY0ERAtl6AJ9a+s7p3m/T+NF5/uTgc8rB4jzhiwCaA1M/ > nwlSCSBf6XIjY2XwoYxksRs= > =itjm > -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jun 3 09:52:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53GqunC002224 for ; Mon, 3 Jun 2002 09:52:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53GqthV002223 for linux-xfs-outgoing; Mon, 3 Jun 2002 09:52:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53GqpnC002159 for ; Mon, 3 Jun 2002 09:52:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA59359 for ; Mon, 3 Jun 2002 11:54:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA38753 for ; Mon, 3 Jun 2002 11:54:35 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g53GoeX08384; Mon, 3 Jun 2002 11:50:40 -0500 Message-Id: <200206031650.g53GoeX08384@jen.americas.sgi.com> Date: Mon, 3 Jun 2002 11:50:40 -0500 Subject: TAKE - fix 2.5 acl test regression To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 3 09:53:59 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:120663a linux/fs/xfs/linux/xfs_xattr.c - 1.13 - fix up 2.5 acl interface - too much code was removed in the last merge From owner-linux-xfs@oss.sgi.com Mon Jun 3 10:02:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53H2TnC002607 for ; Mon, 3 Jun 2002 10:02:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53H2TJO002606 for linux-xfs-outgoing; Mon, 3 Jun 2002 10:02:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53H2NnC002578 for ; Mon, 3 Jun 2002 10:02:24 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g53H3xqX076195; Mon, 3 Jun 2002 19:04:04 +0200 (CEST) Message-Id: <4.3.2.7.2.20020603190340.0392c270@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Jun 2002 19:05:01 +0200 To: Roy Sigurd Karlsbakk , Raymond From: Seth Mos Subject: Re: RAID Controller Caching and XFS Cc: linux-xfs In-Reply-To: <200206031012.g53ACgj31318@mail.pronto.tv> References: <4.3.2.7.2.20020603111702.03831978@pop.xs4all.nl> <4.3.2.7.2.20020603111702.03831978@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:12 3-6-2002 +0200, Roy Sigurd Karlsbakk wrote: > > >I'd check for how long the battery will last. Contact the vendor and try > > >to get the guarantied values. Also - how long the battery will last under > > >normal and extraordinary conditions. > > > > 72 hours at most. > >Interesting.... > >Compaq once told me their battery backup on the SMART raid controllers could >stand sevaral weeks We are talking about the megaraid here. The compaq might use a different battery pack. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Jun 3 10:48:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53Hm1nC003363 for ; Mon, 3 Jun 2002 10:48:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53Hm1x4003362 for linux-xfs-outgoing; Mon, 3 Jun 2002 10:48:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53HkmnC003325 for ; Mon, 3 Jun 2002 10:46:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA60267 for ; Mon, 3 Jun 2002 12:48:33 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA41655 for ; Mon, 3 Jun 2002 12:48:33 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g53Hib608479; Mon, 3 Jun 2002 12:44:37 -0500 Message-Id: <200206031744.g53Hib608479@jen.americas.sgi.com> Date: Mon, 3 Jun 2002 12:44:37 -0500 Subject: TAKE - merge up to 2.5.20 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 3 10:05:58 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:120664a linux/drivers/char/hvc_console.c - 1.1 linux/drivers/usb/host/usb-ohci-sa1111.c - 1.1 linux/drivers/acpi/pci_bind.c - 1.1 linux/drivers/usb/host/usb-ohci-pci.c - 1.1 linux/Documentation/networking/e100.txt - 1.1 linux/arch/ppc64/lib/copyuser.S - 1.1 linux/drivers/usb/core/urb.c - 1.1 linux/drivers/usb/core/message.c - 1.1 linux/drivers/acpi/ac.c - 1.1 linux/drivers/usb/core/config.c - 1.1 linux/drivers/acpi/battery.c - 1.1 linux/drivers/acpi/bus.c - 1.1 linux/drivers/acpi/pci_root.c - 1.1 linux/drivers/acpi/fan.c - 1.1 linux/drivers/acpi/pci_link.c - 1.1 linux/drivers/acpi/button.c - 1.1 linux/drivers/acpi/pci_irq.c - 1.1 linux/arch/ppc64/lib/memcpy.S - 1.1 linux/drivers/acpi/thermal.c - 1.1 linux/include/linux/swapops.h - 1.1 linux/drivers/acpi/system.c - 1.1 linux/arch/ppc64/lib/copypage.S - 1.1 linux/drivers/acpi/processor.c - 1.1 linux/drivers/ide/device.c - 1.1 linux/drivers/acpi/osl.c - 1.1 linux/drivers/acpi/utils.c - 1.1 linux/scripts/split-include.c - 1.4 linux/scripts/mkdep.c - 1.14 linux/mm/vmscan.c - 1.102 linux/mm/swapfile.c - 1.58 linux/mm/swap_state.c - 1.40 linux/mm/mmap.c - 1.51 linux/mm/memory.c - 1.83 linux/mm/filemap.c - 1.121 linux/kernel/time.c - 1.11 linux/kernel/softirq.c - 1.20 linux/kernel/ksyms.c - 1.147 linux/init/main.c - 1.82 linux/include/linux/types.h - 1.7 linux/include/linux/swap.h - 1.58 linux/include/linux/sched.h - 1.70 linux/include/linux/pipe_fs_i.h - 1.8 linux/include/linux/nfs_fs.h - 1.23 linux/include/linux/nbd.h - 1.14 linux/include/linux/module.h - 1.34 linux/include/linux/list.h - 1.12 linux/include/linux/hdreg.h - 1.23 linux/include/linux/fs.h - 1.172 linux/include/linux/blkdev.h - 1.58 linux/include/linux/blk.h - 1.35 linux/include/linux/adfs_fs.h - 1.7 linux/include/asm-sparc64/siginfo.h - 1.10 linux/include/asm-sparc64/pgtable.h - 1.36 linux/include/asm-sparc/siginfo.h - 1.12 linux/include/asm-sparc/pgtable.h - 1.26 linux/include/asm-ppc/pgtable.h - 1.36 linux/include/asm-mips/siginfo.h - 1.9 linux/include/asm-mips/pgtable.h - 1.18 linux/include/asm-m68k/siginfo.h - 1.9 linux/include/asm-m68k/pgtable.h - 1.15 linux/include/asm-i386/pgtable.h - 1.35 linux/include/asm-i386/page.h - 1.27 linux/include/asm-arm/proc-armv/uncompress.h - 1.5 linux/include/asm-arm/proc-armv/processor.h - 1.10 linux/include/asm-arm/proc-armo/uncompress.h - 1.4 linux/include/asm-arm/proc-armo/processor.h - 1.10 linux/include/asm-arm/pgtable.h - 1.27 linux/include/asm-arm/atomic.h - 1.10 linux/include/asm-alpha/siginfo.h - 1.8 linux/include/asm-alpha/pgtable.h - 1.34 linux/fs/umsdos/namei.c - 1.14 linux/fs/ufs/truncate.c - 1.19 linux/fs/ufs/namei.c - 1.17 linux/fs/ufs/dir.c - 1.18 linux/fs/sysv/namei.c - 1.19 linux/fs/sysv/dir.c - 1.16 linux/fs/pipe.c - 1.30 linux/fs/nfs/inode.c - 1.44 linux/fs/namei.c - 1.56 linux/fs/minix/namei.c - 1.21 linux/fs/minix/dir.c - 1.13 linux/fs/inode.c - 1.75 linux/fs/ext2/namei.c - 1.26 linux/fs/buffer.c - 1.123 linux/fs/binfmt_script.c - 1.15 linux/fs/binfmt_em86.c - 1.16 linux/fs/binfmt_elf.c - 1.42 linux/fs/adfs/super.c - 1.23 linux/fs/adfs/map.c - 1.10 linux/fs/adfs/inode.c - 1.26 linux/fs/adfs/file.c - 1.14 linux/fs/adfs/dir.c - 1.19 linux/drivers/usb/Makefile - 1.54 linux/drivers/usb/Config.in - 1.59 linux/drivers/scsi/scsi_debug.c - 1.20 linux/drivers/scsi/ide-scsi.c - 1.36 linux/drivers/sbus/char/openprom.c - 1.13 linux/drivers/net/pcnet32.c - 1.35 linux/drivers/net/eepro100.c - 1.45 linux/drivers/net/3c501.c - 1.18 linux/drivers/isdn/hisax/teles3.c - 1.13 linux/drivers/isdn/hisax/niccy.c - 1.15 linux/drivers/isdn/hisax/elsa.c - 1.18 linux/drivers/isdn/hisax/avm_a1.c - 1.11 linux/drivers/char/tty_io.c - 1.45 linux/drivers/char/rtc.c - 1.29 linux/drivers/char/pc_keyb.c - 1.29 linux/drivers/char/istallion.c - 1.21 linux/drivers/char/isicom.c - 1.18 linux/drivers/char/h8.c - 1.14 linux/drivers/char/esp.c - 1.18 linux/drivers/char/epca.c - 1.22 linux/drivers/char/dtlk.c - 1.18 linux/drivers/char/Makefile - 1.60 linux/drivers/char/Config.in - 1.59 linux/drivers/cdrom/sonycd535.c - 1.21 linux/drivers/cdrom/sbpcd4.c - 1.3 linux/drivers/cdrom/sbpcd3.c - 1.3 linux/drivers/cdrom/sbpcd2.c - 1.3 linux/drivers/cdrom/sbpcd.h - 1.4 linux/drivers/cdrom/sbpcd.c - 1.23 linux/drivers/cdrom/gscd.h - 1.4 linux/drivers/cdrom/gscd.c - 1.18 linux/drivers/cdrom/aztcd.c - 1.20 linux/drivers/cdrom/Makefile - 1.6 linux/drivers/cdrom/Config.in - 1.5 linux/drivers/block/xd.c - 1.37 linux/drivers/block/ps2esdi.c - 1.39 linux/drivers/block/nbd.c - 1.39 linux/drivers/block/ll_rw_blk.c - 1.103 linux/drivers/block/floppy.c - 1.40 linux/drivers/block/acsi.c - 1.30 linux/drivers/acorn/block/mfmhd.c - 1.24 linux/arch/sparc64/kernel/sys_sparc.c - 1.25 linux/arch/sparc/kernel/sys_sunos.c - 1.37 linux/arch/ppc/kernel/syscalls.c - 1.12 linux/arch/m68k/atari/stram.c - 1.15 linux/arch/i386/kernel/setup.c - 1.77 linux/arch/i386/kernel/io_apic.c - 1.37 linux/arch/i386/kernel/apm.c - 1.44 linux/arch/arm/mm/init.c - 1.30 linux/arch/arm/kernel/setup.c - 1.31 linux/arch/arm/kernel/process.c - 1.28 linux/arch/arm/kernel/entry-armv.S - 1.31 linux/arch/arm/config.in - 1.41 linux/arch/arm/boot/compressed/misc.c - 1.6 linux/Rules.make - 1.23 linux/README - 1.13 linux/Makefile - 1.200 linux/MAINTAINERS - 1.107 linux/Documentation/Changes - 1.51 linux/include/linux/ide.h - 1.50 linux/fs/hpfs/super.c - 1.18 linux/drivers/block/cpqarray.c - 1.47 linux/drivers/char/raw.c - 1.25 linux/drivers/isdn/hisax/gazel.c - 1.13 linux/include/asm-sh/pgtable.h - 1.25 linux/include/linux/udf_fs.h - 1.15 linux/include/linux/acpi.h - 1.25 linux/arch/i386/lib/mmx.c - 1.9 linux/arch/i386/kernel/smpboot.c - 1.39 linux/arch/arm/def-configs/victor - 1.4 linux/arch/arm/def-configs/empeg - 1.2 linux/arch/arm/def-configs/brutus - 1.11 linux/include/linux/highmem.h - 1.22 linux/include/linux/agp_backend.h - 1.18 linux/kernel/timer.c - 1.22 linux/drivers/char/agp/agpgart_be.c - 1.38 linux/drivers/char/agp/agp.h - 1.24 linux/arch/i386/kernel/acpi.c - 1.27 linux/drivers/net/pcmcia/com20020_cs.c - 1.8 linux/drivers/ieee1394/pcilynx.c - 1.20 linux/arch/i386/kernel/mpparse.c - 1.20 linux/include/asm-i386/mpspec.h - 1.9 linux/include/asm-i386/io_apic.h - 1.7 linux/drivers/scsi/scsi_scan.c - 1.24 linux/drivers/char/mixcomwd.c - 1.12 linux/drivers/char/efirtc.c - 1.9 linux/fs/adfs/adfs.h - 1.8 linux/drivers/scsi/qla1280.c - 1.16 linux/include/asm-ia64/siginfo.h - 1.14 linux/include/linux/raid/md_k.h - 1.21 linux/include/asm-ia64/pgtable.h - 1.18 linux/include/asm-mips64/siginfo.h - 1.7 linux/include/asm-mips64/pgtable.h - 1.13 linux/include/linux/usb.h - 1.39 linux/drivers/ide/via82cxxx.c - 1.29 linux/drivers/ide/trm290.c - 1.9 linux/drivers/ide/sl82c105.c - 1.12 linux/drivers/ide/sis5513.c - 1.20 linux/drivers/ide/piix.c - 1.24 linux/drivers/ide/pdc4030.c - 1.17 linux/drivers/ide/pdc202xx.c - 1.22 linux/drivers/ide/ns87415.c - 1.9 linux/drivers/ide/ide.c - 1.54 linux/drivers/ide/ide-tape.c - 1.28 linux/drivers/ide/ide-pmac.c - 1.14 linux/drivers/ide/ide-pci.c - 1.28 linux/drivers/ide/ide-floppy.c - 1.25 linux/drivers/ide/ide-disk.c - 1.36 linux/drivers/ide/ide-cd.c - 1.36 linux/drivers/ide/icside.c - 1.16 linux/drivers/ide/ht6560b.c - 1.10 linux/drivers/ide/hpt366.c - 1.19 linux/drivers/ide/hpt34x.c - 1.12 linux/drivers/ide/hd.c - 1.22 linux/drivers/ide/cy82c693.c - 1.12 linux/drivers/ide/cs5530.c - 1.11 linux/drivers/ide/cmd64x.c - 1.15 linux/drivers/ide/alim15x3.c - 1.17 linux/drivers/ide/Makefile - 1.24 linux/Documentation/DocBook/Makefile - 1.31 linux/Documentation/DocBook/kernel-api.tmpl - 1.17 linux/fs/ramfs/inode.c - 1.23 linux/drivers/ide/aec62xx.c - 1.10 linux/drivers/char/rio/rioctrl.c - 1.8 linux/drivers/s390/misc/chandev.c - 1.9 linux/include/asm-s390/pgtable.h - 1.13 linux/arch/arm/def-configs/assabet - 1.9 linux/arch/arm/def-configs/graphicsclient - 1.8 linux/arch/arm/def-configs/lusl7200 - 1.5 linux/arch/s390/kernel/ptrace.c - 1.7 linux/arch/s390/kernel/signal.c - 1.11 linux/fs/xfs/linux/xfs_iops.c - 1.148 linux/Documentation/filesystems/Locking - 1.15 linux/drivers/usb/storage/transport.c - 1.22 linux/drivers/usb/storage/scsiglue.c - 1.21 linux/drivers/acpi/tables/tbxface.c - 1.10 linux/drivers/acpi/tables/tbutils.c - 1.10 linux/drivers/acpi/tables/tbinstal.c - 1.10 linux/drivers/acpi/tables/tbget.c - 1.10 linux/drivers/acpi/tables.c - 1.3 linux/drivers/acpi/resources/rsxface.c - 1.9 linux/drivers/acpi/resources/rsutils.c - 1.9 linux/drivers/acpi/resources/rsmisc.c - 1.8 linux/drivers/acpi/resources/rsmemory.c - 1.8 linux/drivers/acpi/resources/rslist.c - 1.9 linux/drivers/acpi/resources/rsirq.c - 1.8 linux/drivers/acpi/resources/rsio.c - 1.8 linux/drivers/acpi/resources/rsdump.c - 1.9 linux/drivers/acpi/resources/rscreate.c - 1.9 linux/drivers/acpi/resources/rscalc.c - 1.9 linux/drivers/acpi/resources/rsaddr.c - 1.8 linux/drivers/acpi/parser/psxface.c - 1.10 linux/drivers/acpi/parser/pswalk.c - 1.9 linux/drivers/acpi/parser/psutils.c - 1.10 linux/drivers/acpi/parser/pstree.c - 1.9 linux/drivers/acpi/parser/psparse.c - 1.11 linux/drivers/acpi/parser/psopcode.c - 1.10 linux/drivers/acpi/parser/psargs.c - 1.10 linux/drivers/acpi/namespace/nsxfobj.c - 1.12 linux/drivers/acpi/namespace/nsxfname.c - 1.10 linux/drivers/acpi/namespace/nswalk.c - 1.8 linux/drivers/acpi/namespace/nsutils.c - 1.10 linux/drivers/acpi/namespace/nssearch.c - 1.11 linux/drivers/acpi/namespace/nsobject.c - 1.10 linux/drivers/acpi/namespace/nsnames.c - 1.10 linux/drivers/acpi/namespace/nsload.c - 1.9 linux/drivers/acpi/namespace/nseval.c - 1.11 linux/drivers/acpi/namespace/nsalloc.c - 1.10 linux/drivers/acpi/namespace/nsaccess.c - 1.11 linux/drivers/acpi/include/amlcode.h - 1.10 linux/drivers/acpi/include/actypes.h - 1.12 linux/drivers/acpi/include/actables.h - 1.10 linux/drivers/acpi/include/acpixf.h - 1.11 linux/drivers/acpi/include/acobject.h - 1.10 linux/drivers/acpi/include/acexcep.h - 1.9 linux/drivers/acpi/hardware/hwregs.c - 1.11 linux/drivers/acpi/hardware/hwgpe.c - 1.10 linux/drivers/acpi/hardware/hwacpi.c - 1.10 linux/drivers/acpi/events/evxfregn.c - 1.10 linux/drivers/acpi/events/evxfevnt.c - 1.9 linux/drivers/acpi/events/evxface.c - 1.10 linux/drivers/acpi/events/evsci.c - 1.9 linux/drivers/acpi/events/evrgnini.c - 1.9 linux/drivers/acpi/events/evregion.c - 1.11 linux/drivers/acpi/events/evmisc.c - 1.10 linux/drivers/acpi/events/evevent.c - 1.12 linux/drivers/acpi/ec.c - 1.8 linux/drivers/acpi/dispatcher/dswstate.c - 1.10 linux/drivers/acpi/dispatcher/dswload.c - 1.10 linux/drivers/acpi/dispatcher/dswexec.c - 1.10 linux/drivers/acpi/dispatcher/dsutils.c - 1.10 linux/drivers/acpi/dispatcher/dsopcode.c - 1.11 linux/drivers/acpi/dispatcher/dsobject.c - 1.11 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.9 linux/drivers/acpi/dispatcher/dsmethod.c - 1.10 linux/drivers/acpi/dispatcher/dsfield.c - 1.8 linux/drivers/acpi/Makefile - 1.14 linux/kernel/user.c - 1.4 linux/include/asm-arm/mach/arch.h - 1.7 linux/drivers/usb/storage/freecom.c - 1.12 linux/arch/arm/mach-sa1100/Makefile - 1.11 linux/drivers/acpi/include/acconfig.h - 1.11 linux/drivers/acpi/include/acdebug.h - 1.10 linux/drivers/acpi/include/acdispat.h - 1.9 linux/drivers/acpi/include/acevents.h - 1.10 linux/drivers/acpi/include/acglobal.h - 1.9 linux/drivers/acpi/include/achware.h - 1.8 linux/drivers/acpi/include/acinterp.h - 1.10 linux/drivers/acpi/include/aclocal.h - 1.11 linux/drivers/acpi/include/acmacros.h - 1.9 linux/drivers/acpi/include/acnamesp.h - 1.10 linux/drivers/acpi/include/acparser.h - 1.7 linux/drivers/acpi/include/acresrc.h - 1.6 linux/drivers/acpi/namespace/nsdump.c - 1.7 linux/include/linux/ethtool.h - 1.11 linux/arch/arm/def-configs/neponset - 1.7 linux/arch/arm/def-configs/pangolin - 1.6 linux/arch/arm/def-configs/sherman - 1.4 linux/include/asm-parisc/pgtable.h - 1.5 linux/include/asm-parisc/siginfo.h - 1.4 linux/drivers/acpi/tables/tbconvrt.c - 1.8 linux/drivers/acpi/tables/tbxfroot.c - 1.8 linux/drivers/acpi/namespace/nsinit.c - 1.10 linux/mm/shmem.c - 1.37 linux/drivers/acpi/power.c - 1.4 linux/drivers/acpi/acpi_ksyms.c - 1.7 linux/drivers/acpi/hardware/hwsleep.c - 1.8 linux/drivers/acpi/hardware/hwtimer.c - 1.8 linux/include/asm-s390x/pgtable.h - 1.9 linux/arch/s390x/kernel/signal.c - 1.8 linux/arch/s390x/kernel/ptrace.c - 1.6 linux/arch/cris/drivers/ide.c - 1.14 linux/arch/s390x/kernel/debug.c - 1.6 linux/drivers/s390/block/xpram.c - 1.17 linux/include/asm-cris/siginfo.h - 1.4 linux/arch/s390/kernel/debug.c - 1.6 linux/include/asm-cris/pgtable.h - 1.9 linux/arch/arm/mach-integrator/arch.c - 1.4 linux/drivers/net/wan/dscc4.c - 1.12 linux/arch/s390/math-emu/math.c - 1.3 linux/drivers/mtd/nftlcore.c - 1.17 linux/drivers/acpi/executer/exstore.c - 1.6 linux/drivers/acpi/utilities/utxface.c - 1.5 linux/drivers/acpi/utilities/utobject.c - 1.5 linux/drivers/acpi/utilities/utmisc.c - 1.5 linux/drivers/acpi/utilities/utinit.c - 1.5 linux/drivers/acpi/utilities/utglobal.c - 1.6 linux/drivers/acpi/utilities/uteval.c - 1.6 linux/drivers/acpi/utilities/utdelete.c - 1.6 linux/drivers/acpi/utilities/utdebug.c - 1.6 linux/drivers/acpi/utilities/utcopy.c - 1.6 linux/drivers/acpi/utilities/utalloc.c - 1.5 linux/drivers/acpi/Config.in - 1.3 linux/drivers/acpi/include/acstruct.h - 1.6 linux/drivers/acpi/include/acutils.h - 1.5 linux/drivers/net/wireless/airo.c - 1.15 linux/drivers/acpi/include/platform/acenv.h - 1.6 linux/drivers/acpi/include/platform/acgcc.h - 1.8 linux/drivers/acpi/include/platform/aclinux.h - 1.5 linux/drivers/acpi/debugger/dbcmds.c - 1.5 linux/drivers/acpi/debugger/dbdisasm.c - 1.5 linux/drivers/acpi/debugger/dbdisply.c - 1.6 linux/drivers/acpi/debugger/dbexec.c - 1.4 linux/drivers/acpi/debugger/dbfileio.c - 1.6 linux/drivers/acpi/debugger/dbhistry.c - 1.4 linux/drivers/acpi/debugger/dbinput.c - 1.5 linux/drivers/acpi/debugger/dbstats.c - 1.5 linux/drivers/acpi/debugger/dbutils.c - 1.6 linux/drivers/acpi/debugger/dbxface.c - 1.5 linux/drivers/acpi/executer/exutils.c - 1.5 linux/drivers/acpi/executer/exsystem.c - 1.4 linux/drivers/acpi/executer/exstorob.c - 1.5 linux/drivers/acpi/executer/exstoren.c - 1.5 linux/drivers/acpi/executer/exconfig.c - 1.6 linux/drivers/acpi/executer/exconvrt.c - 1.6 linux/drivers/acpi/executer/excreate.c - 1.5 linux/drivers/acpi/executer/exdump.c - 1.6 linux/drivers/acpi/executer/exfield.c - 1.5 linux/drivers/acpi/executer/exfldio.c - 1.6 linux/drivers/acpi/executer/exmisc.c - 1.5 linux/drivers/acpi/executer/exmutex.c - 1.4 linux/drivers/acpi/executer/exnames.c - 1.4 linux/drivers/acpi/executer/exprep.c - 1.6 linux/drivers/acpi/executer/exregion.c - 1.6 linux/drivers/acpi/executer/exresnte.c - 1.7 linux/drivers/acpi/executer/exresolv.c - 1.6 linux/drivers/acpi/executer/exresop.c - 1.6 linux/drivers/char/w83877f_wdt.c - 1.7 linux/drivers/net/dl2k.h - 1.8 linux/drivers/net/dl2k.c - 1.13 linux/drivers/char/drm/drm_agpsupport.h - 1.7 linux/drivers/ide/serverworks.c - 1.11 linux/drivers/ide/amd74xx.c - 1.12 linux/arch/arm/def-configs/anakin - 1.3 linux/arch/arm/def-configs/flexanet - 1.5 linux/arch/arm/def-configs/freebird - 1.4 linux/arch/arm/def-configs/freebird_new - 1.4 linux/arch/arm/def-configs/huw_webpanel - 1.3 linux/arch/arm/def-configs/jornada720 - 1.5 linux/arch/arm/mach-sa1100/xp860.c - 1.6 linux/arch/arm/def-configs/omnimeter - 1.4 linux/arch/arm/mach-sa1100/victor.c - 1.5 linux/arch/arm/def-configs/pfs168_mqtft - 1.4 linux/arch/arm/def-configs/pfs168_mqvga - 1.4 linux/arch/arm/def-configs/pfs168_sastn - 1.4 linux/arch/arm/def-configs/pfs168_satft - 1.4 linux/arch/arm/def-configs/pleb - 1.3 linux/arch/arm/mach-sa1100/simpad.c - 1.8 linux/arch/arm/mach-sa1100/sherman.c - 1.5 linux/arch/arm/mach-sa1100/pleb.c - 1.5 linux/arch/arm/mach-sa1100/pfs168.c - 1.8 linux/arch/arm/mach-sa1100/pangolin.c - 1.7 linux/arch/arm/mach-sa1100/omnimeter.c - 1.6 linux/arch/arm/mach-sa1100/nanoengine.c - 1.5 linux/arch/arm/mach-anakin/arch.c - 1.4 linux/arch/arm/mach-sa1100/jornada720.c - 1.7 linux/arch/arm/mach-integrator/cpu.c - 1.3 linux/arch/arm/mach-sa1100/itsy.c - 1.4 linux/arch/arm/mach-sa1100/huw_webpanel.c - 1.6 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.9 linux/arch/arm/mach-sa1100/assabet.c - 1.8 linux/arch/arm/mach-sa1100/brutus.c - 1.4 linux/arch/arm/mach-sa1100/cerf.c - 1.8 linux/arch/arm/mach-sa1100/generic.c - 1.5 linux/arch/arm/mach-sa1100/freebird.c - 1.7 linux/arch/arm/mach-sa1100/empeg.c - 1.5 linux/arch/arm/mach-sa1100/flexanet.c - 1.6 linux/drivers/ide/qd65xx.c - 1.9 linux/drivers/char/ite_gpio.c - 1.3 linux/include/asm-arm/tlb.h - 1.2 linux/drivers/char/ib700wdt.c - 1.4 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.9 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.7 linux/drivers/acpi/utilities/utmath.c - 1.3 linux/arch/arm/def-configs/adsbitsy - 1.4 linux/arch/arm/def-configs/cerfcube - 1.4 linux/arch/arm/def-configs/cerfpda - 1.4 linux/arch/arm/def-configs/cerfpod - 1.4 linux/arch/arm/def-configs/epxa10db - 1.4 linux/arch/arm/def-configs/graphicsmaster - 1.4 linux/arch/arm/mach-epxa10db/arch.c - 1.4 linux/drivers/acpi/executer/exoparg3.c - 1.3 linux/drivers/acpi/executer/exoparg2.c - 1.4 linux/drivers/acpi/executer/exoparg1.c - 1.4 linux/fs/jbd/journal.c - 1.12 linux/fs/ext3/inode.c - 1.13 linux/fs/ext3/namei.c - 1.8 linux/include/linux/jbd.h - 1.7 linux/include/linux/ext3_jbd.h - 1.4 linux/include/linux/ext3_fs.h - 1.6 linux/fs/jbd/transaction.c - 1.9 linux/fs/driverfs/inode.c - 1.13 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.6 linux/include/linux/device.h - 1.9 linux/init/do_mounts.c - 1.13 linux/arch/arm/mach-iop310/arch.c - 1.4 linux/arch/arm/def-configs/adi_evb - 1.3 linux/arch/arm/def-configs/iq80310 - 1.8 linux/arch/arm/mach-sa1100/system3.c - 1.7 linux/arch/arm/mach-adifcc/arch.c - 1.4 linux/arch/arm/mach-clps711x/cdb89712.c - 1.4 linux/arch/arm/mach-l7200/core.c - 1.4 linux/arch/arm/mach-rpc/riscpc.c - 1.3 linux/fs/xfs/pagebuf/page_buf_io.c - 1.34 linux/drivers/ide/ide-taskfile.c - 1.13 linux/drivers/acpi/Config.help - 1.3 linux/drivers/cdrom/Config.help - 1.2 linux/drivers/char/Config.help - 1.5 linux/drivers/net/Config.help - 1.5 linux/drivers/base/interface.c - 1.6 linux/drivers/base/core.c - 1.10 linux/drivers/pci/pci-driver.c - 1.5 linux/sound/isa/sb/sb16_csp.c - 1.3 linux/include/asm-x86_64/pgtable.h - 1.5 linux/include/asm-ppc64/hardirq.h - 1.2 linux/arch/ppc64/mm/fault.c - 1.3 linux/arch/ppc64/mm/init.c - 1.5 linux/include/asm-ppc64/fcntl.h - 1.2 linux/arch/ppc64/Makefile - 1.3 linux/arch/ppc64/boot/main.c - 1.2 linux/arch/ppc64/config.in - 1.6 linux/arch/ppc64/defconfig - 1.4 linux/arch/ppc64/kernel/Makefile - 1.5 linux/arch/ppc64/kernel/entry.S - 1.5 linux/arch/ppc64/kernel/idle.c - 1.4 linux/arch/ppc64/kernel/ioctl32.c - 1.5 linux/arch/ppc64/kernel/irq.c - 1.3 linux/arch/ppc64/kernel/misc.S - 1.3 linux/arch/ppc64/kernel/mk_defs.c - 1.4 linux/arch/ppc64/kernel/pci.c - 1.4 linux/arch/ppc64/kernel/ppc-stub.c - 1.2 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.4 linux/arch/ppc64/kernel/process.c - 1.4 linux/arch/ppc64/kernel/prom.c - 1.4 linux/arch/ppc64/kernel/setup.c - 1.4 linux/arch/ppc64/kernel/signal.c - 1.5 linux/arch/ppc64/kernel/signal32.c - 1.5 linux/arch/ppc64/kernel/smp.c - 1.6 linux/arch/ppc64/kernel/stab.c - 1.4 linux/arch/ppc64/kernel/sys_ppc32.c - 1.4 linux/arch/ppc64/kernel/traps.c - 1.3 linux/arch/ppc64/lib/Makefile - 1.3 linux/arch/ppc64/lib/string.S - 1.4 linux/arch/ppc64/xmon/xmon.c - 1.4 linux/include/asm-ppc64/memory.h - 1.3 linux/include/asm-ppc64/mmu.h - 1.4 linux/include/asm-ppc64/unistd.h - 1.3 linux/include/asm-ppc64/thread_info.h - 1.3 linux/include/asm-ppc64/uaccess.h - 1.3 linux/include/asm-ppc64/timex.h - 1.2 linux/include/asm-ppc64/system.h - 1.4 linux/include/asm-ppc64/processor.h - 1.4 linux/include/asm-ppc64/pgtable.h - 1.4 linux/include/asm-ppc64/page.h - 1.4 linux/drivers/net/e1000/e1000_main.c - 1.7 linux/Documentation/networking/e1000.txt - 1.2 linux/drivers/net/e1000/Makefile - 1.4 linux/drivers/net/e1000/e1000_osdep.h - 1.3 linux/drivers/net/e1000/e1000.h - 1.4 linux/drivers/net/e1000/e1000_ethtool.c - 1.3 linux/include/asm-arm/thread_info.h - 1.4 linux/arch/arm/def-configs/badge4 - 1.5 linux/fs/jfs/inode.c - 1.5 linux/fs/jfs/jfs_dmap.c - 1.4 linux/fs/jfs/jfs_incore.h - 1.4 linux/fs/jfs/namei.c - 1.4 linux/fs/jfs/jfs_xtree.c - 1.4 linux/fs/jfs/jfs_logmgr.c - 1.6 linux/fs/jfs/super.c - 1.6 linux/fs/jfs/jfs_txnmgr.c - 1.4 linux/fs/jfs/jfs_metapage.c - 1.6 linux/drivers/net/tulip/de4x5.c - 1.2 linux/drivers/net/e100/e100_proc.c - 1.3 linux/drivers/net/e100/e100.h - 1.4 linux/drivers/net/e100/e100_config.c - 1.4 linux/drivers/net/e100/e100_main.c - 1.5 linux/include/asm-i386/acpi.h - 1.3 linux/drivers/acpi/acpi_ac.c - 1.3 linux/drivers/acpi/acpi_battery.c - 1.3 linux/drivers/media/video/video-buf.c - 1.2 linux/drivers/acpi/acpi_bus.c - 1.4 linux/drivers/acpi/acpi_bus.h - 1.3 linux/drivers/acpi/acpi_button.c - 1.3 linux/arch/i386/kernel/acpi_wakeup.S - 1.5 linux/drivers/acpi/acpi_pci_root.c - 1.3 linux/drivers/acpi/acpi_drivers.h - 1.3 linux/drivers/acpi/acpi_ec.c - 1.3 linux/drivers/acpi/acpi_fan.c - 1.2 linux/drivers/acpi/acpi_osl.c - 1.4 linux/drivers/acpi/acpi_processor.c - 1.3 linux/drivers/acpi/acpi_pci_link.c - 1.3 linux/drivers/acpi/acpi_system.c - 1.4 linux/drivers/acpi/acpi_tables.c - 1.3 linux/drivers/acpi/acpi_power.c - 1.2 linux/drivers/acpi/acpi_thermal.c - 1.3 linux/drivers/acpi/acpi_utils.c - 1.2 linux/drivers/net/e1000/e1000_hw.h - 1.2 linux/drivers/usb/core/Makefile - 1.4 linux/drivers/usb/core/usb.c - 1.7 linux/drivers/usb/host/Config.in - 1.5 linux/drivers/usb/host/Makefile - 1.5 linux/arch/arm/mach-pxa/idp.c - 1.3 linux/arch/arm/mach-pxa/lubbock.c - 1.3 linux/drivers/usb/host/ehci-q.c - 1.5 linux/drivers/base/power.c - 1.2 linux/drivers/base/base.h - 1.3 linux/drivers/usb/host/usb-ohci.c - 1.4 linux/drivers/usb/host/usb-ohci.h - 1.2 linux/drivers/net/e1000/e1000_hw.c - 1.2 linux/drivers/usb/image/scanner.c - 1.6 linux/drivers/usb/image/scanner.h - 1.4 linux/drivers/video/clps711xfb.c - 1.4 linux/drivers/net/e100/e100_test.c - 1.2 linux/arch/ppc64/kernel/pSeries_htab.c - 1.2 linux/fs/exportfs/expfs.c - 1.4 linux/drivers/ide/tcq.c - 1.3 linux/drivers/ide/pcihost.h - 1.3 linux/drivers/ide/pcidma.c - 1.3 linux/arch/i386/pci/acpi.c - 1.2 linux/arch/i386/pci/common.c - 1.2 linux/arch/i386/pci/irq.c - 1.2 linux/arch/i386/pci/legacy.c - 1.2 linux/drivers/pci/hotplug.c - 1.3 linux/fs/fs-writeback.c - 1.3 linux/arch/i386/pci/numa.c - 1.2 linux/arch/i386/pci/pci.h - 1.2 linux/mm/page-writeback.c - 1.3 linux/include/linux/buffer_head.h - 1.4 linux/include/asm-ppc64/paca.h - 1.2 linux/include/linux/writeback.h - 1.3 linux/kernel/suspend.c - 1.2 linux/drivers/ide/ioctl.c - 1.2 linux/drivers/ide/main.c - 1.2 linux/include/linux/atapi.h - 1.2 linux/drivers/ide/probe.c - 1.2 linux/drivers/base/bus.c - 1.2 linux/drivers/base/driver.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jun 3 11:20:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53IKinC004098 for ; Mon, 3 Jun 2002 11:20:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53IKi85004097 for linux-xfs-outgoing; Mon, 3 Jun 2002 11:20:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53IKdnC004067 for ; Mon, 3 Jun 2002 11:20:39 -0700 Received: from [64.32.179.242] (HELO awm-laptop) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 32984443 for linux-xfs@oss.sgi.com; Mon, 03 Jun 2002 11:14:13 -0700 Content-Type: text/plain; charset="us-ascii" From: "Anthony W. Marino" Organization: AWM Objects To: linux-xfs Subject: Which Kernel for XFS Date: Mon, 3 Jun 2002 14:26:28 -0400 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200206031426.28859.anthony@AWMObjects.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g53IKdnC004070 X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm building/setting-up a new server SuSE 7.3 which will include 3ware (7810) ide raid (10 or 5) with brand new drives and most likely LVM too. Should I get the kernel from oss.sgi.com cvs (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" linux-2.4-xfs) or is there another location/process that I should entertain? Also what kernel release does the oss.sgi.com cvs sources give me? Thank You, Anthony From owner-linux-xfs@oss.sgi.com Mon Jun 3 11:25:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53IPNnC004290 for ; Mon, 3 Jun 2002 11:25:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53IPNjI004289 for linux-xfs-outgoing; Mon, 3 Jun 2002 11:25:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53IPHnC004260 for ; Mon, 3 Jun 2002 11:25:17 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA60086; Mon, 3 Jun 2002 13:27:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA50481; Mon, 3 Jun 2002 13:27:00 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g53IN4L12204; Mon, 3 Jun 2002 13:23:04 -0500 Subject: Re: Which Kernel for XFS From: Steve Lord To: "Anthony W. Marino" Cc: linux-xfs In-Reply-To: <200206031426.28859.anthony@AWMObjects.com> References: <200206031426.28859.anthony@AWMObjects.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 03 Jun 2002 13:23:04 -0500 Message-Id: <1023128584.1422.11.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: > I'm building/setting-up a new server SuSE 7.3 which will include 3ware (7810) > ide raid (10 or 5) with brand new drives and most likely LVM too. Should I > get the kernel from oss.sgi.com cvs (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" > linux-2.4-xfs) or is there another location/process that I should entertain? > Also what kernel release does the oss.sgi.com cvs sources give me? > > Thank You, > Anthony > Right now it gives you 2.4.19-pre9 with xfs and kdb (which you probably do not care about). There are fixes in this tree which are not available anywhere else, it is the most direct link to XFS development. Of course this also possibly means there are bugs in this tree which are not available anywhere else. Steve From owner-linux-xfs@oss.sgi.com Mon Jun 3 12:07:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53J75nC004911 for ; Mon, 3 Jun 2002 12:07:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53J75pa004910 for linux-xfs-outgoing; Mon, 3 Jun 2002 12:07:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53J6wnC004880 for ; Mon, 3 Jun 2002 12:06:58 -0700 Received: from [64.32.179.242] (HELO awm-laptop) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 32997414; Mon, 03 Jun 2002 12:00:32 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects To: Steve Lord Subject: Re: Which Kernel for XFS Date: Mon, 3 Jun 2002 15:12:48 -0400 User-Agent: KMail/1.4.1 Cc: linux-xfs References: <200206031426.28859.anthony@AWMObjects.com> <1023128584.1422.11.camel@jen.americas.sgi.com> In-Reply-To: <1023128584.1422.11.camel@jen.americas.sgi.com> MIME-Version: 1.0 Message-Id: <200206031512.48300.anthony@AWMObjects.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g53J6wnC004882 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, What do you recommend that I use since the box I'm building is a development box for myself which I will be using for development purposes and thus will be using other cvs sources from other opesource projects as well? Anthony > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: > > I'm building/setting-up a new server SuSE 7.3 which will include 3ware > > (7810) ide raid (10 or 5) with brand new drives and most likely LVM too. > > Should I get the kernel from oss.sgi.com cvs > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" linux-2.4-xfs) or is there > > another location/process that I should entertain? Also what kernel > > release does the oss.sgi.com cvs sources give me? > > > > Thank You, > > Anthony > > Right now it gives you 2.4.19-pre9 with xfs and kdb (which you probably > do not care about). There are fixes in this tree which are not available > anywhere else, it is the most direct link to XFS development. Of course > this also possibly means there are bugs in this tree which are not > available anywhere else. > > Steve From owner-linux-xfs@oss.sgi.com Mon Jun 3 12:07:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53J7unC005015 for ; Mon, 3 Jun 2002 12:07:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53J7uka005014 for linux-xfs-outgoing; Mon, 3 Jun 2002 12:07:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53J7qnC004985 for ; Mon, 3 Jun 2002 12:07:52 -0700 Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.4/8.12.4) with ESMTP id g53J9aNG012036 for ; Mon, 3 Jun 2002 15:09:36 -0400 Message-ID: <3CFBBF50.E2037B7@oceana.com> Date: Mon, 03 Jun 2002 15:11:12 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Linux XFS Mailing List Subject: kernel-header-2.4.18-4SGI_XFS_1.1.i386.rpm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I didn't see this package on either the 1.1 Installer CD or on the ftp site. Did I miss it, or do I have to either build it myself or switch back to the non-RH kernel packages? Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Mon Jun 3 12:14:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53JEMnC005459 for ; Mon, 3 Jun 2002 12:14:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53JELWJ005458 for linux-xfs-outgoing; Mon, 3 Jun 2002 12:14:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from uni02du.unity.ncsu.edu (uni02du.unity.ncsu.edu [152.1.2.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53JEGnC005430 for ; Mon, 3 Jun 2002 12:14:17 -0700 Received: (from pmkasodh@localhost) by uni02du.unity.ncsu.edu (8.8.4/EC02Jan97) id PAA28105; Mon, 3 Jun 2002 15:16:04 -0400 (EDT) Date: Mon, 3 Jun 2002 15:16:04 -0400 (EDT) From: Palash Mohanlal Kasodhan To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: XFS client software In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Can I get the same sort of functionality from XFS as I would get from Andrew File System or Sun's Network File System? I plan to deploy XFS on my Linux server.I would like other Linux workstations on my network to be able to access the XFS file system resources on my Linux server. Will installing Samba on my Linux server enable the Linux workstations to access resources on the XFS file system on my Linux server.Would I need to install any software on the Linux workstations ? Thanks Palash From owner-linux-xfs@oss.sgi.com Mon Jun 3 12:16:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53JGVnC005626 for ; Mon, 3 Jun 2002 12:16:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53JGVZf005625 for linux-xfs-outgoing; Mon, 3 Jun 2002 12:16:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53JGRnC005595 for ; Mon, 3 Jun 2002 12:16:27 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA60607; Mon, 3 Jun 2002 14:18:11 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA49876; Mon, 3 Jun 2002 14:18:11 -0500 (CDT) Subject: Re: kernel-header-2.4.18-4SGI_XFS_1.1.i386.rpm From: Eric Sandeen To: Ken Murchison Cc: Linux XFS Mailing List In-Reply-To: <3CFBBF50.E2037B7@oceana.com> References: <3CFBBF50.E2037B7@oceana.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 03 Jun 2002 14:16:38 -0500 Message-Id: <1023131798.28857.5.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The kernel-headers RPM no longer exist in the Red Hat distribution; they now come from the glibc-kernheaders package, and Red Hat does not seem to update this package with each kernel release. -Eric On Mon, 2002-06-03 at 14:11, Ken Murchison wrote: > I didn't see this package on either the 1.1 Installer CD or on the ftp > site. Did I miss it, or do I have to either build it myself or switch > back to the non-RH kernel packages? > > Ken From owner-linux-xfs@oss.sgi.com Mon Jun 3 12:20:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53JKGnC005818 for ; Mon, 3 Jun 2002 12:20:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53JKGgZ005817 for linux-xfs-outgoing; Mon, 3 Jun 2002 12:20:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53JK9nC005788 for ; Mon, 3 Jun 2002 12:20:09 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id g53JLv429882; Mon, 3 Jun 2002 15:21:57 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Mon, 3 Jun 2002 15:21:56 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Palash Mohanlal Kasodhan cc: Mike Burger , Subject: Re: XFS client software In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 3 Jun 2002 at 3:16pm, Palash Mohanlal Kasodhan wrote > Can I get the same sort of functionality from XFS as I would get > from Andrew File System or Sun's Network File System? And what functionality do you want? NFS isn't really Sun's... > I plan to deploy XFS on my Linux server.I would like other Linux > workstations on my network to be able to access the XFS file system > resources on my Linux server. > Will installing Samba on my Linux server enable the Linux > workstations to access resources on the XFS file system on my Linux > server.Would I need to install any software on the Linux workstations ? You don't need samba for Linux clients. You can export an XFS filesystem using NFS (just like you could an ext{2,3} filesystem) and mount it on any of Linux client. All Linux distros that I know of come with NFS support compiled in. For more detailed info, see the Linux NFS HOWTO: http://nfs.sourceforge.net/nfs-howto/ -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Mon Jun 3 12:21:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53JL5nC005908 for ; Mon, 3 Jun 2002 12:21:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53JL5tE005907 for linux-xfs-outgoing; Mon, 3 Jun 2002 12:21:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53JKxnC005879 for ; Mon, 3 Jun 2002 12:21:00 -0700 Received: from oceana.com (KEN.oceana.com [192.168.10.26]) by eagle.oceana.com (8.12.4/8.12.4) with ESMTP id g53JMiNG012250; Mon, 3 Jun 2002 15:22:44 -0400 Message-ID: <3CFBC264.1B38C076@oceana.com> Date: Mon, 03 Jun 2002 15:24:20 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd. X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Eric Sandeen CC: Linux XFS Mailing List Subject: Re: kernel-header-2.4.18-4SGI_XFS_1.1.i386.rpm References: <3CFBBF50.E2037B7@oceana.com> <1023131798.28857.5.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > > The kernel-headers RPM no longer exist in the Red Hat distribution; they > now come from the glibc-kernheaders package, and Red Hat does not seem > to update this package with each kernel release. Doh! Thanks. > On Mon, 2002-06-03 at 14:11, Ken Murchison wrote: > > I didn't see this package on either the 1.1 Installer CD or on the ftp > > site. Did I miss it, or do I have to either build it myself or switch > > back to the non-RH kernel packages? > > > > Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Mon Jun 3 12:24:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53JO0nC006152 for ; Mon, 3 Jun 2002 12:24:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53JO0vX006151 for linux-xfs-outgoing; Mon, 3 Jun 2002 12:24:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53JNunC006123 for ; Mon, 3 Jun 2002 12:23:56 -0700 Received: from maine.americas.sgi.com (maine.americas.sgi.com [128.162.191.42]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA46371; Mon, 3 Jun 2002 14:25:40 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.35 #1 (Debian)) id 17ExSV-0000WF-00; Mon, 03 Jun 2002 14:25:39 -0500 Date: Mon, 3 Jun 2002 14:25:38 -0500 From: Nathan Straz To: Palash Mohanlal Kasodhan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS client software Message-ID: <20020603192538.GF16971@sgi.com> Mail-Followup-To: Palash Mohanlal Kasodhan , linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 03, 2002 at 03:16:04PM -0400, Palash Mohanlal Kasodhan wrote: > Can I get the same sort of functionality from XFS as I would get > from Andrew File System or Sun's Network File System? XFS is a local file system not a network or distributed file system. If you want other machines to access the file systems on your server, you need to export it with a network file system. NFS is probably the best option if you're serving NFS clients. Samba is probably the best option of you're serving Microsoft clients. You can use Samba and NFS at the same time. -- Nate Straz nstraz@sgi.com sgi, inc http://www.sgi.com/ Linux Test Project http://ltp.sf.net/ From owner-linux-xfs@oss.sgi.com Mon Jun 3 12:54:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53JsRnC013134 for ; Mon, 3 Jun 2002 12:54:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53JsR9T013133 for linux-xfs-outgoing; Mon, 3 Jun 2002 12:54:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zork.zork.net (mail@zork.zork.net [66.92.188.166]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53JsLnC013097 for ; Mon, 3 Jun 2002 12:54:22 -0700 Received: from sneakums by zork.zork.net with local (Exim 3.35 #1 (Debian)) id 17Exw3-00026v-00; Mon, 03 Jun 2002 12:56:11 -0700 To: Linux XFS Subject: Re: kernel-header-2.4.18-4SGI_XFS_1.1.i386.rpm References: <3CFBBF50.E2037B7@oceana.com> <1023131798.28857.5.camel@stout.americas.sgi.com> From: Sean Neakums X-Worst-Pick-Up-Line-Ever: "Hey baby, wanna peer with my leafnode instance?" X-Groin-Mounted-Steering-Wheel: "Arrrr... it's driving me nuts!" X-Message-Flag: Message text advisory: AFFIRMATION OF THE CONSEQUENT, BRAZEN SELF-DECEIT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Mon, 03 Jun 2002 20:56:11 +0100 In-Reply-To: <1023131798.28857.5.camel@stout.americas.sgi.com> (Eric Sandeen's message of "03 Jun 2002 14:16:38 -0500") Message-ID: <6ubsasuof8.fsf@zork.zork.net> Lines: 14 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk commence Eric Sandeen quotation: > The kernel-headers RPM no longer exist in the Red Hat distribution; > they now come from the glibc-kernheaders package, and Red Hat does > not seem to update this package with each kernel release. That may be because the kernel headers used with glibc must match the kernel version against which glibc itself was built, rather than the kernel upon which it is running. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Mon Jun 3 13:26:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53KQUnC013746 for ; Mon, 3 Jun 2002 13:26:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53KQUTT013745 for linux-xfs-outgoing; Mon, 3 Jun 2002 13:26:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53KQMnC013716 for ; Mon, 3 Jun 2002 13:26:22 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Jun 2002 13:33:35 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F17F@nasexs1.meridian-data.com> From: Dale Stephenson To: "'linux-xfs@oss.sgi.com'" Subject: RE: xfs_freeze stuck on filesystem with several snapshots. Date: Mon, 3 Jun 2002 13:33:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've reproduced the freeze and figured out where xfs_freeze is stuck, though I still don't understand why. xfs_freeze and kupdated seem to be accessing the same pagebuf structure, but seem to be stuck on different locks. kupdated is stopped after calling down() inside pagebuf_lock(), presumably from _pagebuf_find_lockable_buffer(). From the comment in fs/xfs/pagebuf/page_buf_locking.c, it is waiting for buffer ownership. xfs_freeze is stopped in pagebuf_iorequest(), specifically inside the inline _pagebuf_wait_unpin(). From the comment in fs/xfs/pagebuf/pagebuf.c, it waits until all the memory associated with the buffer is unlocked. pb_pin_count for the pagebuf structure is 1. So kupdated can't get a lock, and xfs_freeze is waiting because somebody's locked the buffer. I don't see the pagebuf address in any other processes' call stack. The kernel I'm using is rather old code, but the functions involved don't seem to have changed over the last few months. Is there a way to tell which process these two are waiting for? Dale Stephenson steph@snapserver.com > -----Original Message----- > From: Dale Stephenson > Sent: Tuesday, May 21, 2002 12:10 PM > To: 'linux-xfs@oss.sgi.com' > Subject: xfs_freeze stuck on filesystem with several snapshots. > > > I'm looking at a machine where xfs_freeze -f is stuck in D > state. The freeze is done on a filesystem that already has > three LVM snapshots, and has writes streamed to it over both > nfs and samba. I have some backtraces from kdb (attached), > but I'm not quite sure what to make of them. After > xfs_freeze -f stuck, xfs_freeze -u was tried from the command > line, and also stuck. > > The kernel is from the XFS CVS tree of Mar 19th, using LVM's > VFS lock patch. It has been patched to exempt certain > processes coming from being stopped by xfs_check_frozen, > specifically kupdated and xfs_freeze. knfsd and many smbd > processes are stopped by xfs_check_frozen, which is fine. From owner-linux-xfs@oss.sgi.com Mon Jun 3 13:58:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53KwtnC018890 for ; Mon, 3 Jun 2002 13:58:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53Kwss7018889 for linux-xfs-outgoing; Mon, 3 Jun 2002 13:58:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53KwmnC018150 for ; Mon, 3 Jun 2002 13:58:48 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA61683 for ; Mon, 3 Jun 2002 16:00:33 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA44252 for ; Mon, 3 Jun 2002 16:00:32 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA62808 for linux-xfs@oss.sgi.com; Mon, 3 Jun 2002 16:00:32 -0500 (CDT) Date: Mon, 3 Jun 2002 16:00:32 -0500 (CDT) From: Dean Roehrich Message-Id: <200206032100.QAA62808@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make dmapi use native linux mem alloc/free routines X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Make dmapi use native linux mem alloc/free routines. This reduces our dependence on xfs and takes us a few steps closer to being able to unload and reload the dmapi module. Also fix some memory leaks. Date: Mon Jun 3 14:00:11 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:120688a linux/fs/xfs_dmapi/dmapi_session.c - 1.7 linux/fs/xfs_dmapi/dmapi_right.c - 1.5 linux/fs/xfs_dmapi/dmapi_register.c - 1.10 linux/fs/xfs_dmapi/dmapi_private.h - 1.7 linux/fs/xfs_dmapi/dmapi_mountinfo.c - 1.4 linux/fs/xfs_dmapi/dmapi_event.c - 1.4 linux/fs/xfs_dmapi/dmapi_sysent.c - 1.4 - No Message Supplied From owner-linux-xfs@oss.sgi.com Mon Jun 3 14:02:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53L2hnC019888 for ; Mon, 3 Jun 2002 14:02:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53L2hZE019887 for linux-xfs-outgoing; Mon, 3 Jun 2002 14:02:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53L2cnC019859 for ; Mon, 3 Jun 2002 14:02:38 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA61652 for ; Mon, 3 Jun 2002 16:04:23 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA89496 for ; Mon, 3 Jun 2002 16:04:23 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA70836 for linux-xfs@oss.sgi.com; Mon, 3 Jun 2002 16:04:23 -0500 (CDT) Date: Mon, 3 Jun 2002 16:04:23 -0500 (CDT) From: Dean Roehrich Message-Id: <200206032104.QAA70836@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - give dmapi its own sv_wait routines X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When building dmapi as a module, use its own sv_wait routines. This further reduces dmapi's dependence on xfs, and allows dmapi to build as a module again. Date: Mon Jun 3 14:04:12 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:120689a linux/fs/xfs_dmapi/sv.c - 1.1 linux/fs/xfs_dmapi/sv.h - 1.1 linux/fs/xfs_dmapi/Makefile.in - 1.5 linux/fs/xfs_dmapi/Makefile - 1.4 - No Message Supplied From owner-linux-xfs@oss.sgi.com Mon Jun 3 14:04:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53L4GnC020052 for ; Mon, 3 Jun 2002 14:04:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53L4GOU020051 for linux-xfs-outgoing; Mon, 3 Jun 2002 14:04:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53L4BnC020023 for ; Mon, 3 Jun 2002 14:04:12 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA60562 for ; Mon, 3 Jun 2002 16:05:57 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA47736 for ; Mon, 3 Jun 2002 16:05:56 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA54721 for linux-xfs@oss.sgi.com; Mon, 3 Jun 2002 16:05:56 -0500 (CDT) Date: Mon, 3 Jun 2002 16:05:56 -0500 (CDT) From: Dean Roehrich Message-Id: <200206032105.QAA54721@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - mem fixups in xfs_dmapi.c X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 3 14:05:32 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:120690a linux/fs/xfs/xfs_dmapi.c - 1.55 - fix some mem leaks, and in cases where alloc'd mem will be shared with the dmapi module, use the native linux mem routines. From owner-linux-xfs@oss.sgi.com Mon Jun 3 14:50:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53LoqnC020699 for ; Mon, 3 Jun 2002 14:50:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53Loqvu020698 for linux-xfs-outgoing; Mon, 3 Jun 2002 14:50:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53LoknC020669 for ; Mon, 3 Jun 2002 14:50:47 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA62158 for ; Mon, 3 Jun 2002 16:52:32 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA68760 for ; Mon, 3 Jun 2002 16:52:32 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g53LmY028419; Mon, 3 Jun 2002 16:48:34 -0500 Message-Id: <200206032148.g53LmY028419@jen.americas.sgi.com> Date: Mon, 3 Jun 2002 16:48:34 -0500 Subject: TAKE - back out a change which affects debian compilers X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This change caused folks using the debian 2.95 compilers to generate bad code for xfs. It resulted in stalls in I/O and sometimes hangs. Date: Mon Jun 3 14:51:14 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline Undoes mod: 2.4.x-xfs:slinx:120154a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120708a linux/fs/xfs/xfs_log.h - 1.60 linux/fs/xfs/Makefile - 1.140 linux/fs/xfs/xfs_log_lsn.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jun 3 14:57:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53LvSnC020928 for ; Mon, 3 Jun 2002 14:57:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53LvS2x020927 for linux-xfs-outgoing; Mon, 3 Jun 2002 14:57:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53LvMnC020897 for ; Mon, 3 Jun 2002 14:57:22 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA62317 for ; Mon, 3 Jun 2002 16:59:08 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA22631 for ; Mon, 3 Jun 2002 16:59:07 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA27892 for linux-xfs@oss.sgi.com; Mon, 3 Jun 2002 16:59:07 -0500 (CDT) Date: Mon, 3 Jun 2002 16:59:07 -0500 (CDT) From: Dean Roehrich Message-Id: <200206032159.QAA27892@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - in dmapi, use sv_wait_sig rather than mp_sv_wait_sig X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 3 14:58:54 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:120709a linux/fs/xfs_dmapi/dmapi_session.c - 1.8 linux/fs/xfs_dmapi/dmapi_register.c - 1.11 - No Message Supplied From owner-linux-xfs@oss.sgi.com Mon Jun 3 15:39:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53MdgnC021489 for ; Mon, 3 Jun 2002 15:39:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53MdgSp021488 for linux-xfs-outgoing; Mon, 3 Jun 2002 15:39:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@[216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53MdYnC021453 for ; Mon, 3 Jun 2002 15:39:34 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 063B94C3022; Mon, 3 Jun 2002 18:41:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 04843C0EE0F; Mon, 3 Jun 2002 18:41:26 -0400 (EDT) Date: Mon, 3 Jun 2002 18:41:26 -0400 (EDT) From: Mike Burger To: Palash Mohanlal Kasodhan Cc: linux-xfs@oss.sgi.com Subject: Re: XFS client software In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS is not a remote or networked filesystem access system, as AFS, NFS or Samba would give you. XFS is more akin to EXT3, JFS, ReiserFS. You format the server's hard drives with XFS, and remote systems can have access to the server's file system via NFS, AFS, Samba, etc. The networked file systems can be installed so that they can access an XFS formatted system, and won't care what the underlying filesystem, on the server, is. On Mon, 3 Jun 2002, Palash Mohanlal Kasodhan wrote: > > Can I get the same sort of functionality from XFS as I would get > from Andrew File System or Sun's Network File System? > I plan to deploy XFS on my Linux server.I would like other Linux > workstations on my network to be able to access the XFS file system > resources on my Linux server. > Will installing Samba on my Linux server enable the Linux > workstations to access resources on the XFS file system on my Linux > server.Would I need to install any software on the Linux workstations ? > > Thanks > > Palash > > From owner-linux-xfs@oss.sgi.com Mon Jun 3 16:12:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53NCunC022353 for ; Mon, 3 Jun 2002 16:12:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53NCu8f022352 for linux-xfs-outgoing; Mon, 3 Jun 2002 16:12:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53NCinC022324 for ; Mon, 3 Jun 2002 16:12:45 -0700 Received: from localhost ([80.1.68.230]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020603221616.ZGQC295.mta03-svc.ntlworld.com@localhost> for ; Mon, 3 Jun 2002 23:16:16 +0100 Content-Type: text/plain; charset="us-ascii" From: mark Reply-To: mark.newman2@ntlworld.com Organization: mark To: "'linux-xfs@oss.sgi.com'" Subject: probs with cp -p Date: Mon, 3 Jun 2002 22:01:36 +0000 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Message-Id: <200206032201.36167.mark.newman2@ntlworld.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g53NCjnC022325 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I've been having problems using the following with my xfs fs cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/ which returns the following cp: `/usr/local/share/mondo/restore-scripts.tgz': Argument list too long cp: preserving permissions for `/home/mondo.scratch.19294/usr/local/share/mondo': Invalid argument Steve has suggested I run the comand with strace -v to confirm its not XFS related. Not being a developer myself the output does not really help me but I would be greatful for any insight on this Even a pointer in the right direction. I have a small ext3 partition where the comand works fine but its smaller and different files are involved so this may not be a proof. The end of the strace is below I am not sure which parts are required if anyone needs to see more pls let me know I just didnt want to waste bandwidth read(3, "", 4096) = 0 close(4) = 0 close(3) = 0 utime("/home/mondo.scratch.30606/usr/local/share/mondo/restore-scripts.tgz", [2002/06/03-21:42:43, 2002/06/03-14:18:36]) = 0 SYS_229(0x8054e78, 0x4d286327, 0xbff72684, 0x84, 0x62) = -1 E2BIG (Argument list too long) write(2, "cp: ", 4cp: ) = 4 write(2, "`/usr/local/share/mondo/restore-"..., 44`/usr/local/share/mondo/restore-scripts.tgz') = 44 write(2, ": Argument list too long", 24: Argument list too long) = 24 write(2, "\n", 1 ) = 1 utime("/home/mondo.scratch.30606/usr/local/share/mondo", [2002/06/03-21:42:43, 2002/06/03-14:18:36]) = 0 SYS_229(0xbff73b9c, 0x4d286327, 0xbff728b4, 0x84, 0) = -1 ENODATA (No data available) stat64("/usr/local/share/mondo", {st_dev=makedev(3, 5), st_ino=25175423, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=32, st_atime=2002/06/03-21:59:11, st_mtime=2002/06/03-14:18:36, st_ctime=2002/06/03-14:18:36}) = 0 SYS_226(0x8054df0, 0x4d286370, 0x8054f08, 0x1c, 0) = 0 SYS_229(0xbff73b9c, 0x4d28633f, 0xbff728b4, 0x84, 0x4d26308d) = -1 ENODATA (No data available) SYS_226(0x8054df0, 0x4d286388, 0x8054ea8, 0x4, 0) = -1 EINVAL (Invalid argument) write(2, "cp: ", 4cp: ) = 4 write(2, "preserving permissions for `/hom"..., 76preserving permissions for `/home/mondo.scratch.30606/usr/local/share/mondo') = 76 write(2, ": Invalid argument", 18: Invalid argument) = 18 write(2, "\n", 1 ) = 1 geteuid32() = 0 _exit(1) = ? local Thanks Mark From owner-linux-xfs@oss.sgi.com Mon Jun 3 16:15:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g53NFEnC022562 for ; Mon, 3 Jun 2002 16:15:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g53NFEoS022561 for linux-xfs-outgoing; Mon, 3 Jun 2002 16:15:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g53NF7nC022529 for ; Mon, 3 Jun 2002 16:15:07 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA03503 for ; Mon, 3 Jun 2002 16:16:56 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13889; Tue, 4 Jun 2002 09:15:35 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA29179; Tue, 4 Jun 2002 09:15:34 +1000 (AEST) Date: Tue, 4 Jun 2002 09:15:33 +1000 From: Nathan Scott To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: acl_extended_file() broken? Message-ID: <20020604091533.C229351@wobbly.melbourne.sgi.com> References: <20020603044347.I13201@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020603044347.I13201@plato.local.lan>; from erbenson@alaska.net on Mon, Jun 03, 2002 at 04:43:47AM -0800 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Ethan, On Mon, Jun 03, 2002 at 04:43:47AM -0800, Ethan Benson wrote: > ... > afaict it uses the libacl function acl_extended_file() to check > whether a file/dir has an actual acl associated, it appears to use > this function correctly so i wrote a test program and found this > function appears to be lying: > ... > am i missing something? the way i read the man page it should return 0: > > The acl_extended_file() function returns 1 if the file or directory > referred to by the argument path_p is associated with an extended access > ACL, or if the directory referred to by path_p is associated with a > default ACL. The function returns 0 if the file has neither an extended > access ACL nor a default ACL. > Yeah, I see the problem now. Basically, Andreas and I interpreted this differently, and now that I read the current man page again, looks like I've implemented it incorrectly in XFS. This acl call is implemented using getxattr with size==0 -- I had originally interpreted this as "return size of a buffer large enough to hold the EA value" ... and this probably was the semantics at some point while the syscall discussions were going on. I see the current man page - getxattr(2) - is explicit on this being the current size. This shouldn't be too hard to fix in XFS, I expect to have some new code later today to correct this. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jun 3 18:47:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g541lPnC024451 for ; Mon, 3 Jun 2002 18:47:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g541lOv8024450 for linux-xfs-outgoing; Mon, 3 Jun 2002 18:47:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g541lFnC024422 for ; Mon, 3 Jun 2002 18:47:15 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA02613 for ; Mon, 3 Jun 2002 18:48:56 -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 LAA64998; Tue, 4 Jun 2002 11:47:37 +1000 (EST) Date: Tue, 4 Jun 2002 11:47:37 +1000 (EST) From: Nathan Scott Message-Id: <200206040147.LAA64998@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: erbenson@alaska.net Subject: TAKE - xfs_acl.c X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This should fix that fileutils problem you observed, Ethan. cheers. Date: Sun Jun 2 18:47:28 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:120647a cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.7 cmd/xfsprogs/include/xfs_mount.h - 1.17 cmd/xfsprogs/libxfs/xfs_ialloc.c - 1.10 cmd/xfsprogs/libxfs/xfs.h - 1.17 cmd/xfsprogs/libxfs/xfs_alloc.c - 1.10 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.10 - sync with recent kernel changes. Date: Mon Jun 3 18:45:49 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120723a linux/fs/xfs/xfs_acl.c - 1.21 - Fix up behaviour when we're called via getxattr + size==0 code path, which in turn affects libacl's acl_extended_file routine, which in turn affects fileutils checks for the presence of file ACLs. From owner-linux-xfs@oss.sgi.com Mon Jun 3 18:51:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g541pqnC024641 for ; Mon, 3 Jun 2002 18:51:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g541pqFH024640 for linux-xfs-outgoing; Mon, 3 Jun 2002 18:51:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g541plnC024612 for ; Mon, 3 Jun 2002 18:51:47 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA02981 for ; Mon, 3 Jun 2002 18:53:36 -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 LAA15041; Tue, 4 Jun 2002 11:52:19 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA32712; Tue, 4 Jun 2002 11:52:18 +1000 (AEST) Date: Tue, 4 Jun 2002 11:52:18 +1000 From: Nathan Scott To: mark Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: probs with cp -p Message-ID: <20020604115218.D232510@wobbly.melbourne.sgi.com> References: <200206032201.36167.mark.newman2@ntlworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206032201.36167.mark.newman2@ntlworld.com>; from mark.newman2@ntlworld.com on Mon, Jun 03, 2002 at 10:01:36PM +0000 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 03, 2002 at 10:01:36PM +0000, mark wrote: > Hi > > I've been having problems using the following with my xfs fs > > cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/ > > which returns the following > > cp: `/usr/local/share/mondo/restore-scripts.tgz': Argument list too long > cp: preserving permissions for > `/home/mondo.scratch.19294/usr/local/share/mondo': Invalid argument Please try a more recent kernel, and let me know if the problem persists. This looks like a problem that was fixed in the ACL return codes a little while ago. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jun 4 05:54:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54CsCnC026132 for ; Tue, 4 Jun 2002 05:54:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54CsCDk026131 for linux-xfs-outgoing; Tue, 4 Jun 2002 05:54:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54Cs5nC026102 for ; Tue, 4 Jun 2002 05:54:06 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA66116 for ; Tue, 4 Jun 2002 07:55:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA82082 for ; Tue, 4 Jun 2002 07:55:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g54Cpou06408; Tue, 4 Jun 2002 07:51:50 -0500 Message-Id: <200206041251.g54Cpou06408@jen.americas.sgi.com> Date: Tue, 4 Jun 2002 07:51:50 -0500 Subject: TAKE - tweak allocation size To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This brings the default amount of data xfs allocates back in line with the code prior to the multiple blocksize work. Worth a few percent on write speed. Date: Tue Jun 4 05:53:41 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120735a linux/fs/xfs/xfs_mount.h - 1.143 - Define XFS_WRITE_IO_LOG linux/fs/xfs/linux/xfs_iops.c - 1.146 - Use XFS_WRITE_IO_LOG as the size for extending allocations From owner-linux-xfs@oss.sgi.com Tue Jun 4 07:17:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54EHTnC027110 for ; Tue, 4 Jun 2002 07:17:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54EHTdx027109 for linux-xfs-outgoing; Tue, 4 Jun 2002 07:17:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54EHKnC027081 for ; Tue, 4 Jun 2002 07:17:21 -0700 Received: from localhost ([80.1.68.230]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020604111130.JPTO2755.mta05-svc.ntlworld.com@localhost>; Tue, 4 Jun 2002 12:11:30 +0100 Content-Type: text/plain; charset="iso-8859-1" From: mark Reply-To: mark.newman2@ntlworld.com Organization: mark To: Nathan Scott Subject: Re: probs with cp -p Date: Tue, 4 Jun 2002 10:56:45 +0000 User-Agent: KMail/1.4.1 References: <200206032201.36167.mark.newman2@ntlworld.com> <20020604115218.D232510@wobbly.melbourne.sgi.com> In-Reply-To: <20020604115218.D232510@wobbly.melbourne.sgi.com> Cc: "'linux-xfs@oss.sgi.com'" MIME-Version: 1.0 Message-Id: <200206041056.45746.mark.newman2@ntlworld.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54EHLnC027082 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tuesday 04 June 2002 01:52, Nathan Scott wrote: > On Mon, Jun 03, 2002 at 10:01:36PM +0000, mark wrote: > > Hi > > > > I've been having problems using the following with my xfs fs > > > > cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/ > > > > which returns the following > > > > cp: `/usr/local/share/mondo/restore-scripts.tgz': Argument list too long > > cp: preserving permissions for > > `/home/mondo.scratch.19294/usr/local/share/mondo': Invalid argument > > Please try a more recent kernel, and let me know if the problem persists. > This looks like a problem that was fixed in the ACL return codes a little > while ago. > > thanks. Okay I have now tried a vanilla 2.4.18 with XFS 1.1 kernel (just to ensure it wasnt a problem with my patched 2.4.19) with similar results. 'Argument too long' dissapeared but I still get the 'invalid argument' message. Could there be some kind of problem with my filesystem. Is there more info I could provide? Mark From owner-linux-xfs@oss.sgi.com Tue Jun 4 08:07:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54F7pnC028505 for ; Tue, 4 Jun 2002 08:07:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54F7pVI028504 for linux-xfs-outgoing; Tue, 4 Jun 2002 08:07:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf06bis.bellsouth.net (mail006.mail.bellsouth.net [205.152.58.26]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54F7dnC028476 for ; Tue, 4 Jun 2002 08:07:40 -0700 Received: from taz ([66.156.5.105]) by imf06bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020604151054.PCQT1231.imf06bis.bellsouth.net@taz>; Tue, 4 Jun 2002 11:10:54 -0400 Date: Tue, 4 Jun 2002 11:01:19 -0400 From: Greg Freemyer Subject: re[2]: Which Kernel for XFS To: "Anthony W. Marino" cc: linux-xfs Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020604151054.PCQT1231.imf06bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54F7enC028477 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Since you are using a SuSE distribution, have you thought about using the SuSE experimental kernel from ftp://ftp.suse.com/pub/people/mantel/next/RPM/ It has all the standard SuSE patches and includes a relatively recent XFS. Possibly XFS v1.1, but I'm not sure. FYI: The stock SuSE 8.0 kernel also has XFS support, but the ACL handling is broken in such a way that xfsdump/xfsrestore don't handle ACLs correctly. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com >> Steve, >> What do you recommend that I use since the box I'm building is a >> development >> box for myself which I will be using for development purposes and thus >> will >> be using other cvs sources from other opesource projects as well? >> Anthony >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: >> > > I'm building/setting-up a new server SuSE 7.3 which will include 3ware >> > > (7810) ide raid (10 or 5) with brand new drives and most likely LVM >> too. >> > > Should I get the kernel from oss.sgi.com cvs >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" linux-2.4-xfs) or is there >> > > another location/process that I should entertain? Also what kernel >> > > release does the oss.sgi.com cvs sources give me? >> > > >> > > Thank You, >> > > Anthony >> > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb (which you probably >> > do not care about). There are fixes in this tree which are not available >> > anywhere else, it is the most direct link to XFS development. Of course >> > this also possibly means there are bugs in this tree which are not >> > available anywhere else. >> > >> > Steve From owner-linux-xfs@oss.sgi.com Tue Jun 4 08:18:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54FI7nC028775 for ; Tue, 4 Jun 2002 08:18:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54FI6k2028774 for linux-xfs-outgoing; Tue, 4 Jun 2002 08:18:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ente.berdmann.de (frnk-d514e16e.dsl.mediaWays.net [213.20.225.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54FHxnC028746 for ; Tue, 4 Jun 2002 08:17:59 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 17FG67-0003pW-00 for linux-xfs@oss.sgi.com; Tue, 04 Jun 2002 17:19:47 +0200 Message-ID: <3CFCDA93.1B4D65EA@berdmann.de> Date: Tue, 04 Jun 2002 17:19:47 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: 7.3 SGI XFS ISO fails net install Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I tried to install 7.3 (SGI XFS 1.1) via HTTP (RedHat/base/ from SGI-CD, Redhat/RPMS/ filled with RPMs from RH CD 1, 2, 3 and SGI CD in this order). The installer fails when trying to load netstg1.img. On Alt-F3 is printed: transferring http://rhinstall//redhat/7.3/i386/RedHat/base/netstg1.img to a fd copied 8144792 bytes to /tmp/ramfs/netstg1.img (the number of bytes varies: 8144416, 8144296, 8143920, 8143920) Interesting enough this file is of 8572928 bytes on disk. After download with a browser it's size is the same. This happens on two different boxes: - Compaq ProLiant DL 360, 4 GB RAM (using the driver disk) - noname Celeron 600 Using the same procedure for 7.2 (SGI XFS 1.0.2) works well. From owner-linux-xfs@oss.sgi.com Tue Jun 4 08:25:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54FPDnC029019 for ; Tue, 4 Jun 2002 08:25:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54FPDol029018 for linux-xfs-outgoing; Tue, 4 Jun 2002 08:25:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54FP0nC028981 for ; Tue, 4 Jun 2002 08:25:00 -0700 Received: from [64.32.179.242] (HELO awm-laptop) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 30112425; Tue, 04 Jun 2002 08:19:14 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects To: Greg Freemyer Subject: Re: re[2]: Which Kernel for XFS Date: Tue, 4 Jun 2002 11:30:50 -0400 User-Agent: KMail/1.4.1 Cc: linux-xfs References: <20020604151054.PCQT1231.imf06bis.bellsouth.net@taz> In-Reply-To: <20020604151054.PCQT1231.imf06bis.bellsouth.net@taz> MIME-Version: 1.0 Message-Id: <200206041130.50974.anthony@AWMObjects.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54FP0nC028984 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Since you are using a SuSE distribution, have you thought about using the > SuSE experimental kernel from > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ > > It has all the standard SuSE patches and includes a relatively recent XFS. > Possibly XFS v1.1, but I'm not sure. > I have the Mantel's latest kernel installed on my laptop however I'm not certain what it is that I have. What I mean by that is how do I find out what XFS version and patch level do I have so that I can decide on patch upgrades? I know it says kernel 2.4.18 however is it really 2.4.19 pre... . As you can see, I'm not certain of the versions and patch levels contained within the Mantel stuff. Anthony > FYI: The stock SuSE 8.0 kernel also has XFS support, but the ACL handling > is broken in such a way that xfsdump/xfsrestore don't handle ACLs > correctly. > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com > > >> Steve, > >> What do you recommend that I use since the box I'm building is a > >> development > >> box for myself which I will be using for development purposes and thus > >> will > >> be using other cvs sources from other opesource projects as well? > >> > >> Anthony > >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: > >> > > I'm building/setting-up a new server SuSE 7.3 which will include > >> > > 3ware (7810) ide raid (10 or 5) with brand new drives and most > >> > > likely LVM > >> > >> too. > >> > >> > > Should I get the kernel from oss.sgi.com cvs > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" linux-2.4-xfs) or is > >> > > there another location/process that I should entertain? Also what > >> > > kernel release does the oss.sgi.com cvs sources give me? > >> > > > >> > > Thank You, > >> > > Anthony > >> > > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb (which you > >> > probably do not care about). There are fixes in this tree which are > >> > not available anywhere else, it is the most direct link to XFS > >> > development. Of course this also possibly means there are bugs in > >> > this tree which are not available anywhere else. > >> > > >> > Steve From owner-linux-xfs@oss.sgi.com Tue Jun 4 09:31:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54GVTnC029905 for ; Tue, 4 Jun 2002 09:31:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54GVTOj029904 for linux-xfs-outgoing; Tue, 4 Jun 2002 09:31:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54GV3nC029871 for ; Tue, 4 Jun 2002 09:31:04 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA68274 for ; Tue, 4 Jun 2002 11:32:52 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA11269 for ; Tue, 4 Jun 2002 11:32:51 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g54GVA513769; Tue, 4 Jun 2002 11:31:10 -0500 Message-Id: <200206041631.g54GVA513769@stout.americas.sgi.com> Date: Tue, 4 Jun 2002 11:31:10 -0500 Subject: TAKE - Update copyrights on kernel files X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Busywork from legal, with apologies to CVS users who are going to have a very large update coming up here... especially when I do the cmds/ subdirectory. :( no code changes whatsoever, just 172 updated copyright lines. Update copyright dates Date: Tue Jun 4 09:30:46 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-copyright The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120763a linux/fs/xfs/xfs_trans_dquot.c - 1.35 linux/fs/xfs/xfsidbg.c - 1.183 linux/fs/xfs/xfs_log.h - 1.61 linux/fs/xfs/xfs_log.c - 1.248 linux/fs/xfs/xfs_quota_priv.h - 1.21 linux/fs/xfs/xfs_ialloc.c - 1.157 linux/fs/xfs/xfs_macros.c - 1.41 linux/fs/xfs/xfs_ag.h - 1.44 linux/fs/xfs/xfs_rw.h - 1.63 linux/fs/xfs/xfs_rw.c - 1.356 linux/fs/xfs/xfs_extfree_item.c - 1.47 linux/fs/xfs/xfs_buf.h - 1.88 linux/fs/xfs/xfs_buf_item.h - 1.34 linux/fs/xfs/xfs_buf_item.c - 1.121 linux/fs/xfs/xfs_trans_priv.h - 1.22 linux/fs/xfs/xfs_attr_sf.h - 1.15 linux/fs/xfs/xfs_log_priv.h - 1.82 linux/fs/xfs/xfs_grio.c - 1.88 linux/fs/xfs/xfs_da_btree.c - 1.128 linux/fs/xfs/xfs_da_btree.h - 1.43 linux/fs/xfs/xfs_bit.h - 1.10 linux/fs/xfs/xfs_bit.c - 1.16 linux/fs/xfs/xfs_sb.h - 1.51 linux/fs/xfs/xfs_trans_ail.c - 1.63 linux/fs/xfs/xfs_vnodeops.c - 1.529 linux/fs/xfs/xfs_dir2_block.c - 1.24 linux/fs/xfs/xfs_dir2_block.h - 1.8 linux/fs/xfs/xfs_attr_fetch.c - 1.10 linux/fs/xfs/xfsquotasstubs.c - 1.15 linux/fs/xfs/xfs_dir.c - 1.135 linux/fs/xfs/xfs_dqblk.h - 1.7 linux/fs/xfs/xfs_rtalloc.c - 1.72 linux/fs/xfs/xfs_itable.c - 1.105 linux/fs/xfs/xfs_itable.h - 1.35 linux/fs/xfs/xfs_ialloc_btree.c - 1.66 linux/fs/xfs/xfs_dmapi.h - 1.22 linux/fs/xfs/xfs_dmapi.c - 1.56 linux/fs/xfs/xfs_inode_item.c - 1.99 linux/fs/xfs/Makefile - 1.141 linux/fs/xfs/xfs_iocore.c - 1.30 linux/fs/xfs/xfsrtstubs.c - 1.12 linux/fs/xfs/xfs_qm_syscalls.c - 1.62 linux/fs/xfs/xfs_log_recover.c - 1.232 linux/fs/xfs/xfs_trans_item.c - 1.31 linux/fs/xfs/xfs_dquot_item.h - 1.7 linux/fs/xfs/xfs_dquot_item.c - 1.27 linux/fs/xfs/xfs_vfsops.c - 1.349 linux/fs/xfs/xfs_dfrag.c - 1.30 linux/fs/xfs/xfs_iget.c - 1.159 linux/fs/xfs/xfs_clnt.h - 1.29 linux/fs/xfs/xfs_bmap_btree.c - 1.122 linux/fs/xfs/xfs_dir2_sf.h - 1.12 linux/fs/xfs/xfs_dir2_sf.c - 1.26 linux/fs/xfs/xfs_dquot.h - 1.21 linux/fs/xfs/xfs_dquot.c - 1.65 linux/fs/xfs/xfs_dir_leaf.c - 1.100 linux/fs/xfs/xfs_dir_leaf.h - 1.33 linux/fs/xfs/xfs_mount.h - 1.144 linux/fs/xfs/xfs_mount.c - 1.286 linux/fs/xfs/xfs_rtbit.c - 1.10 linux/fs/xfs/xfs_btree.c - 1.97 linux/fs/xfs/xfs_btree.h - 1.52 linux/fs/xfs/xfs_qm.h - 1.22 linux/fs/xfs/xfs_qm.c - 1.75 linux/fs/xfs/xfs_dir2_data.c - 1.17 linux/fs/xfs/xfs_inode.c - 1.339 linux/fs/xfs/xfs_inode.h - 1.160 linux/fs/xfs/xfs_dir2_trace.c - 1.11 linux/fs/xfs/xfs_dir2_leaf.c - 1.26 linux/fs/xfs/xfs_dir2_leaf.h - 1.9 linux/fs/xfs/xfs_attr_leaf.h - 1.28 linux/fs/xfs/xfs_attr_leaf.c - 1.62 linux/fs/xfs/xfs_types.h - 1.55 linux/fs/xfs/xfs_trans.c - 1.130 linux/fs/xfs/xfs_trans.h - 1.111 linux/fs/xfs/xfs_error.c - 1.32 linux/fs/xfs/xfs_error.h - 1.25 linux/fs/xfs/xfs_utils.c - 1.44 linux/fs/xfs/xfs_utils.h - 1.16 linux/fs/xfs/xfs_alloc.c - 1.151 linux/fs/xfs/xfs_alloc.h - 1.51 linux/fs/xfs/xfs_fsops.h - 1.20 linux/fs/xfs/xfs_fsops.c - 1.78 linux/fs/xfs/xfs_bmap.c - 1.284 linux/fs/xfs/xfsdmapistubs.c - 1.11 linux/fs/xfs/xfs_alloc_btree.c - 1.69 linux/fs/xfs/xfs_quota.h - 1.26 linux/fs/xfs/xfs_trans_buf.c - 1.100 linux/fs/xfs/xfs_cxfs.h - 1.9 linux/fs/xfs/xfs_dir2_node.c - 1.23 linux/fs/xfs/xfs_rename.c - 1.34 linux/fs/xfs/xfs_attr.c - 1.91 linux/fs/xfs/xfs_attr.h - 1.21 linux/fs/xfs/xfs_dir2.h - 1.10 linux/fs/xfs/xfs_dir2.c - 1.32 linux/fs/xfs/xfs_dinode.h - 1.60 linux/fs/xfs/linux/xfs_lrw.h - 1.21 linux/fs/xfs/linux/xfs_lrw.c - 1.140 linux/fs/xfs/linux/xfs_vfs.c - 1.30 linux/fs/xfs/linux/xfs_dmistubs.c - 1.15 linux/fs/xfs/linux/xfs_globals.c - 1.27 linux/fs/xfs/linux/xfs_linux.h - 1.68 linux/fs/xfs/linux/Makefile - 1.51 linux/fs/xfs/linux/xfs_file.c - 1.61 linux/fs/xfs/linux/xfs_vnode.c - 1.80 linux/fs/xfs/linux/xfs_fs_subr.c - 1.30 linux/fs/xfs/linux/xfs_super.h - 1.20 linux/fs/xfs/linux/xfs_super.c - 1.174 linux/fs/xfs/linux/xfs_iops.c - 1.147 linux/fs/xfs/linux/xfs_iops.h - 1.13 linux/include/linux/xfs_fs_i.h - 1.8 linux/include/linux/xfs_fs.h - 1.33 linux/fs/xfs/linux/xfs_cred.h - 1.15 linux/fs/xfs/linux/xfs_ioctl.c - 1.62 linux/fs/xfs/xfs_grio.h - 1.5 linux/include/linux/behavior.h - 1.3 linux/include/linux/vnode.h - 1.6 linux/include/linux/dmapi.h - 1.9 linux/include/linux/dmapi_kern.h - 1.10 linux/fs/xfs/linux/xfs_globals.h - 1.8 linux/fs/xfs/xfs.h - 1.22 linux/fs/xfs/linux/xfs_vnode.h - 1.34 linux/fs/xfs/linux/xfs_vfs.h - 1.13 linux/fs/xfs/linux/xfs_fs_subr.h - 1.6 linux/fs/xfs/linux/xfs_behavior.h - 1.4 linux/fs/xfs/support/uuid.h - 1.4 linux/fs/xfs/support/atomic.h - 1.5 linux/fs/xfs/support/debug.c - 1.5 linux/fs/xfs/support/uuid.c - 1.4 linux/fs/xfs/support/types.h - 1.5 linux/fs/xfs/support/time.h - 1.4 linux/fs/xfs/support/sv.h - 1.6 linux/fs/xfs/support/sv.c - 1.6 linux/fs/xfs/support/spin.h - 1.5 linux/fs/xfs/support/sema.h - 1.6 linux/fs/xfs/support/qsort.h - 1.4 linux/fs/xfs/support/mutex.h - 1.7 linux/fs/xfs/support/mutex.c - 1.4 linux/fs/xfs/support/mrlock.h - 1.6 linux/fs/xfs/support/mrlock.c - 1.8 linux/fs/xfs/support/ktrace.h - 1.5 linux/fs/xfs/support/move.h - 1.7 linux/fs/xfs/linux/xfs_stats.c - 1.3 linux/fs/xfs/support/Makefile - 1.9 linux/fs/xfs/support/arch.h - 1.5 linux/fs/xfs/support/move.c - 1.5 linux/fs/xfs/support/kmem.h - 1.7 linux/fs/xfs/support/debug.h - 1.4 linux/fs/xfs/support/kmem.c - 1.10 linux/fs/xfs/support/ktrace.c - 1.7 linux/fs/xfs/xfs_acl.h - 1.10 linux/fs/xfs/xfs_acl.c - 1.22 linux/fs/xfs/Makefile.in - 1.16 linux/fs/xfs/linux/Makefile.in - 1.6 linux/fs/xfs/linux/xfs_sysctl.h - 1.3 linux/fs/xfs/linux/xfs_sysctl.c - 1.3 linux/fs/xfs_dmapi/xfsjunk.c - 1.6 linux/fs/xfs/pagebuf/Makefile.in - 1.6 linux/fs/xfs/pagebuf/page_buf_io.c - 1.41 linux/fs/xfs/pagebuf/Makefile - 1.10 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.16 linux/fs/xfs/pagebuf/page_buf.c - 1.31 linux/fs/xfs/pagebuf/page_buf_trace.h - 1.3 linux/fs/xfs/pagebuf/page_buf.h - 1.18 linux/fs/xfs/xfs_mac.h - 1.2 linux/fs/xfs/xfs_mac.c - 1.2 linux/fs/xfs/linux/xfs_xattr.c - 1.11 linux/fs/xfs/linux/xfs_xattr.h - 1.5 linux/fs/xattr.c - 1.6 linux/include/linux/xattr.h - 1.2 linux/fs/xfs/support/Makefile.in - 1.2 linux/include/linux/quotaio_xfs.h - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jun 4 10:02:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54H2UnC031802 for ; Tue, 4 Jun 2002 10:02:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54H2UC8031801 for linux-xfs-outgoing; Tue, 4 Jun 2002 10:02:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf01bis.bellsouth.net (mail301.mail.bellsouth.net [205.152.58.161]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54H2FnC031771 for ; Tue, 4 Jun 2002 10:02:15 -0700 Received: from taz ([66.156.5.105]) by imf01bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020604170528.WVJP1202.imf01bis.bellsouth.net@taz>; Tue, 4 Jun 2002 13:05:28 -0400 Date: Tue, 4 Jun 2002 12:55:33 -0400 From: Greg Freemyer Subject: re[4]: Which Kernel for XFS To: "Anthony W. Marino" cc: linux-xfs Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020604170528.WVJP1202.imf01bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54H2GnC031772 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anthony, The notes at ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/people/mantel/next/kernel-source.changes give you some of what you are asking about. Per the above, it is based on the 2.4.19-pre8aa1 kernel. I believe that already has the XFS patches in it, so you could look into what it has. For details, I guess you need to download the source RPM and read the specfile. Greg >> > Since you are using a SuSE distribution, have you thought about using >> the >> > SuSE experimental kernel from >> > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ >> > >> > It has all the standard SuSE patches and includes a relatively recent >> XFS. >> > Possibly XFS v1.1, but I'm not sure. >> > >> I have the Mantel's latest kernel installed on my laptop however I'm not >> certain what it is that I have. What I mean by that is how do I find out >> what XFS version and patch level do I have so that I can decide on patch >> upgrades? I know it says kernel 2.4.18 however is it really 2.4.19 pre... >> . >> As you can see, I'm not certain of the versions and patch levels contained >> >> within the Mantel stuff. >> Anthony >> > FYI: The stock SuSE 8.0 kernel also has XFS support, but the ACL >> handling >> > is broken in such a way that xfsdump/xfsrestore don't handle ACLs >> > correctly. >> > >> > Greg Freemyer >> > Internet Engineer >> > Deployment and Integration Specialist >> > Compaq ASE - Tru64 >> > Compaq Master ASE - SAN Architect >> > The Norcross Group >> > www.NorcrossGroup.com >> > >> > >> Steve, >> > >> What do you recommend that I use since the box I'm building is a >> > >> development >> > >> box for myself which I will be using for development purposes and >> thus >> > >> will >> > >> be using other cvs sources from other opesource projects as well? >> > >> >> > >> Anthony >> > >> >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: >> > >> > > I'm building/setting-up a new server SuSE 7.3 which will >> include >> > >> > > 3ware (7810) ide raid (10 or 5) with brand new drives and most >> > >> > > likely LVM >> > >> >> > >> too. >> > >> >> > >> > > Should I get the kernel from oss.sgi.com cvs >> > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" linux-2.4-xfs) or is >> > >> > > there another location/process that I should entertain? Also >> what >> > >> > > kernel release does the oss.sgi.com cvs sources give me? >> > >> > > >> > >> > > Thank You, >> > >> > > Anthony >> > >> > >> > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb (which you >> > >> > probably do not care about). There are fixes in this tree which >> are >> > >> > not available anywhere else, it is the most direct link to XFS >> > >> > development. Of course this also possibly means there are bugs in >> > >> > this tree which are not available anywhere else. >> > >> > >> > >> > Steve Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 11:01:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54I1vnC002668 for ; Tue, 4 Jun 2002 11:01:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54I1vEU002667 for linux-xfs-outgoing; Tue, 4 Jun 2002 11:01:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54I0PnC002631 for ; Tue, 4 Jun 2002 11:00:25 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA52856 for ; Tue, 4 Jun 2002 13:02:13 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA18648 for ; Tue, 4 Jun 2002 13:02:13 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g54I0VT19489; Tue, 4 Jun 2002 13:00:31 -0500 Message-Id: <200206041800.g54I0VT19489@stout.americas.sgi.com> Date: Tue, 4 Jun 2002 13:00:31 -0500 Subject: TAKE - Update copyrights on cmd/ X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just in case your 56k modem isn't pleading for mercy... Update copyright dates Date: Tue Jun 4 10:58:21 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-copyright The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:120772a cmd/acl/install-sh - 1.8 cmd/acl/Makefile - 1.10 cmd/acl/doc/Makefile - 1.9 cmd/acl/man/Makefile - 1.7 cmd/acl/man/man1/Makefile - 1.6 cmd/acl/man/man3/Makefile - 1.5 cmd/acl/man/man5/Makefile - 1.6 cmd/acl/build/Makefile - 1.6 cmd/acl/build/rpm/Makefile - 1.7 cmd/acl/build/tar/Makefile - 1.5 cmd/acl/chacl/Makefile - 1.6 cmd/acl/chacl/chacl.c - 1.12 cmd/acl/include/buildrules - 1.8 cmd/acl/include/Makefile - 1.8 cmd/acl/debian/Makefile - 1.6 cmd/acl/debian/copyright - 1.4 cmd/acl/libacl/Makefile - 1.14 cmd/attr/install-sh - 1.4 cmd/attr/Makefile - 1.5 cmd/attr/doc/Makefile - 1.6 cmd/attr/man/Makefile - 1.6 cmd/attr/man/man1/Makefile - 1.5 cmd/attr/man/man2/Makefile - 1.6 cmd/attr/man/man3/Makefile - 1.6 cmd/attr/attr/attr.c - 1.6 cmd/attr/attr/Makefile - 1.5 cmd/attr/libattr/Makefile - 1.6 cmd/attr/build/Makefile - 1.4 cmd/attr/build/rpm/Makefile - 1.6 cmd/attr/build/rpm/attr.spec.in - 1.6 cmd/attr/build/tar/Makefile - 1.4 cmd/attr/include/buildrules - 1.5 cmd/attr/include/Makefile - 1.6 cmd/attr/include/attributes.h - 1.6 cmd/attr/debian/Makefile - 1.5 cmd/attr/debian/copyright - 1.3 cmd/xfsprogs/db/help.c - 1.2 cmd/xfsprogs/db/help.h - 1.2 cmd/xfsprogs/db/bmap.c - 1.3 cmd/xfsprogs/db/bmap.h - 1.2 cmd/xfsprogs/db/dir2sf.c - 1.2 cmd/xfsprogs/db/dir2sf.h - 1.2 cmd/xfsprogs/db/debug.h - 1.2 cmd/xfsprogs/db/debug.c - 1.2 cmd/xfsprogs/db/data.c - 1.2 cmd/xfsprogs/db/data.h - 1.2 cmd/xfsprogs/db/dquot.h - 1.2 cmd/xfsprogs/db/dquot.c - 1.3 cmd/xfsprogs/db/write.c - 1.3 cmd/xfsprogs/db/write.h - 1.2 cmd/xfsprogs/db/flist.c - 1.3 cmd/xfsprogs/db/flist.h - 1.2 cmd/xfsprogs/db/field.h - 1.2 cmd/xfsprogs/db/field.c - 1.2 cmd/xfsprogs/db/dir2.c - 1.2 cmd/xfsprogs/db/dir2.h - 1.2 cmd/xfsprogs/db/addr.h - 1.2 cmd/xfsprogs/db/attr.h - 1.2 cmd/xfsprogs/db/attr.c - 1.2 cmd/xfsprogs/db/addr.c - 1.2 cmd/xfsprogs/db/sb.c - 1.3 cmd/xfsprogs/db/dir.c - 1.2 cmd/xfsprogs/db/sb.h - 1.2 cmd/xfsprogs/db/dir.h - 1.2 cmd/xfsprogs/db/cntbt.c - 1.2 cmd/xfsprogs/db/cntbt.h - 1.2 cmd/xfsprogs/db/bnobt.c - 1.2 cmd/xfsprogs/db/bnobt.h - 1.2 cmd/xfsprogs/db/dbread.c - 1.2 cmd/xfsprogs/db/dbread.h - 1.2 cmd/xfsprogs/db/mount.h - 1.2 cmd/xfsprogs/db/mount.c - 1.2 cmd/xfsprogs/db/bmapbt.h - 1.2 cmd/xfsprogs/db/bmapbt.c - 1.2 cmd/xfsprogs/db/bmroot.c - 1.2 cmd/xfsprogs/db/bmroot.h - 1.2 cmd/xfsprogs/db/input.c - 1.3 cmd/xfsprogs/db/inobt.c - 1.2 cmd/xfsprogs/db/inobt.h - 1.2 cmd/xfsprogs/db/input.h - 1.2 cmd/xfsprogs/db/attrshort.h - 1.2 cmd/xfsprogs/db/attrshort.c - 1.2 cmd/xfsprogs/db/xfs_ncheck.sh - 1.2 cmd/xfsprogs/db/print.c - 1.3 cmd/xfsprogs/db/fprint.c - 1.3 cmd/xfsprogs/db/print.h - 1.2 cmd/xfsprogs/db/fprint.h - 1.2 cmd/xfsprogs/db/dirshort.c - 1.2 cmd/xfsprogs/db/dirshort.h - 1.2 cmd/xfsprogs/db/inode.c - 1.3 cmd/xfsprogs/db/inode.h - 1.2 cmd/xfsprogs/db/faddr.h - 1.2 cmd/xfsprogs/db/faddr.c - 1.2 cmd/xfsprogs/db/init.h - 1.3 cmd/xfsprogs/db/init.c - 1.4 cmd/xfsprogs/db/uuid.h - 1.2 cmd/xfsprogs/db/uuid.c - 1.3 cmd/xfsprogs/db/quit.h - 1.2 cmd/xfsprogs/db/quit.c - 1.2 cmd/xfsprogs/db/bit.c - 1.4 cmd/xfsprogs/db/bit.h - 1.2 cmd/xfsprogs/db/type.c - 1.3 cmd/xfsprogs/db/type.h - 1.3 cmd/xfsprogs/db/agf.c - 1.2 cmd/xfsprogs/db/agf.h - 1.2 cmd/xfsprogs/db/frag.c - 1.4 cmd/xfsprogs/db/frag.h - 1.2 cmd/xfsprogs/db/sig.c - 1.2 cmd/xfsprogs/db/sig.h - 1.2 cmd/xfsprogs/db/freesp.h - 1.2 cmd/xfsprogs/db/freesp.c - 1.3 cmd/xfsprogs/db/Makefile - 1.6 cmd/xfsprogs/db/hash.c - 1.2 cmd/xfsprogs/db/hash.h - 1.3 cmd/xfsprogs/db/xfs_check64.sh - 1.2 cmd/xfsprogs/db/agi.c - 1.2 cmd/xfsprogs/db/agi.h - 1.2 cmd/xfsprogs/db/command.h - 1.2 cmd/xfsprogs/db/command.c - 1.2 cmd/xfsprogs/db/convert.c - 1.2 cmd/xfsprogs/db/convert.h - 1.2 cmd/xfsprogs/db/output.c - 1.2 cmd/xfsprogs/db/output.h - 1.2 cmd/xfsprogs/db/xfs_check.sh - 1.2 cmd/xfsprogs/db/strvec.c - 1.2 cmd/xfsprogs/db/strvec.h - 1.2 cmd/xfsprogs/db/agfl.h - 1.2 cmd/xfsprogs/db/agfl.c - 1.2 cmd/xfsprogs/db/xfs_admin.sh - 1.3 cmd/xfsprogs/db/malloc.c - 1.2 cmd/xfsprogs/db/malloc.h - 1.2 cmd/xfsprogs/db/check.c - 1.6 cmd/xfsprogs/db/check.h - 1.2 cmd/xfsprogs/db/block.c - 1.2 cmd/xfsprogs/db/block.h - 1.2 cmd/xfsprogs/db/main.c - 1.3 cmd/xfsprogs/db/xfs_ncheck64.sh - 1.2 cmd/xfsprogs/db/echo.h - 1.2 cmd/xfsprogs/db/echo.c - 1.2 cmd/xfsprogs/db/io.c - 1.6 cmd/xfsprogs/db/io.h - 1.2 cmd/xfsprogs/install-sh - 1.5 cmd/xfsprogs/Makefile - 1.10 cmd/xfsprogs/doc/Makefile - 1.7 cmd/xfsprogs/man/Makefile - 1.3 cmd/xfsprogs/man/man3/Makefile - 1.2 cmd/xfsprogs/man/man5/Makefile - 1.3 cmd/xfsprogs/man/man8/Makefile - 1.3 cmd/xfsprogs/bmap/Makefile - 1.6 cmd/xfsprogs/bmap/xfs_bmap.c - 1.7 cmd/xfsprogs/fsck/xfs_fsck.c - 1.2 cmd/xfsprogs/fsck/Makefile - 1.5 cmd/xfsprogs/imap/Makefile - 1.2 cmd/xfsprogs/imap/xfs_imap.c - 1.3 cmd/xfsprogs/mkfs/maxtrres.c - 1.3 cmd/xfsprogs/mkfs/fstyp.c - 1.4 cmd/xfsprogs/mkfs/Makefile - 1.10 cmd/xfsprogs/mkfs/proto.c - 1.5 cmd/xfsprogs/mkfs/proto.h - 1.2 cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.26 cmd/xfsprogs/mkfs/xfs_mkfs.h - 1.3 cmd/xfsprogs/rtcp/Makefile - 1.4 cmd/xfsprogs/rtcp/xfs_rtcp.c - 1.5 cmd/xfsprogs/logprint/log_print_all.c - 1.5 cmd/xfsprogs/logprint/log_print_trans.c - 1.5 cmd/xfsprogs/logprint/Makefile - 1.7 cmd/xfsprogs/logprint/logprint.c - 1.7 cmd/xfsprogs/logprint/logprint.h - 1.7 cmd/xfsprogs/logprint/log_misc.c - 1.8 cmd/xfsprogs/libdisk/pttype.c - 1.2 cmd/xfsprogs/libdisk/fstype.c - 1.2 cmd/xfsprogs/libdisk/fstype.h - 1.2 cmd/xfsprogs/libdisk/md.c - 1.4 cmd/xfsprogs/libdisk/drivers.c - 1.5 cmd/xfsprogs/libdisk/Makefile - 1.3 cmd/xfsprogs/libdisk/mountinfo.c - 1.2 cmd/xfsprogs/libdisk/xvm.c - 1.4 cmd/xfsprogs/libdisk/lvm.c - 1.4 cmd/xfsprogs/libdisk/xvm.h - 1.3 cmd/xfsprogs/freeze/Makefile - 1.4 cmd/xfsprogs/freeze/xfs_freeze.c - 1.3 cmd/xfsprogs/growfs/xfs_info.sh - 1.2 cmd/xfsprogs/growfs/xfs_growfs.c - 1.10 cmd/xfsprogs/growfs/Makefile - 1.6 cmd/xfsprogs/build/Makefile - 1.5 cmd/xfsprogs/build/rpm/xfsprogs.spec.in - 1.9 cmd/xfsprogs/build/rpm/Makefile - 1.6 cmd/xfsprogs/build/tar/Makefile - 1.4 cmd/xfsprogs/libxlog/Makefile - 1.3 cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.8 cmd/xfsprogs/libxlog/util.c - 1.2 cmd/xfsprogs/include/xfs_trans_space.h - 1.2 cmd/xfsprogs/include/xfs_log.h - 1.7 cmd/xfsprogs/include/xfs_inum.h - 1.2 cmd/xfsprogs/include/xfs_ialloc.h - 1.2 cmd/xfsprogs/include/xfs_ag.h - 1.7 cmd/xfsprogs/include/xfs_extfree_item.h - 1.2 cmd/xfsprogs/include/xfs_buf_item.h - 1.3 cmd/xfsprogs/include/buildrules - 1.7 cmd/xfsprogs/include/xfs_attr_sf.h - 1.3 cmd/xfsprogs/include/xfs_log_priv.h - 1.6 cmd/xfsprogs/include/xfs_da_btree.h - 1.4 cmd/xfsprogs/include/handle.h - 1.6 cmd/xfsprogs/include/xfs_bit.h - 1.4 cmd/xfsprogs/include/volume.h - 1.3 cmd/xfsprogs/include/xfs_sb.h - 1.3 cmd/xfsprogs/include/xfs_dir2_block.h - 1.3 cmd/xfsprogs/include/xfs_fs.h - 1.14 cmd/xfsprogs/include/xfs_dir.h - 1.2 cmd/xfsprogs/include/xfs_dqblk.h - 1.3 cmd/xfsprogs/include/xfs_arch.h - 1.2 cmd/xfsprogs/include/libxfs.h - 1.10 cmd/xfsprogs/include/xfs_rtalloc.h - 1.2 cmd/xfsprogs/include/fstyp.h - 1.2 cmd/xfsprogs/include/xfs_ialloc_btree.h - 1.2 cmd/xfsprogs/include/xfs_inode_item.h - 1.2 cmd/xfsprogs/include/Makefile - 1.9 cmd/xfsprogs/include/arch.h - 1.4 cmd/xfsprogs/include/dvh.h - 1.2 cmd/xfsprogs/include/mountinfo.h - 1.2 cmd/xfsprogs/include/xfs_log_recover.h - 1.2 cmd/xfsprogs/include/xfs_dquot_item.h - 1.3 cmd/xfsprogs/include/xfs_dfrag.h - 1.2 cmd/xfsprogs/include/libxlog.h - 1.2 cmd/xfsprogs/include/xfs_cred.h - 1.9 cmd/xfsprogs/include/xfs_bmap_btree.h - 1.2 cmd/xfsprogs/include/xfs_dir2_sf.h - 1.3 cmd/xfsprogs/include/xfs_dir_leaf.h - 1.4 cmd/xfsprogs/include/platform_defs.h.in - 1.8 cmd/xfsprogs/include/xfs_mount.h - 1.18 cmd/xfsprogs/include/xfs_btree.h - 1.3 cmd/xfsprogs/include/xfs_dir2_data.h - 1.2 cmd/xfsprogs/include/xfs_inode.h - 1.18 cmd/xfsprogs/include/xfs_dir2_leaf.h - 1.3 cmd/xfsprogs/include/xfs_attr_leaf.h - 1.3 cmd/xfsprogs/include/xfs_types.h - 1.7 cmd/xfsprogs/include/xfs_trans.h - 1.5 cmd/xfsprogs/include/xfs_dir_sf.h - 1.2 cmd/xfsprogs/include/xfs_alloc.h - 1.4 cmd/xfsprogs/include/jdm.h - 1.4 cmd/xfsprogs/include/xqm.h - 1.8 cmd/xfsprogs/include/xfs_imap.h - 1.2 cmd/xfsprogs/include/xfs_bmap.h - 1.2 cmd/xfsprogs/include/xfs_alloc_btree.h - 1.2 cmd/xfsprogs/include/xfs_quota.h - 1.5 cmd/xfsprogs/include/xfs_dir2_node.h - 1.2 cmd/xfsprogs/include/xfs_dir2.h - 1.4 cmd/xfsprogs/include/xfs_dinode.h - 1.4 cmd/xfsprogs/debian/Makefile - 1.6 cmd/xfsprogs/debian/copyright - 1.3 cmd/xfsprogs/repair/bmap.c - 1.2 cmd/xfsprogs/repair/bmap.h - 1.2 cmd/xfsprogs/repair/phase6.c - 1.7 cmd/xfsprogs/repair/phase7.c - 1.2 cmd/xfsprogs/repair/incore_bmc.c - 1.2 cmd/xfsprogs/repair/avl64.c - 1.5 cmd/xfsprogs/repair/avl64.h - 1.3 cmd/xfsprogs/repair/dir2.c - 1.5 cmd/xfsprogs/repair/dir2.h - 1.2 cmd/xfsprogs/repair/sb.c - 1.5 cmd/xfsprogs/repair/dir.c - 1.5 cmd/xfsprogs/repair/dir.h - 1.2 cmd/xfsprogs/repair/phase4.c - 1.6 cmd/xfsprogs/repair/dinode.c - 1.7 cmd/xfsprogs/repair/dinode.h - 1.2 cmd/xfsprogs/repair/phase5.c - 1.2 cmd/xfsprogs/repair/agheader.h - 1.2 cmd/xfsprogs/repair/agheader.c - 1.5 cmd/xfsprogs/repair/dir_stack.c - 1.3 cmd/xfsprogs/repair/dir_stack.h - 1.2 cmd/xfsprogs/repair/init.c - 1.4 cmd/xfsprogs/repair/rt.c - 1.2 cmd/xfsprogs/repair/rt.h - 1.2 cmd/xfsprogs/repair/versions.c - 1.3 cmd/xfsprogs/repair/versions.h - 1.2 cmd/xfsprogs/repair/protos.h - 1.2 cmd/xfsprogs/repair/phase2.c - 1.4 cmd/xfsprogs/repair/globals.c - 1.2 cmd/xfsprogs/repair/globals.h - 1.5 cmd/xfsprogs/repair/phase3.c - 1.4 cmd/xfsprogs/repair/err_protos.h - 1.2 cmd/xfsprogs/repair/incore_ext.c - 1.2 cmd/xfsprogs/repair/Makefile - 1.7 cmd/xfsprogs/repair/phase1.c - 1.2 cmd/xfsprogs/repair/xfs_repair.c - 1.6 cmd/xfsprogs/repair/dino_chunks.c - 1.4 cmd/xfsprogs/repair/incore.h - 1.3 cmd/xfsprogs/repair/incore.c - 1.2 cmd/xfsprogs/repair/avl.c - 1.5 cmd/xfsprogs/repair/avl.h - 1.3 cmd/xfsprogs/repair/incore_ino.c - 1.4 cmd/xfsprogs/repair/scan.h - 1.2 cmd/xfsprogs/repair/scan.c - 1.3 cmd/xfsprogs/repair/attr_repair.h - 1.6 cmd/xfsprogs/repair/attr_repair.c - 1.9 cmd/xfsprogs/repair/io.c - 1.4 cmd/xfsprogs/libhandle/handle.c - 1.9 cmd/xfsprogs/libhandle/Makefile - 1.7 cmd/xfsprogs/libhandle/jdm.c - 1.5 cmd/xfsprogs/libxfs/xfs_ialloc.c - 1.11 cmd/xfsprogs/libxfs/rdwr.c - 1.6 cmd/xfsprogs/libxfs/xfs_da_btree.c - 1.11 cmd/xfsprogs/libxfs/logitem.c - 1.3 cmd/xfsprogs/libxfs/xfs.h - 1.18 cmd/xfsprogs/libxfs/xfs_bit.c - 1.5 cmd/xfsprogs/libxfs/trans.c - 1.4 cmd/xfsprogs/libxfs/init.c - 1.16 cmd/xfsprogs/libxfs/xfs_dir2_block.c - 1.5 cmd/xfsprogs/libxfs/xfs_dir.c - 1.4 cmd/xfsprogs/libxfs/xfs_rtalloc.c - 1.7 cmd/xfsprogs/libxfs/xfs_ialloc_btree.c - 1.3 cmd/xfsprogs/libxfs/Makefile - 1.9 cmd/xfsprogs/libxfs/xfs_bmap_btree.c - 1.7 cmd/xfsprogs/libxfs/xfs_dir2_sf.c - 1.4 cmd/xfsprogs/libxfs/xfs_dir_leaf.c - 1.6 cmd/xfsprogs/libxfs/xfs_mount.c - 1.6 cmd/xfsprogs/libxfs/xfs_rtbit.c - 1.4 cmd/xfsprogs/libxfs/xfs_btree.c - 1.7 cmd/xfsprogs/libxfs/xfs_dir2_data.c - 1.4 cmd/xfsprogs/libxfs/xfs_inode.c - 1.9 cmd/xfsprogs/libxfs/xfs_dir2_leaf.c - 1.4 cmd/xfsprogs/libxfs/xfs_attr_leaf.c - 1.3 cmd/xfsprogs/libxfs/util.c - 1.6 cmd/xfsprogs/libxfs/xfs_trans.c - 1.2 cmd/xfsprogs/libxfs/xfs_alloc.c - 1.11 cmd/xfsprogs/libxfs/xfs_bmap.c - 1.11 cmd/xfsprogs/libxfs/xfs_alloc_btree.c - 1.4 cmd/xfsprogs/libxfs/xfs_dir2_node.c - 1.5 cmd/xfsprogs/libxfs/xfs_dir2.c - 1.4 cmd/xfsprogs/mkfile/xfs_mkfile.c - 1.8 cmd/xfsprogs/mkfile/Makefile - 1.5 cmd/xfsdump/install-sh - 1.5 cmd/xfsdump/Makefile - 1.6 cmd/xfsdump/doc/Makefile - 1.5 cmd/xfsdump/fsr/xfs_fsr.c - 1.9 cmd/xfsdump/fsr/Makefile - 1.4 cmd/xfsdump/man/Makefile - 1.2 cmd/xfsdump/man/man8/Makefile - 1.2 cmd/xfsdump/copy/xfs_copy.c - 1.4 cmd/xfsdump/copy/locks.h - 1.3 cmd/xfsdump/copy/locks.c - 1.2 cmd/xfsdump/copy/Makefile - 1.5 cmd/xfsdump/dump/var.c - 1.4 cmd/xfsdump/dump/var.h - 1.3 cmd/xfsdump/dump/Makefile - 1.10 cmd/xfsdump/dump/getopt.h - 1.6 cmd/xfsdump/dump/content.c - 1.20 cmd/xfsdump/dump/hsmapi.h - 1.2 cmd/xfsdump/dump/hsmapi.c - 1.3 cmd/xfsdump/dump/inomap.h - 1.3 cmd/xfsdump/dump/inomap.c - 1.14 cmd/xfsdump/quota/xfsdq.c - 1.7 cmd/xfsdump/quota/Makefile - 1.4 cmd/xfsdump/quota/xfsrq.sh - 1.3 cmd/xfsdump/build/Makefile - 1.4 cmd/xfsdump/build/rpm/Makefile - 1.5 cmd/xfsdump/build/rpm/xfsdump.spec.in - 1.7 cmd/xfsdump/build/tar/Makefile - 1.3 cmd/xfsdump/include/buildrules - 1.4 cmd/xfsdump/include/Makefile - 1.4 cmd/xfsdump/restore/mmap.h - 1.2 cmd/xfsdump/restore/mmap.c - 1.2 cmd/xfsdump/restore/namreg.h - 1.2 cmd/xfsdump/restore/namreg.c - 1.3 cmd/xfsdump/restore/node.c - 1.3 cmd/xfsdump/restore/node.h - 1.3 cmd/xfsdump/restore/tree.c - 1.14 cmd/xfsdump/restore/tree.h - 1.3 cmd/xfsdump/restore/bag.c - 1.2 cmd/xfsdump/restore/bag.h - 1.2 cmd/xfsdump/restore/Makefile - 1.10 cmd/xfsdump/restore/getopt.h - 1.4 cmd/xfsdump/restore/content.c - 1.20 cmd/xfsdump/restore/dirattr.h - 1.3 cmd/xfsdump/restore/dirattr.c - 1.4 cmd/xfsdump/restore/win.c - 1.4 cmd/xfsdump/restore/win.h - 1.3 cmd/xfsdump/restore/inomap.h - 1.2 cmd/xfsdump/restore/inomap.c - 1.2 cmd/xfsdump/debian/Makefile - 1.4 cmd/xfsdump/debian/copyright - 1.2 cmd/xfsdump/invutil/Makefile - 1.5 cmd/xfsdump/invutil/invutil.c - 1.6 cmd/xfsdump/inventory/inv_core.c - 1.2 cmd/xfsdump/inventory/testmain.c - 1.2 cmd/xfsdump/inventory/inv_oref.h - 1.2 cmd/xfsdump/inventory/inv_oref.c - 1.3 cmd/xfsdump/inventory/inv_priv.h - 1.4 cmd/xfsdump/inventory/inv_stobj.c - 1.5 cmd/xfsdump/inventory/inv_mgr.c - 1.4 cmd/xfsdump/inventory/Makefile - 1.4 cmd/xfsdump/inventory/inventory.h - 1.4 cmd/xfsdump/inventory/getopt.h - 1.2 cmd/xfsdump/inventory/inv_fstab.c - 1.2 cmd/xfsdump/inventory/inv_files.c - 1.2 cmd/xfsdump/inventory/inv_api.c - 1.5 cmd/xfsdump/inventory/inv_idx.c - 1.3 cmd/xfsdump/librmt/rmtdev.c - 1.2 cmd/xfsdump/librmt/rmtopen.c - 1.9 cmd/xfsdump/librmt/rmtmsg.c - 1.3 cmd/xfsdump/librmt/rmtwrite.c - 1.2 cmd/xfsdump/librmt/rmtfstat.c - 1.2 cmd/xfsdump/librmt/rmtabort.c - 1.3 cmd/xfsdump/librmt/rmtcreat.c - 1.2 cmd/xfsdump/librmt/isrmt.c - 1.2 cmd/xfsdump/librmt/rmtclose.c - 1.2 cmd/xfsdump/librmt/rmtcommand.c - 1.3 cmd/xfsdump/librmt/rmtlib.h - 1.4 cmd/xfsdump/librmt/rmtisatty.c - 1.2 cmd/xfsdump/librmt/Makefile - 1.6 cmd/xfsdump/librmt/rmtioctl.c - 1.6 cmd/xfsdump/librmt/rmtread.c - 1.2 cmd/xfsdump/librmt/rmtstatus.c - 1.2 cmd/xfsdump/librmt/rmtaccess.c - 1.2 cmd/xfsdump/librmt/rmtlseek.c - 1.2 cmd/xfsdump/estimate/Makefile - 1.4 cmd/xfsdump/estimate/xfs_estimate.c - 1.3 cmd/xfsdump/common/namreg.h - 1.2 cmd/xfsdump/common/namreg.c - 1.2 cmd/xfsdump/common/content_common.h - 1.2 cmd/xfsdump/common/content_common.c - 1.3 cmd/xfsdump/common/content_inode.h - 1.3 cmd/xfsdump/common/stream.c - 1.7 cmd/xfsdump/common/stream.h - 1.3 cmd/xfsdump/common/global.h - 1.3 cmd/xfsdump/common/global.c - 1.3 cmd/xfsdump/common/openutil.h - 1.2 cmd/xfsdump/common/openutil.c - 1.3 cmd/xfsdump/common/drive.c - 1.4 cmd/xfsdump/common/drive.h - 1.2 cmd/xfsdump/common/fs.c - 1.3 cmd/xfsdump/common/fs.h - 1.2 cmd/xfsdump/common/types.h - 1.6 cmd/xfsdump/common/exit.h - 1.2 cmd/xfsdump/common/sproc.c - 1.2 cmd/xfsdump/common/sproc.h - 1.2 cmd/xfsdump/common/getdents.h - 1.2 cmd/xfsdump/common/getdents.c - 1.6 cmd/xfsdump/common/cleanup.h - 1.2 cmd/xfsdump/common/cleanup.c - 1.2 cmd/xfsdump/common/mlog.h - 1.5 cmd/xfsdump/common/mlog.c - 1.9 cmd/xfsdump/common/dlog.c - 1.4 cmd/xfsdump/common/dlog.h - 1.3 cmd/xfsdump/common/ring.c - 1.2 cmd/xfsdump/common/ring.h - 1.3 cmd/xfsdump/common/media.h - 1.2 cmd/xfsdump/common/media.c - 1.2 cmd/xfsdump/common/Makefile - 1.9 cmd/xfsdump/common/inventory.c - 1.3 cmd/xfsdump/common/inventory.h - 1.4 cmd/xfsdump/common/path.c - 1.2 cmd/xfsdump/common/path.h - 1.2 cmd/xfsdump/common/arch_xlate.c - 1.6 cmd/xfsdump/common/arch_xlate.h - 1.3 cmd/xfsdump/common/drive_scsitape.c - 1.6 cmd/xfsdump/common/content.h - 1.3 cmd/xfsdump/common/lock.c - 1.2 cmd/xfsdump/common/lock.h - 1.2 cmd/xfsdump/common/qlock.c - 1.4 cmd/xfsdump/common/qlock.h - 1.2 cmd/xfsdump/common/util.h - 1.3 cmd/xfsdump/common/util.c - 1.8 cmd/xfsdump/common/rec_hdr.h - 1.2 cmd/xfsdump/common/cldmgr.c - 1.6 cmd/xfsdump/common/cldmgr.h - 1.2 cmd/xfsdump/common/drive_minrmt.c - 1.6 cmd/xfsdump/common/main.c - 1.19 cmd/xfsdump/common/media_rmvtape.h - 1.2 cmd/xfsdump/common/drive_simple.c - 1.4 cmd/xfstests/common.rc - 1.15 cmd/xfstests/001 - 1.2 cmd/xfstests/002 - 1.2 cmd/xfstests/003 - 1.2 cmd/xfstests/004 - 1.5 cmd/xfstests/005 - 1.4 cmd/xfstests/006 - 1.2 cmd/xfstests/007 - 1.2 cmd/xfstests/008 - 1.5 cmd/xfstests/009 - 1.5 cmd/xfstests/010 - 1.4 cmd/xfstests/011 - 1.2 cmd/xfstests/012 - 1.2 cmd/xfstests/013 - 1.3 cmd/xfstests/014 - 1.2 cmd/xfstests/015 - 1.5 cmd/xfstests/016 - 1.7 cmd/xfstests/017 - 1.6 cmd/xfstests/018 - 1.11 cmd/xfstests/019 - 1.4 cmd/xfstests/020 - 1.7 cmd/xfstests/021 - 1.9 cmd/xfstests/022 - 1.3 cmd/xfstests/023 - 1.3 cmd/xfstests/024 - 1.5 cmd/xfstests/025 - 1.3 cmd/xfstests/026 - 1.2 cmd/xfstests/027 - 1.2 cmd/xfstests/028 - 1.4 cmd/xfstests/029 - 1.4 cmd/xfstests/030 - 1.5 cmd/xfstests/031 - 1.6 cmd/xfstests/032 - 1.4 cmd/xfstests/033 - 1.5 cmd/xfstests/034 - 1.4 cmd/xfstests/035 - 1.3 cmd/xfstests/036 - 1.2 cmd/xfstests/037 - 1.2 cmd/xfstests/038 - 1.2 cmd/xfstests/039 - 1.2 cmd/xfstests/040 - 1.4 cmd/xfstests/041 - 1.9 cmd/xfstests/042 - 1.8 cmd/xfstests/043 - 1.4 cmd/xfstests/044 - 1.8 cmd/xfstests/045 - 1.4 cmd/xfstests/046 - 1.2 cmd/xfstests/047 - 1.4 cmd/xfstests/048 - 1.2 cmd/xfstests/049 - 1.4 cmd/xfstests/050 - 1.12 cmd/xfstests/051 - 1.16 cmd/xfstests/052 - 1.5 cmd/xfstests/053 - 1.5 cmd/xfstests/054 - 1.6 cmd/xfstests/055 - 1.3 cmd/xfstests/056 - 1.3 cmd/xfstests/057 - 1.7 cmd/xfstests/058 - 1.4 cmd/xfstests/059 - 1.2 cmd/xfstests/060 - 1.2 cmd/xfstests/061 - 1.3 cmd/xfstests/062 - 1.14 cmd/xfstests/063 - 1.2 cmd/xfstests/064 - 1.5 cmd/xfstests/common.quota - 1.11 cmd/xfstests/common.filter - 1.2 cmd/xfstests/remake - 1.2 cmd/xfstests/install-sh - 1.2 cmd/xfstests/common.config - 1.18 cmd/xfstests/common.repair - 1.3 cmd/xfstests/check - 1.6 cmd/xfstests/Makefile - 1.4 cmd/xfstests/common.attr - 1.5 cmd/xfstests/common.dump - 1.37 cmd/xfstests/common - 1.3 cmd/xfstests/new - 1.3 cmd/xfstests/soak - 1.3 cmd/xfstests/src/devzero.c - 1.3 cmd/xfstests/src/acl_test.c - 1.6 cmd/xfstests/src/fault.c - 1.3 cmd/xfstests/src/usemem.c - 1.2 cmd/xfstests/src/dbtest.c - 1.2 cmd/xfstests/src/bstat.c - 1.3 cmd/xfstests/src/global.h - 1.3 cmd/xfstests/src/truncfile.c - 1.3 cmd/xfstests/src/permname.c - 1.2 cmd/xfstests/src/fill2.c - 1.4 cmd/xfstests/src/runas.c - 1.3 cmd/xfstests/src/fill2fs - 1.6 cmd/xfstests/src/alloc.c - 1.3 cmd/xfstests/src/randholes.c - 1.4 cmd/xfstests/src/holes.c - 1.3 cmd/xfstests/src/fill2fs_check - 1.4 cmd/xfstests/src/Makefile - 1.9 cmd/xfstests/src/loggen.c - 1.3 cmd/xfstests/src/nametest.c - 1.4 cmd/xfstests/src/fill2attr - 1.2 cmd/xfstests/src/acl_get.c - 1.8 cmd/xfstests/src/ioctl.c - 1.3 cmd/xfstests/src/lstat64.c - 1.4 cmd/xfstests/src/feature.c - 1.5 cmd/xfstests/src/fsstress.c - 1.5 cmd/xfstests/src/fill.c - 1.2 cmd/xfstests/src/dirstress.c - 1.2 cmd/xfstests/include/buildrules - 1.2 cmd/xfstests/include/Makefile - 1.2 cmd/xfstests/include/builddefs.in - 1.6 cmd/xfstests/crash/xfscrash - 1.2 cmd/xfstests/crash/rc.sysinit - 1.2 cmd/xfstests/dmapi/README - 1.2 cmd/xfstests/dmapi/src/suite2/README - 1.2 cmd/xfstests/dmapi/src/suite2/README_for_check_dmapi - 1.2 cmd/xfstests/dmapi/src/suite2/menu_test - 1.2 cmd/xfstests/dmapi/src/suite2/DMAPI_aliases - 1.2 cmd/xfstests/dmapi/src/suite2/create_cpio - 1.2 cmd/xfstests/dmapi/src/suite2/lib/errtest.h - 1.2 cmd/xfstests/dmapi/src/suite2/src/mmap.c - 1.3 cmd/xfstests/dmapi/src/suite2/src/test_hole.c - 1.5 cmd/xfstests/dmapi/src/suite2/src/Makefile.am - 1.3 cmd/xfstests/dmapi/src/suite2/src/send_msg.c - 1.4 cmd/xfstests/dmapi/src/suite2/src/mm_fill.c - 1.2 cmd/xfstests/dmapi/src/suite2/src/region_test.c - 1.4 cmd/xfstests/dmapi/src/suite2/src/check_dmapi.c - 1.5 cmd/xfstests/dmapi/src/suite2/src/test_dmattr.c - 1.5 cmd/xfstests/dmapi/src/suite2/src/test_rights.c - 1.5 cmd/xfstests/dmapi/src/suite2/src/test_invis.c - 1.5 cmd/xfstests/dmapi/src/suite2/src/test_efault.c - 1.4 cmd/xfstests/dmapi/src/suite2/src/test_region.c - 1.4 cmd/xfstests/dmapi/src/suite2/src/invis_test.c - 1.5 cmd/xfstests/dmapi/src/suite2/src/dump_allocinfo.c - 1.2 cmd/xfstests/dmapi/src/suite2/src/mmap_cp.c - 1.2 cmd/xfstests/dmapi/src/suite2/src/test_fileattr.c - 1.5 cmd/xfstests/dmapi/src/suite2/src/test_eventlist.c - 1.4 cmd/xfstests/dmapi/src/suite2/data/pending.dat - 1.2 cmd/xfstests/dmapi/src/suite2/data/nfs.dat - 1.2 cmd/xfstests/dmapi/src/suite2/data/fail.dat - 1.2 cmd/xfstests/dmapi/src/suite2/data/pending_nfs.dat - 1.2 cmd/xfstests/dmapi/src/suite2/data/smallq.dat - 1.2 cmd/xfstests/dmapi/src/suite2/data/main.dat - 1.2 cmd/xfstests/dmapi/src/suite2/data/standard.dat - 1.2 cmd/xfstests/dmapi/src/suite2/data/realtime.dat - 1.2 cmd/xfstests/dmapi/src/suite2/data/standard_nfs.dat - 1.2 cmd/xfstests/dmapi/src/suite2/dist/README - 1.2 cmd/xfstests/dmapi/src/suite2/bindir/make_holey - 1.2 cmd/xfstests/dmapi/src/suite2/bindir/run_test - 1.2 cmd/xfstests/dmapi/src/suite2/bindir/ctf - 1.2 cmd/xfstests/dmapi/src/suite2/bindir/stf - 1.2 cmd/xfstests/dmapi/src/suite2/bindir/crttf - 1.2 cmd/xfstests/dmapi/src/suite2/bindir/test_allocinfo_2 - 1.2 cmd/xfstests/dmapi/src/suite2/bindir/test_allocinfo_1 - 1.2 cmd/xfstests/dmapi/src/suite1/function_coverage - 1.2 cmd/xfstests/dmapi/src/suite1/cmd/handle_to_path.c - 1.7 cmd/xfstests/dmapi/src/suite1/cmd/probe_hole.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/Makefile.am - 1.2 cmd/xfstests/dmapi/src/suite1/cmd/downgrade_right.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/request_right.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/query_right.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/upgrade_right.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/security_hole.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/respond_event.c - 1.6 cmd/xfstests/dmapi/src/suite1/cmd/test_assumption.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/dm_handle.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/path_to_fshandle.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/remove_dmattr.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/rwt.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/getall_dmattr.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/obj_ref_hold.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/set_disp.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/obj_ref_rele.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/security_hole2.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/make_rt_sparse.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/create_userevent.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/getall_disp.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/get_dmattr.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/handle_to_fshandle.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/get_mountinfo.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/punch_hole.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/release_right.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/pending.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/obj_ref_query.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/link_test.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/print_fshandle.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/make_sparse.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/struct_test.c - 1.5 cmd/xfstests/dmapi/src/suite1/cmd/get_region.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/fd_to_handle.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/randomize_file.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/set_eventlist.c - 1.6 cmd/xfstests/dmapi/src/suite1/cmd/get_eventlist.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/set_dmattr.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/get_config_events.c - 1.5 cmd/xfstests/dmapi/src/suite1/cmd/get_fileattr.c - 1.6 cmd/xfstests/dmapi/src/suite1/cmd/set_fileattr.c - 1.6 cmd/xfstests/dmapi/src/suite1/cmd/get_allocinfo.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/init_service.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/get_dirattrs.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/path_to_handle.c - 1.3 cmd/xfstests/dmapi/src/suite1/cmd/sync_by_handle.c - 1.4 cmd/xfstests/dmapi/src/suite1/cmd/get_events.c - 1.4 cmd/xfstests/dmapi/src/simple/Makefile.am - 1.2 cmd/xfstests/dmapi/src/simple/dm_getall_tokens.c - 1.5 cmd/xfstests/dmapi/src/simple/dm_create_session.c - 1.5 cmd/xfstests/dmapi/src/simple/dm_getall_sessions.c - 1.5 cmd/xfstests/dmapi/src/simple/dm_destroy_session.c - 1.5 cmd/xfstests/dmapi/src/simple/dm_find_eventmsg.c - 1.5 cmd/xfstests/dmapi/src/simple/dm_query_session.c - 1.5 cmd/xfstests/dmapi/src/sample_hsm/Makefile.am - 1.3 cmd/xfstests/dmapi/src/common/cmd/Makefile.am - 1.3 cmd/xfstests/dmapi/src/common/cmd/set_region.c - 1.5 cmd/xfstests/dmapi/src/common/cmd/read_invis.c - 1.5 cmd/xfstests/dmapi/src/common/cmd/write_invis.c - 1.5 cmd/xfstests/dmapi/src/common/cmd/handle_write_invis.c - 1.3 cmd/xfstests/dmapi/src/common/cmd/set_return_on_destroy.c - 1.7 cmd/xfstests/dmapi/src/common/cmd/handle_read_invis.c - 1.3 cmd/xfstests/dmapi/src/common/lib/Makefile.am - 1.2 cmd/xfstests/dmapi/src/common/lib/dmport.h - 1.3 cmd/xfstests/dmapi/src/common/lib/print.c - 1.4 cmd/xfstests/dmapi/src/common/lib/stubs.c - 1.2 cmd/xfstests/dmapi/src/common/lib/find_session.c - 1.4 cmd/xfstests/tools/db-walk - 1.2 cmd/xfstests/tools/fs-walk - 1.2 cmd/xfstests/tools/auto-qa - 1.31 cmd/dmapi/install-sh - 1.6 cmd/dmapi/Makefile - 1.4 cmd/dmapi/doc/Makefile - 1.4 cmd/dmapi/man/Makefile - 1.2 cmd/dmapi/man/man3/Makefile - 1.2 cmd/dmapi/build/Makefile - 1.4 cmd/dmapi/build/rpm/Makefile - 1.5 cmd/dmapi/build/rpm/dmapi.spec.in - 1.7 cmd/dmapi/build/tar/Makefile - 1.3 cmd/dmapi/include/dmapi_kern.h - 1.4 cmd/dmapi/include/buildrules - 1.6 cmd/dmapi/include/Makefile - 1.4 cmd/dmapi/include/dmapi.h - 1.5 cmd/dmapi/debian/Makefile - 1.3 cmd/dmapi/debian/copyright - 1.3 cmd/dmapi/libdm/dm_handle2path.c - 1.8 cmd/dmapi/libdm/dm_bulkattr.c - 1.4 cmd/dmapi/libdm/dm_session.c - 1.4 cmd/dmapi/libdm/dm_handle.c - 1.5 cmd/dmapi/libdm/dmapi_lib.h - 1.3 cmd/dmapi/libdm/dmapi_lib.c - 1.8 cmd/dmapi/libdm/dm_dmattr.c - 1.4 cmd/dmapi/libdm/Makefile - 1.8 cmd/dmapi/libdm/dm_mountinfo.c - 1.4 cmd/dmapi/libdm/dm_region.c - 1.4 cmd/dmapi/libdm/dm_hole.c - 1.4 cmd/dmapi/libdm/dm_config.c - 1.4 cmd/dmapi/libdm/dm_event.c - 1.4 cmd/dmapi/libdm/dm_right.c - 1.4 cmd/dmapi/libdm/dm_attr.c - 1.4 cmd/dmapi/libdm/dm_rdwr.c - 1.4 cmd/xfsprogs/db/text.h - 1.2 cmd/xfsprogs/db/text.c - 1.2 cmd/xfstests/065 - 1.6 cmd/xfsmisc/2.4.18-pre3-ac2-quotactl.patch - 1.3 cmd/attr/libattr/syscalls.c - 1.10 cmd/attr/test/Makefile - 1.3 cmd/attr/setfattr/setfattr.c - 1.7 cmd/attr/setfattr/Makefile - 1.3 cmd/attr/man/man5/Makefile - 1.5 cmd/attr/getfattr/Makefile - 1.4 cmd/attr/getfattr/getfattr.c - 1.13 cmd/attr/include/xattr.h - 1.4 cmd/attr/libattr/libattr.c - 1.3 cmd/acl/setfacl/Makefile - 1.5 cmd/acl/getfacl/Makefile - 1.5 cmd/acl/test/Makefile - 1.3 cmd/attr/doc/ea-conv/Makefile - 1.2 cmd/xfsmisc/2.4-xattr.patch - 1.4 cmd/acl/po/Makefile - 1.2 cmd/acl/examples/Makefile - 1.2 cmd/xfstests/066 - 1.6 cmd/xfstests/067 - 1.3 cmd/Makefile - 1.2 cmd/xfsdump/include/quotaio_xfs.h - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jun 4 11:55:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54ItXnC003823 for ; Tue, 4 Jun 2002 11:55:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54ItXhM003822 for linux-xfs-outgoing; Tue, 4 Jun 2002 11:55:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54ItLnC003781 for ; Tue, 4 Jun 2002 11:55:25 -0700 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 17FJUQ-000312-00 for ; Tue, 04 Jun 2002 20:57:06 +0200 Message-ID: <3CFD0DE8.9020405@st-peter.stw.uni-erlangen.de> Date: Tue, 04 Jun 2002 20:58:48 +0200 From: Svetoslav Slavtchev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: [2.5.20-dj1]ld: cannot open xfs_dmapi/built-in.o: No such file or directory Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *17FJUQ-000312-00*epUF/9JEO/c* (Studentenwohnanlage Nuernberg St.-Peter) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi so the subject says it almost all i'm getting this error message : ####################################################################### make[2]: Leaving directory `/usr/src/linux-2.5.20-dj1-lvm-xfs-w1/fs/xfs' make[2]: Entering directory `/usr/src/linux-2.5.20-dj1-lvm-xfs-w1/fs/xfs_dmapi' make[2]: Nothing to be done for `first_rule'. make[2]: Leaving directory `/usr/src/linux-2.5.20-dj1-lvm-xfs-w1/fs/xfs_dmapi' ld -m elf_i386 -r -o fs.o open.o read_write.o devices.o file_table.o buffer.o bio.o super.o block_dev.o char_dev.o stat.o exec.o pipe.o namei.o fcntl.o ioctl.o readdir.o select.o fifo.o locks.o dcache.o inode.o attr.o bad_inode.o file.o iobuf.o dnotify.o filesystems.o namespace.o seq_file.o xattr.o libfs.o fs-writeback.o mpage.o nfsctl.o binfmt_script.o binfmt_elf.o dquot.o quota_v2.o quota.o proc/built-in.o partitions/built-in.o driverfs/built-in.o ext3/built-in.o jbd/built-in.o ext2/built-in.o ramfs/built-in.o isofs/built-in.o devfs/built-in.o nls/built-in.o autofs4/built-in.o reiserfs/built-in.o devpts/built-in.o xfs_dmapi/built-in.o xfs/built-in.o ld: cannot open xfs_dmapi/built-in.o: No such file or directory make[1]: *** [fs.o] Error 1 make[1]: Leaving directory `/usr/src/linux-2.5.20-dj1-lvm-xfs-w1/fs' make: *** [fs] Error 2 [root@svetljo linux-2.5.20-dj1-lvm-xfs-w1] ######################################################## am i doing smth wrong or it comes from the dj tree regards svetljo From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:05:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54J5lnC002232 for ; Tue, 4 Jun 2002 12:05:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54J5lv7002231 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:05:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54J5QnC002178 for ; Tue, 4 Jun 2002 12:05:27 -0700 Received: from [64.32.179.242] (HELO awm-laptop) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 30144463; Tue, 04 Jun 2002 11:59:41 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects To: Greg Freemyer Subject: Re: re[4]: Which Kernel for XFS Date: Tue, 4 Jun 2002 15:11:17 -0400 User-Agent: KMail/1.4.1 Cc: linux-xfs References: <20020604170528.WVJP1202.imf01bis.bellsouth.net@taz> In-Reply-To: <20020604170528.WVJP1202.imf01bis.bellsouth.net@taz> MIME-Version: 1.0 Message-Id: <200206041511.17461.anthony@AWMObjects.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54J5RnC002180 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Anthony, > > The notes at > ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/people/mantel/ne >xt/kernel-source.changes give you some of what you are asking about. > > Per the above, it is based on the 2.4.19-pre8aa1 kernel. I believe that > already has the XFS patches in it, so you could look into what it has. > Greg, That document was missing from the SuSE ftp site. Thanks for the link. > For details, I guess you need to download the source RPM and read the > specfile. I have the source however where should I look to find the XFS versions? I looked somewhat at "/usr/src/linux/fs/xfs *.c/*.h" but didn't see anything. Thank You Very Much! Anthony > Greg > > >> > Since you are using a SuSE distribution, have you thought about > >> > using > >> > >> the > >> > >> > SuSE experimental kernel from > >> > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ > >> > > >> > It has all the standard SuSE patches and includes a relatively > >> > recent > >> > >> XFS. > >> > >> > Possibly XFS v1.1, but I'm not sure. > >> > >> I have the Mantel's latest kernel installed on my laptop however I'm > >> not certain what it is that I have. What I mean by that is how do I > >> find out what XFS version and patch level do I have so that I can > >> decide on patch upgrades? I know it says kernel 2.4.18 however is it > >> really 2.4.19 pre... . > >> As you can see, I'm not certain of the versions and patch levels > >> contained > >> > >> within the Mantel stuff. > >> > >> Anthony > >> > >> > FYI: The stock SuSE 8.0 kernel also has XFS support, but the ACL > >> > >> handling > >> > >> > is broken in such a way that xfsdump/xfsrestore don't handle ACLs > >> > correctly. > >> > > >> > Greg Freemyer > >> > Internet Engineer > >> > Deployment and Integration Specialist > >> > Compaq ASE - Tru64 > >> > Compaq Master ASE - SAN Architect > >> > The Norcross Group > >> > www.NorcrossGroup.com > >> > > >> > >> Steve, > >> > >> What do you recommend that I use since the box I'm building is > >> > >> a development > >> > >> box for myself which I will be using for development purposes > >> > >> and > >> > >> thus > >> > >> > >> will > >> > >> be using other cvs sources from other opesource projects as > >> > >> well? > >> > >> > >> > >> Anthony > >> > >> > >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: > >> > >> > > I'm building/setting-up a new server SuSE 7.3 which will > >> > >> include > >> > >> > >> > > 3ware (7810) ide raid (10 or 5) with brand new drives and > >> > >> > > most likely LVM > >> > >> > >> > >> too. > >> > >> > >> > >> > > Should I get the kernel from oss.sgi.com cvs > >> > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" linux-2.4-xfs) or > >> > >> > > is there another location/process that I should entertain? > >> > >> > > Also > >> > >> what > >> > >> > >> > > kernel release does the oss.sgi.com cvs sources give me? > >> > >> > > > >> > >> > > Thank You, > >> > >> > > Anthony > >> > >> > > >> > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb (which > >> > >> > you probably do not care about). There are fixes in this tree > >> > >> > which > >> > >> are > >> > >> > >> > not available anywhere else, it is the most direct link to > >> > >> > XFS development. Of course this also possibly means there are > >> > >> > bugs in this tree which are not available anywhere else. > >> > >> > > >> > >> > Steve > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:09:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54J9JnC002414 for ; Tue, 4 Jun 2002 12:09:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54J9JNo002413 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:09:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54J92nC002384 for ; Tue, 4 Jun 2002 12:09:02 -0700 Received: from [64.32.179.242] (HELO awm-laptop) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 33137326; Tue, 04 Jun 2002 12:02:35 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects To: Greg Freemyer Subject: Re: re[4]: Which Kernel for XFS Date: Tue, 4 Jun 2002 15:14:52 -0400 User-Agent: KMail/1.4.1 Cc: linux-xfs References: <20020604170528.WVJP1202.imf01bis.bellsouth.net@taz> In-Reply-To: <20020604170528.WVJP1202.imf01bis.bellsouth.net@taz> MIME-Version: 1.0 Message-Id: <200206041514.52842.anthony@AWMObjects.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54J92nC002385 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Greg, Are there any advantages to me using the Mantel/SuSE kernel over the latest sources from sgi? Thanks, Anthon > Anthony, > > The notes at > ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/people/mantel/ne >xt/kernel-source.changes give you some of what you are asking about. > > Per the above, it is based on the 2.4.19-pre8aa1 kernel. I believe that > already has the XFS patches in it, so you could look into what it has. > > For details, I guess you need to download the source RPM and read the > specfile. > > Greg > > >> > Since you are using a SuSE distribution, have you thought about > >> > using > >> > >> the > >> > >> > SuSE experimental kernel from > >> > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ > >> > > >> > It has all the standard SuSE patches and includes a relatively > >> > recent > >> > >> XFS. > >> > >> > Possibly XFS v1.1, but I'm not sure. > >> > >> I have the Mantel's latest kernel installed on my laptop however I'm > >> not certain what it is that I have. What I mean by that is how do I > >> find out what XFS version and patch level do I have so that I can > >> decide on patch upgrades? I know it says kernel 2.4.18 however is it > >> really 2.4.19 pre... . > >> As you can see, I'm not certain of the versions and patch levels > >> contained > >> > >> within the Mantel stuff. > >> > >> Anthony > >> > >> > FYI: The stock SuSE 8.0 kernel also has XFS support, but the ACL > >> > >> handling > >> > >> > is broken in such a way that xfsdump/xfsrestore don't handle ACLs > >> > correctly. > >> > > >> > Greg Freemyer > >> > Internet Engineer > >> > Deployment and Integration Specialist > >> > Compaq ASE - Tru64 > >> > Compaq Master ASE - SAN Architect > >> > The Norcross Group > >> > www.NorcrossGroup.com > >> > > >> > >> Steve, > >> > >> What do you recommend that I use since the box I'm building is > >> > >> a development > >> > >> box for myself which I will be using for development purposes > >> > >> and > >> > >> thus > >> > >> > >> will > >> > >> be using other cvs sources from other opesource projects as > >> > >> well? > >> > >> > >> > >> Anthony > >> > >> > >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: > >> > >> > > I'm building/setting-up a new server SuSE 7.3 which will > >> > >> include > >> > >> > >> > > 3ware (7810) ide raid (10 or 5) with brand new drives and > >> > >> > > most likely LVM > >> > >> > >> > >> too. > >> > >> > >> > >> > > Should I get the kernel from oss.sgi.com cvs > >> > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" linux-2.4-xfs) or > >> > >> > > is there another location/process that I should entertain? > >> > >> > > Also > >> > >> what > >> > >> > >> > > kernel release does the oss.sgi.com cvs sources give me? > >> > >> > > > >> > >> > > Thank You, > >> > >> > > Anthony > >> > >> > > >> > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb (which > >> > >> > you probably do not care about). There are fixes in this tree > >> > >> > which > >> > >> are > >> > >> > >> > not available anywhere else, it is the most direct link to > >> > >> > XFS development. Of course this also possibly means there are > >> > >> > bugs in this tree which are not available anywhere else. > >> > >> > > >> > >> > Steve > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:22:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JMjnC002834 for ; Tue, 4 Jun 2002 12:22:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JMjfI002833 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:22:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.168]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JManC002799 for ; Tue, 4 Jun 2002 12:22:37 -0700 Received: (qmail 8309 invoked by uid 500); 4 Jun 2002 19:24:16 -0000 Subject: Can I make my blocksize > 4k during mkfs.xfs? From: Austin Gonyou To: linux-xfs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-encrypted"; boundary="=-rynb/29xXRYVc674bWER" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jun 2002 14:24:16 -0500 Message-Id: <1023218656.7905.19.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=0.5 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-rynb/29xXRYVc674bWER Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I would like to have 8k blocks..instead of 4k blocks. I didn't see anything in the manpages..and I'm assuming it's not possible..but I thought I'd ask. I want to try to do a 1:1 test with Veritas. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-rynb/29xXRYVc674bWER Content-Type: application/pgp-encrypted; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8/RPg94g6ZVmFMoIRAi5lAKCBKrx+pIr59M1lUx7o0p1h86c5twCgyfU+ x2wEUFT1CCzWpCYw9Or/QOQ= =daKO -----END PGP SIGNATURE----- --=-rynb/29xXRYVc674bWER-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:24:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JOKnC003133 for ; Tue, 4 Jun 2002 12:24:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JOK5v003131 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:24:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.168]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JOCnC002976 for ; Tue, 4 Jun 2002 12:24:13 -0700 Received: (qmail 8314 invoked by uid 500); 4 Jun 2002 19:25:56 -0000 Subject: blocksize > 4k...Belay my last. From: Austin Gonyou To: linux-xfs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-encrypted"; boundary="=-+/gURPYUzbNDlIpXXjRP" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jun 2002 14:25:56 -0500 Message-Id: <1023218756.7925.21.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-+/gURPYUzbNDlIpXXjRP Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Never mind..I'm dumb. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-+/gURPYUzbNDlIpXXjRP Content-Type: application/pgp-encrypted; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8/RRE94g6ZVmFMoIRAvYrAJoDMpSYxtN5kZFDUkpmXE2yGRu79gCg2bkd 3JvUackFkkhUkZ32Yty5jJ4= =/LMY -----END PGP SIGNATURE----- --=-+/gURPYUzbNDlIpXXjRP-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:24:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JO9nC003014 for ; Tue, 4 Jun 2002 12:24:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JO9LW003013 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:24:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JO3nC002974 for ; Tue, 4 Jun 2002 12:24:05 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.35 #1) id 17FJwG-0002Id-00; Tue, 04 Jun 2002 21:25:52 +0200 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Svetoslav Slavtchev" Date: Tue, 04 Jun 2002 21:25:52 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2502) For Windows 2000 (5.0.2195;2) In-Reply-To: <3CFD0DE8.9020405@st-peter.stw.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [2.5.20-dj1]ld: cannot open xfs_dmapi/built-in.o: No such file or directory Message-Id: X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,GAPPY_TEXT version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 04 Jun 2002 20:58:48 +0200, Svetoslav Slavtchev wrote: >ld: cannot open xfs_dmapi/built-in.o: No such file or directory Do you have DMAPI configured as a module? That doesn't work, IIRC. You need to configure it into the kernel, then it will link properly. -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:25:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JPYnC003350 for ; Tue, 4 Jun 2002 12:25:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JPYXl003349 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:25:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JPTnC003315 for ; Tue, 4 Jun 2002 12:25:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA69521; Tue, 4 Jun 2002 14:27:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA15680; Tue, 4 Jun 2002 14:27:18 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g54JNBM24964; Tue, 4 Jun 2002 14:23:11 -0500 Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? From: Steve Lord To: Austin Gonyou Cc: linux-xfs In-Reply-To: <1023218656.7905.19.camel@UberGeek> References: <1023218656.7905.19.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 04 Jun 2002 14:23:11 -0500 Message-Id: <1023218591.6937.52.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-04 at 14:24, Austin Gonyou wrote: > I would like to have 8k blocks..instead of 4k blocks. I didn't see > anything in the manpages..and I'm assuming it's not possible..but I > thought I'd ask. I want to try to do a 1:1 test with Veritas. Only if you have hardware with a page size of 8K or greater, want to buy an ia64 box? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:34:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JY1nC004766 for ; Tue, 4 Jun 2002 12:34:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JY1OI004765 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:34:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.168]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JXqnC004734 for ; Tue, 4 Jun 2002 12:33:53 -0700 Received: (qmail 8336 invoked by uid 500); 4 Jun 2002 19:35:36 -0000 Subject: Invalid argument when trying to set the blocksize. From: Austin Gonyou To: linux-xfs Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-encrypted"; boundary="=-Vrd8Pu+akUwCv/BwWgOu" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jun 2002 14:35:36 -0500 Message-Id: <1023219336.7927.25.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-Vrd8Pu+akUwCv/BwWgOu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I try to perform the following: mkfs.xfs -b size=3D8192 /dev/data/datavol1 The fs is made on the volume, but I get the following message: mkfs.xfs: warning - cannot set blocksize on block device=20 /dev/data/datavol1: Invalid argument I'm using LVM 1.1rc2 tools, and have a 2.4.19-pre9-aa2 kernel.=20 Is this another one of those ioctl() things that's depricated or is it something else. TIA --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-Vrd8Pu+akUwCv/BwWgOu Content-Type: application/pgp-encrypted; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8/RaI94g6ZVmFMoIRArqjAJ9veZPzZwoD3/sZTJARcYUUwracXACfb7WB gRHangj5d44XdM9Tp0AyK2U= =YSv2 -----END PGP SIGNATURE----- --=-Vrd8Pu+akUwCv/BwWgOu-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:38:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JclnC004998 for ; Tue, 4 Jun 2002 12:38:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JclAT004997 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:38:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JcdnC004964 for ; Tue, 4 Jun 2002 12:38:40 -0700 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 17FKAD-0003Tq-00; Tue, 04 Jun 2002 21:40:17 +0200 Message-ID: <3CFD1807.4020407@st-peter.stw.uni-erlangen.de> Date: Tue, 04 Jun 2002 21:41:59 +0200 From: Svetoslav Slavtchev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Ralf G. R. Bergs" CC: "linux-xfs@oss.sgi.com" Subject: Re: [2.5.20-dj1]ld: cannot open xfs_dmapi/built-in.o: No such file or directory References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *17FKAD-0003Tq-00*0OjSLAGV/Ww* (Studentenwohnanlage Nuernberg St.-Peter) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ralf G. R. Bergs wrote: >On Tue, 04 Jun 2002 20:58:48 +0200, Svetoslav Slavtchev wrote: > > > >>ld: cannot open xfs_dmapi/built-in.o: No such file or directory >> >> > >Do you have DMAPI configured as a module? That doesn't work, IIRC. You need to >configure it into the kernel, then it will link properly. > > > > well it's configured built in, the error comes by making bzImage root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# cat .config | grep XFS CONFIG_VXFS_FS=m CONFIG_XFS_FS=y CONFIG_XFS_RT=y CONFIG_XFS_QUOTA=y CONFIG_XFS_DMAPI=y CONFIG_XFS_DMAPI=y CONFIG_HAVE_XFS_DMAPI=y [root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:44:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JiUnC005209 for ; Tue, 4 Jun 2002 12:44:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JiU3a005208 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:44:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JiOnC005178 for ; Tue, 4 Jun 2002 12:44:24 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA69104; Tue, 4 Jun 2002 14:46:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA23113; Tue, 4 Jun 2002 14:45:46 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g54Jfdo25355; Tue, 4 Jun 2002 14:41:39 -0500 Subject: Re: [2.5.20-dj1]ld: cannot open xfs_dmapi/built-in.o: No such file or directory From: Steve Lord To: Svetoslav Slavtchev Cc: "Ralf G. R. Bergs" , "linux-xfs@oss.sgi.com" In-Reply-To: <3CFD1807.4020407@st-peter.stw.uni-erlangen.de> References: <3CFD1807.4020407@st-peter.stw.uni-erlangen.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 04 Jun 2002 14:41:39 -0500 Message-Id: <1023219699.6937.57.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.9 required=5.0 tests=IN_REP_TO,SUBJ_HAS_SPACES,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-04 at 14:41, Svetoslav Slavtchev wrote: > > root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# cat .config | grep XFS > CONFIG_VXFS_FS=m > CONFIG_XFS_FS=y > CONFIG_XFS_RT=y > CONFIG_XFS_QUOTA=y > CONFIG_XFS_DMAPI=y > CONFIG_XFS_DMAPI=y > CONFIG_HAVE_XFS_DMAPI=y > [root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# Just turn off dmapi - chances of it actually working in 2.5 are minimal anyway right now. Same with realtime. Your problem may also actually be due to the duplicate DMAPI entry in the config. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:50:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JoqnC005407 for ; Tue, 4 Jun 2002 12:50:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JoqKF005406 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:50:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.168]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JognC005374 for ; Tue, 4 Jun 2002 12:50:42 -0700 Received: (qmail 8381 invoked by uid 500); 4 Jun 2002 19:52:28 -0000 Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? From: Austin Gonyou To: Steve Lord Cc: linux-xfs In-Reply-To: <1023218591.6937.52.camel@jen.americas.sgi.com> References: <1023218591.6937.52.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-encrypted"; boundary="=-a0Urp4zWCikdHB5bsz76" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jun 2002 14:52:28 -0500 Message-Id: <1023220348.7912.28.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-a0Urp4zWCikdHB5bsz76 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-06-04 at 14:23, Steve Lord wrote: > On Tue, 2002-06-04 at 14:24, Austin Gonyou wrote: > > I would like to have 8k blocks..instead of 4k blocks. I didn't see > > anything in the manpages..and I'm assuming it's not possible..but I > > thought I'd ask. I want to try to do a 1:1 test with Veritas. >=20 >=20 > Only if you have hardware with a page size of 8K or greater, want > to buy an ia64 box? Well...regardless of this..I've got a larger problem..and I think it's that I need to patch my kernel for LVM 1.1.x, cause ATM, regardless of -b size=3D8192 during mkfs, I cannot mount the volume which has been formatted.=20 > Steve >=20 >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-a0Urp4zWCikdHB5bsz76 Content-Type: application/pgp-encrypted; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8/Rp894g6ZVmFMoIRAlegAJ0fAyCXAY/esC0guEsx33gCoUS1EwCfdKHc W/VfA0zQmTn/7f8NJk8y4CE= =OLGS -----END PGP SIGNATURE----- --=-a0Urp4zWCikdHB5bsz76-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:52:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JqunC005592 for ; Tue, 4 Jun 2002 12:52:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54Jqu36005591 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:52:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JqonC005562 for ; Tue, 4 Jun 2002 12:52:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA69834; Tue, 4 Jun 2002 14:54:39 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA22387; Tue, 4 Jun 2002 14:54:19 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g54JoCN25717; Tue, 4 Jun 2002 14:50:12 -0500 Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? From: Steve Lord To: Austin Gonyou Cc: linux-xfs In-Reply-To: <1023220348.7912.28.camel@UberGeek> References: <1023218591.6937.52.camel@jen.americas.sgi.com> <1023220348.7912.28.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 04 Jun 2002 14:50:12 -0500 Message-Id: <1023220212.6923.59.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-04 at 14:52, Austin Gonyou wrote: > On Tue, 2002-06-04 at 14:23, Steve Lord wrote: > > On Tue, 2002-06-04 at 14:24, Austin Gonyou wrote: > > > I would like to have 8k blocks..instead of 4k blocks. I didn't see > > > anything in the manpages..and I'm assuming it's not possible..but I > > > thought I'd ask. I want to try to do a 1:1 test with Veritas. > > > > > > Only if you have hardware with a page size of 8K or greater, want > > to buy an ia64 box? > > Well...regardless of this..I've got a larger problem..and I think it's > that I need to patch my kernel for LVM 1.1.x, cause ATM, regardless of > -b size=8192 during mkfs, I cannot mount the volume which has been > formatted. > XFS will refuse to mount it. There is no support for a filesystem with a blocksize larger than the system pagesize. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:55:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JtZnC005774 for ; Tue, 4 Jun 2002 12:55:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JtZQb005773 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:55:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.168]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JtPnC005741 for ; Tue, 4 Jun 2002 12:55:25 -0700 Received: (qmail 8398 invoked by uid 500); 4 Jun 2002 19:57:12 -0000 Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? From: Austin Gonyou To: Steve Lord Cc: linux-xfs In-Reply-To: <1023220212.6923.59.camel@jen.americas.sgi.com> References: <1023220212.6923.59.camel@jen.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-encrypted"; boundary="=-KPoAxh4rTrXBRU140YCD" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jun 2002 14:57:12 -0500 Message-Id: <1023220632.7927.33.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-KPoAxh4rTrXBRU140YCD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-06-04 at 14:50, Steve Lord wrote: ... > > >=20 > > > Only if you have hardware with a page size of 8K or greater, want > > > to buy an ia64 box? > >=20 > > Well...regardless of this..I've got a larger problem..and I think > it's > > that I need to patch my kernel for LVM 1.1.x, cause ATM, regardless > of > > -b size=3D8192 during mkfs, I cannot mount the volume which has been > > formatted.=20 > >=20 >=20 > XFS will refuse to mount it. There is no support for a filesystem with > a blocksize larger than the system pagesize. Ahh..I seee....so IA32 cannot handle this at all? > Steve >=20=20 >=20 > --=20 >=20 > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-KPoAxh4rTrXBRU140YCD Content-Type: application/pgp-encrypted; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8/RuY94g6ZVmFMoIRAoOyAKCLyayytsfYyI4afdEnSP0V8GC5ogCgx6kR ECJ4rPFpbU+PKDCU2GUeCo4= =KxeT -----END PGP SIGNATURE----- --=-KPoAxh4rTrXBRU140YCD-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 12:57:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54JvXnC005954 for ; Tue, 4 Jun 2002 12:57:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54JvXwZ005953 for linux-xfs-outgoing; Tue, 4 Jun 2002 12:57:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54JvTnC005922 for ; Tue, 4 Jun 2002 12:57:29 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA68714; Tue, 4 Jun 2002 14:59:19 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA59352; Tue, 4 Jun 2002 14:59:18 -0500 (CDT) Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? From: Eric Sandeen To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1023220632.7927.33.camel@UberGeek> References: <1023220212.6923.59.camel@jen.americas.sgi.com> <1023220632.7927.33.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 04 Jun 2002 14:57:36 -0500 Message-Id: <1023220656.17830.42.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-04 at 14:57, Austin Gonyou wrote: > Ahh..I seee....so IA32 cannot handle this at all? There is no support in XFS for filesystem block size > page size for any architecture... -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 4 13:36:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54KainC006712 for ; Tue, 4 Jun 2002 13:36:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54KaiRA006711 for linux-xfs-outgoing; Tue, 4 Jun 2002 13:36:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54KacnC006682 for ; Tue, 4 Jun 2002 13:36:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA70028 for ; Tue, 4 Jun 2002 15:38:28 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA99293 for ; Tue, 4 Jun 2002 15:38:28 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g54KajD07726; Tue, 4 Jun 2002 15:36:45 -0500 Message-Id: <200206042036.g54KajD07726@stout.americas.sgi.com> Date: Tue, 4 Jun 2002 15:36:45 -0500 Subject: TAKE - Merge Irix mod irix6.5f:irix:120477a X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk fix xfs_dir2_sf_replace to count the number of 8-byte inodes correctly. Date: Tue Jun 4 13:37:15 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-irixmerge Inspected by: cwf@sgi.com Author: overby Merged by: sandeen Merged mods: irix6.5f:irix:120477a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120477a linux/fs/xfs/xfs_dir2_sf.c - 1.27 From owner-linux-xfs@oss.sgi.com Tue Jun 4 13:41:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54KfnnC006928 for ; Tue, 4 Jun 2002 13:41:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54KfnY1006927 for linux-xfs-outgoing; Tue, 4 Jun 2002 13:41:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fuerzag.ulatina.ac.cr (fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54KfGnC006894 for ; Tue, 4 Jun 2002 13:41:23 -0700 Received: from lucy.ulatina.ac.cr (fede2@lucy.ulatina.ac.cr [163.178.60.3]) by fuerzag.ulatina.ac.cr (8.11.6/8.10.2) with ESMTP id g54KaRS06527 for ; Tue, 4 Jun 2002 14:36:27 -0600 Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? From: Alvaro Figueroa To: XFS list In-Reply-To: <1023218591.6937.52.camel@jen.americas.sgi.com> References: <1023218656.7905.19.camel@UberGeek> <1023218591.6937.52.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 04 Jun 2002 14:42:27 -0600 Message-Id: <1023223347.25693.10.camel@lucy> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Only if you have hardware with a page size of 8K or greater, want > to buy an ia64 box? sparc64 works quite well. BTW, what is needed, so that you guys can "offer" XFS as a stable filesystem for some arquitecture other that ia(32|64)? (I specially want to know if there is anything I can do to help) -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Tue Jun 4 13:45:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54KjknC007130 for ; Tue, 4 Jun 2002 13:45:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54Kjkkq007129 for linux-xfs-outgoing; Tue, 4 Jun 2002 13:45:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf08bis.bellsouth.net (mail108.mail.bellsouth.net [205.152.58.48]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54KjNnC007094 for ; Tue, 4 Jun 2002 13:45:23 -0700 Received: from taz ([66.156.5.105]) by imf08bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020604204839.TJIP21266.imf08bis.bellsouth.net@taz>; Tue, 4 Jun 2002 16:48:39 -0400 Date: Tue, 4 Jun 2002 16:38:41 -0400 From: Greg Freemyer Subject: re[6]: Which Kernel for XFS To: "Anthony W. Marino" cc: linux-xfs Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020604204839.TJIP21266.imf08bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54KjNnC007096 X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anthony, I am not an expert on Linux kernels, and I'm sure there are people on this list that will disagree with the below, but my thoughts are: It depends on what you are trying to do. If you are a kernel developer, or you want to be on the bleeding edge of kernel capabilities, then you need a kernel from kernel.org or one of the other kernel maintainers. For production I like to use distribution kernels.or patched distribution kernels. i.e. From Redhat, SuSE, Mandrake, etc. My logic for this is that if the kernel turns out to have a bug, it is likely that distribution maintainer will correct the kernel and send out the fix. i.e. Redhat supported the 2.4.9 kernel for 8 months or so, and may still be releasing patches for it. If you are using a kernel.org kernel, and you get a rev. level behind, nobody is going to support you. i.e. If you have 2.4.17 kernel today, and a kernel bug pops up that you care about, there is nobody that is going to creating patches against that "old" of a kernel. As I understand it, the kernel developers never fix a released kernel. If something is broke, they fix it in the next release. Unfortunately, something else will likely be broken in the next release. If you want a "maintained" kernel, you have to get it from a distribution provider. Another issue, is that if you upgrade your kernel and you don't get all the associated pieces, you can break some applications. i.e. Some of the xfs user-land tools for kernels prior to 2.4.18 don't work with the 2.4.18 kernel. I imagine that there are many of these kernel dependencies spread around a typical distribution, and you risk breaking things if you upgrade the kernel lock, stock, and barrel. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com >> Greg, >> Are there any advantages to me using the Mantel/SuSE kernel over the >> latest >> sources from sgi? >> Thanks, >> Anthon >> > Anthony, >> > >> > The notes at >> > >> ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/people/mantel/ >> ne >> >xt/kernel-source.changes give you some of what you are asking about. >> > >> > Per the above, it is based on the 2.4.19-pre8aa1 kernel. I believe that >> > already has the XFS patches in it, so you could look into what it has. >> > >> > For details, I guess you need to download the source RPM and read the >> > specfile. >> > >> > Greg >> > >> > >> > Since you are using a SuSE distribution, have you thought about >> > >> > using >> > >> >> > >> the >> > >> >> > >> > SuSE experimental kernel from >> > >> > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ >> > >> > >> > >> > It has all the standard SuSE patches and includes a relatively >> > >> > recent >> > >> >> > >> XFS. >> > >> >> > >> > Possibly XFS v1.1, but I'm not sure. >> > >> >> > >> I have the Mantel's latest kernel installed on my laptop however >> I'm >> > >> not certain what it is that I have. What I mean by that is how do I >> > >> find out what XFS version and patch level do I have so that I can >> > >> decide on patch upgrades? I know it says kernel 2.4.18 however is >> it >> > >> really 2.4.19 pre... . >> > >> As you can see, I'm not certain of the versions and patch levels >> > >> contained >> > >> >> > >> within the Mantel stuff. >> > >> >> > >> Anthony >> > >> >> > >> > FYI: The stock SuSE 8.0 kernel also has XFS support, but the ACL >> > >> >> > >> handling >> > >> >> > >> > is broken in such a way that xfsdump/xfsrestore don't handle ACLs >> > >> > correctly. >> > >> > >> > >> > Greg Freemyer >> > >> > Internet Engineer >> > >> > Deployment and Integration Specialist >> > >> > Compaq ASE - Tru64 >> > >> > Compaq Master ASE - SAN Architect >> > >> > The Norcross Group >> > >> > www.NorcrossGroup.com >> > >> > >> > >> > >> Steve, >> > >> > >> What do you recommend that I use since the box I'm building >> is >> > >> > >> a development >> > >> > >> box for myself which I will be using for development >> purposes >> > >> > >> and >> > >> >> > >> thus >> > >> >> > >> > >> will >> > >> > >> be using other cvs sources from other opesource projects as >> > >> > >> well? >> > >> > >> >> > >> > >> Anthony >> > >> > >> >> > >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: >> > >> > >> > > I'm building/setting-up a new server SuSE 7.3 which will >> > >> >> > >> include >> > >> >> > >> > >> > > 3ware (7810) ide raid (10 or 5) with brand new drives >> and >> > >> > >> > > most likely LVM >> > >> > >> >> > >> > >> too. >> > >> > >> >> > >> > >> > > Should I get the kernel from oss.sgi.com cvs >> > >> > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" linux-2.4-xfs) >> or >> > >> > >> > > is there another location/process that I should >> entertain? >> > >> > >> > > Also >> > >> >> > >> what >> > >> >> > >> > >> > > kernel release does the oss.sgi.com cvs sources give me? >> > >> > >> > > >> > >> > >> > > Thank You, >> > >> > >> > > Anthony >> > >> > >> > >> > >> > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb (which >> > >> > >> > you probably do not care about). There are fixes in this >> tree >> > >> > >> > which >> > >> >> > >> are >> > >> >> > >> > >> > not available anywhere else, it is the most direct link to >> > >> > >> > XFS development. Of course this also possibly means there >> are >> > >> > >> > bugs in this tree which are not available anywhere else. >> > >> > >> > >> > >> > >> > Steve >> > >> > Greg Freemyer >> > Internet Engineer >> > Deployment and Integration Specialist >> > Compaq ASE - Tru64 >> > Compaq Master ASE - SAN Architect >> > The Norcross Group >> > www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 13:50:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54KoCnC007326 for ; Tue, 4 Jun 2002 13:50:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54KoC7j007325 for linux-xfs-outgoing; Tue, 4 Jun 2002 13:50:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54KnhnC007286 for ; Tue, 4 Jun 2002 13:49:44 -0700 Received: from [64.32.179.242] (HELO awm-laptop) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 33154620; Tue, 04 Jun 2002 13:43:17 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects To: Greg Freemyer Subject: Re: re[6]: Which Kernel for XFS Date: Tue, 4 Jun 2002 16:55:34 -0400 User-Agent: KMail/1.4.1 Cc: linux-xfs References: <20020604204839.TJIP21266.imf08bis.bellsouth.net@taz> In-Reply-To: <20020604204839.TJIP21266.imf08bis.bellsouth.net@taz> MIME-Version: 1.0 Message-Id: <200206041655.34823.anthony@AWMObjects.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54KninC007289 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Greg, I, do, appreciate and agree with your thought process however I want the latest and greatest XFS patches. Do you, then, think that it's safe to stay with, let's say in my case, Mantel, and apply XFS patches to it as they appear??? Thank You, Anthony > Anthony, > > I am not an expert on Linux kernels, and I'm sure there are people on this > list that will disagree with the below, but my thoughts are: > > It depends on what you are trying to do. > > If you are a kernel developer, or you want to be on the bleeding edge of > kernel capabilities, then you need a kernel from kernel.org or one of the > other kernel maintainers. > > For production I like to use distribution kernels.or patched distribution > kernels. i.e. From Redhat, SuSE, Mandrake, etc. > > My logic for this is that if the kernel turns out to have a bug, it is > likely that distribution maintainer will correct the kernel and send out > the fix. > > i.e. Redhat supported the 2.4.9 kernel for 8 months or so, and may still be > releasing patches for it. > > If you are using a kernel.org kernel, and you get a rev. level behind, > nobody is going to support you. > > i.e. If you have 2.4.17 kernel today, and a kernel bug pops up that you > care about, there is nobody that is going to creating patches against that > "old" of a kernel. As I understand it, the kernel developers never fix a > released kernel. If something is broke, they fix it in the next release. > Unfortunately, something else will likely be broken in the next release. > > If you want a "maintained" kernel, you have to get it from a distribution > provider. > > Another issue, is that if you upgrade your kernel and you don't get all the > associated pieces, you can break some applications. > > i.e. Some of the xfs user-land tools for kernels prior to 2.4.18 don't work > with the 2.4.18 kernel. I imagine that there are many of these kernel > dependencies spread around a typical distribution, and you risk breaking > things if you upgrade the kernel lock, stock, and barrel. > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com > > >> Greg, > >> Are there any advantages to me using the Mantel/SuSE kernel over the > >> latest > >> sources from sgi? > >> > >> Thanks, > >> Anthon > >> > >> > Anthony, > >> > > >> > The notes at > >> > >> > >> ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/people/mante > >>l/ ne > >> > >> >xt/kernel-source.changes give you some of what you are asking about. > >> > > >> > Per the above, it is based on the 2.4.19-pre8aa1 kernel. I believe > >> > that already has the XFS patches in it, so you could look into what > >> > it has. > >> > > >> > For details, I guess you need to download the source RPM and read > >> > the specfile. > >> > > >> > Greg > >> > > >> > >> > Since you are using a SuSE distribution, have you thought > >> > >> > about using > >> > >> > >> > >> the > >> > >> > >> > >> > SuSE experimental kernel from > >> > >> > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ > >> > >> > > >> > >> > It has all the standard SuSE patches and includes a > >> > >> > relatively recent > >> > >> > >> > >> XFS. > >> > >> > >> > >> > Possibly XFS v1.1, but I'm not sure. > >> > >> > >> > >> I have the Mantel's latest kernel installed on my laptop > >> > >> however > >> > >> I'm > >> > >> > >> not certain what it is that I have. What I mean by that is how > >> > >> do I find out what XFS version and patch level do I have so that > >> > >> I can decide on patch upgrades? I know it says kernel 2.4.18 > >> > >> however is > >> > >> it > >> > >> > >> really 2.4.19 pre... . > >> > >> As you can see, I'm not certain of the versions and patch > >> > >> levels contained > >> > >> > >> > >> within the Mantel stuff. > >> > >> > >> > >> Anthony > >> > >> > >> > >> > FYI: The stock SuSE 8.0 kernel also has XFS support, but the > >> > >> > ACL > >> > >> > >> > >> handling > >> > >> > >> > >> > is broken in such a way that xfsdump/xfsrestore don't handle > >> > >> > ACLs correctly. > >> > >> > > >> > >> > Greg Freemyer > >> > >> > Internet Engineer > >> > >> > Deployment and Integration Specialist > >> > >> > Compaq ASE - Tru64 > >> > >> > Compaq Master ASE - SAN Architect > >> > >> > The Norcross Group > >> > >> > www.NorcrossGroup.com > >> > >> > > >> > >> > >> Steve, > >> > >> > >> What do you recommend that I use since the box I'm > >> > >> > >> building > >> > >> is > >> > >> > >> > >> a development > >> > >> > >> box for myself which I will be using for development > >> > >> purposes > >> > >> > >> > >> and > >> > >> > >> > >> thus > >> > >> > >> > >> > >> will > >> > >> > >> be using other cvs sources from other opesource projects > >> > >> > >> as well? > >> > >> > >> > >> > >> > >> Anthony > >> > >> > >> > >> > >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: > >> > >> > >> > > I'm building/setting-up a new server SuSE 7.3 which > >> > >> > >> > > will > >> > >> > >> > >> include > >> > >> > >> > >> > >> > > 3ware (7810) ide raid (10 or 5) with brand new > >> > >> > >> > > drives > >> > >> and > >> > >> > >> > >> > > most likely LVM > >> > >> > >> > >> > >> > >> too. > >> > >> > >> > >> > >> > >> > > Should I get the kernel from oss.sgi.com cvs > >> > >> > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" > >> > >> > >> > > linux-2.4-xfs) > >> > >> or > >> > >> > >> > >> > > is there another location/process that I should > >> > >> entertain? > >> > >> > >> > >> > > Also > >> > >> > >> > >> what > >> > >> > >> > >> > >> > > kernel release does the oss.sgi.com cvs sources give > >> > >> > >> > > me? > >> > >> > >> > > > >> > >> > >> > > Thank You, > >> > >> > >> > > Anthony > >> > >> > >> > > >> > >> > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb > >> > >> > >> > (which you probably do not care about). There are > >> > >> > >> > fixes in this > >> > >> tree > >> > >> > >> > >> > which > >> > >> > >> > >> are > >> > >> > >> > >> > >> > not available anywhere else, it is the most direct > >> > >> > >> > link to XFS development. Of course this also possibly > >> > >> > >> > means there > >> > >> are > >> > >> > >> > >> > bugs in this tree which are not available anywhere > >> > >> > >> > else. > >> > >> > >> > > >> > >> > >> > Steve > >> > > >> > Greg Freemyer > >> > Internet Engineer > >> > Deployment and Integration Specialist > >> > Compaq ASE - Tru64 > >> > Compaq Master ASE - SAN Architect > >> > The Norcross Group > >> > www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:01:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54L1mnC007586 for ; Tue, 4 Jun 2002 14:01:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54L1moP007585 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:01:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.168]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54L1dnC007552 for ; Tue, 4 Jun 2002 14:01:39 -0700 Received: (qmail 9314 invoked by uid 500); 4 Jun 2002 21:03:05 -0000 Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? From: Austin Gonyou To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1023220656.17830.42.camel@stout.americas.sgi.com> References: <1023220656.17830.42.camel@stout.americas.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-encrypted"; boundary="=-9QFVHFpODeIhNXGo2FpO" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jun 2002 16:03:05 -0500 Message-Id: <1023224585.9286.1.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-9QFVHFpODeIhNXGo2FpO Content-Type: text/plain Content-Transfer-Encoding: quoted-printable So say, with NTFS...you *can* do that..is that because they make it do that..but it can be slower? On Tue, 2002-06-04 at 14:57, Eric Sandeen wrote: > On Tue, 2002-06-04 at 14:57, Austin Gonyou wrote: >=20 > > Ahh..I seee....so IA32 cannot handle this at all? >=20 > There is no support in XFS for filesystem block size > page size for > any > architecture... >=20 > -Eric --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-9QFVHFpODeIhNXGo2FpO Content-Type: application/pgp-encrypted; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8/SsJ94g6ZVmFMoIRAnrEAJ4vAyC+7b/XxTBUwX3kjLFtpvWkyQCeJhhR cGmkJz9FL4iwLeIneT3zt4o= =mDuJ -----END PGP SIGNATURE----- --=-9QFVHFpODeIhNXGo2FpO-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:02:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54L2jnC007747 for ; Tue, 4 Jun 2002 14:02:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54L2jvE007743 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:02:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from front1.mail.megapathdsl.net (front1.mail.megapathdsl.net [66.80.60.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54L2EnC007619 for ; Tue, 4 Jun 2002 14:02:14 -0700 Received: from [64.32.179.242] (HELO awm-laptop) by front1.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 30161221; Tue, 04 Jun 2002 13:56:28 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects To: Greg Freemyer Subject: Re: re[6]: Which Kernel for XFS Date: Tue, 4 Jun 2002 17:08:04 -0400 User-Agent: KMail/1.4.1 Cc: linux-xfs References: <20020604204839.TJIP21266.imf08bis.bellsouth.net@taz> In-Reply-To: <20020604204839.TJIP21266.imf08bis.bellsouth.net@taz> MIME-Version: 1.0 Message-Id: <200206041708.04980.anthony@AWMObjects.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54L2EnC007636 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Greg, Using a browser and not YAST I can see the "changes" text file. YAST shows that I have source installed however I'm going to force installation of the kernel source per your recommendation. Thank You, Anthony > Anthony, > > I am not an expert on Linux kernels, and I'm sure there are people on this > list that will disagree with the below, but my thoughts are: > > It depends on what you are trying to do. > > If you are a kernel developer, or you want to be on the bleeding edge of > kernel capabilities, then you need a kernel from kernel.org or one of the > other kernel maintainers. > > For production I like to use distribution kernels.or patched distribution > kernels. i.e. From Redhat, SuSE, Mandrake, etc. > > My logic for this is that if the kernel turns out to have a bug, it is > likely that distribution maintainer will correct the kernel and send out > the fix. > > i.e. Redhat supported the 2.4.9 kernel for 8 months or so, and may still be > releasing patches for it. > > If you are using a kernel.org kernel, and you get a rev. level behind, > nobody is going to support you. > > i.e. If you have 2.4.17 kernel today, and a kernel bug pops up that you > care about, there is nobody that is going to creating patches against that > "old" of a kernel. As I understand it, the kernel developers never fix a > released kernel. If something is broke, they fix it in the next release. > Unfortunately, something else will likely be broken in the next release. > > If you want a "maintained" kernel, you have to get it from a distribution > provider. > > Another issue, is that if you upgrade your kernel and you don't get all the > associated pieces, you can break some applications. > > i.e. Some of the xfs user-land tools for kernels prior to 2.4.18 don't work > with the 2.4.18 kernel. I imagine that there are many of these kernel > dependencies spread around a typical distribution, and you risk breaking > things if you upgrade the kernel lock, stock, and barrel. > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com > > >> Greg, > >> Are there any advantages to me using the Mantel/SuSE kernel over the > >> latest > >> sources from sgi? > >> > >> Thanks, > >> Anthon > >> > >> > Anthony, > >> > > >> > The notes at > >> > >> > >> ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/people/mante > >>l/ ne > >> > >> >xt/kernel-source.changes give you some of what you are asking about. > >> > > >> > Per the above, it is based on the 2.4.19-pre8aa1 kernel. I believe > >> > that already has the XFS patches in it, so you could look into what > >> > it has. > >> > > >> > For details, I guess you need to download the source RPM and read > >> > the specfile. > >> > > >> > Greg > >> > > >> > >> > Since you are using a SuSE distribution, have you thought > >> > >> > about using > >> > >> > >> > >> the > >> > >> > >> > >> > SuSE experimental kernel from > >> > >> > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ > >> > >> > > >> > >> > It has all the standard SuSE patches and includes a > >> > >> > relatively recent > >> > >> > >> > >> XFS. > >> > >> > >> > >> > Possibly XFS v1.1, but I'm not sure. > >> > >> > >> > >> I have the Mantel's latest kernel installed on my laptop > >> > >> however > >> > >> I'm > >> > >> > >> not certain what it is that I have. What I mean by that is how > >> > >> do I find out what XFS version and patch level do I have so that > >> > >> I can decide on patch upgrades? I know it says kernel 2.4.18 > >> > >> however is > >> > >> it > >> > >> > >> really 2.4.19 pre... . > >> > >> As you can see, I'm not certain of the versions and patch > >> > >> levels contained > >> > >> > >> > >> within the Mantel stuff. > >> > >> > >> > >> Anthony > >> > >> > >> > >> > FYI: The stock SuSE 8.0 kernel also has XFS support, but the > >> > >> > ACL > >> > >> > >> > >> handling > >> > >> > >> > >> > is broken in such a way that xfsdump/xfsrestore don't handle > >> > >> > ACLs correctly. > >> > >> > > >> > >> > Greg Freemyer > >> > >> > Internet Engineer > >> > >> > Deployment and Integration Specialist > >> > >> > Compaq ASE - Tru64 > >> > >> > Compaq Master ASE - SAN Architect > >> > >> > The Norcross Group > >> > >> > www.NorcrossGroup.com > >> > >> > > >> > >> > >> Steve, > >> > >> > >> What do you recommend that I use since the box I'm > >> > >> > >> building > >> > >> is > >> > >> > >> > >> a development > >> > >> > >> box for myself which I will be using for development > >> > >> purposes > >> > >> > >> > >> and > >> > >> > >> > >> thus > >> > >> > >> > >> > >> will > >> > >> > >> be using other cvs sources from other opesource projects > >> > >> > >> as well? > >> > >> > >> > >> > >> > >> Anthony > >> > >> > >> > >> > >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino wrote: > >> > >> > >> > > I'm building/setting-up a new server SuSE 7.3 which > >> > >> > >> > > will > >> > >> > >> > >> include > >> > >> > >> > >> > >> > > 3ware (7810) ide raid (10 or 5) with brand new > >> > >> > >> > > drives > >> > >> and > >> > >> > >> > >> > > most likely LVM > >> > >> > >> > >> > >> > >> too. > >> > >> > >> > >> > >> > >> > > Should I get the kernel from oss.sgi.com cvs > >> > >> > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" > >> > >> > >> > > linux-2.4-xfs) > >> > >> or > >> > >> > >> > >> > > is there another location/process that I should > >> > >> entertain? > >> > >> > >> > >> > > Also > >> > >> > >> > >> what > >> > >> > >> > >> > >> > > kernel release does the oss.sgi.com cvs sources give > >> > >> > >> > > me? > >> > >> > >> > > > >> > >> > >> > > Thank You, > >> > >> > >> > > Anthony > >> > >> > >> > > >> > >> > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb > >> > >> > >> > (which you probably do not care about). There are > >> > >> > >> > fixes in this > >> > >> tree > >> > >> > >> > >> > which > >> > >> > >> > >> are > >> > >> > >> > >> > >> > not available anywhere else, it is the most direct > >> > >> > >> > link to XFS development. Of course this also possibly > >> > >> > >> > means there > >> > >> are > >> > >> > >> > >> > bugs in this tree which are not available anywhere > >> > >> > >> > else. > >> > >> > >> > > >> > >> > >> > Steve > >> > > >> > Greg Freemyer > >> > Internet Engineer > >> > Deployment and Integration Specialist > >> > Compaq ASE - Tru64 > >> > Compaq Master ASE - SAN Architect > >> > The Norcross Group > >> > www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:03:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54L3YnC007911 for ; Tue, 4 Jun 2002 14:03:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54L3YjV007910 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:03:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf07bis.bellsouth.net (mail307.mail.bellsouth.net [205.152.58.167]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54L2unC007800 for ; Tue, 4 Jun 2002 14:02:56 -0700 Received: from taz ([66.156.5.105]) by imf07bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020604210613.KLAU1171.imf07bis.bellsouth.net@taz>; Tue, 4 Jun 2002 17:06:13 -0400 Date: Tue, 4 Jun 2002 16:56:11 -0400 From: Greg Freemyer Subject: re[8]: Which Kernel for XFS To: "Anthony W. Marino" cc: linux-xfs Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020604210613.KLAU1171.imf07bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54L2unC007845 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Anthony, You need more advice than I can give you. I have so far stuck to patched distribution kernels. i.e. Mandrake, Redhat, SuSE. In your case, you might want to start following the aa kernels. i.e. SuSE is using 2.4.19-pre8aa1 where the aa is the initials of a specific kernel developer. They are a set of patched kernel.org kernels that have the xfs patches and some others all ready integrated. I don't know if they have any xfs patches newer than xfs v1.1 or not. I "assume" that only stable xfs patches are included. I say this, because the CVS tree breaks from time-to-time, and if you just blindly grab every patch that comes along, you will likely have a broken kernel from time-to-time. Greg >> Greg, >> I, do, appreciate and agree with your thought process however I want the >> latest and greatest XFS patches. >> Do you, then, think that it's safe to stay with, let's say in my case, >> Mantel, >> and apply XFS patches to it as they appear??? >> Thank You, >> Anthony >> > Anthony, >> > >> > I am not an expert on Linux kernels, and I'm sure there are people on >> this >> > list that will disagree with the below, but my thoughts are: >> > >> > It depends on what you are trying to do. >> > >> > If you are a kernel developer, or you want to be on the bleeding edge of >> > kernel capabilities, then you need a kernel from kernel.org or one of >> the >> > other kernel maintainers. >> > >> > For production I like to use distribution kernels.or patched >> distribution >> > kernels. i.e. From Redhat, SuSE, Mandrake, etc. >> > >> > My logic for this is that if the kernel turns out to have a bug, it is >> > likely that distribution maintainer will correct the kernel and send out >> > the fix. >> > >> > i.e. Redhat supported the 2.4.9 kernel for 8 months or so, and may still >> be >> > releasing patches for it. >> > >> > If you are using a kernel.org kernel, and you get a rev. level behind, >> > nobody is going to support you. >> > >> > i.e. If you have 2.4.17 kernel today, and a kernel bug pops up that you >> > care about, there is nobody that is going to creating patches against >> that >> > "old" of a kernel. As I understand it, the kernel developers never fix >> a >> > released kernel. If something is broke, they fix it in the next >> release. >> > Unfortunately, something else will likely be broken in the next release. >> > >> > If you want a "maintained" kernel, you have to get it from a >> distribution >> > provider. >> > >> > Another issue, is that if you upgrade your kernel and you don't get all >> the >> > associated pieces, you can break some applications. >> > >> > i.e. Some of the xfs user-land tools for kernels prior to 2.4.18 don't >> work >> > with the 2.4.18 kernel. I imagine that there are many of these kernel >> > dependencies spread around a typical distribution, and you risk breaking >> > things if you upgrade the kernel lock, stock, and barrel. >> > >> > Greg Freemyer >> > Internet Engineer >> > Deployment and Integration Specialist >> > Compaq ASE - Tru64 >> > Compaq Master ASE - SAN Architect >> > The Norcross Group >> > www.NorcrossGroup.com >> > >> > >> Greg, >> > >> Are there any advantages to me using the Mantel/SuSE kernel over >> the >> > >> latest >> > >> sources from sgi? >> > >> >> > >> Thanks, >> > >> Anthon >> > >> >> > >> > Anthony, >> > >> > >> > >> > The notes at >> > >> >> > >> >> > >> >> ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/people/mante >> > >>l/ ne >> > >> >> > >> >xt/kernel-source.changes give you some of what you are asking >> about. >> > >> > >> > >> > Per the above, it is based on the 2.4.19-pre8aa1 kernel. I >> believe >> > >> > that already has the XFS patches in it, so you could look into >> what >> > >> > it has. >> > >> > >> > >> > For details, I guess you need to download the source RPM and read >> > >> > the specfile. >> > >> > >> > >> > Greg >> > >> > >> > >> > >> > Since you are using a SuSE distribution, have you thought >> > >> > >> > about using >> > >> > >> >> > >> > >> the >> > >> > >> >> > >> > >> > SuSE experimental kernel from >> > >> > >> > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ >> > >> > >> > >> > >> > >> > It has all the standard SuSE patches and includes a >> > >> > >> > relatively recent >> > >> > >> >> > >> > >> XFS. >> > >> > >> >> > >> > >> > Possibly XFS v1.1, but I'm not sure. >> > >> > >> >> > >> > >> I have the Mantel's latest kernel installed on my laptop >> > >> > >> however >> > >> >> > >> I'm >> > >> >> > >> > >> not certain what it is that I have. What I mean by that is >> how >> > >> > >> do I find out what XFS version and patch level do I have so >> that >> > >> > >> I can decide on patch upgrades? I know it says kernel 2.4.18 >> > >> > >> however is >> > >> >> > >> it >> > >> >> > >> > >> really 2.4.19 pre... . >> > >> > >> As you can see, I'm not certain of the versions and patch >> > >> > >> levels contained >> > >> > >> >> > >> > >> within the Mantel stuff. >> > >> > >> >> > >> > >> Anthony >> > >> > >> >> > >> > >> > FYI: The stock SuSE 8.0 kernel also has XFS support, but >> the >> > >> > >> > ACL >> > >> > >> >> > >> > >> handling >> > >> > >> >> > >> > >> > is broken in such a way that xfsdump/xfsrestore don't >> handle >> > >> > >> > ACLs correctly. >> > >> > >> > >> > >> > >> > Greg Freemyer >> > >> > >> > Internet Engineer >> > >> > >> > Deployment and Integration Specialist >> > >> > >> > Compaq ASE - Tru64 >> > >> > >> > Compaq Master ASE - SAN Architect >> > >> > >> > The Norcross Group >> > >> > >> > www.NorcrossGroup.com >> > >> > >> > >> > >> > >> > >> Steve, >> > >> > >> > >> What do you recommend that I use since the box I'm >> > >> > >> > >> building >> > >> >> > >> is >> > >> >> > >> > >> > >> a development >> > >> > >> > >> box for myself which I will be using for development >> > >> >> > >> purposes >> > >> >> > >> > >> > >> and >> > >> > >> >> > >> > >> thus >> > >> > >> >> > >> > >> > >> will >> > >> > >> > >> be using other cvs sources from other opesource >> projects >> > >> > >> > >> as well? >> > >> > >> > >> >> > >> > >> > >> Anthony >> > >> > >> > >> >> > >> > >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino >> wrote: >> > >> > >> > >> > > I'm building/setting-up a new server SuSE 7.3 >> which >> > >> > >> > >> > > will >> > >> > >> >> > >> > >> include >> > >> > >> >> > >> > >> > >> > > 3ware (7810) ide raid (10 or 5) with brand new >> > >> > >> > >> > > drives >> > >> >> > >> and >> > >> >> > >> > >> > >> > > most likely LVM >> > >> > >> > >> >> > >> > >> > >> too. >> > >> > >> > >> >> > >> > >> > >> > > Should I get the kernel from oss.sgi.com cvs >> > >> > >> > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" >> > >> > >> > >> > > linux-2.4-xfs) >> > >> >> > >> or >> > >> >> > >> > >> > >> > > is there another location/process that I should >> > >> >> > >> entertain? >> > >> >> > >> > >> > >> > > Also >> > >> > >> >> > >> > >> what >> > >> > >> >> > >> > >> > >> > > kernel release does the oss.sgi.com cvs sources >> give >> > >> > >> > >> > > me? >> > >> > >> > >> > > >> > >> > >> > >> > > Thank You, >> > >> > >> > >> > > Anthony >> > >> > >> > >> > >> > >> > >> > >> > Right now it gives you 2.4.19-pre9 with xfs and kdb >> > >> > >> > >> > (which you probably do not care about). There are >> > >> > >> > >> > fixes in this >> > >> >> > >> tree >> > >> >> > >> > >> > >> > which >> > >> > >> >> > >> > >> are >> > >> > >> >> > >> > >> > >> > not available anywhere else, it is the most direct >> > >> > >> > >> > link to XFS development. Of course this also >> possibly >> > >> > >> > >> > means there >> > >> >> > >> are >> > >> >> > >> > >> > >> > bugs in this tree which are not available anywhere >> > >> > >> > >> > else. >> > >> > >> > >> > >> > >> > >> > >> > Steve >> > >> > >> > >> > Greg Freemyer >> > >> > Internet Engineer >> > >> > Deployment and Integration Specialist >> > >> > Compaq ASE - Tru64 >> > >> > Compaq Master ASE - SAN Architect >> > >> > The Norcross Group >> > >> > www.NorcrossGroup.com Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:11:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54LBanC009085 for ; Tue, 4 Jun 2002 14:11:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54LBaFJ009084 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:11:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from front2.mail.megapathdsl.net (front2.mail.megapathdsl.net [66.80.60.30]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54LArnC009055 for ; Tue, 4 Jun 2002 14:10:54 -0700 Received: from [64.32.179.242] (HELO awm-laptop) by front2.mail.megapathdsl.net (CommuniGate Pro SMTP 3.5.8) with ESMTP id 33158230; Tue, 04 Jun 2002 14:04:27 -0700 Content-Type: text/plain; charset="iso-8859-1" From: "Anthony W. Marino" Organization: AWM Objects To: Greg Freemyer Subject: Re: re[8]: Which Kernel for XFS Date: Tue, 4 Jun 2002 17:16:43 -0400 User-Agent: KMail/1.4.1 Cc: linux-xfs References: <20020604210613.KLAU1171.imf07bis.bellsouth.net@taz> In-Reply-To: <20020604210613.KLAU1171.imf07bis.bellsouth.net@taz> MIME-Version: 1.0 Message-Id: <200206041716.43189.anthony@AWMObjects.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54LAsnC009056 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Greg, Thank you for your time!!! Anthony > Anthony, > > You need more advice than I can give you. I have so far stuck to patched > distribution kernels. i.e. Mandrake, Redhat, SuSE. > > In your case, you might want to start following the aa kernels. i.e. SuSE > is using 2.4.19-pre8aa1 where the aa is the initials of a specific kernel > developer. > > They are a set of patched kernel.org kernels that have the xfs patches and > some others all ready integrated. > > I don't know if they have any xfs patches newer than xfs v1.1 or not. I > "assume" that only stable xfs patches are included. > > I say this, because the CVS tree breaks from time-to-time, and if you just > blindly grab every patch that comes along, you will likely have a broken > kernel from time-to-time. > > Greg > > >> Greg, > >> > >> I, do, appreciate and agree with your thought process however I want > >> the latest and greatest XFS patches. > >> > >> Do you, then, think that it's safe to stay with, let's say in my case, > >> Mantel, > >> and apply XFS patches to it as they appear??? > >> > >> > >> Thank You, > >> Anthony > >> > >> > Anthony, > >> > > >> > I am not an expert on Linux kernels, and I'm sure there are people > >> > on > >> > >> this > >> > >> > list that will disagree with the below, but my thoughts are: > >> > > >> > It depends on what you are trying to do. > >> > > >> > If you are a kernel developer, or you want to be on the bleeding > >> > edge of kernel capabilities, then you need a kernel from kernel.org > >> > or one of > >> > >> the > >> > >> > other kernel maintainers. > >> > > >> > For production I like to use distribution kernels.or patched > >> > >> distribution > >> > >> > kernels. i.e. From Redhat, SuSE, Mandrake, etc. > >> > > >> > My logic for this is that if the kernel turns out to have a bug, it > >> > is likely that distribution maintainer will correct the kernel and > >> > send out the fix. > >> > > >> > i.e. Redhat supported the 2.4.9 kernel for 8 months or so, and may > >> > still > >> > >> be > >> > >> > releasing patches for it. > >> > > >> > If you are using a kernel.org kernel, and you get a rev. level > >> > behind, nobody is going to support you. > >> > > >> > i.e. If you have 2.4.17 kernel today, and a kernel bug pops up that > >> > you care about, there is nobody that is going to creating patches > >> > against > >> > >> that > >> > >> > "old" of a kernel. As I understand it, the kernel developers never > >> > fix > >> > >> a > >> > >> > released kernel. If something is broke, they fix it in the next > >> > >> release. > >> > >> > Unfortunately, something else will likely be broken in the next > >> > release. > >> > > >> > If you want a "maintained" kernel, you have to get it from a > >> > >> distribution > >> > >> > provider. > >> > > >> > Another issue, is that if you upgrade your kernel and you don't get > >> > all > >> > >> the > >> > >> > associated pieces, you can break some applications. > >> > > >> > i.e. Some of the xfs user-land tools for kernels prior to 2.4.18 > >> > don't > >> > >> work > >> > >> > with the 2.4.18 kernel. I imagine that there are many of these > >> > kernel dependencies spread around a typical distribution, and you > >> > risk breaking things if you upgrade the kernel lock, stock, and > >> > barrel. > >> > > >> > Greg Freemyer > >> > Internet Engineer > >> > Deployment and Integration Specialist > >> > Compaq ASE - Tru64 > >> > Compaq Master ASE - SAN Architect > >> > The Norcross Group > >> > www.NorcrossGroup.com > >> > > >> > >> Greg, > >> > >> Are there any advantages to me using the Mantel/SuSE kernel > >> > >> over > >> > >> the > >> > >> > >> latest > >> > >> sources from sgi? > >> > >> > >> > >> Thanks, > >> > >> Anthon > >> > >> > >> > >> > Anthony, > >> > >> > > >> > >> > The notes at > >> > >> > >> ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/people/mante > >> > >> > >>l/ ne > >> > >> > >> > >> >xt/kernel-source.changes give you some of what you are asking > >> > >> about. > >> > >> > >> > Per the above, it is based on the 2.4.19-pre8aa1 kernel. I > >> > >> believe > >> > >> > >> > that already has the XFS patches in it, so you could look > >> > >> > into > >> > >> what > >> > >> > >> > it has. > >> > >> > > >> > >> > For details, I guess you need to download the source RPM and > >> > >> > read the specfile. > >> > >> > > >> > >> > Greg > >> > >> > > >> > >> > >> > Since you are using a SuSE distribution, have you > >> > >> > >> > thought about using > >> > >> > >> > >> > >> > >> the > >> > >> > >> > >> > >> > >> > SuSE experimental kernel from > >> > >> > >> > ftp://ftp.suse.com/pub/people/mantel/next/RPM/ > >> > >> > >> > > >> > >> > >> > It has all the standard SuSE patches and includes a > >> > >> > >> > relatively recent > >> > >> > >> > >> > >> > >> XFS. > >> > >> > >> > >> > >> > >> > Possibly XFS v1.1, but I'm not sure. > >> > >> > >> > >> > >> > >> I have the Mantel's latest kernel installed on my laptop > >> > >> > >> however > >> > >> > >> > >> I'm > >> > >> > >> > >> > >> not certain what it is that I have. What I mean by that > >> > >> > >> is > >> > >> how > >> > >> > >> > >> do I find out what XFS version and patch level do I have > >> > >> > >> so > >> > >> that > >> > >> > >> > >> I can decide on patch upgrades? I know it says kernel > >> > >> > >> 2.4.18 however is > >> > >> > >> > >> it > >> > >> > >> > >> > >> really 2.4.19 pre... . > >> > >> > >> As you can see, I'm not certain of the versions and > >> > >> > >> patch levels contained > >> > >> > >> > >> > >> > >> within the Mantel stuff. > >> > >> > >> > >> > >> > >> Anthony > >> > >> > >> > >> > >> > >> > FYI: The stock SuSE 8.0 kernel also has XFS support, > >> > >> > >> > but > >> > >> the > >> > >> > >> > >> > ACL > >> > >> > >> > >> > >> > >> handling > >> > >> > >> > >> > >> > >> > is broken in such a way that xfsdump/xfsrestore don't > >> > >> handle > >> > >> > >> > >> > ACLs correctly. > >> > >> > >> > > >> > >> > >> > Greg Freemyer > >> > >> > >> > Internet Engineer > >> > >> > >> > Deployment and Integration Specialist > >> > >> > >> > Compaq ASE - Tru64 > >> > >> > >> > Compaq Master ASE - SAN Architect > >> > >> > >> > The Norcross Group > >> > >> > >> > www.NorcrossGroup.com > >> > >> > >> > > >> > >> > >> > >> Steve, > >> > >> > >> > >> What do you recommend that I use since the box > >> > >> > >> > >> I'm building > >> > >> > >> > >> is > >> > >> > >> > >> > >> > >> a development > >> > >> > >> > >> box for myself which I will be using for > >> > >> > >> > >> development > >> > >> > >> > >> purposes > >> > >> > >> > >> > >> > >> and > >> > >> > >> > >> > >> > >> thus > >> > >> > >> > >> > >> > >> > >> will > >> > >> > >> > >> be using other cvs sources from other opesource > >> > >> projects > >> > >> > >> > >> > >> as well? > >> > >> > >> > >> > >> > >> > >> > >> Anthony > >> > >> > >> > >> > >> > >> > >> > >> > On Mon, 2002-06-03 at 13:26, Anthony W. Marino > >> > >> wrote: > >> > >> > >> > >> > > I'm building/setting-up a new server SuSE 7.3 > >> > >> which > >> > >> > >> > >> > >> > > will > >> > >> > >> > >> > >> > >> include > >> > >> > >> > >> > >> > >> > >> > > 3ware (7810) ide raid (10 or 5) with brand > >> > >> > >> > >> > > new drives > >> > >> > >> > >> and > >> > >> > >> > >> > >> > >> > > most likely LVM > >> > >> > >> > >> > >> > >> > >> > >> too. > >> > >> > >> > >> > >> > >> > >> > >> > > Should I get the kernel from oss.sgi.com cvs > >> > >> > >> > >> > > (CVSROOT=":pserver:cvs@oss.sgi.com:/cvs" > >> > >> > >> > >> > > linux-2.4-xfs) > >> > >> > >> > >> or > >> > >> > >> > >> > >> > >> > > is there another location/process that I > >> > >> > >> > >> > > should > >> > >> > >> > >> entertain? > >> > >> > >> > >> > >> > >> > > Also > >> > >> > >> > >> > >> > >> what > >> > >> > >> > >> > >> > >> > >> > > kernel release does the oss.sgi.com cvs > >> > >> > >> > >> > > sources > >> > >> give > >> > >> > >> > >> > >> > > me? > >> > >> > >> > >> > > > >> > >> > >> > >> > > Thank You, > >> > >> > >> > >> > > Anthony > >> > >> > >> > >> > > >> > >> > >> > >> > Right now it gives you 2.4.19-pre9 with xfs and > >> > >> > >> > >> > kdb (which you probably do not care about). > >> > >> > >> > >> > There are fixes in this > >> > >> > >> > >> tree > >> > >> > >> > >> > >> > >> > which > >> > >> > >> > >> > >> > >> are > >> > >> > >> > >> > >> > >> > >> > not available anywhere else, it is the most > >> > >> > >> > >> > direct link to XFS development. Of course this > >> > >> > >> > >> > also > >> > >> possibly > >> > >> > >> > >> > >> > means there > >> > >> > >> > >> are > >> > >> > >> > >> > >> > >> > bugs in this tree which are not available > >> > >> > >> > >> > anywhere else. > >> > >> > >> > >> > > >> > >> > >> > >> > Steve > >> > >> > > >> > >> > Greg Freemyer > >> > >> > Internet Engineer > >> > >> > Deployment and Integration Specialist > >> > >> > Compaq ASE - Tru64 > >> > >> > Compaq Master ASE - SAN Architect > >> > >> > The Norcross Group > >> > >> > www.NorcrossGroup.com > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:26:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54LQfnC011546 for ; Tue, 4 Jun 2002 14:26:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54LQf5A011545 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:26:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54LQTnC011512 for ; Tue, 4 Jun 2002 14:26:30 -0700 Received: from erbenson.alaska.net (110-pm18.nwc.alaska.net [209.112.142.110]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g54LSCX47132 for ; Tue, 4 Jun 2002 13:28:14 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id D9D7B3924 for ; Tue, 4 Jun 2002 13:27:59 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id D0CCA10294; Tue, 4 Jun 2002 13:27:59 -0800 (AKDT) Date: Tue, 4 Jun 2002 13:27:59 -0800 From: Ethan Benson To: "'linux-xfs@oss.sgi.com'" Subject: Re: probs with cp -p Message-ID: <20020604132759.L13201@plato.local.lan> Mail-Followup-To: "'linux-xfs@oss.sgi.com'" References: <200206032201.36167.mark.newman2@ntlworld.com> <20020604115218.D232510@wobbly.melbourne.sgi.com> <200206041056.45746.mark.newman2@ntlworld.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L1EIGrW/+75u5Nmw" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200206041056.45746.mark.newman2@ntlworld.com>; from mark.newman2@ntlworld.com on Tue, Jun 04, 2002 at 10:56:45AM +0000 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --L1EIGrW/+75u5Nmw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 04, 2002 at 10:56:45AM +0000, mark wrote: > On Tuesday 04 June 2002 01:52, Nathan Scott wrote: > > On Mon, Jun 03, 2002 at 10:01:36PM +0000, mark wrote: > > > Hi > > > > > > I've been having problems using the following with my xfs fs > > > > > > cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/ > > > > > > which returns the following > > > > > > cp: `/usr/local/share/mondo/restore-scripts.tgz': Argument list too l= ong > > > cp: preserving permissions for > > > `/home/mondo.scratch.19294/usr/local/share/mondo': Invalid argument > > > > Please try a more recent kernel, and let me know if the problem persist= s. > > This looks like a problem that was fixed in the ACL return codes a litt= le > > while ago. > > > > thanks. >=20 > Okay I have now tried a vanilla 2.4.18 with XFS 1.1 kernel (just to ensur= e it=20 > wasnt a problem with my patched 2.4.19) with similar results. 'Argument = too=20 > long' dissapeared but I still get the 'invalid argument' message. Could= =20 > there be some kind of problem with my filesystem. >=20 > Is there more info I could provide? i think he meant try current cvs as of yesterday, it looks suspiciously related to my report of acl_extended_file() lying. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --L1EIGrW/+75u5Nmw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjz9MN8ACgkQJKx7GixEevxPQQCgh6qG+UDkLQVhEV2MkmbNjDYE knYAn1S/YsBsNYQizUs4dZ347Bog3EbA =XAzX -----END PGP SIGNATURE----- --L1EIGrW/+75u5Nmw-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:35:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54LZ9nC011833 for ; Tue, 4 Jun 2002 14:35:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54LZ9ad011832 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:35:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54LYxnC011797 for ; Tue, 4 Jun 2002 14:34:59 -0700 Received: from erbenson.alaska.net (110-pm18.nwc.alaska.net [209.112.142.110]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g54Lal081614 for ; Tue, 4 Jun 2002 13:36:49 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id A43453924 for ; Tue, 4 Jun 2002 13:36:39 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id C72E510294; Tue, 4 Jun 2002 13:36:39 -0800 (AKDT) Date: Tue, 4 Jun 2002 13:36:39 -0800 From: Ethan Benson To: XFS list Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? Message-ID: <20020604133639.M13201@plato.local.lan> Mail-Followup-To: XFS list References: <1023218656.7905.19.camel@UberGeek> <1023218591.6937.52.camel@jen.americas.sgi.com> <1023223347.25693.10.camel@lucy> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aiCxlS1GuupXjEh3" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1023223347.25693.10.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Tue, Jun 04, 2002 at 02:42:27PM -0600 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --aiCxlS1GuupXjEh3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 04, 2002 at 02:42:27PM -0600, Alvaro Figueroa wrote: > > Only if you have hardware with a page size of 8K or greater, want > > to buy an ia64 box? >=20 > sparc64 works quite well. >=20 > BTW, what is needed, so that you guys can "offer" XFS as a stable > filesystem for some arquitecture other that ia(32|64)? the only thing in the ia64 patch is syscall entries iirc. other then syscall entries kdb is the only other somewhat non-portable peice of code, but its not really related to XFS. > (I specially want to know if there is anything I can do to help) the syscall issue should become irrelevant in 2.4.20 when Marcello is apparently going to merge the extended attributes API/syscalls. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --aiCxlS1GuupXjEh3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjz9MucACgkQJKx7GixEevylZgCfRRg33mZ0yC7On+Le00xCgp7V ehsAnAyhS6mh/zoi0cobr5hZ7mCEnTPD =LSh+ -----END PGP SIGNATURE----- --aiCxlS1GuupXjEh3-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:46:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54LkYnC012221 for ; Tue, 4 Jun 2002 14:46:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54LkYEW012220 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:46:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54LkQnC012151 for ; Tue, 4 Jun 2002 14:46:26 -0700 Received: from [172.19.20.63] (helo=mrvdomng2.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #3) id 17FMA2-0005uN-00; Tue, 4 Jun 2002 23:48:14 +0200 Received: from [217.228.157.102] (helo=kernelpanix.aura.of.mankind) by mrvdomng2.kundenserver.de with esmtp (Exim 3.22 #2) id 17FMA1-0002lJ-00; Tue, 04 Jun 2002 23:48:13 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id g54LY8c24232; Tue, 4 Jun 2002 23:34:08 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Tue, 4 Jun 2002 23:34:08 +0200 From: utz lehmann To: Austin Gonyou Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? Message-ID: <20020604233408.A24193@s2y4n2c.de> References: <1023220656.17830.42.camel@stout.americas.sgi.com> <1023224585.9286.1.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1023224585.9286.1.camel@UberGeek> X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk btw: is there any advantage for xfs if (hypotheitcally) using block size > page size? On an classic block allocation based fs you will gain performance due less fragmentation. But on xfs the files are stored in large contiguous extents. My guess is, that it will not make a difference, only space is wasted. utz Austin Gonyou [austin@coremetrics.com] wrote: > So say, with NTFS...you *can* do that..is that because they make it do > that..but it can be slower? > > On Tue, 2002-06-04 at 14:57, Eric Sandeen wrote: > > On Tue, 2002-06-04 at 14:57, Austin Gonyou wrote: > > > > > Ahh..I seee....so IA32 cannot handle this at all? > > > > There is no support in XFS for filesystem block size > page size for > > any > > architecture... > > > > -Eric > -- > Austin Gonyou > Systems Architect, CCNA > Coremetrics, Inc. > Phone: 512-698-7250 > email: austin@coremetrics.com > > "One ought never to turn one's back on a threatened danger and > try to run away from it. If you do that, you will double the danger. > But if you meet it promptly and without flinching, you will > reduce the danger by half." > Sir Winston Churchill From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:46:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54LkPnC012152 for ; Tue, 4 Jun 2002 14:46:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54LkPWQ012150 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:46:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54LkLnC012112 for ; Tue, 4 Jun 2002 14:46:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA70793 for ; Tue, 4 Jun 2002 16:48:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA30402 for ; Tue, 4 Jun 2002 16:48:10 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g54Li3e30449; Tue, 4 Jun 2002 16:44:03 -0500 Message-Id: <200206042144.g54Li3e30449@jen.americas.sgi.com> Date: Tue, 4 Jun 2002 16:44:03 -0500 Subject: TAKE - fix make deps for xfs To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 4 14:47:31 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:120803a linux/fs/xfs/Makefile - 1.143 - fix make dep for xfs From owner-linux-xfs@oss.sgi.com Tue Jun 4 14:50:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54LornC012637 for ; Tue, 4 Jun 2002 14:50:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54LorpO012636 for linux-xfs-outgoing; Tue, 4 Jun 2002 14:50:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.168]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54LofnC012598 for ; Tue, 4 Jun 2002 14:50:41 -0700 Received: (qmail 9767 invoked by uid 500); 4 Jun 2002 21:52:23 -0000 Subject: Re: Can I make my blocksize > 4k during mkfs.xfs? From: Austin Gonyou To: utz lehmann Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20020604233408.A24193@s2y4n2c.de> References: <20020604233408.A24193@s2y4n2c.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-encrypted"; boundary="=-UNBNDKFmXt8N4fo9GMBS" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jun 2002 16:52:23 -0500 Message-Id: <1023227543.9289.6.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-UNBNDKFmXt8N4fo9GMBS Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Good to know..thanks for the feedback! On Tue, 2002-06-04 at 16:34, utz lehmann wrote: > btw: is there any advantage for xfs if (hypotheitcally) using=20 > block size > page size? >=20 > On an classic block allocation based fs you will gain performance due > less > fragmentation. But on xfs the files are stored in large contiguous > extents. >=20 > My guess is, that it will not make a difference, only space is wasted. >=20 >=20 > utz >=20 > Austin Gonyou [austin@coremetrics.com] wrote: > > So say, with NTFS...you *can* do that..is that because they make it > do > > that..but it can be slower? > >=20 > > On Tue, 2002-06-04 at 14:57, Eric Sandeen wrote: > > > On Tue, 2002-06-04 at 14:57, Austin Gonyou wrote: > > >=20 > > > > Ahh..I seee....so IA32 cannot handle this at all? > > >=20 > > > There is no support in XFS for filesystem block size > page size > for > > > any > > > architecture... > > >=20 > > > -Eric > > --=20 > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-698-7250 > > email: austin@coremetrics.com > >=20 > > "One ought never to turn one's back on a threatened danger and=20 > > try to run away from it. If you do that, you will double the danger. > > But if you meet it promptly and without flinching, you will=20 > > reduce the danger by half." > > Sir Winston Churchill --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-UNBNDKFmXt8N4fo9GMBS Content-Type: application/pgp-encrypted; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8/TaX94g6ZVmFMoIRAgiTAKDaaxRwU//8GFALOhZV2FNg49D65wCfTBkY 4QFWD8mwAFb8paZIATK3MiI= =34+5 -----END PGP SIGNATURE----- --=-UNBNDKFmXt8N4fo9GMBS-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 16:00:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g54N0rnC014244 for ; Tue, 4 Jun 2002 16:00:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g54N0r06014243 for linux-xfs-outgoing; Tue, 4 Jun 2002 16:00:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g54N0jnC014215 for ; Tue, 4 Jun 2002 16:00:46 -0700 Received: from localhost ([80.1.68.230]) by mta06-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020603173632.ILLA4119.mta06-svc.ntlworld.com@localhost> for ; Mon, 3 Jun 2002 18:36:32 +0100 Content-Type: text/plain; charset="iso-8859-1" From: mark Reply-To: mark.newman2@ntlworld.com To: linux-xfs@oss.sgi.com Subject: problems with cp -p Date: Mon, 3 Jun 2002 17:21:50 +0000 User-Agent: KMail/1.4.1 References: <200206031725.g53HPEBm003142@oss.sgi.com> In-Reply-To: <200206031725.g53HPEBm003142@oss.sgi.com> MIME-Version: 1.0 Message-Id: <200206031721.50727.mark.newman2@ntlworld.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g54N0knC014216 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I have been using XFS for a while with no problems. However I have recently moved to Gentoo linux and backups are now much more critical to me. I am trying to use Mondo Rescue as a backup program and one of the commands it uses is as follows cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/ which returns the following cp: `/usr/local/share/mondo/restore-scripts.tgz': Argument list too long cp: preserving permissions for `/home/mondo.scratch.19294/usr/local/share/mondo': Invalid argument it seems to be the -p switch which causes this. It has been suggested that this could be a problem with XFS (I am running version 1.1) My kernel is a Gentoo supplied patched kernel. I could possibly try a more vanilla one. Perhaps someone could try cp on a directory with these arguments and see if they can duplicate these results Any help is appreciated. Regards Mark From owner-linux-xfs@oss.sgi.com Tue Jun 4 18:07:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5517vnC017480 for ; Tue, 4 Jun 2002 18:07:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5517v1D017479 for linux-xfs-outgoing; Tue, 4 Jun 2002 18:07:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5517nnC017451 for ; Tue, 4 Jun 2002 18:07:50 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA06047 for ; Tue, 4 Jun 2002 18:09:35 -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 LAA24320; Wed, 5 Jun 2002 11:08:18 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA70543; Wed, 5 Jun 2002 11:08:16 +1000 (AEST) Date: Wed, 5 Jun 2002 11:08:16 +1000 From: Nathan Scott To: Austin Gonyou Cc: linux-xfs Subject: Re: Invalid argument when trying to set the blocksize. Message-ID: <20020605110816.E226988@wobbly.melbourne.sgi.com> References: <1023219336.7927.25.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1023219336.7927.25.camel@UberGeek>; from austin@coremetrics.com on Tue, Jun 04, 2002 at 02:35:36PM -0500 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 04, 2002 at 02:35:36PM -0500, Austin Gonyou wrote: > I try to perform the following: > > mkfs.xfs -b size=8192 /dev/data/datavol1 > > The fs is made on the volume, but I get the following message: > > mkfs.xfs: warning - cannot set blocksize on block device > /dev/data/datavol1: Invalid argument > > > I'm using LVM 1.1rc2 tools, and have a 2.4.19-pre9-aa2 kernel. > > Is this another one of those ioctl() things that's depricated or is it > something else. TIA This block device doesn't support the BLKBSZSET ioctl - it's missing functionality, not something that's deprecated. It also returns the wrong errno for an unrecognised ioctl (should be ENOTTY apparently). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jun 4 18:21:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g551L0nC017753 for ; Tue, 4 Jun 2002 18:21:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g551L0A2017752 for linux-xfs-outgoing; Tue, 4 Jun 2002 18:21:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.168]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g551KonC017708 for ; Tue, 4 Jun 2002 18:20:51 -0700 Received: (qmail 10908 invoked by uid 500); 5 Jun 2002 01:22:26 -0000 Subject: Re: Invalid argument when trying to set the blocksize. From: Austin Gonyou To: Nathan Scott Cc: linux-xfs In-Reply-To: <20020605110816.E226988@wobbly.melbourne.sgi.com> References: <20020605110816.E226988@wobbly.melbourne.sgi.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-encrypted"; boundary="=-wdGRPk7d66fEoknVhhKw" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 04 Jun 2002 20:22:26 -0500 Message-Id: <1023240146.10758.2.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-wdGRPk7d66fEoknVhhKw Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-06-04 at 20:08, Nathan Scott wrote: ... > This block device doesn't support the BLKBSZSET ioctl - it's missing > functionality, not something that's deprecated. It also returns the > wrong errno for an unrecognised ioctl (should be ENOTTY apparently). >=20 > cheers. Ok. That's what it seems like as well..I just wasn't getting this error before 2.4.19.(previous kernel was 2.4.6) I did rev back to lvmtools 0.9.7, and it's all good now.(sort of:)) > --=20 > Nathan --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "One ought never to turn one's back on a threatened danger and=20 try to run away from it. If you do that, you will double the danger.=20 But if you meet it promptly and without flinching, you will=20 reduce the danger by half." Sir Winston Churchill --=-wdGRPk7d66fEoknVhhKw Content-Type: application/pgp-encrypted; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA8/WfR94g6ZVmFMoIRAlbyAKCsgqFI2ON5D20nUuWwlfUwfalMIwCguhY5 TteoqOOV/REPU1do8hidr9M= =zMNe -----END PGP SIGNATURE----- --=-wdGRPk7d66fEoknVhhKw-- From owner-linux-xfs@oss.sgi.com Tue Jun 4 18:24:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g551OqnC017950 for ; Tue, 4 Jun 2002 18:24:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g551Oqsm017949 for linux-xfs-outgoing; Tue, 4 Jun 2002 18:24:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g551OlnC017921 for ; Tue, 4 Jun 2002 18:24:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA01576 for ; Tue, 4 Jun 2002 18:26:41 -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 LAA38286 for linux-xfs@oss.sgi.com; Wed, 5 Jun 2002 11:25:19 +1000 (EST) Date: Wed, 5 Jun 2002 11:25:19 +1000 (EST) From: Nathan Scott Message-Id: <200206050125.LAA38286@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfsprogs X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 4 18:22:08 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:120848a cmd/xfsprogs/doc/CHANGES - 1.68 - update for repair & man page changes. cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.8 - document current blocksize status. cmd/xfsprogs/repair/phase6.c - 1.10 - Take the parent inode number into account when calculating i8count. Do not skip updating the i8count when dealing with regular files. PV 855721. cmd/xfsprogs/repair/dir2.c - 1.8 - Take the parent inode number into account when calculating i8count - PV 855721. From owner-linux-xfs@oss.sgi.com Tue Jun 4 18:34:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g551YJnC018147 for ; Tue, 4 Jun 2002 18:34:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g551YJto018146 for linux-xfs-outgoing; Tue, 4 Jun 2002 18:34:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g551YEnC018116 for ; Tue, 4 Jun 2002 18:34:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA06241 for ; Tue, 4 Jun 2002 18:36:08 -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 LAA24566; Wed, 5 Jun 2002 11:34:51 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA36520; Wed, 5 Jun 2002 11:34:50 +1000 (AEST) Date: Wed, 5 Jun 2002 11:34:50 +1000 From: Nathan Scott To: mark Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: probs with cp -p Message-ID: <20020605113450.F226988@wobbly.melbourne.sgi.com> References: <200206032201.36167.mark.newman2@ntlworld.com> <20020604115218.D232510@wobbly.melbourne.sgi.com> <200206041056.45746.mark.newman2@ntlworld.com> <20020604132759.L13201@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020604132759.L13201@plato.local.lan>; from erbenson@alaska.net on Tue, Jun 04, 2002 at 01:27:59PM -0800 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 04, 2002 at 01:27:59PM -0800, Ethan Benson wrote: > On Tue, Jun 04, 2002 at 10:56:45AM +0000, mark wrote: > > > > Okay I have now tried a vanilla 2.4.18 with XFS 1.1 kernel (just to ensure it > > wasnt a problem with my patched 2.4.19) with similar results. 'Argument too > > long' dissapeared but I still get the 'invalid argument' message. Could > > there be some kind of problem with my filesystem. I doubt it, this error is more likely a coding issue in the kernel, rather than an on-disk problem. > > Is there more info I could provide? > > i think he meant try current cvs as of yesterday, it looks There have been several related fixes, incl. yesterdays fix - please try a current CVS kernel, Mark & let me know if it still fails. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jun 4 22:20:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g555KPnC020073 for ; Tue, 4 Jun 2002 22:20:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g555KP3r020072 for linux-xfs-outgoing; Tue, 4 Jun 2002 22:20:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mel-rto2.wanadoo.fr (smtp-out-2.wanadoo.fr [193.252.19.254]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g555KGnC020041 for ; Tue, 4 Jun 2002 22:20:17 -0700 Received: from mel-rta7.wanadoo.fr (193.252.19.61) by mel-rto2.wanadoo.fr (6.5.007) id 3CFB20330015E23A; Wed, 5 Jun 2002 07:17:56 +0200 Received: from wanadoo.fr (80.11.212.138) by mel-rta7.wanadoo.fr (6.5.007) id 3CFB1EED0014FFB6; Wed, 5 Jun 2002 07:17:56 +0200 Message-ID: <3CFD9E44.7060800@wanadoo.fr> Date: Wed, 05 Jun 2002 07:14:44 +0200 From: Fabrice Ferrero Organization: Cap Gemini User-Agent: Mozilla/5.0 (Windows; U; Win98; fr-FR; rv:1.0rc2) Gecko/20020512 Netscape/7.0b1 X-Accept-Language: fr,en MIME-Version: 1.0 To: Svetoslav Slavtchev CC: "linux-xfs@oss.sgi.com" Subject: Re: [2.5.20-dj1]ld: cannot open xfs_dmapi/built-in.o: No such file or directory References: <3CFD1807.4020407@st-peter.stw.uni-erlangen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id g555KHnC020042 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've got quite the same problem when trying to compile another 2.4.18 kernel with gcc 3.1. So I came back to 3.0.4 and all work well. What's your release of gcc ? Fab Svetoslav Slavtchev a écrit: > Ralf G. R. Bergs wrote: > >> On Tue, 04 Jun 2002 20:58:48 +0200, Svetoslav Slavtchev wrote: >> >> >> >>> ld: cannot open xfs_dmapi/built-in.o: No such file or directory >>> >> >> >> Do you have DMAPI configured as a module? That doesn't work, IIRC. >> You need to configure it into the kernel, then it will link properly. >> >> >> >> > well it's configured built in, > the error comes by making bzImage > > root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# cat .config | grep XFS > CONFIG_VXFS_FS=m > CONFIG_XFS_FS=y > CONFIG_XFS_RT=y > CONFIG_XFS_QUOTA=y > CONFIG_XFS_DMAPI=y > CONFIG_XFS_DMAPI=y > CONFIG_HAVE_XFS_DMAPI=y > [root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# > > From owner-linux-xfs@oss.sgi.com Wed Jun 5 01:15:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g558F9nC022272 for ; Wed, 5 Jun 2002 01:15:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g558F9PL022271 for linux-xfs-outgoing; Wed, 5 Jun 2002 01:15:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g558EsnC022239 for ; Wed, 5 Jun 2002 01:14:58 -0700 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 17FVy9-0005zb-00; Wed, 05 Jun 2002 10:16:37 +0200 Message-ID: <3CFDC94C.8050905@st-peter.stw.uni-erlangen.de> Date: Wed, 05 Jun 2002 10:18:20 +0200 From: Svetoslav Slavtchev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fabrice Ferrero CC: "linux-xfs@oss.sgi.com" Subject: Re: [2.5.20-dj1]ld: cannot open xfs_dmapi/built-in.o: No such file or directory References: <3CFD1807.4020407@st-peter.stw.uni-erlangen.de> <3CFD9E44.7060800@wanadoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *17FVy9-0005zb-00*4j/uU3yue3s* (Studentenwohnanlage Nuernberg St.-Peter) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I've got quite the same problem when trying to compile another 2.4.18 > kernel with gcc 3.1. So I came back to 3.0.4 and all work well. > What's your release of gcc ? > Fab it's gcc-3.1.1 i'll try with 3.0.4 ant let you now svetljo >>>> ld: cannot open xfs_dmapi/built-in.o: No such file or directory >>>> >>> >>> >>> >>> Do you have DMAPI configured as a module? That doesn't work, IIRC. >>> You need to configure it into the kernel, then it will link properly. >>> >>> >>> >>> >> well it's configured built in, >> the error comes by making bzImage >> >> root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# cat .config | grep XFS >> CONFIG_VXFS_FS=m >> CONFIG_XFS_FS=y >> CONFIG_XFS_RT=y >> CONFIG_XFS_QUOTA=y >> CONFIG_XFS_DMAPI=y >> CONFIG_XFS_DMAPI=y >> CONFIG_HAVE_XFS_DMAPI=y >> [root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# >> >> From owner-linux-xfs@oss.sgi.com Wed Jun 5 02:13:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g559DCnC022974 for ; Wed, 5 Jun 2002 02:13:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g559DCsZ022973 for linux-xfs-outgoing; Wed, 5 Jun 2002 02:13:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g559D2nC022944 for ; Wed, 5 Jun 2002 02:13:03 -0700 Received: from svetljo.st-peter.stw.uni-erlangen.de ([172.17.17.181] helo=st-peter.stw.uni-erlangen.de) by voyager.st-peter.stw.uni-erlangen.de with esmtp (Exim 3.12 #1 (Debian)) id 17FWsV-0006OI-00; Wed, 05 Jun 2002 11:14:51 +0200 Message-ID: <3CFDD6F3.3010206@st-peter.stw.uni-erlangen.de> Date: Wed, 05 Jun 2002 11:16:35 +0200 From: Svetoslav Slavtchev User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/00200205 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fabrice Ferrero CC: "linux-xfs@oss.sgi.com" Subject: Re: [2.5.20-dj1]ld: cannot open xfs_dmapi/built-in.o: No such file or directory References: <3CFD1807.4020407@st-peter.stw.uni-erlangen.de> <3CFD9E44.7060800@wanadoo.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *17FWsV-0006OI-00*83lzL1guyzg* (Studentenwohnanlage Nuernberg St.-Peter) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fabrice Ferrero wrote: > I've got quite the same problem when trying to compile another 2.4.18 > kernel with gcc 3.1. So I came back to 3.0.4 and all work well. > What's your release of gcc ? > Fab doesn't helped :) svetljo > >>> >>>> ld: cannot open xfs_dmapi/built-in.o: No such file or directory >>>> >>> >>> >>> >>> Do you have DMAPI configured as a module? That doesn't work, IIRC. >>> You need to configure it into the kernel, then it will link properly. >>> >>> >>> >>> >> well it's configured built in, >> the error comes by making bzImage >> >> root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# cat .config | grep XFS >> CONFIG_VXFS_FS=m >> CONFIG_XFS_FS=y >> CONFIG_XFS_RT=y >> CONFIG_XFS_QUOTA=y >> CONFIG_XFS_DMAPI=y >> CONFIG_XFS_DMAPI=y >> CONFIG_HAVE_XFS_DMAPI=y >> [root@svetljo linux-2.5.20-dj1-lvm-xfs-w1]# >> >> > > > From owner-linux-xfs@oss.sgi.com Wed Jun 5 03:22:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55AMYnC025015 for ; Wed, 5 Jun 2002 03:22:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55AMY69025014 for linux-xfs-outgoing; Wed, 5 Jun 2002 03:22:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55AMSnC024983 for ; Wed, 5 Jun 2002 03:22:29 -0700 Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) 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 DAA00188 for ; Wed, 5 Jun 2002 03:24:19 -0700 (PDT) mail_from (Florian.Lindner@xgm.de) Received: from fwd02.sul.t-online.de by mailout01.sul.t-online.com with smtp id 17FXnu-0004UT-04; Wed, 05 Jun 2002 12:14:10 +0200 Received: from horus.xgm.de (340060635977-0001@[80.129.22.204]) by fmrl02.sul.t-online.com with esmtp id 17FXnd-1vdvKCC; Wed, 5 Jun 2002 12:13:53 +0200 Received: from florian (unknown [192.168.0.2]) by horus.xgm.de (Postfix) with SMTP id 7D3E359 for ; Wed, 5 Jun 2002 12:11:59 +0200 (CEST) Message-ID: <003601c20c7a$2e04b8c0$0200a8c0@florian> From: "Florian Lindner" To: Subject: XFS installer for Redhat Date: Wed, 5 Jun 2002 12:17:21 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 340060635977-0001@t-dialin.net X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, does anybody have experiencies with the Redhat installer from ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/installer/i386/ Does anybody has tried that? It is supposed to be stable enough for everyday use? Thx, Florian [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jun 5 04:00:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55B0OnC025459 for ; Wed, 5 Jun 2002 04:00:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55B0Oaq025458 for linux-xfs-outgoing; Wed, 5 Jun 2002 04:00:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55B00nC025412 for ; Wed, 5 Jun 2002 04:00:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA74185 for ; Wed, 5 Jun 2002 06:01:52 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-33.corp.sgi.com [134.15.64.33]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA74468 for ; Wed, 5 Jun 2002 06:01:51 -0500 (CDT) From: Steve Lord Received: by snafu (8.11.6/SGI-client-1.7) id g55Avdr08101; Wed, 5 Jun 2002 05:57:39 -0500 Message-Id: <200206051057.g55Avdr08101@snafu> Date: Wed, 5 Jun 2002 05:57:39 -0500 Subject: TAKE - merge up to 2.4.19-pre10 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just keeping up with Marcelo until 2.4.19 comes out. Date: Wed Jun 5 03:58:09 PDT 2002 Workarea: cf-vpn-sw-corp-64-33.corp.sgi.com:/home/lord/src/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120869a linux/net/sched/sch_api.c - 1.13 linux/net/ipv6/raw.c - 1.23 linux/net/ipv4/tcp_ipv4.c - 1.43 linux/net/ipv4/tcp_input.c - 1.36 linux/net/ipv4/tcp.c - 1.38 linux/net/ipv4/syncookies.c - 1.14 linux/net/ipv4/route.c - 1.33 linux/net/ipv4/ip_output.c - 1.31 linux/net/core/sock.c - 1.25 linux/net/core/neighbour.c - 1.15 linux/mm/slab.c - 1.30 linux/lib/vsprintf.c - 1.16 linux/kernel/exit.c - 1.36 linux/ipc/sem.c - 1.16 linux/include/net/route.h - 1.16 linux/include/net/pkt_sched.h - 1.10 linux/include/linux/slab.h - 1.21 linux/include/linux/coda_psdev.h - 1.8 linux/include/linux/coda_fs_i.h - 1.9 linux/include/asm-sparc64/ide.h - 1.11 linux/fs/ufs/super.c - 1.22 linux/fs/proc/array.c - 1.33 linux/fs/dcache.c - 1.32 linux/fs/coda/inode.c - 1.17 linux/fs/coda/file.c - 1.19 linux/fs/coda/cnode.c - 1.14 linux/fs/binfmt_misc.c - 1.17 linux/drivers/video/fbmem.c - 1.45 linux/drivers/usb/Makefile - 1.48 linux/drivers/sound/sb_card.c - 1.32 linux/drivers/sound/opl3sa2.c - 1.14 linux/drivers/sound/msnd_pinnacle.c - 1.20 linux/drivers/sound/mpu401.c - 1.14 linux/drivers/sound/ad1848.c - 1.15 linux/drivers/sound/Config.in - 1.31 linux/drivers/sgi/char/sgiserial.c - 1.11 linux/drivers/scsi/sg.c - 1.27 linux/drivers/scsi/scsi_ioctl.c - 1.21 linux/drivers/scsi/qlogicfc.c - 1.26 linux/drivers/scsi/aha152x.h - 1.7 linux/drivers/scsi/aha152x.c - 1.26 linux/drivers/pci/quirks.c - 1.29 linux/drivers/net/via-rhine.c - 1.34 linux/drivers/net/pcnet32.c - 1.32 linux/drivers/net/eepro100.c - 1.41 linux/drivers/net/de4x5.c - 1.25 linux/drivers/net/cs89x0.h - 1.6 linux/drivers/net/cs89x0.c - 1.22 linux/drivers/net/acenic.c - 1.38 linux/drivers/net/3c59x.c - 1.34 linux/drivers/net/3c509.c - 1.28 linux/drivers/macintosh/via-pmu.c - 1.19 linux/drivers/char/tpqic02.c - 1.17 linux/drivers/char/stallion.c - 1.19 linux/drivers/char/rtc.c - 1.27 linux/drivers/char/pty.c - 1.13 linux/drivers/char/pcwd.c - 1.17 linux/drivers/char/n_tty.c - 1.13 linux/drivers/char/istallion.c - 1.19 linux/drivers/char/epca.c - 1.19 linux/drivers/block/swim3.c - 1.15 linux/drivers/block/paride/pt.c - 1.14 linux/drivers/block/paride/pg.c - 1.13 linux/drivers/block/paride/paride.c - 1.11 linux/drivers/acorn/block/mfmhd.c - 1.17 linux/arch/ppc/kernel/irq.c - 1.33 linux/arch/i386/kernel/signal.c - 1.22 linux/Makefile - 1.171 linux/Documentation/video4linux/API.html - 1.5 linux/Documentation/networking/cs89x0.txt - 1.9 linux/CREDITS - 1.70 linux/drivers/char/sx.c - 1.24 linux/include/linux/irq.h - 1.10 linux/drivers/net/fc/iph5526.c - 1.18 linux/drivers/atm/horizon.c - 1.11 linux/drivers/scsi/ips.c - 1.23 linux/drivers/block/swim_iop.c - 1.9 linux/arch/i386/kernel/pci-pc.c - 1.33 linux/include/linux/pci_ids.h - 1.57 linux/drivers/net/wan/sdla_fr.c - 1.18 linux/mm/bootmem.c - 1.18 linux/fs/proc/proc_misc.c - 1.29 linux/drivers/pci/pci.ids - 1.42 linux/drivers/sound/trident.c - 1.34 linux/net/sched/sch_ingress.c - 1.9 linux/drivers/char/mxser.c - 1.15 linux/drivers/scsi/scsi_scan.c - 1.23 linux/Documentation/DMA-mapping.txt - 1.14 linux/include/asm-sparc/ide.h - 1.8 linux/drivers/sound/ac97_codec.c - 1.23 linux/drivers/sound/via82cxxx_audio.c - 1.26 linux/drivers/net/8139too.c - 1.36 linux/Documentation/networking/8139too.txt - 1.17 linux/drivers/net/tulip/tulip_core.c - 1.40 linux/drivers/net/tulip/21142.c - 1.12 linux/arch/mips64/kernel/linux32.c - 1.13 linux/drivers/sound/mpu401.h - 1.5 linux/drivers/ide/ide-floppy.c - 1.13 linux/Documentation/DocBook/kernel-api.tmpl - 1.14 linux/net/ipv4/netfilter/ipchains_core.c - 1.10 linux/drivers/sound/dmasound/dmasound_core.c - 1.11 linux/drivers/sound/i810_audio.c - 1.23 linux/arch/s390/kernel/ptrace.c - 1.8 linux/drivers/input/joydev.c - 1.7 linux/drivers/net/tulip/ChangeLog - 1.15 linux/drivers/video/sis/Makefile - 1.6 linux/drivers/video/sis/initdef.h - 1.4 linux/drivers/video/sis/sis_main.c - 1.10 linux/include/linux/ethtool.h - 1.10 linux/drivers/video/riva/accel.c - 1.4 linux/arch/s390x/kernel/ptrace.c - 1.7 linux/arch/s390x/kernel/debug.c - 1.6 linux/arch/s390/kernel/debug.c - 1.6 linux/drivers/char/machzwd.c - 1.6 linux/drivers/block/paride/bpck6.c - 1.5 linux/fs/nls/nls_koi8-ru.c - 1.3 linux/drivers/net/dl2k.h - 1.7 linux/drivers/net/dl2k.c - 1.10 linux/arch/ppc/kernel/cputable.c - 1.5 linux/drivers/video/sstfb.h - 1.4 linux/drivers/video/sstfb.c - 1.6 linux/Documentation/fb/README-sstfb.txt - 1.3 linux/drivers/sound/ite8172.c - 1.5 linux/scripts/mkspec - 1.4 linux/drivers/video/sis/300vtbl.h - 1.3 linux/drivers/video/sis/310vtbl.h - 1.3 linux/drivers/video/sis/init.c - 1.3 linux/drivers/video/sis/init.h - 1.3 linux/drivers/video/sis/init301.c - 1.3 linux/drivers/video/sis/init301.h - 1.3 linux/drivers/video/sis/oem300.h - 1.3 linux/drivers/video/sis/oem310.h - 1.3 linux/drivers/video/sis/sis_main.h - 1.3 linux/drivers/video/sis/vgatypes.h - 1.3 linux/fs/intermezzo/ext_attr.c - 1.2 linux/fs/intermezzo/kml.c - 1.2 linux/fs/intermezzo/psdev.c - 1.5 linux/drivers/hotplug/Config.in - 1.3 linux/drivers/net/mii.c - 1.2 linux/include/asm-ppc/pmac_feature.h - 1.3 linux/arch/ppc/kernel/pmac_feature.c - 1.3 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.3 linux/drivers/block/umem.c - 1.2 linux/drivers/net/tg3.c - 1.2 linux/drivers/net/tg3.h - 1.2 linux/drivers/net/wan/8253x/8253xmac.c - 1.2 linux/drivers/net/wan/8253x/8253xpeer.c - 1.2 linux/drivers/net/wan/8253x/8253xspeed.c - 1.2 linux/drivers/net/wan/8253x/8253xutl.c - 1.2 linux/drivers/net/wan/8253x/Makefile - 1.2 linux/drivers/net/wan/8253x/eprom9050.c - 1.2 linux/drivers/sound/au1000.c - 1.2 linux/drivers/sound/swarm_cs4297a.c - 1.2 linux/drivers/usb/auerswald.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jun 5 04:07:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55B7bnC027318 for ; Wed, 5 Jun 2002 04:07:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55B7bYT027317 for linux-xfs-outgoing; Wed, 5 Jun 2002 04:07:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55B7TnC027287 for ; Wed, 5 Jun 2002 04:07:29 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g55B9NiR072234; Wed, 5 Jun 2002 13:09:24 +0200 (CEST) Message-Id: <4.3.2.7.2.20020605130314.039695c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 05 Jun 2002 13:10:14 +0200 To: "Florian Lindner" , From: Seth Mos Subject: Re: XFS installer for Redhat In-Reply-To: <003601c20c7a$2e04b8c0$0200a8c0@florian> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:17 5-6-2002 +0200, Florian Lindner wrote: >Hello, >does anybody have experiencies with the Redhat installer from >ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/installer/i386/ >Does anybody has tried that? It is supposed to be stable enough for everyday >use? >Thx, >Florian I did test the kernel from this installer (2.4.18 Red Hat based) on a medium sized ia32 box and it did well. It was a dual 1.4Ghz PIII and 2GB ram with a hardware raid 10. I tried some local mongo.pl runs with a lot of processes and bonnie++ runs back to back for a day over NFS (gigabit ethernet). Not too stellar scores (hardware raid limit) but the machine survived none the less. NFS performance was about 500Mbps but this was limited by the desktop client machine. Don't forget to make your network buffers larger if you have gigabit ethernet if you want some return on investment ;) Otherwise it is just like having 100Mbit ethernet. I have not tested the installer part due to time shortage. I think Eric did test this before releasing it. Eric you did test it by upgrading did you :) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jun 5 04:57:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55Bv2nC027968 for ; Wed, 5 Jun 2002 04:57:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55Bv2JM027967 for linux-xfs-outgoing; Wed, 5 Jun 2002 04:57:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from eagle.oceana.com (eagle.oceana.com [208.17.123.12]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55BusnC027929 for ; Wed, 5 Jun 2002 04:56:54 -0700 Received: from oceana.com (ppp0.oceana.com [192.168.10.242]) by eagle.oceana.com (8.12.4/8.12.4) with ESMTP id g55BwiNG000372; Wed, 5 Jun 2002 07:58:45 -0400 Message-ID: <3CFDFBDE.7030908@oceana.com> Date: Wed, 05 Jun 2002 07:54:06 -0400 From: Ken Murchison Organization: Oceana Matrix Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seth Mos CC: Florian Lindner , linux-xfs@oss.sgi.com Subject: Re: XFS installer for Redhat References: <4.3.2.7.2.20020605130314.039695c8@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > At 12:17 5-6-2002 +0200, Florian Lindner wrote: > >> Hello, >> does anybody have experiencies with the Redhat installer from >> ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/installer/i386/ >> >> Does anybody has tried that? It is supposed to be stable enough for >> everyday >> use? >> Thx, >> Florian > > [...] > > I have not tested the installer part due to time shortage. I think Eric > did test this before releasing it. Eric you did test it by upgrading did > you :) I used it to upgrade my laptop. No problems yet, but I'm not really stressing it. The only thing that I noticed during the upgrade is that it removed my old kernel packages, but didn't remove the relevent grub.conf entries. Of course, this might be a problem with the RH installer. Ken -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp From owner-linux-xfs@oss.sgi.com Wed Jun 5 05:45:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55CjZnC028575 for ; Wed, 5 Jun 2002 05:45:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55CjZYB028574 for linux-xfs-outgoing; Wed, 5 Jun 2002 05:45:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from pina.terra.com.br (pina.terra.com.br [200.176.3.17]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55CjPnC028545 for ; Wed, 5 Jun 2002 05:45:25 -0700 Received: from bica.terra.com.br (bica.terra.com.br [200.176.3.32]) by pina.terra.com.br (Postfix) with ESMTP id E7D0253020 for ; Wed, 5 Jun 2002 09:47:21 -0300 (EST) Received: from johnnie.walker.absoluta.intra (cm-net-poa-C8B028F1.brdterra.com.br [200.176.40.241]) (authenticated user abslucio) by bica.terra.com.br (Postfix) with ESMTP id 97620D5418 for ; Wed, 5 Jun 2002 09:47:21 -0300 (EST) Subject: SMBFS mount error whit 2.4.18-xfs-1.1 From: Lucio Maciel To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Jun 2002 09:45:12 -0300 Message-Id: <1023281113.4746.33.camel@johnnie> Mime-Version: 1.0 X-Spam-Status: No, hits=0.9 required=5.0 tests=URI_IS_POUND version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, i tryed to use sambafs as a module in 2.4.18-xfs-1.1 but i get the following error root@johnnie:~# smbd -V Version 2.2.4 root@johnnie:~# uname -a Linux johnnie 2.4.18-xfs-1.1 #6 Tue Jun 4 18:15:01 BRT 2002 i686 unknown root@johnnie:~# smbmount //viking/projetos /mnt/projetos -o username=lucio Password: <1>Unable to handle kernel NULL pointer dereference at virtual address 000000d4 printing eip: d084e410 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010206 eax: 000000cc ebx: ce2a6a00 ecx: ce324400 edx: ce3253c0 esi: d08522bd edi: ce709c88 ebp: ce3244cc esp: ce191e60 ds: 0018 es: 0018 ss: 0018 Process smbmnt (pid: 163, stackpage=ce191000) Stack: d08504fc ce3253c0 ce324400 00000000 ce324448 00000000 ce709c88 ce326f40 73726576 00000010 00000002 000141ed 00000000 00000000 00000000 00001000 00000000 3cfbb160 00000000 00001000 00000008 c013225a ce324400 ce153000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 40 08 f6 40 10 08 74 09 c7 42 4c 38 28 85 d0 eb 07 c7 42 mount.smbfs[162]: ioctl failed, res=-1 162: Could not umount /mnt/projetos: Invalid argument with samba as built-in int the kernel, no errors... mount external volumes fine... Lucio Maciel abslucio@terra.com.br From owner-linux-xfs@oss.sgi.com Wed Jun 5 06:00:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55D0mnC029553 for ; Wed, 5 Jun 2002 06:00:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55D0mdW029552 for linux-xfs-outgoing; Wed, 5 Jun 2002 06:00:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55D0gnC029492 for ; Wed, 5 Jun 2002 06:00:42 -0700 Received: from terra.it (156.107-30-212.9massy1-1-ro-as-i4-2.9tel.net [212.30.107.156]) by smtp4.9tel.net (Postfix) with ESMTP id E43AF5C09F; Wed, 5 Jun 2002 14:59:46 +0200 (CEST) Message-ID: <124892002635125653816@terra.it> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: surprise@imp20.com To: "." From: "Chiamami" Subject: Qualcuno ti ama in segreto Date: Wed, 5 Jun 2002 14:56:53 +0200 MIME-Version: 1.0 X-Spam-Status: No, hits=0.6 required=5.0 tests=FROM_ENDS_IN_NUMS,X_EM_VER_PRESENT,TO_BE_REMOVED_REPLY,DIFFERENT_REPLY_TO,FROM_AND_TO_SAME version=2.20 X-Spam-Level: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Jun 5 08:13:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55FD7nC008454 for ; Wed, 5 Jun 2002 08:13:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55FD7td008453 for linux-xfs-outgoing; Wed, 5 Jun 2002 08:13:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55FD0nC008357 for ; Wed, 5 Jun 2002 08:13:01 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA75414 for ; Wed, 5 Jun 2002 10:14:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA85194 for ; Wed, 5 Jun 2002 10:14:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g55FAcZ22416; Wed, 5 Jun 2002 10:10:38 -0500 Message-Id: <200206051510.g55FAcZ22416@jen.americas.sgi.com> Date: Wed, 5 Jun 2002 10:10:38 -0500 Subject: TAKE - fix a locking window To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A hole in buffered vs direct I/O coherency - a buffered writer can get data into cache between the direct write flushing the cache and doing its own write. Actually not a real issue on Linux due to the i_sem lock held for all writes. Date: Wed Jun 5 08:04:30 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120873a linux/fs/xfs/xfs_rw.c - 1.357 - Use lock demote rather than unlock/relock to move from a write to a read level of the IO lock. This closes a window where a buffered write could get in. From owner-linux-xfs@oss.sgi.com Wed Jun 5 08:26:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55FQWnC013441 for ; Wed, 5 Jun 2002 08:26:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55FQW62013440 for linux-xfs-outgoing; Wed, 5 Jun 2002 08:26:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55FQKnC013341 for ; Wed, 5 Jun 2002 08:26:20 -0700 Received: from slc-unislc.slc.unisys.com ([192.60.174.32]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id PAA00920 for ; Wed, 5 Jun 2002 15:26:30 GMT Received: from localhost.localdomain (slc-knysna.slc.unisys.com [192.60.130.30]) by slc-unislc.slc.unisys.com (8.9.3/UW7.1.1) with ESMTP id JAA10408 for ; Wed, 5 Jun 2002 09:28:16 -0600 (MDT) Received: from slc-knysna (slc-knysna [127.0.0.1]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g55FSRo15340 for ; Wed, 5 Jun 2002 09:28:27 -0600 Content-Type: text/plain; charset="us-ascii" From: Warren Stockton Reply-To: wns@slc.unisys.com To: linux-xfs@oss.sgi.com Date: Wed, 5 Jun 2002 09:28:26 -0600 User-Agent: KMail/1.4.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Features needed/desired in 2.4.9 for ES7000 Message-Id: <200206050928.26887.wns@slc.unisys.com> X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk John, First cut... More issues exist but I can't think of them right now... The following bits of code are in 2.4.18 which allow us to boot on an IA32 ES7000: - CONFIG_MULTIQUAD for IBM/Sequent - provides the Hierarchial Clustered APIC addressing. This is the only APIC mode that IA32 ES7000 supports besides virtual wire (which will only run a 1x) (Would be interesting to know how RedHat implements this for IBM/Sequent since this define is not enabled in the generic RedHat kernels.) The following list is some of the features in 2.4.18 that improve our scalability/performance on ES7000 (additional fixes beyond 2.4.18 are required to improve scaling for 16x and beyond) - Changes to fs/buffer.c and additional fs/*.c and mm/*.c files to reduce contention on lru_list_lock Additional areas that require attention for further scaling improvements: - Changes to reduce contention on pagemap_lru_lock (seen running AIM7 workloads) - Changes to reduce wasted system time in blk_get_queue() (seen running Oracle TPCH on raw devices) -- Warren Stockton mailto: wns@slc.unisys.com From owner-linux-xfs@oss.sgi.com Wed Jun 5 08:39:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55FdgnC018531 for ; Wed, 5 Jun 2002 08:39:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55FdgPh018530 for linux-xfs-outgoing; Wed, 5 Jun 2002 08:39:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55FdZnC018441 for ; Wed, 5 Jun 2002 08:39:35 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jun 2002 11:41:27 -0400 Message-ID: From: Murthy Kambhampaty To: "Linux-Xfs (E-mail)" Subject: CVS checkout of May24: Bad interaction bet. xfsrestore and nfs Date: Wed, 5 Jun 2002 11:41:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When using kernel and tools from the CVS checkout of May 24, xfsrestore hangs with /var/log/messages showing: "Jun 3 13:13:24 compa6 kernel: nfs: server compa5 not responding, still trying Jun 3 13:15:14 compa6 kernel: nfs: task 2189 can't get a request slot" Being reluctant to update to kernel-2.4.19-pre9/-pre10, I installed the XFS 1.1 (generic 2.4.18) kernel and cmds, but ran xfsrestore before rebooting the XFS 1.1 kernel, and it completes without problems. My question is, can I use the XFS 1.1 cmd with the CVS kernel of May 24 until kernel-2.4.19 is official, or am I asking for trouble? Thanks for the help, Murthy From owner-linux-xfs@oss.sgi.com Wed Jun 5 08:49:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55FnHnC022184 for ; Wed, 5 Jun 2002 08:49:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55FnHV3022183 for linux-xfs-outgoing; Wed, 5 Jun 2002 08:49:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55FnAnC022080 for ; Wed, 5 Jun 2002 08:49:11 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Wed, 5 Jun 2002 11:51:03 -0400 Message-ID: From: Murthy Kambhampaty To: "'Linux-Xfs (E-mail)'" Subject: Oops, revised. CVS checkout of May24: Bad interaction bet. xfsres tore and nfs Date: Wed, 5 Jun 2002 11:51:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.7 required=5.0 tests=SUBJ_HAS_SPACES version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When using kernel and tools from the CVS checkout of May 24, xfsrestore hangs with /var/log/messages showing: "Jun 3 13:13:24 compa6 kernel: nfs: server compa5 not responding, still trying Jun 3 13:15:14 compa6 kernel: nfs: task 2189 can't get a request slot" Being reluctant to update to kernel-2.4.19-pre9/-pre10, I installed the XFS 1.1 (generic 2.4.18) kernel and cmds, but ran xfsrestore before rebooting the XFS 1.1 kernel, and it completes without problems. >>Sorry, the problem persists, it just takes longer to show up :-( Jun 5 11:40:14 compa6 kernel: nfs: server compa5 not responding, still trying Jun 5 11:42:04 compa6 kernel: nfs: task 8570 can't get a request slot ... repeats I'll run the XFS 1.1 kernel like a good boy should, and let you know if I still have the problem (I have run xfsrestore to completion on a machine running kernel and tools from CVS checkout of April 25). Murthy From owner-linux-xfs@oss.sgi.com Wed Jun 5 08:53:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55Fr2nC023776 for ; Wed, 5 Jun 2002 08:53:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55Fr2a7023775 for linux-xfs-outgoing; Wed, 5 Jun 2002 08:53:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55FqtnC023668 for ; Wed, 5 Jun 2002 08:52:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA75985 for ; Wed, 5 Jun 2002 10:54:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA96741 for ; Wed, 5 Jun 2002 10:54:48 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g55FoX423787; Wed, 5 Jun 2002 10:50:33 -0500 Message-Id: <200206051550.g55FoX423787@jen.americas.sgi.com> Date: Wed, 5 Jun 2002 10:50:33 -0500 Subject: TAKE - make better use of dentries in xfs To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This makes things fly a little faster. Date: Wed Jun 5 08:53:46 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120877a linux/fs/xfs/xfs_vnodeops.c - 1.530 - Add dentries into the vops, and get the inode from the dentry in unlink and rmdir. linux/fs/xfs/xfs_utils.c - 1.45 - In name lookup, if we have a positive dentry use that directly instead of the directory lookup. linux/fs/xfs/xfs_utils.h - 1.17 - prototype changes linux/fs/xfs/xfs_rename.c - 1.35 - deal with dentries instead of names linux/fs/xfs/linux/xfs_iops.c - 1.148 - pass the dentries into the vop calls rather than just the string linux/fs/xfs/linux/xfs_vnode.h - 1.35 - change vop prototypes From owner-linux-xfs@oss.sgi.com Wed Jun 5 09:04:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55G4fnC028048 for ; Wed, 5 Jun 2002 09:04:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55G4f1d028047 for linux-xfs-outgoing; Wed, 5 Jun 2002 09:04:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55G4UnC027913 for ; Wed, 5 Jun 2002 09:04:30 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA76236 for ; Wed, 5 Jun 2002 11:06:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA89996 for ; Wed, 5 Jun 2002 11:06:23 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g55G4Wc25817; Wed, 5 Jun 2002 11:04:32 -0500 Message-Id: <200206051604.g55G4Wc25817@stout.americas.sgi.com> Date: Wed, 5 Jun 2002 11:04:32 -0500 Subject: TAKE - A couple more copyright tidbits X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk sync kernel/user copyright headers Automated scripts only get you so far... they got our kernel/userspace header files out of sync by a bit. Date: Wed Jun 5 09:05:11 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:120878a cmd/xfsprogs/include/xfs_trans_space.h - 1.5 cmd/xfsprogs/include/xfs_inum.h - 1.5 cmd/xfsprogs/include/xfs_ialloc.h - 1.5 cmd/xfsprogs/include/xfs_extfree_item.h - 1.5 cmd/xfsprogs/include/xfs_attr_sf.h - 1.6 cmd/xfsprogs/include/xfs_da_btree.h - 1.7 cmd/xfsprogs/include/xfs_bit.h - 1.7 cmd/xfsprogs/include/xfs_fs.h - 1.17 cmd/xfsprogs/include/xfs_dir.h - 1.5 cmd/xfsprogs/include/xfs_arch.h - 1.5 cmd/xfsprogs/include/xfs_rtalloc.h - 1.5 cmd/xfsprogs/include/xfs_ialloc_btree.h - 1.5 cmd/xfsprogs/include/xfs_inode_item.h - 1.5 cmd/xfsprogs/include/arch.h - 1.7 cmd/xfsprogs/include/xfs_log_recover.h - 1.5 cmd/xfsprogs/include/xfs_dfrag.h - 1.5 cmd/xfsprogs/include/xfs_bmap_btree.h - 1.5 cmd/xfsprogs/include/xfs_dir2_data.h - 1.5 cmd/xfsprogs/include/xfs_attr_leaf.h - 1.6 cmd/xfsprogs/include/xfs_dir_sf.h - 1.5 cmd/xfsprogs/include/xfs_imap.h - 1.5 cmd/xfsprogs/include/xfs_bmap.h - 1.5 cmd/xfsprogs/include/xfs_alloc_btree.h - 1.5 cmd/xfsprogs/include/xfs_dir2_node.h - 1.5 cmd/xfsprogs/include/xfs_dinode.h - 1.7 cmd/xfsdump/include/quotaio_xfs.h - 1.5 From owner-linux-xfs@oss.sgi.com Wed Jun 5 09:24:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55GO5nC003098 for ; Wed, 5 Jun 2002 09:24:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55GO5cO003097 for linux-xfs-outgoing; Wed, 5 Jun 2002 09:24:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55GNxnC003033 for ; Wed, 5 Jun 2002 09:23:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA76482 for ; Wed, 5 Jun 2002 11:25:52 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA91818 for ; Wed, 5 Jun 2002 11:25:52 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g55GO1708634; Wed, 5 Jun 2002 11:24:01 -0500 Message-Id: <200206051624.g55GO1708634@stout.americas.sgi.com> Date: Wed, 5 Jun 2002 11:24:01 -0500 Subject: TAKE - More userspace/kernel sync-ups X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At least these ones aren't copyright-related... sync userspace with kernel Date: Wed Jun 5 09:24:32 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:120880a cmd/xfsprogs/include/xfs_mount.h - 1.21 cmd/xfsprogs/libxfs/xfs_dir2_sf.c - 1.7 From owner-linux-xfs@oss.sgi.com Wed Jun 5 09:50:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55GolnC010579 for ; Wed, 5 Jun 2002 09:50:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55GolMu010578 for linux-xfs-outgoing; Wed, 5 Jun 2002 09:50:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55GofnC010537 for ; Wed, 5 Jun 2002 09:50:41 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA76795; Wed, 5 Jun 2002 11:52:34 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA00831; Wed, 5 Jun 2002 11:52:33 -0500 (CDT) Subject: Re: Oops, revised. CVS checkout of May24: Bad interaction bet. xfsres tore and nfs From: Eric Sandeen To: Murthy Kambhampaty Cc: "'Linux-Xfs (E-mail)'" In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 05 Jun 2002 11:50:42 -0500 Message-Id: <1023295843.25182.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,SUBJ_HAS_SPACES version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-05 at 10:51, Murthy Kambhampaty wrote: > When using kernel and tools from the CVS checkout of May 24, xfsrestore > hangs with /var/log/messages showing: > > "Jun 3 13:13:24 compa6 kernel: nfs: server compa5 not responding, still > trying > Jun 3 13:15:14 compa6 kernel: nfs: task 2189 can't get a request slot" hi Murthy - How are you using nfs in this case? I'm wondering what the obvious interactions might be. Also, if you have kdb enabled, can you do a "kdb> bt " where is your xfsrestore process? Any hints that could help reproduce this here would be appreciated... Thanks, -Eric From owner-linux-xfs@oss.sgi.com Wed Jun 5 10:06:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55H6OnC012811 for ; Wed, 5 Jun 2002 10:06:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55H6OIE012810 for linux-xfs-outgoing; Wed, 5 Jun 2002 10:06:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from endeavour.uwyo.edu (endeavour.uwyo.edu [129.72.10.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55H6DnC012778 for ; Wed, 5 Jun 2002 10:06:14 -0700 Received: from CONVERSION-DAEMON.endeavour.uwyo.edu by endeavour.uwyo.edu (PMDF V6.1-1 #40460) id <0GX800001SXN9A@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Wed, 05 Jun 2002 11:08:11 -0600 (MDT) Received: from asuwlink.uwyo.edu (asuwlink.uwyo.edu [129.72.60.2]) by endeavour.uwyo.edu (PMDF V6.1-1 #40460) with ESMTP id <0GX800KJ3SXNA1@endeavour.uwyo.edu> for linux-xfs@oss.sgi.com; Wed, 05 Jun 2002 11:08:11 -0600 (MDT) Received: from ross226 (ringram@ross226.uwyo.edu [129.72.51.220]) by asuwlink.uwyo.edu (8.8.8/8.8.7) with SMTP id LAA16766 for ; Wed, 05 Jun 2002 11:08:11 -0600 (MDT) Date: Wed, 05 Jun 2002 11:17:49 +0000 From: Russel Ingram Subject: Re: XFS installer for Redhat In-reply-to: <4.3.2.7.2.20020605130314.039695c8@pop.xs4all.nl> To: linux-xfs@oss.sgi.com Message-id: <20020605111749.5aead251.ringram@gargoylecc.com> Organization: Gargoyle Computer Consulting MIME-version: 1.0 X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i386-debian-linux-gnu) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <003601c20c7a$2e04b8c0$0200a8c0@florian> <4.3.2.7.2.20020605130314.039695c8@pop.xs4all.nl> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 05 Jun 2002 13:10:14 +0200 "Seth Mos" wrote: > At 12:17 5-6-2002 +0200, Florian Lindner wrote: > >Hello, > >does anybody have experiencies with the Redhat installer from > >ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/instal > >ler/i386/ Does anybody has tried that? It is supposed to be stable > >enough for everyday use? > >Thx, > >Florian > > I did test the kernel from this installer (2.4.18 Red Hat based) on a > medium sized ia32 box and it did well. > > It was a dual 1.4Ghz PIII and 2GB ram with a hardware raid 10. > I tried some local mongo.pl runs with a lot of processes and bonnie++ > runs back to back for a day over NFS (gigabit ethernet). > > Not too stellar scores (hardware raid limit) but the machine survived > none the less. NFS performance was about 500Mbps but this was limited > by the desktop client machine. > > Don't forget to make your network buffers larger if you have gigabit > ethernet if you want some return on investment ;) > Otherwise it is just like having 100Mbit ethernet. > > I have not tested the installer part due to time shortage. I think > Eric did test this before releasing it. Eric you did test it by > upgrading did you :) > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > As far as just the installer part goes I just finished upgrading 6 machines from RH7.1-XFS1.0.1 without a hitch. The only problems I had were with things that would have occured with the installer from Red Hat as well related to the installer defaulting to ipchains while the systems were set up to use iptables. Thanks for great work Eric! Russ -- Russel H. Ingram Unix Systems Administrator Institute for Scientific Computation University of Wyoming/Math Dept. Phone: (307)766-6546 E-Mail: ringram@uwyo.edu From owner-linux-xfs@oss.sgi.com Wed Jun 5 10:58:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55HwpnC013159 for ; Wed, 5 Jun 2002 10:58:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55Hwpo7013158 for linux-xfs-outgoing; Wed, 5 Jun 2002 10:58:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55HwenC013127 for ; Wed, 5 Jun 2002 10:58:41 -0700 Received: from fwd09.sul.t-online.de by mailout01.sul.t-online.com with smtp id 17Ff5K-0001L6-06; Wed, 05 Jun 2002 20:00:38 +0200 Received: from horus.xgm.de (340060635977-0001@[80.129.27.161]) by fmrl09.sul.t-online.com with esmtp id 17Ff58-1h0CsiC; Wed, 5 Jun 2002 20:00:26 +0200 Received: from florian (unknown [192.168.0.2]) by horus.xgm.de (Postfix) with SMTP id C761EC8 for ; Wed, 5 Jun 2002 19:58:25 +0200 (CEST) Message-ID: <000c01c20cbb$593ddf80$0200a8c0@florian> From: "Florian Lindner" To: References: <003601c20c7a$2e04b8c0$0200a8c0@florian> <4.3.2.7.2.20020605130314.039695c8@pop.xs4all.nl> <20020605111749.5aead251.ringram@gargoylecc.com> Subject: Re: XFS installer for Redhat Date: Wed, 5 Jun 2002 20:03:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 340060635977-0001@t-dialin.net X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > On Wed, 05 Jun 2002 13:10:14 +0200 > "Seth Mos" wrote: > > > At 12:17 5-6-2002 +0200, Florian Lindner wrote: > > >Hello, > > >does anybody have experiencies with the Redhat installer from > > >ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/instal > > >ler/i386/ Does anybody has tried that? It is supposed to be stable > > >enough for everyday use? > > >Thx, > > >Florian > > > > I did test the kernel from this installer (2.4.18 Red Hat based) on a > > medium sized ia32 box and it did well. > > > > It was a dual 1.4Ghz PIII and 2GB ram with a hardware raid 10. > > I tried some local mongo.pl runs with a lot of processes and bonnie++ > > runs back to back for a day over NFS (gigabit ethernet). > > > > Not too stellar scores (hardware raid limit) but the machine survived > > none the less. NFS performance was about 500Mbps but this was limited > > by the desktop client machine. > > > > Don't forget to make your network buffers larger if you have gigabit > > ethernet if you want some return on investment ;) > > Otherwise it is just like having 100Mbit ethernet. > > > > I have not tested the installer part due to time shortage. I think > > Eric did test this before releasing it. Eric you did test it by > > upgrading did you :) > > > > Cheers > > > > -- > > Seth > > It might just be your lucky day, if you only knew. > > > > As far as just the installer part goes I just finished upgrading 6 machines > from RH7.1-XFS1.0.1 without a hitch. The only problems I had were with things > that would have occured with the installer from Red Hat as well related to > the installer defaulting to ipchains while the systems were set up to use > iptables. Which bootloader you have used? The XFS website says that there might be problems with GRUB. Thx, Florian From owner-linux-xfs@oss.sgi.com Wed Jun 5 11:27:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55IRAnC013616 for ; Wed, 5 Jun 2002 11:27:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55IRA6i013615 for linux-xfs-outgoing; Wed, 5 Jun 2002 11:27:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55IR4nC013587 for ; Wed, 5 Jun 2002 11:27:04 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA08699 for ; Wed, 5 Jun 2002 11:29:01 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id LAA22459 for ; Wed, 5 Jun 2002 11:28:30 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 2AA6B136323 for ; Wed, 5 Jun 2002 11:28:30 -0700 (PDT) Subject: Re: XFS installer for Redhat From: Florin Andrei To: linux-xfs In-Reply-To: <000c01c20cbb$593ddf80$0200a8c0@florian> References: <003601c20c7a$2e04b8c0$0200a8c0@florian> <4.3.2.7.2.20020605130314.039695c8@pop.xs4all.nl> <20020605111749.5aead251.ringram@gargoylecc.com> <000c01c20cbb$593ddf80$0200a8c0@florian> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Jun 2002 11:28:30 -0700 Message-Id: <1023301710.32329.16.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-05 at 11:03, Florian Lindner wrote: > > Which bootloader you have used? The XFS website says that there might be > problems with GRUB. I'm using Grub. No problem. I have this distribution installed on an AthlonXP 1800 machine, MSI nForce motherboard, IDE drives. Besides plain desktop applications, i do a lot of video stuff on this machine (MPEG conversions, video editing, etc), and that means moving multi-gigabyte files around while the CPU is at 100%. No problem until now. -- Florin Andrei "You can get excited about just any subject if you study it enough. It's the deep knowledge that makes a topic interesting." - Larry McVoy From owner-linux-xfs@oss.sgi.com Wed Jun 5 12:11:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55JBInC014246 for ; Wed, 5 Jun 2002 12:11:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55JBH6b014245 for linux-xfs-outgoing; Wed, 5 Jun 2002 12:11:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55JBCnC014215 for ; Wed, 5 Jun 2002 12:11:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA78007 for ; Wed, 5 Jun 2002 14:13:05 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA99824 for ; Wed, 5 Jun 2002 14:13:05 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g55J8nc05593; Wed, 5 Jun 2002 14:08:49 -0500 Message-Id: <200206051908.g55J8nc05593@jen.americas.sgi.com> Date: Wed, 5 Jun 2002 14:08:49 -0500 Subject: TAKE - optimize bit manipulation functions again To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is fixed version of the code which went in and out again a week or so back. I found and fixed the problem in the original code, but Andi Kleen did most of this. Speeds things up again. Steve Date: Wed Jun 5 12:11:07 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-baseline The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120910a linux/fs/xfs/xfs_buf_item.c - 1.122 linux/fs/xfs/xfs_bit.h - 1.11 linux/fs/xfs/xfs_bit.c - 1.17 linux/fs/xfs/xfs_log_recover.c - 1.233 linux/fs/xfs/xfs_rtbit.c - 1.11 From owner-linux-xfs@oss.sgi.com Wed Jun 5 13:02:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55K2VnC016250 for ; Wed, 5 Jun 2002 13:02:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55K2Vpn016249 for linux-xfs-outgoing; Wed, 5 Jun 2002 13:02:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from reefedge.reefedge.com (reefedge.com [216.10.14.212]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55K2OnC016219 for ; Wed, 5 Jun 2002 13:02:25 -0700 Received: from pla-muek.reefedge.com (mocha.reefedge.com [64.50.29.181]) by reefedge.reefedge.com (8.12.1/8.12.1) with ESMTP id g55Jv2EZ012364 for ; Wed, 5 Jun 2002 15:57:03 -0400 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id g55K4M514897 for linux-xfs@oss.sgi.com; Wed, 5 Jun 2002 16:04:22 -0400 (EDT) Date: Wed, 5 Jun 2002 16:04:22 -0400 From: Thor Lancelot Simon To: linux-xfs@oss.sgi.com Subject: Re: RAID Controller Caching and XFS Message-ID: <20020605160422.A14886@pla-muek.reefedge.com> References: <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl>; from knuffie@xs4all.nl on Mon, Jun 03, 2002 at 11:16:35AM +0200 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 03, 2002 at 11:16:35AM +0200, Seth Mos wrote: > At 12:35 2-6-2002 -0700, Raymond wrote: > >I have enabled write-backing caching on a MegaRAID 1500 with battery back-up. > > > >Two other cache options exist: Read-Ahead and I/O Caching. > > > >Any potential problems enabling these options with XFS 1.02? > > I have not found any using caching IO. > > Read ahead can safely be used, but the readahead under linux itself is > probably more usefull. More importantly, you don't *want* to use readahead because it will waste valuable cache space on the controller that could be used to cache small writes. Unless you have a truly silly memory configuration (e.g. more cache RAM on the RAID controller than main memory available for buffer cache on your machine) the read cache of the operating system will do all that the controller's cache could do and then some. On the other hand, since the controller has battery backup, it can do something the OS can't: safely gather small writes into its battery-backed cache and clear them to disk in an efficient manner. So if your RAID controller lets you configure its cache that way, that's what you want to do. Thor From owner-linux-xfs@oss.sgi.com Wed Jun 5 13:14:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55KE6nC016636 for ; Wed, 5 Jun 2002 13:14:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55KE6bg016635 for linux-xfs-outgoing; Wed, 5 Jun 2002 13:14:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55KDtnC016599 for ; Wed, 5 Jun 2002 13:13:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA78551 for ; Wed, 5 Jun 2002 15:15:48 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA38149 for ; Wed, 5 Jun 2002 15:15:48 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g55KDuV22238; Wed, 5 Jun 2002 15:13:56 -0500 Message-Id: <200206052013.g55KDuV22238@stout.americas.sgi.com> Date: Wed, 5 Jun 2002 15:13:56 -0500 Subject: TAKE - Make scripts executable again X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Make scripts executable again... sigh... The copyright gyrations stripped the +x off these files. Are we having fun yet? Date: Wed Jun 5 13:14:16 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-copyright The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:120926a cmd/attr/install-sh - 1.7 cmd/xfsprogs/db/xfs_ncheck.sh - 1.5 cmd/xfsprogs/db/xfs_check64.sh - 1.5 cmd/xfsprogs/db/xfs_check.sh - 1.5 cmd/xfsprogs/db/xfs_admin.sh - 1.6 cmd/xfsprogs/db/xfs_ncheck64.sh - 1.5 cmd/xfsprogs/install-sh - 1.8 cmd/xfsprogs/growfs/xfs_info.sh - 1.5 cmd/xfsdump/install-sh - 1.8 cmd/xfsdump/quota/xfsrq.sh - 1.6 cmd/xfstests/001 - 1.5 cmd/xfstests/002 - 1.5 cmd/xfstests/003 - 1.5 cmd/xfstests/005 - 1.7 cmd/xfstests/006 - 1.5 cmd/xfstests/007 - 1.5 cmd/xfstests/011 - 1.5 cmd/xfstests/012 - 1.5 cmd/xfstests/014 - 1.5 cmd/xfstests/022 - 1.6 cmd/xfstests/023 - 1.6 cmd/xfstests/024 - 1.8 cmd/xfstests/025 - 1.6 cmd/xfstests/026 - 1.5 cmd/xfstests/027 - 1.5 cmd/xfstests/028 - 1.7 cmd/xfstests/033 - 1.8 cmd/xfstests/035 - 1.6 cmd/xfstests/036 - 1.5 cmd/xfstests/037 - 1.5 cmd/xfstests/038 - 1.5 cmd/xfstests/039 - 1.5 cmd/xfstests/040 - 1.7 cmd/xfstests/046 - 1.5 cmd/xfstests/047 - 1.7 cmd/xfstests/048 - 1.5 cmd/xfstests/059 - 1.5 cmd/xfstests/060 - 1.5 cmd/xfstests/061 - 1.6 cmd/xfstests/063 - 1.5 cmd/xfstests/remake - 1.5 cmd/xfstests/install-sh - 1.5 cmd/xfstests/new - 1.6 cmd/xfstests/src/fill2fs - 1.9 cmd/xfstests/src/fill2fs_check - 1.7 cmd/xfstests/src/fill2attr - 1.5 cmd/xfstests/crash/xfscrash - 1.5 cmd/xfstests/dmapi/src/suite2/menu_test - 1.5 cmd/xfstests/dmapi/src/suite2/bindir/make_holey - 1.5 cmd/xfstests/dmapi/src/suite2/bindir/run_test - 1.5 cmd/xfstests/dmapi/src/suite2/bindir/ctf - 1.5 cmd/xfstests/dmapi/src/suite2/bindir/stf - 1.5 cmd/xfstests/dmapi/src/suite2/bindir/crttf - 1.5 cmd/xfstests/dmapi/src/suite2/bindir/test_allocinfo_2 - 1.5 cmd/xfstests/dmapi/src/suite2/bindir/test_allocinfo_1 - 1.5 cmd/xfstests/tools/db-walk - 1.5 cmd/xfstests/tools/fs-walk - 1.5 cmd/dmapi/install-sh - 1.9 cmd/xfstests/065 - 1.9 cmd/xfstests/066 - 1.9 cmd/xfstests/067 - 1.6 From owner-linux-xfs@oss.sgi.com Wed Jun 5 13:37:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55KbCnC017150 for ; Wed, 5 Jun 2002 13:37:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55KbCXE017149 for linux-xfs-outgoing; Wed, 5 Jun 2002 13:37:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta06-svc.ntlworld.com (mta06-svc.ntlworld.com [62.253.162.46]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55Kb4nC017121 for ; Wed, 5 Jun 2002 13:37:05 -0700 Received: from localhost ([80.1.68.230]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020603194923.PMTM28297.mta01-svc.ntlworld.com@localhost> for ; Mon, 3 Jun 2002 20:49:23 +0100 Content-Type: text/plain; charset="iso-8859-1" From: mark Reply-To: mark.newman2@ntlworld.com Subject: : problems with cp -p Date: Mon, 3 Jun 2002 19:34:42 +0000 User-Agent: KMail/1.4.1 To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Message-Id: <200206031934.42312.mark.newman2@ntlworld.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g55Kb6nC017122 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi I have been using XFS for a while with no problems. However I have recently moved to Gentoo linux and backups are now much more critical to me. I am trying to use Mondo Rescue as a backup program and one of the commands it uses is as follows cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/ which returns the following cp: `/usr/local/share/mondo/restore-scripts.tgz': Argument list too long cp: preserving permissions for `/home/mondo.scratch.19294/usr/local/share/mondo': Invalid argument it seems to be the -p switch which causes this. It has been suggested that this could be a problem with XFS (I am running version 1.1) My kernel is a Gentoo supplied patched kernel. I could possibly try a more vanilla one. Perhaps someone could try cp on a directory with these arguments and see if they can duplicate these results Any help is appreciated. Regards Mark ------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 5 14:01:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55L1TnC017600 for ; Wed, 5 Jun 2002 14:01:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55L1TUC017599 for linux-xfs-outgoing; Wed, 5 Jun 2002 14:01:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55L1NnC017571 for ; Wed, 5 Jun 2002 14:01:23 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA78858 for ; Wed, 5 Jun 2002 16:03:17 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA46253 for ; Wed, 5 Jun 2002 16:03:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g55L1OE23879; Wed, 5 Jun 2002 16:01:24 -0500 Message-Id: <200206052101.g55L1OE23879@stout.americas.sgi.com> Date: Wed, 5 Jun 2002 16:01:24 -0500 Subject: TAKE - Clear up delete_inode path X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The delete_inode superblock method is supposed to call clear_inode internally, but our clear_inode & delete_inode methods are functionally identical, so we were doing things twice on the delete_inode path. We can just use clear_inode as our delete_inode method (with me so far?) and when we get down to linvfs_clear_inode, xfs will do the right things for both paths (delete & clear). Date: Wed Jun 5 13:59:54 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120935a linux/fs/xfs/linux/xfs_super.c - 1.175 - Clean up delete_inode path; just call clear_inode. From owner-linux-xfs@oss.sgi.com Wed Jun 5 14:55:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55LtanC021476 for ; Wed, 5 Jun 2002 14:55:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55LtaO7021475 for linux-xfs-outgoing; Wed, 5 Jun 2002 14:55:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55LtVnC021437 for ; Wed, 5 Jun 2002 14:55:31 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA07363 for ; Wed, 5 Jun 2002 14:57:29 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id OAA75368 for ; Wed, 5 Jun 2002 14:56:57 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 64B8E136420 for ; Wed, 5 Jun 2002 14:56:57 -0700 (PDT) Subject: Re: RAID Controller Caching and XFS From: Florin Andrei To: linux-xfs In-Reply-To: <20020605160422.A14886@pla-muek.reefedge.com> References: <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> <20020605160422.A14886@pla-muek.reefedge.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Jun 2002 14:56:57 -0700 Message-Id: <1023314217.32329.32.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-05 at 13:04, Thor Lancelot Simon wrote: > > More importantly, you don't *want* to use readahead because it will waste > valuable cache space on the controller that could be used to cache small > writes. How safe is it to enable caching for writes on the controller (if you don't have a battery on it)? I mean, i configured my Mylex with "Write Through" for data-safety reasons, even though the other option ("Write Back") could offer improved performance. -- Florin Andrei "You can get excited about just any subject if you study it enough. It's the deep knowledge that makes a topic interesting." - Larry McVoy From owner-linux-xfs@oss.sgi.com Wed Jun 5 15:00:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55M0unC021774 for ; Wed, 5 Jun 2002 15:00:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55M0uDa021773 for linux-xfs-outgoing; Wed, 5 Jun 2002 15:00:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55M0nnC021745 for ; Wed, 5 Jun 2002 15:00:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA79390; Wed, 5 Jun 2002 17:02:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA09099; Wed, 5 Jun 2002 17:02:43 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g55LwPj03966; Wed, 5 Jun 2002 16:58:25 -0500 Subject: Re: RAID Controller Caching and XFS From: Steve Lord To: Florin Andrei Cc: linux-xfs In-Reply-To: <1023314217.32329.32.camel@stantz.corp.sgi.com> References: <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> <20020605160422.A14886@pla-muek.reefedge.com> <1023314217.32329.32.camel@stantz.corp.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Jun 2002 16:58:25 -0500 Message-Id: <1023314305.29323.446.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-05 at 16:56, Florin Andrei wrote: > On Wed, 2002-06-05 at 13:04, Thor Lancelot Simon wrote: > > > > More importantly, you don't *want* to use readahead because it will waste > > valuable cache space on the controller that could be used to cache small > > writes. > > How safe is it to enable caching for writes on the controller (if you > don't have a battery on it)? > I mean, i configured my Mylex with "Write Through" for data-safety > reasons, even though the other option ("Write Back") could offer > improved performance. > How important is your data? If it is in the cache and you lose power, then you lose it. If the raid controller does reordering on the I/O then you can end up with a corrupted file system. You will not know it is corrupted until you attempt to access the part of it that is corrupt, or run xfs_check on it. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jun 5 15:01:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55M1YnC021827 for ; Wed, 5 Jun 2002 15:01:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55M1Ywb021826 for linux-xfs-outgoing; Wed, 5 Jun 2002 15:01:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moutvdom01.kundenserver.de (moutvdom01.kundenserver.de [195.20.224.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55M1SnC021798 for ; Wed, 5 Jun 2002 15:01:29 -0700 Received: from [172.19.20.61] (helo=mrvdomng0.kundenserver.de) by moutvdom01.kundenserver.de with esmtp (Exim 2.12 #3) id 17FisG-0004th-00; Thu, 6 Jun 2002 00:03:24 +0200 Received: from [217.88.210.240] (helo=kernelpanix.aura.of.mankind) by mrvdomng0.kundenserver.de with esmtp (Exim 3.22 #2) id 17FisG-0000b7-00; Thu, 06 Jun 2002 00:03:24 +0200 Received: (from utz@localhost) by kernelpanix.aura.of.mankind (8.11.2/8.11.2) id g55LnDg29560; Wed, 5 Jun 2002 23:49:13 +0200 X-Authentication-Warning: kernelpanix.aura.of.mankind: utz set sender to xfs@s2y4n2c.de using -f Date: Wed, 5 Jun 2002 23:49:13 +0200 From: utz lehmann To: Florin Andrei Cc: linux-xfs Subject: Re: RAID Controller Caching and XFS Message-ID: <20020605234913.A29557@s2y4n2c.de> References: <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> <20020605160422.A14886@pla-muek.reefedge.com> <1023314217.32329.32.camel@stantz.corp.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: <1023314217.32329.32.camel@stantz.corp.sgi.com> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Florin Andrei [florin@sgi.com] wrote: > On Wed, 2002-06-05 at 13:04, Thor Lancelot Simon wrote: > > > > More importantly, you don't *want* to use readahead because it will waste > > valuable cache space on the controller that could be used to cache small > > writes. > > How safe is it to enable caching for writes on the controller (if you > don't have a battery on it)? > I mean, i configured my Mylex with "Write Through" for data-safety > reasons, even though the other option ("Write Back") could offer > improved performance. It's not (really) safe, see http://oss.sgi.com/projects/xfs/mail_archive/200205/msg00510.html utz From owner-linux-xfs@oss.sgi.com Wed Jun 5 15:07:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55M74nC022802 for ; Wed, 5 Jun 2002 15:07:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55M74Dm022801 for linux-xfs-outgoing; Wed, 5 Jun 2002 15:07:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55M6xnC022768 for ; Wed, 5 Jun 2002 15:06:59 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA04832 for ; Wed, 5 Jun 2002 15:08:57 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id PAA02774 for ; Wed, 5 Jun 2002 15:08:26 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id C35E0136420 for ; Wed, 5 Jun 2002 15:08:26 -0700 (PDT) Subject: Re: RAID Controller Caching and XFS From: Florin Andrei To: linux-xfs In-Reply-To: <1023314305.29323.446.camel@jen.americas.sgi.com> References: <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> <20020605160422.A14886@pla-muek.reefedge.com> <1023314217.32329.32.camel@stantz.corp.sgi.com> <1023314305.29323.446.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Jun 2002 15:08:26 -0700 Message-Id: <1023314906.32015.40.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-05 at 14:58, Steve Lord wrote: > On Wed, 2002-06-05 at 16:56, Florin Andrei wrote: > > > > How safe is it to enable caching for writes on the controller (if you > > don't have a battery on it)? > > How important is your data? If it is in the cache and you lose power, > then you lose it. If the raid controller does reordering on the I/O > then you can end up with a corrupted file system. You will not know How's ENS' database-backed logging (syslog) server for "important"? ;-) Ok, i got it, i made the right decision: use Write Through and loose some performance to get some data safety. -- Florin Andrei "You can get excited about just any subject if you study it enough. It's the deep knowledge that makes a topic interesting." - Larry McVoy From owner-linux-xfs@oss.sgi.com Wed Jun 5 15:30:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55MUSnC023057 for ; Wed, 5 Jun 2002 15:30:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55MUSIV023056 for linux-xfs-outgoing; Wed, 5 Jun 2002 15:30:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ente.berdmann.de (frnk-d514e136.dsl.mediaWays.net [213.20.225.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55MULnC023028 for ; Wed, 5 Jun 2002 15:30:22 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 17FjKB-0000yX-00; Thu, 06 Jun 2002 00:32:15 +0200 Message-ID: <3CFE916F.FA1D9341@berdmann.de> Date: Thu, 06 Jun 2002 00:32:15 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Florian Lindner CC: linux-xfs@oss.sgi.com Subject: Re: XFS installer for Redhat References: <003601c20c7a$2e04b8c0$0200a8c0@florian> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florian Lindner wrote: > > Hello, > does anybody have experiencies with the Redhat installer from > ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/installer/i386/ > Does anybody has tried that? It is supposed to be stable enough for everyday > use? > Thx, > Florian > > [[HTML alternate version deleted]] Hi, the network installer (bootnet.img) failed for me. From owner-linux-xfs@oss.sgi.com Wed Jun 5 15:45:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g55MjHnC023337 for ; Wed, 5 Jun 2002 15:45:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g55MjHKH023336 for linux-xfs-outgoing; Wed, 5 Jun 2002 15:45:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g55Mj9nC023308 for ; Wed, 5 Jun 2002 15:45:09 -0700 Received: from localhost ([80.1.68.230]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020605224707.CXCF295.mta03-svc.ntlworld.com@localhost> for ; Wed, 5 Jun 2002 23:47:07 +0100 Content-Type: text/plain; charset="iso-8859-1" From: mark Reply-To: mark.newman2@ntlworld.com Organization: mark Subject: Re: probs with cp -p Date: Thu, 6 Jun 2002 00:43:54 +0100 User-Agent: KMail/1.4.1 To: linux-xfs MIME-Version: 1.0 Message-Id: <200206060043.54987.mark.newman2@ntlworld.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g55MjAnC023309 X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 05 June 2002 02:34, Nathan Scott wrote: > On Tue, Jun 04, 2002 at 01:27:59PM -0800, Ethan Benson wrote: > > On Tue, Jun 04, 2002 at 10:56:45AM +0000, mark wrote: > > > Okay I have now tried a vanilla 2.4.18 with XFS 1.1 kernel (just to > > > ensure it wasnt a problem with my patched 2.4.19) with similar results. > > > 'Argument too long' dissapeared but I still get the 'invalid argument' > > > message. Could there be some kind of problem with my filesystem. > > I doubt it, this error is more likely a coding issue in the kernel, > rather than an on-disk problem. > > > > Is there more info I could provide? > > > > i think he meant try current cvs as of yesterday, it looks > > There have been several related fixes, incl. yesterdays fix - please > try a current CVS kernel, Mark & let me know if it still fails. > > cheers. Okay, I just tried with a cvs from last night and the problem persists localhost me # cp --parents -pRdf /usr/local/share /home cp: preserving permissions for `/home/usr/local/share/doc': Invalid argument cp: preserving permissions for `/home/usr/local/share/man/man1': Invalid argument cp: preserving permissions for `/home/usr/local/share/man': Invalid argument cp: preserving permissions for `/home/usr/local/share/mindi': Invalid argument cp: preserving permissions for `/home/usr/local/share/mondo': Invalid argument cp: preserving permissions for `/home/usr/local/share': Invalid argument Regards Mark ------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Wed Jun 5 17:46:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g560ktnC024721 for ; Wed, 5 Jun 2002 17:46:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g560ktfC024720 for linux-xfs-outgoing; Wed, 5 Jun 2002 17:46:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g560khnC024692 for ; Wed, 5 Jun 2002 17:46:43 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA08718 for ; Wed, 5 Jun 2002 17:48:42 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA04349; Thu, 6 Jun 2002 10:47:23 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-1) with ESMTP id g560k6Zc001699; Thu, 6 Jun 2002 10:46:07 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-1) id g560k62v001697; Thu, 6 Jun 2002 10:46:06 +1000 Date: Thu, 6 Jun 2002 10:46:06 +1000 From: Nathan Scott To: mark Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: probs with cp -p Message-ID: <20020606004605.GB1413@frodo> References: <200206032201.36167.mark.newman2@ntlworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206032201.36167.mark.newman2@ntlworld.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Mark, > Okay, I just tried with a cvs from last night and the problem persists > > localhost me # cp --parents -pRdf /usr/local/share /home > cp: preserving permissions for `/home/usr/local/share/doc': Invalid argument > cp: preserving permissions for `/home/usr/local/share/man/man1': Invalid > argument > cp: preserving permissions for `/home/usr/local/share/man': Invalid argument > cp: preserving permissions for `/home/usr/local/share/mindi': Invalid > argument cp: preserving permissions for `/home/usr/local/share/mondo': > Invalid argument cp: preserving permissions for `/home/usr/local/share': > Invalid argument Do these files actually have ACLs set on them? (eg. what output does "chacl -l /home/usr/local/share/doc" produce?) Going back to your original mail... On Mon, Jun 03, 2002 at 10:01:36PM +0000, mark wrote: > Hi > > I've been having problems using the following with my xfs fs > > cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/ > ... > direction. I have a small ext3 partition where the comand works fine but its > smaller and different files are involved so this may not be a proof. Are you using the ext2/3 ACL patches in your kernel? This would be interesting to tell whether this is an XFS or a fileutils problem. > SYS_229(0x8054e78, 0x4d286327, 0xbff72684, 0x84, 0x62) = -1 E2BIG (Argument > list too long) OK, so this one we know now is fixed in cvs (getxattr == SYS_229), and was an XFS problem. > stat64("/usr/local/share/mondo", {st_dev=makedev(3, 5), st_ino=25175423, > st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, > st_blocks=0, st_size=32, st_atime=2002/06/03-21:59:11, > st_mtime=2002/06/03-14:18:36, st_ctime=2002/06/03-14:18:36}) = 0 > SYS_226(0x8054df0, 0x4d286370, 0x8054f08, 0x1c, 0) = 0 > SYS_229(0xbff73b9c, 0x4d28633f, 0xbff728b4, 0x84, 0x4d26308d) = -1 ENODATA (No > data available) > SYS_226(0x8054df0, 0x4d286388, 0x8054ea8, 0x4, 0) = -1 EINVAL (Invalid > argument) [ugh, it would help to have strace to know about these new syscalls, then we could see the (all-critical) name of this extended attribute which we're trying to manipulate above.] SYS_226 is setxattr, so we're trying to set an attribute, but size 0x4 looks very small. What does this command say for one of these failing files: getfattr -e hex -d -m . Another piece of useful information, in addition to the strace output, would be the output from ltrace showing which routines are calling the failing library routines. thanks. ps: this is an IA32 machine right? -- Nathan From owner-linux-xfs@oss.sgi.com Wed Jun 5 18:34:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g561YqnC025254 for ; Wed, 5 Jun 2002 18:34:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g561Ypwh025253 for linux-xfs-outgoing; Wed, 5 Jun 2002 18:34:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g561YenC025224 for ; Wed, 5 Jun 2002 18:34:41 -0700 Received: from user-2inia3m.dialup.mindspring.com ([165.121.40.118] helo=waltsathlon.localhost.net) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 17FmCe-0000Es-00 for linux-xfs@oss.sgi.com; Wed, 05 Jun 2002 21:36:40 -0400 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id A700B162C3F4; Wed, 5 Jun 2002 18:34:53 -0700 (PDT) Message-ID: <3CFEBC3D.3080308@mindspring.com> Date: Wed, 05 Jun 2002 18:34:53 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: mark.newman2@ntlworld.com Cc: linux-xfs Subject: Re: probs with cp -p References: <200206060043.54987.mark.newman2@ntlworld.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi mark, I just tried doing the exact command you provided below in my recently installed gentoo system and it completes fine. I'm not using any acl's here, and do not have any acl tools installed. I'm using the kernel package from gentoo-sources from the 1.1a release which reports itself as: Linux virtualgentoo.localhost.net 2.4.19-gentoo-r5 #1 Sat Jun 1 23:28:51 PDT 2002 i686 AuthenticAMD XFS is compiled into the kernel with quota support using the 2.95.3 stock gcc. The only major thing that (might be) different between our setups, is that I'm running this under vmware for consideration as a future distro to use. -Walt mark wrote: > On Wednesday 05 June 2002 02:34, Nathan Scott wrote: > >>On Tue, Jun 04, 2002 at 01:27:59PM -0800, Ethan Benson wrote: >> >>>On Tue, Jun 04, 2002 at 10:56:45AM +0000, mark wrote: >>> >>>>Okay I have now tried a vanilla 2.4.18 with XFS 1.1 kernel (just to >>>>ensure it wasnt a problem with my patched 2.4.19) with similar results. >>>> 'Argument too long' dissapeared but I still get the 'invalid argument' >>>>message. Could there be some kind of problem with my filesystem. >>> >>I doubt it, this error is more likely a coding issue in the kernel, >>rather than an on-disk problem. >> >> >>>>Is there more info I could provide? >>> >>>i think he meant try current cvs as of yesterday, it looks >> >>There have been several related fixes, incl. yesterdays fix - please >>try a current CVS kernel, Mark & let me know if it still fails. >> >>cheers. > > > Okay, I just tried with a cvs from last night and the problem persists > > localhost me # cp --parents -pRdf /usr/local/share /home > cp: preserving permissions for `/home/usr/local/share/doc': Invalid argument > cp: preserving permissions for `/home/usr/local/share/man/man1': Invalid > argument > cp: preserving permissions for `/home/usr/local/share/man': Invalid argument > cp: preserving permissions for `/home/usr/local/share/mindi': Invalid > argument cp: preserving permissions for `/home/usr/local/share/mondo': > Invalid argument cp: preserving permissions for `/home/usr/local/share': > Invalid argument > > > Regards > > Mark > > ------------------------------------------------------- > > From owner-linux-xfs@oss.sgi.com Wed Jun 5 18:44:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g561iMnC025449 for ; Wed, 5 Jun 2002 18:44:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g561iMLA025448 for linux-xfs-outgoing; Wed, 5 Jun 2002 18:44:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g561iFnC025420 for ; Wed, 5 Jun 2002 18:44:16 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAB09983 for ; Wed, 5 Jun 2002 18:46:12 -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 LAA12326 for linux-xfs@oss.sgi.com; Thu, 6 Jun 2002 11:44:54 +1000 (EST) Date: Thu, 6 Jun 2002 11:44:54 +1000 (EST) From: Nathan Scott Message-Id: <200206060144.LAA12326@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - user/kernel sync ups X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 4 18:58:05 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:120863a cmd/xfsprogs/include/xfs_log.h - 1.10 - sync up with kernel (backs out last change). Date: Wed Jun 5 18:35:36 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:120976a cmd/xfsprogs/libxfs/bit.c - 1.1 - rationalise bit manipulation routines in userspace. cmd/xfsprogs/include/xfs_bit.h - 1.8 - sync user/kernel, mark extern functions as extern, make comments consistent. cmd/xfsprogs/libxfs/Makefile - 1.12 - rationalise bit manipulation routines in userspace. Modid: 2.4.x-xfs:slinx:120976b linux/fs/xfs/xfs_bit.h - 1.12 - sync user/kernel, mark extern functions as extern, make comments consistent. From owner-linux-xfs@oss.sgi.com Wed Jun 5 19:03:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5623UnC025720 for ; Wed, 5 Jun 2002 19:03:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5623TdK025719 for linux-xfs-outgoing; Wed, 5 Jun 2002 19:03:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from AVQIMAIL1.paq.av.com (avqimail1.corp.altavista.com [209.73.174.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5623NnC025690 for ; Wed, 5 Jun 2002 19:03:24 -0700 Received: from Local loopback [127.0.0.1] by AVQIMAIL1.paq.av.com - SuperScout Email Filter (4.0); Wednesday, 05 June 2002, 19:04:04 Message-ID: <2A554097CA54D511BE7D00508B6F5A5020E3F4@avqimail4.paq.av.com> From: David Hallman To: "'linux-xfs@oss.sgi.com'" Cc: "'lord@sgi.com'" , "'Imad.Ossaily@nokia.com'" , "'knuffie@xs4all.nl'" Date: Wed, 5 Jun 2002 19:01:35 -0700 Subject: Xfs prblems with clearcase mvfs MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I came across this thread http://marc.theaimsgroup.com/?l=linux-xfs&m=99552661303036&w=2 from almost a year ago. I don't see that any conclusion was reached. Has anyone been sucessful in getting ClearCase MVFS working with xfs or found some other solution? We are trying to use RedHat 7.2 (kernel 2.4.18), SGI xfs 1.0.2 and ClearCase 4.2. Everything seems to work except the MVFS will not load. I'm desperate for this to work since all our development is moving to this platform in the very near future (like now) and limiting development to snapshot views will be a huge problem for us - we can barely get our developers to do merges much less keep snapshot views up-to-date... :( Thanks. /dave David L. Hallman Mgr, Configuration and Release Engineering AltaVista - The Search Company david.hallman@av.com Office: 650-320-6362 Cell: 650-537-1750 MobileEmail: 6505371750@messaging.nextel.com Please email ccase-request@av.com for all ClearCase/DDTS and SCM issues. AltaVista http://www.altavista.com From owner-linux-xfs@oss.sgi.com Wed Jun 5 19:18:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g562IhnC026039 for ; Wed, 5 Jun 2002 19:18:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g562Ih0s026038 for linux-xfs-outgoing; Wed, 5 Jun 2002 19:18:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g562IZnC026010 for ; Wed, 5 Jun 2002 19:18:35 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA80582; Wed, 5 Jun 2002 21:20:14 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-43.corp.sgi.com [134.15.64.43]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA19981; Wed, 5 Jun 2002 21:20:12 -0500 (CDT) Subject: Re: Xfs prblems with clearcase mvfs From: Stephen Lord To: David Hallman Cc: "'linux-xfs@oss.sgi.com'" , "'Imad.Ossaily@nokia.com'" , "'knuffie@xs4all.nl'" In-Reply-To: <2A554097CA54D511BE7D00508B6F5A5020E3F4@avqimail4.paq.av.com> References: <2A554097CA54D511BE7D00508B6F5A5020E3F4@avqimail4.paq.av.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 05 Jun 2002 21:15:45 -0500 Message-Id: <1023329746.1179.7.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-05 at 21:01, David Hallman wrote: > > I came across this thread > http://marc.theaimsgroup.com/?l=linux-xfs&m=99552661303036&w=2 from almost a > year ago. I don't see that any conclusion was reached. Has anyone been > sucessful in getting ClearCase MVFS working with xfs or found some other > solution? > > We are trying to use RedHat 7.2 (kernel 2.4.18), SGI xfs 1.0.2 and ClearCase > 4.2. Everything seems to work except the MVFS will not load. > > I'm desperate for this to work since all our development is moving to this > platform in the very near future (like now) and limiting development to > snapshot views will be a huge problem for us - we can barely get our > developers to do merges much less keep snapshot views up-to-date... :( I presume you are getting the same sorts of errors from the clearcase module that this message describes. Basically clearcase is a binary module built against specific kernel headers, and it appears to have checks built in which ensure it is being used in a compatible kernel. Their technique basically limits the range of kernels the module will build into. I doubt clearcase will rebuild you a special version, which means the only way to get this to go any further is to fix up the structure sizes which XFS changes. There should be less of these than there used to be, and if my memory serves me correctly, DMAPI and extended attributes are the only things which make things non-standard sizes. It would be possible to get XFS to work without these extensions in the kernel without too much work. Steve From owner-linux-xfs@oss.sgi.com Wed Jun 5 22:13:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g565DrnC027590 for ; Wed, 5 Jun 2002 22:13:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g565DrNQ027589 for linux-xfs-outgoing; Wed, 5 Jun 2002 22:13:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g565DjnC027561 for ; Wed, 5 Jun 2002 22:13:46 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g565Filp011817; Thu, 6 Jun 2002 07:15:44 +0200 (CEST) Message-Id: <4.3.2.7.2.20020606071526.0431c8e0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 06 Jun 2002 07:16:32 +0200 To: utz lehmann , Florin Andrei From: Seth Mos Subject: Re: RAID Controller Caching and XFS Cc: linux-xfs In-Reply-To: <20020605234913.A29557@s2y4n2c.de> References: <1023314217.32329.32.camel@stantz.corp.sgi.com> <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> <20020605160422.A14886@pla-muek.reefedge.com> <1023314217.32329.32.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 23:49 5-6-2002 +0200, utz lehmann wrote: >Hi > >Florin Andrei [florin@sgi.com] wrote: > > On Wed, 2002-06-05 at 13:04, Thor Lancelot Simon wrote: > > > > > > More importantly, you don't *want* to use readahead because it will waste > > > valuable cache space on the controller that could be used to cache small > > > writes. > > > > How safe is it to enable caching for writes on the controller (if you > > don't have a battery on it)? > > I mean, i configured my Mylex with "Write Through" for data-safety > > reasons, even though the other option ("Write Back") could offer > > improved performance. > >It's not (really) safe, see >http://oss.sgi.com/projects/xfs/mail_archive/200205/msg00510.html He is talking about a add-in card with it's own battery backup. The mail you referenced is about a externel raid device without a battery backup. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jun 6 02:01:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5691nnC032629 for ; Thu, 6 Jun 2002 02:01:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5691n7K032628 for linux-xfs-outgoing; Thu, 6 Jun 2002 02:01:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from comm.hcsd.de (comm-ext2.hcsd.de [217.146.142.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5691cnC032599 for ; Thu, 6 Jun 2002 02:01:39 -0700 Received: from babbage.hcsd.de (babbage.hcsd.de [192.168.100.5]) by comm.hcsd.de (8.12.2/8.12.2) with ESMTP id g5693c8v011448 for ; Thu, 6 Jun 2002 11:03:38 +0200 Received: (from au@localhost) by babbage.hcsd.de (8.11.3/8.11.3) id g5693cM27836 for linux-xfs@oss.sgi.com; Thu, 6 Jun 2002 11:03:38 +0200 Date: Thu, 6 Jun 2002 11:03:38 +0200 From: Stephan Austermuehle To: linux-xfs@oss.sgi.com Subject: Problems with xfsdump on snapshot LV Message-ID: <20020606110338.A27807@babbage.hcsd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I did the following: # xfs_freeze -f /usr # lvcreate -L 256m -n /dev/vg00/lv_usr_snap -s /dev/vg00/lv_usr # xfs_freeze -u /usr # mount -t xfs -o ro,nouuid /dev/vg00/lv_usr_snap /mnt # xfsdump -l 0 -p 60 - /mnt |buffer ... > /dev/nst1 This results in the following error messages: XFS mounting filesystem lvm(58,19) lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap I/O error in filesystem ("lvm(58,19)") meta-data dev 0x3a13 block 0x1007fc ("xlog_iodone") error 5 buf count 6656 xfs_force_shutdown(lvm(58,19),0x2) called from line 939 of file xfs_log.c. Return address = 0xc01bdbe6 Log I/O Error Detected. Shutting down filesystem: lvm(58,19) Please umount the filesystem, and rectify the problem(s) Unable to handle kernel NULL pointer dereference at virtual address 00000020 printing eip: c0131f02 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted EFLAGS: 00010202 eax: 00003a13 ebx: 00000000 ecx: 00003a13 edx: 00003a13 esi: 00000001 edi: 00000000 ebp: 00000000 esp: d01fdd60 ds: 0018 es: 0018 ss: 0018 Process lvremove (pid: 25437, stackpage=d01fd000) Stack: dfed8740 df466400 c0347df6 dfb6d000 3a13d000 00000000 00000000 c0132000 dfed8740 00000000 dfe3b370 c0237668 00003a13 00000000 00003a13 00000000 bffff5ac c0347e64 dfb6d000 00000180 dfb6d4c4 00000010 c0234c21 00000000 Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 8b 7b 20 0f b7 54 24 12 66 39 53 0c 0f 85 84 00 00 00 83 7b Why does xfsdump try to write to a filesystem that should be backup'd? Thanks for your help, Stephan From owner-linux-xfs@oss.sgi.com Thu Jun 6 03:21:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56ALvnC008692 for ; Thu, 6 Jun 2002 03:21:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56ALvJZ008691 for linux-xfs-outgoing; Thu, 6 Jun 2002 03:21:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56AL8nC008660 for ; Thu, 6 Jun 2002 03:21:08 -0700 Received: from localhost ([80.1.68.230]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020606102307.WQQX295.mta03-svc.ntlworld.com@localhost>; Thu, 6 Jun 2002 11:23:07 +0100 Content-Type: text/plain; charset="iso-8859-1" From: mark Reply-To: mark.newman2@ntlworld.com Organization: mark To: Nathan Scott Subject: Re: probs with cp -p Date: Thu, 6 Jun 2002 12:19:47 +0100 User-Agent: KMail/1.4.1 Cc: "'linux-xfs@oss.sgi.com'" References: <200206032201.36167.mark.newman2@ntlworld.com> <20020606004605.GB1413@frodo> In-Reply-To: <20020606004605.GB1413@frodo> MIME-Version: 1.0 Message-Id: <200206061219.47056.mark.newman2@ntlworld.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g56AL9nC008661 X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,GAPPY_TEXT version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thursday 06 June 2002 01:46, Nathan Scott wrote: > hi Mark, > > > Okay, I just tried with a cvs from last night and the problem persists > > > > localhost me # cp --parents -pRdf /usr/local/share /home > > cp: preserving permissions for `/home/usr/local/share/doc': Invalid > > argument cp: preserving permissions for `/home/usr/local/share/man/man1': > > Invalid argument > > cp: preserving permissions for `/home/usr/local/share/man': Invalid > > argument cp: preserving permissions for `/home/usr/local/share/mindi': > > Invalid argument cp: preserving permissions for > > `/home/usr/local/share/mondo': Invalid argument cp: preserving > > permissions for `/home/usr/local/share': Invalid argument > > Do these files actually have ACLs set on them? (eg. what output does > "chacl -l /home/usr/local/share/doc" produce?) > chacl -l /home/usr/local/share/doc /home/usr/local/share/doc [u::rwx,g::r-x,o::r-x] > Going back to your original mail... > > On Mon, Jun 03, 2002 at 10:01:36PM +0000, mark wrote: > > Hi > > > > I've been having problems using the following with my xfs fs > > > > cp --parents -pRdf /usr/local/share/mondo /home/mondo.scratch.1050/ > > ... > > direction. I have a small ext3 partition where the comand works fine but > > its smaller and different files are involved so this may not be a proof. > > Are you using the ext2/3 ACL patches in your kernel? This would be > interesting to tell whether this is an XFS or a fileutils problem. > When I tried using the cvs kernel I applied no extra patches. I did use my same .config but file have applied no patches. > > SYS_229(0x8054e78, 0x4d286327, 0xbff72684, 0x84, 0x62) = -1 E2BIG > > (Argument list too long) > > OK, so this one we know now is fixed in cvs (getxattr == SYS_229), > and was an XFS problem. > > > stat64("/usr/local/share/mondo", {st_dev=makedev(3, 5), st_ino=25175423, > > st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, > > st_blocks=0, st_size=32, st_atime=2002/06/03-21:59:11, > > st_mtime=2002/06/03-14:18:36, st_ctime=2002/06/03-14:18:36}) = 0 > > SYS_226(0x8054df0, 0x4d286370, 0x8054f08, 0x1c, 0) = 0 > > SYS_229(0xbff73b9c, 0x4d28633f, 0xbff728b4, 0x84, 0x4d26308d) = -1 > > ENODATA (No data available) > > SYS_226(0x8054df0, 0x4d286388, 0x8054ea8, 0x4, 0) = -1 EINVAL (Invalid > > argument) > > [ugh, it would help to have strace to know about these new syscalls, > then we could see the (all-critical) name of this extended attribute > which we're trying to manipulate above.] > > SYS_226 is setxattr, so we're trying to set an attribute, but size 0x4 > looks very small. What does this command say for one of these failing > files: > getfattr -e hex -d -m . > Here's the complete strace, sorry for the size, I'll keep this off list if thats okay ********************************************************************************************************** # strace -v cp --parents -pRdf /usr/local/share/doc /home localhost linux # strace -v cp --parents -pRdf /usr/local/share/doc /home execve("/bin/cp", ["cp", "--parents", "-pRdf", "/usr/local/share/doc", "/home"], [/* 28 vars */]) = 0 brk(0) = 0x8054284 open("/etc/ld.so.preload", O_RDONLY) = 3 fstat64(3, {st_dev=makedev(3, 5), st_ino=25223927, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2002/06/06-11:24:35, st_mtime=2002/06/06-11:24:35, st_ctime=2002/06/06-11:24:35}) = 0 close(3) = 0 open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_dev=makedev(3, 5), st_ino=25253176, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=128, st_size=64799, st_atime=2002/06/06-11:58:25, st_mtime=2002/06/06-11:24:34, st_ctime=2002/06/06-11:24:34}) = 0 old_mmap(NULL, 64799, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40016000 close(3) = 0 open("/lib/libacl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200\23"..., 1024) = 1024 fstat64(3, {st_dev=makedev(3, 5), st_ino=18946179, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=56, st_size=27874, st_atime=2002/06/06-11:58:25, st_mtime=2002/03/31-19:35:14, st_ctime=2002/03/31-19:35:15}) = 0 old_mmap(NULL, 22084, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40026000 mprotect(0x4002b000, 1604, PROT_NONE) = 0 old_mmap(0x4002b000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x4000) = 0x4002b000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\230\223"..., 1024) = 1024 fstat64(3, {st_dev=makedev(3, 5), st_ino=13398130, st_mode=S_IFREG|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=2512, st_size=1282712, st_atime=2002/06/06-11:58:25, st_mtime=2002/06/05-23:54:26, st_ctime=2002/06/05-23:54:49}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4002c000 old_mmap(NULL, 1240672, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4002d000 mprotect(0x40152000, 40544, PROT_NONE) = 0 old_mmap(0x40152000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x124000) = 0x40152000 old_mmap(0x40158000, 15968, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40158000 close(3) = 0 open("/lib/libattr.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240\t\0"..., 1024) = 1024 fstat64(3, {st_dev=makedev(3, 5), st_ino=67374403, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=24, st_size=9856, st_atime=2002/06/06-11:58:25, st_mtime=2002/03/31-18:10:41, st_ctime=2002/03/31-18:10:42}) = 0 old_mmap(NULL, 10036, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4015c000 mprotect(0x4015e000, 1844, PROT_NONE) = 0 old_mmap(0x4015e000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1000) = 0x4015e000 close(3) = 0 munmap(0x40016000, 64799) = 0 brk(0) = 0x8054284 brk(0x80542ac) = 0x80542ac brk(0x8055000) = 0x8055000 geteuid32() = 0 lstat64("/home", {st_dev=makedev(3, 7), st_ino=128, st_mode=S_IFDIR|0755, st_nlink=9, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=131, st_atime=2002/04/01-00:30:09, st_mtime=2002/06/06-00:41:31, st_ctime=2002/06/06-00:41:31}) = 0 stat64("/home", {st_dev=makedev(3, 7), st_ino=128, st_mode=S_IFDIR|0755, st_nlink=9, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=131, st_atime=2002/04/01-00:30:09, st_mtime=2002/06/06-00:41:31, st_ctime=2002/06/06-00:41:31}) = 0 lstat64("/home/usr/local/share", {st_dev=makedev(3, 7), st_ino=10121920, st_mode=S_IFDIR|0755, st_nlink=6, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=62, st_atime=2002/06/06-11:45:02, st_mtime=2002/06/02-18:46:28, st_ctime=2002/06/06-11:57:45}) = 0 lstat64("/usr/local/share/doc", {st_dev=makedev(3, 5), st_ino=79691929, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=28, st_atime=2002/06/06-11:57:44, st_mtime=2002/05/13-19:13:47, st_ctime=2002/05/13-19:13:47}) = 0 lstat64("/home/usr/local/share/doc", {st_dev=makedev(3, 7), st_ino=4374401, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=28, st_atime=2002/06/06-11:45:02, st_mtime=2002/05/13-19:13:47, st_ctime=2002/06/06-11:57:44}) = 0 open("/dev/null", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = -1 ENOTDIR (Not a directory) open("/usr/local/share/doc", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 fstat64(3, {st_dev=makedev(3, 5), st_ino=79691929, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=28, st_atime=2002/06/06-11:57:44, st_mtime=2002/05/13-19:13:47, st_ctime=2002/05/13-19:13:47}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 brk(0x8057000) = 0x8057000 getdents64(0x3, 0x8054798, 0x1000, 0) = 104 getdents64(0x3, 0x8054798, 0x1000, 0) = 0 close(3) = 0 lstat64("/usr/local/share/doc/doc", {st_dev=makedev(3, 5), st_ino=4219189, st_mode=S_IFLNK|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=9, st_atime=2002/06/06-11:57:44, st_mtime=2002/04/01-10:49:14, st_ctime=2002/04/01-10:49:19}) = 0 lstat64("/home/usr/local/share/doc/doc", {st_dev=makedev(3, 7), st_ino=4374402, st_mode=S_IFLNK|0755, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=9, st_atime=2002/06/06-11:57:44, st_mtime=2002/06/06-11:57:44, st_ctime=2002/06/06-11:57:44}) = 0 stat64("/usr/local/share/doc", {st_dev=makedev(3, 5), st_ino=79691929, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=28, st_atime=2002/06/06-11:58:25, st_mtime=2002/05/13-19:13:47, st_ctime=2002/05/13-19:13:47}) = 0 stat64("/home/usr/local/share/doc", {st_dev=makedev(3, 7), st_ino=4374401, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=28, st_atime=2002/06/06-11:45:02, st_mtime=2002/05/13-19:13:47, st_ctime=2002/06/06-11:57:44}) = 0 unlink("/home/usr/local/share/doc/doc") = 0 readlink("/usr/local/share/doc/doc", "share/doc", 128) = 9 symlink("share/doc", "/home/usr/local/share/doc/doc") = 0 lchown32(0x8054788, 0, 0) = 0 lstat64("/usr/local/share/doc/.keep", {st_dev=makedev(3, 5), st_ino=25236944, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2002/06/06-11:57:44, st_mtime=2002/05/13-19:13:46, st_ctime=2002/05/13-19:13:47}) = 0 lstat64("/home/usr/local/share/doc/.keep", {st_dev=makedev(3, 7), st_ino=4374403, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=0, st_atime=2002/06/06-11:45:02, st_mtime=2002/05/13-19:13:46, st_ctime=2002/06/06-11:57:44}) = 0 open("/usr/local/share/doc/.keep", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_dev=makedev(3, 5), st_ino=25236944, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2002/06/06-11:57:44, st_mtime=2002/05/13-19:13:46, st_ctime=2002/05/13-19:13:47}) = 0 open("/home/usr/local/share/doc/.keep", O_WRONLY|O_TRUNC|O_LARGEFILE) = 4 fstat64(4, {st_dev=makedev(3, 7), st_ino=4374403, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=0, st_atime=2002/06/06-11:45:02, st_mtime=2002/06/06-11:58:25, st_ctime=2002/06/06-11:58:25}) = 0 fstat64(3, {st_dev=makedev(3, 5), st_ino=25236944, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2002/06/06-11:57:44, st_mtime=2002/05/13-19:13:46, st_ctime=2002/05/13-19:13:47}) = 0 read(3, "", 4096) = 0 close(4) = 0 close(3) = 0 utime("/home/usr/local/share/doc/.keep", [2002/06/06-11:57:44, 2002/05/13-19:13:46]) = 0 SYS_229(0x8054768, 0x4002a327, 0xbffff294, 0x84, 0x62) = -1 ENODATA (No data available) stat64("/usr/local/share/doc/.keep", {st_dev=makedev(3, 5), st_ino=25236944, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=0, st_atime=2002/06/06-11:58:25, st_mtime=2002/05/13-19:13:46, st_ctime=2002/05/13-19:13:47}) = 0 SYS_226(0x8054788, 0x4002a370, 0x8054840, 0x1c, 0) = 0 utime("/home/usr/local/share/doc", [2002/06/06-11:57:44, 2002/05/13-19:13:47]) = 0 SYS_229(0xbffffce0, 0x4002a327, 0xbffff554, 0x84, 0) = -1 ENODATA (No data available) stat64("/usr/local/share/doc", {st_dev=makedev(3, 5), st_ino=79691929, st_mode=S_IFDIR|0755, st_nlink=2, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=0, st_size=28, st_atime=2002/06/06-11:58:25, st_mtime=2002/05/13-19:13:47, st_ctime=2002/05/13-19:13:47}) = 0 SYS_226(0x8054710, 0x4002a370, 0x80547f8, 0x1c, 0) = 0 SYS_229(0xbffffce0, 0x4002a33f, 0xbffff554, 0x84, 0) = -1 ENODATA (No data available) SYS_226(0x8054710, 0x4002a388, 0x8054798, 0x4, 0) = -1 EINVAL (Invalid argument) write(2, "cp: ", 4cp: ) = 4 write(2, "preserving permissions for `/hom"..., 54preserving permissions for `/home/usr/local/share/doc') = 54 write(2, ": Invalid argument", 18: Invalid argument) = 18 write(2, "\n", 1 ) = 1 geteuid32() = 0 _exit(1) = ? localhos > Another piece of useful information, in addition to the strace output, > would be the output from ltrace showing which routines are calling the > failing library routines. localhost linux # ltrace cp --parents -pRdf /usr/local/share/doc /home __libc_start_main(0x0804a808, 5, 0xbffffbb4, 0x08049104, 0x08050280 __register_frame_info(0x08053e34, 0x08054078, 0xbffffb58, 0x4005a7cf, 0x40157020) = 0x08053e34 setlocale(6, "") = "C" bindtextdomain("fileutils", "/usr/share/locale") = "/usr/share/locale" textdomain("fileutils") = "fileutils" __cxa_atexit(0x0804ecac, 0, 0, 0x080501b0, 0x40157020) = 0 geteuid() = 0 getenv("SIMPLE_BACKUP_SUFFIX") = NULL getopt_long(5, 0xbffffbb4, "abdfHilLprsuvxPRS:V:", 0x0805031c, NULL) = 130 getopt_long(5, 0xbffffbb4, "abdfHilLprsuvxPRS:V:", 0x0805031c, NULL) = 112 getopt_long(5, 0xbffffbb4, "abdfHilLprsuvxPRS:V:", 0x0805031c, NULL) = 82 getopt_long(5, 0xbffffbb4, "abdfHilLprsuvxPRS:V:", 0x0805031c, NULL) = 100 getopt_long(5, 0xbffffbb4, "abdfHilLprsuvxPRS:V:", 0x0805031c, NULL) = 102 getopt_long(5, 0xbffffbb4, "abdfHilLprsuvxPRS:V:", 0x0805031c, NULL) = -1 malloc(40) = 0x080542c0 malloc(1048) = 0x080542f0 __lxstat64(3, 0xbffffcf5, 0xbffffa3c, 17827, 0xbffffae4) = 0 __xstat64(3, 0xbffffcf5, 0xbffff9dc, 17827, 0xbffffae4) = 0 memcpy(0xbffff914, "/usr/local/share/doc", 21) = 0xbffff914 malloc(27) = 0x08054710 __mempcpy(0x08054710, 0xbffffcf5, 5, 0x0804fbc3, 0xbffff914) = 0x08054715 memcpy(0x08054715, "/usr/local/share/doc", 20) = 0x08054715 strcpy(0xbffff844, "/home/usr/local/share/doc") = 0xbffff844 memcpy(0xbffff824, "/home/usr/local/share", 21) = 0xbffff824 __lxstat64(3, 0xbffff824, 0xbffff88c, 0x0805021c, 0xbffff88c) = 0 __lxstat64(3, 0xbffffce0, 0xbffff83c, 0x0805021c, 0xbffff83c) = 0 __lxstat64(3, 0x08054710, 0xbffff7dc, 0x0805021c, 0xbffff7dc) = 0 malloc(20) = 0x08054730 malloc(26) = 0x08054748 strcpy(0x08054748, "/home/usr/local/share/doc") = 0x08054748 opendir("/usr/local/share/doc") = 0x08054768 malloc(512) = 0x080557a0 __errno_location() = 0x40157c20 readdir64(0x08054768, 0x080542c0, 0x40000000, 0x08048e9c, 0xbffffae4) = 0x08054798 readdir64(0x08054768, 0x080542c0, 0x40000000, 0x08048e9c, 0xbffffae4) = 0x080547b0 readdir64(0x08054768, 0x080542c0, 0x40000000, 0x08048e9c, 0xbffffae4) = 0x080547c8 memcpy(0x080557a0, "doc", 4) = 0x080557a0 readdir64(0x08054768, 0x080547db, 4, 0x08048e9c, 0xbffffae4) = 0x080547e0 memcpy(0x080557a4, ".keep", 6) = 0x080557a4 readdir64(0x08054768, 0x080547f3, 6, 0x08048e9c, 0xbffffae4) = 0 __errno_location() = 0x40157c20 closedir(0x08054768) = 0 malloc(25) = 0x08054768 __mempcpy(0x08054768, 0xbffffce0, 20, 0x4009fc7a, 0xbffffae4) = 0x0805477c memcpy(0x0805477d, "doc", 3) = 0x0805477d malloc(30) = 0x08054788 __mempcpy(0x08054788, 0x08054710, 25, 0x0804eec0, 0x08054768) = 0x080547a1 memcpy(0x080547a2, "doc", 3) = 0x080547a2 __lxstat64(3, 0x08054768, 0xbffff55c, 0x0805021c, 0xbffff55c) = 0 __lxstat64(3, 0x08054788, 0xbffff4fc, 0x0805021c, 0xbffff4fc) = 0 malloc(21) = 0x080547b0 memcpy(0x080547b0, "/usr/local/share/doc", 20) = 0x080547b0 malloc(26) = 0x080547d0 memcpy(0x080547d0, "/home/usr/local/share/doc", 25) = 0x080547d0 __xstat64(3, 0x080547b0, 0xbffff26c, 1840, 0xbffff55c) = 0 __xstat64(3, 0x080547d0, 0xbffff20c, 1840, 0xbffff55c) = 0 free(0x080547b0) = free(0x080547d0) = unlink("/home/usr/local/share/doc/doc") = 0 malloc(128) = 0x080547b0 readlink(0x08054768, 0x080547b0, 128, 0x0804fd9a, 128) = 9 symlink("share/doc", "/home/usr/local/share/doc/doc") = 0 free(0x080547b0) = lchown(0x08054788, 0, 0, 0x400301e8, 0x08054768) = 0 free(0x08054788) = free(0x08054768) = malloc(27) = 0x08054768 __mempcpy(0x08054768, 0xbffffce0, 20, 0x400a05b7, 0x08054768) = 0x0805477c memcpy(0x0805477d, ".keep", 5) = 0x0805477d malloc(32) = 0x08054788 __mempcpy(0x08054788, 0x08054710, 25, 0x0804eec0, 0x08054768) = 0x080547a1 memcpy(0x080547a2, ".keep", 5) = 0x080547a2 __lxstat64(3, 0x08054768, 0xbffff55c, 0x0805021c, 0xbffff55c) = 0 __lxstat64(3, 0x08054788, 0xbffff4fc, 0x0805021c, 0xbffff4fc) = 0 open64(0x08054768, 0, 0, 0x0b7b29cb, 32768) = 3 __fxstat64(3, 3, 0xbffff2fc, 0x0b7b29cb, 32768) = 0 open64(0x08054788, 513, 33188, 0x0b7b29cb, 32768) = 4 __fxstat64(3, 4, 0xbffff35c, 0x0b7b29cb, 32768) = 0 __fxstat64(3, 3, 0xbffff35c, 0x0b7b29cb, 32768) = 0 read(3, "", 4096) = 0 close(4) = 0 close(3) = 0 utime(0x08054788, 0xbffff428, 0, 0x400301e8, 0x08054768) = 0 acl_get_file(0x08054768, 32768, 0x08048a6a, 0x40030b78, 32768) = 0x080547b4 acl_set_file(0x08054788, 32768, 0x080547b4, 0x40030b78, 32768) = 0 acl_free(0x080547b4, 32768, 0x080547b4, 0x40030b78, 32768) = 0 free(0x08054788) = free(0x08054768) = free(0x080557a0) = utime(0x08054710, 0xbffff708, 0, 0x0804c1e7, 0) = 0 acl_get_file(0xbffffce0, 32768, 0x08050210, 0, 0xbffff6a4) = 0x0805476c acl_set_file(0x08054710, 32768, 0x0805476c, 0, 0xbffff6a4) = 0 acl_free(0x0805476c, 32768, 0x0805476c, 0, 0xbffff6a4) = 0 acl_get_file(0xbffffce0, 16384, 0x0805476c, 0, 0xbffff6a4) = 0x08054784 acl_set_file(0x08054710, 16384, 0x08054784, 0, 0xbffff6a4) = -1 __ctype_get_mb_cur_max(256, 0x08054140, 0, 0x4002a180, 0x4002b574) = 1 dcgettext(0, 0x0805294a, 5, 0x4009fb14, 0) = 0x0805294a dcgettext(0, 0x0805294c, 5, 0x0804f01f, 0) = 0x0805294c dcgettext(0, 0x08052606, 5, 0xbffff68c, 0x08054140) = 0x08052606 __errno_location() = 0x40157c20 error(0, 22, 0x08052606, 0x08054140, 0x08054710cp: preserving permissions for `/home/usr/local/share/doc': Invalid argument ) = 0 acl_free(0x08054784, 16384, 0x08054784, 0, 0xbffff6a4) = 0 geteuid() = 0 strcpy(0xbffff854, "/home/usr/local/share/doc") = 0xbffff854 free(0x08054710) = free(0x08054748) = free(0x08054730) = free(0x080542f0) = free(0x080542c0) = exit(1 __fpending(0x40154420, 0x401548c0, 0xbffffa3c, 0x400a05b7, 0x40157020) = 0 __deregister_frame_info(0x08053e34, 0, 0x40015a2c, 0x4002c468, 1) = 0 +++ exited (status 1) +++ localhost > > thanks. > > ps: this is an IA32 machine right? Yes ia32 smp Regards Mark From owner-linux-xfs@oss.sgi.com Thu Jun 6 03:25:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56APBnC008870 for ; Thu, 6 Jun 2002 03:25:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56APB5D008869 for linux-xfs-outgoing; Thu, 6 Jun 2002 03:25:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpstore.strencom.net (IDENT:postfix@[217.75.0.67]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56AP0nC008841 for ; Thu, 6 Jun 2002 03:25:04 -0700 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id B7DF3C323C for ; Thu, 6 Jun 2002 11:35:59 +0100 (IST) Received: from no.name.available by raptor.raidtec.ie via smtpd (for [217.75.0.67]) with SMTP; 6 Jun 2002 11:11:31 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: ACL and File Mode Date: Thu, 6 Jun 2002 11:27:00 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems with xfsdump on snapshot LV Thread-Index: AcINOWOg27vaMibxQsGnLjem71KNhAACeB0Q From: "Juer Lee" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g56AP4nC008842 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk XFS Gurus, Quick question about ACL and file mode. According POSIX1003.1eD16, in file mode the MASK is set instead of the GROUP entry, if there is a MASK. Why don't we use MASK AND GROUP Bit? Are there any potential problems if we do it like that? I found a problem with Samba 2.2.4 + Linux2.4.18 + XFS 1.1. This is what I get: ( note: 'aaaa' is created from a samba client, and the parent directory's default acl is u::rwx,g::rwx,o::rwx,u:aa:r-x,m::rwx ) ------------------------------------------------------------------------ --------- bash-2.04# ls -l aaaa -rwxrwxrw- 1 juer.lee users 0 Feb 25 07:42 aaaa bash-2.04# getfacl aaaa # file: aaaa # owner: juer.lee # group: users user::rwx group::rw- other::rw- user:aa:r-x mask::rwx ------------------------------------------------------------------------ --------- When I use LS command, it says all owning-group users have full access right, it is not right --- the result got from GETFACL reflected correctly. Could anybody tell me a solution? My solution is set the group entry bits as GROUP_ENTRY & MASK if there is a MASK, but it is not the POSIX1003.1eD16 standard. Juer From owner-linux-xfs@oss.sgi.com Thu Jun 6 04:05:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56B55nC009746 for ; Thu, 6 Jun 2002 04:05:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56B55Vj009745 for linux-xfs-outgoing; Thu, 6 Jun 2002 04:05:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56B4mnC009703 for ; Thu, 6 Jun 2002 04:04:48 -0700 Received: from erbenson.alaska.net (51-pm33.nwc.alaska.net [209.112.159.51]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g56B6lR06915 for ; Thu, 6 Jun 2002 03:06:47 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 7A40E3939 for ; Thu, 6 Jun 2002 03:06:46 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id D605710294; Thu, 6 Jun 2002 03:06:45 -0800 (AKDT) Date: Thu, 6 Jun 2002 03:06:45 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: ACL and File Mode Message-ID: <20020606030645.A9152@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from Juer.Lee@raidtec.ie on Thu, Jun 06, 2002 at 11:27:00AM +0100 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 06, 2002 at 11:27:00AM +0100, Juer Lee wrote: > XFS Gurus,=20 >=20 > Quick question about ACL and file mode. > According POSIX1003.1eD16, in file mode the MASK is set instead of the > GROUP entry, if there is a MASK. Why don't we use MASK AND GROUP Bit? > Are there any potential problems if we do it like that? i asked this question to the acl developers and they ignored me. it seems to me the behavior defined in the withdrawn posix draft just breaks things, i cannot think of any advantage to not making=20 chmod g=3Dwhatever affect both the mask and group permissions.=20=20 i also see no reason to treat a *withdrawn* draft standard as the word of god, the fact it was withdrawn indicates at least to me that there was still some brokeness which was never resolved. > I found a problem with Samba 2.2.4 + Linux2.4.18 + XFS 1.1.=20 >=20 > This is what I get: ( note: 'aaaa' is created from a samba client, and > the parent directory's default acl is > u::rwx,g::rwx,o::rwx,u:aa:r-x,m::rwx ) > ------------------------------------------------------------------------ > --------- > bash-2.04# ls -l aaaa=20 > -rwxrwxrw- 1 juer.lee users 0 Feb 25 07:42 aaaa > bash-2.04# getfacl aaaa=20 > # file: aaaa > # owner: juer.lee > # group: users > user::rwx > group::rw- > other::rw- > user:aa:r-x > mask::rwx > ------------------------------------------------------------------------ > --------- > When I use LS command, it says all owning-group users have full access > right, it is not right --- the result got from GETFACL reflected > correctly. well now the fact that ls reports the mask permissions instead of group permissions does have a rational discussed in the posix draft (at least indirectly), the idea is someone can look at the permissions reported by ls and have some idea of the maximum permissions granted to any user. it does have the negative affect of being somewhat misleading, esp to those not very familer with ACLs. > Could anybody tell me a solution? My solution is set the group entry > bits as GROUP_ENTRY & MASK if there is a MASK, but it is not the > POSIX1003.1eD16 standard. i have found there really isn't much of a way to completly get the permissions you want from default acl's as implemented currently, if you want execute bits on everything you can't get them (unless you can control the create mode in the program open() calls), and if you don't want execute bits on additional user ACEs or the primary group you can't get that either.=20 however that being said, the permissions your ending up with don't look right at all from my test purly in unix with the default acl you mention i get: # file: foo # owner: eb # group: eb user::rw- user:build:r-x #effective:r-- group::rwx #effective:rw- mask::rw- other::rw- -rw-rw-rw- 1 eb eb 0 Jun 6 02:57 foo samba is obviously playing with its create mode, probably using 0776 instead of 0666, but that does not explain why your group is getting rw- instead of rwx. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjz/QkUACgkQJKx7GixEevyh5wCfXAbX4kLk7qEfl/nSbK+lxzKy IxgAn16OfGFPCed6jeKx/sWWTLvZb5RO =MOWU -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-linux-xfs@oss.sgi.com Thu Jun 6 04:14:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56BEGnC010012 for ; Thu, 6 Jun 2002 04:14:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56BEGw4010011 for linux-xfs-outgoing; Thu, 6 Jun 2002 04:14:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpstore.strencom.net (IDENT:postfix@[217.75.0.67]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56BE8nC009983 for ; Thu, 6 Jun 2002 04:14:08 -0700 Received: from raptor.raidtec.ie (unknown [217.75.2.18]) by smtpstore.strencom.net (Postfix) with SMTP id 5D46BC323D; Thu, 6 Jun 2002 12:25:06 +0100 (IST) Received: from no.name.available by raptor.raidtec.ie via smtpd (for [217.75.0.67]) with SMTP; 6 Jun 2002 12:00:38 UT content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Subject: RE: ACL and File Mode Date: Thu, 6 Jun 2002 12:15:32 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACL and File Mode Thread-Index: AcINSnXdXgpWAzKbSaiV9lyYSlyCcAAAFC5w From: "Juer Lee" To: "Ethan Benson" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g56BE9nC009984 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Ebnson, Thank you very much,. Yes, I understand what you are saying. Actually, I got the correct persmissions when I use TOUCH to create a file under that directory.... But if I create that file through a samba client machine ( create it remotely , using 0777 as create mask), I got the results same as I sent in last email. It is a samba issue, but the question here doesn't care .... Juer >however that being said, the permissions your ending up with don't >look right at all from my test purly in unix with the default acl you >mention i get: > ># file: foo ># owner: eb ># group: eb >user::rw- >user:build:r-x #effective:r-- >group::rwx #effective:rw- >mask::rw- >other::rw- > >-rw-rw-rw- 1 eb eb 0 Jun 6 02:57 foo > >samba is obviously playing with its create mode, probably using 0776 >instead of 0666, but that does not explain why your group is getting >rw- instead of rwx. > >-- >Ethan Benson >http://www.alaska.net/~erbenson/ > From owner-linux-xfs@oss.sgi.com Thu Jun 6 05:00:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56C01nC010466 for ; Thu, 6 Jun 2002 05:00:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56C00YU010459 for linux-xfs-outgoing; Thu, 6 Jun 2002 05:00:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56BxsnC010428 for ; Thu, 6 Jun 2002 04:59:54 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA83514 for ; Thu, 6 Jun 2002 07:01:50 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA33027 for ; Thu, 6 Jun 2002 07:01:50 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g56BvRj12468; Thu, 6 Jun 2002 06:57:27 -0500 Message-Id: <200206061157.g56BvRj12468@jen.americas.sgi.com> Date: Thu, 6 Jun 2002 06:57:27 -0500 Subject: TAKE - small acl optimization To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Reduces the performance drop when acls are compiled in, but not in use. Date: Thu Jun 6 04:59:51 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:120984a linux/fs/xfs/xfs_acl.h - 1.11 - optimize the case of acls built in but no acls on a file From owner-linux-xfs@oss.sgi.com Thu Jun 6 05:23:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56CNGnC016223 for ; Thu, 6 Jun 2002 05:23:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56CNGhM016222 for linux-xfs-outgoing; Thu, 6 Jun 2002 05:23:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56CMxnC016192 for ; Thu, 6 Jun 2002 05:22:59 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g56COtC27512 for ; Thu, 6 Jun 2002 21:24:55 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g56COsZ07776 for ; Thu, 6 Jun 2002 21:24:54 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g56COs829339 for ; Thu, 6 Jun 2002 21:24:54 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA363 for ; Thu, 6 Jun 2002 21:24:53 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Thu Jun 06 21:24:52 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g56COrA77164 for ; Thu, 6 Jun 2002 21:24:53 +0900 (JST) Received: from NEC4D4BGTKMOBI (TNES017100.bsd.tnes.nec.co.jp [10.1.104.62]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g56COrY32402 for ; Thu, 6 Jun 2002 21:24:53 +0900 Message-ID: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp> From: "=?iso-2022-jp?B?GyRCQ2ZMbiEhR25HNxsoQg==?=" To: Subject: XFS force shutdown : EFSCORRUPTED Date: Thu, 6 Jun 2002 21:24:52 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=1.8 required=5.0 tests=CHARSET_FARAWAY_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi XFS stuff. I met a problem with XFS filesystem. I am using kernel 2.4.18-xfs. Hardware is pentium3 800Mhz,128MB of RAM. XFS goes to force-shutdown everytime when I execute my test suite. Do you have any information for this issue? My test suite consists of a shell-script and a compiled program. It uses XFS command cvs tree (xfs-cmd.tar.gz) as a data for test. My Shell-scrippt (org-g.sh) is : umount /dev/hda7 /usr/src/cmd/xfsprogs/mkfs/mkfs.xfs -f -l agnum=1,size=2000b /dev/hda7 mount /dev/hda7 /mnt/xfs cd /mnt/xfs tar zxvf /test/xfs-cmd.tar.gz /test/test_dev_read cd /test rm -rf /mnt/xfs/cmd and my program (test_dev_read.c) is : #include #include #include #include #include #include int main( argc, argv ) int argc; const char *argv[]; { int fd,ret,i,error; char bufl[4096]; if( ( fd = open( "/dev/hda7" , O_RDONLY , S_IRWXU ) ) < 0 ){ printf( "error= %s\n" , strerror(errno) ); return; } for( i=0; i<1; i++ ){ ret = 40; error = read( fd , bufl , ret ); printf( "test read1 finish = %x \n",(char)bufl[0] ); } if ( lseek( fd, 4096*16, SEEK_CUR ) == -1 ){ printf( "error2= %s\n" , strerror(errno) ); } for( i=0; i<1; i++ ){ ret = 40; error = read( fd , bufl , ret ); printf( "test read2 finish = %x \n",(char)bufl[0] ); } printf( "test program finish \n" ); close( fd ); } This test suite shows following results: [root@bsd241 /root]# /test/org-g.sh meta-data=/dev/hda7 isize=256 agcount=8, agsize=91620 blks data = bsize=4096 blocks=732957, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=2000 realtime =none extsz=65536 blocks=0, rtextents=0 XFS mounting filesystem ide0(3,7) cmd/ cmd/CVS/ cmd/CVS/Root cmd/CVS/Repository cmd/CVS/Entries cmd/CVS/Tag cmd/acl/ cmd/acl/CVS/ cmd/acl/CVS/Root cmd/acl/CVS/Reposito . . . cmd/xfstests/tools/fs-walk cmd/xfstests/tools/interop cmd/xfstests/tools/srcdiff cmd/xfstests/tools/srctest test read1 finish = 58 test read2 finish = 0 test program finish xfs_iunlink_remove: xfs_itobp() returned an error 990 on ide0(3,7). Returning error. xfs_inactive: xfs_ifree() returned an error = 990 on ide0(3,7) xfs_force_shutdown(ide0(3,7),0x1) called from line 1952 of file xfs_vnodeops.c. Return address = 0x c01dadb1 I/O Error Detected. Shutting down filesystem: ide0(3,7) Please umount the filesystem, and rectify the problem(s) rm: cannot remove directory `/mnt/xfs/cmd/attr/build': Input/output error rm: cannot remove directory `/mnt/xfs/cmd/attr': Input/output error rm: cannot remove directory `/mnt/xfs/cmd': Input/output error [root@bsd241 /root]# Please show me why this problem happens. Regards. From owner-linux-xfs@oss.sgi.com Thu Jun 6 05:42:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56CgunC016498 for ; Thu, 6 Jun 2002 05:42:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56Cgu9A016497 for linux-xfs-outgoing; Thu, 6 Jun 2002 05:42:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hotmail.com (f227.law12.hotmail.com [64.4.19.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56CgpnC016469 for ; Thu, 6 Jun 2002 05:42:51 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Jun 2002 05:44:48 -0700 Received: from 217.81.38.77 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 06 Jun 2002 12:44:48 GMT X-Originating-IP: [217.81.38.77] From: "Karl Ran" To: linux-xfs@oss.sgi.com Subject: xfs_check reports errors or warnings? Date: Thu, 06 Jun 2002 12:44:48 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jun 2002 12:44:48.0570 (UTC) FILETIME=[F18D99A0:01C20D57] X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! When im doing: xfs_check /dev/hdc2 I get: allocated inode 307133061 has 0 link count allocated inode 308255403 has 0 link count Should I worry about this? May I loose data soon? Thanks, Karl _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-linux-xfs@oss.sgi.com Thu Jun 6 05:49:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56CnfnC016691 for ; Thu, 6 Jun 2002 05:49:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56Cnfn6016690 for linux-xfs-outgoing; Thu, 6 Jun 2002 05:49:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dmz.tecosim.de (dmz.tecosim.com [195.135.152.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56CnVnC016662 for ; Thu, 6 Jun 2002 05:49:33 -0700 Received: (from uucp@localhost) by dmz.tecosim.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) id g56CpRZ23575; Thu, 6 Jun 2002 14:51:27 +0200 Received: from ns.tecosim.com(195.135.152.146), claiming to be "ns.tecosim.de" via SMTP by dmz.tecosim.com, id smtpd4A22BK; Thu Jun 6 14:51:21 2002 Received: from donner.tecosim.de (donner.tecosim.de [194.24.222.109]) by ns.tecosim.de (8.11.3/8.11.3/SuSE Linux 8.11.1-0.5) with ESMTP id g56CpKO07148; Thu, 6 Jun 2002 14:51:20 +0200 Received: (from leh@localhost) by donner.tecosim.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id g56CpKR31075; Thu, 6 Jun 2002 14:51:20 +0200 Date: Thu, 6 Jun 2002 14:51:20 +0200 From: Utz Lehmann To: Seth Mos Cc: utz lehmann , Florin Andrei , linux-xfs Subject: Re: RAID Controller Caching and XFS Message-ID: <20020606145120.C25038@de.tecosim.com> References: <1023314217.32329.32.camel@stantz.corp.sgi.com> <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> <20020605160422.A14886@pla-muek.reefedge.com> <1023314217.32329.32.camel@stantz.corp.sgi.com> <2 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.12i In-Reply-To: <4.3.2.7.2.20020606071526.0431c8e0@pop.xs4all.nl>; from knuffie@xs4all.nl on Thu, Jun 06, 2002 at 07:16:32AM +0200 X-Scanned-By: MIMEDefang 1.3 (www dot roaringpenguin dot com slash mimedefang) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Seth Seth Mos [knuffie@xs4all.nl] wrote: > At 23:49 5-6-2002 +0200, utz lehmann wrote: > >Hi > > > >Florin Andrei [florin@sgi.com] wrote: > > > On Wed, 2002-06-05 at 13:04, Thor Lancelot Simon wrote: > > > > > > > > More importantly, you don't *want* to use readahead because it will waste > > > > valuable cache space on the controller that could be used to cache small > > > > writes. > > > > > > How safe is it to enable caching for writes on the controller (if you > > > don't have a battery on it)? > > > I mean, i configured my Mylex with "Write Through" for data-safety > > > reasons, even though the other option ("Write Back") could offer > > > improved performance. > > > >It's not (really) safe, see > >http://oss.sgi.com/projects/xfs/mail_archive/200205/msg00510.html > > He is talking about a add-in card with it's own battery backup. The mail > you referenced is about a externel raid device without a battery backup. He sad, that the controller don't have a battery, look above. So it's the same, a poweroutage cause lost of all unwritten data in the controller cache. utz From owner-linux-xfs@oss.sgi.com Thu Jun 6 06:03:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56D3YnC016982 for ; Thu, 6 Jun 2002 06:03:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56D3YF4016981 for linux-xfs-outgoing; Thu, 6 Jun 2002 06:03:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56D3RnC016953 for ; Thu, 6 Jun 2002 06:03:28 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA83740; Thu, 6 Jun 2002 08:05:24 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-29.corp.sgi.com [134.15.64.29]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA45763; Thu, 6 Jun 2002 08:05:22 -0500 (CDT) Subject: Re: xfs_check reports errors or warnings? From: Stephen Lord To: Karl Ran Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 08:05:07 -0500 Message-Id: <1023368708.1701.11.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-06 at 07:44, Karl Ran wrote: > Hi! > > When im doing: > xfs_check /dev/hdc2 > I get: > allocated inode 307133061 has 0 link count > allocated inode 308255403 has 0 link count > > Should I worry about this? > May I loose data soon? You have two inodes which are not connected to a directory. If you are concerned, run xfs_repair on the filesystem and the two unlinked inodes should get put in lost+found. If that was all the output then I doubt you have reason to be worried. Steve > > Thanks, > Karl > > _________________________________________________________________ > Send and receive Hotmail on your mobile device: http://mobile.msn.com From owner-linux-xfs@oss.sgi.com Thu Jun 6 06:12:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56DCanC017756 for ; Thu, 6 Jun 2002 06:12:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56DCatU017755 for linux-xfs-outgoing; Thu, 6 Jun 2002 06:12:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56DCUnC017727 for ; Thu, 6 Jun 2002 06:12:31 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA83647; Thu, 6 Jun 2002 08:14:26 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-29.corp.sgi.com [134.15.64.29]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA84789; Thu, 6 Jun 2002 08:14:25 -0500 (CDT) Subject: Re: XFS force shutdown : EFSCORRUPTED From: Stephen Lord To: nakano@bsd.tnes.nec.co.jp Cc: linux-xfs@oss.sgi.com In-Reply-To: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp> References: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 08:14:09 -0500 Message-Id: <1023369251.1701.20.camel@snafu> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g56DCVnC017728 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-06 at 07:24, 中野　博之 wrote: > > Hi XFS stuff. > > I met a problem with XFS filesystem. > > I am using kernel 2.4.18-xfs. Hardware is pentium3 800Mhz,128MB of RAM. > > XFS goes to force-shutdown everytime when I execute my test suite. > Do you have any information for this issue? I will try this, but in general, I do not think XFS functions correctly with a single allocation group. Do you know which factor here is the trigger for the error - reading the block device, or the single allocation group? Steve From owner-linux-xfs@oss.sgi.com Thu Jun 6 06:22:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56DMlnC018005 for ; Thu, 6 Jun 2002 06:22:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56DMlxS018004 for linux-xfs-outgoing; Thu, 6 Jun 2002 06:22:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cc.itu.edu.tr (mail.cc.itu.edu.tr [160.75.2.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56DGunC017931 for ; Thu, 6 Jun 2002 06:17:01 -0700 Received: from aontws4044 (AONTWS4044.cc.itu.edu.tr [160.75.5.44]) by mail.cc.itu.edu.tr (8.11.2/8.11.2) with SMTP id g56DEbG23779 for ; Thu, 6 Jun 2002 16:14:37 +0300 From: =?iso-8859-9?Q?=DEeref_Tufan_=DEen?= To: Subject: FS Corruption and xfs_repair error Date: Thu, 6 Jun 2002 16:18:48 +0300 Message-ID: <012201c20d5c$b28d4430$2c054ba0@cc.ad.itu.edu.tr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0123_01C20D75.D7DA7C30" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0123_01C20D75.D7DA7C30 Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.cc.itu.edu.tr id g56DEbG23779 Hi, I am running XFS on my 3 file servers. At the beginning of this week =FD = found one of servers fs hass been shut. Two days before coruption my storage device has given timeouts and I had to reboot my servers. After rebooting all came online again and ran fine for two days. Then one of them failed.= I was running linux-2.4.9 at this time , and the old xfsutils. After corruption rebooted the server , umount the fs and then ran xfs_repair. Xfs_repair didn't give any error and fixed the fs. The other day fs becam= e corrupted again. Then I updated my kernel to 2.4.18 and xfsprogs (from 1.= 1 release rpms). After this , running xfs_repair ends with error.(I attache= d the repair.log) I'm runnig XFS on LVM. Only root fs on local disk. All other disks are on= a storage device. The servers have Qlogic2100 HBA's. 2/3 works fine , but o= ne server is has a corrupted fs now and it makes my work too hard. It's an N= FS file server and when it's down all my work stops. Any idea about what can i do?? (Worst case mkfs the fs and return from backup. Please another solution.) Sorry for my english. Jun 3 04:24:23 lnxsrv1 kernel: xfs_inotobp: xfs_imap() returned an erro= r 22 on lvm(58,0). Returning error. Jun 3 04:24:23 lnxsrv1 kernel: xfs_iunlink_remove: xfs_inotobp() return= ed an error 22 on lvm(58,0). Returning error. Jun 3 04:24:23 lnxsrv1 kernel: xfs_inactive: xfs_ifree() returned an er= ror =3D 22 on lvm(58,0) Jun 3 04:24:23 lnxsrv1 kernel: xfs_force_shutdown(lvm(58,0),0x1) called from line 1946 of file xfs_vnodeops.c. Return address =3D 0xc01f3a79 Jun 3 04:24:23 lnxsrv1 kernel: I/O Error Detected. Shutting down filesystem: lvm(58,0) Jun 3 04:24:23 lnxsrv1 kernel: Please umount the filesystem, and rectify the problem(s) Jun 4 04:24:26 lnxsrv1 kernel: xfs_inotobp: xfs_imap() returned an erro= r 22 on lvm(58,0). Returning error. Jun 4 04:24:26 lnxsrv1 kernel: xfs_iunlink_remove: xfs_inotobp() return= ed an error 22 on lvm(58,0). Returning error. Jun 4 04:24:26 lnxsrv1 kernel: xfs_inactive: xfs_ifree() returned an er= ror =3D 22 on lvm(58,0) Jun 4 04:24:26 lnxsrv1 kernel: xfs_force_shutdown(lvm(58,0),0x1) called from line 1946 of file xfs_vnodeops.c. Return address =3D 0xc01f3a79 Jun 4 04:24:26 lnxsrv1 kernel: I/O Error Detected. Shutting down filesystem: lvm(58,0) Jun 4 04:24:26 lnxsrv1 kernel: Please umount the filesystem, and rectify the problem(s) Jun 5 04:34:36 lnxsrv1 kernel: xfs_inotobp: xfs_imap() returned an erro= r 22 on lvm(58,0). Returning error. Jun 5 04:34:36 lnxsrv1 kernel: xfs_iunlink_remove: xfs_inotobp() return= ed an error 22 on lvm(58,0). Returning error. Jun 5 04:34:36 lnxsrv1 kernel: xfs_inactive: xfs_ifree() returned an er= ror =3D 22 on lvm(58,0) Jun 5 04:34:36 lnxsrv1 kernel: xfs_force_shutdown(lvm(58,0),0x1) called from line 1952 of file xfs_vnodeops.c. Return address =3D 0xc01f57f1 Jun 5 04:34:36 lnxsrv1 kernel: I/O Error Detected. Shutting down filesystem: lvm(58,0) Jun 5 04:34:36 lnxsrv1 kernel: Please umount the filesystem, and rectify the problem(s) Jun 6 04:36:15 lnxsrv1 kernel: xfs_inotobp: xfs_imap() returned an erro= r 22 on lvm(58,0). Returning error. Jun 6 04:36:15 lnxsrv1 kernel: xfs_iunlink_remove: xfs_inotobp() return= ed an error 22 on lvm(58,0). Returning error. Jun 6 04:36:15 lnxsrv1 kernel: xfs_inactive: xfs_ifree() returned an er= ror =3D 22 on lvm(58,0) Jun 6 04:36:15 lnxsrv1 kernel: xfs_force_shutdown(lvm(58,0),0x1) called from line 1952 of file xfs_vnodeops.c. Return address =3D 0xc01f57f1 Jun 6 04:36:15 lnxsrv1 kernel: I/O Error Detected. Shutting down filesystem: lvm(58,0) Jun 6 04:36:15 lnxsrv1 kernel: Please umount the filesystem, and rectify the problem(s) ------=_NextPart_000_0123_01C20D75.D7DA7C30 Content-Type: application/octet-stream; name="repair.log" Content-Disposition: attachment; filename="repair.log" Content-Transfer-Encoding: quoted-printable xfs_repair: warning - cannot set blocksize on block device = /dev/lnxsrv100/lvol1: Invalid argument=0A= Phase 1 - find and verify superblock...=0A= Phase 2 - using internal log=0A= - zero log...=0A= - scan filesystem freespace and inode maps...=0A= - found root inode chunk=0A= Phase 3 - for each AG...=0A= - scan and clear agi unlinked lists...=0A= - process known inodes and perform inode discovery...=0A= - agno =3D 0=0A= - agno =3D 1=0A= - agno =3D 2=0A= entry "/." at block 0 offset 264 in directory inode 33928488 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 264...=0A= entry at block 0 offset 264 in directory inode 33928488 has illegal name = "/.": no .. entry for directory 33928488=0A= - agno =3D 3=0A= entry "/." at block 0 offset 416 in directory inode 54008755 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 416...=0A= entry at block 0 offset 416 in directory inode 54008755 has illegal name = "/.": no .. entry for directory 54008755=0A= - agno =3D 4=0A= entry "/." at block 0 offset 984 in directory inode 68390570 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 984...=0A= entry at block 0 offset 984 in directory inode 68390570 has illegal name = "/.": no .. entry for directory 68390570=0A= entry "/." at block 0 offset 360 in directory inode 71078862 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 360...=0A= entry at block 0 offset 360 in directory inode 71078862 has illegal name = "/.": no .. entry for directory 71078862=0A= entry "/." at block 0 offset 840 in directory inode 71554883 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 840...=0A= entry at block 0 offset 840 in directory inode 71554883 has illegal name = "/.": no .. entry for directory 71554883=0A= - agno =3D 5=0A= entry "/." at block 0 offset 384 in directory inode 86464332 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 384...=0A= entry at block 0 offset 384 in directory inode 86464332 has illegal name = "/.": no .. entry for directory 86464332=0A= entry "/." at block 0 offset 552 in directory inode 87339255 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 552...=0A= entry at block 0 offset 552 in directory inode 87339255 has illegal name = "/.": no .. entry for directory 87339255=0A= entry "/." at block 2 offset 1384 in directory inode 89244494 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 1384...=0A= entry at block 2 offset 1384 in directory inode 89244494 has illegal = name "/.": no .. entry for directory 89244494=0A= - agno =3D 6=0A= entry "/." at block 1 offset 3904 in directory inode 103081012 = references invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 3904...=0A= entry at block 1 offset 3904 in directory inode 103081012 has illegal = name "/.": no .. entry for directory 103081012=0A= - agno =3D 7=0A= entry "/." at block 0 offset 312 in directory inode 122345326 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 312...=0A= entry at block 0 offset 312 in directory inode 122345326 has illegal = name "/.": no .. entry for directory 122345326=0A= - agno =3D 8=0A= entry "/." at block 0 offset 272 in directory inode 134718096 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 272...=0A= entry at block 0 offset 272 in directory inode 134718096 has illegal = name "/.": no .. entry for directory 134718096=0A= - agno =3D 9=0A= - agno =3D 10=0A= entry "/." at block 0 offset 1544 in directory inode 168007934 = references invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 1544...=0A= entry at block 0 offset 1544 in directory inode 168007934 has illegal = name "/.": no .. entry for directory 168007934=0A= entry "/." at block 0 offset 264 in directory inode 172422841 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 264...=0A= entry at block 0 offset 264 in directory inode 172422841 has illegal = name "/.": no .. entry for directory 172422841=0A= - agno =3D 11=0A= - agno =3D 12=0A= - agno =3D 13=0A= entry "/." at block 0 offset 384 in directory inode 218268546 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 384...=0A= entry at block 0 offset 384 in directory inode 218268546 has illegal = name "/.": no .. entry for directory 218268546=0A= - agno =3D 14=0A= entry "/." at block 0 offset 392 in directory inode 235151627 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 392...=0A= entry at block 0 offset 392 in directory inode 235151627 has illegal = name "/.": no .. entry for directory 235151627=0A= - agno =3D 15=0A= entry "/." at block 0 offset 352 in directory inode 251909785 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 352...=0A= entry at block 0 offset 352 in directory inode 251909785 has illegal = name "/.": no .. entry for directory 251909785=0A= entry "/." at block 0 offset 392 in directory inode 252083876 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 392...=0A= entry at block 0 offset 392 in directory inode 252083876 has illegal = name "/.": no .. entry for directory 252083876=0A= - agno =3D 16=0A= entry "/." at block 0 offset 1504 in directory inode 273989902 = references invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 1504...=0A= entry at block 0 offset 1504 in directory inode 273989902 has illegal = name "/.": no .. entry for directory 273989902=0A= - agno =3D 17=0A= - agno =3D 18=0A= - agno =3D 19=0A= entry "/." at block 0 offset 312 in directory inode 319042642 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 312...=0A= entry at block 0 offset 312 in directory inode 319042642 has illegal = name "/.": no .. entry for directory 319042642=0A= - agno =3D 20=0A= entry "/." at block 0 offset 496 in directory inode 339752858 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 496...=0A= entry at block 0 offset 496 in directory inode 339752858 has illegal = name "/.": no .. entry for directory 339752858=0A= - agno =3D 21=0A= entry "/." at block 2 offset 2584 in directory inode 355352876 = references invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 2584...=0A= entry at block 2 offset 2584 in directory inode 355352876 has illegal = name "/.": no .. entry for directory 355352876=0A= entry "/." at block 0 offset 840 in directory inode 356434361 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 840...=0A= entry at block 0 offset 840 in directory inode 356434361 has illegal = name "/.": no .. entry for directory 356434361=0A= - agno =3D 22=0A= entry "/." at block 0 offset 912 in directory inode 369168279 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 912...=0A= entry at block 0 offset 912 in directory inode 369168279 has illegal = name "/.": no .. entry for directory 369168279=0A= entry "/." at block 0 offset 776 in directory inode 373793134 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 776...=0A= entry at block 0 offset 776 in directory inode 373793134 has illegal = name "/.": no .. entry for directory 373793134=0A= entry "/." at block 0 offset 536 in directory inode 373796366 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 536...=0A= entry at block 0 offset 536 in directory inode 373796366 has illegal = name "/.": no .. entry for directory 373796366=0A= - agno =3D 23=0A= entry "/." at block 0 offset 544 in directory inode 386816708 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 544...=0A= entry at block 0 offset 544 in directory inode 386816708 has illegal = name "/.": no .. entry for directory 386816708=0A= - agno =3D 24=0A= entry "/." at block 0 offset 344 in directory inode 403461440 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 344...=0A= entry at block 0 offset 344 in directory inode 403461440 has illegal = name "/.": no .. entry for directory 403461440=0A= entry "/." at block 0 offset 512 in directory inode 406493346 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 512...=0A= entry at block 0 offset 512 in directory inode 406493346 has illegal = name "/.": no .. entry for directory 406493346=0A= - agno =3D 25=0A= entry "/." at block 0 offset 368 in directory inode 423423777 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 368...=0A= entry at block 0 offset 368 in directory inode 423423777 has illegal = name "/.": no .. entry for directory 423423777=0A= entry "/." at block 0 offset 464 in directory inode 423823890 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 464...=0A= entry at block 0 offset 464 in directory inode 423823890 has illegal = name "/.": no .. entry for directory 423823890=0A= - agno =3D 26=0A= - agno =3D 27=0A= entry "/." at block 2 offset 1208 in directory inode 453693751 = references invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 1208...=0A= entry at block 2 offset 1208 in directory inode 453693751 has illegal = name "/.": no .. entry for directory 453693751=0A= entry "/." at block 0 offset 2792 in directory inode 455717914 = references invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 2792...=0A= entry at block 0 offset 2792 in directory inode 455717914 has illegal = name "/.": no .. entry for directory 455717914=0A= - agno =3D 28=0A= entry "/." at block 0 offset 296 in directory inode 473012315 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 296...=0A= entry at block 0 offset 296 in directory inode 473012315 has illegal = name "/.": no .. entry for directory 473012315=0A= - agno =3D 29=0A= - agno =3D 30=0A= entry "/." at block 0 offset 384 in directory inode 506147367 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 384...=0A= entry at block 0 offset 384 in directory inode 506147367 has illegal = name "/.": no .. entry for directory 506147367=0A= entry "/." at block 0 offset 416 in directory inode 507365528 references = invalid inode 18374686479671623679=0A= clearing inode number in entry at offset 416...=0A= entry at block 0 offset 416 in directory inode 507365528 has illegal = name "/.": no .. entry for directory 507365528=0A= - process newly discovered inodes...=0A= Phase 4 - check for duplicate blocks...=0A= - setting up duplicate extent list...=0A= - clear lost+found (if it exists) ...=0A= - clearing existing "lost+found" inode=0A= - deleting existing "lost+found" entry=0A= - check for inodes claiming duplicate blocks...=0A= - agno =3D 0=0A= - agno =3D 1=0A= - agno =3D 2=0A= no .. entry for directory 33928488=0A= - agno =3D 3=0A= no .. entry for directory 54008755=0A= - agno =3D 4=0A= no .. entry for directory 68390570=0A= no .. entry for directory 71078862=0A= no .. entry for directory 71554883=0A= - agno =3D 5=0A= no .. entry for directory 86464332=0A= no .. entry for directory 87339255=0A= no .. entry for directory 89244494=0A= - agno =3D 6=0A= no .. entry for directory 103081012=0A= - agno =3D 7=0A= no .. entry for directory 122345326=0A= - agno =3D 8=0A= no .. entry for directory 134718096=0A= - agno =3D 9=0A= - agno =3D 10=0A= no .. entry for directory 168007934=0A= no .. entry for directory 172422841=0A= - agno =3D 11=0A= - agno =3D 12=0A= - agno =3D 13=0A= no .. entry for directory 218268546=0A= - agno =3D 14=0A= no .. entry for directory 235151627=0A= - agno =3D 15=0A= no .. entry for directory 251909785=0A= no .. entry for directory 252083876=0A= - agno =3D 16=0A= no .. entry for directory 273989902=0A= - agno =3D 17=0A= - agno =3D 18=0A= - agno =3D 19=0A= no .. entry for directory 319042642=0A= - agno =3D 20=0A= no .. entry for directory 339752858=0A= - agno =3D 21=0A= no .. entry for directory 355352876=0A= no .. entry for directory 356434361=0A= - agno =3D 22=0A= no .. entry for directory 369168279=0A= no .. entry for directory 373793134=0A= no .. entry for directory 373796366=0A= - agno =3D 23=0A= no .. entry for directory 386816708=0A= - agno =3D 24=0A= no .. entry for directory 403461440=0A= no .. entry for directory 406493346=0A= - agno =3D 25=0A= no .. entry for directory 423423777=0A= no .. entry for directory 423823890=0A= - agno =3D 26=0A= - agno =3D 27=0A= no .. entry for directory 453693751=0A= no .. entry for directory 455717914=0A= - agno =3D 28=0A= no .. entry for directory 473012315=0A= - agno =3D 29=0A= - agno =3D 30=0A= no .. entry for directory 506147367=0A= no .. entry for directory 507365528=0A= Phase 5 - rebuild AG headers and trees...=0A= - reset superblock...=0A= Phase 6 - check inode connectivity...=0A= - resetting contents of realtime bitmap and summary inodes=0A= - ensuring existence of lost+found directory=0A= - traversing filesystem starting at / ... =0A= - traversal finished ... =0A= - traversing all unattached subtrees ... =0A= rebuilding directory inode 33928488=0A= rebuilding directory inode 54008755=0A= rebuilding directory inode 68390570=0A= rebuilding directory inode 71078862=0A= rebuilding directory inode 71554883=0A= rebuilding directory inode 86464332=0A= rebuilding directory inode 87339255=0A= rebuilding directory inode 89244494=0A= rebuilding directory inode 103081012=0A= rebuilding directory inode 122345326=0A= rebuilding directory inode 134718096=0A= rebuilding directory inode 168007934=0A= rebuilding directory inode 172422841=0A= rebuilding directory inode 218268546=0A= rebuilding directory inode 235151627=0A= rebuilding directory inode 251909785=0A= rebuilding directory inode 252083876=0A= rebuilding directory inode 273989902=0A= rebuilding directory inode 319042642=0A= rebuilding directory inode 339752858=0A= rebuilding directory inode 355352876=0A= rebuilding directory inode 356434361=0A= rebuilding directory inode 369168279=0A= rebuilding directory inode 373793134=0A= rebuilding directory inode 373796366=0A= rebuilding directory inode 386816708=0A= rebuilding directory inode 403461440=0A= rebuilding directory inode 406493346=0A= rebuilding directory inode 423423777=0A= rebuilding directory inode 423823890=0A= rebuilding directory inode 453693751=0A= rebuilding directory inode 455717914=0A= rebuilding directory inode 473012315=0A= rebuilding directory inode 506147367=0A= rebuilding directory inode 507365528=0A= - traversals finished ... =0A= - moving disconnected inodes to lost+found ... =0A= disconnected inode 3041, moving to lost+found=0A= disconnected dir inode 3056, moving to lost+found=0A= disconnected inode 4169, moving to lost+found=0A= disconnected inode 4171, moving to lost+found=0A= disconnected dir inode 34771, moving to lost+found=0A= disconnected inode 52755, moving to lost+found=0A= disconnected inode 57518, moving to lost+found=0A= disconnected inode 293983, moving to lost+found=0A= disconnected inode 294427, moving to lost+found=0A= disconnected inode 385548, moving to lost+found=0A= disconnected inode 420128, moving to lost+found=0A= disconnected inode 420130, moving to lost+found=0A= disconnected inode 420131, moving to lost+found=0A= disconnected inode 420132, moving to lost+found=0A= disconnected inode 420151, moving to lost+found=0A= disconnected dir inode 1001849, moving to lost+found=0A= disconnected inode 1393243, moving to lost+found=0A= disconnected inode 1393244, moving to lost+found=0A= disconnected inode 1393245, moving to lost+found=0A= disconnected inode 1393246, moving to lost+found=0A= disconnected inode 1393247, moving to lost+found=0A= disconnected dir inode 1583912, moving to lost+found=0A= disconnected dir inode 2462030, moving to lost+found=0A= disconnected dir inode 16801647, moving to lost+found=0A= disconnected inode 16846538, moving to lost+found=0A= disconnected dir inode 16848435, moving to lost+found=0A= disconnected inode 16990831, moving to lost+found=0A= disconnected inode 17192014, moving to lost+found=0A= disconnected inode 17199088, moving to lost+found=0A= disconnected inode 17388224, moving to lost+found=0A= disconnected inode 17388225, moving to lost+found=0A= disconnected inode 17388226, moving to lost+found=0A= disconnected inode 17388227, moving to lost+found=0A= disconnected inode 17388229, moving to lost+found=0A= disconnected inode 17388230, moving to lost+found=0A= disconnected inode 17388231, moving to lost+found=0A= disconnected inode 17388232, moving to lost+found=0A= disconnected inode 17388233, moving to lost+found=0A= disconnected inode 17388234, moving to lost+found=0A= disconnected inode 17388235, moving to lost+found=0A= disconnected inode 17388236, moving to lost+found=0A= disconnected inode 17388237, moving to lost+found=0A= disconnected inode 17388238, moving to lost+found=0A= disconnected inode 17388239, moving to lost+found=0A= disconnected inode 17388240, moving to lost+found=0A= disconnected inode 17388241, moving to lost+found=0A= disconnected inode 17388242, moving to lost+found=0A= disconnected inode 17388243, moving to lost+found=0A= disconnected inode 17388244, moving to lost+found=0A= disconnected inode 17388245, moving to lost+found=0A= disconnected inode 17388246, moving to lost+found=0A= disconnected inode 17388247, moving to lost+found=0A= disconnected inode 17388248, moving to lost+found=0A= disconnected inode 17388249, moving to lost+found=0A= disconnected inode 17388250, moving to lost+found=0A= disconnected inode 17388251, moving to lost+found=0A= disconnected inode 17388252, moving to lost+found=0A= disconnected inode 17388253, moving to lost+found=0A= disconnected inode 17388254, moving to lost+found=0A= disconnected inode 17388255, moving to lost+found=0A= disconnected inode 17388256, moving to lost+found=0A= disconnected inode 17388257, moving to lost+found=0A= disconnected inode 17388258, moving to lost+found=0A= disconnected inode 17388260, moving to lost+found=0A= disconnected inode 17388261, moving to lost+found=0A= disconnected inode 17388262, moving to lost+found=0A= disconnected inode 17388263, moving to lost+found=0A= disconnected inode 17388264, moving to lost+found=0A= disconnected inode 17388265, moving to lost+found=0A= disconnected inode 17388266, moving to lost+found=0A= disconnected inode 17388267, moving to lost+found=0A= disconnected inode 17388268, moving to lost+found=0A= disconnected inode 17388269, moving to lost+found=0A= disconnected inode 17388270, moving to lost+found=0A= disconnected inode 17388271, moving to lost+found=0A= disconnected inode 17388272, moving to lost+found=0A= disconnected inode 17388273, moving to lost+found=0A= disconnected inode 17388274, moving to lost+found=0A= disconnected inode 17388275, moving to lost+found=0A= disconnected inode 17388276, moving to lost+found=0A= disconnected inode 17388277, moving to lost+found=0A= disconnected inode 17388278, moving to lost+found=0A= disconnected inode 17388279, moving to lost+found=0A= disconnected inode 17388280, moving to lost+found=0A= disconnected inode 17388281, moving to lost+found=0A= disconnected inode 17388282, moving to lost+found=0A= disconnected inode 17388283, moving to lost+found=0A= disconnected inode 17388284, moving to lost+found=0A= disconnected inode 17388285, moving to lost+found=0A= disconnected inode 17388286, moving to lost+found=0A= disconnected inode 17388287, moving to lost+found=0A= disconnected inode 17388448, moving to lost+found=0A= disconnected inode 17388449, moving to lost+found=0A= disconnected inode 17388450, moving to lost+found=0A= disconnected inode 17388451, moving to lost+found=0A= disconnected inode 17388452, moving to lost+found=0A= disconnected inode 17388453, moving to lost+found=0A= disconnected inode 17388454, moving to lost+found=0A= disconnected inode 17388455, moving to lost+found=0A= disconnected inode 17388456, moving to lost+found=0A= disconnected inode 17388457, moving to lost+found=0A= disconnected inode 17388458, moving to lost+found=0A= disconnected inode 17388459, moving to lost+found=0A= disconnected inode 17388460, moving to lost+found=0A= disconnected inode 17388461, moving to lost+found=0A= disconnected inode 17388463, moving to lost+found=0A= disconnected inode 17400184, moving to lost+found=0A= disconnected inode 17547374, moving to lost+found=0A= disconnected inode 17547375, moving to lost+found=0A= disconnected inode 17547385, moving to lost+found=0A= disconnected inode 17547650, moving to lost+found=0A= disconnected inode 17547656, moving to lost+found=0A= disconnected inode 17554274, moving to lost+found=0A= disconnected inode 17554275, moving to lost+found=0A= disconnected inode 17557932, moving to lost+found=0A= disconnected inode 17653874, moving to lost+found=0A= disconnected inode 17706113, moving to lost+found=0A= disconnected inode 17729717, moving to lost+found=0A= disconnected inode 17769801, moving to lost+found=0A= disconnected inode 17769803, moving to lost+found=0A= disconnected inode 17769804, moving to lost+found=0A= disconnected inode 17769805, moving to lost+found=0A= disconnected inode 17769806, moving to lost+found=0A= disconnected inode 17769807, moving to lost+found=0A= disconnected inode 17769808, moving to lost+found=0A= disconnected inode 17769809, moving to lost+found=0A= disconnected inode 17769810, moving to lost+found=0A= disconnected inode 17769811, moving to lost+found=0A= disconnected inode 17769812, moving to lost+found=0A= disconnected inode 17769813, moving to lost+found=0A= disconnected inode 17769815, moving to lost+found=0A= disconnected inode 17769816, moving to lost+found=0A= disconnected inode 17769818, moving to lost+found=0A= disconnected inode 17777728, moving to lost+found=0A= disconnected inode 17777732, moving to lost+found=0A= disconnected inode 17777737, moving to lost+found=0A= disconnected inode 17777738, moving to lost+found=0A= disconnected inode 17777755, moving to lost+found=0A= disconnected inode 17777759, moving to lost+found=0A= disconnected inode 17777761, moving to lost+found=0A= disconnected inode 17777762, moving to lost+found=0A= disconnected inode 17777782, moving to lost+found=0A= disconnected inode 18138093, moving to lost+found=0A= disconnected inode 18138094, moving to lost+found=0A= disconnected inode 18138095, moving to lost+found=0A= disconnected inode 18138096, moving to lost+found=0A= disconnected inode 18138097, moving to lost+found=0A= disconnected inode 18138098, moving to lost+found=0A= disconnected inode 18201839, moving to lost+found=0A= disconnected inode 18288453, moving to lost+found=0A= disconnected inode 18452571, moving to lost+found=0A= disconnected inode 18488111, moving to lost+found=0A= disconnected dir inode 19310090, moving to lost+found=0A= disconnected dir inode 19844237, moving to lost+found=0A= disconnected inode 21495380, moving to lost+found=0A= disconnected inode 21496381, moving to lost+found=0A= disconnected dir inode 21515383, moving to lost+found=0A= disconnected dir inode 33620334, moving to lost+found=0A= disconnected dir inode 33624801, moving to lost+found=0A= disconnected inode 33829198, moving to lost+found=0A= disconnected inode 33829199, moving to lost+found=0A= disconnected inode 33829200, moving to lost+found=0A= disconnected inode 33829201, moving to lost+found=0A= disconnected inode 33902018, moving to lost+found=0A= disconnected inode 33902019, moving to lost+found=0A= disconnected dir inode 33928486, moving to lost+found=0A= disconnected dir inode 33928488, moving to lost+found=0A= disconnected inode 33964298, moving to lost+found=0A= disconnected inode 34106174, moving to lost+found=0A= disconnected inode 34117027, moving to lost+found=0A= disconnected inode 34585277, moving to lost+found=0A= disconnected inode 34892883, moving to lost+found=0A= disconnected inode 35078125, moving to lost+found=0A= disconnected inode 35079325, moving to lost+found=0A= disconnected dir inode 35364398, moving to lost+found=0A= disconnected inode 35438221, moving to lost+found=0A= disconnected inode 36425312, moving to lost+found=0A= disconnected inode 36425314, moving to lost+found=0A= disconnected inode 36425326, moving to lost+found=0A= disconnected inode 36425355, moving to lost+found=0A= disconnected inode 36771982, moving to lost+found=0A= disconnected inode 36777457, moving to lost+found=0A= disconnected inode 36777458, moving to lost+found=0A= disconnected inode 36777461, moving to lost+found=0A= disconnected dir inode 36975369, moving to lost+found=0A= disconnected inode 38088902, moving to lost+found=0A= disconnected dir inode 38193657, moving to lost+found=0A= disconnected inode 38282439, moving to lost+found=0A= disconnected inode 38562704, moving to lost+found=0A= disconnected inode 38562717, moving to lost+found=0A= disconnected inode 38562718, moving to lost+found=0A= disconnected inode 38562720, moving to lost+found=0A= disconnected inode 38562721, moving to lost+found=0A= disconnected inode 38562722, moving to lost+found=0A= disconnected inode 38562723, moving to lost+found=0A= disconnected inode 38562724, moving to lost+found=0A= disconnected inode 38562725, moving to lost+found=0A= disconnected inode 38562726, moving to lost+found=0A= disconnected inode 38562727, moving to lost+found=0A= disconnected inode 38562728, moving to lost+found=0A= disconnected inode 38562732, moving to lost+found=0A= disconnected inode 38562733, moving to lost+found=0A= disconnected inode 38562734, moving to lost+found=0A= disconnected inode 38562735, moving to lost+found=0A= disconnected inode 38562736, moving to lost+found=0A= disconnected inode 38562737, moving to lost+found=0A= disconnected inode 38562739, moving to lost+found=0A= disconnected inode 38562740, moving to lost+found=0A= disconnected inode 38562741, moving to lost+found=0A= disconnected inode 38562742, moving to lost+found=0A= disconnected inode 38562743, moving to lost+found=0A= disconnected inode 38562744, moving to lost+found=0A= disconnected inode 38562745, moving to lost+found=0A= disconnected inode 38562746, moving to lost+found=0A= disconnected inode 38562747, moving to lost+found=0A= disconnected inode 38562748, moving to lost+found=0A= disconnected inode 38562750, moving to lost+found=0A= disconnected inode 38562751, moving to lost+found=0A= disconnected inode 38565700, moving to lost+found=0A= disconnected inode 38565701, moving to lost+found=0A= disconnected inode 38565702, moving to lost+found=0A= disconnected inode 38565705, moving to lost+found=0A= disconnected inode 38565707, moving to lost+found=0A= disconnected inode 38565710, moving to lost+found=0A= disconnected inode 38565714, moving to lost+found=0A= disconnected inode 38565721, moving to lost+found=0A= disconnected inode 38565725, moving to lost+found=0A= disconnected inode 38565730, moving to lost+found=0A= disconnected inode 38565731, moving to lost+found=0A= disconnected inode 38565732, moving to lost+found=0A= disconnected inode 38565733, moving to lost+found=0A= disconnected inode 38565734, moving to lost+found=0A= disconnected inode 38565735, moving to lost+found=0A= disconnected inode 38565738, moving to lost+found=0A= disconnected inode 38565739, moving to lost+found=0A= disconnected inode 38565740, moving to lost+found=0A= disconnected inode 38565741, moving to lost+found=0A= disconnected inode 38565742, moving to lost+found=0A= disconnected inode 38565743, moving to lost+found=0A= disconnected inode 38565744, moving to lost+found=0A= disconnected inode 38565745, moving to lost+found=0A= disconnected inode 38565746, moving to lost+found=0A= disconnected inode 38565747, moving to lost+found=0A= disconnected inode 38565748, moving to lost+found=0A= disconnected inode 38565749, moving to lost+found=0A= disconnected inode 38565750, moving to lost+found=0A= disconnected inode 38565751, moving to lost+found=0A= disconnected inode 38565755, moving to lost+found=0A= disconnected inode 38565756, moving to lost+found=0A= disconnected inode 38565759, moving to lost+found=0A= disconnected inode 38565856, moving to lost+found=0A= disconnected inode 38565858, moving to lost+found=0A= disconnected inode 38565859, moving to lost+found=0A= disconnected inode 38565862, moving to lost+found=0A= disconnected inode 38565865, moving to lost+found=0A= disconnected inode 38565866, moving to lost+found=0A= disconnected inode 38565867, moving to lost+found=0A= disconnected inode 38565868, moving to lost+found=0A= disconnected inode 38565869, moving to lost+found=0A= disconnected inode 38565872, moving to lost+found=0A= disconnected inode 38565873, moving to lost+found=0A= disconnected inode 38565876, moving to lost+found=0A= disconnected inode 38565877, moving to lost+found=0A= disconnected inode 38565878, moving to lost+found=0A= disconnected inode 38565879, moving to lost+found=0A= disconnected inode 38565881, moving to lost+found=0A= disconnected inode 38565882, moving to lost+found=0A= disconnected inode 38565883, moving to lost+found=0A= disconnected inode 38565884, moving to lost+found=0A= disconnected inode 38565885, moving to lost+found=0A= disconnected inode 38565886, moving to lost+found=0A= disconnected inode 38565887, moving to lost+found=0A= disconnected inode 38565888, moving to lost+found=0A= disconnected inode 38565889, moving to lost+found=0A= disconnected inode 38565890, moving to lost+found=0A= disconnected inode 38565891, moving to lost+found=0A= disconnected inode 38565894, moving to lost+found=0A= disconnected inode 38565895, moving to lost+found=0A= disconnected inode 38565898, moving to lost+found=0A= disconnected inode 38565899, moving to lost+found=0A= disconnected inode 38565900, moving to lost+found=0A= disconnected inode 50384197, moving to lost+found=0A= disconnected dir inode 50386834, moving to lost+found=0A= disconnected dir inode 50473673, moving to lost+found=0A= disconnected inode 50761484, moving to lost+found=0A= disconnected inode 50761485, moving to lost+found=0A= disconnected inode 50854667, moving to lost+found=0A= disconnected inode 50886620, moving to lost+found=0A= disconnected inode 50886621, moving to lost+found=0A= disconnected inode 50886622, moving to lost+found=0A= disconnected inode 50918209, moving to lost+found=0A= disconnected inode 50918223, moving to lost+found=0A= disconnected inode 50918227, moving to lost+found=0A= disconnected inode 50923493, moving to lost+found=0A= disconnected inode 50923495, moving to lost+found=0A= disconnected inode 50923496, moving to lost+found=0A= disconnected inode 50923503, moving to lost+found=0A= disconnected inode 51002293, moving to lost+found=0A= disconnected inode 51002294, moving to lost+found=0A= disconnected inode 51379108, moving to lost+found=0A= disconnected dir inode 51586179, moving to lost+found=0A= disconnected inode 51597589, moving to lost+found=0A= disconnected inode 51597711, moving to lost+found=0A= disconnected inode 51597712, moving to lost+found=0A= disconnected dir inode 51597713, moving to lost+found=0A= disconnected inode 51947358, moving to lost+found=0A= disconnected inode 51947359, moving to lost+found=0A= disconnected inode 51947382, moving to lost+found=0A= disconnected inode 51947383, moving to lost+found=0A= disconnected inode 51948884, moving to lost+found=0A= disconnected inode 51948885, moving to lost+found=0A= disconnected inode 51948886, moving to lost+found=0A= disconnected inode 51948887, moving to lost+found=0A= disconnected inode 51948888, moving to lost+found=0A= disconnected inode 51948889, moving to lost+found=0A= disconnected inode 51948890, moving to lost+found=0A= disconnected inode 51948891, moving to lost+found=0A= disconnected inode 51948892, moving to lost+found=0A= disconnected inode 51948893, moving to lost+found=0A= disconnected inode 51948894, moving to lost+found=0A= disconnected inode 51948895, moving to lost+found=0A= disconnected inode 51948896, moving to lost+found=0A= disconnected inode 51948897, moving to lost+found=0A= disconnected inode 51948898, moving to lost+found=0A= disconnected inode 51948899, moving to lost+found=0A= disconnected inode 51948900, moving to lost+found=0A= disconnected inode 51948901, moving to lost+found=0A= disconnected inode 51948902, moving to lost+found=0A= disconnected inode 51948903, moving to lost+found=0A= disconnected inode 51948904, moving to lost+found=0A= disconnected inode 51948905, moving to lost+found=0A= disconnected inode 51948906, moving to lost+found=0A= disconnected inode 51948907, moving to lost+found=0A= disconnected inode 51948908, moving to lost+found=0A= disconnected inode 51948909, moving to lost+found=0A= disconnected inode 51948910, moving to lost+found=0A= disconnected inode 51948911, moving to lost+found=0A= disconnected inode 51948912, moving to lost+found=0A= disconnected inode 51948913, moving to lost+found=0A= disconnected inode 51948914, moving to lost+found=0A= disconnected inode 51948915, moving to lost+found=0A= disconnected inode 51948916, moving to lost+found=0A= disconnected inode 51948917, moving to lost+found=0A= disconnected inode 51948918, moving to lost+found=0A= disconnected inode 51948919, moving to lost+found=0A= disconnected inode 51948920, moving to lost+found=0A= disconnected inode 51948921, moving to lost+found=0A= disconnected inode 51948922, moving to lost+found=0A= disconnected inode 51948923, moving to lost+found=0A= disconnected inode 51948924, moving to lost+found=0A= disconnected inode 51948925, moving to lost+found=0A= disconnected inode 51948926, moving to lost+found=0A= disconnected inode 51948927, moving to lost+found=0A= disconnected inode 51949952, moving to lost+found=0A= disconnected inode 51949953, moving to lost+found=0A= disconnected inode 51949954, moving to lost+found=0A= disconnected inode 51949958, moving to lost+found=0A= disconnected inode 51949959, moving to lost+found=0A= disconnected inode 51995808, moving to lost+found=0A= disconnected inode 51995814, moving to lost+found=0A= disconnected inode 51995844, moving to lost+found=0A= disconnected inode 51995852, moving to lost+found=0A= disconnected inode 51998358, moving to lost+found=0A= disconnected inode 51998359, moving to lost+found=0A= disconnected inode 51998362, moving to lost+found=0A= disconnected inode 51998364, moving to lost+found=0A= disconnected inode 51998366, moving to lost+found=0A= disconnected inode 51998622, moving to lost+found=0A= disconnected inode 51998627, moving to lost+found=0A= disconnected inode 52000512, moving to lost+found=0A= disconnected inode 52000513, moving to lost+found=0A= disconnected inode 52000515, moving to lost+found=0A= disconnected inode 52000520, moving to lost+found=0A= disconnected inode 52000521, moving to lost+found=0A= disconnected inode 52000524, moving to lost+found=0A= disconnected inode 52000526, moving to lost+found=0A= disconnected inode 52002190, moving to lost+found=0A= disconnected inode 52002207, moving to lost+found=0A= disconnected inode 52010188, moving to lost+found=0A= disconnected inode 52010199, moving to lost+found=0A= disconnected inode 52082921, moving to lost+found=0A= disconnected inode 52148178, moving to lost+found=0A= disconnected inode 52148185, moving to lost+found=0A= disconnected inode 52220750, moving to lost+found=0A= disconnected inode 52222852, moving to lost+found=0A= disconnected inode 52781676, moving to lost+found=0A= disconnected dir inode 52790118, moving to lost+found=0A= disconnected inode 52860580, moving to lost+found=0A= disconnected inode 52860611, moving to lost+found=0A= disconnected inode 52860949, moving to lost+found=0A= disconnected inode 53098271, moving to lost+found=0A= disconnected inode 53366748, moving to lost+found=0A= disconnected inode 53366769, moving to lost+found=0A= disconnected dir inode 53373001, moving to lost+found=0A= disconnected dir inode 53442760, moving to lost+found=0A= disconnected dir inode 53442764, moving to lost+found=0A= disconnected inode 53448646, moving to lost+found=0A= disconnected inode 53756568, moving to lost+found=0A= disconnected inode 53764769, moving to lost+found=0A= disconnected dir inode 53929697, moving to lost+found=0A= disconnected dir inode 54008755, moving to lost+found=0A= disconnected dir inode 55001749, moving to lost+found=0A= disconnected dir inode 55001751, moving to lost+found=0A= disconnected dir inode 55595351, moving to lost+found=0A= disconnected dir inode 55595359, moving to lost+found=0A= disconnected inode 67108951, moving to lost+found=0A= disconnected inode 67108952, moving to lost+found=0A= disconnected dir inode 67113206, moving to lost+found=0A= disconnected inode 67151094, moving to lost+found=0A= disconnected dir inode 67151211, moving to lost+found=0A= disconnected dir inode 67199173, moving to lost+found=0A= disconnected inode 67772950, moving to lost+found=0A= disconnected dir inode 67861696, moving to lost+found=0A= disconnected inode 68016928, moving to lost+found=0A= disconnected inode 68016930, moving to lost+found=0A= disconnected inode 68016931, moving to lost+found=0A= disconnected inode 68133972, moving to lost+found=0A= disconnected inode 68133973, moving to lost+found=0A= disconnected inode 68133974, moving to lost+found=0A= disconnected inode 68133975, moving to lost+found=0A= disconnected inode 68205720, moving to lost+found=0A= disconnected inode 68205738, moving to lost+found=0A= disconnected inode 68205743, moving to lost+found=0A= disconnected inode 68236665, moving to lost+found=0A= disconnected dir inode 68390570, moving to lost+found=0A= disconnected inode 68394342, moving to lost+found=0A= disconnected inode 68394367, moving to lost+found=0A= disconnected inode 68394368, moving to lost+found=0A= disconnected inode 68394369, moving to lost+found=0A= disconnected inode 68394374, moving to lost+found=0A= disconnected inode 68395570, moving to lost+found=0A= disconnected inode 68500019, moving to lost+found=0A= disconnected inode 68719685, moving to lost+found=0A= disconnected inode 68822663, moving to lost+found=0A= disconnected inode 68867531, moving to lost+found=0A= disconnected inode 68867581, moving to lost+found=0A= disconnected inode 68976311, moving to lost+found=0A= disconnected inode 69030740, moving to lost+found=0A= disconnected inode 69051806, moving to lost+found=0A= disconnected inode 69126978, moving to lost+found=0A= disconnected inode 69126979, moving to lost+found=0A= disconnected inode 69126980, moving to lost+found=0A= disconnected inode 69126986, moving to lost+found=0A= disconnected inode 69129056, moving to lost+found=0A= disconnected inode 69129057, moving to lost+found=0A= disconnected inode 69129058, moving to lost+found=0A= disconnected inode 69129059, moving to lost+found=0A= disconnected inode 69129060, moving to lost+found=0A= disconnected inode 69129061, moving to lost+found=0A= disconnected inode 69129062, moving to lost+found=0A= disconnected inode 69129063, moving to lost+found=0A= disconnected inode 69129064, moving to lost+found=0A= disconnected inode 69129065, moving to lost+found=0A= disconnected inode 69129066, moving to lost+found=0A= disconnected inode 69129067, moving to lost+found=0A= disconnected inode 69483791, moving to lost+found=0A= disconnected inode 69520409, moving to lost+found=0A= disconnected dir inode 70074407, moving to lost+found=0A= disconnected dir inode 70074410, moving to lost+found=0A= disconnected dir inode 71078862, moving to lost+found=0A= disconnected dir inode 71554883, moving to lost+found=0A= disconnected dir inode 71554886, moving to lost+found=0A= disconnected dir inode 83892017, moving to lost+found=0A= disconnected dir inode 83899612, moving to lost+found=0A= disconnected inode 83899818, moving to lost+found=0A= disconnected inode 83899819, moving to lost+found=0A= disconnected inode 83899821, moving to lost+found=0A= disconnected inode 83899822, moving to lost+found=0A= disconnected inode 83899823, moving to lost+found=0A= disconnected inode 83899841, moving to lost+found=0A= disconnected inode 83899842, moving to lost+found=0A= disconnected inode 83899843, moving to lost+found=0A= disconnected inode 83899844, moving to lost+found=0A= disconnected inode 84130879, moving to lost+found=0A= disconnected inode 84130880, moving to lost+found=0A= disconnected inode 84130881, moving to lost+found=0A= disconnected inode 84130882, moving to lost+found=0A= disconnected inode 84130883, moving to lost+found=0A= disconnected inode 84130884, moving to lost+found=0A= disconnected dir inode 84273095, moving to lost+found=0A= disconnected inode 85181265, moving to lost+found=0A= disconnected dir inode 86464332, moving to lost+found=0A= disconnected dir inode 86464343, moving to lost+found=0A= disconnected dir inode 87339255, moving to lost+found=0A= disconnected dir inode 87362713, moving to lost+found=0A= disconnected dir inode 87412164, moving to lost+found=0A= disconnected dir inode 87412166, moving to lost+found=0A= disconnected dir inode 87412182, moving to lost+found=0A= disconnected dir inode 89244494, moving to lost+found=0A= disconnected dir inode 100664972, moving to lost+found=0A= disconnected dir inode 100855571, moving to lost+found=0A= disconnected inode 100856719, moving to lost+found=0A= disconnected inode 101558947, moving to lost+found=0A= disconnected inode 101743036, moving to lost+found=0A= disconnected inode 101823876, moving to lost+found=0A= disconnected inode 101823880, moving to lost+found=0A= disconnected inode 101823881, moving to lost+found=0A= disconnected inode 101823882, moving to lost+found=0A= disconnected inode 101829300, moving to lost+found=0A= disconnected inode 101829301, moving to lost+found=0A= disconnected inode 101829302, moving to lost+found=0A= disconnected inode 101829303, moving to lost+found=0A= disconnected inode 101829304, moving to lost+found=0A= disconnected inode 101829305, moving to lost+found=0A= disconnected inode 101829306, moving to lost+found=0A= disconnected inode 101829307, moving to lost+found=0A= disconnected inode 101829309, moving to lost+found=0A= disconnected inode 101829311, moving to lost+found=0A= disconnected dir inode 101874035, moving to lost+found=0A= disconnected inode 101881728, moving to lost+found=0A= disconnected inode 102013113, moving to lost+found=0A= disconnected dir inode 102271260, moving to lost+found=0A= disconnected inode 102381819, moving to lost+found=0A= disconnected inode 102574290, moving to lost+found=0A= disconnected inode 102623395, moving to lost+found=0A= disconnected inode 102623396, moving to lost+found=0A= disconnected inode 102751969, moving to lost+found=0A= disconnected inode 102751994, moving to lost+found=0A= disconnected inode 102935533, moving to lost+found=0A= disconnected dir inode 103081012, moving to lost+found=0A= disconnected dir inode 103099904, moving to lost+found=0A= disconnected inode 103321713, moving to lost+found=0A= disconnected inode 103321714, moving to lost+found=0A= disconnected inode 103321715, moving to lost+found=0A= disconnected inode 103321716, moving to lost+found=0A= disconnected inode 103321717, moving to lost+found=0A= disconnected inode 103321718, moving to lost+found=0A= disconnected inode 103321720, moving to lost+found=0A= disconnected inode 103321724, moving to lost+found=0A= disconnected inode 103321725, moving to lost+found=0A= disconnected inode 103321726, moving to lost+found=0A= disconnected inode 103321727, moving to lost+found=0A= disconnected dir inode 117450615, moving to lost+found=0A= disconnected dir inode 117521113, moving to lost+found=0A= disconnected dir inode 117812256, moving to lost+found=0A= disconnected dir inode 118034415, moving to lost+found=0A= disconnected dir inode 118299448, moving to lost+found=0A= disconnected inode 118450311, moving to lost+found=0A= disconnected inode 118450320, moving to lost+found=0A= disconnected inode 118450321, moving to lost+found=0A= disconnected inode 118450322, moving to lost+found=0A= disconnected inode 118450323, moving to lost+found=0A= disconnected inode 118450324, moving to lost+found=0A= disconnected dir inode 118450326, moving to lost+found=0A= disconnected dir inode 118455036, moving to lost+found=0A= disconnected inode 118516466, moving to lost+found=0A= disconnected inode 118516470, moving to lost+found=0A= disconnected inode 118524146, moving to lost+found=0A= disconnected inode 118785222, moving to lost+found=0A= disconnected inode 118785225, moving to lost+found=0A= disconnected dir inode 118795268, moving to lost+found=0A= disconnected inode 119098831, moving to lost+found=0A= disconnected inode 119689022, moving to lost+found=0A= disconnected inode 119695182, moving to lost+found=0A= disconnected dir inode 119793240, moving to lost+found=0A= disconnected dir inode 119799296, moving to lost+found=0A= disconnected dir inode 119799314, moving to lost+found=0A= disconnected dir inode 120468438, moving to lost+found=0A= disconnected dir inode 120656313, moving to lost+found=0A= disconnected dir inode 122345326, moving to lost+found=0A= disconnected dir inode 134393023, moving to lost+found=0A= disconnected dir inode 134398975, moving to lost+found=0A= disconnected dir inode 134641087, moving to lost+found=0A= disconnected inode 134642389, moving to lost+found=0A= disconnected dir inode 134718096, moving to lost+found=0A= disconnected inode 135044976, moving to lost+found=0A= disconnected dir inode 135186678, moving to lost+found=0A= disconnected inode 135493847, moving to lost+found=0A= disconnected inode 135659959, moving to lost+found=0A= disconnected inode 135661195, moving to lost+found=0A= disconnected inode 135661206, moving to lost+found=0A= disconnected inode 135668721, moving to lost+found=0A= disconnected inode 135674083, moving to lost+found=0A= disconnected inode 135674084, moving to lost+found=0A= disconnected inode 135674086, moving to lost+found=0A= disconnected inode 135674087, moving to lost+found=0A= disconnected inode 135674088, moving to lost+found=0A= disconnected inode 135674089, moving to lost+found=0A= disconnected inode 135674090, moving to lost+found=0A= disconnected dir inode 135940990, moving to lost+found=0A= disconnected dir inode 136873942, moving to lost+found=0A= disconnected dir inode 137256773, moving to lost+found=0A= disconnected inode 137489693, moving to lost+found=0A= disconnected inode 137489694, moving to lost+found=0A= disconnected inode 137489695, moving to lost+found=0A= disconnected inode 137489696, moving to lost+found=0A= disconnected dir inode 137903216, moving to lost+found=0A= disconnected inode 137904211, moving to lost+found=0A= disconnected inode 137904212, moving to lost+found=0A= disconnected inode 137904213, moving to lost+found=0A= disconnected inode 137904214, moving to lost+found=0A= disconnected inode 137904215, moving to lost+found=0A= disconnected inode 137904216, moving to lost+found=0A= disconnected inode 137904217, moving to lost+found=0A= disconnected inode 137904218, moving to lost+found=0A= disconnected inode 137904219, moving to lost+found=0A= disconnected inode 137904220, moving to lost+found=0A= disconnected inode 137904221, moving to lost+found=0A= disconnected inode 137904222, moving to lost+found=0A= disconnected inode 137904223, moving to lost+found=0A= disconnected inode 137904224, moving to lost+found=0A= disconnected inode 137904225, moving to lost+found=0A= disconnected inode 137904226, moving to lost+found=0A= disconnected inode 137904227, moving to lost+found=0A= disconnected inode 137904228, moving to lost+found=0A= disconnected inode 137904229, moving to lost+found=0A= disconnected inode 137904230, moving to lost+found=0A= disconnected inode 137904231, moving to lost+found=0A= disconnected inode 137904232, moving to lost+found=0A= disconnected inode 137904233, moving to lost+found=0A= disconnected inode 137904234, moving to lost+found=0A= disconnected inode 137904235, moving to lost+found=0A= disconnected inode 137904236, moving to lost+found=0A= disconnected inode 137904237, moving to lost+found=0A= disconnected inode 137904239, moving to lost+found=0A= disconnected inode 137904240, moving to lost+found=0A= disconnected inode 137904241, moving to lost+found=0A= disconnected inode 137904242, moving to lost+found=0A= disconnected inode 137904243, moving to lost+found=0A= disconnected inode 137904244, moving to lost+found=0A= disconnected inode 137904245, moving to lost+found=0A= disconnected inode 137904246, moving to lost+found=0A= disconnected inode 137904247, moving to lost+found=0A= disconnected inode 137904248, moving to lost+found=0A= disconnected inode 137904249, moving to lost+found=0A= disconnected inode 137904250, moving to lost+found=0A= disconnected inode 137904251, moving to lost+found=0A= disconnected inode 137904252, moving to lost+found=0A= disconnected inode 137904253, moving to lost+found=0A= disconnected inode 137904254, moving to lost+found=0A= disconnected inode 137904255, moving to lost+found=0A= disconnected inode 137906048, moving to lost+found=0A= disconnected inode 137906049, moving to lost+found=0A= disconnected inode 137906050, moving to lost+found=0A= disconnected inode 137906051, moving to lost+found=0A= disconnected inode 137906052, moving to lost+found=0A= disconnected inode 137906053, moving to lost+found=0A= disconnected inode 137906054, moving to lost+found=0A= disconnected inode 137906055, moving to lost+found=0A= disconnected inode 137906056, moving to lost+found=0A= disconnected inode 137906057, moving to lost+found=0A= disconnected inode 137906058, moving to lost+found=0A= disconnected inode 137906059, moving to lost+found=0A= disconnected dir inode 137906060, moving to lost+found=0A= disconnected dir inode 137906061, moving to lost+found=0A= disconnected dir inode 138886481, moving to lost+found=0A= disconnected inode 139127970, moving to lost+found=0A= disconnected dir inode 151045895, moving to lost+found=0A= disconnected dir inode 151048877, moving to lost+found=0A= disconnected inode 151062929, moving to lost+found=0A= disconnected inode 151064299, moving to lost+found=0A= disconnected dir inode 151246996, moving to lost+found=0A= disconnected inode 151247001, moving to lost+found=0A= disconnected inode 151248306, moving to lost+found=0A= disconnected inode 151248316, moving to lost+found=0A= disconnected inode 151248317, moving to lost+found=0A= disconnected inode 151248330, moving to lost+found=0A= disconnected dir inode 152503367, moving to lost+found=0A= disconnected inode 155227489, moving to lost+found=0A= disconnected inode 155227490, moving to lost+found=0A= disconnected inode 155227492, moving to lost+found=0A= disconnected inode 155227494, moving to lost+found=0A= disconnected inode 155227496, moving to lost+found=0A= disconnected inode 155227498, moving to lost+found=0A= disconnected inode 155227499, moving to lost+found=0A= disconnected inode 155227501, moving to lost+found=0A= disconnected inode 155227504, moving to lost+found=0A= disconnected inode 155227506, moving to lost+found=0A= disconnected inode 155227509, moving to lost+found=0A= disconnected inode 167781045, moving to lost+found=0A= disconnected inode 167819889, moving to lost+found=0A= disconnected dir inode 167820183, moving to lost+found=0A= disconnected inode 167823072, moving to lost+found=0A= disconnected inode 167916317, moving to lost+found=0A= disconnected inode 168007659, moving to lost+found=0A= disconnected dir inode 168007934, moving to lost+found=0A= disconnected inode 168064001, moving to lost+found=0A= disconnected inode 168101081, moving to lost+found=0A= disconnected dir inode 168161033, moving to lost+found=0A= disconnected inode 168161215, moving to lost+found=0A= disconnected inode 168353364, moving to lost+found=0A= disconnected dir inode 168933041, moving to lost+found=0A= disconnected inode 168951372, moving to lost+found=0A= disconnected dir inode 168951400, moving to lost+found=0A= disconnected inode 169119542, moving to lost+found=0A= disconnected dir inode 171852475, moving to lost+found=0A= disconnected dir inode 172422841, moving to lost+found=0A= disconnected dir inode 184551707, moving to lost+found=0A= disconnected dir inode 184901760, moving to lost+found=0A= disconnected dir inode 185292998, moving to lost+found=0A= disconnected inode 185295653, moving to lost+found=0A= disconnected inode 185295661, moving to lost+found=0A= disconnected inode 185295663, moving to lost+found=0A= disconnected inode 185295664, moving to lost+found=0A= disconnected inode 185298616, moving to lost+found=0A= disconnected inode 185317845, moving to lost+found=0A= disconnected inode 185345398, moving to lost+found=0A= disconnected inode 185689276, moving to lost+found=0A= disconnected inode 185781527, moving to lost+found=0A= disconnected inode 185781531, moving to lost+found=0A= disconnected inode 185794315, moving to lost+found=0A= disconnected inode 185794318, moving to lost+found=0A= disconnected dir inode 186070963, moving to lost+found=0A= disconnected inode 186189752, moving to lost+found=0A= disconnected inode 187033391, moving to lost+found=0A= disconnected inode 188323417, moving to lost+found=0A= disconnected inode 188323418, moving to lost+found=0A= disconnected inode 188323419, moving to lost+found=0A= disconnected inode 188323420, moving to lost+found=0A= disconnected inode 188323421, moving to lost+found=0A= disconnected inode 188323422, moving to lost+found=0A= disconnected inode 188323423, moving to lost+found=0A= disconnected inode 188387904, moving to lost+found=0A= disconnected inode 188387905, moving to lost+found=0A= disconnected inode 188387906, moving to lost+found=0A= disconnected inode 188387907, moving to lost+found=0A= disconnected inode 188387908, moving to lost+found=0A= disconnected inode 188387909, moving to lost+found=0A= disconnected inode 188387910, moving to lost+found=0A= disconnected inode 188387911, moving to lost+found=0A= disconnected inode 188387912, moving to lost+found=0A= disconnected inode 188387913, moving to lost+found=0A= disconnected inode 188387914, moving to lost+found=0A= disconnected inode 188387915, moving to lost+found=0A= disconnected inode 188387916, moving to lost+found=0A= disconnected inode 188387917, moving to lost+found=0A= disconnected inode 188387918, moving to lost+found=0A= disconnected inode 188387919, moving to lost+found=0A= disconnected inode 188387920, moving to lost+found=0A= disconnected inode 188849148, moving to lost+found=0A= disconnected inode 188849149, moving to lost+found=0A= disconnected inode 188849150, moving to lost+found=0A= disconnected inode 188849151, moving to lost+found=0A= disconnected inode 188851264, moving to lost+found=0A= disconnected inode 188851265, moving to lost+found=0A= disconnected inode 188851266, moving to lost+found=0A= disconnected inode 188851267, moving to lost+found=0A= disconnected inode 188851268, moving to lost+found=0A= disconnected inode 189197288, moving to lost+found=0A= disconnected inode 189306735, moving to lost+found=0A= disconnected inode 189386743, moving to lost+found=0A= disconnected dir inode 201335728, moving to lost+found=0A= disconnected inode 202830770, moving to lost+found=0A= disconnected inode 202830771, moving to lost+found=0A= disconnected dir inode 203165268, moving to lost+found=0A= disconnected dir inode 203329096, moving to lost+found=0A= disconnected dir inode 205994622, moving to lost+found=0A= disconnected dir inode 206374229, moving to lost+found=0A= disconnected dir inode 218175952, moving to lost+found=0A= disconnected dir inode 218268546, moving to lost+found=0A= disconnected dir inode 219474532, moving to lost+found=0A= disconnected dir inode 220095564, moving to lost+found=0A= disconnected dir inode 222309415, moving to lost+found=0A= disconnected dir inode 222917385, moving to lost+found=0A= disconnected dir inode 235151627, moving to lost+found=0A= disconnected inode 235160129, moving to lost+found=0A= disconnected dir inode 235167913, moving to lost+found=0A= disconnected inode 235170690, moving to lost+found=0A= disconnected inode 235170715, moving to lost+found=0A= disconnected inode 235170716, moving to lost+found=0A= disconnected inode 235185347, moving to lost+found=0A= disconnected inode 235185349, moving to lost+found=0A= disconnected inode 235185355, moving to lost+found=0A= disconnected inode 235185356, moving to lost+found=0A= disconnected inode 235185381, moving to lost+found=0A= disconnected dir inode 235272563, moving to lost+found=0A= disconnected dir inode 236212929, moving to lost+found=0A= disconnected dir inode 236354140, moving to lost+found=0A= disconnected inode 238415856, moving to lost+found=0A= disconnected inode 251802323, moving to lost+found=0A= disconnected inode 251802324, moving to lost+found=0A= disconnected inode 251802325, moving to lost+found=0A= disconnected inode 251891064, moving to lost+found=0A= disconnected inode 251891065, moving to lost+found=0A= disconnected inode 251891066, moving to lost+found=0A= disconnected inode 251891067, moving to lost+found=0A= disconnected inode 251891068, moving to lost+found=0A= disconnected inode 251891069, moving to lost+found=0A= disconnected dir inode 251909785, moving to lost+found=0A= disconnected dir inode 251911929, moving to lost+found=0A= disconnected dir inode 252083876, moving to lost+found=0A= disconnected dir inode 252086032, moving to lost+found=0A= disconnected inode 252798686, moving to lost+found=0A= disconnected inode 252798687, moving to lost+found=0A= disconnected inode 252798688, moving to lost+found=0A= disconnected inode 252798689, moving to lost+found=0A= disconnected inode 252798690, moving to lost+found=0A= disconnected inode 252798691, moving to lost+found=0A= disconnected inode 252798692, moving to lost+found=0A= disconnected inode 252798693, moving to lost+found=0A= disconnected inode 252798694, moving to lost+found=0A= disconnected inode 252798695, moving to lost+found=0A= disconnected dir inode 256822619, moving to lost+found=0A= disconnected dir inode 268498244, moving to lost+found=0A= disconnected inode 268541277, moving to lost+found=0A= disconnected inode 268541278, moving to lost+found=0A= disconnected dir inode 268657749, moving to lost+found=0A= disconnected dir inode 268691537, moving to lost+found=0A= disconnected dir inode 268730151, moving to lost+found=0A= disconnected inode 268783469, moving to lost+found=0A= disconnected inode 268783470, moving to lost+found=0A= disconnected inode 268783473, moving to lost+found=0A= disconnected dir inode 269001678, moving to lost+found=0A= disconnected inode 269230581, moving to lost+found=0A= disconnected dir inode 269450705, moving to lost+found=0A= disconnected inode 269450706, moving to lost+found=0A= disconnected inode 269450707, moving to lost+found=0A= disconnected inode 269450708, moving to lost+found=0A= disconnected inode 269450709, moving to lost+found=0A= disconnected inode 269450710, moving to lost+found=0A= disconnected inode 270034346, moving to lost+found=0A= disconnected inode 270143827, moving to lost+found=0A= disconnected inode 270164461, moving to lost+found=0A= disconnected inode 270168216, moving to lost+found=0A= disconnected inode 270168217, moving to lost+found=0A= disconnected inode 270179477, moving to lost+found=0A= disconnected inode 270318133, moving to lost+found=0A= disconnected inode 270421940, moving to lost+found=0A= disconnected inode 271610170, moving to lost+found=0A= disconnected inode 271707629, moving to lost+found=0A= disconnected inode 271902661, moving to lost+found=0A= disconnected inode 271902662, moving to lost+found=0A= disconnected inode 271902672, moving to lost+found=0A= disconnected inode 271902689, moving to lost+found=0A= disconnected inode 271902690, moving to lost+found=0A= disconnected inode 271957620, moving to lost+found=0A= disconnected inode 271958076, moving to lost+found=0A= disconnected inode 271958077, moving to lost+found=0A= disconnected inode 271958079, moving to lost+found=0A= disconnected inode 272066927, moving to lost+found=0A= disconnected inode 272066928, moving to lost+found=0A= disconnected inode 272157717, moving to lost+found=0A= disconnected inode 272157718, moving to lost+found=0A= disconnected inode 272157721, moving to lost+found=0A= disconnected inode 272157728, moving to lost+found=0A= disconnected inode 272157731, moving to lost+found=0A= disconnected inode 272177241, moving to lost+found=0A= disconnected inode 272197245, moving to lost+found=0A= disconnected inode 272197246, moving to lost+found=0A= disconnected inode 272241897, moving to lost+found=0A= disconnected dir inode 273989902, moving to lost+found=0A= disconnected inode 274042728, moving to lost+found=0A= disconnected dir inode 285270286, moving to lost+found=0A= disconnected inode 285416151, moving to lost+found=0A= disconnected inode 285416152, moving to lost+found=0A= disconnected inode 285416153, moving to lost+found=0A= disconnected dir inode 285477456, moving to lost+found=0A= disconnected inode 285477458, moving to lost+found=0A= disconnected inode 285477459, moving to lost+found=0A= disconnected inode 285477460, moving to lost+found=0A= disconnected inode 285477461, moving to lost+found=0A= disconnected inode 285477462, moving to lost+found=0A= disconnected inode 285477463, moving to lost+found=0A= disconnected inode 285477464, moving to lost+found=0A= disconnected inode 285477465, moving to lost+found=0A= disconnected inode 285534953, moving to lost+found=0A= disconnected inode 285534954, moving to lost+found=0A= disconnected inode 285534955, moving to lost+found=0A= disconnected inode 285534956, moving to lost+found=0A= disconnected inode 285534957, moving to lost+found=0A= disconnected dir inode 285660223, moving to lost+found=0A= disconnected dir inode 285660291, moving to lost+found=0A= disconnected inode 285663104, moving to lost+found=0A= disconnected inode 285663105, moving to lost+found=0A= disconnected inode 285663106, moving to lost+found=0A= disconnected inode 285663107, moving to lost+found=0A= disconnected inode 285663108, moving to lost+found=0A= disconnected inode 285663168, moving to lost+found=0A= disconnected inode 285663169, moving to lost+found=0A= disconnected inode 285663170, moving to lost+found=0A= disconnected inode 285663171, moving to lost+found=0A= disconnected inode 285663172, moving to lost+found=0A= disconnected inode 285663173, moving to lost+found=0A= disconnected inode 285663174, moving to lost+found=0A= disconnected inode 285663175, moving to lost+found=0A= disconnected inode 285663176, moving to lost+found=0A= disconnected inode 285663177, moving to lost+found=0A= disconnected inode 285663178, moving to lost+found=0A= disconnected inode 285663179, moving to lost+found=0A= disconnected inode 285663180, moving to lost+found=0A= disconnected inode 285663181, moving to lost+found=0A= disconnected inode 285663182, moving to lost+found=0A= disconnected inode 285663183, moving to lost+found=0A= disconnected inode 285663184, moving to lost+found=0A= disconnected inode 285663185, moving to lost+found=0A= disconnected inode 285663186, moving to lost+found=0A= disconnected inode 285663187, moving to lost+found=0A= disconnected inode 285663188, moving to lost+found=0A= disconnected inode 285663189, moving to lost+found=0A= disconnected inode 285663190, moving to lost+found=0A= disconnected inode 285663191, moving to lost+found=0A= disconnected inode 285663192, moving to lost+found=0A= disconnected inode 285663193, moving to lost+found=0A= disconnected inode 285663194, moving to lost+found=0A= disconnected inode 285663195, moving to lost+found=0A= disconnected inode 285663196, moving to lost+found=0A= disconnected inode 285663197, moving to lost+found=0A= disconnected inode 285663198, moving to lost+found=0A= disconnected inode 285663199, moving to lost+found=0A= disconnected inode 285663200, moving to lost+found=0A= disconnected inode 285663201, moving to lost+found=0A= disconnected inode 285663202, moving to lost+found=0A= disconnected inode 285663203, moving to lost+found=0A= disconnected inode 285663204, moving to lost+found=0A= disconnected inode 285663205, moving to lost+found=0A= disconnected inode 285663206, moving to lost+found=0A= disconnected inode 285663207, moving to lost+found=0A= disconnected inode 285663208, moving to lost+found=0A= disconnected inode 285663209, moving to lost+found=0A= disconnected inode 285663210, moving to lost+found=0A= disconnected inode 285663211, moving to lost+found=0A= disconnected inode 285663212, moving to lost+found=0A= disconnected inode 285663213, moving to lost+found=0A= disconnected inode 285663214, moving to lost+found=0A= disconnected inode 285663215, moving to lost+found=0A= disconnected inode 285663216, moving to lost+found=0A= disconnected inode 285663217, moving to lost+found=0A= disconnected inode 285663218, moving to lost+found=0A= disconnected inode 285663219, moving to lost+found=0A= disconnected inode 285663221, moving to lost+found=0A= disconnected inode 285663222, moving to lost+found=0A= disconnected inode 285663223, moving to lost+found=0A= disconnected inode 285663224, moving to lost+found=0A= disconnected inode 285663225, moving to lost+found=0A= disconnected inode 285663226, moving to lost+found=0A= disconnected inode 285663227, moving to lost+found=0A= disconnected inode 285663228, moving to lost+found=0A= disconnected inode 285663229, moving to lost+found=0A= disconnected inode 285663231, moving to lost+found=0A= disconnected inode 285663328, moving to lost+found=0A= disconnected inode 285663330, moving to lost+found=0A= disconnected inode 285663331, moving to lost+found=0A= disconnected inode 285663332, moving to lost+found=0A= disconnected inode 285663333, moving to lost+found=0A= disconnected inode 285663334, moving to lost+found=0A= disconnected inode 285663335, moving to lost+found=0A= disconnected inode 285663338, moving to lost+found=0A= disconnected inode 285663339, moving to lost+found=0A= disconnected inode 285663340, moving to lost+found=0A= disconnected inode 285663341, moving to lost+found=0A= disconnected inode 285663342, moving to lost+found=0A= disconnected inode 285663343, moving to lost+found=0A= disconnected inode 285663344, moving to lost+found=0A= disconnected inode 285663345, moving to lost+found=0A= disconnected inode 285663346, moving to lost+found=0A= disconnected inode 285663347, moving to lost+found=0A= disconnected inode 285663348, moving to lost+found=0A= disconnected inode 285663349, moving to lost+found=0A= disconnected inode 285663350, moving to lost+found=0A= disconnected inode 285663351, moving to lost+found=0A= disconnected inode 285663352, moving to lost+found=0A= disconnected inode 285663353, moving to lost+found=0A= disconnected inode 285663354, moving to lost+found=0A= disconnected inode 285663355, moving to lost+found=0A= disconnected inode 285663356, moving to lost+found=0A= disconnected inode 285663357, moving to lost+found=0A= disconnected inode 285663358, moving to lost+found=0A= disconnected inode 285663359, moving to lost+found=0A= disconnected inode 285663360, moving to lost+found=0A= disconnected inode 285663361, moving to lost+found=0A= disconnected inode 285663362, moving to lost+found=0A= disconnected inode 285663363, moving to lost+found=0A= disconnected inode 285663364, moving to lost+found=0A= disconnected inode 285663365, moving to lost+found=0A= disconnected inode 285663366, moving to lost+found=0A= disconnected inode 285663367, moving to lost+found=0A= disconnected inode 285663368, moving to lost+found=0A= disconnected inode 285663369, moving to lost+found=0A= disconnected inode 285663370, moving to lost+found=0A= disconnected inode 285663371, moving to lost+found=0A= disconnected inode 285663372, moving to lost+found=0A= disconnected inode 285663373, moving to lost+found=0A= disconnected inode 285663374, moving to lost+found=0A= disconnected inode 285663375, moving to lost+found=0A= disconnected inode 285663376, moving to lost+found=0A= disconnected inode 285663377, moving to lost+found=0A= disconnected inode 285663378, moving to lost+found=0A= disconnected inode 285663379, moving to lost+found=0A= disconnected inode 285663380, moving to lost+found=0A= disconnected inode 285663381, moving to lost+found=0A= disconnected inode 285663382, moving to lost+found=0A= disconnected inode 285663383, moving to lost+found=0A= disconnected inode 285663384, moving to lost+found=0A= disconnected inode 285663385, moving to lost+found=0A= disconnected inode 285663386, moving to lost+found=0A= disconnected inode 285663387, moving to lost+found=0A= disconnected inode 285663388, moving to lost+found=0A= disconnected inode 285663389, moving to lost+found=0A= disconnected inode 285663390, moving to lost+found=0A= disconnected inode 285663391, moving to lost+found=0A= disconnected inode 285663392, moving to lost+found=0A= disconnected inode 285663393, moving to lost+found=0A= disconnected inode 285663394, moving to lost+found=0A= disconnected inode 285663395, moving to lost+found=0A= disconnected inode 285663396, moving to lost+found=0A= disconnected inode 285663397, moving to lost+found=0A= disconnected inode 285663398, moving to lost+found=0A= disconnected inode 285663399, moving to lost+found=0A= disconnected inode 285663400, moving to lost+found=0A= disconnected inode 285663401, moving to lost+found=0A= disconnected inode 285663402, moving to lost+found=0A= disconnected inode 285663403, moving to lost+found=0A= disconnected inode 285663404, moving to lost+found=0A= disconnected inode 285663405, moving to lost+found=0A= disconnected inode 285663406, moving to lost+found=0A= disconnected inode 285663407, moving to lost+found=0A= disconnected inode 285663408, moving to lost+found=0A= disconnected inode 285663409, moving to lost+found=0A= disconnected inode 285663410, moving to lost+found=0A= disconnected inode 285663411, moving to lost+found=0A= disconnected inode 285663412, moving to lost+found=0A= disconnected inode 285663413, moving to lost+found=0A= disconnected inode 285663414, moving to lost+found=0A= disconnected inode 285663415, moving to lost+found=0A= disconnected inode 285663416, moving to lost+found=0A= disconnected inode 285663417, moving to lost+found=0A= disconnected inode 285663418, moving to lost+found=0A= disconnected inode 285663419, moving to lost+found=0A= disconnected inode 285663420, moving to lost+found=0A= disconnected inode 285663421, moving to lost+found=0A= disconnected inode 285663422, moving to lost+found=0A= disconnected inode 285663423, moving to lost+found=0A= disconnected inode 285663424, moving to lost+found=0A= disconnected inode 285663425, moving to lost+found=0A= disconnected inode 285663426, moving to lost+found=0A= disconnected inode 285663427, moving to lost+found=0A= disconnected inode 285663428, moving to lost+found=0A= disconnected inode 285663429, moving to lost+found=0A= disconnected inode 285663430, moving to lost+found=0A= disconnected inode 285663431, moving to lost+found=0A= disconnected inode 285663432, moving to lost+found=0A= disconnected inode 285663433, moving to lost+found=0A= disconnected inode 285663434, moving to lost+found=0A= disconnected inode 285663435, moving to lost+found=0A= disconnected inode 285663436, moving to lost+found=0A= disconnected inode 285663437, moving to lost+found=0A= disconnected inode 285663438, moving to lost+found=0A= disconnected inode 285663439, moving to lost+found=0A= disconnected inode 285663440, moving to lost+found=0A= disconnected inode 285663441, moving to lost+found=0A= disconnected inode 285663442, moving to lost+found=0A= disconnected inode 285663443, moving to lost+found=0A= disconnected inode 285663444, moving to lost+found=0A= disconnected inode 285663445, moving to lost+found=0A= disconnected inode 285663446, moving to lost+found=0A= disconnected inode 285663447, moving to lost+found=0A= disconnected inode 285663448, moving to lost+found=0A= disconnected inode 285663449, moving to lost+found=0A= disconnected inode 285663450, moving to lost+found=0A= disconnected inode 285663451, moving to lost+found=0A= disconnected inode 285663452, moving to lost+found=0A= disconnected inode 285663453, moving to lost+found=0A= disconnected inode 285663455, moving to lost+found=0A= disconnected inode 285663456, moving to lost+found=0A= disconnected inode 285663457, moving to lost+found=0A= disconnected inode 285663458, moving to lost+found=0A= disconnected inode 285663459, moving to lost+found=0A= disconnected inode 285663460, moving to lost+found=0A= disconnected inode 285663461, moving to lost+found=0A= disconnected inode 285663462, moving to lost+found=0A= disconnected inode 285663463, moving to lost+found=0A= disconnected inode 285663464, moving to lost+found=0A= disconnected inode 285663465, moving to lost+found=0A= disconnected inode 285663466, moving to lost+found=0A= disconnected inode 285663467, moving to lost+found=0A= disconnected inode 285663468, moving to lost+found=0A= disconnected inode 285663469, moving to lost+found=0A= disconnected inode 285663470, moving to lost+found=0A= disconnected inode 285663471, moving to lost+found=0A= disconnected inode 285663472, moving to lost+found=0A= disconnected inode 285663473, moving to lost+found=0A= disconnected inode 285663474, moving to lost+found=0A= disconnected inode 285663475, moving to lost+found=0A= disconnected inode 285663476, moving to lost+found=0A= disconnected inode 285663477, moving to lost+found=0A= disconnected inode 285663478, moving to lost+found=0A= disconnected inode 285663479, moving to lost+found=0A= disconnected inode 285663480, moving to lost+found=0A= disconnected inode 285663481, moving to lost+found=0A= disconnected inode 285663482, moving to lost+found=0A= disconnected inode 285663483, moving to lost+found=0A= disconnected inode 285663484, moving to lost+found=0A= disconnected inode 285663485, moving to lost+found=0A= disconnected inode 285663486, moving to lost+found=0A= disconnected inode 285663487, moving to lost+found=0A= disconnected inode 285663488, moving to lost+found=0A= disconnected inode 285663489, moving to lost+found=0A= disconnected inode 285663490, moving to lost+found=0A= disconnected inode 285663491, moving to lost+found=0A= disconnected inode 285663492, moving to lost+found=0A= disconnected inode 285663493, moving to lost+found=0A= disconnected inode 285663494, moving to lost+found=0A= disconnected inode 285663495, moving to lost+found=0A= disconnected inode 285663496, moving to lost+found=0A= disconnected inode 285663497, moving to lost+found=0A= disconnected inode 285663498, moving to lost+found=0A= disconnected inode 285663499, moving to lost+found=0A= disconnected inode 285663500, moving to lost+found=0A= disconnected inode 285663501, moving to lost+found=0A= disconnected inode 285663502, moving to lost+found=0A= disconnected inode 285663503, moving to lost+found=0A= disconnected inode 285663505, moving to lost+found=0A= disconnected inode 285663507, moving to lost+found=0A= disconnected inode 285663508, moving to lost+found=0A= disconnected inode 285663509, moving to lost+found=0A= disconnected inode 285663510, moving to lost+found=0A= disconnected inode 285663511, moving to lost+found=0A= disconnected inode 285663512, moving to lost+found=0A= disconnected inode 285663513, moving to lost+found=0A= disconnected inode 285663514, moving to lost+found=0A= disconnected inode 285663515, moving to lost+found=0A= disconnected inode 285663516, moving to lost+found=0A= disconnected inode 285663517, moving to lost+found=0A= disconnected inode 285663518, moving to lost+found=0A= disconnected inode 285663519, moving to lost+found=0A= disconnected inode 285663584, moving to lost+found=0A= disconnected inode 285663585, moving to lost+found=0A= disconnected inode 285663586, moving to lost+found=0A= disconnected inode 285663587, moving to lost+found=0A= disconnected inode 285663588, moving to lost+found=0A= disconnected inode 285663589, moving to lost+found=0A= disconnected inode 285663590, moving to lost+found=0A= disconnected inode 285663591, moving to lost+found=0A= disconnected inode 285663592, moving to lost+found=0A= disconnected inode 285663593, moving to lost+found=0A= disconnected inode 285663594, moving to lost+found=0A= disconnected inode 285663595, moving to lost+found=0A= disconnected inode 285663596, moving to lost+found=0A= disconnected inode 285663597, moving to lost+found=0A= disconnected inode 285663598, moving to lost+found=0A= disconnected inode 285663599, moving to lost+found=0A= disconnected inode 285663600, moving to lost+found=0A= disconnected inode 285663601, moving to lost+found=0A= disconnected inode 285663602, moving to lost+found=0A= disconnected inode 285663603, moving to lost+found=0A= disconnected inode 285663604, moving to lost+found=0A= disconnected inode 285663605, moving to lost+found=0A= disconnected inode 285663606, moving to lost+found=0A= disconnected inode 285663607, moving to lost+found=0A= disconnected inode 285663608, moving to lost+found=0A= disconnected inode 285663609, moving to lost+found=0A= disconnected inode 285663610, moving to lost+found=0A= disconnected inode 285663612, moving to lost+found=0A= disconnected inode 285663613, moving to lost+found=0A= disconnected inode 285663614, moving to lost+found=0A= disconnected inode 285663615, moving to lost+found=0A= disconnected inode 285663616, moving to lost+found=0A= disconnected inode 285663617, moving to lost+found=0A= disconnected inode 285663618, moving to lost+found=0A= disconnected inode 285663619, moving to lost+found=0A= disconnected inode 285663620, moving to lost+found=0A= disconnected inode 285663621, moving to lost+found=0A= disconnected inode 285663622, moving to lost+found=0A= disconnected inode 285663623, moving to lost+found=0A= disconnected inode 285663624, moving to lost+found=0A= disconnected inode 285663625, moving to lost+found=0A= disconnected inode 285663626, moving to lost+found=0A= disconnected inode 285663629, moving to lost+found=0A= disconnected inode 285663630, moving to lost+found=0A= disconnected inode 285663631, moving to lost+found=0A= disconnected inode 285663632, moving to lost+found=0A= disconnected inode 285663633, moving to lost+found=0A= disconnected inode 285663634, moving to lost+found=0A= disconnected inode 285663635, moving to lost+found=0A= disconnected inode 285663636, moving to lost+found=0A= disconnected inode 285663637, moving to lost+found=0A= disconnected inode 285663638, moving to lost+found=0A= disconnected inode 285663639, moving to lost+found=0A= disconnected inode 285663640, moving to lost+found=0A= disconnected inode 285663641, moving to lost+found=0A= disconnected inode 285663642, moving to lost+found=0A= disconnected inode 285663643, moving to lost+found=0A= disconnected inode 285663644, moving to lost+found=0A= disconnected inode 285663645, moving to lost+found=0A= disconnected inode 285663647, moving to lost+found=0A= disconnected inode 285665766, moving to lost+found=0A= disconnected inode 285666478, moving to lost+found=0A= disconnected inode 285666483, moving to lost+found=0A= disconnected inode 285666618, moving to lost+found=0A= disconnected inode 285666654, moving to lost+found=0A= disconnected inode 285666688, moving to lost+found=0A= disconnected inode 285666787, moving to lost+found=0A= disconnected inode 285666789, moving to lost+found=0A= disconnected inode 285666805, moving to lost+found=0A= disconnected inode 285666807, moving to lost+found=0A= disconnected dir inode 285667809, moving to lost+found=0A= disconnected inode 285667813, moving to lost+found=0A= disconnected inode 285667815, moving to lost+found=0A= disconnected inode 285667824, moving to lost+found=0A= disconnected inode 285667825, moving to lost+found=0A= disconnected inode 285667837, moving to lost+found=0A= disconnected inode 285667841, moving to lost+found=0A= disconnected inode 285667842, moving to lost+found=0A= disconnected inode 285667843, moving to lost+found=0A= disconnected inode 285667844, moving to lost+found=0A= disconnected inode 285667845, moving to lost+found=0A= disconnected inode 285667904, moving to lost+found=0A= disconnected inode 285667905, moving to lost+found=0A= disconnected inode 285667906, moving to lost+found=0A= disconnected inode 285667907, moving to lost+found=0A= disconnected inode 285667908, moving to lost+found=0A= disconnected inode 285667909, moving to lost+found=0A= disconnected inode 285667910, moving to lost+found=0A= disconnected inode 285667911, moving to lost+found=0A= disconnected inode 285667912, moving to lost+found=0A= disconnected inode 285667913, moving to lost+found=0A= disconnected inode 285667914, moving to lost+found=0A= disconnected inode 285667915, moving to lost+found=0A= disconnected inode 285667916, moving to lost+found=0A= disconnected inode 285667917, moving to lost+found=0A= disconnected inode 285667918, moving to lost+found=0A= disconnected inode 285667920, moving to lost+found=0A= disconnected inode 285667921, moving to lost+found=0A= disconnected inode 285667922, moving to lost+found=0A= disconnected inode 285667923, moving to lost+found=0A= disconnected inode 285667924, moving to lost+found=0A= disconnected inode 285667925, moving to lost+found=0A= disconnected inode 285667926, moving to lost+found=0A= disconnected inode 285667927, moving to lost+found=0A= disconnected inode 285667928, moving to lost+found=0A= disconnected inode 285667929, moving to lost+found=0A= disconnected inode 285667930, moving to lost+found=0A= disconnected inode 285667931, moving to lost+found=0A= disconnected inode 285667932, moving to lost+found=0A= disconnected inode 285667933, moving to lost+found=0A= disconnected inode 285667934, moving to lost+found=0A= disconnected inode 285667935, moving to lost+found=0A= disconnected inode 285667936, moving to lost+found=0A= disconnected inode 285667937, moving to lost+found=0A= disconnected inode 285667938, moving to lost+found=0A= disconnected inode 285667939, moving to lost+found=0A= disconnected inode 285667940, moving to lost+found=0A= disconnected inode 285667941, moving to lost+found=0A= disconnected inode 285667942, moving to lost+found=0A= disconnected inode 285667943, moving to lost+found=0A= disconnected inode 285667944, moving to lost+found=0A= disconnected inode 285667945, moving to lost+found=0A= disconnected inode 285667946, moving to lost+found=0A= disconnected inode 285667968, moving to lost+found=0A= disconnected inode 285667969, moving to lost+found=0A= disconnected inode 285667970, moving to lost+found=0A= disconnected inode 285667971, moving to lost+found=0A= disconnected inode 285667972, moving to lost+found=0A= disconnected inode 285667973, moving to lost+found=0A= disconnected inode 285667974, moving to lost+found=0A= disconnected inode 285667975, moving to lost+found=0A= disconnected inode 285667976, moving to lost+found=0A= disconnected inode 285667977, moving to lost+found=0A= disconnected inode 285667978, moving to lost+found=0A= disconnected inode 285667979, moving to lost+found=0A= disconnected inode 285667980, moving to lost+found=0A= disconnected inode 285667981, moving to lost+found=0A= disconnected inode 285667982, moving to lost+found=0A= disconnected inode 285667983, moving to lost+found=0A= disconnected inode 285667984, moving to lost+found=0A= disconnected inode 285667985, moving to lost+found=0A= disconnected inode 285667986, moving to lost+found=0A= disconnected inode 285667987, moving to lost+found=0A= disconnected inode 285667988, moving to lost+found=0A= disconnected inode 285667989, moving to lost+found=0A= disconnected inode 285667990, moving to lost+found=0A= disconnected inode 285667991, moving to lost+found=0A= disconnected inode 285667992, moving to lost+found=0A= disconnected inode 285667993, moving to lost+found=0A= disconnected inode 285667994, moving to lost+found=0A= disconnected inode 285667995, moving to lost+found=0A= disconnected inode 285667996, moving to lost+found=0A= disconnected inode 285667997, moving to lost+found=0A= disconnected inode 285667998, moving to lost+found=0A= disconnected inode 285667999, moving to lost+found=0A= disconnected inode 285668000, moving to lost+found=0A= disconnected inode 285668001, moving to lost+found=0A= disconnected inode 285668002, moving to lost+found=0A= disconnected inode 285668003, moving to lost+found=0A= disconnected inode 285668004, moving to lost+found=0A= disconnected inode 285668005, moving to lost+found=0A= disconnected inode 285668006, moving to lost+found=0A= disconnected inode 285668007, moving to lost+found=0A= disconnected inode 285668008, moving to lost+found=0A= disconnected inode 285668009, moving to lost+found=0A= disconnected inode 285668010, moving to lost+found=0A= disconnected inode 285668011, moving to lost+found=0A= disconnected inode 285668012, moving to lost+found=0A= disconnected inode 285668013, moving to lost+found=0A= disconnected inode 285668014, moving to lost+found=0A= disconnected inode 285668015, moving to lost+found=0A= disconnected inode 285668016, moving to lost+found=0A= disconnected inode 285668017, moving to lost+found=0A= disconnected inode 285668018, moving to lost+found=0A= disconnected inode 285668019, moving to lost+found=0A= disconnected inode 285668020, moving to lost+found=0A= disconnected inode 285668021, moving to lost+found=0A= disconnected inode 285668022, moving to lost+found=0A= disconnected inode 285668023, moving to lost+found=0A= disconnected inode 285668024, moving to lost+found=0A= disconnected inode 285668025, moving to lost+found=0A= disconnected inode 285668026, moving to lost+found=0A= disconnected inode 285668027, moving to lost+found=0A= disconnected inode 285668028, moving to lost+found=0A= disconnected inode 285668029, moving to lost+found=0A= disconnected inode 285668030, moving to lost+found=0A= disconnected inode 285668031, moving to lost+found=0A= disconnected inode 285668128, moving to lost+found=0A= disconnected inode 285668129, moving to lost+found=0A= disconnected inode 285668130, moving to lost+found=0A= disconnected inode 285668131, moving to lost+found=0A= disconnected inode 285668132, moving to lost+found=0A= disconnected inode 285668133, moving to lost+found=0A= disconnected inode 285668134, moving to lost+found=0A= disconnected inode 285668135, moving to lost+found=0A= disconnected inode 285668136, moving to lost+found=0A= disconnected inode 285668137, moving to lost+found=0A= disconnected inode 285668138, moving to lost+found=0A= disconnected inode 285668139, moving to lost+found=0A= disconnected inode 285668140, moving to lost+found=0A= disconnected inode 285668141, moving to lost+found=0A= disconnected inode 285668142, moving to lost+found=0A= disconnected inode 285668143, moving to lost+found=0A= disconnected inode 285668144, moving to lost+found=0A= disconnected inode 285668145, moving to lost+found=0A= disconnected inode 285668146, moving to lost+found=0A= disconnected inode 285668147, moving to lost+found=0A= disconnected inode 285668148, moving to lost+found=0A= disconnected inode 285668149, moving to lost+found=0A= disconnected inode 285668150, moving to lost+found=0A= disconnected inode 285668151, moving to lost+found=0A= disconnected inode 285668152, moving to lost+found=0A= disconnected inode 285668153, moving to lost+found=0A= disconnected inode 285668154, moving to lost+found=0A= disconnected inode 285668155, moving to lost+found=0A= disconnected inode 285668156, moving to lost+found=0A= disconnected inode 285668157, moving to lost+found=0A= disconnected inode 285668158, moving to lost+found=0A= disconnected inode 285668159, moving to lost+found=0A= disconnected inode 285668160, moving to lost+found=0A= disconnected inode 285668161, moving to lost+found=0A= disconnected inode 285668162, moving to lost+found=0A= disconnected inode 285668163, moving to lost+found=0A= disconnected inode 285668164, moving to lost+found=0A= disconnected inode 285668165, moving to lost+found=0A= disconnected inode 285668166, moving to lost+found=0A= disconnected inode 285668167, moving to lost+found=0A= disconnected inode 285668168, moving to lost+found=0A= disconnected inode 285668169, moving to lost+found=0A= disconnected inode 285668170, moving to lost+found=0A= disconnected inode 285668171, moving to lost+found=0A= disconnected inode 285668172, moving to lost+found=0A= disconnected inode 285668173, moving to lost+found=0A= disconnected inode 285668174, moving to lost+found=0A= disconnected inode 285668175, moving to lost+found=0A= disconnected inode 285668176, moving to lost+found=0A= disconnected inode 285668177, moving to lost+found=0A= disconnected inode 285668178, moving to lost+found=0A= disconnected inode 285668179, moving to lost+found=0A= disconnected inode 285668180, moving to lost+found=0A= disconnected inode 285668181, moving to lost+found=0A= disconnected inode 285668182, moving to lost+found=0A= disconnected inode 285668183, moving to lost+found=0A= disconnected inode 285668184, moving to lost+found=0A= disconnected inode 285668185, moving to lost+found=0A= disconnected inode 285668186, moving to lost+found=0A= disconnected inode 285668187, moving to lost+found=0A= disconnected inode 285668188, moving to lost+found=0A= disconnected inode 285668189, moving to lost+found=0A= disconnected inode 285668190, moving to lost+found=0A= disconnected inode 285668191, moving to lost+found=0A= disconnected inode 285668192, moving to lost+found=0A= disconnected inode 285668193, moving to lost+found=0A= disconnected inode 285668194, moving to lost+found=0A= disconnected inode 285668195, moving to lost+found=0A= disconnected inode 285668196, moving to lost+found=0A= disconnected inode 285668197, moving to lost+found=0A= disconnected inode 285668198, moving to lost+found=0A= disconnected inode 285668199, moving to lost+found=0A= disconnected inode 285668200, moving to lost+found=0A= disconnected inode 285668201, moving to lost+found=0A= disconnected inode 285668202, moving to lost+found=0A= disconnected inode 285668203, moving to lost+found=0A= disconnected inode 285668204, moving to lost+found=0A= disconnected inode 285668205, moving to lost+found=0A= disconnected inode 285668206, moving to lost+found=0A= disconnected inode 285668207, moving to lost+found=0A= disconnected inode 285668208, moving to lost+found=0A= disconnected inode 285668209, moving to lost+found=0A= disconnected inode 285668210, moving to lost+found=0A= disconnected inode 285668211, moving to lost+found=0A= disconnected inode 285668212, moving to lost+found=0A= disconnected inode 285668213, moving to lost+found=0A= disconnected inode 285668214, moving to lost+found=0A= disconnected inode 285668215, moving to lost+found=0A= disconnected inode 285668216, moving to lost+found=0A= disconnected inode 285668217, moving to lost+found=0A= disconnected inode 285668218, moving to lost+found=0A= disconnected inode 285668219, moving to lost+found=0A= disconnected inode 285668220, moving to lost+found=0A= disconnected inode 285668221, moving to lost+found=0A= disconnected inode 285668222, moving to lost+found=0A= disconnected inode 285668223, moving to lost+found=0A= disconnected inode 285668224, moving to lost+found=0A= disconnected inode 285668225, moving to lost+found=0A= disconnected inode 285668226, moving to lost+found=0A= disconnected inode 285668227, moving to lost+found=0A= disconnected inode 285668228, moving to lost+found=0A= disconnected inode 285668229, moving to lost+found=0A= disconnected inode 285668230, moving to lost+found=0A= disconnected inode 285668231, moving to lost+found=0A= disconnected inode 285668232, moving to lost+found=0A= disconnected inode 285668233, moving to lost+found=0A= disconnected inode 285668234, moving to lost+found=0A= disconnected inode 285668235, moving to lost+found=0A= disconnected inode 285668236, moving to lost+found=0A= disconnected inode 285668237, moving to lost+found=0A= disconnected inode 285668238, moving to lost+found=0A= disconnected inode 285668239, moving to lost+found=0A= disconnected inode 285668240, moving to lost+found=0A= disconnected inode 285668241, moving to lost+found=0A= disconnected inode 285668242, moving to lost+found=0A= disconnected inode 285668243, moving to lost+found=0A= disconnected inode 285668244, moving to lost+found=0A= disconnected inode 285668245, moving to lost+found=0A= disconnected inode 285668251, moving to lost+found=0A= disconnected inode 285668252, moving to lost+found=0A= disconnected inode 285668255, moving to lost+found=0A= disconnected inode 285668527, moving to lost+found=0A= disconnected inode 285668528, moving to lost+found=0A= disconnected inode 285668529, moving to lost+found=0A= disconnected inode 285668530, moving to lost+found=0A= disconnected inode 285668531, moving to lost+found=0A= disconnected inode 285668532, moving to lost+found=0A= disconnected inode 285668533, moving to lost+found=0A= disconnected inode 285668534, moving to lost+found=0A= disconnected inode 285668535, moving to lost+found=0A= disconnected inode 285668536, moving to lost+found=0A= disconnected inode 285668537, moving to lost+found=0A= disconnected inode 285668538, moving to lost+found=0A= disconnected inode 285668539, moving to lost+found=0A= disconnected inode 285668540, moving to lost+found=0A= disconnected inode 285668542, moving to lost+found=0A= disconnected inode 285668543, moving to lost+found=0A= disconnected inode 285668544, moving to lost+found=0A= disconnected inode 285668545, moving to lost+found=0A= disconnected inode 285668546, moving to lost+found=0A= disconnected inode 285668547, moving to lost+found=0A= disconnected inode 285668548, moving to lost+found=0A= disconnected inode 285668549, moving to lost+found=0A= disconnected inode 285668550, moving to lost+found=0A= disconnected inode 285668551, moving to lost+found=0A= disconnected inode 285668552, moving to lost+found=0A= disconnected inode 285668553, moving to lost+found=0A= disconnected inode 285668554, moving to lost+found=0A= disconnected inode 285668555, moving to lost+found=0A= disconnected inode 285668556, moving to lost+found=0A= disconnected inode 285668557, moving to lost+found=0A= disconnected inode 285668558, moving to lost+found=0A= disconnected inode 285668559, moving to lost+found=0A= disconnected inode 285668560, moving to lost+found=0A= disconnected inode 285668561, moving to lost+found=0A= disconnected inode 285668562, moving to lost+found=0A= disconnected inode 285668563, moving to lost+found=0A= disconnected inode 285668564, moving to lost+found=0A= disconnected inode 285668565, moving to lost+found=0A= disconnected inode 285668566, moving to lost+found=0A= disconnected inode 285668567, moving to lost+found=0A= disconnected inode 285668568, moving to lost+found=0A= disconnected inode 285668569, moving to lost+found=0A= disconnected inode 285668570, moving to lost+found=0A= disconnected inode 285668571, moving to lost+found=0A= disconnected inode 285668572, moving to lost+found=0A= disconnected inode 285668573, moving to lost+found=0A= disconnected inode 285668574, moving to lost+found=0A= disconnected inode 285668575, moving to lost+found=0A= disconnected inode 285668921, moving to lost+found=0A= disconnected inode 285668922, moving to lost+found=0A= disconnected inode 285668923, moving to lost+found=0A= disconnected inode 285668932, moving to lost+found=0A= disconnected inode 285668943, moving to lost+found=0A= disconnected inode 285671733, moving to lost+found=0A= disconnected inode 285671734, moving to lost+found=0A= disconnected inode 285675989, moving to lost+found=0A= disconnected inode 285676009, moving to lost+found=0A= disconnected inode 285676010, moving to lost+found=0A= disconnected inode 285676011, moving to lost+found=0A= disconnected inode 285676012, moving to lost+found=0A= disconnected inode 285676013, moving to lost+found=0A= disconnected inode 285676014, moving to lost+found=0A= disconnected inode 285676015, moving to lost+found=0A= disconnected inode 285676016, moving to lost+found=0A= disconnected inode 285676019, moving to lost+found=0A= disconnected inode 285676020, moving to lost+found=0A= disconnected inode 285676021, moving to lost+found=0A= disconnected inode 285676022, moving to lost+found=0A= disconnected inode 285676023, moving to lost+found=0A= disconnected inode 285676024, moving to lost+found=0A= disconnected inode 285676025, moving to lost+found=0A= disconnected inode 285676026, moving to lost+found=0A= disconnected inode 285676027, moving to lost+found=0A= disconnected inode 285676028, moving to lost+found=0A= disconnected inode 285676029, moving to lost+found=0A= disconnected inode 285676030, moving to lost+found=0A= disconnected inode 285676031, moving to lost+found=0A= disconnected inode 285678557, moving to lost+found=0A= disconnected inode 285678558, moving to lost+found=0A= disconnected inode 285678679, moving to lost+found=0A= disconnected inode 285678683, moving to lost+found=0A= disconnected inode 285678685, moving to lost+found=0A= disconnected inode 285678686, moving to lost+found=0A= disconnected inode 286333221, moving to lost+found=0A= disconnected inode 286333222, moving to lost+found=0A= disconnected dir inode 286333223, moving to lost+found=0A= disconnected inode 286553032, moving to lost+found=0A= disconnected inode 286553035, moving to lost+found=0A= disconnected inode 288229341, moving to lost+found=0A= disconnected inode 290413527, moving to lost+found=0A= disconnected inode 290461847, moving to lost+found=0A= disconnected inode 290461849, moving to lost+found=0A= disconnected inode 302039116, moving to lost+found=0A= disconnected inode 302039128, moving to lost+found=0A= disconnected dir inode 302050147, moving to lost+found=0A= disconnected dir inode 302110541, moving to lost+found=0A= disconnected dir inode 302157519, moving to lost+found=0A= disconnected dir inode 302172750, moving to lost+found=0A= disconnected inode 302290460, moving to lost+found=0A= disconnected inode 302290464, moving to lost+found=0A= disconnected inode 302319708, moving to lost+found=0A= disconnected dir inode 302375092, moving to lost+found=0A= disconnected dir inode 302535429, moving to lost+found=0A= disconnected dir inode 302535582, moving to lost+found=0A= disconnected inode 302965995, moving to lost+found=0A= disconnected dir inode 302966013, moving to lost+found=0A= disconnected dir inode 307118029, moving to lost+found=0A= disconnected inode 318894317, moving to lost+found=0A= disconnected inode 318894318, moving to lost+found=0A= disconnected inode 318894330, moving to lost+found=0A= disconnected inode 318894331, moving to lost+found=0A= disconnected inode 318894332, moving to lost+found=0A= disconnected inode 318894333, moving to lost+found=0A= disconnected inode 318894339, moving to lost+found=0A= disconnected inode 318894340, moving to lost+found=0A= disconnected inode 318894344, moving to lost+found=0A= disconnected dir inode 318896856, moving to lost+found=0A= disconnected dir inode 318901264, moving to lost+found=0A= disconnected inode 318927129, moving to lost+found=0A= disconnected dir inode 318927131, moving to lost+found=0A= disconnected inode 318927132, moving to lost+found=0A= disconnected inode 318927133, moving to lost+found=0A= disconnected inode 318927134, moving to lost+found=0A= disconnected inode 318927147, moving to lost+found=0A= disconnected dir inode 318943167, moving to lost+found=0A= disconnected inode 318983477, moving to lost+found=0A= disconnected dir inode 318983489, moving to lost+found=0A= disconnected dir inode 319042642, moving to lost+found=0A= disconnected inode 319453119, moving to lost+found=0A= disconnected inode 320300337, moving to lost+found=0A= disconnected dir inode 320339566, moving to lost+found=0A= disconnected inode 320520593, moving to lost+found=0A= disconnected inode 321033654, moving to lost+found=0A= disconnected inode 321033655, moving to lost+found=0A= disconnected inode 321033663, moving to lost+found=0A= disconnected inode 321033670, moving to lost+found=0A= disconnected inode 321033675, moving to lost+found=0A= disconnected inode 321033679, moving to lost+found=0A= disconnected inode 321033680, moving to lost+found=0A= disconnected inode 321105396, moving to lost+found=0A= disconnected inode 321212176, moving to lost+found=0A= disconnected inode 321212177, moving to lost+found=0A= disconnected inode 321212182, moving to lost+found=0A= disconnected inode 321212183, moving to lost+found=0A= disconnected inode 321212184, moving to lost+found=0A= disconnected inode 321212185, moving to lost+found=0A= disconnected inode 321212203, moving to lost+found=0A= disconnected inode 321297639, moving to lost+found=0A= disconnected inode 321297640, moving to lost+found=0A= disconnected inode 321625889, moving to lost+found=0A= disconnected inode 321628184, moving to lost+found=0A= disconnected inode 321628185, moving to lost+found=0A= disconnected inode 321628186, moving to lost+found=0A= disconnected inode 321628187, moving to lost+found=0A= disconnected inode 321628188, moving to lost+found=0A= disconnected inode 321628189, moving to lost+found=0A= disconnected inode 321628190, moving to lost+found=0A= disconnected inode 321645886, moving to lost+found=0A= disconnected inode 321645887, moving to lost+found=0A= disconnected inode 321658272, moving to lost+found=0A= disconnected inode 321658273, moving to lost+found=0A= disconnected inode 321658274, moving to lost+found=0A= disconnected inode 321658275, moving to lost+found=0A= disconnected inode 321658276, moving to lost+found=0A= disconnected inode 321658277, moving to lost+found=0A= disconnected inode 321658278, moving to lost+found=0A= disconnected inode 321658279, moving to lost+found=0A= disconnected inode 321658286, moving to lost+found=0A= disconnected inode 321658287, moving to lost+found=0A= disconnected inode 321658288, moving to lost+found=0A= disconnected inode 321658289, moving to lost+found=0A= disconnected inode 321658290, moving to lost+found=0A= disconnected inode 321658292, moving to lost+found=0A= disconnected inode 321658293, moving to lost+found=0A= disconnected inode 321658299, moving to lost+found=0A= disconnected inode 321671658, moving to lost+found=0A= disconnected inode 321832999, moving to lost+found=0A= disconnected inode 321941547, moving to lost+found=0A= disconnected inode 321955648, moving to lost+found=0A= disconnected inode 321955649, moving to lost+found=0A= disconnected inode 321961815, moving to lost+found=0A= disconnected inode 321963040, moving to lost+found=0A= disconnected inode 321965416, moving to lost+found=0A= disconnected inode 321965417, moving to lost+found=0A= disconnected inode 322775330, moving to lost+found=0A= disconnected dir inode 323606998, moving to lost+found=0A= disconnected dir inode 335655267, moving to lost+found=0A= disconnected dir inode 335722793, moving to lost+found=0A= disconnected inode 335834540, moving to lost+found=0A= disconnected inode 335834541, moving to lost+found=0A= disconnected inode 335834542, moving to lost+found=0A= disconnected inode 335834543, moving to lost+found=0A= disconnected inode 335834859, moving to lost+found=0A= disconnected inode 335868802, moving to lost+found=0A= disconnected inode 335868803, moving to lost+found=0A= disconnected inode 335870575, moving to lost+found=0A= disconnected inode 336448622, moving to lost+found=0A= disconnected inode 336678470, moving to lost+found=0A= disconnected inode 336691195, moving to lost+found=0A= disconnected inode 336769515, moving to lost+found=0A= disconnected inode 336817491, moving to lost+found=0A= disconnected inode 336817492, moving to lost+found=0A= disconnected inode 336817493, moving to lost+found=0A= disconnected inode 336817495, moving to lost+found=0A= disconnected inode 336817496, moving to lost+found=0A= disconnected inode 336817497, moving to lost+found=0A= disconnected inode 336817498, moving to lost+found=0A= disconnected inode 336817499, moving to lost+found=0A= disconnected inode 336817500, moving to lost+found=0A= disconnected inode 336817501, moving to lost+found=0A= disconnected inode 336817502, moving to lost+found=0A= disconnected inode 336817503, moving to lost+found=0A= disconnected inode 336817504, moving to lost+found=0A= disconnected inode 336817505, moving to lost+found=0A= disconnected inode 336817506, moving to lost+found=0A= disconnected inode 336817507, moving to lost+found=0A= disconnected inode 336817508, moving to lost+found=0A= disconnected inode 336817509, moving to lost+found=0A= disconnected inode 336817510, moving to lost+found=0A= disconnected inode 336817511, moving to lost+found=0A= disconnected inode 336817513, moving to lost+found=0A= disconnected inode 337012609, moving to lost+found=0A= disconnected inode 337074977, moving to lost+found=0A= disconnected inode 337297511, moving to lost+found=0A= disconnected inode 337297512, moving to lost+found=0A= disconnected inode 337297516, moving to lost+found=0A= disconnected inode 337297518, moving to lost+found=0A= disconnected dir inode 338624502, moving to lost+found=0A= disconnected dir inode 339348710, moving to lost+found=0A= disconnected inode 339752439, moving to lost+found=0A= disconnected inode 339752440, moving to lost+found=0A= disconnected inode 339752441, moving to lost+found=0A= disconnected inode 339752442, moving to lost+found=0A= disconnected inode 339752443, moving to lost+found=0A= disconnected inode 339752445, moving to lost+found=0A= disconnected inode 339752832, moving to lost+found=0A= disconnected inode 339752836, moving to lost+found=0A= disconnected dir inode 339752858, moving to lost+found=0A= disconnected inode 339810510, moving to lost+found=0A= disconnected inode 339885184, moving to lost+found=0A= disconnected dir inode 340108086, moving to lost+found=0A= disconnected dir inode 340108087, moving to lost+found=0A= disconnected dir inode 340129251, moving to lost+found=0A= disconnected dir inode 352486520, moving to lost+found=0A= disconnected dir inode 353164585, moving to lost+found=0A= disconnected inode 353452711, moving to lost+found=0A= disconnected inode 354355872, moving to lost+found=0A= disconnected inode 354355873, moving to lost+found=0A= disconnected inode 354355874, moving to lost+found=0A= disconnected inode 354355876, moving to lost+found=0A= disconnected inode 354355877, moving to lost+found=0A= disconnected inode 354355878, moving to lost+found=0A= disconnected dir inode 355352876, moving to lost+found=0A= disconnected inode 356196893, moving to lost+found=0A= disconnected inode 356196894, moving to lost+found=0A= disconnected inode 356196895, moving to lost+found=0A= disconnected inode 356196896, moving to lost+found=0A= disconnected inode 356196897, moving to lost+found=0A= disconnected inode 356196898, moving to lost+found=0A= disconnected inode 356196899, moving to lost+found=0A= disconnected inode 356196900, moving to lost+found=0A= disconnected inode 356196901, moving to lost+found=0A= disconnected dir inode 356434361, moving to lost+found=0A= disconnected inode 356973448, moving to lost+found=0A= disconnected inode 356973449, moving to lost+found=0A= disconnected inode 356973450, moving to lost+found=0A= disconnected inode 356973451, moving to lost+found=0A= disconnected inode 356973452, moving to lost+found=0A= disconnected inode 356973453, moving to lost+found=0A= disconnected inode 356973454, moving to lost+found=0A= disconnected inode 356973455, moving to lost+found=0A= disconnected inode 356973456, moving to lost+found=0A= disconnected inode 356973457, moving to lost+found=0A= disconnected dir inode 357459689, moving to lost+found=0A= disconnected dir inode 369143683, moving to lost+found=0A= disconnected dir inode 369143687, moving to lost+found=0A= disconnected dir inode 369143688, moving to lost+found=0A= disconnected dir inode 369143692, moving to lost+found=0A= disconnected dir inode 369143693, moving to lost+found=0A= disconnected inode 369143694, moving to lost+found=0A= disconnected inode 369143695, moving to lost+found=0A= disconnected inode 369143706, moving to lost+found=0A= disconnected inode 369143707, moving to lost+found=0A= disconnected inode 369143710, moving to lost+found=0A= disconnected inode 369143713, moving to lost+found=0A= disconnected inode 369143718, moving to lost+found=0A= disconnected inode 369143719, moving to lost+found=0A= disconnected inode 369143730, moving to lost+found=0A= disconnected dir inode 369145007, moving to lost+found=0A= disconnected inode 369147906, moving to lost+found=0A= disconnected inode 369161689, moving to lost+found=0A= disconnected dir inode 369168279, moving to lost+found=0A= disconnected inode 369282340, moving to lost+found=0A= disconnected inode 369282358, moving to lost+found=0A= disconnected dir inode 369282359, moving to lost+found=0A= disconnected dir inode 369437605, moving to lost+found=0A= disconnected dir inode 370008038, moving to lost+found=0A= disconnected dir inode 372516811, moving to lost+found=0A= disconnected dir inode 373480910, moving to lost+found=0A= disconnected dir inode 373480920, moving to lost+found=0A= disconnected dir inode 373793134, moving to lost+found=0A= disconnected dir inode 373796366, moving to lost+found=0A= disconnected dir inode 386148184, moving to lost+found=0A= disconnected dir inode 386816708, moving to lost+found=0A= disconnected dir inode 386816732, moving to lost+found=0A= disconnected dir inode 386911201, moving to lost+found=0A= disconnected dir inode 387066241, moving to lost+found=0A= disconnected dir inode 387126502, moving to lost+found=0A= disconnected dir inode 389560204, moving to lost+found=0A= disconnected dir inode 390139336, moving to lost+found=0A= disconnected dir inode 390558373, moving to lost+found=0A= disconnected dir inode 390558378, moving to lost+found=0A= disconnected dir inode 402843956, moving to lost+found=0A= disconnected dir inode 402859367, moving to lost+found=0A= disconnected dir inode 402859391, moving to lost+found=0A= disconnected dir inode 403061767, moving to lost+found=0A= disconnected inode 403144027, moving to lost+found=0A= disconnected inode 403144030, moving to lost+found=0A= disconnected dir inode 403153590, moving to lost+found=0A= disconnected inode 403161486, moving to lost+found=0A= disconnected inode 403161492, moving to lost+found=0A= disconnected inode 403161498, moving to lost+found=0A= disconnected inode 403161499, moving to lost+found=0A= disconnected inode 403161500, moving to lost+found=0A= disconnected dir inode 403174421, moving to lost+found=0A= disconnected inode 403335104, moving to lost+found=0A= disconnected dir inode 403348193, moving to lost+found=0A= disconnected dir inode 403348196, moving to lost+found=0A= disconnected dir inode 403348197, moving to lost+found=0A= disconnected dir inode 403348198, moving to lost+found=0A= disconnected dir inode 403348206, moving to lost+found=0A= disconnected dir inode 403348212, moving to lost+found=0A= disconnected dir inode 403348215, moving to lost+found=0A= disconnected dir inode 403348221, moving to lost+found=0A= disconnected dir inode 403461440, moving to lost+found=0A= disconnected inode 403461455, moving to lost+found=0A= disconnected inode 403527712, moving to lost+found=0A= disconnected inode 403528351, moving to lost+found=0A= disconnected inode 403655015, moving to lost+found=0A= disconnected inode 403699788, moving to lost+found=0A= disconnected inode 403699794, moving to lost+found=0A= disconnected inode 403712424, moving to lost+found=0A= disconnected inode 403725298, moving to lost+found=0A= disconnected inode 403725299, moving to lost+found=0A= disconnected inode 403725302, moving to lost+found=0A= disconnected dir inode 405205761, moving to lost+found=0A= disconnected inode 405477783, moving to lost+found=0A= disconnected inode 405477784, moving to lost+found=0A= disconnected inode 405477785, moving to lost+found=0A= disconnected inode 405477786, moving to lost+found=0A= disconnected inode 405477787, moving to lost+found=0A= disconnected inode 405477788, moving to lost+found=0A= disconnected inode 405477789, moving to lost+found=0A= disconnected inode 405477790, moving to lost+found=0A= disconnected inode 405477791, moving to lost+found=0A= disconnected inode 405477792, moving to lost+found=0A= disconnected inode 405477793, moving to lost+found=0A= disconnected inode 405477794, moving to lost+found=0A= disconnected inode 405477795, moving to lost+found=0A= disconnected dir inode 406493346, moving to lost+found=0A= disconnected dir inode 406787711, moving to lost+found=0A= disconnected dir inode 407275043, moving to lost+found=0A= disconnected inode 419788525, moving to lost+found=0A= disconnected inode 419920378, moving to lost+found=0A= disconnected dir inode 419960957, moving to lost+found=0A= disconnected inode 420276608, moving to lost+found=0A= disconnected inode 420276609, moving to lost+found=0A= disconnected inode 420276610, moving to lost+found=0A= disconnected inode 420276611, moving to lost+found=0A= disconnected inode 420397930, moving to lost+found=0A= disconnected inode 420397931, moving to lost+found=0A= disconnected inode 420397932, moving to lost+found=0A= disconnected inode 420397933, moving to lost+found=0A= disconnected inode 420397934, moving to lost+found=0A= disconnected inode 420397935, moving to lost+found=0A= disconnected inode 420397936, moving to lost+found=0A= disconnected inode 420397937, moving to lost+found=0A= disconnected inode 420397938, moving to lost+found=0A= disconnected inode 420397939, moving to lost+found=0A= disconnected inode 420397941, moving to lost+found=0A= disconnected inode 420462939, moving to lost+found=0A= disconnected inode 420462940, moving to lost+found=0A= disconnected inode 420462941, moving to lost+found=0A= disconnected inode 420462942, moving to lost+found=0A= disconnected inode 420462943, moving to lost+found=0A= disconnected dir inode 420819012, moving to lost+found=0A= disconnected inode 421222107, moving to lost+found=0A= disconnected inode 421222108, moving to lost+found=0A= disconnected inode 421222109, moving to lost+found=0A= disconnected inode 421222110, moving to lost+found=0A= disconnected inode 421222111, moving to lost+found=0A= disconnected inode 421222112, moving to lost+found=0A= disconnected inode 421222113, moving to lost+found=0A= disconnected inode 421222114, moving to lost+found=0A= disconnected inode 421222115, moving to lost+found=0A= disconnected dir inode 421936866, moving to lost+found=0A= disconnected inode 421979303, moving to lost+found=0A= disconnected inode 421979304, moving to lost+found=0A= disconnected inode 421979306, moving to lost+found=0A= disconnected inode 421979307, moving to lost+found=0A= disconnected inode 421979308, moving to lost+found=0A= disconnected inode 421979309, moving to lost+found=0A= disconnected inode 421979310, moving to lost+found=0A= disconnected inode 421979311, moving to lost+found=0A= disconnected dir inode 423423777, moving to lost+found=0A= disconnected dir inode 423823890, moving to lost+found=0A= disconnected dir inode 436314658, moving to lost+found=0A= disconnected dir inode 436315254, moving to lost+found=0A= disconnected dir inode 436323580, moving to lost+found=0A= disconnected dir inode 436323607, moving to lost+found=0A= disconnected dir inode 436323612, moving to lost+found=0A= disconnected inode 436359330, moving to lost+found=0A= disconnected dir inode 436359352, moving to lost+found=0A= disconnected dir inode 436359353, moving to lost+found=0A= disconnected dir inode 436409278, moving to lost+found=0A= disconnected dir inode 436670294, moving to lost+found=0A= disconnected inode 437079528, moving to lost+found=0A= disconnected inode 437079531, moving to lost+found=0A= disconnected dir inode 437387707, moving to lost+found=0A= disconnected dir inode 438383537, moving to lost+found=0A= disconnected dir inode 438716196, moving to lost+found=0A= disconnected inode 438765490, moving to lost+found=0A= disconnected inode 438765492, moving to lost+found=0A= disconnected inode 439016162, moving to lost+found=0A= disconnected inode 439016165, moving to lost+found=0A= disconnected inode 439019873, moving to lost+found=0A= disconnected inode 439019877, moving to lost+found=0A= disconnected inode 439019880, moving to lost+found=0A= disconnected inode 439339988, moving to lost+found=0A= disconnected dir inode 440707936, moving to lost+found=0A= disconnected inode 453070916, moving to lost+found=0A= disconnected inode 453070917, moving to lost+found=0A= disconnected inode 453070933, moving to lost+found=0A= disconnected inode 453070934, moving to lost+found=0A= disconnected inode 453070939, moving to lost+found=0A= disconnected inode 453070940, moving to lost+found=0A= disconnected inode 453070942, moving to lost+found=0A= disconnected inode 453070943, moving to lost+found=0A= disconnected inode 453070944, moving to lost+found=0A= disconnected inode 453070945, moving to lost+found=0A= disconnected inode 453070947, moving to lost+found=0A= disconnected inode 453070948, moving to lost+found=0A= disconnected inode 453070949, moving to lost+found=0A= disconnected inode 453070950, moving to lost+found=0A= disconnected inode 453070951, moving to lost+found=0A= disconnected inode 453070953, moving to lost+found=0A= disconnected inode 453070954, moving to lost+found=0A= disconnected inode 453070955, moving to lost+found=0A= disconnected inode 453070956, moving to lost+found=0A= disconnected inode 453070957, moving to lost+found=0A= disconnected inode 453070958, moving to lost+found=0A= disconnected inode 453070959, moving to lost+found=0A= disconnected inode 453070960, moving to lost+found=0A= disconnected inode 453070961, moving to lost+found=0A= disconnected inode 453070962, moving to lost+found=0A= disconnected inode 453070963, moving to lost+found=0A= disconnected inode 453070964, moving to lost+found=0A= disconnected inode 453070965, moving to lost+found=0A= disconnected inode 453070966, moving to lost+found=0A= disconnected inode 453070967, moving to lost+found=0A= disconnected inode 453070968, moving to lost+found=0A= disconnected inode 453070969, moving to lost+found=0A= disconnected inode 453070970, moving to lost+found=0A= disconnected inode 453070971, moving to lost+found=0A= disconnected inode 453070972, moving to lost+found=0A= disconnected inode 453070974, moving to lost+found=0A= disconnected inode 453070975, moving to lost+found=0A= disconnected inode 453086754, moving to lost+found=0A= disconnected inode 453086755, moving to lost+found=0A= disconnected inode 453086756, moving to lost+found=0A= disconnected inode 453086757, moving to lost+found=0A= disconnected inode 453086758, moving to lost+found=0A= disconnected inode 453086759, moving to lost+found=0A= disconnected inode 453086760, moving to lost+found=0A= disconnected inode 453086761, moving to lost+found=0A= disconnected inode 453086762, moving to lost+found=0A= disconnected inode 453086763, moving to lost+found=0A= disconnected inode 453086765, moving to lost+found=0A= disconnected inode 453086767, moving to lost+found=0A= disconnected inode 453086768, moving to lost+found=0A= disconnected inode 453086770, moving to lost+found=0A= disconnected inode 453086774, moving to lost+found=0A= disconnected inode 453086775, moving to lost+found=0A= disconnected inode 453086776, moving to lost+found=0A= disconnected inode 453086779, moving to lost+found=0A= disconnected inode 453086781, moving to lost+found=0A= disconnected inode 453086785, moving to lost+found=0A= disconnected inode 453086790, moving to lost+found=0A= disconnected inode 453086794, moving to lost+found=0A= disconnected inode 453086795, moving to lost+found=0A= disconnected inode 453086796, moving to lost+found=0A= disconnected inode 453086797, moving to lost+found=0A= disconnected inode 453086798, moving to lost+found=0A= disconnected inode 453086799, moving to lost+found=0A= disconnected inode 453086802, moving to lost+found=0A= disconnected inode 453086807, moving to lost+found=0A= disconnected inode 453086808, moving to lost+found=0A= disconnected inode 453086810, moving to lost+found=0A= disconnected inode 453086811, moving to lost+found=0A= disconnected inode 453086812, moving to lost+found=0A= disconnected inode 453086813, moving to lost+found=0A= disconnected inode 453086814, moving to lost+found=0A= disconnected inode 453086815, moving to lost+found=0A= disconnected inode 453089984, moving to lost+found=0A= disconnected inode 453089985, moving to lost+found=0A= disconnected inode 453089986, moving to lost+found=0A= disconnected inode 453089987, moving to lost+found=0A= disconnected inode 453089991, moving to lost+found=0A= disconnected inode 453089992, moving to lost+found=0A= disconnected inode 453089995, moving to lost+found=0A= disconnected inode 453089996, moving to lost+found=0A= disconnected inode 453089997, moving to lost+found=0A= disconnected inode 453090001, moving to lost+found=0A= disconnected inode 453090002, moving to lost+found=0A= disconnected inode 453090003, moving to lost+found=0A= disconnected inode 453090004, moving to lost+found=0A= disconnected inode 453090005, moving to lost+found=0A= disconnected inode 453090006, moving to lost+found=0A= disconnected inode 453090007, moving to lost+found=0A= disconnected dir inode 453314848, moving to lost+found=0A= disconnected dir inode 453693751, moving to lost+found=0A= disconnected dir inode 454285346, moving to lost+found=0A= disconnected inode 455005965, moving to lost+found=0A= disconnected inode 455005987, moving to lost+found=0A= disconnected inode 455005994, moving to lost+found=0A= disconnected inode 455006023, moving to lost+found=0A= disconnected inode 455006028, moving to lost+found=0A= disconnected inode 455009504, moving to lost+found=0A= disconnected inode 455009507, moving to lost+found=0A= disconnected inode 455009508, moving to lost+found=0A= disconnected inode 455009509, moving to lost+found=0A= disconnected inode 455009510, moving to lost+found=0A= disconnected inode 455009511, moving to lost+found=0A= disconnected inode 455009517, moving to lost+found=0A= disconnected inode 455009518, moving to lost+found=0A= disconnected inode 455009519, moving to lost+found=0A= disconnected inode 455009520, moving to lost+found=0A= disconnected inode 455009521, moving to lost+found=0A= disconnected inode 455009522, moving to lost+found=0A= disconnected inode 455009523, moving to lost+found=0A= disconnected inode 455009524, moving to lost+found=0A= disconnected inode 455009525, moving to lost+found=0A= disconnected inode 455009526, moving to lost+found=0A= disconnected inode 455009527, moving to lost+found=0A= disconnected inode 455009528, moving to lost+found=0A= disconnected inode 455009529, moving to lost+found=0A= disconnected inode 455009552, moving to lost+found=0A= disconnected inode 455009553, moving to lost+found=0A= disconnected inode 455022677, moving to lost+found=0A= disconnected inode 455022682, moving to lost+found=0A= disconnected inode 455040682, moving to lost+found=0A= disconnected inode 455040688, moving to lost+found=0A= disconnected dir inode 455717914, moving to lost+found=0A= disconnected inode 458222100, moving to lost+found=0A= disconnected inode 458222107, moving to lost+found=0A= disconnected inode 458222108, moving to lost+found=0A= disconnected inode 458222109, moving to lost+found=0A= disconnected inode 458222984, moving to lost+found=0A= disconnected inode 458222989, moving to lost+found=0A= disconnected inode 458222990, moving to lost+found=0A= disconnected inode 458222991, moving to lost+found=0A= disconnected inode 458222993, moving to lost+found=0A= disconnected inode 458222997, moving to lost+found=0A= disconnected inode 458222998, moving to lost+found=0A= disconnected inode 458223000, moving to lost+found=0A= disconnected inode 458223001, moving to lost+found=0A= disconnected inode 458223009, moving to lost+found=0A= disconnected inode 458223010, moving to lost+found=0A= disconnected inode 458223011, moving to lost+found=0A= disconnected inode 458223047, moving to lost+found=0A= disconnected inode 458223056, moving to lost+found=0A= disconnected inode 458223067, moving to lost+found=0A= disconnected inode 458223188, moving to lost+found=0A= disconnected inode 458223189, moving to lost+found=0A= disconnected inode 458223190, moving to lost+found=0A= disconnected inode 458223191, moving to lost+found=0A= disconnected inode 458223192, moving to lost+found=0A= disconnected inode 458223193, moving to lost+found=0A= disconnected inode 458223194, moving to lost+found=0A= disconnected inode 458408687, moving to lost+found=0A= disconnected inode 458408688, moving to lost+found=0A= disconnected inode 458408689, moving to lost+found=0A= disconnected inode 458408690, moving to lost+found=0A= disconnected inode 458408691, moving to lost+found=0A= disconnected inode 458408692, moving to lost+found=0A= disconnected inode 458408693, moving to lost+found=0A= disconnected dir inode 469902403, moving to lost+found=0A= disconnected inode 469910526, moving to lost+found=0A= disconnected inode 469910527, moving to lost+found=0A= disconnected inode 469910528, moving to lost+found=0A= disconnected inode 469910529, moving to lost+found=0A= disconnected inode 469910530, moving to lost+found=0A= disconnected inode 469910531, moving to lost+found=0A= disconnected inode 469910533, moving to lost+found=0A= disconnected inode 469910534, moving to lost+found=0A= disconnected inode 469910535, moving to lost+found=0A= disconnected inode 469910536, moving to lost+found=0A= disconnected inode 469910537, moving to lost+found=0A= disconnected inode 469910538, moving to lost+found=0A= disconnected inode 469910539, moving to lost+found=0A= disconnected inode 469910540, moving to lost+found=0A= disconnected inode 469910541, moving to lost+found=0A= disconnected inode 469910542, moving to lost+found=0A= disconnected dir inode 469935756, moving to lost+found=0A= disconnected dir inode 470210904, moving to lost+found=0A= disconnected inode 470320718, moving to lost+found=0A= disconnected inode 470720816, moving to lost+found=0A= disconnected dir inode 472147687, moving to lost+found=0A= disconnected dir inode 473012315, moving to lost+found=0A= disconnected dir inode 486627204, moving to lost+found=0A= disconnected dir inode 486742075, moving to lost+found=0A= disconnected inode 486753286, moving to lost+found=0A= disconnected dir inode 487185484, moving to lost+found=0A= disconnected inode 487421386, moving to lost+found=0A= disconnected inode 488566434, moving to lost+found=0A= disconnected dir inode 489361505, moving to lost+found=0A= disconnected inode 489372900, moving to lost+found=0A= disconnected inode 489372903, moving to lost+found=0A= disconnected inode 489550850, moving to lost+found=0A= disconnected inode 489550851, moving to lost+found=0A= disconnected inode 489550852, moving to lost+found=0A= disconnected inode 489550853, moving to lost+found=0A= disconnected inode 489550854, moving to lost+found=0A= disconnected inode 489550855, moving to lost+found=0A= disconnected inode 489550856, moving to lost+found=0A= disconnected inode 489607218, moving to lost+found=0A= disconnected inode 489643094, moving to lost+found=0A= disconnected inode 489650727, moving to lost+found=0A= disconnected inode 490332477, moving to lost+found=0A= disconnected inode 490349899, moving to lost+found=0A= disconnected inode 490390739, moving to lost+found=0A= disconnected inode 490609058, moving to lost+found=0A= disconnected inode 491489139, moving to lost+found=0A= disconnected inode 491489140, moving to lost+found=0A= disconnected inode 491489141, moving to lost+found=0A= disconnected inode 491489142, moving to lost+found=0A= disconnected inode 491489143, moving to lost+found=0A= disconnected inode 491489145, moving to lost+found=0A= disconnected inode 491489146, moving to lost+found=0A= disconnected inode 491489147, moving to lost+found=0A= disconnected inode 491489148, moving to lost+found=0A= disconnected inode 491489149, moving to lost+found=0A= disconnected inode 491489150, moving to lost+found=0A= disconnected inode 491489151, moving to lost+found=0A= disconnected inode 491505571, moving to lost+found=0A= disconnected inode 491505572, moving to lost+found=0A= disconnected inode 491505573, moving to lost+found=0A= disconnected inode 491505574, moving to lost+found=0A= disconnected inode 491505575, moving to lost+found=0A= disconnected inode 491505576, moving to lost+found=0A= disconnected inode 491505578, moving to lost+found=0A= disconnected inode 491537014, moving to lost+found=0A= disconnected inode 491584950, moving to lost+found=0A= disconnected inode 492027426, moving to lost+found=0A= disconnected dir inode 503457840, moving to lost+found=0A= disconnected dir inode 503521943, moving to lost+found=0A= disconnected inode 504294352, moving to lost+found=0A= disconnected inode 504294353, moving to lost+found=0A= disconnected inode 504294354, moving to lost+found=0A= disconnected inode 504294355, moving to lost+found=0A= disconnected dir inode 505436977, moving to lost+found=0A= disconnected inode 505723294, moving to lost+found=0A= disconnected inode 506106496, moving to lost+found=0A= disconnected dir inode 506147367, moving to lost+found=0A= disconnected inode 506183468, moving to lost+found=0A= disconnected dir inode 507365528, moving to lost+found=0A= disconnected dir inode 507378378, moving to lost+found=0A= Phase 7 - verify and correct link counts...=0A= resetting inode 33928488 nlinks from 3 to 2=0A= resetting inode 54008755 nlinks from 6 to 5=0A= resetting inode 68390570 nlinks from 3 to 2=0A= =0A= fatal error -- couldn't map inode 70234622, err =3D 990=0A= ------=_NextPart_000_0123_01C20D75.D7DA7C30-- From owner-linux-xfs@oss.sgi.com Thu Jun 6 06:42:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56DgFnC018297 for ; Thu, 6 Jun 2002 06:42:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56DgFPu018296 for linux-xfs-outgoing; Thu, 6 Jun 2002 06:42:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hotmail.com (f31.law12.hotmail.com [64.4.19.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56DgBnC018266 for ; Thu, 6 Jun 2002 06:42:11 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Jun 2002 06:44:08 -0700 Received: from 217.81.38.77 by lw12fd.law12.hotmail.msn.com with HTTP; Thu, 06 Jun 2002 13:44:08 GMT X-Originating-IP: [217.81.38.77] From: "Karl Ran" To: lord@sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: xfs_check reports errors or warnings? Date: Thu, 06 Jun 2002 13:44:08 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Jun 2002 13:44:08.0703 (UTC) FILETIME=[3B8EC8F0:01C20D60] X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >If that was all the output then I doubt you have reason to >be worried. Thanks for the quick help. Karl PS: Keep up the good work! I realy like it _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx From owner-linux-xfs@oss.sgi.com Thu Jun 6 07:11:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56EBgnC023376 for ; Thu, 6 Jun 2002 07:11:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56EBgtL023375 for linux-xfs-outgoing; Thu, 6 Jun 2002 07:11:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56EBanC023344 for ; Thu, 6 Jun 2002 07:11:37 -0700 Received: from fwd06.sul.t-online.de by mailout07.sul.t-online.com with smtp id 17Fy1A-0008Au-07; Thu, 06 Jun 2002 16:13:36 +0200 Received: from horus.xgm.de (340060635977-0001@[80.129.13.14]) by fmrl06.sul.t-online.com with esmtp id 17Fy0w-1VgB1MC; Thu, 6 Jun 2002 16:13:22 +0200 Received: from florian (unknown [192.168.0.2]) by horus.xgm.de (Postfix) with SMTP id 0C4A8C5 for ; Thu, 6 Jun 2002 16:11:22 +0200 (CEST) Message-ID: <001a01c20d64$ce38e100$0200a8c0@florian> From: "Florian Lindner" To: Subject: Tutorial to ACL and XFS handling Date: Thu, 6 Jun 2002 16:16:52 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 340060635977-0001@t-dialin.net X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I'm looking for tutorial for ACLs generell und especially how XFS handles them. I'm not interessted in how the implementiation is done, but I want to know from a users point of view. (tool for managing ACLs, ....). Language English or German. Thx, Florian [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jun 6 07:25:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56EPjnC024430 for ; Thu, 6 Jun 2002 07:25:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56EPjCf024429 for linux-xfs-outgoing; Thu, 6 Jun 2002 07:25:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fileserver.kancelar.seznam.cz (ns.seznam.cz [212.80.76.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56EPcnC024398 for ; Thu, 6 Jun 2002 07:25:39 -0700 Received: from lotus.kancelar.seznam.cz (lotus.kancelar.seznam.cz [192.168.7.24]) by fileserver.kancelar.seznam.cz (8.11.4/8.11.3) with ESMTP id g56ESsL20191 for ; Thu, 6 Jun 2002 16:28:54 +0200 (CEST) (envelope-from Marek.Les@firma.seznam.cz) Subject: mkfs - cannot set blocksize To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Marek.Les@firma.seznam.cz Date: Thu, 6 Jun 2002 16:27:26 +0200 X-MIMETrack: Serialize by Router on Lotus/Seznam(Release 5.0.8 |June 18, 2001) at 06/06/2002 04:27:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I am trying to test XFS with LVM and I've encountered this error while trying to do mkfs.xfs on the LVM logical volume: mkfs.xfs: warning - cannot set blocksize on block device /dev/test_vg/test_lv: Invalid argument I tried to find something in the mailing list but the only thing I found was something about EVMS but no LVM stuff. Can anyone tell me, what exactly this warning means and (if possible) how to get rid of it? I am running XFS 1.1 on 2.4.18 kernel with xfsprogs 2.0.3 and LVM version 1.1-rc2. Thanks in advance. Marek Les From owner-linux-xfs@oss.sgi.com Thu Jun 6 07:31:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56EVBnC024701 for ; Thu, 6 Jun 2002 07:31:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56EVBcm024700 for linux-xfs-outgoing; Thu, 6 Jun 2002 07:31:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56EV5nC024666 for ; Thu, 6 Jun 2002 07:31:05 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA84385; Thu, 6 Jun 2002 09:33:02 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA76904; Thu, 6 Jun 2002 09:33:01 -0500 (CDT) Subject: Re: mkfs - cannot set blocksize From: Eric Sandeen To: Marek.Les@firma.seznam.cz Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Jun 2002 09:31:02 -0500 Message-Id: <1023373862.5878.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi - This is because apparently LVM still does not honor the BLKBSZSET ioctl, I think this is harmless at this point, however. If mkfs completes without any other errors, you should be ok. -Eric On Thu, 2002-06-06 at 09:27, Marek.Les@firma.seznam.cz wrote: > Hello, > > I am trying to test XFS with LVM and I've encountered this error while > trying to do mkfs.xfs on the LVM logical volume: > > mkfs.xfs: warning - cannot set blocksize on block device > /dev/test_vg/test_lv: Invalid argument > > I tried to find something in the mailing list but the only thing I found > was something about EVMS but no LVM stuff. Can anyone tell me, what exactly > this warning means and (if possible) how to get rid of it? > > I am running XFS 1.1 on 2.4.18 kernel with xfsprogs 2.0.3 and LVM version > 1.1-rc2. > > Thanks in advance. > > Marek Les From owner-linux-xfs@oss.sgi.com Thu Jun 6 07:53:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56ErNnC025159 for ; Thu, 6 Jun 2002 07:53:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56ErNmC025157 for linux-xfs-outgoing; Thu, 6 Jun 2002 07:53:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf00bis.bellsouth.net (mail000.mail.bellsouth.net [205.152.58.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56ErGnC025082 for ; Thu, 6 Jun 2002 07:53:16 -0700 Received: from taz ([66.156.1.210]) by imf00bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020606145640.YAL1202.imf00bis.bellsouth.net@taz>; Thu, 6 Jun 2002 10:56:40 -0400 Date: Thu, 6 Jun 2002 10:44:03 -0400 From: Greg Freemyer Subject: re: mkfs - cannot set blocksize To: , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020606145640.YAL1202.imf00bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g56ErGnC025110 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Before chasing this down to far, you might want to read the thread ending at http://marc.theaimsgroup.com/?l=linux-xfs&m=102276577224994&w=2 >> Hello, >> I am trying to test XFS with LVM and I've encountered this error while >> trying to do mkfs.xfs on the LVM logical volume: >> mkfs.xfs: warning - cannot set blocksize on block device >> /dev/test_vg/test_lv: Invalid argument >> I tried to find something in the mailing list but the only thing I found >> was something about EVMS but no LVM stuff. Can anyone tell me, what >> exactly >> this warning means and (if possible) how to get rid of it? >> I am running XFS 1.1 on 2.4.18 kernel with xfsprogs 2.0.3 and LVM version >> 1.1-rc2. >> Thanks in advance. >> Marek Les Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Thu Jun 6 07:53:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56ErJnC025138 for ; Thu, 6 Jun 2002 07:53:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56ErIFk025134 for linux-xfs-outgoing; Thu, 6 Jun 2002 07:53:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56ErAnC025081 for ; Thu, 6 Jun 2002 07:53:11 -0700 Received: from mail.pronto.tv ([62.70.58.70]) 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 HAA07121 for ; Thu, 6 Jun 2002 07:55:18 -0700 (PDT) mail_from (roy@mail.pronto.tv) Received: from localhost (localhost [[UNIX: localhost]]) by mail.pronto.tv (8.11.6/8.11.6) id g56EZpl28164; Thu, 6 Jun 2002 16:35:51 +0200 Message-Id: <200206061435.g56EZpl28164@mail.pronto.tv> Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: Pronto TV AS To: Marek.Les@firma.seznam.cz, linux-xfs@oss.sgi.com Subject: Re: mkfs - cannot set blocksize Date: Thu, 6 Jun 2002 16:35:51 +0200 X-Mailer: KMail [version 1.3.1] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g56ErBnC025083 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk linux ia32 only supports 4kB block size On Thursday 06 June 2002 16:27, Marek.Les@firma.seznam.cz wrote: > Hello, > > I am trying to test XFS with LVM and I've encountered this error while > trying to do mkfs.xfs on the LVM logical volume: > > mkfs.xfs: warning - cannot set blocksize on block device > /dev/test_vg/test_lv: Invalid argument > > I tried to find something in the mailing list but the only thing I found > was something about EVMS but no LVM stuff. Can anyone tell me, what exactly > this warning means and (if possible) how to get rid of it? > > I am running XFS 1.1 on 2.4.18 kernel with xfsprogs 2.0.3 and LVM version > 1.1-rc2. > > Thanks in advance. > > Marek Les -- Roy Sigurd Karlsbakk, Datavaktmester Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Thu Jun 6 08:47:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56FlqnC026409 for ; Thu, 6 Jun 2002 08:47:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56Flqw9026408 for linux-xfs-outgoing; Thu, 6 Jun 2002 08:47:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fileserver.kancelar.seznam.cz (ns.seznam.cz [212.80.76.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56FlinC026328 for ; Thu, 6 Jun 2002 08:47:45 -0700 Received: from lotus.kancelar.seznam.cz (lotus.kancelar.seznam.cz [192.168.7.24]) by fileserver.kancelar.seznam.cz (8.11.4/8.11.3) with ESMTP id g56Fp0L22725 for ; Thu, 6 Jun 2002 17:51:00 +0200 (CEST) (envelope-from Marek.Les@firma.seznam.cz) Subject: enterprise-level experience To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Marek.Les@firma.seznam.cz Date: Thu, 6 Jun 2002 17:49:28 +0200 X-MIMETrack: Serialize by Router on Lotus/Seznam(Release 5.0.8 |June 18, 2001) at 06/06/2002 05:49:40 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, Our company is in the process of moving the production server data on a enterprise storage servers and therefore we are considering which setup would have the best performance and stability at the same time. Our preliminary tests showed us that, at the filesystem level, XFS performs best. Unfortunately, to be capable of growing the volumes we need to add another layer - the volume manager. This increases the chances for something to go wrong. As I've read through the mailing list and other sources, there are only two possible software packages on Linux - LVM and EVMS. From what I've read I understood that LVM 1.x is feature-frozen and maybe even bugsolve-frozen in favor of LVM2 development (see the deadlock while using xfs_freeze issue). LVM 2.x is unstable beta and EVMS is so fresh that no real experience has been heard of. I understand that there's no bug-free software and no guarantee of anything but maybe some of you have some enterprise-level experience with, say, 2+ TB data pool on XFS and some volume manager. I appreciate any reference of any kind, some known imcompatibilies, what mistakes to avoid.. it would help me a lot. With best regards, Marek Les Seznam.cz Note: If you don't want to discuss this theme in public, please don't hesitate to write me directly :-) From owner-linux-xfs@oss.sgi.com Thu Jun 6 08:46:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56FkMnC026250 for ; Thu, 6 Jun 2002 08:46:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56FkMmq026249 for linux-xfs-outgoing; Thu, 6 Jun 2002 08:46:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56FkDnC026220 for ; Thu, 6 Jun 2002 08:46:13 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA83813; Thu, 6 Jun 2002 10:48:09 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA09666; Thu, 6 Jun 2002 10:48:09 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA52876; Thu, 6 Jun 2002 10:48:08 -0500 (CDT) Message-Id: <200206061548.KAA52876@slobber.americas.sgi.com> To: "James A Goodwin" , "Francis Qu" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region Date: Thu, 06 Jun 2002 10:48:07 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" >I'm running XFS 1.0.2 on kernel 2.4.14 and am having the following DMAPI >problem: > >dm_get_fileattr() hangs when an append is in progress. > >I have a file with a DMAPI region covering whole file (offset & length both >set to 0). >The region has read, write, and truncate events enabled. >When an append is done and the write event is received, a subsequent call >to dm_get_fileattr() hangs. > >Is this something that has been fixed in a later patch, or is it new? Francis, you reported seeing this via dm_set_region. It's all the same. The user process had an exclusive lock on the xfs_inode_t, preventing DMAPI from doing anything with it. Here's a patch for it. Dean ----------- *** /usr/tmp/TmpDir.2091635-0/linux/fs/xfs/linux/xfs_lrw.c_1.140 Thu Jun 6 10:42:48 2002 --- linux/fs/xfs/linux/xfs_lrw.c Wed Jun 5 14:55:58 2002 *************** *** 531,543 **** if ((DM_EVENT_ENABLED_IO(vp->v_vfsp, io, DM_EVENT_WRITE) && !(filp->f_mode & FINVIS) && !eventsent)) { error = xfs_dm_send_data_event(DM_EVENT_WRITE, bdp, *offsetp, size, FILP_DELAY_FLAG(filp), &locktype); if (error) { ! xfs_iunlock(xip, XFS_ILOCK_EXCL|iolock); return error; } eventsent = 1; /* --- 531,545 ---- if ((DM_EVENT_ENABLED_IO(vp->v_vfsp, io, DM_EVENT_WRITE) && !(filp->f_mode & FINVIS) && !eventsent)) { + xfs_iunlock(xip, XFS_ILOCK_EXCL); error = xfs_dm_send_data_event(DM_EVENT_WRITE, bdp, *offsetp, size, FILP_DELAY_FLAG(filp), &locktype); if (error) { ! xfs_iunlock(xip, iolock); return error; } + xfs_ilock(xip, XFS_ILOCK_EXCL); eventsent = 1; /* From owner-linux-xfs@oss.sgi.com Thu Jun 6 08:46:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56Fk2nC026211 for ; Thu, 6 Jun 2002 08:46:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56Fk2OU026210 for linux-xfs-outgoing; Thu, 6 Jun 2002 08:46:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56FjtnC026181 for ; Thu, 6 Jun 2002 08:45:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA84548 for ; Thu, 6 Jun 2002 10:47:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA48173 for ; Thu, 6 Jun 2002 10:47:52 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g56FhS213831; Thu, 6 Jun 2002 10:43:28 -0500 Message-Id: <200206061543.g56FhS213831@jen.americas.sgi.com> Date: Thu, 6 Jun 2002 10:43:28 -0500 Subject: TAKE - rename cleanups To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Kill some more code, thanks to Christoph Hellwig again. Date: Thu Jun 6 08:46:50 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121001a linux/fs/xfs/xfs_utils.h - 1.18 - remove references to pathname linux/fs/xfs/xfs_rename.c - 1.36 - no pathname parameter on rename, cleanup rename checks to avoid duplication with the vfs. linux/fs/xfs/linux/xfs_linux.h - 1.69 - remove definition of pathname_t linux/fs/xfs/linux/xfs_iops.c - 1.149 - Remove pathname from rename VOP - not used linux/fs/xfs/linux/xfs_vnode.h - 1.36 - remove pathname from rename VOP From owner-linux-xfs@oss.sgi.com Thu Jun 6 09:05:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56G5QnC006104 for ; Thu, 6 Jun 2002 09:05:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56G5P3q006103 for linux-xfs-outgoing; Thu, 6 Jun 2002 09:05:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56G5KnC006075 for ; Thu, 6 Jun 2002 09:05:21 -0700 Received: from fwd05.sul.t-online.de by mailout01.sul.t-online.com with smtp id 17FwWN-0005b7-0S; Thu, 06 Jun 2002 14:37:43 +0200 Received: from horus.xgm.de (340060635977-0001@[80.129.13.14]) by fmrl05.sul.t-online.com with esmtp id 17FwWJ-0xDHxgC; Thu, 6 Jun 2002 14:37:39 +0200 Received: from florian (unknown [192.168.0.2]) by horus.xgm.de (Postfix) with SMTP id 87D4DED for ; Thu, 6 Jun 2002 14:35:40 +0200 (CEST) Message-ID: <000d01c20d57$6f7b1b90$0200a8c0@florian> From: "Florian Lindner" To: Subject: Tutorial to ACLs and XFS handling Date: Thu, 6 Jun 2002 14:41:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 340060635977-0001@t-dialin.net X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I'm looking for tutorial for ACLs generell und especially how XFS handles them. I'm not interessted in how the implementiation is done, but I want to know from a users point of view. (tool for managing ACLs, ....). Language English or German. Thx, Florian From owner-linux-xfs@oss.sgi.com Thu Jun 6 09:15:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56GF4nC006357 for ; Thu, 6 Jun 2002 09:15:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56GF49Q006356 for linux-xfs-outgoing; Thu, 6 Jun 2002 09:15:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56GEwnC006318 for ; Thu, 6 Jun 2002 09:14:58 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA85144; Thu, 6 Jun 2002 11:16:55 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA92061; Thu, 6 Jun 2002 11:16:54 -0500 (CDT) Subject: Re: Tutorial to ACLs and XFS handling From: Eric Sandeen To: Florian Lindner Cc: linux-xfs@oss.sgi.com In-Reply-To: <000d01c20d57$6f7b1b90$0200a8c0@florian> References: <000d01c20d57$6f7b1b90$0200a8c0@florian> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 06 Jun 2002 11:14:55 -0500 Message-Id: <1023380095.5878.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florian - Have you looked at http://acl.bestbits.at/? Not xfs-specific, but: What are extended attributes? What are access control lists? Using extended attributes and access control lists Frequently asked questions etc. -Eric On Thu, 2002-06-06 at 07:41, Florian Lindner wrote: > Hello, > I'm looking for tutorial for ACLs generell und especially how XFS handles > them. I'm not interessted in how the implementiation is done, but I want to > know from a users point of view. (tool for managing ACLs, ....). > Language English or German. > Thx, > Florian From owner-linux-xfs@oss.sgi.com Thu Jun 6 09:56:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56GuxnC006790 for ; Thu, 6 Jun 2002 09:56:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56Guxt3006789 for linux-xfs-outgoing; Thu, 6 Jun 2002 09:56:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56GuhnC006761 for ; Thu, 6 Jun 2002 09:56:43 -0700 Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g56GwLg5210708; Thu, 6 Jun 2002 12:58:23 -0400 Received: from d03nm800.boulder.ibm.com (d03nm800.boulder.ibm.com [9.17.194.116]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g56GwKX36200; Thu, 6 Jun 2002 10:58:20 -0600 Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region To: Dean Roehrich Cc: "Francis Qu" , linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Thu, 6 Jun 2002 11:58:16 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 06/06/2002 10:58:20 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean, Thanks for the patch. It gets us past the problem with dm_get_fileattr(). However, later in the same function (called when the write event was received), my process hangs on dm_set_region() for the same file. Is this perhaps a similar problem with a similar fix? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich > cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region 06/06/2002 10:48 AM >From: "James A Goodwin" >I'm running XFS 1.0.2 on kernel 2.4.14 and am having the following DMAPI >problem: > >dm_get_fileattr() hangs when an append is in progress. > >I have a file with a DMAPI region covering whole file (offset & length both >set to 0). >The region has read, write, and truncate events enabled. >When an append is done and the write event is received, a subsequent call >to dm_get_fileattr() hangs. > >Is this something that has been fixed in a later patch, or is it new? Francis, you reported seeing this via dm_set_region. It's all the same. The user process had an exclusive lock on the xfs_inode_t, preventing DMAPI from doing anything with it. Here's a patch for it. Dean ----------- *** /usr/tmp/TmpDir.2091635-0/linux/fs/xfs/linux/xfs_lrw.c_1.140 Thu Jun 6 10:42:48 2002 --- linux/fs/xfs/linux/xfs_lrw.c Wed Jun 5 14:55:58 2002 *************** *** 531,543 **** if ((DM_EVENT_ENABLED_IO(vp->v_vfsp, io, DM_EVENT_WRITE) && !(filp->f_mode & FINVIS) && !eventsent)) { error = xfs_dm_send_data_event(DM_EVENT_WRITE, bdp, *offsetp, size, FILP_DELAY_FLAG(filp), &locktype); if (error) { ! xfs_iunlock(xip, XFS_ILOCK_EXCL|iolock); return error; } eventsent = 1; /* --- 531,545 ---- if ((DM_EVENT_ENABLED_IO(vp->v_vfsp, io, DM_EVENT_WRITE) && !(filp->f_mode & FINVIS) && !eventsent)) { + xfs_iunlock(xip, XFS_ILOCK_EXCL); error = xfs_dm_send_data_event(DM_EVENT_WRITE, bdp, *offsetp, size, FILP_DELAY_FLAG(filp), &locktype); if (error) { ! xfs_iunlock(xip, iolock); return error; } + xfs_ilock(xip, XFS_ILOCK_EXCL); eventsent = 1; /* From owner-linux-xfs@oss.sgi.com Thu Jun 6 10:35:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56HZHnC007317 for ; Thu, 6 Jun 2002 10:35:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56HZHO4007316 for linux-xfs-outgoing; Thu, 6 Jun 2002 10:35:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56HZCnC007288 for ; Thu, 6 Jun 2002 10:35:12 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id KAA09419 for ; Thu, 6 Jun 2002 10:37:14 -0700 (PDT) mail_from (florin@sgi.com) Received: from stantz.corp.sgi.com (stantz.corp.sgi.com [130.62.4.42]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id KAA37649 for ; Thu, 6 Jun 2002 10:36:43 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 97C8B136420 for ; Thu, 6 Jun 2002 10:36:43 -0700 (PDT) Subject: Re: RAID Controller Caching and XFS From: Florin Andrei To: linux-xfs In-Reply-To: <20020606145120.C25038@de.tecosim.com> References: <1023314217.32329.32.camel@stantz.corp.sgi.com> <4.3.2.7.2.20020603111517.03b4e1b0@pop.xs4all.nl> <20020605160422.A14886@pla-muek.reefedge.com> <1023314217.32329.32.camel@stantz.corp.sgi.com> <2 <20020606145120.C25038@de.tecosim.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 06 Jun 2002 10:36:43 -0700 Message-Id: <1023385003.14510.11.camel@stantz.corp.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-06 at 05:51, Utz Lehmann wrote: > > He sad, that the controller don't have a battery, look above. So it's the > same, a poweroutage cause lost of all unwritten data in the controller > cache. Yup, no battery here. -- Florin Andrei "You can get excited about just any subject if you study it enough. It's the deep knowledge that makes a topic interesting." - Larry McVoy From owner-linux-xfs@oss.sgi.com Thu Jun 6 10:56:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56HuQnC021600 for ; Thu, 6 Jun 2002 10:56:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56HuQ06021599 for linux-xfs-outgoing; Thu, 6 Jun 2002 10:56:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56Hu5nC021569 for ; Thu, 6 Jun 2002 10:56:06 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 54075C222; Thu, 6 Jun 2002 19:33:06 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id TAA08165; Thu, 6 Jun 2002 19:33:05 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 8B38257306; Thu, 6 Jun 2002 19:32:54 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id DB55125835; Thu, 6 Jun 2002 19:32:53 +0200 (CEST) Message-ID: <3CFF9CC5.7DBD4957@ch.sauter-bc.com> Date: Thu, 06 Jun 2002 19:32:53 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Marek.Les@firma.seznam.cz Cc: linux-xfs@oss.sgi.com Subject: Re: enterprise-level experience References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Marek.Les@firma.seznam.cz schrieb: > > Hi there, > > Our company is in the process of moving the production server data on a > enterprise storage servers and therefore we are considering which setup > would have the best performance and stability at the same time. Our > preliminary tests showed us that, at the filesystem level, XFS performs > best. Unfortunately, to be capable of growing the volumes we need to add > another layer - the volume manager. This increases the chances for > something to go wrong. > As I've read through the mailing list and other sources, there are only two > possible software packages on Linux - LVM and EVMS. From what I've read I > understood that LVM 1.x is feature-frozen and maybe even bugsolve-frozen in > favor of LVM2 development (see the deadlock while using xfs_freeze issue). > LVM 2.x is unstable beta and EVMS is so fresh that no real experience has > been heard of. > I understand that there's no bug-free software and no guarantee of anything > but maybe some of you have some enterprise-level experience with, say, 2+ > TB data pool on XFS and some volume manager. I appreciate any reference of > any kind, some known imcompatibilies, what mistakes to avoid.. it would > help me a lot. I don't know the kind of storage you're going to use. There are ways to create blockdevices which you can enlarge later, for example a linear array where you just concatenate disks, or with some hardware RAID or high end storage solution. It's then the same procedure like having a 100G disk with only one partition of 20G. You can enlarge (delete and create the larger one with the same starting point) this partition to 40G and just grow the (still existing) xfs volume on it. It's my dirty but safe way of doing Logical Volume Management :) Simon > > With best regards, > > Marek Les > Seznam.cz > > Note: If you don't want to discuss this theme in public, please don't > hesitate to write me directly :-) From owner-linux-xfs@oss.sgi.com Thu Jun 6 11:25:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56IPVnC022070 for ; Thu, 6 Jun 2002 11:25:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56IPV53022069 for linux-xfs-outgoing; Thu, 6 Jun 2002 11:25:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf05bis.bellsouth.net (mail205.mail.bellsouth.net [205.152.58.145]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56IPJnC022040 for ; Thu, 6 Jun 2002 11:25:19 -0700 Received: from taz ([66.156.1.210]) by imf05bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020606182844.OEBN18134.imf05bis.bellsouth.net@taz>; Thu, 6 Jun 2002 14:28:44 -0400 Date: Thu, 6 Jun 2002 14:15:34 -0400 From: Greg Freemyer Subject: re[2]: enterprise-level experience To: Simon Matter , cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020606182844.OEBN18134.imf05bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g56IPJnC022041 X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I agree with Simon. When you are talking about a couple of Terabytes, most Raid Arrays effectively have their own LVM built in. Generally, software LVM is just needed for 2 features: Snapshots: This is available in many Raid systems, but it can be a fairly expensive option, so many people prefer software snapshots. Since XFS does not to my knowledge directly support snapshots, one is left to consider a software LVM vs. paying for the hardware option. Mirroring between Raid Arrays: Some truly paranoid people use LVM to mirror 2 standalone Raid Arrays to together. This is pretty rare because it is very expensive to do. I doubt you are planning on doing this. You mention volume growth in your e-mail, put that is typically done in hardware when you are talking about a 2 Terabyte array. Greg Freemyer >> Marek.Les@firma.seznam.cz schrieb: >> > >> > Hi there, >> > >> > Our company is in the process of moving the production server data on a >> > enterprise storage servers and therefore we are considering which setup >> > would have the best performance and stability at the same time. Our >> > preliminary tests showed us that, at the filesystem level, XFS performs >> > best. Unfortunately, to be capable of growing the volumes we need to add >> > another layer - the volume manager. This increases the chances for >> > something to go wrong. >> > As I've read through the mailing list and other sources, there are only >> two >> > possible software packages on Linux - LVM and EVMS. From what I've read >> I >> > understood that LVM 1.x is feature-frozen and maybe even bugsolve-frozen >> in >> > favor of LVM2 development (see the deadlock while using xfs_freeze >> issue). >> > LVM 2.x is unstable beta and EVMS is so fresh that no real experience >> has >> > been heard of. >> > I understand that there's no bug-free software and no guarantee of >> anything >> > but maybe some of you have some enterprise-level experience with, say, >> 2+ >> > TB data pool on XFS and some volume manager. I appreciate any reference >> of >> > any kind, some known imcompatibilies, what mistakes to avoid.. it would >> > help me a lot. >> I don't know the kind of storage you're going to use. There are ways to >> create blockdevices which you can enlarge later, for example a linear >> array where you just concatenate disks, or with some hardware RAID or >> high end storage solution. It's then the same procedure like having a >> 100G disk with only one partition of 20G. You can enlarge (delete and >> create the larger one with the same starting point) this partition to >> 40G and just grow the (still existing) xfs volume on it. >> It's my dirty but safe way of doing Logical Volume Management :) >> Simon >> > >> > With best regards, >> > >> > Marek Les >> > Seznam.cz >> > >> > Note: If you don't want to discuss this theme in public, please don't >> > hesitate to write me directly :-) From owner-linux-xfs@oss.sgi.com Thu Jun 6 11:44:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56IiLnC022487 for ; Thu, 6 Jun 2002 11:44:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56IiLZx022486 for linux-xfs-outgoing; Thu, 6 Jun 2002 11:44:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56IiFnC022447 for ; Thu, 6 Jun 2002 11:44:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA86941; Thu, 6 Jun 2002 13:46:12 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA61181; Thu, 6 Jun 2002 13:46:11 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id NAA53839; Thu, 6 Jun 2002 13:46:11 -0500 (CDT) Message-Id: <200206061846.NAA53839@slobber.americas.sgi.com> To: "James A Goodwin" cc: "Francis Qu" , linux-xfs@oss.sgi.com Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region Date: Thu, 06 Jun 2002 13:46:10 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" > >Dean, > >Thanks for the patch. It gets us past the problem with dm_get_fileattr(). > >However, later in the same function (called when the write event was >received), my process hangs on dm_set_region() for the same file. Is this >perhaps a similar problem with a similar fix? So a user process opens a file for append, and then does a write. This generates a write event. The HSM calls dm_get_events to get the write event. Then it calls dm_get_fileattr on that handle, then dm_set_region on that handle, then finally responds to the write event with dm_respond_event--is that the scenario? That scenario doesn't hang for me, so is there anything else going on in there? Dean From owner-linux-xfs@oss.sgi.com Thu Jun 6 11:45:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56IjInC022554 for ; Thu, 6 Jun 2002 11:45:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56IjInB022553 for linux-xfs-outgoing; Thu, 6 Jun 2002 11:45:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56IiunC022523 for ; Thu, 6 Jun 2002 11:44:56 -0700 Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) 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 LAA07761 for ; Thu, 6 Jun 2002 11:47:03 -0700 (PDT) mail_from (i.d.hardy@soton.ac.uk) Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g56Ibwq26719; Thu, 6 Jun 2002 19:37:58 +0100 (BST) Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g56IbjM21718; Thu, 6 Jun 2002 19:37:45 +0100 (BST) Message-ID: <3CFFABF9.5BFD2B80@soton.ac.uk> Date: Thu, 06 Jun 2002 19:37:45 +0100 From: "Ian D. Hardy" Organization: University of Southampton X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord , linux-xfs@oss.sgi.com CC: idh@soton.ac.uk, oz@soton.ac.uk Subject: Re-occurance of NFS server panics References: <200203201906.g2KJ69q10974@jen.americas.sgi.com> <3CB5B736.3F588C69@soton.ac.uk> <1018964322.24401.0.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean X-Spam-Status: No, hits=0.8 required=5.0 tests=SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, ++++ Some bad news, you may remember a couple of months ago I was having problems with an NFS server that kept panicing, you diagnosed a number of potential problems and patches; these seemed to help! (many thanks) indeed this did work for ~45 days but recently we started to get a re-occurance of these failures (again with crashes ~every 4-6 days). I then remembered that one of your suggestions/fixes concerned potential problems with high levels of filesystem fragmentation (at the time I ran 'xfs_fsr' to defrag the filesystem and you also introduced a change to the CVS tree intended to help prevent these crashes). Anyway, I then noticed that at the time that my crashes started to re-occur that the filesystem fragmentation had increased to ~60% (!!!) as reported via 'xfs_db' (some files having >3000 extents). Is it possible that there is still a issue in the XFS kernel (I'm currently using a kernel compiled from the CVS tree as of 17th May)? Oops/ksymoops output below. I've ran xfs_fsr to defrag the filesystem (getting it back down to <1%), however, I've (again) had a couple of instances in which shortly after running 'xfs_fsr' the filesystem has gone off-line, the system log shows: Jun 6 07:53:18 blue00 kernel: xfs_force_shutdown(md(9,0),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xc01e1fb9 Jun 6 07:53:18 blue00 kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,0) This was on an active filesystem. Is it possible that there is a interaction between xfs_fsr and NFS? (I'd guess that xfs_fsr may have a harder time detecting that a NFS client is accessing a file than for local file access?. Our current intention, now we've defraged the filesystem is to see how it goes for a couple of weeks if it seems better we will then schedule regular (2-4 weeks) maintenance periods to run 'xfs_fsr' on the filesytem without other filesystem activity. Does this seem sensible too you? One question, if there is a problem associated with high levels of fragmentation, is it overall high levels of fragmentation within the filesytem that causes the failure or could it potentially be a single file with a large number of extents? (I believe that we are getting some highly fragmented files as we have a number of users/ applications that frequently open, apend and then close a log file, these files soon get fragmented as the close releases any pre-allocated blocks). For various reasons I've not managed to capture the Oops outupt from most of the recent crashes but here's one (passed through ksymoops) that I did get. May help to identify the problem (does look to me as though it is related to filesystem extents/fragmentation, 'xfs_iext_realloc' in the trace, though I'm not a kernel code expert!). invalid operand: 0000 CPU: 1 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010086 eax: 0000001d ebx: 00e350c0 ecx: 0000002e edx: 00000026 esi: f8d4b000 edi: f8d43000 ebp: 00010000 esp: f3ba5a44 ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 615, stackpage=f3ba5000) Stack: c02b4082 f8d43000 00008000 f8d4b000 c0e20000 00010000 00000286 f8d43000 c01fd146 f8d43000 c01fd1a4 f8d43000 00010000 f4a5224c f8d43000 f8d4b000 00008000 c0e18000 c01d04f1 f8d43000 00008000 00010000 00000001 ffffffff Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 0f 0b 83 c4 08 8b 15 2c 95 3f c0 8b 2c 1a 89 7c 24 14 b8 00 >>EIP; c012ff76 <===== Trace; c01fd146 Trace; c01fd1a4 Trace; c01d04f0 Trace; c01a6996 Trace; c01a5f12 Trace; c01d6474 Trace; c01fd2e0 Trace; c01aac14 Trace; c01cf962 Trace; c01e6e22 Trace; c01e6340 Trace; c026cf44 Trace; c01f696e Trace; c01e6340 Trace; c014f45c Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> Trace; f8d2b348 <[nfsd]nfsd+1b8/370> Trace; c01057ea Code; c012ff76 00000000 <_EIP>: Code; c012ff76 <===== 0: 0f 0b ud2a <===== Code; c012ff78 2: 83 c4 08 add $0x8,%esp Code; c012ff7a 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx Code; c012ff80 b: 8b 2c 1a mov (%edx,%ebx,1),%ebp Code; c012ff84 e: 89 7c 24 14 mov %edi,0x14(%esp,1) Code; c012ff88 12: b8 00 00 00 00 mov $0x0,%eax Many thanks for your past (and continued) support. I'll be away from the 9th to the 23rd of June, I'd therefore be grateful if you could copy any replies to my colleague Oz Parchment at 'O.G.Parchment@soton.ac.uk'. Thanks again. Ian Hardy Steve Lord wrote: > > On Thu, 2002-04-11 at 11:17, Ian D. Hardy wrote: > > Steve, +++ > > > > Good news! (though posting this is tempting fait a bit). Since > > installing the XFS/CVS containing this fix my server has now > > been up for 21+days, this is a record (it's average was ~4 days > > but it did manage up to 14 days). > > > > I also applied the 'vnode.patch' that you posted in response > > to my problems on 6th March, as far as I'm aware that has not > > gone into the CVS tree? Is this still a valid patch? My > > understanding is that I'd probably seen at least these two bugs > > at various times? > > The vnode code changes should be in the tree as well. > > > > > Many thanks for all your help. > > Thanks for perservering with xfs! > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- /////////////Technical Coordination, Research Services//////////////////// Ian Hardy Tel: 023 80 593577 Computing Services Southampton University email: idh@soton.ac.uk Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Thu Jun 6 11:49:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56IndnC022848 for ; Thu, 6 Jun 2002 11:49:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56Ind14022847 for linux-xfs-outgoing; Thu, 6 Jun 2002 11:49:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56InZnC022818 for ; Thu, 6 Jun 2002 11:49:35 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA86815 for ; Thu, 6 Jun 2002 13:51:33 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA28701 for ; Thu, 6 Jun 2002 13:51:32 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id NAA72659 for linux-xfs@oss.sgi.com; Thu, 6 Jun 2002 13:51:32 -0500 (CDT) Date: Thu, 6 Jun 2002 13:51:32 -0500 (CDT) From: Dean Roehrich Message-Id: <200206061851.NAA72659@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - allow dmapi set/get-region test tools to take handle X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 6 11:51:10 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:121014a src/suite1/cmd/get_region.c - 1.7 - No Message Supplied src/common/cmd/set_region.c - 1.8 - No Message Supplied From owner-linux-xfs@oss.sgi.com Thu Jun 6 15:49:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56MnWnC028100 for ; Thu, 6 Jun 2002 15:49:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56MnWJq028099 for linux-xfs-outgoing; Thu, 6 Jun 2002 15:49:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56MnOnC028071 for ; Thu, 6 Jun 2002 15:49:25 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA07208 for ; Thu, 6 Jun 2002 15:51:26 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA13222; Fri, 7 Jun 2002 08:50:07 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g56MmnQq001213; Fri, 7 Jun 2002 08:48:49 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g56MmmWP001211; Fri, 7 Jun 2002 08:48:48 +1000 Date: Fri, 7 Jun 2002 08:48:48 +1000 From: Nathan Scott To: mark Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: SOLVED cp -p problem Message-ID: <20020606224848.GA479@frodo> References: <200206061528.24033.mark.newman2@ntlworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206061528.24033.mark.newman2@ntlworld.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 06, 2002 at 03:28:24PM +0100, mark wrote: > Hi > > Sorry to waste peoples time, this is a Gentoo Linux configuration problem. Hmm - thats not really fair on Gentoo. This is a workaround, but the underlying problem remains, and is not Gentoo related. > Basically Gentoo builds all its apps from source using an 'ebuild' script > which controls the configure, make, make install. A fellow Gentoo user has > provided the solution There was a flag in one of my config files which was > causing cp to be built against acl in some way. Since I had no real need of > acl just removing this flag and rebuilding fileuttils has solved the problem > > I am not saying there is a problem with acl or not, to be honest it is not a > subject I have spent any time learning about so it could be just that I > misconfigured xfs in some way. Anyway all seems fine now. You haven't misconfigured XFS - I'm able to reproduce this with the cp binary you sent me last night. It is definately a problem in ACL land, but not clear yet whether its XFS, libacl.so or the patch to fileutils which is causing it. I will keep trying to figure this out... thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 6 16:22:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g56NMMnC028932 for ; Thu, 6 Jun 2002 16:22:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g56NMMdp028931 for linux-xfs-outgoing; Thu, 6 Jun 2002 16:22:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g56NMFnC028903 for ; Thu, 6 Jun 2002 16:22:15 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA01847 for ; Thu, 6 Jun 2002 16:24:17 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13512; Fri, 7 Jun 2002 09:22:58 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g56NLdQq001373; Fri, 7 Jun 2002 09:21:39 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g56NLb7R001371; Fri, 7 Jun 2002 09:21:37 +1000 Date: Fri, 7 Jun 2002 09:21:37 +1000 From: Nathan Scott To: Marek.Les@firma.seznam.cz, Roy Sigurd Karlsbakk Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: Re: mkfs - cannot set blocksize Message-ID: <20020606232137.GB479@frodo> References: <200206061435.g56EZpl28164@mail.pronto.tv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206061435.g56EZpl28164@mail.pronto.tv> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Thu, Jun 06, 2002 at 04:35:51PM +0200, Roy Sigurd Karlsbakk wrote: > linux ia32 only supports 4kB block size 4K pagesize, not blocksize. [filesystem] blocksizes smaller than 4K are also supported. Thats unrelated to this problem though, which is related to the device driver blocksize... mkfs is trying to tell the device to do IOs in 512 byte chunks, but its not listening. There's some corner cases where mkfs will fail if the device driver ignores its request to change the device block size. > On Thursday 06 June 2002 16:27, Marek.Les@firma.seznam.cz wrote: > > Hello, > > > > I am trying to test XFS with LVM and I've encountered this error while > > trying to do mkfs.xfs on the LVM logical volume: > > > > mkfs.xfs: warning - cannot set blocksize on block device > > /dev/test_vg/test_lv: Invalid argument > > I tried to find something in the mailing list but the only thing I found > > was something about EVMS but no LVM stuff. Can anyone tell me, what exactly > > this warning means and (if possible) how to get rid of it? ^^^^^^^^^^^^^^^^^^^^ We need to contact the LVM folks and ask them to implement the BLKBSZSET ioctl (and while I'm at it, I'll mention that ENOTTY should be returned instead of EINVAL for unrecognised ioctls, apparently). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 6 17:53:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g570rXnC030298 for ; Thu, 6 Jun 2002 17:53:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g570rXwT030297 for linux-xfs-outgoing; Thu, 6 Jun 2002 17:53:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g570rJnC030269 for ; Thu, 6 Jun 2002 17:53:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA03899 for ; Thu, 6 Jun 2002 17:55:20 -0700 (PDT) mail_from (ivanr@sgi.com) Received: from omen (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id KAA14251; Fri, 7 Jun 2002 10:53:57 +1000 Date: Fri, 7 Jun 2002 10:53:56 +1000 From: Ivan Rayner To: Stephan Austermuehle Cc: linux-xfs@oss.sgi.com Subject: Re: Problems with xfsdump on snapshot LV Message-Id: <20020607105356.7715feab.ivanr@sgi.com> In-Reply-To: <20020606110338.A27807@babbage.hcsd.de> References: <20020606110338.A27807@babbage.hcsd.de> Organization: SGI X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Without the xfsdump output, it's hard to know exactly. However, xfsdump will write out a file containing quota information to be included in the dump -- assuming your filesystem has or had at some point, quotas enabled. Ivan On Thu, 6 Jun 2002 11:03:38 +0200, Stephan Austermuehle wrote: > Hi, > > I did the following: > > # xfs_freeze -f /usr > # lvcreate -L 256m -n /dev/vg00/lv_usr_snap -s /dev/vg00/lv_usr > # xfs_freeze -u /usr > # mount -t xfs -o ro,nouuid /dev/vg00/lv_usr_snap /mnt > # xfsdump -l 0 -p 60 - /mnt |buffer ... > /dev/nst1 > > This results in the following error messages: > > XFS mounting filesystem lvm(58,19) > lvm - lvm_map: ll_rw_blk write for readonly LV > /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for > readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write > for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk > write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: > ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - > lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap > lvm - lvm_map: ll_rw_blk write for readonly LV > /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write for > readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk write > for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: ll_rw_blk > write for readonly LV /dev/vg00/lv_usr_snap lvm - lvm_map: > ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap lvm - > lvm_map: ll_rw_blk write for readonly LV /dev/vg00/lv_usr_snap > lvm - lvm_map: ll_rw_blk write for readonly LV > /dev/vg00/lv_usr_snap I/O error in filesystem ("lvm(58,19)") > meta-data dev 0x3a13 block 0x1007fc > ("xlog_iodone") error 5 buf count 6656 > xfs_force_shutdown(lvm(58,19),0x2) called from line 939 of file > xfs_log.c. Return address = 0xc01bdbe6 Log I/O Error Detected. > Shutting down filesystem: lvm(58,19) Please umount the > filesystem, and rectify the problem(s) Unable to handle kernel > NULL pointer dereference at virtual address 00000020 > printing eip: > c0131f02 > *pde = 00000000 > Oops: 0000 > CPU: 0 > EIP: 0010:[] Not tainted > EFLAGS: 00010202 > eax: 00003a13 ebx: 00000000 ecx: 00003a13 edx: 00003a13 > esi: 00000001 edi: 00000000 ebp: 00000000 esp: d01fdd60 > ds: 0018 es: 0018 ss: 0018 > Process lvremove (pid: 25437, stackpage=d01fd000) > Stack: dfed8740 df466400 c0347df6 dfb6d000 3a13d000 00000000 > 00000000 c0132000 > dfed8740 00000000 dfe3b370 c0237668 00003a13 00000000 > 00003a13 00000000 bffff5ac c0347e64 dfb6d000 00000180 > dfb6d4c4 00000010 c0234c21 00000000 > Call Trace: [] [] [] [] > [] > [] [] [] [] > [] [] [] [] > [] [] [] > > Code: 8b 7b 20 0f b7 54 24 12 66 39 53 0c 0f 85 84 00 00 00 83 > 7b > > Why does xfsdump try to write to a filesystem that should be backup'd? > > Thanks for your help, > > Stephan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jun 6 18:34:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g571YBnC030850 for ; Thu, 6 Jun 2002 18:34:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g571YBJK030849 for linux-xfs-outgoing; Thu, 6 Jun 2002 18:34:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g571Y4nC030821 for ; Thu, 6 Jun 2002 18:34:04 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA09413 for ; Thu, 6 Jun 2002 18:36:06 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA14639; Fri, 7 Jun 2002 11:34:45 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g571XSlS000496; Fri, 7 Jun 2002 11:33:28 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g571XRl7000494; Fri, 7 Jun 2002 11:33:27 +1000 Date: Fri, 7 Jun 2002 11:33:27 +1000 From: Nathan Scott To: mark Cc: linux-xfs@oss.sgi.com Subject: Re: probs with cp -p Message-ID: <20020607013327.GA442@frodo> References: <200206032201.36167.mark.newman2@ntlworld.com> <20020606004605.GB1413@frodo> <200206061219.47056.mark.newman2@ntlworld.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206061219.47056.mark.newman2@ntlworld.com> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Mark, On Thu, Jun 06, 2002 at 12:19:47PM +0100, mark wrote: > > acl_free(0x0805476c, 32768, 0x0805476c, 0, 0xbffff6a4) = 0 > acl_get_file(0xbffffce0, 16384, 0x0805476c, 0, 0xbffff6a4) = 0x08054784 > acl_set_file(0x08054710, 16384, 0x08054784, 0, 0xbffff6a4) = -1 > __ctype_get_mb_cur_max(256, 0x08054140, 0, 0x4002a180, 0x4002b574) = 1 > dcgettext(0, 0x0805294a, 5, 0x4009fb14, 0) = 0x0805294a > dcgettext(0, 0x0805294c, 5, 0x0804f01f, 0) = 0x0805294c > dcgettext(0, 0x08052606, 5, 0xbffff68c, 0x08054140) = 0x08052606 > __errno_location() = 0x40157c20 > error(0, 22, 0x08052606, 0x08054140, 0x08054710cp: preserving permissions for > `/home/usr/local/share/doc': Invalid argument > ) = 0 OK, I know what is happening here now - it seems to me that libacl is doing some unholy things, including attempting to set default ACLs with no ACEs. We will change XFS to be more graceful in the presense of this condition, and take this up with the libacl and fileutils patch author. Thanks for reporting and helping resolve the problem. The fix to prevent these warning messages will show up in XFS CVS shortly. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 6 18:34:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g571YgnC030912 for ; Thu, 6 Jun 2002 18:34:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g571Ygju030911 for linux-xfs-outgoing; Thu, 6 Jun 2002 18:34:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g571YcnC030882 for ; Thu, 6 Jun 2002 18:34:38 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA09611 for ; Thu, 6 Jun 2002 18:36:41 -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 LAA87020 for linux-xfs@oss.sgi.com; Fri, 7 Jun 2002 11:35:20 +1000 (EST) Date: Fri, 7 Jun 2002 11:35:20 +1000 (EST) From: Nathan Scott Message-Id: <200206070135.LAA87020@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfs_acl.c X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 6 18:25:42 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:121046a linux/fs/xfs/xfs_acl.c - 1.23 - acl_set_file(3) may request that we set default ACLs with zero length; defend (gracefully) against that in XFS, and take it up with Andreas as to whether libacl needs fixing too. From owner-linux-xfs@oss.sgi.com Thu Jun 6 19:23:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g572NInC031708 for ; Thu, 6 Jun 2002 19:23:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g572NIQX031707 for linux-xfs-outgoing; Thu, 6 Jun 2002 19:23:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g572N8nC031679 for ; Thu, 6 Jun 2002 19:23:09 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g5728Xd25006 for ; Fri, 7 Jun 2002 11:08:33 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g5728WL27004 for ; Fri, 7 Jun 2002 11:08:32 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g5728O812719 for ; Fri, 7 Jun 2002 11:08:31 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA411 for ; Fri, 7 Jun 2002 11:08:23 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Fri Jun 07 11:08:22 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g5728NA60488; Fri, 7 Jun 2002 11:08:23 +0900 (JST) Received: from NEC4D4BGTKMOBI (TNES017100.bsd.tnes.nec.co.jp [10.1.104.62]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g5728MY18630; Fri, 7 Jun 2002 11:08:22 +0900 Message-ID: <011f01c20dc8$33a11450$3e68010a@bsd.tnes.nec.co.jp> From: =?UTF-8?B?5Lit6YeO44CA5Y2a5LmL?= To: "Stephen Lord" Cc: References: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp> <1023369251.1701.20.camel@snafu> Subject: Re: XFS force shutdown : EFSCORRUPTED Date: Fri, 7 Jun 2002 11:08:22 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, I hold factor is reading block device. As I make 8 allocation groups by mkfs.xfs, and I put log on allocation group1. Thanks. -nak > > > > Hi XFS stuff. > > > > I met a problem with XFS filesystem. > > > > I am using kernel 2.4.18-xfs. Hardware is pentium3 800Mhz,128MB of RAM. > > > > XFS goes to force-shutdown everytime when I execute my test suite. > > Do you have any information for this issue? > > I will try this, but in general, I do not think XFS functions correctly > with a single allocation group. Do you know which factor here is the > trigger for the error - reading the block device, or the single > allocation group? > > Steve > > From owner-linux-xfs@oss.sgi.com Thu Jun 6 21:29:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g574TZnC001092 for ; Thu, 6 Jun 2002 21:29:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g574TZ8j001091 for linux-xfs-outgoing; Thu, 6 Jun 2002 21:29:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g574TEnC001061 for ; Thu, 6 Jun 2002 21:29:16 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g574VDC23964 for ; Fri, 7 Jun 2002 13:31:13 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g574VDL02453 for ; Fri, 7 Jun 2002 13:31:13 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g574VA808475 for ; Fri, 7 Jun 2002 13:31:11 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA192 for ; Fri, 7 Jun 2002 13:31:08 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Fri Jun 07 13:31:07 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g574V8A70634 for ; Fri, 7 Jun 2002 13:31:08 +0900 (JST) Received: from TNES017006 (TNES017006.bsd.tnes.nec.co.jp [10.1.104.88]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with ESMTP id g574V7Y27864 for ; Fri, 7 Jun 2002 13:31:07 +0900 Message-ID: <002401c20ddc$24d4b080$5868010a@bsd.tnes.nec.co.jp> From: "hcx" To: Subject: quotaoff error Date: Fri, 7 Jun 2002 13:31:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi XFS stuff. There is a problem about XFS filesystem when XFS_DEBUG is setted. the kernel is 2.4.17and 2.4.18. mount -t xfs -o usrquota,grpquota /dev/hda8 /mnt touch /mnt/f1 rm /mnt/f1 quotaoff /mnt there is ASSERT error.the error information is like this. \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ Disabling group XFS assertion failed: (((struct bhv_desc *)(&((ip)->i_bhv_desc)) ))->bd_vobj, file: xfs_macros.c, line: 1842 quota enforcemeninvalid operand: 0000 CPU: 0 EIP: 0010:[<4028d559>] Not tainted EFLAGS: 00010202 eax: 0000006c ebx: 41a1367c ecx: 41d18000 edx: 438e3f64 esi: 00000000 edi: 4364e000 ebp: 4364e000 esp: 41d19e00 ds: 0018 es: 0018 ss: 0018 Process quotaoff (pid: 945, stackpage=41d19000) Stack: 40413b40 40400bc0 40400ca6 00000732 402389ca 40400bc0 40400ca6 00000732 41a1367c 401d600c 41a1367c 00000000 00000002 4364e000 401d5ac9 41b7b758 00000000 00000000 41b7b758 00000000 00000004 00000070 fffffeff 4364e000 Call Trace: [<402389ca>] [<401d600c>] [<401d5ac9>] [<401d42b2>] [<4011bcfb>] [<401d3ec4>] [<40151a2e>] [<4014abbc>] [<40142190>] [<40142b38>] [<4014abbc>] [<40141ede>] [<40151e26>] [<4010716b>] Code: 0f 0b 83 c4 10 c3 90 53 8b 1d 94 b8 53 40 ba 5f 0b 4e 83 89 t on /dev/hda8 Entering kdb (current=0x41d18000, pid 945) on processor 0 Oops: invalid operand due to oops @ 0x4028d559 eax = 0x0000006c ebx = 0x41a1367c ecx = 0x41d18000 edx = 0x438e3f64 esi = 0x00000000 edi = 0x4364e000 esp = 0x41d19e00 eip = 0x4028d559 ebp = 0x4364e000 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010202 xds = 0x43640018 xes = 0x00000018 origeax = 0xffffffff ®s = 0x41d19dcc [0]kdb> bt EBP EIP Function(args) 0x4364e000 0x4028d559 assfail+0x19 (0x40400bc0, 0x40400ca6, 0x732) kernel .text 0x40100000 0x4028d540 0x4028d560 0x402389ca xfs_itov+0x2a (0x41a1367c, 0x0, 0x2, 0x4364e000, 0x401d5ac 9) kernel .text 0x40100000 0x402389a0 0x402389e0 0x401d600c xfs_qm_dqrele_all_inodes+0xdc (0x4364e000, 0x70, 0x4364e00 0, 0x41d19e80, 0x70) kernel .text 0x40100000 0x401d5f30 0x401d6160 0x401d42b2 xfs_qm_scall_quotaoff+0x2c2 (0x4364e000, 0x50, 0x0) kernel .text 0x40100000 0x401d3ff0 0x401d43f0 0x401d3ec4 linvfs_setxstate+0xc4 (0x41bb1000, 0xc, 0x5802, 0xfffffff2 , 0x1) kernel .text 0x40100000 0x401d3e00 0x401d3ee0 0x40151a2e sbqop+0xce (0x41bb1000, 0x5802, 0x1, 0x0, 0x3ffff918) kernel .text 0x40100000 0x40151960 0x40151c50 0x40151e26 sys_quotactl+0x1d6 (0x580201, 0x8057040, 0x0, 0x3ffff918, 0x1) kernel .text 0x40100000 0x40151c50 0x40151e90 0x4010716b system_call+0x33 kernel .text 0x40100000 0x40107138 0x40107170 [0]kdb> ps Task Addr Pid Parent [*] cpu State Thread Command 0x43b92000 00000001 00000000 0 000 stop 0x43b92370 init 0x43b22000 00000003 00000001 0 000 stop 0x43b22370 keventd 0x43b20000 00000004 00000001 0 000 stop 0x43b20370 kapm-idled 0x43b1e000 00000005 00000000 0 000 run 0x43b1e370 ksoftirqd_CPU0 0x43b14000 00000006 00000000 0 000 stop 0x43b14370 kswapd 0x43af0000 00000007 00000000 0 000 stop 0x43af0370 bdflush 0x43aee000 00000008 00000000 0 000 stop 0x43aee370 kupdated 0x43a8e000 00000009 00000001 0 000 stop 0x43a8e370 pagebuf_daemon 0x43a8c000 00000010 00000000 0 000 stop 0x43a8c370 sxfs_daemon 0x43a60000 00000014 00000001 0 000 stop 0x43a60370 mdrecoveryd 0x43922000 00000426 00000001 0 000 stop 0x43922370 syslogd 0x438e2000 00000431 00000001 0 000 run 0x438e2370 klogd 0x438a2000 00000445 00000001 0 000 stop 0x438a2370 portmap 0x43872000 00000460 00000001 0 000 stop 0x43872370 rpc.statd 0x4386a000 00000542 00000001 0 000 stop 0x4386a370 apmd 0x434fc000 00000590 00000001 0 000 stop 0x434fc370 automount 0x4357e000 00000602 00000001 0 000 stop 0x4357e370 atd 0x43484000 00000617 00000001 0 000 stop 0x43484370 sshd 0x43412000 00000637 00000001 0 000 stop 0x43412370 xinetd 0x43176000 00000653 00000001 0 000 stop 0x43176370 lpd 0x42fb0000 00000673 00000001 0 000 stop 0x42fb0370 sendmail [0]more> 0x42f74000 00000686 00000001 0 000 stop 0x42f74370 gpm 0x42f08000 00000700 00000001 0 000 stop 0x42f08370 jserver 0x42838000 00000713 00000001 0 000 stop 0x42838370 cannaserver 0x42810000 00000725 00000001 0 000 stop 0x42810370 crond 0x425b2000 00000799 00000001 0 000 stop 0x425b2370 xfs 0x4213e000 00000811 00000001 0 000 stop 0x4213e370 smbd 0x41fc6000 00000816 00000001 0 000 stop 0x41fc6370 nmbd 0x41f90000 00000828 00000001 0 000 stop 0x41f90370 anacron 0x423ea000 00000851 00000001 0 000 stop 0x423ea370 mingetty 0x42136000 00000852 00000001 0 000 stop 0x42136370 mingetty 0x42452000 00000853 00000001 0 000 stop 0x42452370 mingetty 0x4246a000 00000854 00000001 0 000 stop 0x4246a370 mingetty 0x42412000 00000855 00000001 0 000 stop 0x42412370 mingetty 0x41fa8000 00000856 00000001 0 000 stop 0x41fa8370 mingetty 0x42132000 00000857 00000001 0 000 stop 0x42132370 login 0x41d06000 00000860 00000857 0 000 stop 0x41d06370 bash 0x41c42000 00000899 00000860 0 000 stop 0x41c42370 su 0x41bfc000 00000900 00000899 0 000 stop 0x41bfc370 bash 0x41d18000 00000945 00000900 1 000 run 0x41d18370*quotaoff [0]kdb> [0]kdb From owner-linux-xfs@oss.sgi.com Thu Jun 6 22:10:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g575AHnC001485 for ; Thu, 6 Jun 2002 22:10:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g575AHcL001484 for linux-xfs-outgoing; Thu, 6 Jun 2002 22:10:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g575A8nC001455 for ; Thu, 6 Jun 2002 22:10:08 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA09690 for ; Thu, 6 Jun 2002 22:12:10 -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 PAA73308; Fri, 7 Jun 2002 15:10:49 +1000 (AEST) Date: Fri, 7 Jun 2002 15:10:49 +1000 From: Tim Shimmin To: Florian.Lindner@xgm.de Cc: linux-xfs@oss.sgi.com Subject: Re: Tutorial to ACLs and XFS handling Message-ID: <20020607151049.K1915227@boing.melbourne.sgi.com> References: <000d01c20d57$6f7b1b90$0200a8c0@florian> <1023380095.5878.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <1023380095.5878.23.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Thu, Jun 06, 2002 at 11:14:55AM -0500 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Florian, As Eric mentioned, the acl.bestbits.at site is the one to go to. The userland tools and libraries mentioned on this site are compatible with the xfs kernel (and stored in our tree). Andreas Gruenbacher is the maintainer of these and questions about them should be sent to his mailing list. Some XFS specific things which come to mind: - xfs stores ACLs in XFS extended attributes - xfsdump and xfsrestore dumps and restores extended attributes, thus it dumps and restores ACLs - XFS ACLs are limited to 25 ACL entries (ACEs) - which leaves 25-4=21 ACEs for user and group ACEs - the guys at Snapserver (jtrostel et al) have some patches for extended permissions and larger ace count (though nathans@sgi.com had suggestions for a nicer implementation I believe) - if ACLs are small enough (<=20 ACEs (20*12+4=244<256)) and the inode is large enough (mkfs.xfs -i size=), then the ACLs may be stored in the inode which can speed up access --Tim On Thu, Jun 06, 2002 at 11:14:55AM -0500, Eric Sandeen wrote: > Florian - > > Have you looked at http://acl.bestbits.at/? Not xfs-specific, but: > > What are extended attributes? > What are access control lists? > Using extended attributes and access control lists > Frequently asked questions > > etc. > > -Eric > > On Thu, 2002-06-06 at 07:41, Florian Lindner wrote: > > Hello, > > I'm looking for tutorial for ACLs generell und especially how XFS handles > > them. I'm not interessted in how the implementiation is done, but I want to > > know from a users point of view. (tool for managing ACLs, ....). > > Language English or German. > > Thx, > > Florian > > From owner-linux-xfs@oss.sgi.com Fri Jun 7 00:43:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g577hvnC002729 for ; Fri, 7 Jun 2002 00:43:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g577hvpT002728 for linux-xfs-outgoing; Fri, 7 Jun 2002 00:43:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from comm.hcsd.de (comm-ext2.hcsd.de [217.146.142.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g577hqnC002699 for ; Fri, 7 Jun 2002 00:43:52 -0700 Received: from babbage.hcsd.de (babbage.hcsd.de [192.168.100.5]) by comm.hcsd.de (8.12.2/8.12.2) with ESMTP id g577ju8v014202 for ; Fri, 7 Jun 2002 09:45:56 +0200 Received: (from au@localhost) by babbage.hcsd.de (8.11.3/8.11.3) id g577juE05208 for linux-xfs@oss.sgi.com; Fri, 7 Jun 2002 09:45:56 +0200 Date: Fri, 7 Jun 2002 09:45:56 +0200 From: Stephan Austermuehle To: linux-xfs@oss.sgi.com Subject: Version flag for xfsdump would be fine... Message-ID: <20020607094556.A5160@babbage.hcsd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! It would be nice to have a flag in xfsdump/xfsrestore that show its version number (e.g., -V, -v, --version, ...). Stephan From owner-linux-xfs@oss.sgi.com Fri Jun 7 01:04:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5784jnC003022 for ; Fri, 7 Jun 2002 01:04:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5784jTH003021 for linux-xfs-outgoing; Fri, 7 Jun 2002 01:04:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5784dnC002992 for ; Fri, 7 Jun 2002 01:04:40 -0700 Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by mail7.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17GElT-0003G3-00; Fri, 07 Jun 2002 09:06:31 +0100 Received: from modem-2036.zebra.dialup.pol.co.uk ([81.76.151.244] helo=reti) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17GElA-0000fE-00; Fri, 07 Jun 2002 09:06:13 +0100 Received: from joe by reti with local (Exim 3.35 #1 (Debian)) id 17GEkn-0000M5-00; Fri, 07 Jun 2002 09:05:49 +0100 Date: Fri, 7 Jun 2002 09:05:39 +0100 To: linux-lvm@sistina.com Cc: Marek.Les@firma.seznam.cz, Roy Sigurd Karlsbakk , linux-xfs@oss.sgi.com Subject: Re: [linux-lvm] Re: mkfs - cannot set blocksize Message-ID: <20020607080539.GA1320@fib011235813.fsnet.co.uk> References: <200206061435.g56EZpl28164@mail.pronto.tv> <20020606232137.GB479@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020606232137.GB479@frodo> User-Agent: Mutt/1.3.28i From: Joe Thornber X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan, On Fri, Jun 07, 2002 at 09:21:37AM +1000, Nathan Scott wrote: > We need to contact the LVM folks and ask them to implement the > BLKBSZSET ioctl (and while I'm at it, I'll mention that ENOTTY > should be returned instead of EINVAL for unrecognised ioctls, > apparently). I put this ioctl into device-mapper (LVM2 driver) recently, and will suggest Heinz does the same for LVM1. You're correct about ENOTTY, thanks for pointing it out. - Joe From owner-linux-xfs@oss.sgi.com Fri Jun 7 01:23:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g578NAnC003300 for ; Fri, 7 Jun 2002 01:23:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g578N9VQ003299 for linux-xfs-outgoing; Fri, 7 Jun 2002 01:23:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@[216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g578N4nC003271 for ; Fri, 7 Jun 2002 01:23:05 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 2FDD84C3032; Fri, 7 Jun 2002 04:25:09 -0400 (EDT) To: linux-xfs@oss.sgi.com Subject: xfsdump and -v or -V? Message-Id: <20020607082509.2FDD84C3032@burgers.bubbanfriends.org> Date: Fri, 7 Jun 2002 04:25:09 -0400 (EDT) From: mburger@bubbanfriends.org (Mike Burger) X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you're looking for the version in xfsdump/restore, just issue: "xfsdump --help" or "--xfrestore --help" The first line gives you the version, and then the usage follows. From owner-linux-xfs@oss.sgi.com Fri Jun 7 01:28:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g578SInC003660 for ; Fri, 7 Jun 2002 01:28:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g578SIGp003659 for linux-xfs-outgoing; Fri, 7 Jun 2002 01:28:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from comm.hcsd.de (comm-ext2.hcsd.de [217.146.142.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g578SDnC003631 for ; Fri, 7 Jun 2002 01:28:14 -0700 Received: from babbage.hcsd.de (babbage.hcsd.de [192.168.100.5]) by comm.hcsd.de (8.12.2/8.12.2) with ESMTP id g578UI8v014297 for ; Fri, 7 Jun 2002 10:30:18 +0200 Received: (from au@localhost) by babbage.hcsd.de (8.11.3/8.11.3) id g578UIS05351 for linux-xfs@oss.sgi.com; Fri, 7 Jun 2002 10:30:18 +0200 Date: Fri, 7 Jun 2002 10:30:01 +0200 From: Stephan Austermuehle To: Mike Burger Subject: Re: xfsdump and -v or -V? Message-ID: <20020607103001.A5323@babbage.hcsd.de> References: <20020607082509.2FDD84C3032@burgers.bubbanfriends.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020607082509.2FDD84C3032@burgers.bubbanfriends.org>; from mburger@bubbanfriends.org on Fri, Jun 07, 2002 at 04:25:09AM -0400 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 07, 2002 at 04:25:09AM -0400, Mike Burger wrote: > "xfsdump --help" or "--xfrestore --help" > The first line gives you the version, and then the usage follows. Yes, thanks for the hint. Nevertheless I think that a separate version flag is better because one doesn't have to look through the tons of lines generated with --help. It's very little effort to implement this. Stephan From owner-linux-xfs@oss.sgi.com Fri Jun 7 01:40:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g578eQnC003893 for ; Fri, 7 Jun 2002 01:40:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g578eQmO003892 for linux-xfs-outgoing; Fri, 7 Jun 2002 01:40:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fileserver.kancelar.seznam.cz (ns.seznam.cz [212.80.76.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g578eGnC003862 for ; Fri, 7 Jun 2002 01:40:17 -0700 Received: from lotus.kancelar.seznam.cz (lotus.kancelar.seznam.cz [192.168.7.24]) by fileserver.kancelar.seznam.cz (8.11.4/8.11.3) with ESMTP id g578hZL53647 for ; Fri, 7 Jun 2002 10:43:35 +0200 (CEST) (envelope-from Marek.Les@firma.seznam.cz) Subject: Re: re[2]: enterprise-level experience To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Marek.Les@firma.seznam.cz Date: Fri, 7 Jun 2002 10:42:17 +0200 X-MIMETrack: Serialize by Router on Lotus/Seznam(Release 5.0.8 |June 18, 2001) at 06/07/2002 10:42:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.6 required=5.0 tests=NO_REAL_NAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, >I agree with Simon. > >When you are talking about a couple of Terabytes, most Raid Arrays effectively >have their own LVM built in. First of all, thanks to all for your responses. Now, the storage solution I am talking about (unfortunately I'm not allowed to be specific here, for the moment) is, what you called a high-end one, and has some kind of LVM of it's own but from what I understood, it cannot simply grow an existing logical volume. It has an internal RAID 5 and I've been told that "it could have been done but it's not for the reason of security". I can see some point in this, they want to maintain data integrity (the way the device works internally is quite complex). So, what happens is that when I want to "enlarge" the volume, I get (physically, in the OS) a new device, like /dev/sdc. And now I'm on my own to grow a filesystem, so I need to use software LVM.. >Generally, software LVM is just needed for 2 features: > >Snapshots: This is available in many Raid systems, but it can be a fairly >expensive option, so many people prefer software snapshots. Since XFS does not >to my knowledge directly support snapshots, one is left to consider a software >LVM vs. paying for the hardware option. As you say, this is a fairly expensive option :) But unfortunately, LVM1 is deadlocking with xfs_freeze - anyone has any EVMS experience? >Mirroring between Raid Arrays: Some truly paranoid people use LVM to mirror 2 >standalone Raid Arrays to together. This is pretty rare because it is very >expensive to do. I doubt you are planning on doing this. Yes, I won't do that. Marek Les Seznam.cz From owner-linux-xfs@oss.sgi.com Fri Jun 7 01:56:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g578uqnC004206 for ; Fri, 7 Jun 2002 01:56:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g578uq73004205 for linux-xfs-outgoing; Fri, 7 Jun 2002 01:56:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.pronto.tv ([62.70.58.70]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g578ujnC004172 for ; Fri, 7 Jun 2002 01:56:46 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by mail.pronto.tv (8.11.6/8.11.6) id g578wfi22035; Fri, 7 Jun 2002 10:58:41 +0200 Message-Id: <200206070858.g578wfi22035@mail.pronto.tv> Content-Type: text/plain; charset="iso-8859-1" From: Roy Sigurd Karlsbakk Organization: Pronto TV AS To: Nathan Scott , Marek.Les@firma.seznam.cz Subject: Re: mkfs - cannot set blocksize Date: Fri, 7 Jun 2002 10:58:41 +0200 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <200206061435.g56EZpl28164@mail.pronto.tv> <20020606232137.GB479@frodo> In-Reply-To: <20020606232137.GB479@frodo> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g578ulnC004176 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > 4K pagesize, not blocksize. [filesystem] blocksizes smaller than 4K > are also supported. Thats unrelated to this problem though, which is > related to the device driver blocksize... mkfs is trying to tell the > device to do IOs in 512 byte chunks, but its not listening. There's > some corner cases where mkfs will fail if the device driver ignores > its request to change the device block size. ok. sorry. rephrasing. Linux on IA32 does not support blocksize > pagesize, which means Linux on IA32 supports 512, 1024, 2048 and 4096 bytes per block -- Roy Sigurd Karlsbakk, Datavaktmester Computers are like air conditioners. They stop working when you open Windows. From owner-linux-xfs@oss.sgi.com Fri Jun 7 02:01:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5791WnC004416 for ; Fri, 7 Jun 2002 02:01:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5791WsO004415 for linux-xfs-outgoing; Fri, 7 Jun 2002 02:01:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5791QnC004387 for ; Fri, 7 Jun 2002 02:01:27 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id CAA00203 for ; Fri, 7 Jun 2002 02:03:30 -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 TAA77112; Fri, 7 Jun 2002 19:02:11 +1000 (AEST) Date: Fri, 7 Jun 2002 19:02:10 +1000 From: Tim Shimmin To: Stephan Austermuehle Cc: Mike Burger , linux-xfs@oss.sgi.com Subject: Re: xfsdump and -v or -V? Message-ID: <20020607190210.P1915227@boing.melbourne.sgi.com> References: <20020607082509.2FDD84C3032@burgers.bubbanfriends.org> <20020607103001.A5323@babbage.hcsd.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020607103001.A5323@babbage.hcsd.de>; from au@hcsd.de on Fri, Jun 07, 2002 at 10:30:01AM +0200 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 07, 2002 at 10:30:01AM +0200, Stephan Austermuehle wrote: > On Fri, Jun 07, 2002 at 04:25:09AM -0400, Mike Burger wrote: > > > "xfsdump --help" or "--xfrestore --help" > > The first line gives you the version, and then the usage follows. > > Yes, thanks for the hint. Nevertheless I think that a separate version > flag is better because one doesn't have to look through the tons of > lines generated with --help. It's very little effort to implement > this. > NOTE that xfsdump -h currently reports the dump format version which doesn't match with the program VERSION number. It will soon output both version numbers. xfsdump/restore are currently overloaded with options. There is no plan to support long options. => no separate version# option (BTW, the getopt handling in xfsdump is more complicated than one might think :( ) --Tim From owner-linux-xfs@oss.sgi.com Fri Jun 7 02:46:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g579kNnC004890 for ; Fri, 7 Jun 2002 02:46:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g579kNG0004889 for linux-xfs-outgoing; Fri, 7 Jun 2002 02:46:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g579k2nC004860 for ; Fri, 7 Jun 2002 02:46:02 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 37967C22B; Fri, 7 Jun 2002 11:29:07 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id LAA05472; Fri, 7 Jun 2002 11:29:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id E30D457306; Fri, 7 Jun 2002 11:28:25 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id BAD4125835; Fri, 7 Jun 2002 11:28:25 +0200 (CEST) Message-ID: <3D007CB9.8C9E5ABF@ch.sauter-bc.com> Date: Fri, 07 Jun 2002 11:28:25 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Marek.Les@firma.seznam.cz Cc: linux-xfs@oss.sgi.com Subject: Re: enterprise-level experience References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Marek.Les@firma.seznam.cz schrieb: > > Hello, > > >I agree with Simon. > > > >When you are talking about a couple of Terabytes, most Raid Arrays > effectively > >have their own LVM built in. > > First of all, thanks to all for your responses. > > Now, the storage solution I am talking about (unfortunately I'm not allowed > to be specific here, for the moment) is, what you called a high-end one, > and has some kind of LVM of it's own but from what I understood, it cannot > simply grow an existing logical volume. It has an internal RAID 5 and I've > been told that "it could have been done but it's not for the reason of > security". I can see some point in this, they want to maintain data > integrity (the way the device works internally is quite complex). So, what > happens is that when I want to "enlarge" the volume, I get (physically, in > the OS) a new device, like /dev/sdc. And now I'm on my own to grow a > filesystem, so I need to use software LVM.. You could still do this by creating a linear array which you could add a drive. But a) this can not be done while mounted and b) I'm not sure MD can do this (linear, not raid0) in 2.4 kernels. It was possible with 2.0... > > >Generally, software LVM is just needed for 2 features: > > > >Snapshots: This is available in many Raid systems, but it can be a fairly > > >expensive option, so many people prefer software snapshots. Since XFS > does not > >to my knowledge directly support snapshots, one is left to consider a > software > >LVM vs. paying for the hardware option. > > As you say, this is a fairly expensive option :) But unfortunately, LVM1 is > deadlocking with xfs_freeze - anyone has any EVMS experience? Now, do you really need xfs_freeze? You need it for snapshotting but not for online growing of volumes. If you just want to add physical units to the volume and then grow the XFS filesystem on it, you can do it while the volume is mounted and without xfs_freeze! > > >Mirroring between Raid Arrays: Some truly paranoid people use LVM to > mirror 2 > >standalone Raid Arrays to together. This is pretty rare because it is > very > >expensive to do. I doubt you are planning on doing this. > > Yes, I won't do that. > > Marek Les > Seznam.cz From owner-linux-xfs@oss.sgi.com Fri Jun 7 03:27:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57ARanC006453 for ; Fri, 7 Jun 2002 03:27:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57ARaW3006452 for linux-xfs-outgoing; Fri, 7 Jun 2002 03:27:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57ARUnC006424 for ; Fri, 7 Jun 2002 03:27:30 -0700 Received: from mail.cid.net (mail.cid.net [193.41.144.34]) 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 DAA07127 for ; Fri, 7 Jun 2002 03:29:32 -0700 (PDT) mail_from (stefan@stefan-foerster.de) Received: from uucp by mail.cid.net (Exim 3.22) with local-bsmtp id 17GGpq-0003hh-00; Fri, 07 Jun 2002 12:19:10 +0200 Received: from foerstes by abyss.st-peter.stw.uni-erlangen.de with local (Exim 3.35 #1 (Debian)) id 17GGpW-000501-00 for ; Fri, 07 Jun 2002 12:18:50 +0200 Date: Fri, 7 Jun 2002 12:18:50 +0200 From: Stefan Foerster To: linux-xfs@oss.sgi.com Subject: XFS 1.1: Too much memory consumed after updatedb Message-ID: <20020607101850.GB1287@st-peter.stw.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Now-Playing: Anastacia - Paid My Dues X-MIME-Autoconverted: from 8bit to quoted-printable by sgi.com id DAA07127 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g57ARVnC006425 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, I'm running a Debian/woody system with Kernel 2.4.18-xfs-1.1. So far, everything works very well. I have just one small problem: During normal operation, only about 20% of my 512MB RAM are used by processes, kernel and so on, the remaining memory is used for buffers etc. But whenver corn.daily executes the updatedb, memory usage increases to about 60%. The used memory is not freed after updatedb terminates. Using top or ps, I wasn't able to identify the process eating up all that memory. Where can I start searching? Ciao Stefan -- Stefan Förster Public Key: 0xBBE2A9E9 From owner-linux-xfs@oss.sgi.com Fri Jun 7 03:38:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57ActnC006680 for ; Fri, 7 Jun 2002 03:38:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57Actwv006679 for linux-xfs-outgoing; Fri, 7 Jun 2002 03:38:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.loewe-komp.de (mail.loewe-komp.de [62.156.155.230]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57AcgnC006651 for ; Fri, 7 Jun 2002 03:38:45 -0700 Received: from loewe-komp.de (pippin [192.168.169.19]) by mail.loewe-komp.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id g57AbKH14965; Fri, 7 Jun 2002 12:37:20 +0200 X-Authentication-Warning: mail.loewe-komp.de: Host pippin [192.168.169.19] claimed to be loewe-komp.de Message-ID: <3D008E35.6050902@loewe-komp.de> Date: Fri, 07 Jun 2002 12:43:01 +0200 From: Peter =?ISO-8859-1?Q?W=E4chtler?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: de, en MIME-Version: 1.0 To: Stefan Foerster CC: linux-xfs@oss.sgi.com Subject: Re: XFS 1.1: Too much memory consumed after updatedb References: <20020607101850.GB1287@st-peter.stw.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Stefan Foerster wrote: > Hi there, > > I'm running a Debian/woody system with Kernel 2.4.18-xfs-1.1. So far, > everything works very well. I have just one small problem: During > normal operation, only about 20% of my 512MB RAM are used by > processes, kernel and so on, the remaining memory is used for buffers > etc. > But whenver corn.daily executes the updatedb, memory usage increases > to about 60%. The used memory is not freed after updatedb terminates. > Using top or ps, I wasn't able to identify the process eating up all > that memory. Where can I start searching? > > Well, this is a feature of the "new" VM. Load some big apps (mozilla:) and see the shrinkage of the buffer cache. # free total used free shared buffers cached Mem: 254756 249052 5704 0 8660 75020 ^^^^^^^^^ -/+ buffers/cache: 165372 89384 Swap: 265032 40252 224780 In the morning this is normally around 80MB for me. When logging into X, the machine happily throws the pages out and everything comes back from swap sloooowly. From owner-linux-xfs@oss.sgi.com Fri Jun 7 03:52:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57AqenC006983 for ; Fri, 7 Jun 2002 03:52:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57AqdsQ006982 for linux-xfs-outgoing; Fri, 7 Jun 2002 03:52:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57AqSnC006943 for ; Fri, 7 Jun 2002 03:52:29 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g57At5j15664; Fri, 7 Jun 2002 12:55:08 +0200 Date: Fri, 7 Jun 2002 12:55:05 +0200 (CEST) From: Matteo Centonza To: cc: Subject: Re: enterprise-level experience In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Marek, > Our company is in the process of moving the production server data on a > enterprise storage servers and therefore we are considering which setup > would have the best performance and stability at the same time. Our > preliminary tests showed us that, at the filesystem level, XFS performs > best. Unfortunately, to be capable of growing the volumes we need to add > another layer - the volume manager. This increases the chances for > something to go wrong. > As I've read through the mailing list and other sources, there are only two > possible software packages on Linux - LVM and EVMS. From what I've read I > understood that LVM 1.x is feature-frozen and maybe even bugsolve-frozen in > favor of LVM2 development (see the deadlock while using xfs_freeze issue). > LVM 2.x is unstable beta and EVMS is so fresh that no real experience has > been heard of. we have made up a similar setup here. Basically it's LVM stacked on top of soft RAID 5 and is in production since June last year, with the caution of keeping away from snapshots (i've had problems at the very beginning with Oops caused by the two stacked layers and we can avoid snapshots at the moment) and making an external log (on raid 1 preferably) for performance. We are currently stick to 2.4.18 (XFS 1.1 and LVM shipped with). In the meanwhile we have performed various operations (creating, deleting, resizing (growing)) on volumes, experienced two IBM DTLA disks failure (giving us the time to replace things ;)) and all without a single problem at filesystem level. We use AMANDA as backup software and the only problem we experienced was on Oops rising from a bad interaction between xfsdump and NFS, now solved (thanks Eric and Steve). This fileserver exports via NFS, SAMBA and netatalk. I've not tried EVMS, but it seems very promising. > I understand that there's no bug-free software and no guarantee of anything > but maybe some of you have some enterprise-level experience with, say, 2+ > TB data pool on XFS and some volume manager. I appreciate any reference of > any kind, some known imcompatibilies, what mistakes to avoid.. it would > help me a lot. Our storage size is an order of magnitude less, so YMMV. Ciao, -m From owner-linux-xfs@oss.sgi.com Fri Jun 7 04:26:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57BQHnC007966 for ; Fri, 7 Jun 2002 04:26:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57BQHpc007965 for linux-xfs-outgoing; Fri, 7 Jun 2002 04:26:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57BQ2nC007936 for ; Fri, 7 Jun 2002 04:26:03 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id F3759C20F for ; Fri, 7 Jun 2002 12:56:06 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id MAA13064 for linux-xfs@oss.sgi.com; Fri, 7 Jun 2002 12:56:05 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5A55757306 for ; Fri, 7 Jun 2002 12:54:18 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 46DC925835 for ; Fri, 7 Jun 2002 12:54:18 +0200 (CEST) Message-ID: <3D0090DA.AE49A1E2@ch.sauter-bc.com> Date: Fri, 07 Jun 2002 12:54:18 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: RH7.3 installer crashes when selecting languages Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've just tried to install XFS enabled RedHat 7.3 with the SGI XFS installer. When I try to install additional languages, anaconda dies. All languages beside english are missing anyway. Thank you anyway. Simon From owner-linux-xfs@oss.sgi.com Fri Jun 7 04:34:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57BYHnC008174 for ; Fri, 7 Jun 2002 04:34:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57BYGYh008173 for linux-xfs-outgoing; Fri, 7 Jun 2002 04:34:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57BYAnC008145 for ; Fri, 7 Jun 2002 04:34:11 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA92035; Fri, 7 Jun 2002 06:36:10 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-43.corp.sgi.com [134.15.64.43]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA57779; Fri, 7 Jun 2002 06:36:08 -0500 (CDT) Subject: Re: XFS force shutdown : EFSCORRUPTED From: Stephen Lord To: =?UTF-8?Q?=E4=B8=AD=E9=87=8E=E3=80=80=E5=8D=9A?= =?UTF-8?Q?=E4=B9=8B?= Cc: linux-xfs@oss.sgi.com In-Reply-To: <011f01c20dc8$33a11450$3e68010a@bsd.tnes.nec.co.jp> References: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp> <1023369251.1701.20.camel@snafu> <011f01c20dc8$33a11450$3e68010a@bsd.tnes.nec.co.jp> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.5 Date: 07 Jun 2002 06:36:08 -0500 Message-Id: <1023449770.1178.3.camel@snafu> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g57BYBnC008146 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-06 at 21:08, 中野　博之 wrote: > Hi Steve, > > I hold factor is reading block device. As I make 8 allocation groups by > mkfs.xfs, > and I put log on allocation group1. I see that now, thanks, I misread your mkfs command. This must be an option you have added to mkfs as it is certainly not supported by the standard code. Could you send me a copy of your mkfs changes please? Steve From owner-linux-xfs@oss.sgi.com Fri Jun 7 04:52:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57BqtnC008847 for ; Fri, 7 Jun 2002 04:52:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57BqtoK008846 for linux-xfs-outgoing; Fri, 7 Jun 2002 04:52:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57BqnnC008818 for ; Fri, 7 Jun 2002 04:52:49 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA90612; Fri, 7 Jun 2002 06:54:49 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-43.corp.sgi.com [134.15.64.43]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA56302; Fri, 7 Jun 2002 06:54:48 -0500 (CDT) Subject: Re: XFS force shutdown : EFSCORRUPTED From: Stephen Lord To: Stephen Lord Cc: =?UTF-8?Q?=E4=B8=AD=E9=87=8E=E3=80=80=E5=8D=9A?= =?UTF-8?Q?=E4=B9=8B?= , linux-xfs@oss.sgi.com In-Reply-To: <1023449770.1178.3.camel@snafu> References: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp> <1023369251.1701.20.camel@snafu> <011f01c20dc8$33a11450$3e68010a@bsd.tnes.nec.co.jp> <1023449770.1178.3.camel@snafu> Content-Type: text/plain; charset=UTF-8 X-Mailer: Ximian Evolution 1.0.5 Date: 07 Jun 2002 06:54:47 -0500 Message-Id: <1023450889.1178.5.camel@snafu> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g57BqnnC008819 X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,FROM_AND_TO_SAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-06-07 at 06:36, Stephen Lord wrote: > On Thu, 2002-06-06 at 21:08, 中野　博之 wrote: > > Hi Steve, > > > > I hold factor is reading block device. As I make 8 allocation groups by > > mkfs.xfs, > > and I put log on allocation group1. > > I see that now, thanks, I misread your mkfs command. This must be an > option you have added to mkfs as it is certainly not supported by the > standard code. Could you send me a copy of your mkfs changes please? > > Steve > > Answering myself - I need to drink coffee before sending email in the morning! This is a supported option isn't it, ignore my last email. Steve From owner-linux-xfs@oss.sgi.com Fri Jun 7 04:54:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57BsUnC008988 for ; Fri, 7 Jun 2002 04:54:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57BsUBa008987 for linux-xfs-outgoing; Fri, 7 Jun 2002 04:54:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57BsQnC008959 for ; Fri, 7 Jun 2002 04:54:26 -0700 Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) 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 EAA09547 for ; Fri, 7 Jun 2002 04:56:36 -0700 (PDT) mail_from (Florian.Lindner@xgm.de) Received: from fwd07.sul.t-online.de by mailout07.sul.t-online.com with smtp id 17GICF-0004BN-01; Fri, 07 Jun 2002 13:46:23 +0200 Received: from horus.xgm.de (340060635977-0001@[217.228.139.46]) by fmrl07.sul.t-online.com with esmtp id 17GIBv-1ekEzIC; Fri, 7 Jun 2002 13:46:03 +0200 Received: from florian (unknown [192.168.0.2]) by horus.xgm.de (Postfix) with SMTP id 38437104; Fri, 7 Jun 2002 13:43:59 +0200 (CEST) Message-ID: <000901c20e19$6527e5c0$0200a8c0@florian> From: "Florian Lindner" To: "Simon Matter" Cc: References: <3D0090DA.AE49A1E2@ch.sauter-bc.com> Subject: Re: RH7.3 installer crashes when selecting languages Date: Fri, 7 Jun 2002 13:49:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 340060635977-0001@t-dialin.net X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----- Original Message ----- From: "Simon Matter" To: "linux-xfs" Sent: Friday, June 07, 2002 12:54 PM Subject: RH7.3 installer crashes when selecting languages > I've just tried to install XFS enabled RedHat 7.3 with the SGI XFS > installer. When I try to install additional languages, anaconda dies. > All languages beside english are missing anyway. Is it always that all languagues beside English are missing? The thing is that I need a German installation. The installer can be Englisch, but the packages need to be German. Florian From owner-linux-xfs@oss.sgi.com Fri Jun 7 04:59:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57BxenC009367 for ; Fri, 7 Jun 2002 04:59:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57BxedT009366 for linux-xfs-outgoing; Fri, 7 Jun 2002 04:59:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57BxPnC009336 for ; Fri, 7 Jun 2002 04:59:25 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id DE839C20D for ; Fri, 7 Jun 2002 13:41:32 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id NAA16699 for linux-xfs@oss.sgi.com; Fri, 7 Jun 2002 13:41:31 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id B86BC57306 for ; Fri, 7 Jun 2002 13:40:25 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id AB2D025835 for ; Fri, 7 Jun 2002 13:40:25 +0200 (CEST) Message-ID: <3D009BA9.43D40DB0@ch.sauter-bc.com> Date: Fri, 07 Jun 2002 13:40:25 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: linux-xfs Subject: Re: RH7.3 installer crashes when selecting languages References: <3D0090DA.AE49A1E2@ch.sauter-bc.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.6 required=5.0 tests=TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter schrieb: > > I've just tried to install XFS enabled RedHat 7.3 with the SGI XFS > installer. When I try to install additional languages, anaconda dies. > All languages beside english are missing anyway. > Oops, and GRUB was not installed correctly, switching to LILO helped. And usage of the installer as rescue CD does not work correctly (it doesn't automount the filesystems). Don't worry, there is always a way around. Just wanted to report the issues. Simon From owner-linux-xfs@oss.sgi.com Fri Jun 7 05:04:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57C4CnC009573 for ; Fri, 7 Jun 2002 05:04:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57C4CMu009572 for linux-xfs-outgoing; Fri, 7 Jun 2002 05:04:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from goliath.sylaba.poznan.pl (root@goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57C41nC009543 for ; Fri, 7 Jun 2002 05:04:04 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g56BVKR17639 for linux-xfs@oss.sgi.com.KAV; Thu, 6 Jun 2002 13:31:20 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g56BVJ617628 for ; Thu, 6 Jun 2002 13:31:19 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g56BVS712219 for ; Thu, 6 Jun 2002 13:31:28 +0200 Subject: Any workaround for samba and quotas From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 06 Jun 2002 13:31:28 +0200 Message-Id: <1023363088.11705.7.camel@venus> Mime-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I need to compile samba with quota support. Will it work if for time I compile samba I put quota headers from vanilla kernel into includes? Will samba work correctly? Regards, Olaf From owner-linux-xfs@oss.sgi.com Fri Jun 7 05:32:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57CWwnC009949 for ; Fri, 7 Jun 2002 05:32:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57CWwmA009948 for linux-xfs-outgoing; Fri, 7 Jun 2002 05:32:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57CWfnC009915 for ; Fri, 7 Jun 2002 05:32:41 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 25967C210; Fri, 7 Jun 2002 14:11:08 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id OAA18929; Fri, 7 Jun 2002 14:11:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3D63357306; Fri, 7 Jun 2002 14:11:01 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 0C3C425835; Fri, 7 Jun 2002 14:11:01 +0200 (CEST) Message-ID: <3D00A2D5.5B3D1E90@ch.sauter-bc.com> Date: Fri, 07 Jun 2002 14:11:01 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: Florian Lindner Cc: linux-xfs@oss.sgi.com Subject: Re: RH7.3 installer crashes when selecting languages References: <3D0090DA.AE49A1E2@ch.sauter-bc.com> <000901c20e19$6527e5c0$0200a8c0@florian> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Florian Lindner schrieb: > > ----- Original Message ----- > From: "Simon Matter" > To: "linux-xfs" > Sent: Friday, June 07, 2002 12:54 PM > Subject: RH7.3 installer crashes when selecting languages > > > I've just tried to install XFS enabled RedHat 7.3 with the SGI XFS > > installer. When I try to install additional languages, anaconda dies. > > All languages beside english are missing anyway. > > Is it always that all languagues beside English are missing? The thing is > that I need a German installation. The installer can be Englisch, but the > packages need to be German. > Florian I'm quite sure it's possible to install additional languages but not at install time. Simon From owner-linux-xfs@oss.sgi.com Fri Jun 7 06:14:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57DENnC010478 for ; Fri, 7 Jun 2002 06:14:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57DEN2k010477 for linux-xfs-outgoing; Fri, 7 Jun 2002 06:14:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57DEGnC010448 for ; Fri, 7 Jun 2002 06:14:16 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA92333; Fri, 7 Jun 2002 08:16:16 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA24163; Fri, 7 Jun 2002 08:16:15 -0500 (CDT) Date: Fri, 7 Jun 2002 08:14:08 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Simon Matter cc: linux-xfs Subject: Re: RH7.3 installer crashes when selecting languages In-Reply-To: <3D009BA9.43D40DB0@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 7 Jun 2002, Simon Matter wrote: > Simon Matter schrieb: > > > > I've just tried to install XFS enabled RedHat 7.3 with the SGI XFS > > installer. When I try to install additional languages, anaconda dies. > > All languages beside english are missing anyway. Hm, not sure what changes might have affected this, it's surely not intentional. :) The slides that show during installation were originally in multiple languages, but since this is just a "nice" feature, I didn't take the time to have _those_ translated. :) Perhaps something happened when I took the other languages out of anaconda-pixmaps. Sorry! > Oops, and GRUB was not installed correctly, switching to LILO helped. At least that one is in the readme! > And usage of the installer as rescue CD does not work correctly (it > doesn't automount the filesystems). Hm, didn't test this; again I'd have to look for the problem. > Don't worry, there is always a way around. Just wanted to report the > issues. The whole installer exercise this time was quick-n-dirty, I'm just happy that it _mostly_ works. :) If anyone wants to send patches to fix these problems, we can look at updating it, but I'm not going to be able to spend time on it anytime in the near future. -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 7 06:35:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57DZBnC010761 for ; Fri, 7 Jun 2002 06:35:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57DZBm6010760 for linux-xfs-outgoing; Fri, 7 Jun 2002 06:35:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ursa.xanoptix.com (host-64-65-199-187.choiceone.net [64.65.199.187]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57DZ5nC010732 for ; Fri, 7 Jun 2002 06:35:06 -0700 Received: from kend-linux.xanoptix.com ([10.20.1.45])by ursa.xanoptix.comwith esmtp(Exim 3.20 #1 (Debian))id 17GJvT-0007ur-00for ; Fri, 07 Jun 2002 09:37:11 -0400 Subject: ACLs changing for no apparent reason. (Samba 2.2.4, XFS on 2.4.17). From: "Ken D'Ambrosio" To: linux-xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 07 Jun 2002 09:37:11 -0400 Message-Id: <1023457031.27600.48.camel@kend-linux> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm not sure if this is a Samba issue or an XFS issue, but for various users, on files that are commonly shared by others, the ACLs change in weird ways, with no action (other than saving the file) on the user's part: - One user, upon saving the file, has the ACL (but not the "stock" Unix permissions) change to no permissions at all for group. - Another two users, upon saving, have the Unix permissions change to the equiv. of "chmod o-w". Any idea what might cause this to be happening, or where I should look to find more info? It's entirely reproducible, and, right now, I have a script running that "chmods" the files every couple seconds -- hack in the extreme. Unless I figure something out, I'll probably start by disabling ACLs in Samba, and see if the problem goes away. Thanks! Ken D'Ambrosio Sr. SysAdmin, Xanoptix, Inc. From owner-linux-xfs@oss.sgi.com Fri Jun 7 07:54:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57EsZnC011485 for ; Fri, 7 Jun 2002 07:54:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57EsZFS011484 for linux-xfs-outgoing; Fri, 7 Jun 2002 07:54:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57EsPnC011456 for ; Fri, 7 Jun 2002 07:54:26 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 1CFAFC001E0; Sat, 8 Jun 2002 00:56:25 +1000 (EST) Date: Sat, 8 Jun 2002 00:56:25 +1000 From: Ian Cumming To: "Ken D'Ambrosio" Cc: linux-xfs@oss.sgi.com Subject: Re: ACLs changing for no apparent reason. (Samba 2.2.4, XFS on 2.4.17). Message-ID: <20020607145625.GA28726@ids.org.au> References: <1023457031.27600.48.camel@kend-linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1023457031.27600.48.camel@kend-linux> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ken, If I remember correctly, someone asked a similar question a little while ago on the list. What you are observing is probably due to the behaviour of the way certain applications write to files. Some windows applications move/remove the old file, and create a new file with the same filename when a user "saves" an open file. Thus, you are losing the ACL on the file, so to speak. You could overcome this problem by setting a default ACL for the user group on the parent directory of any files you share. That way, new files are created with the needed ACLs to allow other users in the group to modify the files. Thus, files which are edited and "saved" by software of said behaviour will have the correct ACLs. hope this helps, Ian. On Fri, Jun 07, 2002 at 09:37:11AM -0400, Ken D'Ambrosio wrote: > I'm not sure if this is a Samba issue or an XFS issue, but for various > users, on files that are commonly shared by others, the ACLs change in > weird ways, with no action (other than saving the file) on the user's > part: > > - One user, upon saving the file, has the ACL (but not the "stock" Unix > permissions) change to no permissions at all for group. > - Another two users, upon saving, have the Unix permissions change to > the equiv. of "chmod o-w". > > Any idea what might cause this to be happening, or where I should look > to find more info? It's entirely reproducible, and, right now, I have a > script running that "chmods" the files every couple seconds -- hack in > the extreme. Unless I figure something out, I'll probably start by > disabling ACLs in Samba, and see if the problem goes away. > > Thanks! > > Ken D'Ambrosio > Sr. SysAdmin, > Xanoptix, Inc. -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Fri Jun 7 08:17:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57FHcnC011907 for ; Fri, 7 Jun 2002 08:17:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57FHclO011906 for linux-xfs-outgoing; Fri, 7 Jun 2002 08:17:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57FHWnC011878 for ; Fri, 7 Jun 2002 08:17:33 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Fri, 7 Jun 2002 11:19:33 -0400 Message-ID: From: Murthy Kambhampaty To: "'Stephan Austermuehle'" Cc: "Linux-Xfs (E-mail)" Subject: RE: xfsdump and -v or -V? Date: Fri, 7 Jun 2002 11:19:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Try "xfsrestore --help | more", which puts the version on the last line. For some odd reason "xfsrestore --help" puts the version at the top of the help screen but, "xfsrestore --help | more" puts it on the last line, obviating the need to "look through the tons of lines generated with --help". Maybe these SGI programmers are deceptively good at user interface design :), as well as at engineering this really high-performance filesystem. Murthy > -----Original Message----- > From: Stephan Austermuehle [mailto:au@hcsd.de] > Sent: Friday, June 07, 2002 04:30 > To: Mike Burger > Subject: Re: xfsdump and -v or -V? > > > On Fri, Jun 07, 2002 at 04:25:09AM -0400, Mike Burger wrote: > > > "xfsdump --help" or "--xfrestore --help" > > The first line gives you the version, and then the usage follows. > > Yes, thanks for the hint. Nevertheless I think that a separate version > flag is better because one doesn't have to look through the tons of > lines generated with --help. It's very little effort to implement > this. > > Stephan > From owner-linux-xfs@oss.sgi.com Fri Jun 7 08:24:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57FOPnC012109 for ; Fri, 7 Jun 2002 08:24:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57FOPP4012108 for linux-xfs-outgoing; Fri, 7 Jun 2002 08:24:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57FOInC012080 for ; Fri, 7 Jun 2002 08:24:19 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g57FR9B24582; Fri, 7 Jun 2002 17:27:09 +0200 Date: Fri, 7 Jun 2002 17:27:09 +0200 (CEST) From: Matteo Centonza To: Murthy Kambhampaty cc: "'Stephan Austermuehle'" , "Linux-Xfs (E-mail)" Subject: RE: xfsdump and -v or -V? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, > Try "xfsrestore --help | more", which puts the version on the last line. For > some odd reason "xfsrestore --help" puts the version at the top of the help > screen but, "xfsrestore --help | more" puts it on the last line, obviating > the need to "look through the tons of lines generated with --help". Maybe > these SGI programmers are deceptively good at user interface design :), as > well as at engineering this really high-performance filesystem. > Murthy that's because the version number is sent to stderr (and the usage to stdout); Try this one: xfsrestore --help 2>/dev/null Ciao, -m From owner-linux-xfs@oss.sgi.com Fri Jun 7 08:28:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57FSnnC012317 for ; Fri, 7 Jun 2002 08:28:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57FSnd2012316 for linux-xfs-outgoing; Fri, 7 Jun 2002 08:28:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57FSAnC012280 for ; Fri, 7 Jun 2002 08:28:10 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 08:35:46 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F18A@nasexs1.meridian-data.com> From: Dale Stephenson To: "'linux-lvm@sistina.com'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: [linux-lvm] How well tested is the snapshot feature? Date: Fri, 7 Jun 2002 08:35:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C20E38.FCE21E70" X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,MIME_NULL_BLOCK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C20E38.FCE21E70 Content-Type: text/plain; charset="iso-8859-1" I'm one of those people using LVM1 snapshots mostly successfully with XFS. However: 1) I'm using a process flag hack to keep XFS's filesystem freeze from snagging writes by kupdated, xfs_freeze, and fsync_dev/fsync_dev_lockfs. I've also removed the xfs_unmountfs_writesb() call from xfs_thaw(). I'm included the two patches I use, which apply against XFS 1.1. I've directed most of my discussion of this to the XFS list, as the locking mechanism is filesystem-specific. The only filesystem calls that the lvm driver makes with the VFS patch are fsync_dev_lockfs() and unlockfs(). The COW activity itself is done through brw_kiovec(), which I believe should not go through the file system at all (though it seems to cause lots of indirect file system activity through kupdated). device-mapper (LVM2) uses (with VFS enhancement) the very same fsync_dev_lockfs() and unlockfs() calls. However, the COW activity is not handled through brw_kiovec(), instead being transferred to device-mapper's kcopyd. I haven't worked with LVM2 yet, so it's certainly possible that kcopyd allieviates the pressure on kupdated. But in theory I would expect it to be susceptible to the same file system deadlocks experienced by LVM1. 2) I'm still seeing an occasional xfs_freeze deadlock. xfs_unmountfs_writesb() (from xfs_freeze) and kupdated get stuck on separate pagebuf locks. It occurs with multiple snapshots and streaming writes to the snapshot source over both samba and nfs. Using these patches, I haven't seen any oops problems, only the odd deadlock. You also have to mount the XFS snapshots with nouuid and norecovery options. Another approach that will work is to forget using the VFS patch entirely, and use writeable snapshots (available for 1.1, LVM2, and working patches have been posted to the list for 1.0.x). If the snapshot is writeable you can just mount with nouuid (or change the UUID of the snapshot), mount the snapshot and let XFS recovery do its stuff. This has the advantage of not running into any locking problems whatsoever. The disadvantage is that the filesystem isn't clean, so instead of having a snapshot of the filesystem at that point of time, you have the filesystem as if the power had suddenly failed at that point in time. Dale Stephenson steph@snapserver.com > -----Original Message----- > From: Joe Thornber [mailto:joe@fib011235813.fsnet.co.uk] > Sent: Friday, June 07, 2002 2:45 AM > To: linux-lvm@sistina.com > Subject: Re: [linux-lvm] How well tested is the snapshot feature? > > > On Fri, Jun 07, 2002 at 11:37:05AM +0200, Stephan Austermuehle wrote: > > On Fri, Jun 07, 2002 at 10:33:00AM +0100, Joe Thornber wrote: > > > > > Did you apply the VFS patch from the 1.0.3 release ? This makes > > > sure that the filesystem flushes a consistent state to the disk > > > before the snapshot is setup. > > > > Do you mean the VFS lock patch? Yes, it is applied. > > Curious, as far as I know people are using LVM1 snapshots successfully > with xfs. > > - Joe ------_=_NextPart_000_01C20E38.FCE21E70 Content-Type: application/octet-stream; name="no_freeze.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="no_freeze.patch" --- linux.old/fs/xfs/xfs_log.c Wed Mar 20 04:51:25 2002 +++ linux/fs/xfs/xfs_log.c Sat Mar 30 00:38:58 2002 @@ -324,6 +324,11 @@ int rval; xlog_t *log =3D mp->m_log; =20 + if (XFS_MTOVFS(mp)->vfs_flag & VFS_RDONLY) { + printk("ignoring xfs_log_force on a read-only filesystem\n"); + return 0; + } + #if defined(DEBUG) || defined(XLOG_NOLOG) if (! xlog_debug && xlog_devt =3D=3D log->l_dev) return 0; --- linux.old/fs/xfs/xfs_mount.c Sat Mar 9 03:21:26 2002 +++ linux/fs/xfs/xfs_mount.c Sat Mar 30 00:39:39 2002 @@ -1680,6 +1680,7 @@ int level) { int s =3D mutex_spinlock(&mp->m_freeze_lock); + unsigned long flags; =20 mp->m_frozen =3D level; mutex_spinunlock(&mp->m_freeze_lock, s); @@ -1688,13 +1689,27 @@ while (atomic_read(&mp->m_active_trans) > 0) delay(100); } + + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; + + /* make sure the log is written after we freeze */ + xfs_log_force(mp, 0, XFS_LOG_FORCE|XFS_LOG_SYNC); + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } } =20 void xfs_finish_freeze( xfs_mount_t *mp) { - int s =3D mutex_spinlock(&mp->m_freeze_lock); + int s; + + if (current->flags & PF_NO_FREEZE) return; + + s =3D mutex_spinlock(&mp->m_freeze_lock); =20 if (mp->m_frozen) { mp->m_frozen =3D 0; @@ -1713,6 +1728,14 @@ { int s; int do_lock =3D 0; + + /* some processes must not freeze - eg. a lvcreate or kupdated, otherwise + lvcreate locks solid as it tries to flush blocks, and that gets here */ + if (current->flags & PF_NO_FREEZE) { + if (level =3D=3D XFS_FREEZE_TRANS) + atomic_inc(&mp->m_active_trans); + return; + } =20 if (!mp->m_frozen) { if (level =3D=3D XFS_FREEZE_TRANS) --- linux.old/fs/buffer.c Sat Mar 30 00:28:28 2002 +++ linux/fs/buffer.c Sat Mar 30 00:40:54 2002 @@ -392,6 +392,14 @@ =20 int fsync_dev(kdev_t dev) { + int ret; + unsigned long flags; + + flags =3D current->flags; + /* we set this flag to prevent the XFS pagebuf code causing a deadlock=20 + during a sync - a frozen filesystem should freeze only new IO, not + existing data waiting to be flushed */ + current->flags |=3D PF_NO_FREEZE; sync_buffers(dev, 0); =20 lock_kernel(); @@ -400,7 +408,13 @@ sync_supers(dev); unlock_kernel(); =20 - return sync_buffers(dev, 1); + ret =3D sync_buffers(dev, 1); + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + + return ret; } =20 /* @@ -3038,6 +3052,9 @@ siginitsetinv(¤t->blocked, sigmask(SIGCONT) | sigmask(SIGSTOP)); recalc_sigpending(tsk); spin_unlock_irq(&tsk->sigmask_lock); + + /* kupdated can also do IO of old blocks on a frozen filesystem */ + current->flags |=3D PF_NO_FREEZE; =20 complete((struct completion *)startup); =20 --- linux.old/include/linux/sched.h Sat Mar 30 00:30:23 2002 +++ linux/include/linux/sched.h Fri Mar 29 23:34:13 2002 @@ -428,6 +428,7 @@ #define PF_FREE_PAGES 0x00002000 /* per process page freeing */ #define PF_NOIO 0x00004000 /* avoid generating further I/O */ #define PF_FSTRANS 0x00008000 /* inside a filesystem transaction */ +#define PF_NO_FREEZE 0x01000000 /* ignore fs freeze flag */ =20 #define PF_USEDFPU 0x00100000 /* task used FPU this quantum (SMP) */ =20 ------_=_NextPart_000_01C20E38.FCE21E70 Content-Type: application/octet-stream; name="no_freeze_lockfs.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="no_freeze_lockfs.patch" --- linux/fs/buffer.c.old Tue Apr 2 10:47:30 2002 +++ linux/fs/buffer.c Tue Apr 2 10:48:35 2002 @@ -428,6 +428,9 @@ =20 int fsync_dev_lockfs(kdev_t dev) { + unsigned long flags; + int ret; + /* you are not allowed to try locking all the filesystems ** on the system, your chances of getting through without ** total deadlock are slim to none. @@ -435,6 +438,9 @@ if (!dev) return fsync_dev(dev) ; =20 + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; + sync_buffers(dev, 0); =20 lock_kernel(); @@ -451,7 +457,13 @@ sync_supers_lockfs(dev) ; unlock_kernel(); =20 - return sync_buffers(dev, 1) ; + ret =3D sync_buffers(dev, 1) ; + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + + return ret; } =20 asmlinkage long sys_sync(void) @@ -1171,13 +1183,23 @@ void balance_dirty(void) { int state =3D balance_dirty_state(); + unsigned long flags; =20 if (state < 0) return; =20 /* If we're getting into imbalance, start write-out */ spin_lock(&lru_list_lock); + + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; + write_some_buffers(NODEV); + + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + =20 /* * And if we're _really_ out of balance, wait for --- linux/fs/xfs/xfs_fsops.c.old Fri Apr 26 18:10:29 2002 +++ linux/fs/xfs/xfs_fsops.c Fri Apr 26 18:13:16 2002 @@ -551,6 +551,7 @@ vfs_t *vfsp; /*REFERENCED*/ int error; + unsigned long flags; =20 vfsp =3D XFS_MTOVFS(mp); =20 @@ -565,6 +566,10 @@ =20 /* Pause transaction subsystem */ xfs_start_freeze(mp, XFS_FREEZE_TRANS); +=09 + /* don't freeze the freeze */ + flags =3D current->flags; + current->flags |=3D PF_NO_FREEZE; =20 /* Flush any remaining inodes into buffers */ VFS_SYNC(vfsp, SYNC_ATTR|SYNC_WAIT, sys_cred, error); @@ -579,6 +584,10 @@ xfs_log_unmount_write(mp); xfs_unmountfs_writesb(mp); =20 + if (! (flags & PF_NO_FREEZE)) { + current->flags &=3D ~PF_NO_FREEZE; + } + return 0; } =20 @@ -587,7 +596,6 @@ xfs_fs_thaw( xfs_mount_t *mp) { - xfs_unmountfs_writesb(mp); xfs_finish_freeze(mp); return 0; } ------_=_NextPart_000_01C20E38.FCE21E70-- From owner-linux-xfs@oss.sgi.com Fri Jun 7 08:36:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57FaunC013291 for ; Fri, 7 Jun 2002 08:36:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57FauRB013290 for linux-xfs-outgoing; Fri, 7 Jun 2002 08:36:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57FapnC013260 for ; Fri, 7 Jun 2002 08:36:52 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA93723 for ; Fri, 7 Jun 2002 10:38:53 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA60904 for ; Fri, 7 Jun 2002 10:38:52 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA41264 for linux-xfs@oss.sgi.com; Fri, 7 Jun 2002 10:38:52 -0500 (CDT) Date: Fri, 7 Jun 2002 10:38:52 -0500 (CDT) From: Dean Roehrich Message-Id: <200206071538.KAA41264@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - fix _ACL_XFS_IACCESS X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Jun 7 08:38:24 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121061a linux/fs/xfs/xfs_acl.h - 1.12 - fix the logic in _ACL_XFS_IACCESS From owner-linux-xfs@oss.sgi.com Fri Jun 7 09:18:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57GI0nC013945 for ; Fri, 7 Jun 2002 09:18:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57GI0s3013944 for linux-xfs-outgoing; Fri, 7 Jun 2002 09:18:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03ps.bigpond.com (mta03ps.bigpond.com [144.135.25.135]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57GHnnC013910 for ; Fri, 7 Jun 2002 09:17:50 -0700 Message-Id: <200206071617.g57GHnnC013910@oss.sgi.com> Received: from there ([144.135.25.75]) by mta03ps.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GXCG1000.ER8; Sat, 8 Jun 2002 02:19:48 +1000 Received: from CPE-144-137-133-221.qld.bigpond.net.au ([144.137.133.221]) by PSMAM03.mailsvc.email.bigpond.com(MailRouter V3.0m 89/877144); 08 Jun 2002 02:19:48 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Simon Matter , Marek.Les@firma.seznam.cz Subject: Re: enterprise-level experience Date: Sat, 8 Jun 2002 02:19:43 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <3D007CB9.8C9E5ABF@ch.sauter-bc.com> In-Reply-To: <3D007CB9.8C9E5ABF@ch.sauter-bc.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 7 Jun 2002 19:28, Simon Matter wrote: > > As you say, this is a fairly expensive option :) But unfortunately, LVM1 > > is deadlocking with xfs_freeze - anyone has any EVMS experience? > > Now, do you really need xfs_freeze? You need it for snapshotting but not > for online growing of volumes. If you just want to add physical units to > the volume and then grow the XFS filesystem on it, you can do it while > the volume is mounted and without xfs_freeze! This is correct - if all your wanting to do is grow volumes xfs_freeze is not needed. In fact xfs_freeze is not needed for snapshots either as long as you have a working implementation of the LVM VFS-lock patch. I have had success with XFS & snapshotting - but I do find it hit & miss at times. Everything from the compiler version, CVS date to whether there was a full moon the night I compiled the kernel. My advice: test, test & test again. An example is that when compiling LVM1 with the VFS-lock patch & XFS with the buggy RedHat 7.2 gcc, everything worked fine. If I used xfs_freeze then things would deadlock. When using kgcc it would not matter if I was using the VFS-lock or xfs_freeze it would either Oops or deadlock. I have a couple of very stable kernels with respect to LVM snapshots and XFS but I have some deadly ones as well. After spending quite some time playing around, discussing issues with the XFS developers, the LVM developers and others - a couple of issues were put down to the 2.4.18 VM. Some people have reported better success when not using the standard Linux tree. The reason I have concluded is that XFS seems to be very VM intensive (maybe because of the delayed writes) and exercises the devils that the other filesystems never touch. If you really need snapshots and you havn't found the VFS-lock route or the xfs_freeze route to work for you there are other ways that people have approached snapshots. There is a patch for writable snapshots for LVM 1.0.? that allows a snapshot to be made without either the VFS-lock patch or xfs_freeze. This allows you to take an inconsistant snapshot and have the snaphot fscked during mount - this method is deadlock free; however, it may not be suitable for what you are trying to achieve. What I have also done is late at night kill any process that is reading/writing to the volume (samba/NFS) then umount the volume and then do a snapshot; then mount and restart processes. In my situation it is done at 04:00 in the morning and it doesn't affect anyone - but again it may not be suitable for what you are trying to achieve. As for EVMS, I tried it many months ago, and for memory it had simular issues to LVM with respect to snapshots at the time. Unfortunately, I didn't take it any further, deciding to run with the devil I knew, rather than learn another. So I cannot give any comments on the current state of EVMS. I hope this helps someone. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Fri Jun 7 10:29:24 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57HTOnC015455 for ; Fri, 7 Jun 2002 10:29:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57HTOHc015454 for linux-xfs-outgoing; Fri, 7 Jun 2002 10:29:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57HTCnC015304 for ; Fri, 7 Jun 2002 10:29:13 -0700 Received: from localhost ([80.1.68.230]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020606231436.JEXE2755.mta05-svc.ntlworld.com@localhost>; Fri, 7 Jun 2002 00:14:36 +0100 Content-Type: text/plain; charset="iso-8859-1" From: mark Reply-To: mark.newman2@ntlworld.com Organization: mark To: Nathan Scott Subject: Re: SOLVED cp -p problem Date: Fri, 7 Jun 2002 01:11:15 +0100 User-Agent: KMail/1.4.1 Cc: "'linux-xfs@oss.sgi.com'" References: <200206061528.24033.mark.newman2@ntlworld.com> <20020606224848.GA479@frodo> In-Reply-To: <20020606224848.GA479@frodo> MIME-Version: 1.0 Message-Id: <200206070111.15856.mark.newman2@ntlworld.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g57HTDnC015305 X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thursday 06 June 2002 23:48, Nathan Scott wrote: > On Thu, Jun 06, 2002 at 03:28:24PM +0100, mark wrote: > > Hi > > > > Sorry to waste peoples time, this is a Gentoo Linux configuration > > problem. > > Hmm - thats not really fair on Gentoo. This is a workaround, but the > underlying problem remains, and is not Gentoo related. > No, I was not blaming Gentoo at all, merely the way I had it configured. I felt I should not have had an ACL flag if I wasnt using it.. The cp binary I sent you was compiled using the ACL flag. I have just looked at the changelog for fileutils under Gentoo and it has the following 03 May 2002; Daniel Robbins : Added acl.c.diff to fix compilation with nls disabled. Blocke is sending this fix upstream to acl.bestbits.at. No rev bump -- no need for a recompile if it worked for people. The diff is as follows, --- acl.c.orig Fri May 3 23:47:34 2002 +++ acl.c Fri May 3 23:47:43 2002 @@ -26,6 +26,7 @@ # include # define _(Text) gettext (Text) #else +# include # define _(Text) Text #endif If I'm honest I dont really understand this but it may help you to understand why my cp binary is different. This patch was only applied if I set a flag as ACL > > Basically Gentoo builds all its apps from source using an 'ebuild' > > script which controls the configure, make, make install. A fellow Gentoo > > user has provided the solution There was a flag in one of my config > > files which was causing cp to be built against acl in some way. Since I > > had no real need of acl just removing this flag and rebuilding fileuttils > > has solved the problem > > > > I am not saying there is a problem with acl or not, to be honest it is > > not a subject I have spent any time learning about so it could be just > > that I misconfigured xfs in some way. Anyway all seems fine now. > > You haven't misconfigured XFS - I'm able to reproduce this with the > cp binary you sent me last night. It is definately a problem in > ACL land, but not clear yet whether its XFS, libacl.so or the patch > to fileutils which is causing it. I will keep trying to figure this > out... > > thanks. No probs. If I can provide further info let me know. Although I am now getting out of my depth. Mark From owner-linux-xfs@oss.sgi.com Fri Jun 7 10:29:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57HTanC016244 for ; Fri, 7 Jun 2002 10:29:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57HTa5N016224 for linux-xfs-outgoing; Fri, 7 Jun 2002 10:29:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57HTSnC015453 for ; Fri, 7 Jun 2002 10:29:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA94438; Fri, 7 Jun 2002 12:31:29 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA16063; Fri, 7 Jun 2002 12:31:29 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id MAA56449; Fri, 7 Jun 2002 12:31:28 -0500 (CDT) Message-Id: <200206071731.MAA56449@slobber.americas.sgi.com> To: "Francis Qu" cc: "Linux XFS" Subject: Re: dm_handle_to_path causes system crash Date: Fri, 07 Jun 2002 12:31:28 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "Francis Qu" >Linux-2.4.18-xfs >dmapi: 2.0.1 > >dm_handle_to_path -> getcwd --> sys_cwd --> __d_path ---> crash > >Thanks, >Francis Francis, I don't see this one in the latest kernel&cmds tree. Here's what I tried, using tools from the dmapi test suite: # mount -o dmapi /dev/hda12 /mnts/dmi1 # mkdir /mnts/dmi1/d2 # touch /mnts/dmi1/d2/P1 # path_to_handle /mnts/dmi1/d2 a82086856f69f7c20e000000010000004400000000000000 # path_to_handle /mnts/dmi1/d2/P1 a82086856f69f7c20e000000010000004500000000000000 # umount /mnts/dmi1 # mount -o dmapi /dev/hda12 /mnts/dmi1 # handle_to_path a82086856f69f7c20e000000010000004400000000000000 \ a82086856f69f7c20e000000010000004500000000000000 dm_handle_to_path failed, (2) No such file or directory # ls /mnts/dmi1/d2 P1 # handle_to_path a82086856f69f7c20e000000010000004400000000000000 \ a82086856f69f7c20e000000010000004500000000000000 rlenp is 17, pathbufp is /mnts/dmi1/d2/P1 # Note, the current implementation of handle_to_path won't find the file if the file isn't already in the dcache. But still, I don't see a core dump or crash. Dean From owner-linux-xfs@oss.sgi.com Fri Jun 7 10:46:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57Hk5nC021843 for ; Fri, 7 Jun 2002 10:46:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57Hk5V8021842 for linux-xfs-outgoing; Fri, 7 Jun 2002 10:46:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57HjwnC021814 for ; Fri, 7 Jun 2002 10:45:59 -0700 Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by mail7.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17GNqF-0007LX-00; Fri, 07 Jun 2002 18:48:03 +0100 Received: from modem-4015.tiger.dialup.pol.co.uk ([62.136.223.175] helo=reti) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17GNqE-000412-00; Fri, 07 Jun 2002 18:48:02 +0100 Received: from joe by reti with local (Exim 3.35 #1 (Debian)) id 17GNpu-0000IQ-00; Fri, 07 Jun 2002 18:47:42 +0100 Date: Fri, 7 Jun 2002 18:47:32 +0100 To: linux-lvm@sistina.com Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: [linux-lvm] How well tested is the snapshot feature? Message-ID: <20020607174732.GA1076@fib011235813.fsnet.co.uk> References: <2D0AFEFEE711D611923E009027D39F2B02F18A@nasexs1.meridian-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F18A@nasexs1.meridian-data.com> User-Agent: Mutt/1.3.28i From: Joe Thornber X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 07, 2002 at 08:35:44AM -0700, Dale Stephenson wrote: > device-mapper (LVM2) uses (with VFS enhancement) the very same > fsync_dev_lockfs() and unlockfs() calls. However, the COW activity is not > handled through brw_kiovec(), instead being transferred to device-mapper's > kcopyd. I haven't worked with LVM2 yet, so it's certainly possible that > kcopyd allieviates the pressure on kupdated. But in theory I would expect > it to be susceptible to the same file system deadlocks experienced by LVM1. I'm not sure what this kupdated interaction that you mention could be. Both brw_kiovec and kcopyd stay well away from both the filesystem and the buffer cache. > 2) I'm still seeing an occasional xfs_freeze deadlock. > xfs_unmountfs_writesb() (from xfs_freeze) and kupdated get stuck on separate > pagebuf locks. It occurs with multiple snapshots and streaming writes to > the snapshot source over both samba and nfs. Which kernel are you using ? I've found that 2.4.18 can be easily persuaded to deadlock by having two processes making GFP_NOIO requests for memory whilst the system is short of free memory. 2.4.19-pre9 works fine. - Joe From owner-linux-xfs@oss.sgi.com Fri Jun 7 11:00:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57I02nC022128 for ; Fri, 7 Jun 2002 11:00:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57I01jj022127 for linux-xfs-outgoing; Fri, 7 Jun 2002 11:00:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57HxrnC022090 for ; Fri, 7 Jun 2002 10:59:54 -0700 Received: from localhost ([80.1.68.230]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020607180200.IPLG295.mta03-svc.ntlworld.com@localhost>; Fri, 7 Jun 2002 19:02:00 +0100 Content-Type: text/plain; charset="iso-8859-1" From: mark Reply-To: mark.newman2@ntlworld.com Organization: mark To: Nathan Scott Subject: Re: probs with cp -p Date: Fri, 7 Jun 2002 18:56:43 +0100 User-Agent: KMail/1.4.1 Cc: linux-xfs@oss.sgi.com References: <200206032201.36167.mark.newman2@ntlworld.com> <200206061219.47056.mark.newman2@ntlworld.com> <20020607013327.GA442@frodo> In-Reply-To: <20020607013327.GA442@frodo> MIME-Version: 1.0 Message-Id: <200206071856.43256.mark.newman2@ntlworld.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g57HxsnC022091 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Friday 07 June 2002 02:33, Nathan Scott wrote: > hi Mark, > > On Thu, Jun 06, 2002 at 12:19:47PM +0100, mark wrote: > > acl_free(0x0805476c, 32768, 0x0805476c, 0, 0xbffff6a4) = 0 > > acl_get_file(0xbffffce0, 16384, 0x0805476c, 0, 0xbffff6a4) = 0x08054784 > > acl_set_file(0x08054710, 16384, 0x08054784, 0, 0xbffff6a4) = -1 > > __ctype_get_mb_cur_max(256, 0x08054140, 0, 0x4002a180, 0x4002b574) = 1 > > dcgettext(0, 0x0805294a, 5, 0x4009fb14, 0) = 0x0805294a > > dcgettext(0, 0x0805294c, 5, 0x0804f01f, 0) = 0x0805294c > > dcgettext(0, 0x08052606, 5, 0xbffff68c, 0x08054140) = 0x08052606 > > __errno_location() = 0x40157c20 > > error(0, 22, 0x08052606, 0x08054140, 0x08054710cp: preserving permissions > > for `/home/usr/local/share/doc': Invalid argument > > ) = 0 > > OK, I know what is happening here now - it seems to me that libacl > is doing some unholy things, including attempting to set default > ACLs with no ACEs. We will change XFS to be more graceful in the > presense of this condition, and take this up with the libacl and > fileutils patch author. > > Thanks for reporting and helping resolve the problem. The fix to > prevent these warning messages will show up in XFS CVS shortly. > > cheers. No problem. Thanks for the help and feedback. Mark From owner-linux-xfs@oss.sgi.com Fri Jun 7 11:22:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57IMUnC022454 for ; Fri, 7 Jun 2002 11:22:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57IMUhH022453 for linux-xfs-outgoing; Fri, 7 Jun 2002 11:22:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57IMQnC022425 for ; Fri, 7 Jun 2002 11:22:26 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id LAA02372 for ; Fri, 7 Jun 2002 11:24:30 -0700 (PDT) mail_from (npollitt@serapis.engr.sgi.com) Received: from serapis.engr.sgi.com (serapis.engr.sgi.com [163.154.20.29]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id LAA72977 for ; Fri, 7 Jun 2002 11:23:14 -0700 (PDT) Received: (from npollitt@localhost) by serapis.engr.sgi.com (8.11.6/8.9.3) id g57INE625557 for linux-xfs@oss.sgi.com; Fri, 7 Jun 2002 11:23:14 -0700 Date: Fri, 7 Jun 2002 11:23:13 -0700 From: Nick Pollitt To: linux-xfs@oss.sgi.com Subject: RH7.3 and Grub? Message-ID: <20020607112313.D25182@serapis.engr.sgi.com> Reply-To: npollitt@engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is grub supported yet on the 7.3 XFS installer? Thanks, Nick From owner-linux-xfs@oss.sgi.com Fri Jun 7 11:24:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57IO3nC022515 for ; Fri, 7 Jun 2002 11:24:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57IO3a1022514 for linux-xfs-outgoing; Fri, 7 Jun 2002 11:24:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from nasexs1.meridian-data.com ([208.0.185.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57INsnC022485 for ; Fri, 7 Jun 2002 11:23:54 -0700 Received: by nasexs1.meridian-data.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Jun 2002 11:31:31 -0700 Message-ID: <2D0AFEFEE711D611923E009027D39F2B02F18C@nasexs1.meridian-data.com> From: Dale Stephenson To: "'linux-lvm@sistina.com'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: [linux-lvm] How well tested is the snapshot feature? Date: Fri, 7 Jun 2002 11:31:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Joe Thornber writes: > On Fri, Jun 07, 2002 at 08:35:44AM -0700, Dale Stephenson wrote: > > device-mapper (LVM2) uses (with VFS enhancement) the very same > > fsync_dev_lockfs() and unlockfs() calls. However, the COW > activity is not > > handled through brw_kiovec(), instead being transferred to > device-mapper's > > kcopyd. I haven't worked with LVM2 yet, so it's certainly > possible that > > kcopyd allieviates the pressure on kupdated. But in theory > I would expect > > it to be susceptible to the same file system deadlocks > experienced by LVM1. > > I'm not sure what this kupdated interaction that you mention could be. > Both brw_kiovec and kcopyd stay well away from both the filesystem > and the buffer cache. > Subjective impression. kupdated always seems to be in D state with streaming writes and snapshots, more so than a similar stream directed at LVM + XFS without snapshots. While brw_kiovec and kcopyd stay away from the filesystem, the filesystem doesn't stay away from them! When kupdated writes out something to a LV with multiple snapshots, multiple COW can occur. Since with device-mapper the COW is done by a separate process (kcopyd), I'd expect kupdated to not spend so much time in D. Plus device-mapper's supposed to be faster. But when I say I expect "it" to be susceptible I'm talking about the system, NOT the COW activity. I really haven't had a problem with a thread getting stuck while trying to do COW. The problem I'm seeing now is with xfs_unmountfs_writesb() as called from xfs_fs_freeze(). I've only seen the problem with (multiple) snapshots, but brw_kiovec() isn't involved in the deadlock and fsync_dev_lockfs() is. So I would expect LVM2 (device-mapper) to be susceptible to the same problem, at least in theory. > > 2) I'm still seeing an occasional xfs_freeze deadlock. > > xfs_unmountfs_writesb() (from xfs_freeze) and kupdated get > stuck on separate > > pagebuf locks. It occurs with multiple snapshots and > streaming writes to > > the snapshot source over both samba and nfs. > > Which kernel are you using ? I've found that 2.4.18 can be easily > persuaded to deadlock by having two processes making GFP_NOIO requests > for memory whilst the system is short of free memory. 2.4.19-pre9 > works fine. > 2.4.18. I've been able to induce memory deadlocks (processes in D state descending from alloc_pages) on my 64K box with multiple snapshots, but haven't been too worried about that since I expect it. On a 1 GB system I haven't seen the deadlocks, or at least recognized it as such. The one I'm seeing has a ton of writing processes waiting on check_frozen (which is fine), kupdated stuck on pagebuf_lock(), and xfs_freeze waiting on _pagebuf_wait_unpin(). Is this something you've seen? I hope to have this tested on 2.4.19-pre10 Real Soon Now. Dale Stephenson steph@snapserver.com From owner-linux-xfs@oss.sgi.com Fri Jun 7 11:43:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57IhxnC023038 for ; Fri, 7 Jun 2002 11:43:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57IhxiS023037 for linux-xfs-outgoing; Fri, 7 Jun 2002 11:43:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from pinga.salk.edu (pinga.salk.edu [192.31.153.187]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57IhsnC023009 for ; Fri, 7 Jun 2002 11:43:54 -0700 Received: from xena.salk.ccmi (buckbeak.salk.edu [192.31.153.184]) by pinga.salk.edu (8.12.2/8.12.2) with SMTP id g57IjoVw001877; Fri, 7 Jun 2002 11:45:50 -0700 Date: Fri, 7 Jun 2002 11:45:50 -0700 From: David Chambers To: npollitt@engr.sgi.com Cc: linux-xfs@oss.sgi.com Subject: Re: RH7.3 and Grub? Message-Id: <20020607114550.3920a63a.davidc@ccmi.salk.edu> In-Reply-To: <20020607112313.D25182@serapis.engr.sgi.com> References: <20020607112313.D25182@serapis.engr.sgi.com> X-Mailer: Sylpheed version 0.7.6claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Looks like it. I had no problems with it, anyhow! - David On Fri, 7 Jun 2002 11:23:13 -0700 Nick Pollitt wrote: > Is grub supported yet on the 7.3 XFS installer? > > Thanks, > Nick > From owner-linux-xfs@oss.sgi.com Fri Jun 7 11:54:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57IsdnC023269 for ; Fri, 7 Jun 2002 11:54:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57Isdgd023268 for linux-xfs-outgoing; Fri, 7 Jun 2002 11:54:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57IsYnC023240 for ; Fri, 7 Jun 2002 11:54:34 -0700 Received: from amanda.carb.nist.gov ([129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GXCNCA00.064; Fri, 7 Jun 2002 14:57:46 -0400 Subject: Re: RH7.3 and Grub? From: "Jonathan F. Dill" To: David Chambers Cc: npollitt@engr.sgi.com, Linux XFS Mailing List In-Reply-To: <20020607114550.3920a63a.davidc@ccmi.salk.edu> References: <20020607112313.D25182@serapis.engr.sgi.com> <20020607114550.3920a63a.davidc@ccmi.salk.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: UMBI CARB X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 07 Jun 2002 14:56:38 -0400 Message-Id: <1023476200.1908.12.camel@amanda.carb.nist.gov> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I tried switching from LILO to GRUB on 2 upgrades from RH 7.2 to RH 7.3 and it didn't work for me. On Fri, 2002-06-07 at 14:45, David Chambers wrote: > Looks like it. I had no problems with it, anyhow! > > - David > > On Fri, 7 Jun 2002 11:23:13 -0700 > Nick Pollitt wrote: > > > Is grub supported yet on the 7.3 XFS installer? > > > > Thanks, > > Nick > > -- Jonathan F. Dill UMBI CARB From owner-linux-xfs@oss.sgi.com Fri Jun 7 11:54:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57IsxnC023302 for ; Fri, 7 Jun 2002 11:54:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57IsxhH023301 for linux-xfs-outgoing; Fri, 7 Jun 2002 11:54:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57IssnC023273 for ; Fri, 7 Jun 2002 11:54:54 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA95358; Fri, 7 Jun 2002 13:56:56 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA54421; Fri, 7 Jun 2002 13:56:55 -0500 (CDT) Subject: Re: RH7.3 and Grub? From: Eric Sandeen To: npollitt@engr.sgi.com Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020607112313.D25182@serapis.engr.sgi.com> References: <20020607112313.D25182@serapis.engr.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Jun 2002 13:54:45 -0500 Message-Id: <1023476085.25892.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nick - There were problems in the 7.2 installer with things not getting synced out to disk properly, so the installer has a big "sync; sleep 30; sync; sleep 30" in the grub path. :) It worked for me when I tested it, but there have been reports of failure. So in essence, it's not working very well; the sleep/sync trick helps, so it might work for you. -Eric On Fri, 2002-06-07 at 13:23, Nick Pollitt wrote: > Is grub supported yet on the 7.3 XFS installer? > > Thanks, > Nick From owner-linux-xfs@oss.sgi.com Fri Jun 7 12:01:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57J1DnC023664 for ; Fri, 7 Jun 2002 12:01:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57J1DSW023663 for linux-xfs-outgoing; Fri, 7 Jun 2002 12:01:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57J17nC023635 for ; Fri, 7 Jun 2002 12:01:07 -0700 Received: from amanda.carb.nist.gov ([129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GXCNN700.U3Q; Fri, 7 Jun 2002 15:04:19 -0400 Subject: Re: RH7.3 and Grub? From: "Jonathan F. Dill" To: Eric Sandeen Cc: npollitt@engr.sgi.com, Linux XFS Mailing List In-Reply-To: <1023476085.25892.4.camel@stout.americas.sgi.com> References: <20020607112313.D25182@serapis.engr.sgi.com> <1023476085.25892.4.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: UMBI CARB X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 07 Jun 2002 15:03:13 -0400 Message-Id: <1023476594.1907.15.camel@amanda.carb.nist.gov> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The symptom that I got with both "upgrades" that I did was that GRUB complained that some files were missing and crapped out to the interactive grub> prompt. If I try it again, I'll write down the filenames. On Fri, 2002-06-07 at 14:54, Eric Sandeen wrote: > Hi Nick - > > There were problems in the 7.2 installer with things not getting synced > out to disk properly, so the installer has a big "sync; sleep 30; sync; > sleep 30" in the grub path. :) > > It worked for me when I tested it, but there have been reports of > failure. > > So in essence, it's not working very well; the sleep/sync trick helps, > so it might work for you. > > -Eric > > On Fri, 2002-06-07 at 13:23, Nick Pollitt wrote: > > Is grub supported yet on the 7.3 XFS installer? > > > > Thanks, > > Nick -- Jonathan F. Dill UMBI CARB From owner-linux-xfs@oss.sgi.com Fri Jun 7 12:30:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57JUXnC024018 for ; Fri, 7 Jun 2002 12:30:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57JUXMr024017 for linux-xfs-outgoing; Fri, 7 Jun 2002 12:30:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lists.samba.org (samba.sourceforge.net [198.186.203.85]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57JUSnC023989 for ; Fri, 7 Jun 2002 12:30:28 -0700 Received: by lists.samba.org (Postfix, from userid 1001) id 1074049DA; Fri, 7 Jun 2002 12:36:22 -0700 (PDT) Date: Fri, 7 Jun 2002 12:36:22 -0700 To: Christoph Hellwig Cc: Jeremy Allison , Jan Kara , Nathan Scott , "Ralf G. R. Bergs" , linux-xfs@oss.sgi.com, samba@lists.samba.org Subject: Re: [Samba] Re: Problems compiling Samba 2.2.4 with quota under Debian stable Message-ID: <20020607123622.T5188@va.samba.org> References: <20020529085106.A207538@wobbly.melbourne.sgi.com> <20020528160447.Q13933@va.samba.org> <20020529141847.GC8372@atrey.karlin.mff.cuni.cz> <20020529114745.T13933@va.samba.org> <20020529194828.A16538@infradead.org> <20020529121717.U13933@va.samba.org> <20020529204507.A17728@infradead.org> <20020529125644.W13933@va.samba.org> <20020529212215.A18293@infradead.org> <20020529212640.A19471@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020529212640.A19471@infradead.org>; from hch@infradead.org on Wed, May 29, 2002 at 09:26:40PM +0100 From: jra@samba.org (Jeremy Allison) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, May 29, 2002 at 09:26:40PM +0100, Christoph Hellwig wrote: > > Here's a better patch - it also handles another linux quota interface > > that samba didn't yet handle at all.. > > Yikes, that was still borked. Ok - a varient of this has been committed to SAMBA_2_2. Can you please CVS checkout and test it ? Thanks, Jeremy. From owner-linux-xfs@oss.sgi.com Fri Jun 7 12:53:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57JrcnC024292 for ; Fri, 7 Jun 2002 12:53:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57Jrc9r024291 for linux-xfs-outgoing; Fri, 7 Jun 2002 12:53:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gk.ka.epigenomics.net (qmailr@gk.ka.epigenomics.net [62.159.77.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57JrWnC024263 for ; Fri, 7 Jun 2002 12:53:33 -0700 Received: (qmail 22511 invoked from network); 7 Jun 2002 19:55:37 -0000 Received: from einstein.epigenomics.epi (qmailr@192.168.1.4) by weinberg.epigenomics.epi with SMTP; 7 Jun 2002 19:55:37 -0000 Received: (qmail 19344 invoked from network); 7 Jun 2002 19:55:36 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by einstein.epigenomics.epi with SMTP; 7 Jun 2002 19:55:36 -0000 Received: (qmail 18987 invoked by uid 9); 7 Jun 2002 19:55:36 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: config question (external raid, external log?) Date: Fri, 7 Jun 2002 19:55:36 +0000 (UTC) Organization: Epigenomics AG Lines: 15 Message-ID: References: X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! I am currently setting up the system (remember: external 1.5TB RAID) and trying to run mkfs.xfs on the partition results in a filesystem of 3 GB size. mkreiserfs on the very same partition gives a filesystem of 1.5TB. Any ideas? Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Jun 7 12:54:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57JsonC024622 for ; Fri, 7 Jun 2002 12:54:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57Jso5W024621 for linux-xfs-outgoing; Fri, 7 Jun 2002 12:54:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57JsenC024569 for ; Fri, 7 Jun 2002 12:54:41 -0700 Received: from twestrelay04.boulder.ibm.com (twestrelay04.boulder.ibm.com [9.17.194.55]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g57JuZg5177340; Fri, 7 Jun 2002 15:56:37 -0400 Received: from d03nm800.boulder.ibm.com (d03nm800.boulder.ibm.com [9.17.194.116]) by twestrelay04.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g57JuV1108170; Fri, 7 Jun 2002 13:56:31 -0600 Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region To: Dean Roehrich Cc: "Francis Qu" , linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Fri, 7 Jun 2002 14:56:28 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 06/07/2002 01:56:34 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean, Your scenario is correct, and yes, there is a lot more going on than just those calls. I'll see if I can get you a more detailed calling sequence. In the mean time, I'm running with your patch on an otherwise unmodified XFS 1.1 system. Perhaps I am missing some more recent modifications? I could grab something more recent from CVS if you think that would help. Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: "Francis Qu" , linux-xfs@oss.sgi.com Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region 06/06/2002 01:46 PM >From: "James A Goodwin" > >Dean, > >Thanks for the patch. It gets us past the problem with dm_get_fileattr(). > >However, later in the same function (called when the write event was >received), my process hangs on dm_set_region() for the same file. Is this >perhaps a similar problem with a similar fix? So a user process opens a file for append, and then does a write. This generates a write event. The HSM calls dm_get_events to get the write event. Then it calls dm_get_fileattr on that handle, then dm_set_region on that handle, then finally responds to the write event with dm_respond_event--is that the scenario? That scenario doesn't hang for me, so is there anything else going on in there? Dean From owner-linux-xfs@oss.sgi.com Fri Jun 7 13:06:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57K6bnC027305 for ; Fri, 7 Jun 2002 13:06:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57K6b2v027304 for linux-xfs-outgoing; Fri, 7 Jun 2002 13:06:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57K6VnC027271 for ; Fri, 7 Jun 2002 13:06:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA96128; Fri, 7 Jun 2002 15:08:31 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA74914; Fri, 7 Jun 2002 15:08:30 -0500 (CDT) Subject: Re: config question (external raid, external log?) From: Eric Sandeen To: Robert Sander Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Jun 2002 15:06:20 -0500 Message-Id: <1023480380.25892.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You need an xfsprogs version >= 2.0 for kernels >= 2.4.18, and vice versa. mkfs uses BLKGETSIZE64 which is broken on older kernels. Or, if you already do have those versions, what scsi controller/driver are you using? Could be broken there too. -Eric On Fri, 2002-06-07 at 14:55, Robert Sander wrote: > Hi! > > I am currently setting up the system (remember: external 1.5TB RAID) and > trying to run mkfs.xfs on the partition results in a filesystem of 3 GB > size. > mkreiserfs on the very same partition gives a filesystem of 1.5TB. > > Any ideas? > > Greetings > -- > Robert Sander > Manager > Information Systems www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Jun 7 13:06:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57K6onC027347 for ; Fri, 7 Jun 2002 13:06:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57K6o3p027346 for linux-xfs-outgoing; Fri, 7 Jun 2002 13:06:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gk.ka.epigenomics.net (qmailr@gk.ka.epigenomics.net [62.159.77.106]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57K6inC027315 for ; Fri, 7 Jun 2002 13:06:45 -0700 Received: (qmail 22532 invoked from network); 7 Jun 2002 20:08:51 -0000 Received: from einstein.epigenomics.epi (qmailr@192.168.1.4) by weinberg.epigenomics.epi with SMTP; 7 Jun 2002 20:08:51 -0000 Received: (qmail 19998 invoked from network); 7 Jun 2002 20:08:50 -0000 Received: from broglie.epigenomics.epi (qmailr@192.168.1.5) by einstein.epigenomics.epi with SMTP; 7 Jun 2002 20:08:50 -0000 Received: (qmail 19265 invoked by uid 9); 7 Jun 2002 20:08:50 -0000 From: Robert Sander Reply-To: Robert Sander X-Newsgroups: epi.ml.linux.xfs Subject: Re: config question (external raid, external log?) Date: Fri, 7 Jun 2002 20:08:50 +0000 (UTC) Organization: Epigenomics AG Lines: 14 Message-ID: References: X-Complaints-To: usenet@epigenomics.com User-Agent: slrn/0.9.7.3 (Linux) To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 7 Jun 2002 19:55:36 +0000 (UTC), Robert Sander wrote: > > Any ideas? My fault. I should have read the archives. The system is running a 2.4.17 kernel, so I need the special pre-2.4.18 rpm... Greetings -- Robert Sander Manager Information Systems www.epigenomics.com Kastanienallee 24 +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Jun 7 13:20:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57KKenC027720 for ; Fri, 7 Jun 2002 13:20:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57KKeka027719 for linux-xfs-outgoing; Fri, 7 Jun 2002 13:20:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57KKXnC027691 for ; Fri, 7 Jun 2002 13:20:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA95940; Fri, 7 Jun 2002 15:22:36 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA52697; Fri, 7 Jun 2002 15:22:35 -0500 (CDT) Subject: Re: config question (external raid, external log?) From: Eric Sandeen To: Robert Sander Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 07 Jun 2002 15:20:24 -0500 Message-Id: <1023481225.25937.9.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The other option, if you want to hack around a bit, is to get the latest xfsprogs, and modify libxfs/init.c so that it does not try to use BLKGETSIZE64, and uses BLKGETSIZE directly - pretty straightforward modification. -Eric On Fri, 2002-06-07 at 15:08, Robert Sander wrote: > On Fri, 7 Jun 2002 19:55:36 +0000 (UTC), > Robert Sander wrote: > > > > Any ideas? > > My fault. I should have read the archives. The system is running a > 2.4.17 kernel, so I need the special pre-2.4.18 rpm... > > Greetings > -- > Robert Sander > Manager > Information Systems www.epigenomics.com Kastanienallee 24 > +493024345330 10435 Berlin From owner-linux-xfs@oss.sgi.com Fri Jun 7 13:24:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57KOonC027901 for ; Fri, 7 Jun 2002 13:24:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57KOoVS027900 for linux-xfs-outgoing; Fri, 7 Jun 2002 13:24:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57KOjnC027871 for ; Fri, 7 Jun 2002 13:24:46 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA96483; Fri, 7 Jun 2002 15:26:45 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA23957; Fri, 7 Jun 2002 15:26:45 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id PAA41285; Fri, 7 Jun 2002 15:26:44 -0500 (CDT) Message-Id: <200206072026.PAA41285@slobber.americas.sgi.com> To: "James A Goodwin" cc: "Francis Qu" , linux-xfs@oss.sgi.com Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region Date: Fri, 07 Jun 2002 15:26:44 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" > >Dean, > >Your scenario is correct, and yes, there is a lot more going on than just >those calls. I'll see if I can get you a more detailed calling sequence. > >In the mean time, I'm running with your patch on an otherwise unmodified >XFS 1.1 system. Perhaps I am missing some more recent modifications? I >could grab something more recent from CVS if you think that would help. nothing comes to mind, but you might try it anyway. I haven't checked in that fix yet, so make sure you reapply the patch when necessary. Dean From owner-linux-xfs@oss.sgi.com Fri Jun 7 14:46:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g57LkmnC028523 for ; Fri, 7 Jun 2002 14:46:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g57LkmkS028522 for linux-xfs-outgoing; Fri, 7 Jun 2002 14:46:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g57LkfnC028494 for ; Fri, 7 Jun 2002 14:46:41 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id OAA05109 for ; Fri, 7 Jun 2002 14:48:47 -0700 (PDT) mail_from (pj@engr.sgi.com) Received: from turbo-linux.engr.sgi.com (turbo-linux.engr.sgi.com [163.154.6.103]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id OAA07090; Fri, 7 Jun 2002 14:47:28 -0700 (PDT) Received: by turbo-linux.engr.sgi.com (Postfix, from userid 2324) id 30A86101548E; Fri, 7 Jun 2002 14:47:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by turbo-linux.engr.sgi.com (Postfix) with ESMTP id 2BC971C000AA; Fri, 7 Jun 2002 14:47:28 -0700 (PDT) Date: Fri, 7 Jun 2002 14:47:28 -0700 (PDT) From: Paul Jackson To: Matteo Centonza Cc: Murthy Kambhampaty , "'Stephan Austermuehle'" , "Linux-Xfs (E-mail)" Subject: RE: xfsdump and -v or -V? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 7 Jun 2002, Matteo Centonza wrote: > that's because the version number is sent to stderr (and the usage to > stdout); Try this one: The other way around. > xfsrestore --help 2>/dev/null This works for me too. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson 1.650.933.1373 From owner-linux-xfs@oss.sgi.com Fri Jun 7 19:43:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g582h2nC030531 for ; Fri, 7 Jun 2002 19:43:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g582h2f5030530 for linux-xfs-outgoing; Fri, 7 Jun 2002 19:43:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g582gvnC030502 for ; Fri, 7 Jun 2002 19:42:57 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA97466 for ; Fri, 7 Jun 2002 21:45:00 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id VAA36715 for ; Fri, 7 Jun 2002 21:45:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g582eLX27856; Fri, 7 Jun 2002 21:40:21 -0500 Message-Id: <200206080240.g582eLX27856@jen.americas.sgi.com> Date: Fri, 7 Jun 2002 21:40:21 -0500 Subject: TAKE - remove unused parameter from read/write path To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some more dead code. Date: Fri Jun 7 19:44:08 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121103a linux/fs/xfs/xfs_rw.h - 1.64 linux/fs/xfs/xfs_dmapi.c - 1.57 linux/fs/xfs/xfs_types.h - 1.56 linux/fs/xfs/linux/xfs_lrw.h - 1.22 linux/fs/xfs/linux/xfs_lrw.c - 1.141 linux/fs/xfs/linux/xfs_file.c - 1.62 linux/fs/xfs/linux/xfs_vnode.h - 1.37 From owner-linux-xfs@oss.sgi.com Fri Jun 7 20:26:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g583QenC031276 for ; Fri, 7 Jun 2002 20:26:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g583QeOc031275 for linux-xfs-outgoing; Fri, 7 Jun 2002 20:26:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g583QYnC031246 for ; Fri, 7 Jun 2002 20:26:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA97199 for ; Fri, 7 Jun 2002 22:28:38 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA00148 for ; Fri, 7 Jun 2002 22:28:38 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g583NwQ30692; Fri, 7 Jun 2002 22:23:58 -0500 Message-Id: <200206080323.g583NwQ30692@jen.americas.sgi.com> Date: Fri, 7 Jun 2002 22:23:58 -0500 Subject: TAKE - fix overagressive writeout of mmap pages To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sometimes xfs could allocate space for and write out pages which it should not have. Showed up as a failure in fsx when running under heavy memory load. Date: Fri Jun 7 20:27:29 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121106a linux/fs/xfs/pagebuf/page_buf_io.c - 1.42 - When clustering unbuffered pages for writeout - only look at dirty ones From owner-linux-xfs@oss.sgi.com Fri Jun 7 20:30:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g583U1nC031456 for ; Fri, 7 Jun 2002 20:30:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g583U1QX031455 for linux-xfs-outgoing; Fri, 7 Jun 2002 20:30:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g583TtnC031420 for ; Fri, 7 Jun 2002 20:29:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA97166 for ; Fri, 7 Jun 2002 22:31:59 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA99914 for ; Fri, 7 Jun 2002 22:31:59 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g583RJO30819; Fri, 7 Jun 2002 22:27:19 -0500 Message-Id: <200206080327.g583RJO30819@jen.americas.sgi.com> Date: Fri, 7 Jun 2002 22:27:19 -0500 Subject: TAKE - Remove PageDelalloc flag To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Christoph pointed out we do not really need this, another xfs change to the core kernel bites the dust. Date: Fri Jun 7 20:30:55 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-test The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121107a linux/mm/filemap.c - 1.111 linux/include/linux/mm.h - 1.83 linux/fs/buffer.c - 1.106 linux/kdb/modules/kdbm_pg.c - 1.54 linux/fs/xfs/pagebuf/page_buf_io.c - 1.43 From owner-linux-xfs@oss.sgi.com Sat Jun 8 01:58:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g588wDnC000830 for ; Sat, 8 Jun 2002 01:58:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g588wDZM000829 for linux-xfs-outgoing; Sat, 8 Jun 2002 01:58:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g588w0nC000801 for ; Sat, 8 Jun 2002 01:58:01 -0700 Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by mail7.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17Gc4u-0001aO-00; Sat, 08 Jun 2002 10:00:08 +0100 Received: from modem-37.zebra.dialup.pol.co.uk ([81.76.144.37] helo=reti) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17Gc4p-0006EX-00; Sat, 08 Jun 2002 10:00:03 +0100 Received: from joe by reti with local (Exim 3.35 #1 (Debian)) id 17Gc4T-0000Fv-00; Sat, 08 Jun 2002 09:59:41 +0100 Date: Sat, 8 Jun 2002 09:59:31 +0100 To: linux-lvm@sistina.com Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: [linux-lvm] How well tested is the snapshot feature? Message-ID: <20020608085931.GA915@fib011235813.fsnet.co.uk> References: <2D0AFEFEE711D611923E009027D39F2B02F18C@nasexs1.meridian-data.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D0AFEFEE711D611923E009027D39F2B02F18C@nasexs1.meridian-data.com> User-Agent: Mutt/1.3.28i From: Joe Thornber X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 07, 2002 at 11:31:30AM -0700, Dale Stephenson wrote: > Subjective impression. kupdated always seems to be in D state with > streaming writes and snapshots, more so than a similar stream directed at > LVM + XFS without snapshots. While brw_kiovec and kcopyd stay away from the > filesystem, the filesystem doesn't stay away from them! When kupdated > writes out something to a LV with multiple snapshots, multiple COW can > occur. The big weakness of snapshots in LVM1 and EVMS is that they perform the copy on write exception synchronously. ie. If a process schedules a lot of writes to a device (eg, kupdate), and these writes trigger a lot of exceptions, the exceptions will be performed one after the other. So if you are using an 8k chunk size for each exception (small chunks sizes eliminate redundant copying), and kupdate triggers 1M of exceptions LVM1 and EVMS will perform the following steps: 1) Issue read of original chunk 2) wait 3) issue write 4) wait And it will do it for *every* chunk, 128 times in this case. So that's 256 times in total that the original process spends waiting for the disk. No wonder you see kupdate in the 'D' state. In order to combat this effect you will be forced to use larger chunk sizes in the hope that most of these exceptions are to adjacent parts of the disk. With device-mapper if an exception is triggered it is immediately handed to kcopyd, and then device-mapper carrys on servicing subsequent requests. Typically queuing more and more exceptions with kcopyd. Kcopyd tries to perform as many of these copies at once, which gives us two major benefits. i) The read for one exception can occur at the same time as the write for another. Assuming the COW store and the origin are on seperate PVs on average this reduces the overhead of performing an exception by a half. ii) There is no uneccessary waiting ! This waiting is readily apparent in the graph on http://people.sistina.com/~thornber/snap_performance.html Since this benchmark is based on dbench which just creating and removing v. large files it is advantageous to LVM1/EVMS since there will be little redundant copying when they use large chunk sizes. It would be interesting to use a benchmark that touches lots of little files scattered over a huge filesystem - that would at least highlight the inefficiency of copying 512k when a 1k file is touched. So with LVM2 people are encouraged to use small chunk sizes to avoid redundant copying. > The problem I'm seeing now is with > xfs_unmountfs_writesb() as called from xfs_fs_freeze(). I've only seen the > problem with (multiple) snapshots, but brw_kiovec() isn't involved in the > deadlock and fsync_dev_lockfs() is. So I would expect LVM2 (device-mapper) > to be susceptible to the same problem, at least in theory. Yes, it sounds like a bug in xfs. > 2.4.18. I've been able to induce memory deadlocks (processes in D state > descending from alloc_pages) on my 64K box with multiple snapshots, but > haven't been too worried about that since I expect it. On a 1 GB system I > haven't seen the deadlocks, or at least recognized it as such. The one I'm > seeing has a ton of writing processes waiting on check_frozen (which is > fine), kupdated stuck on pagebuf_lock(), and xfs_freeze waiting on > _pagebuf_wait_unpin(). Is this something you've seen? No, the deadlocks I've seen seemed to involve a thread staying permanently in the rebalance loop in __alloc_pages. - Joe From owner-linux-xfs@oss.sgi.com Sat Jun 8 02:08:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5898jnC001068 for ; Sat, 8 Jun 2002 02:08:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5898jPU001067 for linux-xfs-outgoing; Sat, 8 Jun 2002 02:08:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail7.svr.pol.co.uk (mail7.svr.pol.co.uk [195.92.193.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5898dnC001039 for ; Sat, 8 Jun 2002 02:08:39 -0700 Received: from [195.92.168.141] (helo=tmailb1.svr.pol.co.uk) by mail7.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17GcFD-0003Bd-00; Sat, 08 Jun 2002 10:10:47 +0100 Received: from modem-37.zebra.dialup.pol.co.uk ([81.76.144.37] helo=reti) by tmailb1.svr.pol.co.uk with esmtp (Exim 3.35 #1) id 17GcFD-0006uv-00; Sat, 08 Jun 2002 10:10:47 +0100 Received: from joe by reti with local (Exim 3.35 #1 (Debian)) id 17GcEy-0000HU-00; Sat, 08 Jun 2002 10:10:32 +0100 Date: Sat, 8 Jun 2002 10:10:22 +0100 To: linux-lvm@sistina.com Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: [linux-lvm] How well tested is the snapshot feature? Message-ID: <20020608091022.GA1070@fib011235813.fsnet.co.uk> References: <2D0AFEFEE711D611923E009027D39F2B02F18C@nasexs1.meridian-data.com> <20020608085931.GA915@fib011235813.fsnet.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020608085931.GA915@fib011235813.fsnet.co.uk> User-Agent: Mutt/1.3.28i From: Joe Thornber X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Jun 08, 2002 at 09:59:31AM +0100, Joe Thornber wrote: > exceptions LVM1 and EVMS will perform the following steps: > > 1) Issue read of original chunk > 2) wait > 3) issue write > 4) wait I forgot about the metadata update: 6) issue metadata write 7) wait device-mapper batches the metadata updates, under load this amortises the cost away (well, to a point where I can't measure it). - Joe From owner-linux-xfs@oss.sgi.com Sat Jun 8 05:15:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g58CFsnC002673 for ; Sat, 8 Jun 2002 05:15:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g58CFsD7002672 for linux-xfs-outgoing; Sat, 8 Jun 2002 05:15:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g58CFnnC002644 for ; Sat, 8 Jun 2002 05:15:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA99793 for ; Sat, 8 Jun 2002 07:17:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA44780 for ; Sat, 8 Jun 2002 07:17:54 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g58CDB005648; Sat, 8 Jun 2002 07:13:11 -0500 Message-Id: <200206081213.g58CDB005648@jen.americas.sgi.com> Date: Sat, 8 Jun 2002 07:13:11 -0500 Subject: TAKE - optimization in unlock code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Too many calls into a transaction path when unlocking an inode, we only need to do this is we are unlocking the ilock. Date: Sat Jun 8 05:16:31 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121116a linux/fs/xfs/xfs_iget.c - 1.160 - If we are not dropping the ilock there is no need to call the transaction system. From owner-linux-xfs@oss.sgi.com Sun Jun 9 03:10:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59AAVnC009807 for ; Sun, 9 Jun 2002 03:10:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59A8h9X009799 for linux-xfs-outgoing; Sun, 9 Jun 2002 03:08:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59A7rnC009769 for ; Sun, 9 Jun 2002 03:08:03 -0700 Received: from online.no (213-187-165-28.dd.nextgentel.com [213.187.165.28]) by mail.broadpark.no (Postfix) with ESMTP id 55AF77D3D; Sat, 8 Jun 2002 20:56:22 +0200 (MEST) Message-ID: <3D025283.F902218D@online.no> Date: Sat, 08 Jun 2002 20:52:51 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4SGI_XFS_1.1custom i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, mvojkovich@nvidia.com Subject: I have been able to duplicat this erro References: <3CEF89F4.E4060C3A@online.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have be able to duplicat this errro. > There may be a problem with the vm becuase it was unable to free a page. > It a bit odd since I have 256 Mb ram and 1 giga byte swap. Send along > log file, I was unable > > May 25 14:01:16 knut kernel: ------------[ cut here ]------------ > May 25 14:01:16 knut kernel: kernel BUG at page_alloc.c:117! > May 25 14:01:16 knut kernel: invalid operand: 0000 > May 25 14:01:16 knut kernel: emu10k1-gp analog gameport joydev input > snd-pcm-oss snd-mixer-oss agpgart NVdr > May 25 14:01:16 knut kernel: CPU: 0 > May 25 14:01:16 knut kernel: EIP: 0010:[__free_pages_ok+87/784] > Tainted: PF > May 25 14:01:16 knut kernel: EIP: 0010:[] Tainted: PF > May 25 14:01:16 knut kernel: EFLAGS: 00210282 > May 25 14:01:16 knut kernel: > May 25 14:01:16 knut kernel: EIP is at __free_pages_ok [kernel] 0x57 > (2.4.18-4SGI_XFS_1.1custom) > May 25 14:01:16 knut kernel: eax: 00000020 ebx: c1260268 ecx: > 00000001 edx: 000025fa > May 25 14:01:16 knut kernel: esi: 00000000 edi: c03580dc ebp: > 00000000 esp: c13dff58 > May 25 14:01:16 knut kernel: ds: 0018 es: 0018 ss: 0018 > May 25 14:01:16 knut kernel: Process kswapd (pid: 5, stackpage=c13df000) > > May 25 14:01:16 knut kernel: Stack: c02a27b5 00000075 c2248400 c1260268 > c013ec33 c9af6e80 c13dff88 00200246 > May 25 14:01:16 knut kernel: c013cd8a c1260268 c1260284 c03580dc > c2248400 c0130c24 c1260268 00000030 > May 25 14:01:16 knut kernel: c1260268 c1260284 c03580dc 00000040 > c01321f6 ffffcf5c c13de000 c0358104 > May 25 14:01:16 knut kernel: Call Trace: [try_to_free_buffers+179/272] > try_to_free_buffers [kernel] 0xb3 > May 25 14:01:16 knut kernel: Call Trace: [] > try_to_free_buffers [kernel] 0xb3 > May 25 14:01:16 knut kernel: [try_to_release_page+58/96] > try_to_release_page [kernel] 0x3a > May 25 14:01:16 knut kernel: [] try_to_release_page [kernel] > 0x3a > May 25 14:01:16 knut kernel: [drop_page+52/672] drop_page [kernel] 0x34 > May 25 14:01:16 knut kernel: [] drop_page [kernel] 0x34 > May 25 14:01:16 knut kernel: [refill_inactive_zone+518/704] > refill_inactive_zone [kernel] 0x206 > May 25 14:01:16 knut kernel: [] refill_inactive_zone [kernel] > 0x206 > May 25 14:01:16 knut kernel: [kswapd+640/720] kswapd [kernel] 0x280 > May 25 14:01:16 knut kernel: [] kswapd [kernel] 0x280 > May 25 14:01:16 knut kernel: [_stext+0/32] stext [kernel] 0x0 > May 25 14:01:16 knut kernel: [] stext [kernel] 0x0 > May 25 14:01:16 knut kernel: [kernel_thread+38/48] kernel_thread > [kernel] 0x26 > May 25 14:01:16 knut kernel: [] kernel_thread [kernel] 0x26 > May 25 14:01:16 knut kernel: [kswapd+0/720] kswapd [kernel] 0x0 > May 25 14:01:16 knut kernel: [] kswapd [kernel] 0x0 > May 25 14:01:16 knut kernel: > May 25 14:01:16 knut kernel: > May 25 14:01:16 knut kernel: Code: 0f 0b 5d 58 8b 3d 90 22 3d c0 89 d8 > 29 f8 69 c0 b7 6d db b6 > May 25 14:03:20 knut kernel: <6>NVRM: AGPGART: freed 38 pages > May 25 14:03:45 knut kernel: NVRM: AGPGART: allocated 38 pages > May 25 14:04:23 knut kernel: NVRM: AGPGART: freed 38 pages > May 25 14:04:47 knut kernel: NVRM: AGPGART: allocated 38 pages > May 25 14:05:05 knut kernel: NVRM: AGPGART: freed 38 pages > May 25 14:36:27 knut kernel: SysRq : SAK > May 25 14:36:28 knut kernel: SysRq : HELP : loglevel0-8 reBoot tErm kIll > saK showMem Off showPc unRaw Sync showTasks Unmount > May 25 14:36:28 knut kernel: SysRq : SAK Jun 8 20:02:14 knut kernel: kernel BUG at page_alloc.c:117! Jun 8 20:02:14 knut kernel: invalid operand: 0000 Jun 8 20:02:14 knut kernel: snd-pcm-oss snd-mixer-oss agpgart NVdriver binfmt_misc vmnet vmmon snd-seq-mid Jun 8 20:02:14 knut kernel: CPU: 0 Jun 8 20:02:14 knut kernel: EIP: 0010:[rw_swap_page_nolock+103/176] Tainted: PF Jun 8 20:02:14 knut kernel: EIP: 0010:[] Tainted: PF Jun 8 20:02:14 knut kernel: EFLAGS: 00210282 Jun 8 20:02:14 knut kernel: Jun 8 20:02:14 knut kernel: EIP is at __free_pages_ok [kernel] 0x57 (2.4.18-4SGI_XFS_1.1custom) Jun 8 20:02:14 knut kernel: eax: 00000020 ebx: c1258f58 ecx: 00000001 edx: 00002b66 Jun 8 20:02:14 knut kernel: esi: 00000000 edi: c034bcdc ebp: 00000000 esp: c13dff58 Jun 8 20:02:14 knut kernel: ds: 0018 es: 0018 ss: 0018 Jun 8 20:02:14 knut kernel: Process kswapd (pid: 5, stackpage=c13df000) Jun 8 20:02:14 knut kernel: Stack: c0298575 00000075 c6548c80 c1258f58 c013ebe3 cfe01880 c13dff88 00200246 Jun 8 20:02:14 knut kernel: c013cd3a c1258f58 c1258f74 c034bcdc c6548c80 c0130b84 c1258f58 00000030 Jun 8 20:02:14 knut kernel: c1258f58 c1258f74 c034bcdc 0000008f c0132156 fffff0ef c13de000 c034bd04 Jun 8 20:02:14 knut kernel: Call Trace: [try_to_free_buffers+99/272] try_to_free_buffers [kernel] 0xb3 Jun 8 20:02:14 knut kernel: Call Trace: [] try_to_free_buffers [kernel] 0xb3 Jun 8 20:02:14 knut kernel: [discard_buffer+122/144] try_to_release_page [kernel] 0x3a Jun 8 20:02:14 knut kernel: [] try_to_release_page [kernel] 0x3a Jun 8 20:02:14 knut kernel: [deactivate_page_nolock+212/304] drop_page [kernel] 0x34 Jun 8 20:02:14 knut kernel: [] drop_page [kernel] 0x34 Jun 8 20:02:14 knut kernel: [refill_inactive_zone+358/704] refill_inactive_zone [kernel] 0x206 Jun 8 20:02:14 knut kernel: [] refill_inactive_zone [kernel] 0x206 Jun 8 20:02:14 knut kernel: [kswapd+480/720] kswapd [kernel] 0x280 Jun 8 20:02:14 knut kernel: [] kswapd [kernel] 0x280 Jun 8 20:02:14 knut kernel: [_stext+0/32] stext [kernel] 0x0 Jun 8 20:02:14 knut kernel: [] stext [kernel] 0x0 Jun 8 20:02:14 knut kernel: [kernel_thread+38/48] kernel_thread [kernel] 0x26 Jun 8 20:02:14 knut kernel: [] kernel_thread [kernel] 0x26 Jun 8 20:02:14 knut kernel: [do_try_to_free_pages+368/384] kswapd [kernel] 0x0 Jun 8 20:02:14 knut kernel: [] kswapd [kernel] 0x0 Jun 8 20:02:14 knut kernel: Jun 8 20:02:14 knut kernel: Jun 8 20:02:14 knut kernel: Code: 0f 0b 5d 58 8b 3d 90 62 3c c0 89 d8 29 f8 69 c0 b7 6d db b6 I dupicated this erro by /sbin/shutdown now as root and then init 5 then The pc lock after loading mozilla with xft support. outpuf from XFree86 log ] (II) Bus 2: bridge is at (0:30:0), (0,2,2), BCTRL: 0x02 (VGA_EN is cleared) (II) Bus 2 I/O range: [0] -1 0x0000d000 - 0x0000dfff (0x1000) IX[B] (II) Bus 2 non-prefetchable memory range: [0] -1 0xfea00000 - 0xfeafffff (0x100000) MX[B] (II) Bus 2 prefetchable memory range: [0] -1 0xf4700000 - 0xf47fffff (0x100000) MX[B] (II) Bus -1: bridge is at (0:31:0), (0,-1,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus -1 I/O range: (II) Bus -1 non-prefetchable memory range: (II) Bus -1 prefetchable memory range: (--) PCI:*(1:0:0) NVidia GeForce2 GTS/Pro rev 164, Mem @ 0xfd000000/24, 0xe8000000/27, BIOS @ 0xfe9f0000/16 (II) Addressable bus resource ranges are [0] -1 0x00000000 - 0xffffffff (0x0) MX[B] [1] -1 0x00000000 - 0x0000ffff (0x10000) IX[B] (II) OS-reported resource ranges: [0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0x00000000 - 0x000000ff (0x100) IX[B] (II) Active PCI resource ranges: [0] -1 0xfeaffc00 - 0xfeaffc7f (0x80) MX[B] [1] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B] [2] -1 0xfe9f0000 - 0xfe9fffff (0x10000) MX[B](B) [3] -1 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [4] -1 0xfd000000 - 0xfdffffff (0x1000000) MX[B](B) [5] -1 0x0000dff0 - 0x0000dff7 (0x8) IX[B] [6] -1 0x0000df80 - 0x0000df9f (0x20) IX[B] [7] -1 0x0000dc00 - 0x0000dc7f (0x80) IX[B] [8] -1 0x0000efa0 - 0x0000efaf (0x10) IX[B] [9] -1 0x0000ef80 - 0x0000ef9f (0x20) IX[B] [10] -1 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] (II) Active PCI resource ranges after removing overlaps: [0] -1 0xfeaffc00 - 0xfeaffc7f (0x80) MX[B] [1] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B] [2] -1 0xfe9f0000 - 0xfe9fffff (0x10000) MX[B](B) [3] -1 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [4] -1 0xfd000000 - 0xfdffffff (0x1000000) MX[B](B) [5] -1 0x0000dff0 - 0x0000dff7 (0x8) IX[B] [6] -1 0x0000df80 - 0x0000df9f (0x20) IX[B] [7] -1 0x0000dc00 - 0x0000dc7f (0x80) IX[B] [8] -1 0x0000efa0 - 0x0000efaf (0x10) IX[B] [9] -1 0x0000ef80 - 0x0000ef9f (0x20) IX[B] [10] -1 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] (II) OS-reported resource ranges after removing overlaps with PCI: [0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0x0000ffff - 0x0000ffff (0x1) IX[B] [6] -1 0x00000000 - 0x000000ff (0x100) IX[B] (II) All system resource ranges: [0] -1 0xffe00000 - 0xffffffff (0x200000) MX[B](B) [1] -1 0x00100000 - 0x3fffffff (0x3ff00000) MX[B]E(B) [2] -1 0x000f0000 - 0x000fffff (0x10000) MX[B] [3] -1 0x000c0000 - 0x000effff (0x30000) MX[B] [4] -1 0x00000000 - 0x0009ffff (0xa0000) MX[B] [5] -1 0xfeaffc00 - 0xfeaffc7f (0x80) MX[B] [6] -1 0xf8000000 - 0xfbffffff (0x4000000) MX[B] [7] -1 0xfe9f0000 - 0xfe9fffff (0x10000) MX[B](B) [8] -1 0xe8000000 - 0xefffffff (0x8000000) MX[B](B) [9] -1 0xfd000000 - 0xfdffffff (0x1000000) MX[B](B) [10] -1 0x0000ffff - 0x0000ffff (0x1) IX[B] [11] -1 0x00000000 - 0x000000ff (0x100) IX[B] [12] -1 0x0000dff0 - 0x0000dff7 (0x8) IX[B] [13] -1 0x0000df80 - 0x0000df9f (0x20) IX[B] [14] -1 0x0000dc00 - 0x0000dc7f (0x80) IX[B] [15] -1 0x0000efa0 - 0x0000efaf (0x10) IX[B] [16] -1 0x0000ef80 - 0x0000ef9f (0x20) IX[B] [17] -1 0x0000ffa0 - 0x0000ffaf (0x10) IX[B] (II) LoadModule: "dbe" (II) Loading /usr/X11R6/lib/modules/extensions/libdbe.a (II) Module dbe: vendor="The XFree86 Project" compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 Server Extension ABI class: XFree86 Server Extension, version 0.1 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: "extmod" (II) Loading /usr/X11R6/lib/modules/extensions/libextmod.a (II) Module extmod: vendor="The XFree86 Project" comp and XF86Config-4 # XFree86 4.0 configuration generated by Xconfigurator # By default, Red Hat Linux 6.0 and later use xfs # This loads all the modules... ##Section "DRI" ##EndSection Section "ServerLayout" Identifier "XFree86 Configured" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection Section "Files" FontPath "unix/:7100" FontPath "tcp/127.0.0.1:7102" EndSection Section "Module" Load "dbe" Load "extmod" Load "glx" Load "record"# Load "v4l" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "keyboard" Option "XkbLayout" "no" EndSection Section "InputDevice" # Modified by mouseconfig Identifier "Mouse0" Driver "mouse" Option "Device" "/dev/mouse" Option "Protocol" "IMPS/2" Option "Emulate3Buttons" "no" Option "ZAxisMapping" "4 5" EndSection Section "Monitor" # GAMMA 1.2 Identifier "DELL E770p" VendorName "Unknown" ModelName "Unknown" HorizSync 30.0 - 70.0 VertRefresh 50.0 - 160.0 EndSection Section "Device" Identifier "nVidia Corporation|NV15 (Geforce2 GTS)" Driver "nvidia" BoardName "Unknown" EndSection Section "Screen" Identifier "Screen0" Device "nVidia Corporation|NV15 (Geforce2 GTS)" Monitor "DELL E770p" DefaultDepth 24 Option "NvAgp" "2" Option "NoLogo" SubSection "Display" Depth 32 Modes "1152x864" EndSubSection SubSection "Display" Depth 24 Modes "1152x864" EndSubSection EndSection From owner-linux-xfs@oss.sgi.com Sun Jun 9 06:12:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59DCDnC015989 for ; Sun, 9 Jun 2002 06:12:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59DCD8R015988 for linux-xfs-outgoing; Sun, 9 Jun 2002 06:12:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59DC8nE015933 for ; Sun, 9 Jun 2002 06:12:09 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA09000 for ; Sun, 9 Jun 2002 05:36:23 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA04518 for ; Sun, 9 Jun 2002 07:35:56 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA57606 for ; Sun, 9 Jun 2002 07:35:55 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g59CV2h21608; Sun, 9 Jun 2002 07:31:02 -0500 Message-Id: <200206091231.g59CV2h21608@jen.americas.sgi.com> Date: Sun, 9 Jun 2002 07:31:02 -0500 Subject: TAKE - fix xfs lookup path in 2.5 for nfs support To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Jun 9 05:35:20 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:121117a linux/fs/xfs/linux/xfs_iops.c - 1.153 - fix lookup operation for nfs support From owner-linux-xfs@oss.sgi.com Sun Jun 9 06:12:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59DCEnC015994 for ; Sun, 9 Jun 2002 06:12:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59DCEaV015992 for linux-xfs-outgoing; Sun, 9 Jun 2002 06:12:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59DC8nC015933 for ; Sun, 9 Jun 2002 06:12:08 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [192.48.203.6]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id FAA06586 for ; Sun, 9 Jun 2002 05:39:59 -0700 (PDT) mail_from (lord@sgi.com) Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA04443 for ; Sun, 9 Jun 2002 07:39:32 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA70708 for ; Sun, 9 Jun 2002 07:39:32 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g59CYdJ21671; Sun, 9 Jun 2002 07:34:39 -0500 Message-Id: <200206091234.g59CYdJ21671@jen.americas.sgi.com> Date: Sun, 9 Jun 2002 07:34:39 -0500 Subject: TAKE - use more kernel builtins in 2.5 for dcache handling To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another one from Christoph, there are now kernel functions to do some of the dcache handling xfs was doing for itself. Date: Sun Jun 9 05:38:16 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:121118a linux/fs/xfs/xfs_dmapi.c - 1.60 linux/fs/xfs/linux/xfs_super.c - 1.188 linux/fs/xfs/linux/xfs_ioctl.c - 1.68 From owner-linux-xfs@oss.sgi.com Sun Jun 9 13:25:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g59KPpnC019712 for ; Sun, 9 Jun 2002 13:25:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g59KPpVt019711 for linux-xfs-outgoing; Sun, 9 Jun 2002 13:25:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g59KOSnC019679 for ; Sun, 9 Jun 2002 13:24:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA05017 for ; Sun, 9 Jun 2002 15:26:39 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA15519 for ; Sun, 9 Jun 2002 15:26:39 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g59KLg103492; Sun, 9 Jun 2002 15:21:42 -0500 Message-Id: <200206092021.g59KLg103492@jen.americas.sgi.com> Date: Sun, 9 Jun 2002 15:21:42 -0500 Subject: TAKE - merge up to 2.5.21 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Jun 9 12:56:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:121119a linux/drivers/s390/cio/cio_debug.h - 1.1 linux/include/asm-s390/tlbflush.h - 1.1 linux/drivers/s390/cio/ioinfo.c - 1.1 linux/include/asm-s390x/rwsem.h - 1.1 linux/include/asm-s390x/qdio.h - 1.1 linux/include/asm-s390x/percpu.h - 1.1 linux/drivers/s390/cio/cio_debug.c - 1.1 linux/drivers/s390/cio/blacklist.h - 1.1 linux/drivers/s390/cio/cio.h - 1.1 linux/include/asm-s390x/fsf.h - 1.1 linux/drivers/isdn/hisax/amd7930_fn.c - 1.1 linux/drivers/isdn/hisax/amd7930_fn.h - 1.1 linux/drivers/isdn/hisax/enternow.h - 1.1 linux/drivers/isdn/hisax/enternow_pci.c - 1.1 linux/drivers/isdn/hisax/ipacx.c - 1.1 linux/drivers/isdn/hisax/ipacx.h - 1.1 linux/drivers/usb/host/ohci-sa1111.c - 1.1 linux/drivers/usb/class/usb-midi.c - 1.1 linux/drivers/s390/cio/blacklist.c - 1.1 linux/scripts/fixdep.c - 1.1 linux/include/asm-s390x/tape390.h - 1.1 linux/arch/s390x/kernel/asm-offsets.c - 1.1 linux/include/asm-s390x/thread_info.h - 1.1 linux/include/asm-s390/cacheflush.h - 1.1 linux/drivers/s390/cio/ioinfo.h - 1.1 linux/drivers/s390/cio/airq.h - 1.1 linux/drivers/s390/cio/airq.c - 1.1 linux/drivers/usb/class/usb-midi.h - 1.1 linux/drivers/s390/cio/misc.c - 1.1 linux/drivers/s390/cio/Makefile - 1.1 linux/drivers/s390/sysinfo.c - 1.1 linux/include/asm-s390x/tlbflush.h - 1.1 linux/drivers/s390/qdio.c - 1.1 linux/drivers/s390/net/lcs.c - 1.1 linux/drivers/s390/cio/misc.h - 1.1 linux/drivers/s390/cio/chsc.c - 1.1 linux/include/asm-s390x/suspend.h - 1.1 linux/drivers/s390/cio/proc.c - 1.1 linux/drivers/usb/core/hcd-pci.c - 1.1 linux/drivers/s390/cio/s390io.h - 1.1 linux/arch/s390/boot/install.sh - 1.1 linux/arch/s390x/boot/install.sh - 1.1 linux/include/asm-s390/suspend.h - 1.1 linux/arch/i386/kernel/suspend.c - 1.1 linux/include/asm-s390/tape390.h - 1.1 linux/arch/s390x/kernel/exec_domain32.c - 1.1 linux/include/asm-s390/fsf.h - 1.1 linux/include/video/tx3912.h - 1.1 linux/include/video/pm2fb.h - 1.1 linux/include/video/neomagic.h - 1.1 linux/drivers/s390/cio/s390io.c - 1.1 linux/include/asm-s390/thread_info.h - 1.1 linux/arch/i386/kernel/cpu/umc.c - 1.1 linux/arch/i386/kernel/cpu/transmeta.c - 1.1 linux/include/asm-s390/rwsem.h - 1.1 linux/arch/i386/kernel/cpu/rise.c - 1.1 linux/include/asm-s390/qdio.h - 1.1 linux/drivers/usb/host/ohci-pci.c - 1.1 linux/arch/i386/kernel/cpu/proc.c - 1.1 linux/arch/i386/kernel/cpu/nexgen.c - 1.1 linux/include/asm-s390/percpu.h - 1.1 linux/arch/i386/kernel/cpu/intel.c - 1.1 linux/drivers/s390/cio/cio.c - 1.1 linux/arch/i386/kernel/cpu/cyrix.c - 1.1 linux/arch/i386/kernel/cpu/cpu.h - 1.1 linux/arch/s390/kernel/asm-offsets.c - 1.1 linux/include/asm-s390x/cacheflush.h - 1.1 linux/drivers/s390/cio/chsc.h - 1.1 linux/drivers/s390/block/dasd_devmap.c - 1.1 linux/drivers/s390/block/dasd_genhd.c - 1.1 linux/drivers/s390/block/dasd_ioctl.c - 1.1 linux/drivers/s390/cio/proc.h - 1.1 linux/drivers/s390/char/tape_idalbuf.h - 1.1 linux/drivers/s390/cio/requestirq.c - 1.1 linux/arch/i386/kernel/cpu/Makefile - 1.1 linux/arch/i386/kernel/cpu/amd.c - 1.1 linux/arch/i386/kernel/cpu/centaur.c - 1.1 linux/arch/i386/kernel/cpu/changelog - 1.1 linux/arch/i386/kernel/cpu/common.c - 1.1 linux/scripts/tkparse.h - 1.5 linux/scripts/tkparse.c - 1.9 linux/scripts/mkdep.c - 1.15 linux/scripts/lxdialog/Makefile - 1.5 linux/scripts/Makefile - 1.6 linux/scripts/Configure - 1.16 linux/net/sunrpc/xdr.c - 1.8 linux/net/sched/sch_api.c - 1.13 linux/net/ipv6/raw.c - 1.25 linux/net/ipv4/tcp_ipv4.c - 1.46 linux/net/ipv4/icmp.c - 1.30 linux/net/ipv4/devinet.c - 1.16 linux/net/ipv4/af_inet.c - 1.36 linux/net/core/dev.c - 1.54 linux/mm/vmalloc.c - 1.40 linux/mm/page_alloc.c - 1.80 linux/kernel/sysctl.c - 1.52 linux/kernel/sched.c - 1.70 linux/kernel/ksyms.c - 1.148 linux/kernel/info.c - 1.8 linux/kernel/fork.c - 1.58 linux/kernel/capability.c - 1.8 linux/kernel/Makefile - 1.31 linux/init/main.c - 1.83 linux/include/net/pkt_sched.h - 1.10 linux/include/linux/wait.h - 1.14 linux/include/linux/vmalloc.h - 1.16 linux/include/linux/sunrpc/xdr.h - 1.9 linux/include/linux/sched.h - 1.71 linux/include/linux/init.h - 1.19 linux/include/linux/fs.h - 1.173 linux/include/linux/capability.h - 1.13 linux/include/linux/byteorder/generic.h - 1.4 linux/include/linux/blkdev.h - 1.59 linux/include/asm-sparc64/page.h - 1.18 linux/include/asm-sparc/vac-ops.h - 1.3 linux/include/asm-sparc/ultra.h - 1.3 linux/include/asm-sparc/page.h - 1.15 linux/include/asm-sparc/btfixup.h - 1.3 linux/include/asm-i386/system.h - 1.25 linux/include/asm-i386/processor.h - 1.39 linux/include/asm-i386/msr.h - 1.12 linux/include/asm-i386/desc.h - 1.10 linux/include/asm-i386/bugs.h - 1.18 linux/include/asm-arm/page.h - 1.18 linux/fs/smbfs/inode.c - 1.36 linux/fs/proc/inode.c - 1.23 linux/fs/open.c - 1.39 linux/fs/ntfs/super.c - 1.15 linux/fs/ntfs/inode.c - 1.18 linux/fs/ntfs/dir.h - 1.6 linux/fs/ntfs/dir.c - 1.13 linux/fs/ntfs/Makefile - 1.19 linux/fs/nfs/inode.c - 1.45 linux/fs/nfs/dir.c - 1.40 linux/fs/ncpfs/inode.c - 1.33 linux/fs/locks.c - 1.24 linux/fs/inode.c - 1.76 linux/fs/fcntl.c - 1.20 linux/fs/dcache.c - 1.39 linux/fs/binfmt_misc.c - 1.25 linux/drivers/zorro/Makefile - 1.8 linux/drivers/video/vfb.c - 1.16 linux/drivers/video/skeletonfb.c - 1.12 linux/drivers/video/pm2fb.c - 1.15 linux/drivers/video/fbmem.c - 1.50 linux/drivers/video/fbcmap.c - 1.7 linux/drivers/video/dnfb.c - 1.15 linux/drivers/video/Makefile - 1.39 linux/drivers/video/Config.in - 1.36 linux/drivers/scsi/script_asm.pl - 1.5 linux/drivers/scsi/ide-scsi.c - 1.37 linux/drivers/pci/quirks.c - 1.28 linux/drivers/pci/Makefile - 1.21 linux/drivers/net/hamradio/soundmodem/Makefile - 1.5 linux/drivers/isdn/hisax/teles3.c - 1.14 linux/drivers/isdn/hisax/sedlbauer.c - 1.18 linux/drivers/isdn/hisax/niccy.c - 1.16 linux/drivers/isdn/hisax/netjet.c - 1.20 linux/drivers/isdn/hisax/ix1_micro.c - 1.11 linux/drivers/isdn/hisax/hisax.h - 1.29 linux/drivers/isdn/hisax/fsm.c - 1.11 linux/drivers/isdn/hisax/elsa.c - 1.19 linux/drivers/isdn/hisax/diva.c - 1.15 linux/drivers/isdn/hisax/config.c - 1.29 linux/drivers/isdn/hisax/asuscom.c - 1.14 linux/drivers/isdn/hisax/Makefile - 1.20 linux/drivers/char/Makefile - 1.61 linux/drivers/cdrom/sonycd535.c - 1.22 linux/drivers/cdrom/sjcd.c - 1.18 linux/drivers/cdrom/sbpcd.c - 1.24 linux/drivers/cdrom/optcd.c - 1.19 linux/drivers/cdrom/cdu31a.c - 1.17 linux/drivers/block/rd.c - 1.52 linux/drivers/block/ll_rw_blk.c - 1.104 linux/arch/sparc64/solaris/timod.c - 1.21 linux/arch/sparc64/solaris/Makefile - 1.8 linux/arch/sparc64/mm/generic.c - 1.12 linux/arch/sparc64/kernel/sys_sparc32.c - 1.51 linux/arch/sparc64/kernel/Makefile - 1.24 linux/arch/sparc/mm/sun4c.c - 1.33 linux/arch/sparc/kernel/devices.c - 1.5 linux/arch/ppc/kernel/ppc_htab.c - 1.17 linux/arch/mips/kernel/sysirix.c - 1.18 linux/arch/mips/boot/Makefile - 1.11 linux/arch/i386/mm/ioremap.c - 1.14 linux/arch/i386/kernel/smp.c - 1.46 linux/arch/i386/kernel/setup.c - 1.78 linux/arch/i386/kernel/entry.S - 1.57 linux/arch/i386/kernel/Makefile - 1.30 linux/arch/i386/config.in - 1.82 linux/arch/i386/boot/compressed/Makefile - 1.10 linux/arch/i386/boot/Makefile - 1.14 linux/arch/i386/Makefile - 1.25 linux/arch/arm/mm/mm-armv.c - 1.28 linux/arch/arm/boot/Makefile - 1.15 linux/arch/arm/Makefile - 1.28 linux/arch/alpha/kernel/signal.c - 1.15 linux/arch/alpha/kernel/osf_sys.c - 1.30 linux/Rules.make - 1.24 linux/Makefile - 1.201 linux/MAINTAINERS - 1.108 linux/Documentation/isdn/README.HiSax - 1.11 linux/Documentation/filesystems/vfs.txt - 1.6 linux/Documentation/filesystems/ntfs.txt - 1.15 linux/CREDITS - 1.82 linux/include/linux/ide.h - 1.51 linux/drivers/video/cyber2000fb.c - 1.34 linux/drivers/isdn/hisax/avm_pci.c - 1.14 linux/net/khttpd/Makefile - 1.5 linux/include/asm-i386/hw_irq.h - 1.29 linux/drivers/isdn/hisax/isurf.c - 1.11 linux/drivers/isdn/hisax/hfcscard.c - 1.9 linux/drivers/isdn/hisax/hfc_pci.c - 1.23 linux/drivers/atm/Makefile - 1.18 linux/arch/sh/boot/Makefile - 1.5 linux/include/asm-i386/pci.h - 1.16 linux/include/asm-i386/kmap_types.h - 1.8 linux/include/linux/spinlock.h - 1.17 linux/include/linux/pci_ids.h - 1.67 linux/drivers/video/tdfxfb.c - 1.21 linux/mm/highmem.c - 1.40 linux/mm/bootmem.c - 1.20 linux/include/asm-i386/highmem.h - 1.12 linux/drivers/video/aty128fb.c - 1.27 linux/drivers/isdn/hisax/w6692.c - 1.12 linux/include/asm-i386/pgalloc.h - 1.20 linux/include/linux/mmzone.h - 1.22 linux/include/asm-i386/rwlock.h - 1.4 linux/kernel/timer.c - 1.23 linux/drivers/video/dn_cfb8.c - 1.10 linux/drivers/video/dn_cfb4.c - 1.9 linux/drivers/video/dn_accel.h - 1.2 linux/arch/ia64/ia32/sys_ia32.c - 1.26 linux/drivers/isdn/hisax/hfc_sx.c - 1.12 linux/arch/i386/kernel/microcode.c - 1.17 linux/drivers/isdn/hysdn/hysdn_defs.h - 1.11 linux/fs/devfs/base.c - 1.39 linux/drivers/video/matrox/matroxfb_crtc2.c - 1.9 linux/arch/mips64/boot/Makefile - 1.8 linux/drivers/net/bonding.c - 1.10 linux/include/linux/if_bonding.h - 1.5 linux/drivers/ide/trm290.c - 1.10 linux/drivers/ide/piix.c - 1.25 linux/drivers/ide/ide.c - 1.55 linux/drivers/ide/ide-pmac.c - 1.15 linux/drivers/ide/ide-pci.c - 1.29 linux/drivers/ide/ide-floppy.c - 1.26 linux/drivers/ide/ide-disk.c - 1.37 linux/drivers/ide/ide-cd.c - 1.37 linux/drivers/ide/icside.c - 1.17 linux/drivers/ide/hpt34x.c - 1.13 linux/drivers/ide/ali14xx.c - 1.10 linux/drivers/ide/Config.in - 1.26 linux/Documentation/DocBook/Makefile - 1.32 linux/include/linux/compatmac.h - 1.3 linux/net/ipv4/netfilter/ipchains_core.c - 1.10 linux/fs/ramfs/inode.c - 1.24 linux/arch/s390/kernel/process.c - 1.13 linux/include/asm-s390/page.h - 1.7 linux/arch/s390/boot/Makefile - 1.8 linux/arch/s390/Makefile - 1.7 linux/include/asm-s390/unistd.h - 1.10 linux/include/asm-s390/uaccess.h - 1.7 linux/arch/s390/config.in - 1.12 linux/arch/s390/defconfig - 1.11 linux/include/asm-s390/timex.h - 1.2 linux/include/asm-s390/irq.h - 1.7 linux/include/asm-s390/lowcore.h - 1.7 linux/include/asm-s390/io.h - 1.5 linux/include/asm-s390/system.h - 1.6 linux/arch/s390/kernel/Makefile - 1.7 linux/include/asm-s390/hardirq.h - 1.5 linux/include/asm-s390/ebcdic.h - 1.5 linux/arch/s390/kernel/bitmap.S - 1.2 linux/include/asm-s390/spinlock.h - 1.5 linux/include/asm-s390/smp.h - 1.5 linux/include/asm-s390/sigp.h - 1.5 linux/include/asm-s390/signal.h - 1.3 linux/include/asm-s390/siginfo.h - 1.5 linux/include/asm-s390/byteorder.h - 1.3 linux/include/asm-s390/setup.h - 1.5 linux/include/asm-s390/semaphore.h - 1.4 linux/arch/s390/kernel/entry.S - 1.18 linux/arch/s390/kernel/head.S - 1.8 linux/include/asm-s390/atomic.h - 1.7 linux/drivers/s390/net/iucv.c - 1.9 linux/drivers/s390/net/Makefile - 1.7 linux/drivers/s390/misc/chandev.c - 1.10 linux/arch/s390/kernel/ieee.h - 1.2 linux/drivers/s390/char/hwc_rw.c - 1.6 linux/drivers/s390/char/hwc_tty.c - 1.6 linux/drivers/s390/char/hwc_rw.h - 1.4 linux/drivers/s390/char/hwc_con.c - 1.6 linux/drivers/s390/char/Makefile - 1.8 linux/drivers/s390/char/hwc.h - 1.5 linux/drivers/s390/char/con3215.c - 1.8 linux/include/asm-s390/s390mach.h - 1.3 linux/include/asm-s390/s390io.h - 1.4 linux/arch/s390/kernel/init_task.c - 1.5 linux/arch/s390/kernel/irq.c - 1.9 linux/drivers/s390/block/dasd_eckd.c - 1.9 linux/drivers/s390/block/dasd.c - 1.25 linux/drivers/s390/block/dasd_erp.c - 1.3 linux/include/asm-s390/s390-gdbregs.h - 1.3 linux/drivers/s390/Makefile - 1.6 linux/arch/s390/vmlinux.lds - 1.7 linux/drivers/s390/Config.in - 1.9 linux/include/asm-s390/ptrace.h - 1.6 linux/include/asm-s390/processor.h - 1.9 linux/include/asm-s390/pgtable.h - 1.14 linux/Documentation/s390/cds.txt - 1.6 linux/include/asm-s390/mman.h - 1.2 linux/include/asm-s390/init.h - 1.3 linux/include/asm-s390/bitops.h - 1.7 linux/include/asm-s390/current.h - 1.5 linux/drivers/s390/block/dasd_proc.c - 1.4 linux/drivers/s390/block/Makefile - 1.8 linux/arch/s390/kernel/time.c - 1.6 linux/include/asm-s390/pgalloc.h - 1.6 linux/arch/s390/kernel/traps.c - 1.9 linux/arch/s390/kernel/ptrace.c - 1.8 linux/arch/s390/kernel/reipl.S - 1.4 linux/arch/s390/kernel/s390_ksyms.c - 1.8 linux/arch/s390/kernel/semaphore.c - 1.6 linux/arch/s390/kernel/setup.c - 1.7 linux/arch/s390/kernel/signal.c - 1.12 linux/arch/s390/kernel/smp.c - 1.14 linux/arch/s390/mm/extable.c - 1.3 linux/arch/s390/mm/fault.c - 1.9 linux/arch/s390/mm/init.c - 1.11 linux/arch/s390/mm/ioremap.c - 1.5 linux/Documentation/filesystems/Locking - 1.16 linux/drivers/char/drm/i810_dma.c - 1.15 linux/include/asm-sparc/kmap_types.h - 1.6 linux/include/asm-arm/mach/map.h - 1.3 linux/drivers/isdn/hysdn/hycapi.c - 1.11 linux/drivers/isdn/hisax/nj_s.c - 1.10 linux/arch/i386/kernel/bluesmoke.c - 1.21 linux/include/asm-ppc/kmap_types.h - 1.9 linux/scripts/makelst - 1.3 linux/fs/xfs/support/mrlock.c - 1.9 linux/fs/xfs/support/kmem.c - 1.12 linux/mm/shmem.c - 1.38 linux/drivers/usb/storage/unusual_devs.h - 1.10 linux/include/asm-s390/dasd.h - 1.7 linux/arch/s390x/kernel/traps.c - 1.5 linux/arch/s390x/kernel/time.c - 1.5 linux/arch/s390x/kernel/sys_s390.c - 1.4 linux/include/asm-s390x/ptrace.h - 1.3 linux/arch/s390x/kernel/smp.c - 1.11 linux/include/asm-s390x/processor.h - 1.5 linux/arch/s390x/kernel/signal32.c - 1.7 linux/include/asm-s390x/pgtable.h - 1.10 linux/include/asm-s390x/pgalloc.h - 1.5 linux/arch/s390x/kernel/signal.c - 1.9 linux/arch/s390x/kernel/setup.c - 1.6 linux/include/asm-s390x/page.h - 1.6 linux/arch/s390x/kernel/semaphore.c - 1.3 linux/include/asm-s390x/mman.h - 1.2 linux/include/asm-s390x/lowcore.h - 1.5 linux/include/asm-s390x/irq.h - 1.6 linux/include/asm-s390x/io.h - 1.4 linux/include/asm-s390x/init.h - 1.3 linux/include/asm-s390x/idals.h - 1.3 linux/include/asm-s390x/hardirq.h - 1.3 linux/include/asm-s390x/elf.h - 1.3 linux/include/asm-s390x/ebcdic.h - 1.4 linux/include/asm-s390x/s390-gdbregs.h - 1.2 linux/include/asm-s390x/debug.h - 1.5 linux/arch/s390x/kernel/s390_ksyms.c - 1.6 linux/arch/s390x/kernel/s390_ext.c - 1.4 linux/include/asm-s390x/s390_ext.h - 1.2 linux/arch/s390x/kernel/reipl.S - 1.3 linux/include/asm-s390x/dasd.h - 1.8 linux/include/asm-s390x/current.h - 1.4 linux/include/asm-s390x/ccwcache.h - 1.4 linux/include/asm-s390x/byteorder.h - 1.3 linux/include/asm-s390x/s390io.h - 1.3 linux/include/asm-s390x/s390mach.h - 1.2 linux/include/asm-s390x/bitops.h - 1.3 linux/arch/s390x/kernel/ptrace.c - 1.7 linux/arch/s390x/kernel/process.c - 1.10 linux/arch/s390x/kernel/linux32.c - 1.13 linux/arch/s390x/kernel/irq.c - 1.6 linux/arch/s390x/kernel/ioctl32.c - 1.5 linux/arch/s390x/kernel/init_task.c - 1.5 linux/arch/s390x/kernel/head.S - 1.7 linux/include/asm-s390x/semaphore.h - 1.3 linux/include/asm-s390x/setup.h - 1.4 linux/include/asm-s390x/siginfo.h - 1.4 linux/include/asm-s390x/signal.h - 1.4 linux/include/asm-s390x/sigp.h - 1.4 linux/drivers/s390/s390mach.c - 1.5 linux/drivers/s390/s390io.c - 1.9 linux/drivers/s390/s390dyn.c - 1.4 linux/drivers/s390/net/netiucv.c - 1.10 linux/include/asm-s390x/smp.h - 1.4 linux/drivers/s390/net/fsm.h - 1.3 linux/drivers/s390/net/fsm.c - 1.3 linux/drivers/s390/net/ctcmain.c - 1.7 linux/drivers/s390/idals.c - 1.4 linux/drivers/s390/char/tapedefs.h - 1.5 linux/drivers/s390/char/tapechar.h - 1.4 linux/arch/s390x/kernel/exec32.c - 1.4 linux/drivers/s390/char/tapechar.c - 1.6 linux/arch/s390x/kernel/entry.S - 1.13 linux/drivers/s390/char/tapeblock.h - 1.4 linux/drivers/s390/char/tapeblock.c - 1.11 linux/drivers/s390/char/tape34xx.h - 1.4 linux/drivers/s390/char/tape34xx.c - 1.10 linux/drivers/s390/char/tape3490.h - 1.4 linux/drivers/s390/char/tape3490.c - 1.4 linux/drivers/s390/char/tape3480.h - 1.4 linux/drivers/s390/char/tape3480.c - 1.4 linux/drivers/s390/char/tape.h - 1.4 linux/drivers/s390/char/tape.c - 1.5 linux/arch/s390x/kernel/debug.c - 1.7 linux/arch/s390x/kernel/bitmap.S - 1.2 linux/arch/s390x/kernel/binfmt_elf32.c - 1.4 linux/arch/s390x/kernel/Makefile - 1.7 linux/arch/s390x/defconfig - 1.10 linux/arch/s390x/config.in - 1.7 linux/arch/s390x/mm/ioremap.c - 1.4 linux/arch/s390x/mm/init.c - 1.8 linux/arch/s390x/mm/fault.c - 1.7 linux/arch/s390x/mm/extable.c - 1.3 linux/include/asm-s390x/spinlock.h - 1.5 linux/drivers/s390/ccwcache.c - 1.4 linux/drivers/s390/block/xpram.c - 1.18 linux/include/asm-s390x/system.h - 1.4 linux/include/asm-s390x/timex.h - 1.2 linux/drivers/s390/block/dasd_fba.h - 1.4 linux/drivers/s390/block/dasd_fba.c - 1.7 linux/drivers/s390/block/dasd_eckd.h - 1.6 linux/drivers/s390/block/dasd_diag.h - 1.4 linux/drivers/s390/block/dasd_diag.c - 1.7 linux/arch/s390x/lib/uaccess.S - 1.2 linux/include/asm-s390x/uaccess.h - 1.4 linux/arch/s390x/kernel/wrapper32.S - 1.5 linux/include/asm-s390/ccwcache.h - 1.4 linux/drivers/s390/block/dasd_9343_erp.c - 1.4 linux/drivers/s390/block/dasd_9336_erp.c - 1.4 linux/drivers/s390/block/dasd_3990_erp.h - 1.5 linux/drivers/s390/block/dasd_3990_erp.c - 1.8 linux/drivers/s390/block/dasd_3370_erp.c - 1.4 linux/include/asm-s390x/unistd.h - 1.7 linux/include/asm-s390x/atomic.h - 1.6 linux/include/asm-s390/scatterlist.h - 1.4 linux/include/asm-s390/s390_ext.h - 1.2 linux/include/asm-s390/idals.h - 1.3 linux/include/asm-s390/debug.h - 1.5 linux/arch/s390/kernel/debug.c - 1.7 linux/arch/s390/kernel/s390_ext.c - 1.4 linux/arch/s390/lib/uaccess.S - 1.2 linux/arch/s390x/vmlinux.lds - 1.7 linux/arch/s390x/boot/Makefile - 1.7 linux/arch/s390x/Makefile - 1.6 linux/arch/arm/mach-integrator/mm.c - 1.3 linux/drivers/s390/block/dasd_9343_erp.h - 1.4 linux/drivers/s390/char/tuball.c - 1.6 linux/drivers/s390/char/tubfs.c - 1.4 linux/drivers/s390/char/tubio.h - 1.4 linux/drivers/s390/char/tubtty.c - 1.6 linux/drivers/s390/char/tubttyaid.c - 1.2 linux/drivers/s390/char/tubttyrcl.c - 1.2 linux/drivers/s390/char/tubttysiz.c - 1.3 linux/drivers/s390/net/ctctty.c - 1.4 linux/Documentation/s390/Debugging390.txt - 1.4 linux/drivers/video/maxinefb.c - 1.6 linux/drivers/video/pmag-ba-fb.c - 1.5 linux/drivers/video/pmagb-b-fb.c - 1.5 linux/arch/s390/math-emu/math.c - 1.4 linux/arch/arm/mach-footbridge/mm.c - 1.2 linux/arch/cris/drivers/sync_serial.c - 1.4 linux/include/asm-s390/vtoc.h - 1.6 linux/include/asm-s390x/vtoc.h - 1.5 linux/drivers/net/irda/irda-usb.c - 1.17 linux/drivers/acpi/Config.in - 1.4 linux/drivers/net/wireless/airo.c - 1.16 linux/include/asm-s390/pci.h - 1.2 linux/fs/ntfs/unistr.c - 1.7 linux/Documentation/s390/CommonIO - 1.3 linux/include/asm-s390x/pci.h - 1.2 linux/drivers/s390/char/tape3590.h - 1.2 linux/drivers/s390/char/hwc_cpi.c - 1.4 linux/drivers/s390/char/tape3590.c - 1.2 linux/drivers/s390/block/dasd_3370_erp.h - 1.2 linux/drivers/s390/block/dasd_int.h - 1.6 linux/drivers/s390/block/dasd_9336_erp.h - 1.2 linux/arch/arm/mach-sa1100/yopy.c - 1.5 linux/arch/arm/mach-sa1100/xp860.c - 1.7 linux/arch/arm/mach-sa1100/simpad.c - 1.9 linux/arch/s390x/vmlinux-shared.lds - 1.5 linux/arch/arm/mach-sa1100/pleb.c - 1.6 linux/arch/s390/vmlinux-shared.lds - 1.5 linux/arch/arm/mach-sa1100/pfs168.c - 1.9 linux/arch/arm/mach-sa1100/pangolin.c - 1.8 linux/arch/arm/mach-sa1100/omnimeter.c - 1.7 linux/arch/arm/mach-sa1100/neponset.c - 1.9 linux/arch/arm/mach-sa1100/nanoengine.c - 1.6 linux/arch/arm/mach-anakin/mm.c - 1.3 linux/arch/arm/mach-sa1100/lart.c - 1.4 linux/arch/arm/mach-sa1100/jornada720.c - 1.8 linux/arch/arm/mach-sa1100/itsy.c - 1.5 linux/arch/arm/mach-sa1100/huw_webpanel.c - 1.7 linux/arch/arm/mach-sa1100/graphicsclient.c - 1.10 linux/arch/arm/mach-sa1100/assabet.c - 1.9 linux/arch/arm/mach-sa1100/cerf.c - 1.9 linux/arch/arm/mach-sa1100/generic.c - 1.6 linux/arch/arm/mach-sa1100/freebird.c - 1.8 linux/arch/arm/mach-sa1100/empeg.c - 1.6 linux/arch/arm/mach-sa1100/flexanet.c - 1.7 linux/drivers/video/tx3912fb.h - 1.2 linux/drivers/video/tx3912fb.c - 1.4 linux/drivers/scsi/dpt_i2o.c - 1.12 linux/drivers/bluetooth/hci_vhci.c - 1.5 linux/include/asm-s390x/tlb.h - 1.2 linux/include/asm-s390/tlb.h - 1.2 linux/arch/arm/mach-sa1100/h3600.c - 1.8 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.10 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.8 linux/arch/arm/mach-epxa10db/mm.c - 1.3 linux/arch/arm/mach-sa1100/pm.c - 1.5 linux/arch/arm/mach-sa1100/sleep.S - 1.4 linux/arch/arm/mach-sa1100/sleep.h - 1.2 linux/drivers/hotplug/pci_hotplug_core.c - 1.10 linux/include/linux/bio.h - 1.9 linux/fs/driverfs/inode.c - 1.14 linux/include/linux/device.h - 1.10 linux/arch/i386/kernel/setup-visws.c - 1.2 linux/arch/arm/mach-tbox/core.c - 1.2 linux/arch/arm/mach-shark/core.c - 1.2 linux/arch/arm/mach-sa1100/system3.c - 1.8 linux/arch/arm/mach-adifcc/mm.c - 1.3 linux/arch/arm/mach-clps711x/autcpu12.c - 1.3 linux/arch/arm/mach-clps711x/cdb89712.c - 1.5 linux/arch/arm/mach-clps711x/edb7211-mm.c - 1.4 linux/arch/arm/mach-clps711x/mm.c - 1.2 linux/arch/arm/mach-clps711x/p720t.c - 1.3 linux/arch/arm/mach-clps7500/core.c - 1.2 linux/arch/arm/mach-ebsa110/core.c - 1.3 linux/arch/arm/mach-ftvpci/core.c - 1.3 linux/arch/arm/mach-iop310/mm.c - 1.3 linux/arch/arm/mach-l7200/core.c - 1.5 linux/arch/arm/mach-rpc/riscpc.c - 1.4 linux/drivers/ide/ide-taskfile.c - 1.14 linux/drivers/video/neofb.c - 1.8 linux/drivers/video/neofb.h - 1.3 linux/arch/s390/Config.help - 1.2 linux/arch/s390x/Config.help - 1.2 linux/drivers/s390/Config.help - 1.2 linux/drivers/ide/Config.help - 1.13 linux/drivers/base/core.c - 1.11 linux/drivers/pci/pci-driver.c - 1.6 linux/include/linux/zlib.h - 1.2 linux/arch/ppc/iSeries/mf.c - 1.2 linux/arch/x86_64/boot/Makefile - 1.4 linux/sound/oss/Makefile - 1.5 linux/sound/last.c - 1.4 linux/include/asm-x86_64/kmap_types.h - 1.2 linux/arch/ppc64/kernel/rtasd.c - 1.3 linux/include/asm-arm/thread_info.h - 1.5 linux/fs/jfs/jfs_metapage.h - 1.3 linux/drivers/hotplug/ibmphp_res.c - 1.2 linux/fs/jfs/jfs_logmgr.h - 1.6 linux/fs/jfs/jfs_lock.h - 1.3 linux/drivers/hotplug/ibmphp_hpc.c - 1.3 linux/drivers/hotplug/ibmphp_ebda.c - 1.3 linux/drivers/hotplug/ibmphp_core.c - 1.4 linux/fs/jfs/file.c - 1.4 linux/fs/jfs/inode.c - 1.6 linux/fs/jfs/jfs_debug.c - 1.3 linux/fs/jfs/jfs_debug.h - 1.3 linux/fs/jfs/jfs_incore.h - 1.5 linux/fs/jfs/jfs_imap.h - 1.3 linux/fs/jfs/namei.c - 1.5 linux/arch/arm/mach-sa1100/stork.c - 1.3 linux/fs/jfs/jfs_logmgr.c - 1.7 linux/fs/jfs/super.c - 1.7 linux/fs/jfs/symlink.c - 1.3 linux/fs/jfs/jfs_txnmgr.c - 1.5 linux/fs/jfs/jfs_txnmgr.h - 1.3 linux/arch/arm/mach-sa1100/badge4.c - 1.6 linux/fs/jfs/jfs_unicode.h - 1.3 linux/fs/jfs/jfs_metapage.c - 1.7 linux/arch/ia64/sn/io/ifconfig_net.c - 1.2 linux/kernel/futex.c - 1.3 linux/drivers/usb/class/Config.in - 1.3 linux/drivers/usb/class/Makefile - 1.4 linux/drivers/usb/core/Makefile - 1.5 linux/drivers/usb/core/drivers.c - 1.3 linux/drivers/usb/core/hcd.c - 1.5 linux/drivers/usb/core/hcd.h - 1.5 linux/drivers/usb/core/inode.c - 1.3 linux/drivers/usb/media/konicawc.c - 1.3 linux/arch/arm/mach-pxa/generic.c - 1.2 linux/arch/arm/mach-pxa/idp.c - 1.4 linux/arch/arm/mach-pxa/lubbock.c - 1.4 linux/drivers/usb/host/ohci-hcd.c - 1.4 linux/drivers/usb/host/ohci-mem.c - 1.2 linux/drivers/usb/host/ohci-q.c - 1.3 linux/drivers/usb/host/ohci.h - 1.2 linux/drivers/base/sys.c - 1.2 linux/drivers/base/base.h - 1.4 linux/drivers/usb/media/usbvideo.c - 1.4 linux/drivers/usb/host/usb-ohci.c - 1.5 linux/drivers/usb/media/ov511.c - 1.4 linux/drivers/usb/media/pwc-if.c - 1.2 linux/drivers/video/clps711xfb.c - 1.5 linux/drivers/video/anakinfb.c - 1.5 linux/drivers/usb/misc/emi26.c - 1.2 linux/drivers/isdn/i4l/isdn_ppp.c - 1.3 linux/drivers/isdn/i4l/isdn_net.h - 1.2 linux/drivers/isdn/i4l/isdn_net.c - 1.2 linux/drivers/isdn/hisax/Config.in - 1.2 linux/drivers/isdn/capi/capi.c - 1.4 linux/fs/ntfs/attrib.c - 1.3 linux/fs/ntfs/volume.h - 1.2 linux/fs/ntfs/attraops.c - 1.3 linux/fs/ntfs/ntfs.h - 1.3 linux/fs/ntfs/namei.c - 1.3 linux/fs/ntfs/layout.h - 1.2 linux/fs/ntfs/ChangeLog - 1.3 linux/scripts/mkversion_h - 1.3 linux/scripts/mkcompile_h - 1.3 linux/drivers/ide/tcq.c - 1.4 linux/drivers/usb/host/uhci-hcd.c - 1.2 linux/drivers/usb/host/uhci-hub.c - 1.2 linux/drivers/ide/pcidma.c - 1.4 linux/arch/i386/pci/acpi.c - 1.3 linux/drivers/net/wan/pc300_drv.c - 1.2 linux/arch/i386/pci/common.c - 1.3 linux/arch/i386/pci/direct.c - 1.2 linux/arch/i386/pci/fixup.c - 1.2 linux/arch/i386/pci/legacy.c - 1.3 linux/arch/i386/pci/numa.c - 1.3 linux/arch/i386/pci/pcbios.c - 1.2 linux/init/Makefile - 1.3 linux/include/asm-i386/suspend.h - 1.2 linux/kernel/suspend.c - 1.3 linux/drivers/ide/ioctl.c - 1.3 linux/drivers/video/cfbcopyarea.c - 1.2 linux/drivers/ide/probe.c - 1.3 linux/include/asm-generic/siginfo.h - 1.2 linux/drivers/isdn/capi/kcapi_proc.c - 1.2 linux/drivers/base/bus.c - 1.3 linux/drivers/base/driver.c - 1.3 linux/drivers/video/cfbimgblt.c - 1.2 linux/include/linux/suspend.h - 1.2 linux/drivers/usb/host/usb-ohci-sa1111.c - 1.2 linux/drivers/usb/host/usb-ohci-pci.c - 1.2 linux/drivers/usb/core/urb.c - 1.2 linux/drivers/usb/core/message.c - 1.2 linux/include/linux/swapops.h - 1.2 linux/drivers/acpi/system.c - 1.2 linux/drivers/ide/device.c - 1.2 From owner-linux-xfs@oss.sgi.com Sun Jun 9 18:03:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A13jnC021180 for ; Sun, 9 Jun 2002 18:03:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A13j0D021179 for linux-xfs-outgoing; Sun, 9 Jun 2002 18:03:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ursa.xanoptix.com (host-64-65-199-187.choiceone.net [64.65.199.187]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A13VnC021151 for ; Sun, 9 Jun 2002 18:03:31 -0700 Received: from kend-linux.xanoptix.com ([10.20.1.45])by ursa.xanoptix.comwith esmtp(Exim 3.20 #1 (Debian))id 17HDZp-0000In-00; Sun, 09 Jun 2002 21:02:33 -0400 Subject: Re: ACLs changing for no apparent reason. (Samba 2.2.4, XFS on 2.4.17). From: "Ken D'Ambrosio" To: Ian Cumming Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020607145625.GA28726@ids.org.au> References: <1023457031.27600.48.camel@kend-linux> <20020607145625.GA28726@ids.org.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 09 Jun 2002 21:02:33 -0400 Message-Id: <1023670953.1474.53.camel@kend-linux> Mime-Version: 1.0 X-Spam-Status: No, hits=-1.7 required=5.0 tests=IN_REP_TO,SUBJ_HAS_SPACES version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-06-07 at 10:56, Ian Cumming wrote: > Hi Ken, > > If I remember correctly, someone asked a similar question a little while > ago on the list. > > What you are observing is probably due to the behaviour of the way > certain applications write to files. Some windows applications > move/remove the old file, and create a new file with the same filename > when a user "saves" an open file. Thus, you are losing the ACL on the > file, so to speak. While I certainly appreciate the reply, I have difficulty seeing how this could be the issue. For example, as I said below, some users actually lose permission to write to the very files that they created. Clearly, a default ACL would already have to be in place for this to occur, but none are. I will attempt to explicitly set the default ACLs on my tree, and see if the issues go away, but I'm reasonably certain that something else is at work, though, again, I'm not sure if it's Samba or XFS that's the culprit. If anything else comes to mind, please do let me know... Thanks! -Ken > You could overcome this problem by setting a default ACL for the user > group on the parent directory of any files you share. That way, new > files are created with the needed ACLs to allow other users in the group > to modify the files. Thus, files which are edited and "saved" by > software of said behaviour will have the correct ACLs. > > hope this helps, > Ian. > > On Fri, Jun 07, 2002 at 09:37:11AM -0400, Ken D'Ambrosio wrote: > > I'm not sure if this is a Samba issue or an XFS issue, but for various > > users, on files that are commonly shared by others, the ACLs change in > > weird ways, with no action (other than saving the file) on the user's > > part: > > > > - One user, upon saving the file, has the ACL (but not the "stock" Unix > > permissions) change to no permissions at all for group. > > - Another two users, upon saving, have the Unix permissions change to > > the equiv. of "chmod o-w". > > > > Any idea what might cause this to be happening, or where I should look > > to find more info? It's entirely reproducible, and, right now, I have a > > script running that "chmods" the files every couple seconds -- hack in > > the extreme. Unless I figure something out, I'll probably start by > > disabling ACLs in Samba, and see if the problem goes away. > > > > Thanks! > > > > Ken D'Ambrosio > > Sr. SysAdmin, > > -- > Ian Cumming, ian@semisphere.org > > "The number of Unix installations has grown to 10, with more expected." > -- The Unix Programmer's Manual, 2nd Edition, June, 1972 > From owner-linux-xfs@oss.sgi.com Sun Jun 9 23:07:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A675nC024494 for ; Sun, 9 Jun 2002 23:07:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A675CN024493 for linux-xfs-outgoing; Sun, 9 Jun 2002 23:07:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A66vnC024465 for ; Sun, 9 Jun 2002 23:06:58 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id D1929C217; Mon, 10 Jun 2002 08:09:08 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id IAA14097; Mon, 10 Jun 2002 08:09:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A96D357306; Mon, 10 Jun 2002 08:08:11 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 1F46025835; Mon, 10 Jun 2002 08:08:10 +0200 (CEST) Message-ID: <3D044249.31FD5017@ch.sauter-bc.com> Date: Mon, 10 Jun 2002 08:08:09 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH MIME-Version: 1.0 To: "Jonathan F. Dill" Cc: David Chambers , npollitt@engr.sgi.com, Linux XFS Mailing List Subject: Re: RH7.3 and Grub? References: <20020607112313.D25182@serapis.engr.sgi.com> <20020607114550.3920a63a.davidc@ccmi.salk.edu> <1023476200.1908.12.camel@amanda.carb.nist.gov> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "Jonathan F. Dill" schrieb: > > I tried switching from LILO to GRUB on 2 upgrades from RH 7.2 to RH 7.3 > and it didn't work for me. I don't know how it is with 7.3 but with 7.2, using GRUB could be a bad idea. GRUB does not install correctly if you're using software raid. RH has added 'special code' to anaconda to install GRUB on MD anyway. If you try it later 'by hand' you'll fail. The other problem is that even with the RedHat trick, GRUB is only installed in the MBR on the first disk. If this one fails, you can not boot from the second like you can when using LILO. Simon > > On Fri, 2002-06-07 at 14:45, David Chambers wrote: > > Looks like it. I had no problems with it, anyhow! > > > > - David > > > > On Fri, 7 Jun 2002 11:23:13 -0700 > > Nick Pollitt wrote: > > > > > Is grub supported yet on the 7.3 XFS installer? > > > > > > Thanks, > > > Nick > > > > -- > Jonathan F. Dill > UMBI CARB From owner-linux-xfs@oss.sgi.com Sun Jun 9 23:15:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5A6FMnC024775 for ; Sun, 9 Jun 2002 23:15:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5A6FMoZ024774 for linux-xfs-outgoing; Sun, 9 Jun 2002 23:15:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5A6FGnC024745 for ; Sun, 9 Jun 2002 23:15:17 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 1FD5FC2DDC5; Mon, 10 Jun 2002 16:17:28 +1000 (EST) Date: Mon, 10 Jun 2002 16:17:28 +1000 From: Ian Cumming To: "Ken D'Ambrosio" Cc: linux-xfs@oss.sgi.com Subject: Re: ACLs changing for no apparent reason. (Samba 2.2.4, XFS on 2.4.17). Message-ID: <20020610061728.GB11517@ids.org.au> References: <1023457031.27600.48.camel@kend-linux> <20020607145625.GA28726@ids.org.au> <1023670953.1474.53.camel@kend-linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1023670953.1474.53.camel@kend-linux> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ken, would you able to to give a small example of what occurs to the permissions of a file when your user writes to it? (ie: ls -l, and getfacl output on the filename). Also could you include the unix permissions and ACL for the parent directory? cheers, Ian. On Sun, Jun 09, 2002 at 09:02:33PM -0400, Ken D'Ambrosio wrote: > While I certainly appreciate the reply, I have difficulty seeing how > this could be the issue. For example, as I said below, some users > actually lose permission to write to the very files that they created. > Clearly, a default ACL would already have to be in place for this to > occur, but none are. I will attempt to explicitly set the default ACLs > on my tree, and see if the issues go away, but I'm reasonably certain > that something else is at work, though, again, I'm not sure if it's > Samba or XFS that's the culprit. -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Mon Jun 10 03:13:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AAD3nC003537 for ; Mon, 10 Jun 2002 03:13:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AAD34Q003536 for linux-xfs-outgoing; Mon, 10 Jun 2002 03:13:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AACrnC003506 for ; Mon, 10 Jun 2002 03:12:54 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g5AAFMG10886 for ; Mon, 10 Jun 2002 12:15:22 +0200 Date: Mon, 10 Jun 2002 12:15:22 +0200 (CEST) From: Matteo Centonza To: Subject: xfsdump recursive exclusion attribute Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, i'm trying to figure out if there's an easy way to skip several subtrees with xsfdump without the need of specifying a bunch of subpaths on the command line. I've read man pages, and excerpting: [snip] Excluding individual files Occasionally it is desirable to be able to exclude partic- ular files or directories from the dump. The -s option can be used to limit the dump to a specified directory, and the -z option can be used to exclude files over a par- ticular size. Additionally, when xfsdump is run with the -e option individual files can be "tagged" so that xfsdump will not include them in a dump. Files are tagged by assigning that file an extended attribute with the name "SGI_XFSDUMP_SKIP_FILE". This can be done with the attr(1) command: $ attr -s "SGI_XFSDUMP_SKIP_FILE" -V "" file To remove the attribute: $ attr -r "SGI_XFSDUMP_SKIP_FILE" file It should be noted that xfsdump will not check directories for this attribute. It should also be noted that this use of extended attributes is not the same as that used by the chattr(1) command. [snip] Is there a way to achieve this task at filesystem level. If not, will it be useful and possible to make xfsdump recognize a sort of SGI_XFSDUMP_SKIP_DIR attribute, skipping the whole subtree (a sort of attribute-coded -s option)? Thanks in advance, -m From owner-linux-xfs@oss.sgi.com Mon Jun 10 07:19:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AEJGnC017303 for ; Mon, 10 Jun 2002 07:19:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AEJGET017302 for linux-xfs-outgoing; Mon, 10 Jun 2002 07:19:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AEJ3nC017273 for ; Mon, 10 Jun 2002 07:19:04 -0700 Received: from mystery.carb.nist.gov ([129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GXHULG00.CEW; Mon, 10 Jun 2002 10:22:28 -0400 Subject: Re: RH7.3 and Grub? From: "Jonathan F. Dill" To: Simon Matter Cc: David Chambers , npollitt@engr.sgi.com, Linux XFS Mailing List In-Reply-To: <3D044249.31FD5017@ch.sauter-bc.com> References: <20020607112313.D25182@serapis.engr.sgi.com> <20020607114550.3920a63a.davidc@ccmi.salk.edu> <1023476200.1908.12.camel@amanda.carb.nist.gov> <3D044249.31FD5017@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: UMBI CARB X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 10 Jun 2002 10:23:39 -0400 Message-Id: <1023719022.1978.28.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I already knew about these problems and had used LILO with the original 7.2 install. Neither system had any MD devices, just regular fs partitions. I wanted to see if during the upgrade from 7.2 to 7.3 I could successfully switch from LILO to GRUB, knowing that there were not any MD, and one of the systems had only 1 disk. My answer: switching from LILO to GRUB during the upgrade from 7.2 to 7.3 did not work for me. Should anyone run into this problem, the solution is simple: Boot off the SGI installer CD, then chroot /mnt/sysimage, edit /etc/lilo.conf, run lilo (then I like to "sync" just to be sure) then reboot. I also did a fresh install of 7.3 on a laptop and tried to install GRUB (no MD devices here either), and that process complained that a file was missing and dropped out to the grub> prompt and the install process failed. I redid the install with LILO and it worked fine. On Mon, 2002-06-10 at 02:08, Simon Matter wrote: > "Jonathan F. Dill" schrieb: > > > > I tried switching from LILO to GRUB on 2 upgrades from RH 7.2 to RH 7.3 > > and it didn't work for me. > > I don't know how it is with 7.3 but with 7.2, using GRUB could be a bad > idea. GRUB does not install correctly if you're using software raid. RH > has added 'special code' to anaconda to install GRUB on MD anyway. If > you try it later 'by hand' you'll fail. The other problem is that even > with the RedHat trick, GRUB is only installed in the MBR on the first > disk. If this one fails, you can not boot from the second like you can > when using LILO -- Jonathan F. Dill UMBI CARB From owner-linux-xfs@oss.sgi.com Mon Jun 10 08:23:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AFNNnC018270 for ; Mon, 10 Jun 2002 08:23:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AFNNQE018269 for linux-xfs-outgoing; Mon, 10 Jun 2002 08:23:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from helixcode.nameip.net (s210-221-75-38.thrunet.ne.kr [210.221.75.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AFNHnC018240 for ; Mon, 10 Jun 2002 08:23:18 -0700 Received: (qmail 2068 invoked by uid 500); 10 Jun 2002 15:25:31 -0000 Subject: updated kernel with XFS 1.1 for From: Seung-young Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 00:25:31 +0900 Message-Id: <1023722731.2020.3.camel@helixcode.nameip.net> Mime-Version: 1.0 X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I wonder if the updated kernel with XFS 1.1 for RedHat 7.1 & 7.2 would be available? http://rhn.redhat.com/errata/RHBA-2002-104.html I'd appreciate any input. Thank you.. From owner-linux-xfs@oss.sgi.com Mon Jun 10 09:03:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AG3wnC018787 for ; Mon, 10 Jun 2002 09:03:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AG3wke018786 for linux-xfs-outgoing; Mon, 10 Jun 2002 09:03:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AG3qnC018758 for ; Mon, 10 Jun 2002 09:03:52 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA10779; Mon, 10 Jun 2002 11:06:06 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA48293; Mon, 10 Jun 2002 11:06:05 -0500 (CDT) Subject: Re: updated kernel with XFS 1.1 for From: Eric Sandeen To: Seung-young Oh Cc: linux-xfs@oss.sgi.com In-Reply-To: <1023722731.2020.3.camel@helixcode.nameip.net> References: <1023722731.2020.3.camel@helixcode.nameip.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 10 Jun 2002 11:03:28 -0500 Message-Id: <1023725008.30885.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk If you need these updates quicly, I would suggest creating a diff between Red Hat's original -31 and -34 kernels, and apply that to the XFS -31 kernel. Hopefully it will go cleanly, but I don't know for sure, I have not looked at these new kernels at all. -Eric On Mon, 2002-06-10 at 10:25, Seung-young Oh wrote: > Hello, > I wonder if the updated kernel with XFS 1.1 for RedHat 7.1 & 7.2 would > be available? > > http://rhn.redhat.com/errata/RHBA-2002-104.html > > I'd appreciate any input. Thank you.. > > From owner-linux-xfs@oss.sgi.com Mon Jun 10 09:47:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AGlTnC019279 for ; Mon, 10 Jun 2002 09:47:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AGlT8F019278 for linux-xfs-outgoing; Mon, 10 Jun 2002 09:47:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AGlMnC019248 for ; Mon, 10 Jun 2002 09:47:22 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA11259 for ; Mon, 10 Jun 2002 11:49:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA37753 for ; Mon, 10 Jun 2002 11:49:36 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5AGiVo24224; Mon, 10 Jun 2002 11:44:31 -0500 Message-Id: <200206101644.g5AGiVo24224@jen.americas.sgi.com> Date: Mon, 10 Jun 2002 11:44:31 -0500 Subject: TAKE - remove some code from the read/write path To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Putting fields into a structure, passing them one level down the stack and pulling them out again is a little inefficient. Date: Mon Jun 10 09:48:00 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121145a linux/fs/xfs/xfs_dmapi.c - 1.58 linux/fs/xfs/linux/xfs_lrw.h - 1.23 linux/fs/xfs/linux/xfs_lrw.c - 1.142 linux/fs/xfs/linux/xfs_file.c - 1.63 linux/fs/xfs/linux/xfs_vnode.h - 1.38 linux/fs/xfs/linux/xfs_vfs.h - 1.14 - kill the use of a uio_t on the read/write path, it was just overhead From owner-linux-xfs@oss.sgi.com Mon Jun 10 09:50:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AGotnC019459 for ; Mon, 10 Jun 2002 09:50:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AGotkS019458 for linux-xfs-outgoing; Mon, 10 Jun 2002 09:50:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AGoonC019430 for ; Mon, 10 Jun 2002 09:50:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA10330 for ; Mon, 10 Jun 2002 11:53:05 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA60174 for ; Mon, 10 Jun 2002 11:53:05 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5AGm0P24292; Mon, 10 Jun 2002 11:48:00 -0500 Message-Id: <200206101648.g5AGm0P24292@jen.americas.sgi.com> Date: Mon, 10 Jun 2002 11:48:00 -0500 Subject: TAKE - remove some magic numbers from pagebuf To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 10 09:52:36 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121146a linux/fs/xfs/pagebuf/page_buf.c - 1.32 - less use of magic numbers for block sizes From owner-linux-xfs@oss.sgi.com Mon Jun 10 10:40:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AHegnC021629 for ; Mon, 10 Jun 2002 10:40:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AHegZS021628 for linux-xfs-outgoing; Mon, 10 Jun 2002 10:40:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AHeanC021600 for ; Mon, 10 Jun 2002 10:40:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA11818 for ; Mon, 10 Jun 2002 12:42:51 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA39336 for ; Mon, 10 Jun 2002 12:42:51 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5AHgnw29772; Mon, 10 Jun 2002 12:42:49 -0500 Message-Id: <200206101742.g5AHgnw29772@jen.americas.sgi.com> Date: Mon, 10 Jun 2002 12:42:49 -0500 Subject: TAKE - remove read_inode method from xfs To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I thought about this, Christoph did it. This used to be of used for NFS, but we no longer need it. Steve Date: Mon Jun 10 10:41:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121152a linux/fs/xfs/xfs_iget.c - 1.161 linux/fs/xfs/linux/xfs_vnode.c - 1.81 linux/fs/xfs/linux/xfs_super.c - 1.176 linux/fs/xfs/linux/xfs_vnode.h - 1.39 From owner-linux-xfs@oss.sgi.com Mon Jun 10 10:45:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AHjtnC021822 for ; Mon, 10 Jun 2002 10:45:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AHjt06021821 for linux-xfs-outgoing; Mon, 10 Jun 2002 10:45:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AHjonC021790 for ; Mon, 10 Jun 2002 10:45:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA11718 for ; Mon, 10 Jun 2002 12:48:05 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA72052 for ; Mon, 10 Jun 2002 12:48:05 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g5AHjRS19688; Mon, 10 Jun 2002 12:45:27 -0500 Message-Id: <200206101745.g5AHjRS19688@stout.americas.sgi.com> Date: Mon, 10 Jun 2002 12:45:27 -0500 Subject: TAKE - Reduce stack usage a bit X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Since it looks like the stack is about to get smaller in 2.5, looking for easy places to make xfs ease up on the stack a bit... Date: Mon Jun 10 10:47:14 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121154a linux/fs/xfs/xfs_qm.c - 1.76 - Get some bytes off the stack in xfs_qm_dqiterate From owner-linux-xfs@oss.sgi.com Mon Jun 10 10:55:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AHtUnC022104 for ; Mon, 10 Jun 2002 10:55:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AHtUmf022103 for linux-xfs-outgoing; Mon, 10 Jun 2002 10:55:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fs1.theiqgroup.com (fs1.theiqgroup.com [216.81.249.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AHtCnC022030 for ; Mon, 10 Jun 2002 10:55:13 -0700 Received: from theiqgroup.com (funkmotor.theiqgroup.com [216.81.249.31]) by fs1.theiqgroup.com (8.12.2/8.12.2) with ESMTP id g5AHvQoP031206; Mon, 10 Jun 2002 12:57:27 -0500 Message-ID: <3D04E887.4060107@theiqgroup.com> Date: Mon, 10 Jun 2002 12:57:27 -0500 From: Kelly Corbin Organization: The IQ Group, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: fatal error -- xfs_repair: duplicate inode range References: <3C96259D.270CEB2E@emergence.com> <1016473250.14540.102.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I ran into this same problem and was curious exactly why/what happened. Does overwriting the superblock cause the corruption or was there corruption AND the superblock was overwritten? Would the newer xfs_repair have fixed more files/directories if it had been used the first time? Would this happen in any other case besides a kernel panic? Thanks! Kelly Steve Lord wrote: > On Mon, 2002-03-18 at 11:36, Michael Best wrote: > >>It appears that either the mailing list manager threw away my earlier >>posting to the mailing list or that there is no hope for recovery of my >>filesystem. >> > > Or people took the weekend off. > > You need a newer xfs_repair, and I suspect a newer kernel. You have > corruption in your filesystems, and older kernels can write over > block zero if they shutdown. > > Steve > > >>Any pointers would be appreciated. ssh access to this machine is >>available. >> >>Trying to get a dump of the filesystem right now with dd. >> >>----- >> >>On the failed system and on this new system I am running the SGI_XFS >>1.0.2 + >>Redhat 7.2 installer. >> >>----- >> >>I was called Sunday morning for a machine that had failed. >> >>You could ping it from the network but nothing else. >> >>I rebooted it, and got a XFS Page alloc kernel panic I believe. (unsure >>it's been hours since then). >> >>I rebooted it in single user mode, read some logfiles and then rebooted >>it into multi user mode. >> >>A short while later the machine appeared to fail again, when rebooted it >>could no longer load the initrd in order to mount the root (/) >>filesystem to boot. >> >>I used a Mandrake 8.2rc1 disc to boot the system, after finding the >>mount command on the 1.0.2 installer disc was hopeless. >> >>I ran XFS repair, which suggested something good had happened. And then >>it suggested mounting it. No luck. It suggested I could use xfs_repair >>-L to try and mount it after that. >> >>I tried that, no luck. All further attempts produce output like this: >> >>fatal error -- xfs_repair: duplicate inode range >> >>Here are the logs from xfs_check and xfs_repair for this filesystem. >> >>http://www.emergence.com/xfs_trouble/xfs_check_sda5.txt >>http://www.emergence.com/xfs_trouble/xfs_repair_sda5.txt >> >>The machine was originally running a single Quantum Atlas V on Ultra 160 >>Scsi chain. I have moved this machine to two Maxtor 20G drives with >>Raid 1 mirroring. The Scsi chain is still in the machine with the >>broken filesystem drive and I can make it available/prepare a filesystem >>dump (perhaps someone can explain how to do that). Hopefully I have >>enough space on my drive for that. >> >>I saw other people with this error in the mailing list archives but >>didn't see if there was a solution to this problem. >> >>-- >>Michael Best >>Systems Administrator ph 780-413-6397 x230 >>Emergence By Design fax 780-433-7548 >>#200, 11209 Jasper Avenue toll 866-860-2666 >>Edmonton, Alberta, T5K 0L5 >> -- -------------------------------------------- -- Kelly Corbin -- Systems Administrator -- -- http://www.theiqgroup.com -- The Future of eServices... -- -- The IQ Group, Inc. -- 6740 Antioch Suite 110 -- Merriam, KS 66204 -- (913)-722-6700 x105 -- Fax (913)722-7264 -------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Jun 10 11:30:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AIUsnC024161 for ; Mon, 10 Jun 2002 11:30:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AIUs4p024160 for linux-xfs-outgoing; Mon, 10 Jun 2002 11:30:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AIUmnC024127 for ; Mon, 10 Jun 2002 11:30:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA12019 for ; Mon, 10 Jun 2002 13:33:03 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA71089 for ; Mon, 10 Jun 2002 13:33:03 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5AIX1X00751; Mon, 10 Jun 2002 13:33:01 -0500 Message-Id: <200206101833.g5AIX1X00751@jen.americas.sgi.com> Date: Mon, 10 Jun 2002 13:33:01 -0500 Subject: TAKE - remove dead code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another contribution to the dead code society from Christoph Date: Mon Jun 10 11:29:39 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121156a linux/fs/xfs/xfs_grio.c - 1.89 linux/fs/xfs/xfs_itable.c - 1.106 linux/fs/xfs/xfs_itable.h - 1.36 linux/fs/xfs/xfs_utils.c - 1.46 linux/fs/xfs/xfs_utils.h - 1.19 linux/fs/xfs/linux/xfs_vfs.c - 1.31 linux/fs/xfs/linux/xfs_linux.h - 1.70 linux/fs/xfs/linux/xfs_vfs.h - 1.15 From owner-linux-xfs@oss.sgi.com Mon Jun 10 11:41:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AIfGnC024418 for ; Mon, 10 Jun 2002 11:41:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AIfGgk024417 for linux-xfs-outgoing; Mon, 10 Jun 2002 11:41:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AIfCnC024389 for ; Mon, 10 Jun 2002 11:41:12 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA12339 for ; Mon, 10 Jun 2002 13:43:27 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA43286 for ; Mon, 10 Jun 2002 13:43:27 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id NAA39634 for linux-xfs@oss.sgi.com; Mon, 10 Jun 2002 13:43:26 -0500 (CDT) Date: Mon, 10 Jun 2002 13:43:26 -0500 (CDT) From: Dean Roehrich Message-Id: <200206101843.NAA39634@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - for invisible I/O, open large files with O_LARGEFILE X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 10 11:42:56 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121160a linux/fs/xfs/xfs_dmapi.c - 1.59 - invisible I/O needs to open large files with O_LARGEFILE. From owner-linux-xfs@oss.sgi.com Mon Jun 10 11:52:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AIq8nC024993 for ; Mon, 10 Jun 2002 11:52:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AIq8CX024992 for linux-xfs-outgoing; Mon, 10 Jun 2002 11:52:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AIpwnC024964 for ; Mon, 10 Jun 2002 11:51:58 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA10851; Mon, 10 Jun 2002 13:54:12 -0500 (CDT) Received: from fsgi416.americas.sgi.com (fsgi416.americas.sgi.com [128.162.187.51]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA75437; Mon, 10 Jun 2002 13:54:11 -0500 (CDT) Received: from sgi.com by fsgi416.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id NAA93106; Mon, 10 Jun 2002 13:54:10 -0500 (CDT) Message-ID: <3D04F5D0.1937A58C@sgi.com> Date: Mon, 10 Jun 2002 13:54:09 -0500 From: John Kihonge X-Mailer: Mozilla 4.76C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Matteo Centonza CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump recursive exclusion attribute References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Matteo Centonza wrote: > Hi, > > i'm trying to figure out if there's an easy way to skip several subtrees > with xsfdump without the need of specifying a bunch of subpaths on the > command line. > > I've read man pages, and excerpting: > > [snip] > > Excluding individual files > Occasionally it is desirable to be able to exclude partic- > ular files or directories from the dump. The -s option > can be used to limit the dump to a specified directory, > and the -z option can be used to exclude files over a par- > ticular size. Additionally, when xfsdump is run with the > -e option individual files can be "tagged" so that xfsdump > will not include them in a dump. Files are tagged by > assigning that file an extended attribute with the name > "SGI_XFSDUMP_SKIP_FILE". This can be done with the > attr(1) command: > > $ attr -s "SGI_XFSDUMP_SKIP_FILE" -V "" file > > To remove the attribute: > > $ attr -r "SGI_XFSDUMP_SKIP_FILE" file > > It should be noted that xfsdump will not check directories > for this attribute. It should also be noted that this use > of extended attributes is not the same as that used by the > chattr(1) command. > > [snip] > > Is there a way to achieve this task at filesystem level. If not, will it > be useful and possible to make xfsdump recognize a sort of SGI_XFSDUMP_SKIP_DIR > attribute, skipping the whole subtree (a sort of attribute-coded -s option)? > > Thanks in advance, > > -m I do not know of any way you can do that at the filesystem level. If one changed the appropriate code, it should be possible to make xfsdump recognize an attribute and skip the whole subtree, similar to the file option. I do not know if any one in the community has tried to change the code to do that yet. There are no plans at the moment to add that feature to xfsdump but it may be added in the future if we get the resources. Thanks, Kihonge JN From owner-linux-xfs@oss.sgi.com Mon Jun 10 12:47:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5AJlZnC026895 for ; Mon, 10 Jun 2002 12:47:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5AJlZD4026894 for linux-xfs-outgoing; Mon, 10 Jun 2002 12:47:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5AJlTnC026863 for ; Mon, 10 Jun 2002 12:47:30 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA12077 for ; Mon, 10 Jun 2002 14:49:45 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA19231 for ; Mon, 10 Jun 2002 14:49:44 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id OAA66731 for linux-xfs@oss.sgi.com; Mon, 10 Jun 2002 14:49:44 -0500 (CDT) Date: Mon, 10 Jun 2002 14:49:44 -0500 (CDT) From: Dean Roehrich Message-Id: <200206101949.OAA66731@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - release ilock during dmapi write event X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 10 12:49:23 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121166a linux/fs/xfs/linux/xfs_lrw.c - 1.143 - when sending a dmapi write event from xfs_write(), release the ilock during the event. From owner-linux-xfs@oss.sgi.com Mon Jun 10 18:16:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5B1GenC001001 for ; Mon, 10 Jun 2002 18:16:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5B1Genx001000 for linux-xfs-outgoing; Mon, 10 Jun 2002 18:16:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5B1GWnC000969 for ; Mon, 10 Jun 2002 18:16:32 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id SAA07123 for ; Mon, 10 Jun 2002 18:18:51 -0700 (PDT) mail_from (ivanr@sgi.com) Received: from omen (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via SMTP id LAA11314; Tue, 11 Jun 2002 11:17:28 +1000 Date: Tue, 11 Jun 2002 11:17:28 +1000 From: Ivan Rayner To: Matteo Centonza Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump recursive exclusion attribute Message-Id: <20020611111728.33525a97.ivanr@sgi.com> In-Reply-To: References: Organization: SGI X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 10 Jun 2002 12:15:22 +0200 (CEST), Matteo Centonza wrote: > i'm trying to figure out if there's an easy way to skip several > subtrees with xsfdump without the need of specifying a bunch of > subpaths on the command line. This was deliberately not done for mainly two reasons: 1. Performance. The current system of excluding files was able to be implemented in such a way that it had very little performance impact on xfsdump. Handling directories however, would have had a significant impact as it would have meant invoking the "directory pruning" stage. 2. Security. I felt that allowing a user to exclude an entire directory tree, regardless of the contents of that tree, could very well lead to problems. Directories owned by Frank could contain files and entire directory trees owned by Joe. If Frank decides to exclude the tree, Joe will not have any of his files backed up, and Joe wont necessarily know about this until he tries a restore. It shouldn't be possible for a user to decide whether another user's files get included in a backup. This is a decision for the owner or for the administator. IMO, the best way to do this would be as an option to xfsdump -- sort of an inverse of the -s option. At the moment, however, you will either have to set the attribute on all the files in the tree you want to exclude, or use the -s option to specify all the directory trees you want to include. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jun 10 22:25:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5B5PMnC002923 for ; Mon, 10 Jun 2002 22:25:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5B5PMMF002922 for linux-xfs-outgoing; Mon, 10 Jun 2002 22:25:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5B5PFnC002893 for ; Mon, 10 Jun 2002 22:25:16 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id WAA01711 for ; Mon, 10 Jun 2002 22:27:33 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA13163; Tue, 11 Jun 2002 15:26:03 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5B5OeHr003369; Tue, 11 Jun 2002 15:24:40 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5B5Oc9h003367; Tue, 11 Jun 2002 15:24:38 +1000 Date: Tue, 11 Jun 2002 15:24:38 +1000 From: Nathan Scott To: hcx Cc: linux-xfs@oss.sgi.com Subject: Re: quotaoff error Message-ID: <20020611052438.GD2004@frodo> References: <002401c20ddc$24d4b080$5868010a@bsd.tnes.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401c20ddc$24d4b080$5868010a@bsd.tnes.nec.co.jp> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 07, 2002 at 01:31:07PM +0900, hcx wrote: > > Hi XFS stuff. > > There is a problem about XFS filesystem when XFS_DEBUG is setted. > the kernel is 2.4.17and 2.4.18. > > mount -t xfs -o usrquota,grpquota /dev/hda8 /mnt > touch /mnt/f1 > rm /mnt/f1 > quotaoff /mnt > there is ASSERT error.the error information is like this. Thanks - I have a fix for this and it will show up in CVS shortly. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jun 10 22:30:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5B5UDnC003121 for ; Mon, 10 Jun 2002 22:30:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5B5UDvQ003120 for linux-xfs-outgoing; Mon, 10 Jun 2002 22:30:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5B5U7nC003091 for ; Mon, 10 Jun 2002 22:30:07 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA09833 for ; Mon, 10 Jun 2002 22:32:27 -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 PAA15718 for linux-xfs@oss.sgi.com; Tue, 11 Jun 2002 15:30:15 +1000 (EST) Date: Tue, 11 Jun 2002 15:30:15 +1000 (EST) From: Nathan Scott Message-Id: <200206110530.PAA15718@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quotaoff X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 10 22:29:57 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121202a linux/fs/xfs/xfs_qm_syscalls.c - 1.63 - fix quotaoff assertion failure for recently removed inodes in the mount list; this code is now aligned up with similar code in xfs_iflush_all() & xfs_ibusy(). linux/fs/xfs/linux/xfs_lrw.c - 1.144 - fix debug builds - were still refering to uiop in a couple of places. From owner-linux-xfs@oss.sgi.com Mon Jun 10 22:50:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5B5oUnC003396 for ; Mon, 10 Jun 2002 22:50:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5B5oU9H003395 for linux-xfs-outgoing; Mon, 10 Jun 2002 22:50:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5B5oOnC003367 for ; Mon, 10 Jun 2002 22:50:25 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id WAA08213 for ; Mon, 10 Jun 2002 22:52:44 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA13351; Tue, 11 Jun 2002 15:51:24 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5B5o0Hr003496; Tue, 11 Jun 2002 15:50:00 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5B5nvmE003494; Tue, 11 Jun 2002 15:49:57 +1000 Date: Tue, 11 Jun 2002 15:49:57 +1000 From: Nathan Scott To: Olaf Fr?czyk Cc: linux-xfs@oss.sgi.com Subject: Re: Any workaround for samba and quotas Message-ID: <20020611054957.GA3471@frodo> References: <1023363088.11705.7.camel@venus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1023363088.11705.7.camel@venus> User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 06, 2002 at 01:31:28PM +0200, Olaf Fr?czyk wrote: > Hi, > I need to compile samba with quota support. > Will it work if for time I compile samba I put quota headers from > vanilla kernel into includes? I believe Jeremy has fixed these problems in the Samba source, so you should be able to get latest Samba CVS code and try that out, and it should fix the problem. Let us know how it goes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jun 11 00:25:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5B7P1nC004597 for ; Tue, 11 Jun 2002 00:25:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5B7P1Y0004596 for linux-xfs-outgoing; Tue, 11 Jun 2002 00:25:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5B7OonC004564 for ; Tue, 11 Jun 2002 00:24:50 -0700 Received: from erbenson.alaska.net (22-pm21.nwc.alaska.net [209.112.143.22]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g5B7RAd90327 for ; Mon, 10 Jun 2002 23:27:11 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id E5F143924 for ; Mon, 10 Jun 2002 23:27:09 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id A2B0110294; Mon, 10 Jun 2002 23:27:09 -0800 (AKDT) Date: Mon, 10 Jun 2002 23:27:09 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfsdump recursive exclusion attribute Message-ID: <20020610232709.D9152@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020611111728.33525a97.ivanr@sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SO98HVl1bnMOfKZd" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020611111728.33525a97.ivanr@sgi.com>; from ivanr@sgi.com on Tue, Jun 11, 2002 at 11:17:28AM +1000 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --SO98HVl1bnMOfKZd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 11, 2002 at 11:17:28AM +1000, Ivan Rayner wrote: > On Mon, 10 Jun 2002 12:15:22 +0200 (CEST), Matteo Centonza wrote: >=20 > > i'm trying to figure out if there's an easy way to skip several > > subtrees with xsfdump without the need of specifying a bunch of > > subpaths on the command line. >=20 > This was deliberately not done for mainly two reasons: >=20 > 1. Performance. The current system of excluding files was able to be > implemented in such a way that it had very little performance impact on > xfsdump. Handling directories however, would have had a significant > impact as it would have meant invoking the "directory pruning" stage. >=20 > 2. Security. I felt that allowing a user to exclude an entire directory > tree, regardless of the contents of that tree, could very well lead to > problems. Directories owned by Frank could contain files and entire > directory trees owned by Joe. If Frank decides to exclude the tree, J= oe > will not have any of his files backed up, and Joe wont necessarily know > about this until he tries a restore. It shouldn't be possible for a > user to decide whether another user's files get included in a backup. > This is a decision for the owner or for the administator. this is a good point. (though ext2/ext3 do it anyway) > IMO, the best way to do this would be as an option to xfsdump -- sort of > an inverse of the -s option. >=20 > At the moment, however, you will either have to set the attribute on all > the files in the tree you want to exclude, or use the -s option to > specify all the directory trees you want to include. a way to specify a glob or regexp for exclusion would be useful, for example */.mozilla/*/Cache --=20 Ethan Benson http://www.alaska.net/~erbenson/ --SO98HVl1bnMOfKZd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0Fpk0ACgkQJKx7GixEevwAnQCeLLNYQKxqqKridf0uSiZ9igZ7 TdMAnijbA4jPfcT4gXKNtNXvLSBBOZUI =2xBu -----END PGP SIGNATURE----- --SO98HVl1bnMOfKZd-- From owner-linux-xfs@oss.sgi.com Tue Jun 11 01:24:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5B8OTnC005452 for ; Tue, 11 Jun 2002 01:24:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5B8OT95005451 for linux-xfs-outgoing; Tue, 11 Jun 2002 01:24:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5B8OInC005423 for ; Tue, 11 Jun 2002 01:24:19 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g5B8QoK07010; Tue, 11 Jun 2002 10:26:50 +0200 Date: Tue, 11 Jun 2002 10:26:50 +0200 (CEST) From: Matteo Centonza To: John Kihonge , Ivan Rayner cc: Subject: Re: xfsdump recursive exclusion attribute In-Reply-To: <20020611111728.33525a97.ivanr@sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi John, Ivan, thanks for the reply; > On Mon, 10 Jun 2002 12:15:22 +0200 (CEST), Matteo Centonza wrote: > > > i'm trying to figure out if there's an easy way to skip several > > subtrees with xsfdump without the need of specifying a bunch of > > subpaths on the command line. > > This was deliberately not done for mainly two reasons: > > 1. Performance. The current system of excluding files was able to be > implemented in such a way that it had very little performance impact on > xfsdump. Handling directories however, would have had a significant > impact as it would have meant invoking the "directory pruning" stage. > BTW you can skip (or better trigger) the directory pruning or the recursive exclusion via a flag to xfsdump. > 2. Security. I felt that allowing a user to exclude an entire directory > tree, regardless of the contents of that tree, could very well lead to > problems. Directories owned by Frank could contain files and entire > directory trees owned by Joe. If Frank decides to exclude the tree, Joe > will not have any of his files backed up, and Joe wont necessarily know > about this until he tries a restore. It shouldn't be possible for a > user to decide whether another user's files get included in a backup. > This is a decision for the owner or for the administator. > that's quite draconian. I don't know attribute's guts much in details, but maybe you can prevent a user from setting a kind of attribute (using a reserved namespace). > IMO, the best way to do this would be as an option to xfsdump -- sort of > an inverse of the -s option. > > At the moment, however, you will either have to set the attribute on all > the files in the tree you want to exclude, or use the -s option to > specify all the directory trees you want to include. Ciao, -m From owner-linux-xfs@oss.sgi.com Tue Jun 11 02:24:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5B9ONnC006265 for ; Tue, 11 Jun 2002 02:24:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5B9ONSE006264 for linux-xfs-outgoing; Tue, 11 Jun 2002 02:24:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5B9OBnC006231 for ; Tue, 11 Jun 2002 02:24:11 -0700 Received: from erbenson.alaska.net (22-pm21.nwc.alaska.net [209.112.143.22]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g5B9QXX35003 for ; Tue, 11 Jun 2002 01:26:33 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 299403924 for ; Tue, 11 Jun 2002 01:26:32 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 239F710294; Tue, 11 Jun 2002 01:26:32 -0800 (AKDT) Date: Tue, 11 Jun 2002 01:26:32 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfsdump recursive exclusion attribute Message-ID: <20020611012632.F9152@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020611111728.33525a97.ivanr@sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ExXT7PjY8AI4Hyfa" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from matteo@sif.it on Tue, Jun 11, 2002 at 10:26:50AM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --ExXT7PjY8AI4Hyfa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 11, 2002 at 10:26:50AM +0200, Matteo Centonza wrote: > > user to decide whether another user's files get included in a backup. > > This is a decision for the owner or for the administator. > >=20 >=20 > that's quite draconian. I don't know attribute's guts much in details, bu= t=20 > maybe you can prevent a user from setting a kind of attribute=20 > (using a reserved namespace). you misunderstand, you must have write permission to the file/dir to apply a user.* extended attribute, generally if you can write the file/dir you can rm -rf it, or cat /dev/random all over it, so adding a DONT_BACKUP attribute is the least of the problems. however what Ivan was talking about is quite different, say you have two people, joe and steve, joe is leading some project, project bar, and steve is also working on it, so they have something like: /home/joe/project-bar (owned by joe) /home/joe/project-bar/fubar (owned by steve) steve has all sorts of things under /home/joe/project-bar/fubar which he assumes is being backed up, because the responsible admin backs up /home regularly. however it turns out joe smokes a lot of crack on free time so does stupid things like marking /home/joe/project-bar as DONT_BACKUP, if xfsdump respects this then it will skip /home/joe/project-bar and everything under it, including all of steves's files in /home/joe/project-bar/fubar. somewhat a contrived example, but i can think of many other cases where allowing this sort of thing could be a problem. even more so using the user.* attribute since you might have a top level dir writable by a group, and various group members have thier own directories under that which are not writable by the group, the group can prevent the group members files from being backed up. i think ext2/3 only allow the file owner to set chattr flags like nodump, so for directories assuming xfs wanted to support this (in the ext2 manner) would need to invent a new system.something namespace just for this, that involves kernel bloat. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --ExXT7PjY8AI4Hyfa Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0FwkcACgkQJKx7GixEevy2VwCgn+u18XnEsxsEJp6UyCWQ+EAo 7PgAnjMWWISFfWKpkm9prjYrA7pCcxZU =PrZo -----END PGP SIGNATURE----- --ExXT7PjY8AI4Hyfa-- From owner-linux-xfs@oss.sgi.com Tue Jun 11 03:19:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BAJenC007113 for ; Tue, 11 Jun 2002 03:19:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BAJeDQ007112 for linux-xfs-outgoing; Tue, 11 Jun 2002 03:19:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BAJSnC007082 for ; Tue, 11 Jun 2002 03:19:29 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g5BAM7O12328; Tue, 11 Jun 2002 12:22:07 +0200 Date: Tue, 11 Jun 2002 12:22:07 +0200 (CEST) From: Matteo Centonza To: Ethan Benson cc: Subject: Re: xfsdump recursive exclusion attribute In-Reply-To: <20020611012632.F9152@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ethan, > On Tue, Jun 11, 2002 at 10:26:50AM +0200, Matteo Centonza wrote: > > > user to decide whether another user's files get included in a backup. > > > This is a decision for the owner or for the administator. > > > > > > > that's quite draconian. I don't know attribute's guts much in details, but > > maybe you can prevent a user from setting a kind of attribute > > (using a reserved namespace). > > you misunderstand, you must have write permission to the file/dir to > apply a user.* extended attribute, generally if you can write the > file/dir you can rm -rf it, or cat /dev/random all over it, so adding > a DONT_BACKUP attribute is the least of the problems. > > however what Ivan was talking about is quite different, say you have > two people, joe and steve, joe is leading some project, project bar, > and steve is also working on it, so they have something like: > > /home/joe/project-bar (owned by joe) > /home/joe/project-bar/fubar (owned by steve) > > steve has all sorts of things under /home/joe/project-bar/fubar which > he assumes is being backed up, because the responsible admin backs up > /home regularly. however it turns out joe smokes a lot of crack on > free time so does stupid things like marking /home/joe/project-bar > as DONT_BACKUP, if xfsdump respects this then it will skip > /home/joe/project-bar and everything under it, including all of > steves's files in /home/joe/project-bar/fubar. are you sure you have mastered all details? Using a reserved namespace, means ``Hey, this is administrator things'', so it's up to the administrator to set this kind of stuff, not to the user. With this approach, you're on the safe side IMHO. BTW, if the administrator smokes Crack then you're toast anyway ;) > somewhat a contrived example, but i can think of many other cases > where allowing this sort of thing could be a problem. even more so > using the user.* attribute since you might have a top level dir > writable by a group, and various group members have thier own > directories under that which are not writable by the group, the group > can prevent the group members files from being backed up. > > i think ext2/3 only allow the file owner to set chattr flags like > nodump, so for directories assuming xfs wanted to support this (in the > ext2 manner) would need to invent a new system.something namespace just > for this, that involves kernel bloat. As you stated above ext* already have a similar feature. As last, are you sure the needed infrastructure it's still not present here? (i've not yet found a paper describing the current implementation). Ciao, -m From owner-linux-xfs@oss.sgi.com Tue Jun 11 03:57:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BAvnnC007512 for ; Tue, 11 Jun 2002 03:57:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BAvmNp007511 for linux-xfs-outgoing; Tue, 11 Jun 2002 03:57:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BAvanC007466 for ; Tue, 11 Jun 2002 03:57:36 -0700 Received: from erbenson.alaska.net (132-pm11.nwc.alaska.net [209.112.140.132]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g5BAxuR71157 for ; Tue, 11 Jun 2002 02:59:57 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 8E6D13924 for ; Tue, 11 Jun 2002 02:59:55 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id BDB7410294; Tue, 11 Jun 2002 02:59:55 -0800 (AKDT) Date: Tue, 11 Jun 2002 02:59:55 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfsdump recursive exclusion attribute Message-ID: <20020611025955.G9152@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020611012632.F9152@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="E69HUUNAyIJqGpVn" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from matteo@sif.it on Tue, Jun 11, 2002 at 12:22:07PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --E69HUUNAyIJqGpVn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 11, 2002 at 12:22:07PM +0200, Matteo Centonza wrote: >=20 > are you sure you have mastered all details? unless something changed very recently yes. > Using a reserved namespace, means ``Hey, this is administrator things'', > so it's up to the administrator to set this kind of stuff, not to the=20 > user. With this approach, you're on the safe side IMHO. BTW, if the=20 > administrator smokes Crack then you're toast anyway ;) there is no such namespace at this time. system.* is special, there are only specific system namespaces defined and the user (even root) cannot just make up new ones. right now there is system.posix_acl_access (only file owner may write this attribute) and system.posix_acl_default (same as _access). there is also an xfs specific system.xfsroot (i think thats right) which only root may read/write/see. the only other xattr namespace at the moment is user.* which is entirely controled by the file/dirs permission bits. (with exceptions for symlinks and special files). there has been discussion about making a owner.* namespace or such, which would only be writable by the file owner, but this does not exist as of yet. so you see there is no place for this per directory attribute except perhaps the system.xfsroot namespace, but im not entirely sure this namespace is really meant to be fscked with by end users.=20=20 > As you stated above ext* already have a similar feature. ext2 allows the object *owner* to decide this, Ivan is of the opinion that the file owner shouldn't have that authority in the case of a directory, thats debatable. if we are discussing implementing the ext2 feature as it works now there is NOT sufficient infrastructure in the extended attributes to do it. (there is no xattr namespace that allows arbitrary attributes which are only writable by the file owner). i am of the opinion that if only root is to be allowed to exclude directories then it should be done with an xfsdump command line argument and not a filesystem attribute. i tend to agree with ivan that allowing lusers to arbitrarly exclude directories from backups is probably not a good idea. (fwiw all i use the ext2 chattr +d for is crap like browser cache and large source trees i only plan to keep temporarly and don't want my limited backup space exhausted by). > As last, are you sure the needed infrastructure it's still not present=20 > here? (i've not yet found a paper describing the current implementation). see above. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --E69HUUNAyIJqGpVn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0F2CsACgkQJKx7GixEevz52gCfUtFXjbqrIbM7D/T6rGMeW/1o rXAAn0xFvFTrWhrleBmSaT5h2AtWVzod =BYkS -----END PGP SIGNATURE----- --E69HUUNAyIJqGpVn-- From owner-linux-xfs@oss.sgi.com Tue Jun 11 04:28:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BBS0nC008964 for ; Tue, 11 Jun 2002 04:28:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BBS0iS008963 for linux-xfs-outgoing; Tue, 11 Jun 2002 04:28:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from quasar.sif.it (quasar.sif.it [131.154.110.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BBRinC008934 for ; Tue, 11 Jun 2002 04:27:45 -0700 Received: from localhost (matteo@localhost) by quasar.sif.it (8.11.6/8.11.6) with ESMTP id g5BBULv14062; Tue, 11 Jun 2002 13:30:21 +0200 Date: Tue, 11 Jun 2002 13:30:21 +0200 (CEST) From: Matteo Centonza To: Ethan Benson cc: Subject: Re: xfsdump recursive exclusion attribute In-Reply-To: <20020611025955.G9152@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ethan, > On Tue, Jun 11, 2002 at 12:22:07PM +0200, Matteo Centonza wrote: > > > > are you sure you have mastered all details? > > unless something changed very recently yes. no, reasons still apply ;) > > > Using a reserved namespace, means ``Hey, this is administrator things'', > > so it's up to the administrator to set this kind of stuff, not to the > > user. With this approach, you're on the safe side IMHO. BTW, if the > > administrator smokes Crack then you're toast anyway ;) > > there is no such namespace at this time. system.* is special, there > are only specific system namespaces defined and the user (even root) > cannot just make up new ones. right now there is > system.posix_acl_access (only file owner may write this attribute) and > system.posix_acl_default (same as _access). there is also an xfs > specific system.xfsroot (i think thats right) which only root may > read/write/see. the only other xattr namespace at the moment is > user.* which is entirely controled by the file/dirs permission > bits. (with exceptions for symlinks and special files). are system.xfsroot (like, if any) feasible for this? > there has been discussion about making a owner.* namespace or such, > which would only be writable by the file owner, but this does not > exist as of yet. > > so you see there is no place for this per directory attribute except > perhaps the system.xfsroot namespace, but im not entirely sure this > namespace is really meant to be fscked with by end users. > > > As you stated above ext* already have a similar feature. > > ext2 allows the object *owner* to decide this, Ivan is of the opinion > that the file owner shouldn't have that authority in the case of a > directory, thats debatable. if we are discussing implementing the > ext2 feature as it works now there is NOT sufficient infrastructure in > the extended attributes to do it. (there is no xattr namespace that > allows arbitrary attributes which are only writable by the file owner). Yet again, you have to consider this as an administator feature, not an user one. Doing so, you can skip a lot of implementation complexity. > > i am of the opinion that if only root is to be allowed to exclude > directories then it should be done with an xfsdump command line > argument and not a filesystem attribute. i tend to agree with ivan > that allowing lusers to arbitrarly exclude directories from backups is > probably not a good idea. (fwiw all i use the ext2 chattr +d for is > crap like browser cache and large source trees i only plan to keep > temporarly and don't want my limited backup space exhausted by). well, i disagree here. If you use to wrap around your dump command with a backup suite like AMANDA (that ``silently ignores exclude list by dump'') you cannot reach the same goal easily. In any case, doing so you have a lot more low level control on your backup process, transparently to the end application. Imagine you have to dynamically add via an application a new dir that won't be backed up to your filesystem. Immediately you have to extend the list of backed-up trees in your dump command ;( Just thoughts, -m From owner-linux-xfs@oss.sgi.com Tue Jun 11 05:27:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BCR8nC010328 for ; Tue, 11 Jun 2002 05:27:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BCR8Zg010327 for linux-xfs-outgoing; Tue, 11 Jun 2002 05:27:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BCR2nC010299 for ; Tue, 11 Jun 2002 05:27:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA17624 for ; Tue, 11 Jun 2002 07:29:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA20411 for ; Tue, 11 Jun 2002 07:29:20 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BCTBp18791; Tue, 11 Jun 2002 07:29:11 -0500 Message-Id: <200206111229.g5BCTBp18791@jen.americas.sgi.com> Date: Tue, 11 Jun 2002 07:29:11 -0500 Subject: TAKE - fix broken write path To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I tested it honest! I broke O_APPEND writes yesterday, one line fix just went in. Steve Date: Tue Jun 11 05:28:17 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121206a linux/fs/xfs/linux/xfs_file.c - 1.65 - fix O_APPEND writes From owner-linux-xfs@oss.sgi.com Tue Jun 11 06:35:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BDZGnC011220 for ; Tue, 11 Jun 2002 06:35:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BDZGUo011219 for linux-xfs-outgoing; Tue, 11 Jun 2002 06:35:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BDZAnC011184 for ; Tue, 11 Jun 2002 06:35:10 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA17717 for ; Tue, 11 Jun 2002 08:37:27 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA13476 for ; Tue, 11 Jun 2002 08:37:27 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BDYfc28702; Tue, 11 Jun 2002 08:34:41 -0500 Message-Id: <200206111334.g5BDYfc28702@stout.americas.sgi.com> Date: Tue, 11 Jun 2002 08:34:41 -0500 Subject: TAKE - Remove delete_inode method X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I had removed linvfs_delete_inode and pointed the delete_inode method at linux's clear_inode(), but as Christoph pointed out, removing the delete_inode method will accomplish the same thing; the VFS calls clear_inode() if there is no delete_inode method. Date: Tue Jun 11 06:34:59 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121209a linux/fs/xfs/linux/xfs_super.c - 1.177 - Just remove delete_inode altogether; VFS will call clear_inode if it's not there From owner-linux-xfs@oss.sgi.com Tue Jun 11 07:27:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BER7nC012072 for ; Tue, 11 Jun 2002 07:27:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BER7Mo012071 for linux-xfs-outgoing; Tue, 11 Jun 2002 07:27:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BER2nC012043 for ; Tue, 11 Jun 2002 07:27:02 -0700 Received: from test2 (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with SMTP id 6FA2DB757 for ; Tue, 11 Jun 2002 07:29:23 -0700 (PDT) From: "Tang Lingbo (Allan)" To: "Linux-Xfs" Subject: Help me choose a stable version Date: Tue, 11 Jun 2002 22:29:06 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g5BER2nC012044 X-Spam-Status: No, hits=1.9 required=5.0 tests=MAY_BE_FORGED,TO_LOCALPART_EQ_REAL version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I notice that there have been many bugs reported / fixed from 1.1 release and cvs update everyday. At present, we need a stable file system in our products. Anyone can help me make a choice: Which version is better / stable to use in a productive environment? XFS-1.1 release ? or I have to get the patch from current CVS? Any suggestion is appreciated. Regards, Allan From owner-linux-xfs@oss.sgi.com Tue Jun 11 07:31:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BEVbnC012276 for ; Tue, 11 Jun 2002 07:31:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BEVbVt012275 for linux-xfs-outgoing; Tue, 11 Jun 2002 07:31:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BEVTnC012247 for ; Tue, 11 Jun 2002 07:31:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA08197; Tue, 11 Jun 2002 09:33:47 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA22685; Tue, 11 Jun 2002 09:33:47 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BEXbf21631; Tue, 11 Jun 2002 09:33:37 -0500 Subject: Re: Help me choose a stable version From: Steve Lord To: "Tang Lingbo (Allan)" Cc: Linux-Xfs In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 09:33:37 -0500 Message-Id: <1023806017.19330.14.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-11 at 09:29, Tang Lingbo (Allan) wrote: > Hi, > > I notice that there have been many bugs reported / fixed from 1.1 release and > cvs update everyday. At present, we need a stable file system in our products. > Anyone can help me make a choice: > Which version is better / stable to use in a productive environment? > XFS-1.1 release ? or I have to get the patch from current CVS? > > Any suggestion is appreciated. > > Regards, > Allan You might be better waiting until 2.4.19 hits the tree - of course we cannot predict when that might happen. In general the cvs tree does have a lot of fixes beyond 1.1 in it, and it will be faster. However, as you may have noticed, it is occasionally broken. Which ever code base you take, you should of course run it through some form of QA process before putting it in a product. If you find problems when you do that, then we are much more likely to try and fix them if you use the cvs tree. Pushing fixes back to the old code bases gets painful. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 11 08:26:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BFQLnC012885 for ; Tue, 11 Jun 2002 08:26:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BFQLS9012884 for linux-xfs-outgoing; Tue, 11 Jun 2002 08:26:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BFQGnC012855 for ; Tue, 11 Jun 2002 08:26:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA18353 for ; Tue, 11 Jun 2002 10:28:34 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA07012 for ; Tue, 11 Jun 2002 10:28:34 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BFSOZ23013; Tue, 11 Jun 2002 10:28:24 -0500 Subject: TAKE - remove old mips abi code From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 10:28:24 -0500 Message-Id: <1023809304.19330.19.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 11 08:27:28 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121219a linux/fs/xfs/xfs_dir.c - 1.136 linux/fs/xfs/xfs_dir_leaf.c - 1.101 linux/fs/xfs/xfs_dir_leaf.h - 1.34 linux/fs/xfs/xfs_dir2.c - 1.33 linux/fs/xfs/linux/xfs_linux.h - 1.71 linux/fs/xfs_dmapi/dmapi_private.h - 1.8 From owner-linux-xfs@oss.sgi.com Tue Jun 11 08:28:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BFSLnC013041 for ; Tue, 11 Jun 2002 08:28:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BFSL6k013040 for linux-xfs-outgoing; Tue, 11 Jun 2002 08:28:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BFSHnC013011 for ; Tue, 11 Jun 2002 08:28:17 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA19070 for ; Tue, 11 Jun 2002 10:30:36 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA32513 for ; Tue, 11 Jun 2002 10:30:35 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BFUO623306; Tue, 11 Jun 2002 10:30:24 -0500 Message-Id: <200206111530.g5BFUO623306@jen.americas.sgi.com> Date: Tue, 11 Jun 2002 10:30:24 -0500 Subject: TAKE - fix a type cast in the readdir path To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 11 08:29:37 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121220a linux/fs/xfs/linux/xfs_file.c - 1.66 - fix a type cast on filldir From owner-linux-xfs@oss.sgi.com Tue Jun 11 08:52:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BFqhnC013490 for ; Tue, 11 Jun 2002 08:52:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BFqhMJ013489 for linux-xfs-outgoing; Tue, 11 Jun 2002 08:52:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BFqanC013460 for ; Tue, 11 Jun 2002 08:52:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA11574 for ; Tue, 11 Jun 2002 10:54:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA32214 for ; Tue, 11 Jun 2002 10:54:55 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BFsjC27005; Tue, 11 Jun 2002 10:54:45 -0500 Message-Id: <200206111554.g5BFsjC27005@jen.americas.sgi.com> Date: Tue, 11 Jun 2002 10:54:45 -0500 Subject: TAKE - pass const pointer info down into write path To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another one from Christoph (along with the rest of this mornings changes), this one speeds up write by letting the compiler optimize more. Date: Tue Jun 11 08:51:39 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121222a linux/fs/xfs/linux/xfs_lrw.h - 1.24 linux/fs/xfs/linux/xfs_lrw.c - 1.145 linux/fs/xfs/linux/xfs_vnode.h - 1.41 linux/fs/xfs/pagebuf/page_buf_io.c - 1.44 linux/fs/xfs/pagebuf/page_buf.h - 1.19 From owner-linux-xfs@oss.sgi.com Tue Jun 11 09:13:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BGDunC014059 for ; Tue, 11 Jun 2002 09:13:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BGDuJu014058 for linux-xfs-outgoing; Tue, 11 Jun 2002 09:13:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BGDfnC013999 for ; Tue, 11 Jun 2002 09:13:42 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 85643C204 for ; Tue, 11 Jun 2002 17:50:07 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id RAA07129 for linux-xfs@oss.sgi.com; Tue, 11 Jun 2002 17:50:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 9926957306 for ; Tue, 11 Jun 2002 17:49:04 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id BDD7225835 for ; Tue, 11 Jun 2002 17:49:03 +0200 (CEST) Message-ID: <3D061BEF.7C10A356@ch.sauter-bc.com> Date: Tue, 11 Jun 2002 17:49:03 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: New kernel RPMs 2.4.9-34SGI_XFS_1.1 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have built updated kernel-2.4.9-34SGI_XFS_1.1 RPMs for RH 7.1/7.2. So far the kernel works fine and I don't expect any problems because the patches from the kernel-2.4.9-31SGI_XFS_1.1 applied cleanly. Unfortunately I don't have the space to make the packages available. Eric, do you hear me... Simon From owner-linux-xfs@oss.sgi.com Tue Jun 11 09:15:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BGFcnC014251 for ; Tue, 11 Jun 2002 09:15:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BGFclH014250 for linux-xfs-outgoing; Tue, 11 Jun 2002 09:15:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BGFYnC014219 for ; Tue, 11 Jun 2002 09:15:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA19221 for ; Tue, 11 Jun 2002 11:17:53 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA39068 for ; Tue, 11 Jun 2002 11:17:53 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BGHgX30207; Tue, 11 Jun 2002 11:17:42 -0500 Message-Id: <200206111617.g5BGHgX30207@jen.americas.sgi.com> Date: Tue, 11 Jun 2002 11:17:42 -0500 Subject: TAKE - more minor cleanup To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More minor cleanups from Christoph, no functional changes here Date: Tue Jun 11 09:16:57 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121226a linux/fs/xfs/linux/xfs_vfs.c - 1.33 linux/fs/xfs/linux/xfs_vfs.h - 1.16 linux/fs/xfs/linux/xfs_stats.c - 1.5 linux/fs/xfs/linux/xfs_sysctl.c - 1.4 linux/fs/xfs/pagebuf/page_buf_io.c - 1.45 From owner-linux-xfs@oss.sgi.com Tue Jun 11 10:52:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BHqHnC015435 for ; Tue, 11 Jun 2002 10:52:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BHqHYA015434 for linux-xfs-outgoing; Tue, 11 Jun 2002 10:52:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BHqBnC015398 for ; Tue, 11 Jun 2002 10:52:11 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g5BHsKE26871 for linux-xfs@oss.sgi.com; Tue, 11 Jun 2002 12:54:20 -0500 Date: Tue, 11 Jun 2002 12:54:20 -0500 From: Dean Roehrich Message-Id: <200206111754.g5BHsKE26871@rope.americas> Subject: TAKE - remove dmapi tests handle_read_invis/handle_write_invis X-Spam-Status: No, hits=1.0 required=5.0 tests=SUBJ_REMOVE,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 11 10:54:03 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:121236a src/common/cmd/handle_write_invis.c - 1.6 - No Message Supplied src/common/cmd/handle_read_invis.c - 1.6 - No Message Supplied From owner-linux-xfs@oss.sgi.com Tue Jun 11 10:57:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BHvMnC015630 for ; Tue, 11 Jun 2002 10:57:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BHvMBS015629 for linux-xfs-outgoing; Tue, 11 Jun 2002 10:57:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BHvInC015598 for ; Tue, 11 Jun 2002 10:57:18 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g5BHxRX26941 for linux-xfs@oss.sgi.com; Tue, 11 Jun 2002 12:59:27 -0500 Date: Tue, 11 Jun 2002 12:59:27 -0500 From: Dean Roehrich Message-Id: <200206111759.g5BHxRX26941@rope.americas> Subject: TAKE - update dmapi tests read_invis/write_invis to accept handles and 64bit offsets X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 11 10:59:14 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:121238a src/common/cmd/read_invis.c - 1.8 - No Message Supplied src/common/cmd/write_invis.c - 1.8 - No Message Supplied From owner-linux-xfs@oss.sgi.com Tue Jun 11 10:58:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BHwZnC015819 for ; Tue, 11 Jun 2002 10:58:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BHwZ8C015818 for linux-xfs-outgoing; Tue, 11 Jun 2002 10:58:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BHwVnC015785 for ; Tue, 11 Jun 2002 10:58:31 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g5BI0eg27010 for linux-xfs@oss.sgi.com; Tue, 11 Jun 2002 13:00:40 -0500 Date: Tue, 11 Jun 2002 13:00:40 -0500 From: Dean Roehrich Message-Id: <200206111800.g5BI0eg27010@rope.americas> Subject: TAKE - X-Spam-Status: No, hits=2.8 required=5.0 tests=MISSING_HEADERS,SUBJ_ALL_CAPS version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 11 11:00:30 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:121239a src/common/cmd/Makefile.am - 1.6 - remove handle_write_invis/handle_read_invis From owner-linux-xfs@oss.sgi.com Tue Jun 11 11:00:29 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BI0TnC016006 for ; Tue, 11 Jun 2002 11:00:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BI0TQ2016005 for linux-xfs-outgoing; Tue, 11 Jun 2002 11:00:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BI0LnC015973 for ; Tue, 11 Jun 2002 11:00:21 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g5BI2U127085 for linux-xfs@oss.sgi.com; Tue, 11 Jun 2002 13:02:30 -0500 Date: Tue, 11 Jun 2002 13:02:30 -0500 From: Dean Roehrich Message-Id: <200206111802.g5BI2U127085@rope.americas> Subject: TAKE - fixup dmapi tests Makefile.in's X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 11 11:02:16 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/dmapitests The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs/cmd/xfstests/dmapi Modid: xfs-cmds:slinx:121240a Makefile.in - 1.5 - No Message Supplied configure.in - 1.4 - No Message Supplied aclocal.m4 - 1.4 - No Message Supplied src/Makefile.in - 1.5 - No Message Supplied src/suite2/Makefile.in - 1.5 - No Message Supplied src/suite2/src/Makefile.in - 1.5 - No Message Supplied src/suite1/Makefile.in - 1.5 - No Message Supplied src/suite1/cmd/Makefile.in - 1.5 - No Message Supplied src/simple/Makefile.in - 1.5 - No Message Supplied src/sample_hsm/Makefile.in - 1.6 - No Message Supplied src/common/Makefile.in - 1.5 - No Message Supplied src/common/cmd/Makefile.in - 1.5 - No Message Supplied src/common/lib/Makefile.in - 1.5 - No Message Supplied From owner-linux-xfs@oss.sgi.com Tue Jun 11 11:01:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BI18nC016163 for ; Tue, 11 Jun 2002 11:01:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BI18x1016162 for linux-xfs-outgoing; Tue, 11 Jun 2002 11:01:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BI10nC016133 for ; Tue, 11 Jun 2002 11:01:01 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id g5BI3P104008 for ; Tue, 11 Jun 2002 14:03:25 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 11 Jun 2002 14:03:25 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Linux xfs mailing list Subject: mounting with sync? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.9 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the course of trying to track down some disk performance issues, I'm trying to mount an XFS partition on a (slow) SCSI disk synchronously via the fstab entry: /dev/sda1 /mnt/test xfs logbufs=8,sync 0 0 However, I'm not getting the behavior I would expect: [root@brian root]# time dd if=/dev/zero of=/mnt/test/bigfile bs=1024k count=512; time umount /mnt/test 512+0 records in 512+0 records out real 0m57.848s user 0m0.000s sys 0m3.280s real 1m6.472s user 0m0.000s sys 0m0.610s So the 'dd' returns after 1 minute, but it takes it another minute to actually unmount the partition (during which there is lots of writing going on). I tried adding 'osyncisdysnc', which ISTR is the default now, and it (obviously) didn't help. Am I misinterpreting what's going on here? Is this the expected behavoir? The kernel is 2.4.18 from the 1.1 release. Thanks. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Jun 11 11:01:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BI1rnC016318 for ; Tue, 11 Jun 2002 11:01:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BI1rpd016317 for linux-xfs-outgoing; Tue, 11 Jun 2002 11:01:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@[216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BI1mnC016283 for ; Tue, 11 Jun 2002 11:01:49 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id DCAB44C303C; Tue, 11 Jun 2002 14:04:10 -0400 (EDT) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id AE092401A40; Tue, 11 Jun 2002 14:04:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id AC0F8C0393F; Tue, 11 Jun 2002 14:04:09 -0400 (EDT) Date: Tue, 11 Jun 2002 14:04:09 -0400 (EDT) From: Mike Burger To: Simon Matter Cc: linux-xfs@oss.sgi.com Subject: Re: New kernel RPMs 2.4.9-34SGI_XFS_1.1 In-Reply-To: <3D061BEF.7C10A356@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon: You still have that login on my server, where you can upload them. On Tue, 11 Jun 2002, Simon Matter wrote: > I have built updated kernel-2.4.9-34SGI_XFS_1.1 RPMs for RH 7.1/7.2. So > far the kernel works fine and I don't expect any problems because the > patches from the kernel-2.4.9-31SGI_XFS_1.1 applied cleanly. > Unfortunately I don't have the space to make the packages available. > Eric, do you hear me... > > Simon > > From owner-linux-xfs@oss.sgi.com Tue Jun 11 11:07:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BI72nC016556 for ; Tue, 11 Jun 2002 11:07:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BI72Zl016555 for linux-xfs-outgoing; Tue, 11 Jun 2002 11:07:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx.de.kpnqwest.net (mx.de.kpnqwest.net [193.141.40.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BI6mnC016524 for ; Tue, 11 Jun 2002 11:06:48 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 4031FC226; Tue, 11 Jun 2002 20:09:07 +0200 (MEST) (envelope-from simon.matter@ch.sauter-bc.com) Received: (from uucp@localhost) by lizard.webland.de (8.8.8/8.8.7) id UAA15579; Tue, 11 Jun 2002 20:09:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 695A357306; Tue, 11 Jun 2002 20:08:50 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 478A125835; Tue, 11 Jun 2002 20:08:49 +0200 (CEST) Message-ID: <3D063CB0.108524CF@ch.sauter-bc.com> Date: Tue, 11 Jun 2002 20:08:48 +0200 From: Simon Matter X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i586) X-Accept-Language: en MIME-Version: 1.0 To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com Subject: Re: New kernel RPMs 2.4.9-34SGI_XFS_1.1 References: <3D061BEF.7C10A356@ch.sauter-bc.com> <20020611172354.A14648@infradead.org> Content-Type: multipart/mixed; boundary="------------0621984B06E70199FC41FA31" X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dies ist eine mehrteilige Nachricht im MIME-Format. --------------0621984B06E70199FC41FA31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christoph Hellwig schrieb: > > On Tue, Jun 11, 2002 at 05:49:03PM +0200, Simon Matter wrote: > > I have built updated kernel-2.4.9-34SGI_XFS_1.1 RPMs for RH 7.1/7.2. So > > far the kernel works fine and I don't expect any problems because the > > patches from the kernel-2.4.9-31SGI_XFS_1.1 applied cleanly. > > Unfortunately I don't have the space to make the packages available. > > Eric, do you hear me... > > just uploading the specfile delta (2.4.9-34 -> 2.4.9-34SGI_XFS_1.1) would > help many people I guess. Okay, the diff is attached. You'll need sources from 2.4.9-34 and 2.4.9-31SGI_XFS_1.1 to build. Simon --------------0621984B06E70199FC41FA31 Content-Type: application/octet-stream; name="kernel-2.4.9-34-RH-xfs-1.1.diff.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="kernel-2.4.9-34-RH-xfs-1.1.diff.gz" H4sICEg7Bj0AA2tlcm5lbC0yLjQuOS0zNC1SSC14ZnMtMS4xLmRpZmYAjVhb b9u4En4++hUDBMGeU1uK5HuM3W6SNm2zTdog6Qb7FtASbbORSC0puU6L/Pcz Q1G2HNtt/GDL5Mw35Fw+DuX7PjxwLXnqd4JeYHIe/+dLyeGvUkIUQScch9E4 GuJD2PFarVZT+Njv9vybD/5yavwoiLaUo9G4H477TvnkBPxhOwqhhd8dODnx 4DDhUyE5TEqRJibLIXo2dvb585etQS4LrnMtDMcpf2Mq4ZNyhqOtHaPhM5iv XBout4YLlvOd63ATK2i+LDS71zzlDFdy+/7i/p93t/foh7UIy/P08f4hmZAV Dw7gjmsjlDSgprBgWqjSQM50Ydb2asBuz3osGvTaQ2hFgwH+kM88+MQyPnZx 8GrIMRz+eFhUz0+ef1Oh0KgDfDr88ad1RMoXPL2PxkEymT15rZdKHv7Y2PCT B5ciJheO4f31pQfvtSrzMdw+moJncC4XQiuZYayOPrqVni/jtDRiwU91PCd7 LE3vl6PBE5jucWi/lm40z+MnEGzgfDDstwfog6FNH3LCaVkozf/NtVqMQSoP rjXH/9YJ1tp9bgdwlW+UnKYiLkxjMq7HcP93XCZKjymAbbiQCxUzr3XN4gc2 4zh8rkUMt0wmHHPld1M9nJiZCGKVvW7DrciUhCtWYE7iPP0LMvvvRFiwIJ6/ 9lpvhSm0mJSFDRXaAkyW2h56UpZLuOUaA+i1/tbpGOZFkY+PjpQxgTN2hLv9 ynHRR1hvlAdnlJm48RvaeKYSBE8NvP4DqDajbhszq4jn1UA/6LVhwoz7G+Ks mftWow0zWeYzzEAxZRiZRjQq74+6NgNHx6uydYLrWLnF4EpKoTm6ehbHlaXj gT/sowpPDff8n0iN+lg3DthGvvUT4SikKrOYrYNfgD6bRk+iX3w+iw1ByERM aXmbv3bj/eMhpd0gHLV7A7vxa3JoFIa9cAwpxczRIDNG6YIn/kQUJrBuXwv3 nwkblsdcF2IqYkbpMMdcq3VwN3VywDuRcmOriUbx82XOkReYRk7S6gHTscxh 8gjTUsaEA1OloZjjLJdIJQVyjFNk8lEhswjiTY6AyRgn3JyvZPoI9nOaplZf 8m8wJePAkDoTsoHrCQA+KYjnTM5wplDIf5jTQs4q2aDGW2Lya4v3ZodsVYA1 vEwaxlAM7dEKHFTjYwqUZToh0sUQ4aLICtUTx4AmfGX931IVrNvBx7+YhI9M s98MdDsYF7hDn9ppVxc5khEYlSGTYwxkzImszLbtb3OB0nO2IM+i19lMc1wA Lhcdg1ZWtt3eXrJzUqa0xMVjOMm7NUgmTFzZvcInnqZM8uqUwDWjJgXZUgf6 6RGw/mCOe9tpJdjey5e5cFBgeGHg/J8vN6d35ze3F58//UHneJtiYGz+UXQ+ vj1DwZTbBKNlb0PiscXKtADiVDGrgorHQqlpm3NWWCyjSh1zSBQOSlVgKuJR kPBqnduYU60yUGVhBMpQSrptFej5ladYnPpJxnIBp5g2ZOX0zaU1//bq9PoC TJnnWJUoT3yOW8YuJMRapG7FdS8RdS8mT0Vhy6CqwmDyvdPQiPZp2ETfqdLZ p+Kyc6dSd59StfedOr19OpRFOzX6+zRW3typNvj54nzRHQ12Kg5/pYhMv1Nx 9LOtbdmjnPg7n2mG+XJ5d0X1FQVh0F0BRhT5dJH5dthv8rEFdwRsgS6IJzP+ /btaJ+wjLyoKwEXVmdUAjzYpvlovrV8qX6zgmkbeiSUYkaIWNwbrASZxBonG 7ki3sZxzZSrmJXtU85aoSvkg1TeJPSIzSjbsdzbtI5Y/+c71hsXPWEgaLL9I AhVLohOqtE9cpHCmEbkB2d2ElBMftZImIPW1/yXnUJsrquU6NvhfAwiTFCX9 RSeI9vndBhFWPc2NUgV1a/dFluP8/OnIZcvhj49IVjfnl0++Rhl7Sg+iTvsY T+lBtx1197Ynv+pM1q0HZhaIPn0N8Autp+Tpvf0DKe9BH/W3GotVw4EjedVj wpxj1mrs6G7LLGP6cQwf7Ig7KupTveoRHRlUjVkPO5MRdmY93HvP7d36s9Mb RuDnUaOhwXgRRWKbuGo8LPHmSNRVklVU7ACIKi0CimyfuRtyUS2HZyEetpbj mvOdev4NnXWOyV0f0ZTrVnKb0aPrQVNo4ISeBc32i2upYS214XRcAp2pu2z3 XmJ7tIl6AMiZbbCk2RTrV573fBIhMnJMVEtEa8++nGnWyit3E2HYIge8GExS npmm2MrrdcEnVcU3ZcjjYVXLdNDvr2X0C/mkvs0+NUF6G17BxI7nmGTQWgK5 8sjg9TZ+5Qr4CFuY+OGemSwwc9dlR8NeZN8K4D0jqu93t+iAqgrQB1lua9GD tzxHK9V1sirP9auATZ3GKwKr6mOLcO06KHu19fxtMDfRxKneHFQQNzxTC76J 0jrYAm4d7ENuHeyBbh3swt7cbkVE5Ixt7ziSqoudvNrpdkO6vHR6nbB2aoN7 qhJIFS7qFVwhrn1jE9oXNS+90vruelDfV+ybj3oQs6Rt05lLhrnZzCdMOHgF 77RAE4/QjSqjZ1x+ZRmeg5fsA6O4/T6JdXqieYI9pL1re+C70m0cTNHIz2e8 OkXo1C9KLfHiM4Xr9+eAu7D3ITwqcNMAcV7a/jDnGlk1AwZFOoEp3gOs7gwr T4uE3s3gfSPlkCPTBXQvMqoN3v8BmaDx2ioTAAA= --------------0621984B06E70199FC41FA31-- From owner-linux-xfs@oss.sgi.com Tue Jun 11 11:14:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BIEjnC016765 for ; Tue, 11 Jun 2002 11:14:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BIEjsS016764 for linux-xfs-outgoing; Tue, 11 Jun 2002 11:14:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BIEZnC016735 for ; Tue, 11 Jun 2002 11:14:35 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA20520; Tue, 11 Jun 2002 13:16:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA68514; Tue, 11 Jun 2002 13:16:53 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BIGgq01613; Tue, 11 Jun 2002 13:16:42 -0500 Subject: Re: mounting with sync? From: Steve Lord To: Joshua Baker-LePain Cc: Linux xfs mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 13:16:42 -0500 Message-Id: <1023819402.19330.32.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-11 at 13:03, Joshua Baker-LePain wrote: > In the course of trying to track down some disk performance issues, I'm > trying to mount an XFS partition on a (slow) SCSI disk synchronously via > the fstab entry: > > /dev/sda1 /mnt/test xfs logbufs=8,sync 0 0 > > However, I'm not getting the behavior I would expect: > > [root@brian root]# time dd if=/dev/zero of=/mnt/test/bigfile bs=1024k > count=512; time umount /mnt/test > 512+0 records in > 512+0 records out > > real 0m57.848s > user 0m0.000s > sys 0m3.280s > > real 1m6.472s > user 0m0.000s > sys 0m0.610s > > So the 'dd' returns after 1 minute, but it takes it another minute to > actually unmount the partition (during which there is lots of writing > going on). I tried adding 'osyncisdysnc', which ISTR is the default now, > and it (obviously) didn't help. > > Am I misinterpreting what's going on here? Is this the expected behavoir? > The kernel is 2.4.18 from the 1.1 release. > > Thanks. Try editing fs/xfs/linux/xfs_lrw.c Look for this code (line 623 in my version): /* Handle various SYNC-type writes */ if (file->f_flags & O_SYNC) { Change it to if ((file->f_flags & O_SYNC) || IS_SYNC(ip)) { See if that does it. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 11 12:53:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BJrJnC019949 for ; Tue, 11 Jun 2002 12:53:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BJrJPN019948 for linux-xfs-outgoing; Tue, 11 Jun 2002 12:53:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BJr9nC019920 for ; Tue, 11 Jun 2002 12:53:09 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id g5BJtWF04199; Tue, 11 Jun 2002 15:55:32 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 11 Jun 2002 15:55:32 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Steve Lord cc: Linux xfs mailing list Subject: Re: mounting with sync? In-Reply-To: <1023819402.19330.32.camel@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 11 Jun 2002 at 1:16pm, Steve Lord wrote > Try editing fs/xfs/linux/xfs_lrw.c > > Look for this code (line 623 in my version): > > /* Handle various SYNC-type writes */ > if (file->f_flags & O_SYNC) { > > Change it to > > if ((file->f_flags & O_SYNC) || IS_SYNC(ip)) { > > See if that does it. In my version (2.4.18 from 1.1 Release) it's on line 752, and looks like this: /* Handle various SYNC-type writes */ if (ioflags & O_SYNC) { I changed it to: if ((ioflags & O_SYNC) || IS_SYNC(ip)) { and got the expected behavior: [root@brian root]# time dd if=/dev/zero of=/mnt/test/bigfile bs=1024k count=512; time umount /mnt/test 512+0 records in 512+0 records out real 1m58.351s user 0m0.010s sys 0m3.940s real 0m0.413s user 0m0.000s sys 0m0.310s Thanks! -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Jun 11 13:08:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BK8TnC020484 for ; Tue, 11 Jun 2002 13:08:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BK8TYx020483 for linux-xfs-outgoing; Tue, 11 Jun 2002 13:08:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BK8NnC020452 for ; Tue, 11 Jun 2002 13:08:24 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA21388 for ; Tue, 11 Jun 2002 15:10:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA41495 for ; Tue, 11 Jun 2002 15:10:42 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BKAUs14891; Tue, 11 Jun 2002 15:10:30 -0500 Message-Id: <200206112010.g5BKAUs14891@jen.americas.sgi.com> Date: Tue, 11 Jun 2002 15:10:30 -0500 Subject: TAKE - enable -o sync for xfs To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This will make xfs obey the -o sync mount option for writes. If you want metadata to be synchronous too then add the wsync mount option. Steve Date: Tue Jun 11 13:09:29 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121268a linux/fs/xfs/linux/xfs_lrw.c - 1.146 - Turn on sync writes for a filesystem mounted -o sync From owner-linux-xfs@oss.sgi.com Tue Jun 11 13:13:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BKDAnC020664 for ; Tue, 11 Jun 2002 13:13:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BKDAnr020663 for linux-xfs-outgoing; Tue, 11 Jun 2002 13:13:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chaos.egr.duke.edu (chaos.egr.duke.edu [152.3.195.82]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BKD5nC020635 for ; Tue, 11 Jun 2002 13:13:05 -0700 Received: from localhost (jlb@localhost) by chaos.egr.duke.edu (8.11.6/8.11.6) with ESMTP id g5BKFTm04257; Tue, 11 Jun 2002 16:15:29 -0400 X-Authentication-Warning: chaos.egr.duke.edu: jlb owned process doing -bs Date: Tue, 11 Jun 2002 16:15:29 -0400 (EDT) From: Joshua Baker-LePain X-X-Sender: jlb@chaos.egr.duke.edu To: Steve Lord cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - enable -o sync for xfs In-Reply-To: <200206112010.g5BKAUs14891@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 11 Jun 2002 at 3:10pm, Steve Lord wrote > This will make xfs obey the -o sync mount option for writes. If you > want metadata to be synchronous too then add the wsync mount option. Is wsync documented anywhere? I don't see it in mount(8) or Documentation/filesystems/xfs.txt. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University From owner-linux-xfs@oss.sgi.com Tue Jun 11 13:16:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BKGtnC020854 for ; Tue, 11 Jun 2002 13:16:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BKGtwA020853 for linux-xfs-outgoing; Tue, 11 Jun 2002 13:16:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BKGnnC020823 for ; Tue, 11 Jun 2002 13:16:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA21780; Tue, 11 Jun 2002 15:19:09 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA55152; Tue, 11 Jun 2002 15:19:08 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5BKIue15008; Tue, 11 Jun 2002 15:18:56 -0500 Subject: Re: TAKE - enable -o sync for xfs From: Steve Lord To: Joshua Baker-LePain Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 11 Jun 2002 15:18:56 -0500 Message-Id: <1023826736.19306.74.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-11 at 15:15, Joshua Baker-LePain wrote: > On Tue, 11 Jun 2002 at 3:10pm, Steve Lord wrote > > > This will make xfs obey the -o sync mount option for writes. If you > > want metadata to be synchronous too then add the wsync mount option. > > Is wsync documented anywhere? I don't see it in mount(8) or > Documentation/filesystems/xfs.txt. Hmm, it really should be somewhere. Looks like the source code is it on Linux now. From the Irix man page: wsync All operations that modify the filesystem are synchronous except for writes to user files (e.g. create, unlink, mv, truncate, etc.). This option can be used in conjunction with exporting a filesystem -wsync to obtain NFS write-synchronous semantics, if so desired. See exports(4) for further information. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 11 14:02:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BL2inC021306 for ; Tue, 11 Jun 2002 14:02:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BL2hcF021305 for linux-xfs-outgoing; Tue, 11 Jun 2002 14:02:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BL2cnC021276 for ; Tue, 11 Jun 2002 14:02:38 -0700 Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) 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 OAA05451 for ; Tue, 11 Jun 2002 14:05:11 -0700 (PDT) mail_from (exchange@xgm.de) Received: from fwd09.sul.t-online.de by mailout04.sul.t-online.com with smtp id 17HsfK-00031C-0A; Tue, 11 Jun 2002 22:54:58 +0200 Received: from horus.xgm.de (340060635977-0001@[80.129.20.255]) by fmrl09.sul.t-online.com with esmtp id 17HsfA-18TkBcC; Tue, 11 Jun 2002 22:54:48 +0200 Received: from arbeitszimmer (unknown [192.168.0.5]) by horus.xgm.de (Postfix) with SMTP id D53A51A2 for ; Tue, 11 Jun 2002 22:52:25 +0200 (CEST) Message-ID: <001501c2118a$86037dd0$0500a8c0@arbeitszimmer> From: "Florian Lindner" To: Subject: XFS library could not be initialized Date: Tue, 11 Jun 2002 22:56:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 340060635977-0001@t-dialin.net X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I get this error message from some XFS utitlities. For example: xfs_check /dev/hda2 says: hda2 contains a mounted filesystem. fatal error: XFS library could not be initalized. Is this the normal behaviour when running xfs_check on a mounted filesystem? I've used Redhat 7.3 with the SGI installer. If this is abnormal, how to fix it? If it's normal, is there any possibility to check a mounted XFS filesystem for errors or is there anything like a bootdisk provided with the essential XFS utils to check my root partition. Thx, Florian From owner-linux-xfs@oss.sgi.com Tue Jun 11 14:05:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BL5qnC021513 for ; Tue, 11 Jun 2002 14:05:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BL5qSO021512 for linux-xfs-outgoing; Tue, 11 Jun 2002 14:05:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BL5mnC021484 for ; Tue, 11 Jun 2002 14:05:48 -0700 Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) 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 OAA08181 for ; Tue, 11 Jun 2002 14:08:22 -0700 (PDT) mail_from (exchange@xgm.de) Received: from fwd04.sul.t-online.de by mailout05.sul.t-online.com with smtp id 17HsiP-0007qj-03; Tue, 11 Jun 2002 22:58:09 +0200 Received: from horus.xgm.de (340060635977-0001@[80.129.20.255]) by fmrl04.sul.t-online.com with esmtp id 17HsiC-0mJ6hMC; Tue, 11 Jun 2002 22:57:56 +0200 Received: from arbeitszimmer (unknown [192.168.0.5]) by horus.xgm.de (Postfix) with SMTP id 7B006147 for ; Tue, 11 Jun 2002 22:55:33 +0200 (CEST) Message-ID: <004101c2118a$f5db1550$0500a8c0@arbeitszimmer> From: "Florian Lindner" To: Subject: XFS library could not be initalized Date: Tue, 11 Jun 2002 23:00:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Sender: 340060635977-0001@t-dialin.net X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I get this error message from some XFS utitlities. For example: xfs_check /dev/hda2 says: hda2 contains a mounted filesystem. fatal error: XFS library could not be initalized. Is this the normal behaviour when running xfs_check on a mounted filesystem? I've used Redhat 7.3 with the SGI installer. If this is abnormal, how to fix it? If it's normal, is there any possibility to check a mounted XFS filesystem for errors or is there anything like a bootdisk provided with the essential XFS utils to check my root partition. Thx, Florian From owner-linux-xfs@oss.sgi.com Tue Jun 11 14:07:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5BL7snC021691 for ; Tue, 11 Jun 2002 14:07:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5BL7sp3021690 for linux-xfs-outgoing; Tue, 11 Jun 2002 14:07:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5BL7mnC021660 for ; Tue, 11 Jun 2002 14:07:48 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA21266; Tue, 11 Jun 2002 16:10:08 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA22555; Tue, 11 Jun 2002 16:10:07 -0500 (CDT) Subject: Re: XFS library could not be initialized From: Eric Sandeen To: Florian Lindner Cc: linux-xfs@oss.sgi.com In-Reply-To: <001501c2118a$86037dd0$0500a8c0@arbeitszimmer> References: <001501c2118a$86037dd0$0500a8c0@arbeitszimmer> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 11 Jun 2002 16:07:19 -0500 Message-Id: <1023829639.3326.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-11 at 15:56, Florian Lindner wrote: > Hello, > I get this error message from some XFS utitlities. > For example: > > xfs_check /dev/hda2 says: > > hda2 contains a mounted filesystem. > fatal error: XFS library could not be initalized. >From the xfs_check man page: "The filesystem should normally be unmounted or read-only during the execution of xfs_check." There is currently no mechanism for checking a mounted, active filesystem. -Eric From owner-linux-xfs@oss.sgi.com Tue Jun 11 19:04:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C24WnC024818 for ; Tue, 11 Jun 2002 19:04:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C24WUW024817 for linux-xfs-outgoing; Tue, 11 Jun 2002 19:04:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C24PnC024789 for ; Tue, 11 Jun 2002 19:04:26 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id F241EC00FCA for ; Wed, 12 Jun 2002 10:06:50 +0800 (PHT) Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [192.168.0.1]) by gusi.leathercollection.ph (Postfix) with ESMTP id 1AA79C00FC9 for ; Wed, 12 Jun 2002 10:06:43 +0800 (PHT) Date: Wed, 12 Jun 2002 10:06:43 +0800 (PHT) From: Federico Sevilla III X-X-Sender: jijo@gusi.leathercollection.ph To: Linux XFS Mailing List Subject: Any tests done using GCC 3.1? (was: TAKE - pass const pointer info down into write path) In-Reply-To: <200206111554.g5BFsjC27005@jen.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi everyone, On Tue, 11 Jun 2002 at 10:54, Steve Lord wrote: > Another one from Christoph (along with the rest of this mornings > changes), this one speeds up write by letting the compiler optimize > more. On the topic of compilers, I wonder: have any tests been done on the XFS Linux kernels using GCC 3.1? I've personally had mixed results using GCC 3.0, so I'm wondering if it will be suicidal of me to try GCC 3.1 out when 2.4.19 finally gets out. TIA. :) --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Tue Jun 11 20:45:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C3jfnC026482 for ; Tue, 11 Jun 2002 20:45:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C3jf8E026481 for linux-xfs-outgoing; Tue, 11 Jun 2002 20:45:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ausmail.coremetrics.com ([64.245.50.27]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C3jWnC026451 for ; Tue, 11 Jun 2002 20:45:33 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jun 2002 22:47:54 -0500 Message-ID: <85063BBE668FD411944400D0B744267A888762@AUSMAIL> From: "Gonyou, Austin" To: "'Federico Sevilla III '" , "'Linux XFS Mailing List '" Subject: RE: Any tests done using GCC 3.1? (was: TAKE - pass const pointer info down into write path) Date: Tue, 11 Jun 2002 22:47:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=2.7 required=5.0 tests=SUBJ_HAS_SPACES version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Personally, I compile and USE on a daily basis, my own kernels from the -aa tree(they include XFS plus 0(1) scheduler fixes, VM changes, etc), and have been happy with kernels built from gcc3 since 3.0.4. As far as I can tell ATM, gcc 3.1 is just super solid. If there's a cornercase, I've not yet run into it, as it's my only compiler on my box. Austin -----Original Message----- From: Federico Sevilla III To: Linux XFS Mailing List Sent: 6/11/2002 9:06 PM Subject: Any tests done using GCC 3.1? (was: TAKE - pass const pointer info down into write path) Hi everyone, On Tue, 11 Jun 2002 at 10:54, Steve Lord wrote: > Another one from Christoph (along with the rest of this mornings > changes), this one speeds up write by letting the compiler optimize > more. On the topic of compilers, I wonder: have any tests been done on the XFS Linux kernels using GCC 3.1? I've personally had mixed results using GCC 3.0, so I'm wondering if it will be suicidal of me to try GCC 3.1 out when 2.4.19 finally gets out. TIA. :) --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Wed Jun 12 00:26:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C7QKnC028745 for ; Wed, 12 Jun 2002 00:26:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C7QK8k028744 for linux-xfs-outgoing; Wed, 12 Jun 2002 00:26:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C7QCnC028716 for ; Wed, 12 Jun 2002 00:26:13 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5C7Scen045250; Wed, 12 Jun 2002 09:28:38 +0200 (CEST) Message-Id: <4.3.2.7.2.20020612092806.03aedd80@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jun 2002 09:29:14 +0200 To: "Florian Lindner" , From: Seth Mos Subject: Re: XFS library could not be initalized In-Reply-To: <004101c2118a$f5db1550$0500a8c0@arbeitszimmer> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 23:00 11-6-2002 +0200, Florian Lindner wrote: >Hello, >I get this error message from some XFS utitlities. >For example: > >xfs_check /dev/hda2 says: > >hda2 contains a mounted filesystem. >fatal error: XFS library could not be initalized. This is normal. >Is this the normal behaviour when running xfs_check on a mounted filesystem? >I've used Redhat 7.3 with the SGI installer. If this is abnormal, how to fix >it? >If it's normal, is there any possibility to check a mounted XFS filesystem >for errors or is there anything like a bootdisk provided with the essential >XFS utils to check my root partition. There are links to several solutions in the FAQ. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jun 12 01:50:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5C8oInC030015 for ; Wed, 12 Jun 2002 01:50:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5C8oIJE030014 for linux-xfs-outgoing; Wed, 12 Jun 2002 01:50:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.siv.de (mail.siv.de [217.5.230.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5C8o0nC029977 for ; Wed, 12 Jun 2002 01:50:01 -0700 Received: from regnermobil (adelie-int [193.158.30.131]) by mail.siv.de (iPlanet Messaging Server 5.0 Patch 2 (built Dec 14 2000)) with ESMTP id <0GXL005KX4N7AQ@mail.siv.de> for linux-xfs@oss.sgi.com; Wed, 12 Jun 2002 10:52:19 +0200 (MEST) Date: Wed, 12 Jun 2002 10:52:16 +0200 From: Ronny Egner Subject: Problem with linux-2.4.18 and freeswan-1.95 To: linux-xfs@oss.sgi.com Message-id: <00c001c211ee$745ac6b0$4f0117ac@regnermobil> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/signed; boundary="----=_NextPart_000_00BC_01C211FF.37CC8C40"; micalg=SHA1; protocol="application/x-pkcs7-signature" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00BC_01C211FF.37CC8C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I am using kernel 2.4.18 with xfs and i am satisfied. Now i would like to set up a vpn between two gateway with freeswan-1.95 On compiling i get this error: ke[2]: Entering directory `/usr/src/linux-2.4.18/arch/i386/lib' make[2]: Nothing to be done for `modules'. make[2]: Leaving directory `/usr/src/linux-2.4.18/arch/i386/lib' make[1]: Leaving directory `/usr/src/linux-2.4.18' packaging/utils/errcheck out.kbuild ***ERRORS DETECTED in out.kbuild (examine file for details): gcc -D__KERNEL__ -I/usr/src/linux-2.4.18/include -Wall -Wstrict-prototypes - Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pip e -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I /usr/lib/gcc-lib/i386-linux/2.95.4/include -I. -funsigned-char -DKBUILD_BASE NAME=xfs_error -c -o xfs_eror.o xfs_eror.c My System is a Debian Woody 3.0, kernel 2.4.18, freeswan-1.95, xfs-1.1-2.4.18-all.patch.bz2. Are there any newer xfs-patches ?? Thanks in advance. Ronny ------=_NextPart_000_00BC_01C211FF.37CC8C40 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIIHKjCCAu0wggJWoAMCAQICDgaGAAAAAs0yUUet/qFpMA0GCSqGSIb3 DQEBBAUAMIG8MQswCQYDVQQGEwJERTEQMA4GA1UECBMHSGFtYnVyZzEQMA4G A1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMgVHJ1c3RDZW50ZXIgZm9yIFNl Y3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21iSDEiMCAGA1UECxMZVEMgVHJ1 c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqGSIb3DQEJARYaY2VydGlmaWNh dGVAdHJ1c3RjZW50ZXIuZGUwHhcNMDExMjE5MTIxNzM2WhcNMDIxMjE5MTIx NzM2WjBGMQswCQYDVQQGEwJERTEUMBIGA1UEAxMLUm9ubnkgRWduZXIxITAf BgkqhkiG9w0BCQEWElJvbm55LkVnbmVyQHNpdi5kZTBcMA0GCSqGSIb3DQEB AQUAA0sAMEgCQQDgRvw5NnQHOXm2ARcNxq1g4hXj5kWMCgWzPPLly1TW6bch 4Hp9xeJ0IsTf5BGKwQAPREMiiL07ci/mMZP6PXQLAgMBAAGjgaowgacwMwYJ YIZIAYb4QgEIBCYWJGh0dHA6Ly93d3cudHJ1c3RjZW50ZXIuZGUvZ3VpZGVs aW5lczARBglghkgBhvhCAQEEBAMCBaAwXQYJYIZIAYb4QgEDBFAWTmh0dHBz Oi8vd3d3LnRydXN0Y2VudGVyLmRlL2NnaS1iaW4vY2hlY2stcmV2LmNnaS8w Njg2MDAwMDAwMDJDRDMyNTE0N0FERkVBMTY5PzANBgkqhkiG9w0BAQQFAAOB gQBgXS6I3EHkFV3Wzg6huO/7IpcRf9WonsmQziaCB6VHgEriv69WNhLjb56o tXCzJIWaqmn28E1zGyd/0dGvg1Jv+MbHjQRUmz629zbPZN93wYkvk6RsiLUn FaCsPvkqtWz4+v/boTFm4Z/Xc5NodDUEqLwPqfIFtmIh4KVeMurAQzCCBDUw ggOeoAMCAQICAQIwDQYJKoZIhvcNAQEEBQAwgbwxCzAJBgNVBAYTAkRFMRAw DgYDVQQIEwdIYW1idXJnMRAwDgYDVQQHEwdIYW1idXJnMTowOAYDVQQKEzFU QyBUcnVzdENlbnRlciBmb3IgU2VjdXJpdHkgaW4gRGF0YSBOZXR3b3JrcyBH bWJIMSIwIAYDVQQLExlUQyBUcnVzdENlbnRlciBDbGFzcyAxIENBMSkwJwYJ KoZIhvcNAQkBFhpjZXJ0aWZpY2F0ZUB0cnVzdGNlbnRlci5kZTAeFw05ODAz MDkxMzU2MzNaFw0wNTEyMzExMzU2MzNaMIG8MQswCQYDVQQGEwJERTEQMA4G A1UECBMHSGFtYnVyZzEQMA4GA1UEBxMHSGFtYnVyZzE6MDgGA1UEChMxVEMg VHJ1c3RDZW50ZXIgZm9yIFNlY3VyaXR5IGluIERhdGEgTmV0d29ya3MgR21i SDEiMCAGA1UECxMZVEMgVHJ1c3RDZW50ZXIgQ2xhc3MgMSBDQTEpMCcGCSqG SIb3DQEJARYaY2VydGlmaWNhdGVAdHJ1c3RjZW50ZXIuZGUwgZ8wDQYJKoZI hvcNAQEBBQADgY0AMIGJAoGBALAp67R2s67Xtlu0Xue947GcSQRXW6Gr2X8T G/26YavY53HfLQCUXVFIfSPvdWKEkDwKH1kRdC+OgKX9MAI9KVLNchpJIZy8 y1KOSKFjlsgQhTBpV3RFwFqGxtU94GhXfTFqJI1Flz4xfmhmMm4kbewyNslB yvAxRMijYcoboDYfAgMBAAGjggFDMIIBPzBABglghkgBhvhCAQMEMxYxaHR0 cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9jaGVjay1yZXYuY2dp PzBABglghkgBhvhCAQQEMxYxaHR0cHM6Ly93d3cudHJ1c3RjZW50ZXIuZGUv Y2dpLWJpbi9jaGVjay1yZXYuY2dpPzA8BglghkgBhvhCAQcELxYtaHR0cHM6 Ly93d3cudHJ1c3RjZW50ZXIuZGUvY2dpLWJpbi9SZW5ldy5jZ2k/MD4GCWCG SAGG+EIBCAQxFi9odHRwOi8vd3d3LnRydXN0Y2VudGVyLmRlL2d1aWRlbGlu ZXMvaW5kZXguaHRtbDAoBglghkgBhvhCAQ0EGxYZVEMgVHJ1c3RDZW50ZXIg Q2xhc3MgMSBDQTARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEEBQAD gYEABUJSJqQMJwFErFwlKMJEQlQIuR3FPmxZZsSzTlCn+PiWdaGWdegWOKDN XW76eacbex0ewwC5Zr5a1mIP5/J7uO9M4MA/Wa45t4QJnqvxqS5raeKtzPLq eAkFIDhCcRh+x7KX5tUCBQZWo1/xqsLET/737xYPneyqhc89KSTxBM0xggHy MIIB7gIBATCBzzCBvDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1cmcx EDAOBgNVBAcTB0hhbWJ1cmcxOjA4BgNVBAoTMVRDIFRydXN0Q2VudGVyIGZv ciBTZWN1cml0eSBpbiBEYXRhIE5ldHdvcmtzIEdtYkgxIjAgBgNVBAsTGVRD IFRydXN0Q2VudGVyIENsYXNzIDEgQ0ExKTAnBgkqhkiG9w0BCQEWGmNlcnRp ZmljYXRlQHRydXN0Y2VudGVyLmRlAg4GhgAAAALNMlFHrf6haTAJBgUrDgMC GgUAoIG6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTAyMDYxMjA4NTIxNlowIwYJKoZIhvcNAQkEMRYEFDCCcl489InE13LN EG97i80B7D52MFsGCSqGSIb3DQEJDzFOMEwwCgYIKoZIhvcNAwcwDgYIKoZI hvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIdMA0GCSqGSIb3DQEBAQUABEBCmfWyIy4h4EcvyiYaFFIK OqkGFh6NPuvruvrqq2RDRUWDkZpbfySsUi7USUdTwpI4J7lQNiZqh0sD3rSy pssxAAAAAAAA ------=_NextPart_000_00BC_01C211FF.37CC8C40-- From owner-linux-xfs@oss.sgi.com Wed Jun 12 03:30:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CAUrnC004304 for ; Wed, 12 Jun 2002 03:30:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CAUriY004303 for linux-xfs-outgoing; Wed, 12 Jun 2002 03:30:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CAUhnC004273 for ; Wed, 12 Jun 2002 03:30:43 -0700 Received: from erbenson.alaska.net (70-pm18.nwc.alaska.net [209.112.142.70]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g5CAX9d99253 for ; Wed, 12 Jun 2002 02:33:09 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 7D0BA3939 for ; Wed, 12 Jun 2002 02:33:08 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id F3DE610294; Wed, 12 Jun 2002 02:33:07 -0800 (AKDT) Date: Wed, 12 Jun 2002 02:33:07 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: XFS library could not be initialized Message-ID: <20020612023307.H9152@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <001501c2118a$86037dd0$0500a8c0@arbeitszimmer> <1023829639.3326.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G44BJl3Aq1QbV/QL" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1023829639.3326.11.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Tue, Jun 11, 2002 at 04:07:19PM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --G44BJl3Aq1QbV/QL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 11, 2002 at 04:07:19PM -0500, Eric Sandeen wrote: > On Tue, 2002-06-11 at 15:56, Florian Lindner wrote: > > Hello, > > I get this error message from some XFS utitlities. > > For example: > >=20 > > xfs_check /dev/hda2 says: > >=20 > > hda2 contains a mounted filesystem. > > fatal error: XFS library could not be initalized. >=20 >=20 > >From the xfs_check man page: >=20 > "The filesystem should normally be unmounted or > read-only during the execution of xfs_check." >=20 > There is currently no mechanism for checking a mounted, active > filesystem. sure there is, try xfs_check -f /dev/whatever but running it on a read-write mounted filesystem almost always results in erroneous error reports anyway. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --G44BJl3Aq1QbV/QL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0HI2MACgkQJKx7GixEevyHQACffnnjOfsdUXLuEmpvFDXZLrzu 9fAAoIjbPPV8QyHfam3VBAeANPt2rigd =ajhL -----END PGP SIGNATURE----- --G44BJl3Aq1QbV/QL-- From owner-linux-xfs@oss.sgi.com Wed Jun 12 08:02:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CF2LnC017711 for ; Wed, 12 Jun 2002 08:02:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CF2LCQ017710 for linux-xfs-outgoing; Wed, 12 Jun 2002 08:02:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CF2CnC017679 for ; Wed, 12 Jun 2002 08:02:14 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.35 #1) id 17I9fl-0007sR-00; Wed, 12 Jun 2002 17:04:33 +0200 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Date: Wed, 12 Jun 2002 17:04:33 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2502) For Windows 2000 (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [OT] Compiling today's Samba for Debian fails with rejected patch Message-Id: X-Spam-Status: No, hits=-1.2 required=5.0 tests=GAPPY_TEXT version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk # debian/rules binary [...] patching file `source/include/proto.h' Hunk #6 FAILED at 1079. Hunk #7 succeeded at 1522 (offset 1 line). Hunk #9 succeeded at 2441 (offset 4 lines). Hunk #11 succeeded at 2537 (offset 4 lines). Hunk #13 succeeded at 4759 (offset 17 lines). 1 out of 14 hunks FAILED -- saving rejects to source/include/proto.h.rej Is the Debian stuff possibly not up-to-date? I'd do the patch manually, but it seems far too much work, and I'm not sure whether I understand what the patch is trying to change. Thanks for any insights, Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Wed Jun 12 08:23:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CFNinC019391 for ; Wed, 12 Jun 2002 08:23:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CFNirG019390 for linux-xfs-outgoing; Wed, 12 Jun 2002 08:23:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CFNdnC019362 for ; Wed, 12 Jun 2002 08:23:39 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA26673 for ; Wed, 12 Jun 2002 10:26:02 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA71148 for ; Wed, 12 Jun 2002 10:26:02 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA23015 for linux-xfs@oss.sgi.com; Wed, 12 Jun 2002 10:26:01 -0500 (CDT) Date: Wed, 12 Jun 2002 10:26:01 -0500 (CDT) From: Dean Roehrich Message-Id: <200206121526.KAA23015@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make dmapi kernel<>library interface 64bit safe X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jun 12 08:25:50 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121353a linux/include/linux/dmapi_kern.h - 1.11 linux/fs/xfs_dmapi/dmapi_private.h - 1.9 linux/fs/xfs_dmapi/dmapi_sysent.c - 1.6 - No Message Supplied From owner-linux-xfs@oss.sgi.com Wed Jun 12 08:25:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CFPYnC019569 for ; Wed, 12 Jun 2002 08:25:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CFPYuC019568 for linux-xfs-outgoing; Wed, 12 Jun 2002 08:25:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CFPSnC019539 for ; Wed, 12 Jun 2002 08:25:28 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA25960 for ; Wed, 12 Jun 2002 10:27:51 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA93750 for ; Wed, 12 Jun 2002 10:27:51 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA42915 for linux-xfs@oss.sgi.com; Wed, 12 Jun 2002 10:27:51 -0500 (CDT) Date: Wed, 12 Jun 2002 10:27:51 -0500 (CDT) From: Dean Roehrich Message-Id: <200206121527.KAA42915@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make dmapi kernel<>library interface 64bit safe X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jun 12 08:27:38 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:121354a cmd/dmapi/VERSION - 1.12 - No Message Supplied cmd/dmapi/build/rpm/dmapi.spec.in - 1.10 - No Message Supplied cmd/dmapi/include/dmapi_kern.h - 1.7 - No Message Supplied cmd/dmapi/debian/control - 1.7 - No Message Supplied cmd/dmapi/debian/changelog - 1.12 - No Message Supplied cmd/dmapi/libdm/dmapi_lib.c - 1.11 - No Message Supplied cmd/dmapi/libdm/Makefile - 1.11 - No Message Supplied From owner-linux-xfs@oss.sgi.com Wed Jun 12 09:26:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CGQknC022193 for ; Wed, 12 Jun 2002 09:26:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CGQkHg022192 for linux-xfs-outgoing; Wed, 12 Jun 2002 09:26:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CGQXnC022162 for ; Wed, 12 Jun 2002 09:26:33 -0700 Received: from mail.btomfg.com (mail.btomfg.com [209.235.17.60]) 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 IAA04119 for ; Wed, 12 Jun 2002 08:11:42 -0700 (PDT) mail_from (joey@btomfg.com) Received: from btowrksta1 [63.243.48.108] by mail.btomfg.com with ESMTP (SMTPD32-7.10) id A47E101E00C4; Wed, 12 Jun 2002 11:10:54 -0400 From: "Joey Sims" To: Subject: Bug in XFS 1.1 Linux Installer Date: Wed, 12 Jun 2002 11:05:16 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0046_01C21201.08982090" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-MS-TNEF-Correlator: X-Spam-Status: No, hits=1.3 required=5.0 tests=SMTPD_IN_RCVD version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0046_01C21201.08982090 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I am experiencing system lock-ups at the very end of the SGI XFS 7.3 install when writing the system configuration settings. Others are reporting system crashes when trying to partition the drive. FDISK and Disk Druid both crash. thanks, Joey P. Sims Sales Manager Build to Order Mfg. 888-888-5525 - Phone 678-339-9840 - Fax joey@btomfg.com www.btoonline.com ------=_NextPart_000_0046_01C21201.08982090 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IhAPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcA GAAAAElQTS5NaWNyb3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEG gAMADgAAANIHBgAMAAsABAAAAAMA/QABA5AGANgFAAAiAAAACwACAAEAAAAL ACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAABAAAAHwAAAEJ1 ZyBpbiBYRlMgMS4xIExpbnV4IEluc3RhbGxlcgAAAgFxAAEAAAAWAAAAAcIS InimDn7N4PNJTO2wpvUtj774IQAAAgEdDAEAAAAVAAAAU01UUDpKT0VZQEJU T01GRy5DT00AAAAACwABDgAAAABAAAYOADDfYSISwgECAQoOAQAAABgAAAAA AAAAz7c3jBZrjE6eA4o/so/8U8KAAAALAB8OAQAAAAIBCRABAAAA5wEAAOMB AACPAgAATFpGdYmN+hMDAAoAcmNwZzEyNRYyAPgLYG4OEDAzM08B9wKkA+MC AGNoCsBz8GV0MCAHEwKDAFAD1c0RdX0KgAjIIDsJbw4wvjUT8xURCbsCgAqB dgiQpHdrC4BkNAxgYwBQAwsDC7UgSSBhbSBYZXhwBnEJ8GMLgGfAIHN5c3Rl GMAJAKBjay11cAQgYQVAoHRoZSB2BJB5GNCRF0Agb2Ya01NHGJCEWEYF8Dcu MyALgLcZ0AdAAyB3GvADoHcFEB50GXIa4hm1BaBuZmn2ZwhwGrBpAiAZoBEw HeLccy4K4wqECoBPGuEREOsYoAlwIAlwcAkRGXkFANxhcxrwBCAdY3QbQB3z vG8gCrEd4B9zGuJkBRADGyAgQCBGRElTSysYoBuBRAQAayZAcnXeaRuQBuAa 4CLULiBqGuCxAHBrcywgagr0YxICoDEgSm9lG1BQIEBeUwdwELAgcwYQbAeR TVkAcGFnBJAgZEImwGw7G5AkIU8LIASQBdBmZ3UnpTguUC0uUhUgDjAgKi0q sGgCIGUgZDY3gy5wD2A5LTk4NBFQUS8gRmF4IGRqKoFA2mIkIG0twQWgbSBl KgC2Mh1QMxAuMcECIGwLgH8lcDIyKgABQClZNEYTEQABNeAACwABgAggBgAA AAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADAAOACCAGAAAAAADAAAAAAAAARgAA AAAQhQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAA/cQEAHgAJ gAggBgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOS4wAAsADYAIIAYA AAAAAMAAAAAAAABGAAAAAIKFAAABAAAACwAggAggBgAAAAAAwAAAAAAAAEYA AAAABoUAAAAAAAADACGACCAGAAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsA KoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwArgAggBgAAAAAAwAAA AAAAAEYAAAAAEYUAAAAAAAADAC2ACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAIB+A8BAAAAEAAAAM+3N4wWa4xOngOKP7KP/FMCAfoPAQAAABAAAADP tzeMFmuMTp4Dij+yj/xTAgH7DwEAAACWAAAAAAAAADihuxAF5RAaobsIACsq VsIAAFBTVFBSWC5ETEwAAAAAAAAAAE5JVEH5v7gBAKoAN9luAAAAQzpcRG9j dW1lbnRzIGFuZCBTZXR0aW5nc1xqb2V5XExvY2FsIFNldHRpbmdzXEFwcGxp Y2F0aW9uIERhdGFcTWljcm9zb2Z0XE91dGxvb2tcb3V0bG9vay5wc3QAAAAD AP4PBQAAAAMADTT9NwAAAgF/AAEAAAAvAAAAPElNRU9KT0FERUZJSUlGQURP S0RJTUVNSENKQUEuam9leUBidG9tZmcuY29tPgAAAwAGEPF/4JYDAAcQJgEA AAMAEBAAAAAAAwAREAAAAAAeAAgQAQAAAGUAAABJQU1FWFBFUklFTkNJTkdT WVNURU1MT0NLLVVQU0FUVEhFVkVSWUVORE9GVEhFU0dJWEZTNzNJTlNUQUxM V0hFTldSSVRJTkdUSEVTWVNURU1DT05GSUdVUkFUSU9OU0VUVElOAAAAANNR ------=_NextPart_000_0046_01C21201.08982090-- From owner-linux-xfs@oss.sgi.com Wed Jun 12 09:35:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CGZrnC022423 for ; Wed, 12 Jun 2002 09:35:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CGZrmR022422 for linux-xfs-outgoing; Wed, 12 Jun 2002 09:35:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CGZhnC022389 for ; Wed, 12 Jun 2002 09:35:44 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5CGcBRY137296; Wed, 12 Jun 2002 12:38:11 -0400 Received: from d03nm800.boulder.ibm.com (d03nm800.boulder.ibm.com [9.17.194.116]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5CGc9O172172; Wed, 12 Jun 2002 10:38:09 -0600 Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region To: Dean Roehrich Cc: "Francis Qu" , linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Wed, 12 Jun 2002 11:38:07 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 06/12/2002 10:38:09 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean, This turned out to be a bug in our software. Who knew that was possible? ; -) Your patch works great. Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: "Francis Qu" , linux-xfs@oss.sgi.com Subject: Re: DMAPI bug in dm_file_getattr() / dm_set_region 06/07/2002 03:26 PM >From: "James A Goodwin" > >Dean, > >Your scenario is correct, and yes, there is a lot more going on than just >those calls. I'll see if I can get you a more detailed calling sequence. > >In the mean time, I'm running with your patch on an otherwise unmodified >XFS 1.1 system. Perhaps I am missing some more recent modifications? I >could grab something more recent from CVS if you think that would help. nothing comes to mind, but you might try it anyway. I haven't checked in that fix yet, so make sure you reapply the patch when necessary. Dean From owner-linux-xfs@oss.sgi.com Wed Jun 12 10:36:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CHaknC026813 for ; Wed, 12 Jun 2002 10:36:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CHakxf026812 for linux-xfs-outgoing; Wed, 12 Jun 2002 10:36:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bender.jdwhite.org (jdwhite.org [209.234.79.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CHadnC026781 for ; Wed, 12 Jun 2002 10:36:39 -0700 Received: from jdwhite by bender.jdwhite.org with local (Exim 3.35 #1) id 17IC5B-000230-00; Wed, 12 Jun 2002 12:38:57 -0500 Date: Wed, 12 Jun 2002 12:38:57 -0500 From: Jason White To: Ronny Egner Cc: linux-xfs@oss.sgi.com Subject: Re: Problem with linux-2.4.18 and freeswan-1.95 Message-ID: <20020612173857.GJ8089@jdwhite.org> Mail-Followup-To: Ronny Egner , linux-xfs@oss.sgi.com References: <00c001c211ee$745ac6b0$4f0117ac@regnermobil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00c001c211ee$745ac6b0$4f0117ac@regnermobil> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 12, 2002 at 10:52AM +0200, Ronny Egner wrote: >I am using kernel 2.4.18 with xfs and i am satisfied. >Now i would like to set up a vpn between two gateway with freeswan-1.95 > >On compiling i get this error: > >packaging/utils/errcheck out.kbuild > >***ERRORS DETECTED in out.kbuild (examine file for details): >gcc -D__KERNEL__ -I/usr/src/linux-2.4.18/include -Wall -Wstrict-prototypes - >Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pip >e -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I >/usr/lib/gcc-lib/i386-linux/2.95.4/include -I. -funsigned-char -DKBUILD_BASE >NAME=xfs_error -c -o xfs_eror.o xfs_eror.c This is a false-positive. The utils/errcheck program in the freeswan build directory essentially scans the out.kbuild file for the string 'error' (and other strings), then attempts to grep out other false positives. The script simply isn't xfs aware. I got this same exact message yesterday with freeswan-1.97, but the kernel build was successful. -Jason -- Jason White jdwhite@jdwhite.org http://www.jdwhite.org/~jdwhite From owner-linux-xfs@oss.sgi.com Wed Jun 12 10:45:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CHjanC027138 for ; Wed, 12 Jun 2002 10:45:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CHjaUM027137 for linux-xfs-outgoing; Wed, 12 Jun 2002 10:45:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CHjRnC027109 for ; Wed, 12 Jun 2002 10:45:27 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5CHlsIQ026071; Wed, 12 Jun 2002 19:47:54 +0200 (CEST) Message-Id: <4.3.2.7.2.20020612194735.03a55e40@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jun 2002 19:48:28 +0200 To: Ronny Egner , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Problem with linux-2.4.18 and freeswan-1.95 In-Reply-To: <00c001c211ee$745ac6b0$4f0117ac@regnermobil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:52 12-6-2002 +0200, Ronny Egner wrote: >Hi, > >I am using kernel 2.4.18 with xfs and i am satisfied. >Now i would like to set up a vpn between two gateway with freeswan-1.95 > >On compiling i get this error: > >ke[2]: Entering directory `/usr/src/linux-2.4.18/arch/i386/lib' >make[2]: Nothing to be done for `modules'. >make[2]: Leaving directory `/usr/src/linux-2.4.18/arch/i386/lib' >make[1]: Leaving directory `/usr/src/linux-2.4.18' >packaging/utils/errcheck out.kbuild > >***ERRORS DETECTED in out.kbuild (examine file for details): >gcc -D__KERNEL__ -I/usr/src/linux-2.4.18/include -Wall -Wstrict-prototypes - >Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pip >e -mpreferred-stack-boundary=2 -march=i686 -nostdinc -I >/usr/lib/gcc-lib/i386-linux/2.95.4/include -I. -funsigned-char -DKBUILD_BASE >NAME=xfs_error -c -o xfs_eror.o xfs_eror.c That's not an error! The script is probably just parsing it for the string error :-) For which XFS has a separate .c file Cheers >My System is a Debian Woody 3.0, kernel 2.4.18, freeswan-1.95, >xfs-1.1-2.4.18-all.patch.bz2. > > > >Are there any newer xfs-patches ?? > > > >Thanks in advance. > >Ronny -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jun 12 10:48:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CHm1nC027318 for ; Wed, 12 Jun 2002 10:48:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CHm1vH027317 for linux-xfs-outgoing; Wed, 12 Jun 2002 10:48:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CHltnC027289 for ; Wed, 12 Jun 2002 10:47:55 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5CHoLrF027495; Wed, 12 Jun 2002 19:50:21 +0200 (CEST) Message-Id: <4.3.2.7.2.20020612194900.04252000@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 12 Jun 2002 19:50:55 +0200 To: "Joey Sims" , From: Seth Mos Subject: Re: Bug in XFS 1.1 Linux Installer In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 11:05 12-6-2002 -0400, Joey Sims wrote: >I am experiencing system lock-ups at the very end of the SGI XFS 7.3 install >when writing the system configuration settings. > >Others are reporting system crashes when trying to partition the drive. >FDISK and Disk Druid both crash. Can you check the md5sum of your image? If it is different you can rebuild it using the rsync access to oss.sgi.com without needing to download the complete iso again. rsync rsync://oss.sgi.com/xfsftp/Release-1.1/ or something like that. I use a ftp browser to build the correct URL. There are more links in the list archives. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jun 12 10:56:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CHurnC027617 for ; Wed, 12 Jun 2002 10:56:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CHurVc027616 for linux-xfs-outgoing; Wed, 12 Jun 2002 10:56:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CHuinC027588 for ; Wed, 12 Jun 2002 10:56:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA27710; Wed, 12 Jun 2002 12:59:04 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA01376; Wed, 12 Jun 2002 12:59:04 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id MAA77746; Wed, 12 Jun 2002 12:59:03 -0500 (CDT) Message-Id: <200206121759.MAA77746@slobber.americas.sgi.com> cc: "James A Goodwin" , linux-xfs@oss.sgi.com Subject: Re: DMAPI 2GB limit Date: Wed, 12 Jun 2002 12:59:03 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is fixed now. The change involved mods to the following files: linux/fs/xfs/xfs_dmapi.c linux/include/linux/dmapi_kern.h linux/fs/xfs_dmapi/dmapi_private.h linux/fs/xfs_dmapi/dmapi_sysent.c And a matching change to the dmapi library. I'm not going to bother sending all of this out as a single patch--I'd rather that you just grab the latest stuff. I changed invis I/O to be able to open files with O_LARGEFILE, then I changed the kernel<>library interface to be able to send 64bit types, and things got a bit involved. Because this is an incompatible change in the kernel<>library interface, I've changed the name of the dmapi device from /proc/fs/xfs_dmapi to /proc/fs/xfs_dmapi_v1. That should prevent an accidental mixing of library and kernel versions that might lead to core dumps or panics. So, when you update your kernel, you have to update the libdm library, too. If you're just using the shared lib, then your application does not have to be rebuilt. Dean >From: Dean Roehrich > >>From: "James A Goodwin" >>We were noticing some EINVAL errors coming from dm_read_invis() on our XFS >>1.1 system. It looks like the sys_dmapi_args_t structure that is used to >>pass data from the DMAPI library to the kernel is using long ints to store >>the offset and length of the read. It turns out that we were trying to >>read some data just past a 2GB offset, and that value in a signed long int >>is interpreted as a fairly large negative number, which explains the EINVAL >>return code. >> >>Is this something that can be changed by recompiling with certain flags set >>(the kernel and the dmapi library), or am I simply hosed? > >I think it needs more than a recompile. Probably have to change the 'long' to >'unsigned long long'. The library already uses large enough types, maybe >it'll work. > >The bug list grows... > >Dean From owner-linux-xfs@oss.sgi.com Wed Jun 12 11:15:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CIFgnC028039 for ; Wed, 12 Jun 2002 11:15:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CIFgMB028038 for linux-xfs-outgoing; Wed, 12 Jun 2002 11:15:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailer (r-rm175-4-15.tin.it [62.211.44.15]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CIFOnC028006 for ; Wed, 12 Jun 2002 11:15:25 -0700 Message-Id: <200206121815.g5CIFOnC028006@oss.sgi.com> X-Sender: mailing@amgi.it From: AMGI To: linux-xfs@oss.sgi.com Date: Tue, 11 Jun 2002 19:41:56 +0200 Subject: A.M.G.I. - www.amgi.it MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quotedGMprintable X-Spam-Status: No, hits=0.5 required=5.0 tests=LINES_OF_YELLING version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A.M.G.I. - www.amgi.it ---------------------------------------------------------------------------= - Piazzaffari =E8 il giornale di annunci economici pi=F9 diffuso della Sardeg= na=20 CERCHI UNA CASA? VENDI UN'AUTO? ......... Piazzaffari lo trovi in edicola ogni venerd=EC. Inviare la tua inserzione n= on costa=20 niente.=20 http://www.piazzaffarinet.it ---------------------------------------------------------------------------= --------------- --- Lancio del concorso Eurowards 2002 --- =C8 stata lanciata l'edizione 2002 del concorso Eurowards=20 (Premi europei per lo spirito imprenditoriale) rivolto=20 agli imprenditori. La competizione, organizzata dal gruppo "Spirito d'impresa", si svolger=E0 in oltre 25 paesi europei. Essa si rivolge alle aziende di tutti i settori e riguarda=20 quattro categorie: incoraggiamento, avviamento, start-up ed=20 espansione. Il presidente del gruppo "Spirito d'impresa",=20 ha dichiarato: "Non si tratta solamente della migliore opportunit=E0=20 di mettere alla prova il vostro piano d'impresa di fronte alla=20 concorrenza proveniente da tutta Europa, ma anche della maniera=20 pi=F9 semplice di ottenere capitali di rischio, dal momento che il=20 concorso =E8 correlato con i fondi di capitale di rischio che=20 investono nelle imprese che hanno ambizioni europee".=20 Termine ultimo per la presentazione delle candidature: 31.08.2002.=20 =09 Per informazioni tel 079/216656 ---------------------------------------------------------------------------= --------------- --- INCENTIVI EMERSIONE LAVORO NERO --- Il datore di lavoro deve, entro il 30 settembre 2002, presentare un piano di emersione al sindaco del Comune ove =E8 svolta l=92attivit=E0 oggetto d= i=20 emersione;=20 Beneficiari Tutti i soggetti situati sul territorio nazionale che producono reddito=20 d=92impresa o di lavoro autonomo che hanno utilizzato lavoro irregolare, an= che parzialmente. Sono compresi anche i soggetti che non hanno mai dichiarato=20 un reddito (evasori totali). Agevolazioni Oltre alle agevolazioni gi=E0 previste (imposta e contribuzione sostitutiva= per=20 il=20 triennio agevolato 2001-2003), la nuova formulazione permette un=92emersion= e=20 progressiva (massimo 18 mesi) mantenendo l=92anonimato e permettendo di usu= fruire=20 della sanatoria di violazioni diverse da quelle fiscali e contributive, di= poter=20 adeguare progressivamente le retribuzioni dei lavoratori e di eliminare il= rischio=20 di rivendicazioni retributive del lavoratore per i periodi pregressi Condizioni =C8 necessario che non siano iniziati accessi, ispezioni o accertamenti di = natura=20 fiscale o previdenziale (non sono tali le richieste effettuate per controlli formali) Controllate istantaneamente la fattibilit=E0 della vostra pratica di mutuo = sul=20 sito www.amgi.it ---------------------------------------------------------------------------= --------------- Puoi cancellarti in ogni momento da una della nostra Newsletter visitando l= a pagina "Newsletter remove" al seguente indirizzo: http://www.amgi.it/canc.htm oppure inviate un messaggio a mailto:mailing@amgi.it richiedendo la cancell= azione=20 manuale dal servizio nell'oggetto della mail. Tutte le richieste di cancellazione inviate diversamente dai suddetti metod= i=20 saranno cestinate! ---------------------------------------------------------------------------= ------------------- PUBBLICITA'MAIL & FAX La nostra azienda mette a disposizione delle aziende che lo richiederanno u= no=20 spazio per=20 pubblicizzare i loro prodotti o servizi. Potr=E0 essere richiesto il serviz= io nazionale=20 o regionale. L'offerta =E8 valida anche per le circolari via e-mail dell'AMGI. Per informazioni sui costi tel 079/216656 ---------------------------------------------------------------------------= ---------------- Per ulteriori informazioni o per istruire la pratica sulle iniziative citat= e=20 in questa e-mail,=20 inviate una mail all'indirizzo info@amgi.it oppure chiamando lo 079/216656 = /05 AMGI 31/05/2002 From owner-linux-xfs@oss.sgi.com Wed Jun 12 12:25:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CJPMnC028811 for ; Wed, 12 Jun 2002 12:25:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CJPMMs028810 for linux-xfs-outgoing; Wed, 12 Jun 2002 12:25:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from helixcode.nameip.net (s210-221-75-38.thrunet.ne.kr [210.221.75.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CJPHnC028782 for ; Wed, 12 Jun 2002 12:25:17 -0700 Received: (qmail 3097 invoked by uid 500); 12 Jun 2002 19:27:39 -0000 Subject: kernel-2.4.9-34SGI_XFS_1.1.src.rpm From: Seung-young Oh To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 Jun 2002 04:27:38 +0900 Message-Id: <1023910058.1579.9.camel@helixcode.nameip.net> Mime-Version: 1.0 X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Eric Sandeen Following your suggestion, I came up with kernel-2.4.9-34SGI_XFS_1.1.src.rpm for RedHat 7.1 & 7.2; ftp://helixcode.nameip.net/xfs/kernel-2.4.9-34SGI_XFS_1.1.src.rpm I just applied the exact diff on several config files and the spec file. $ uname -r 2.4.9-34SGI_XFS_1.1custom From owner-linux-xfs@oss.sgi.com Wed Jun 12 12:45:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5CJjqnC029030 for ; Wed, 12 Jun 2002 12:45:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5CJjqZj029029 for linux-xfs-outgoing; Wed, 12 Jun 2002 12:45:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from helixcode.nameip.net (s210-221-75-38.thrunet.ne.kr [210.221.75.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5CJjhnC029001 for ; Wed, 12 Jun 2002 12:45:44 -0700 Received: (qmail 3347 invoked by uid 500); 12 Jun 2002 19:48:05 -0000 Subject: Re: kernel-2.4.9-34SGI_XFS_1.1.src.rpm From: Seung-young Oh To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1023910184.24379.2.camel@stout.americas.sgi.com> References: <1023910058.1579.9.camel@helixcode.nameip.net> <1023910184.24379.2.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=EUC-KR X-Mailer: Ximian Evolution 1.0.5 Date: 13 Jun 2002 04:48:05 +0900 Message-Id: <1023911285.1579.23.camel@helixcode.nameip.net> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5CJjinC029002 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 2002-06-13 ¸ń 04:29, Eric Sandeen°ˇ ŔŰĽş: > Thank you! So you just used the same xfs patch from 2.4.9-(last)? > > A couple other people have also done this; I'll look at them sometime > soon and put one out on oss for download. > > Thanks again, > > -Eic > Yes I used the same xfs patches, and the files I applied the exact diffs are; kernel-2.4.9-athlon-smp.config kernel-2.4.9-athlon.config kernel-2.4.9-i386-BOOT.config kernel-2.4.9-i386-smp.config kernel-2.4.9-i386.config kernel-2.4.9-i586-smp.config kernel-2.4.9-i586.config kernel-2.4.9-i686-debug.config kernel-2.4.9-i686-enterprise.config kernel-2.4.9-i686-smp.config kernel-2.4.9-i686.config kernel-2.4.9-ia64-BOOT.config kernel-2.4.9-ia64-smp.config kernel-2.4.9-ia64.config and the spec file. (As you can see only config files and a spec file.) Then added newer patches came with kernel-2.4.9-34 from RedHat, and got 'kernel-2.4.9-34SGI_XFS_1.1.src.rpm' From owner-linux-xfs@oss.sgi.com Wed Jun 12 19:58:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D2w8nC020495 for ; Wed, 12 Jun 2002 19:58:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D2w8Q9020493 for linux-xfs-outgoing; Wed, 12 Jun 2002 19:58:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from c-mutex.com (sv.c-mutex.com [210.161.168.175]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D2vxnC020434 for ; Wed, 12 Jun 2002 19:58:00 -0700 Received: (qmail 12223 invoked by uid 0); 13 Jun 2002 03:00:42 -0000 Date: 13 Jun 2002 03:00:42 -0000 Message-ID: <20020613030042.12222.qmail@sv.c-mutex.com> Subject: =?ISO-2022-JP?B?GyRCISo5LTlwISolUSU9JTMlcyROJUchPCU/GyhC?= =?ISO-2022-JP?B?GyRCJHIwdTp+JDckXiQ5IiMwdTp+JE4lRxsoQg==?= =?ISO-2022-JP?B?GyRCJSMlOSUrJSYlcyVIIiMbKEI=?= From: justmail@u01.gate01.com To: linux-xfs@oss.sgi.com Reply-To: justmail@u01.gate01.com Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=3.9 required=5.0 tests=SUBJ_HAS_Q_MARK,NO_REAL_NAME,PLING,CHARSET_FARAWAY_HEADERS version=2.20 X-Spam-Level: *** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --------$B#P#R(B-----------------------------------$B#J#U#S#T#M#A#I#L(B--- $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B"#%Q%=%3%s$N%G!<%?$r"#3J0B$G0u:~$7$^$9"#!c#D#e#g#i(B-$B#P#r#e#s#s!d"#(B $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B $B"#EvE9$NFCD'"#(B $B(.$*5RMM$,%Q%=%3%s$G:n@.$7$?%G!<%?$r0u:~$7$^$9!#(B($B#W#i#n(B & $B#M#a#c(B) $B(-(B $B(2%*%U%;%C%H0u:~$J$N$G9bIJMh$N0u:~$NH>3[0J2<$G$9!*(B($B#A#4%3!<%H;f!"%+%i!<0u:~(B1,000$BKg$G(B16,000$B1_(B) $B(-(B $B(10u:~J*$OA49q$XH/Aw$7$^$9!#(B $B"#&IJ"#!!L>;I!"%]%9%H%+!<%I!"%A%i%7!"%]%9%?!\$7$$%7%9%F%`$O$3$A$i$+$i"-(B http://www.degi-press.co.jp/ $B(,(,(,(,(,(,(,(,(,(,(,(,(,(,(,(B --------$B#P#R(B--------------------------------------$B#J#U#S#T#M#A#I#L(B--- ===================================================================== $B"!"!#J#U#S#T#M#A#I#L$O%@%$%l%/%H#E(B-$B#M#A#I#L$NAw?.Be9T%5!<%S%9$G$9"!"!(B ===================================================================== $B!~#J#U#S#T#M#A#I#L$N$*Ld$$9g$o$;!'(B justmail@u01.gate01.com $B!~Aw?.Dd;_$O$3$A$i$+$i!'(B http://hw001.gate01.com/degi-shop/stop.htm ===================================================================== From owner-linux-xfs@oss.sgi.com Wed Jun 12 20:38:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D3cFnC021150 for ; Wed, 12 Jun 2002 20:38:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D3cF5m021149 for linux-xfs-outgoing; Wed, 12 Jun 2002 20:38:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D3c6nC021121 for ; Wed, 12 Jun 2002 20:38:07 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA32340 for ; Wed, 12 Jun 2002 22:40:32 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA90407 for ; Wed, 12 Jun 2002 22:40:31 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5D3e6815894; Wed, 12 Jun 2002 22:40:06 -0500 Message-Id: <200206130340.g5D3e6815894@jen.americas.sgi.com> Date: Wed, 12 Jun 2002 22:40:06 -0500 Subject: TAKE - fix xfs build issues in 2.5 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Make with modversions now works, and xfs no longer constantly rebuilds. Date: Wed Jun 12 20:39:24 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:121449a linux/fs/xfs/Makefile - 1.144 - Make xfs build better From owner-linux-xfs@oss.sgi.com Wed Jun 12 20:41:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D3f0nC021319 for ; Wed, 12 Jun 2002 20:41:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D3f0pP021318 for linux-xfs-outgoing; Wed, 12 Jun 2002 20:41:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D3etnC021290 for ; Wed, 12 Jun 2002 20:40:55 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA32099 for ; Wed, 12 Jun 2002 22:43:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA33749 for ; Wed, 12 Jun 2002 22:43:20 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5D3gt615966; Wed, 12 Jun 2002 22:42:55 -0500 Message-Id: <200206130342.g5D3gt615966@jen.americas.sgi.com> Date: Wed, 12 Jun 2002 22:42:55 -0500 Subject: TAKE - get kdb working again To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Building with kdb is now possible again Date: Wed Jun 12 20:41:50 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:121451a linux/Makefile - 1.202 linux/arch/i386/kdb/kdba_io.c - 1.15 linux/kdb/modules/kdbm_pg.c - 1.60 From owner-linux-xfs@oss.sgi.com Wed Jun 12 22:38:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D5conC022294 for ; Wed, 12 Jun 2002 22:38:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D5cnGZ022293 for linux-xfs-outgoing; Wed, 12 Jun 2002 22:38:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.lbsd.net (mail.lbsd.net [196.25.111.97]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D5cUnC022265 for ; Wed, 12 Jun 2002 22:38:34 -0700 Received: from localhost (nkukard@localhost) by mail.lbsd.net (8.12.1/8.12.1) with ESMTP id g5D5ewFi001656 for ; Thu, 13 Jun 2002 07:40:59 +0200 Date: Thu, 13 Jun 2002 07:40:57 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: Kernel 2.4.18 + XFS r1.1 + Quota 3.06 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anyone tried to set quota's under the following... kernel 2.4.18 xfs 1.1 quota 3.06 [nkukard@devel.lbsd.net quota-tools]$ mount /dev/sda3 on / type xfs (rw,quota) none on /proc type proc (rw) none on /dev type devfs (rw) /dev/sda1 on /boot type xfs (rw) /dev/sdb on /mnt/hdd type xfs (rw) [nkukard@devel.lbsd.net quota-tools]$ dmesg | grep VFS VFS: Diskquotas version dquot_6.5.0 initialized VFS: Mounted root (xfs filesystem) readonly. [nkukard@devel.lbsd.net quota-tools]$ /usr/sbin/edquota nkukard No filesystems with quota detected. [nkukard@devel.lbsd.net quota-tools]$ strace /usr/sbin/edquota nkukard . . . brk(0x8057000) = 0x8057000 stat64("/proc/fs/xfs/stat", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 stat64("/proc/sys/fs/quota", 0xbffffa10) = -1 ENOENT (No such file or directory) rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0 quotactl(0x1100 /* Q_??? */|USRQUOTA, NULL, 0, {1074990624, 16, 3221223944, 1074288525, 3221224008, 1074990624, 134571248, 1075007948}) = -1 ENOSYS (Function not implemented) rt_sigaction(SIGSEGV, {SIG_DFL}, NULL, 8) = 0 open("/etc/mtab", O_RDONLY) = 3 brk(0x8059000) = 0x8059000 fstat64(3, {st_mode=S_IFREG|0644, st_size=131, ...}) = 0 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 read(3, "/dev/sda3 / xfs rw,quota 0 0\nnon"..., 4096) = 131 statfs("/", {f_type=0x58465342, f_bsize=4096, f_blocks=2169583, f_bfree=1014712, f_files=8683072, f_ffree=8571968, f_namelen=255}) = 0 stat64("/dev/sda3", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 3), ...}) = 0 stat64("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/boot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 statfs("/boot", {f_type=0x58465342, f_bsize=4096, f_blocks=2808, f_bfree=2303, f_files=16000, f_ffree=15988, f_namelen=255}) = 0 stat64("/dev/sda1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 1), ...}) = 0 stat64("/boot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat64("/mnt", {st_mode=S_IFDIR|0755, st_size=52, ...}) = 0 lstat64("/mnt/hdd", {st_mode=S_IFDIR|0755, st_size=36, ...}) = 0 statfs("/mnt/hdd", {f_type=0x58465342, f_bsize=4096, f_blocks=17919655, f_bfree=16388479, f_files=71687360, f_ffree=71375320, f_namelen=255}) = 0 stat64("/dev/sdb", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 16), ...}) = 0 stat64("/mnt/hdd", {st_mode=S_IFDIR|0755, st_size=36, ...}) = 0 read(3, "", 4096) = 0 close(3) = 0 munmap(0x40014000, 4096) = 0 quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/sda3", 0, {1, 0, 4294967295, 4294967295, 0, 0, 0, 4294967295}) = 0 quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/sda1", 0, {1, 0, 4294967295, 4294967295, 0, 0, 0, 4294967295}) = 0 quotactl(0x5805 /* Q_??? */|USRQUOTA, "/dev/sdb", 0, {1, 0, 4294967295, 4294967295, 0, 0, 0, 4294967295}) = 0 write(2, "No filesystems with quota detect"..., 36No filesystems with quota detected. ) = 36 _exit(0) = ? [nkukard@devel.lbsd.net quota-tools]$ /usr/sbin/edquota -V Quota utilities version 3.06. Compiled with RPC and EXT2_DIRECT Bugs to mvw@planets.elm.net, jack@suse.cz anyone got suggestins where to start looking for the problem? -- Nigel Kukard From owner-linux-xfs@oss.sgi.com Thu Jun 13 00:15:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D7FLnC023558 for ; Thu, 13 Jun 2002 00:15:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D7FLM5023557 for linux-xfs-outgoing; Thu, 13 Jun 2002 00:15:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D7FEnC023528 for ; Thu, 13 Jun 2002 00:15:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id AAA07429 for ; Thu, 13 Jun 2002 00:17:42 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA04517; Thu, 13 Jun 2002 17:16:21 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5D7Esbr003103; Thu, 13 Jun 2002 17:14:54 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5D7EriP003101; Thu, 13 Jun 2002 17:14:53 +1000 Date: Thu, 13 Jun 2002 17:14:53 +1000 From: Nathan Scott To: Nigel Kukard Cc: Linux XFS Mailing List Subject: Re: Kernel 2.4.18 + XFS r1.1 + Quota 3.06 Message-ID: <20020613071453.GB1737@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 13, 2002 at 07:40:57AM +0200, Nigel Kukard wrote: > > Has anyone tried to set quota's under the following... > > kernel 2.4.18 > xfs 1.1 > quota 3.06 > > [nkukard@devel.lbsd.net quota-tools]$ mount > /dev/sda3 on / type xfs (rw,quota) > none on /proc type proc (rw) > none on /dev type devfs (rw) > /dev/sda1 on /boot type xfs (rw) > /dev/sdb on /mnt/hdd type xfs (rw) > [nkukard@devel.lbsd.net quota-tools]$ dmesg | grep VFS > VFS: Diskquotas version dquot_6.5.0 initialized > VFS: Mounted root (xfs filesystem) readonly. > [nkukard@devel.lbsd.net quota-tools]$ /usr/sbin/edquota nkukard > No filesystems with quota detected. Have you run quotaon(8) on the root filesystem? It is not sufficient to just use the mount options for root. Refer to cmd/xfsprogs/doc/HOWTO.quota for further details. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 13 00:54:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D7swnC024124 for ; Thu, 13 Jun 2002 00:54:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D7swV1024123 for linux-xfs-outgoing; Thu, 13 Jun 2002 00:54:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D7smnC024085 for ; Thu, 13 Jun 2002 00:54:48 -0700 Received: from erbenson.alaska.net (78-pm6.nwc.alaska.net [209.112.139.78]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g5D7vHd53209 for ; Wed, 12 Jun 2002 23:57:18 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 91435393A for ; Wed, 12 Jun 2002 23:57:16 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 870A210294; Wed, 12 Jun 2002 23:57:16 -0800 (AKDT) Date: Wed, 12 Jun 2002 23:57:16 -0800 From: Ethan Benson To: Linux XFS Mailing List Subject: Re: [OT] Compiling today's Samba for Debian fails with rejected patch Message-ID: <20020612235716.I9152@plato.local.lan> Mail-Followup-To: Linux XFS Mailing List References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xQR6quUbZ63TTuTU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rabe@RWTH-Aachen.DE on Wed, Jun 12, 2002 at 05:04:33PM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --xQR6quUbZ63TTuTU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 12, 2002 at 05:04:33PM +0200, Ralf G. R. Bergs wrote: > # debian/rules binary > [...] > patching file `source/include/proto.h' > Hunk #6 FAILED at 1079. > Hunk #7 succeeded at 1522 (offset 1 line). > Hunk #9 succeeded at 2441 (offset 4 lines). > Hunk #11 succeeded at 2537 (offset 4 lines). > Hunk #13 succeeded at 4759 (offset 17 lines). > 1 out of 14 hunks FAILED -- saving rejects to source/include/proto.h.rej >=20 >=20 > Is the Debian stuff possibly not up-to-date? the debian packaging scripts are applying a set of patches, these patches are obviously against the released version (whatever they are shipping right now) and not random CVS snapshots.=20=20 > I'd do the patch manually, but it seems far too much work, and I'm not su= re=20 > whether I understand what the patch is trying to change. just resolve the .rej files. > Thanks for any insights, you would be better off asking on debian-user@lists.debian.org on how to do this. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --xQR6quUbZ63TTuTU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0IUFwACgkQJKx7GixEevwtmACeI4ragWJXUO1rXFisNCqitu89 jicAn3GMU2g4zTGaVJMrVRNc7aHKjlsA =yjL/ -----END PGP SIGNATURE----- --xQR6quUbZ63TTuTU-- From owner-linux-xfs@oss.sgi.com Thu Jun 13 01:33:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5D8XUnC024883 for ; Thu, 13 Jun 2002 01:33:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5D8XUQs024882 for linux-xfs-outgoing; Thu, 13 Jun 2002 01:33:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5D8XNnC024853 for ; Thu, 13 Jun 2002 01:33:24 -0700 Received: from auto-nb1.arosa.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5D8ZYlF068895; Thu, 13 Jun 2002 10:35:40 +0200 (CEST) Message-Id: <4.3.2.7.2.20020613103328.03974d10@pop.arosa.nl> X-Sender: seth@pop.arosa.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 13 Jun 2002 10:35:55 +0200 To: Russell Coker , From: Seth Mos Subject: Re: XFS and LSM Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020613081508.DF46C1CBC@lyta.coker.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:15 13-6-2002 +0200, Russell Coker wrote: >I wanted to build a system running the XFS file system and Linux Security >Modules (LSM), so I had a look at hacking the patch files to make them work. > >I found one issue where the patches severely conflict, system call 1217 on >IA64 is sys_setxattr for XFS and is sys_security for LSM! > >One of the projects has to change the system call. As far as I know the system calls for the ACL interface have just been commited. In 2.5 that is. I also believe that interface will we integrated in 2.4.20 when that is due. >Seth, I'm emailing you because from a quick glance at the FAQ I couldn't find >a better person to email regarding XFS issues. I have cc'ed the mailinglist. The SGI gurus know exactly what the current state of affairs is. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jun 13 03:14:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DAErnC028266 for ; Thu, 13 Jun 2002 03:14:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DAErtW028265 for linux-xfs-outgoing; Thu, 13 Jun 2002 03:14:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.ocs.com.au (mail.ocs.com.au [203.34.97.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DAEknC028237 for ; Thu, 13 Jun 2002 03:14:47 -0700 Received: (qmail 29888 invoked from network); 13 Jun 2002 10:17:16 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 13 Jun 2002 10:17:16 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id BF2893000BA; Thu, 13 Jun 2002 20:17:13 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id B123A94; Thu, 13 Jun 2002 20:17:13 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Russell Coker Cc: linux-security-module@wirex.com, linux-xfs@oss.sgi.com Subject: Re: XFS and LSM In-reply-to: Your message of "Thu, 13 Jun 2002 10:35:55 +0200." <4.3.2.7.2.20020613103328.03974d10@pop.arosa.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jun 2002 20:17:08 +1000 Message-ID: <5772.1023963428@ocs3.intra.ocs.com.au> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:15 13-6-2002 +0200, Russell Coker wrote: >I wanted to build a system running the XFS file system and Linux Security >Modules (LSM), so I had a look at hacking the patch files to make them work. > >I found one issue where the patches severely conflict, system call 1217 on >IA64 is sys_setxattr for XFS and is sys_security for LSM! The *attr syscall numbers are official, in both Linus and Marcelo kernels. LSM is picking an arbitrary syscall number for testing so they will have to find another number - and change user space to match. Pity Linus did not take my patch that reserves a range of syscall numbers for testing and provides a clean interface for determining which number to use. Linus does not consider this to be a problem. From owner-linux-xfs@oss.sgi.com Thu Jun 13 03:45:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DAjKnC005593 for ; Thu, 13 Jun 2002 03:45:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DAjKOV005592 for linux-xfs-outgoing; Thu, 13 Jun 2002 03:45:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from tsv.sws.net.au (tsv.sws.net.au [203.36.46.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DAjCnC005564 for ; Thu, 13 Jun 2002 03:45:12 -0700 Received: from lyta.coker.com.au (localhost [127.0.0.1]) by tsv.sws.net.au (Postfix) with ESMTP id E104392461; Thu, 13 Jun 2002 20:47:41 +1000 (EST) Received: from there (localhost [127.0.0.1]) by lyta.coker.com.au (Postfix) with SMTP id CF50F1F09; Thu, 13 Jun 2002 12:47:31 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-1" From: Russell Coker Reply-To: Russell Coker To: Keith Owens Subject: Re: XFS and LSM Date: Thu, 13 Jun 2002 12:47:31 +0200 X-Mailer: KMail [version 1.3.2] Cc: linux-security-module@wirex.com, linux-xfs@oss.sgi.com, SE Linux References: <5772.1023963428@ocs3.intra.ocs.com.au> In-Reply-To: <5772.1023963428@ocs3.intra.ocs.com.au> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020613104731.CF50F1F09@lyta.coker.com.au> X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 13 Jun 2002 12:17, Keith Owens wrote: > At 10:15 13-6-2002 +0200, Russell Coker wrote: > >I wanted to build a system running the XFS file system and Linux Security > >Modules (LSM), so I had a look at hacking the patch files to make them > > work. > > > >I found one issue where the patches severely conflict, system call 1217 on > >IA64 is sys_setxattr for XFS and is sys_security for LSM! > > The *attr syscall numbers are official, in both Linus and Marcelo > kernels. LSM is picking an arbitrary syscall number for testing so > they will have to find another number - and change user space to match. OK. Shouldn't be a big issue. > Pity Linus did not take my patch that reserves a range of syscall > numbers for testing and provides a clean interface for determining > which number to use. Linus does not consider this to be a problem. Yes, reserving a separate range for testing would be good, especially if you can make it work so that patches don't conflict... BTW XFS also changes the quota system in a serious way which breaks SE Linux (not LSM). -- I do not get viruses because I do not use MS software. If you use Outlook then please do not put my email address in your address-book so that WHEN you get a virus it won't use my address in the >From field. From owner-linux-xfs@oss.sgi.com Thu Jun 13 03:57:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DAvmnC005863 for ; Thu, 13 Jun 2002 03:57:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DAvm9g005862 for linux-xfs-outgoing; Thu, 13 Jun 2002 03:57:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DAvhnC005834 for ; Thu, 13 Jun 2002 03:57:44 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA34127; Thu, 13 Jun 2002 06:00:06 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-43.corp.sgi.com [134.15.64.43]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA77550; Thu, 13 Jun 2002 06:00:03 -0500 (CDT) Subject: Re: XFS and LSM From: Stephen Lord To: Russell Coker Cc: Keith Owens , linux-security-module@wirex.com, linux-xfs@oss.sgi.com, SE Linux In-Reply-To: <20020613104731.CF50F1F09@lyta.coker.com.au> References: <5772.1023963428@ocs3.intra.ocs.com.au> <20020613104731.CF50F1F09@lyta.coker.com.au> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 13 Jun 2002 05:58:55 -0500 Message-Id: <1023965939.1168.0.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-13 at 05:47, Russell Coker wrote: > > > BTW XFS also changes the quota system in a serious way which breaks SE Linux > (not LSM). > Those quota changes come from Jan Kara and are in 2.5 now. They should be on their way into 2.4 at some point too. Steve From owner-linux-xfs@oss.sgi.com Thu Jun 13 06:52:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DDqnnC008716 for ; Thu, 13 Jun 2002 06:52:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DDqniP008715 for linux-xfs-outgoing; Thu, 13 Jun 2002 06:52:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DDqYnC008682 for ; Thu, 13 Jun 2002 06:52:34 -0700 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5DDt5cx052128; Thu, 13 Jun 2002 09:55:06 -0400 Received: from d03nm800.boulder.ibm.com (d03nm800.boulder.ibm.com [9.17.194.116]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5DDt5V21824; Thu, 13 Jun 2002 07:55:05 -0600 Subject: Re: DMAPI 2GB limit To: Dean Roehrich Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Thu, 13 Jun 2002 08:55:04 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 06/13/2002 07:55:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean, Any idea when this fix will be available in an official release? (ie. When's the next release?) Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: James A Goodwin/Houston/IBM@IBMUS, linux-xfs@oss.sgi.com Subject: Re: DMAPI 2GB limit 06/12/2002 12:59 PM This is fixed now. The change involved mods to the following files: linux/fs/xfs/xfs_dmapi.c linux/include/linux/dmapi_kern.h linux/fs/xfs_dmapi/dmapi_private.h linux/fs/xfs_dmapi/dmapi_sysent.c And a matching change to the dmapi library. I'm not going to bother sending all of this out as a single patch--I'd rather that you just grab the latest stuff. I changed invis I/O to be able to open files with O_LARGEFILE, then I changed the kernel<>library interface to be able to send 64bit types, and things got a bit involved. Because this is an incompatible change in the kernel<>library interface, I've changed the name of the dmapi device from /proc/fs/xfs_dmapi to /proc/fs/xfs_dmapi_v1. That should prevent an accidental mixing of library and kernel versions that might lead to core dumps or panics. So, when you update your kernel, you have to update the libdm library, too. If you're just using the shared lib, then your application does not have to be rebuilt. Dean >From: Dean Roehrich > >>From: "James A Goodwin" >>We were noticing some EINVAL errors coming from dm_read_invis() on our XFS >>1.1 system. It looks like the sys_dmapi_args_t structure that is used to >>pass data from the DMAPI library to the kernel is using long ints to store >>the offset and length of the read. It turns out that we were trying to >>read some data just past a 2GB offset, and that value in a signed long int >>is interpreted as a fairly large negative number, which explains the EINVAL >>return code. >> >>Is this something that can be changed by recompiling with certain flags set >>(the kernel and the dmapi library), or am I simply hosed? > >I think it needs more than a recompile. Probably have to change the 'long' to >'unsigned long long'. The library already uses large enough types, maybe >it'll work. > >The bug list grows... > >Dean From owner-linux-xfs@oss.sgi.com Thu Jun 13 06:56:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DDuNnC008925 for ; Thu, 13 Jun 2002 06:56:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DDuNcJ008924 for linux-xfs-outgoing; Thu, 13 Jun 2002 06:56:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DDuHnC008896 for ; Thu, 13 Jun 2002 06:56:18 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA35260 for ; Thu, 13 Jun 2002 08:58:44 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA55614 for ; Thu, 13 Jun 2002 08:58:44 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id IAA63659 for linux-xfs@oss.sgi.com; Thu, 13 Jun 2002 08:58:44 -0500 (CDT) Date: Thu, 13 Jun 2002 08:58:44 -0500 (CDT) From: Dean Roehrich Message-Id: <200206131358.IAA63659@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - zero kmalloc'd mem in dmapi, to avoid mem corruption X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 13 06:58:21 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121459a linux/fs/xfs_dmapi/dmapi_mountinfo.c - 1.5 - zero kmalloc'd mem, to avoid mem corruption From owner-linux-xfs@oss.sgi.com Thu Jun 13 07:48:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DEmZnC014127 for ; Thu, 13 Jun 2002 07:48:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DEmZu5014126 for linux-xfs-outgoing; Thu, 13 Jun 2002 07:48:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from albexsvr.fac.com (albexsvr.fac.com [12.152.246.67]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DEmRnC014096 for ; Thu, 13 Jun 2002 07:48:27 -0700 Received: from albcm01.fac.com (albcm01.fac.com [10.2.5.60]) by albexsvr.fac.com (8.12.2/8.12.1) with ESMTP id g5DEox2b010759 for ; Thu, 13 Jun 2002 10:50:59 -0400 Received: from remus.fac.com (remus.fac.com [10.2.6.4]) by albcm01.fac.com (Switch-2.1.1/Switch-2.1.1) with ESMTP id U5DE3ENP13493 for ; Thu, 13 Jun 2002 10:50:59 -0400 Received: from albsmtp01.fac.com (albsmtp01 [10.2.5.41]) by remus.fac.com (8.11.3/8.11.3) with ESMTP id g5DEox722074 for ; Thu, 13 Jun 2002 10:50:59 -0400 (EDT) Subject: XFS 1.1 (Redhat 7.3 Installer) GRUB problem To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.6a January 17, 2001 Message-ID: From: "Jameel Akari" Date: Thu, 13 Jun 2002 10:51:08 -0400 X-MIMETrack: Serialize by Router on ALBSMTP01/First Albany(Release 5.0.8 |June 18, 2001) at 06/13/2002 10:49:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Reading this month's XFS list archive shows a couple posts regarding GRUB problems in the XFS/Redhat installer. FWIW, we used the XFS 1.0 / Redhat 7.2 installer on probably a dozen machines of varying spec (laptops up to Compaq servers with hardware RAID), all with GRUB, and it worked fine. Yesterday we did our first XFS 1.1 / Redhat 7.3 install, and GRUB failed miserably - loads stage1, then dumps to a grub> prompt. A coworker did another install today with the same result. In both cases I was able to fix it by booting the CD in rescue mode, and manually mounting the partition containing /sbin (in this case, /dev/hda2). /boot is hda1. Then, I ran grub from there (/mnt/foo/sbin/grub) and did: grub> root (hd0,0) (sets GRUBs root to /boot, /dev/hda1) grub> setup (hd0) (reinstall GRUB into MBR) grub> exit # cd / ; umount /mnt/foo (ctrl+alt+delete, eject your CD) Note that you don't want to do "setup (hd0,0)" or it will try to write the bootblocks over top of /boot (you can gues how I found that out...) These installs were on fairly modest Compaq desktops with IDE drives... the maillists archive leads me to believe that this problem and the 1.0/7.2 problems are somewhat machine dependent, and that the sync; sleep 30; sync hack isn't the right way to address it. (Feels like the kernel timer that is used by the VM and the sleep() timer are not at all aligned...) Sometime next week I'll have time to do a fresh install on a Compaq DL360 with hardware RAID, we'll see how that goes. -- Jameel Akari UNIX Admin First Albany Corp From owner-linux-xfs@oss.sgi.com Thu Jun 13 10:32:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DHWsnC026361 for ; Thu, 13 Jun 2002 10:32:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DHWsnb026360 for linux-xfs-outgoing; Thu, 13 Jun 2002 10:32:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DHWlnC026332 for ; Thu, 13 Jun 2002 10:32:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA28927 for ; Thu, 13 Jun 2002 12:35:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA33906 for ; Thu, 13 Jun 2002 12:35:15 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5DHYi710953; Thu, 13 Jun 2002 12:34:44 -0500 Message-Id: <200206131734.g5DHYi710953@jen.americas.sgi.com> Date: Thu, 13 Jun 2002 12:34:44 -0500 Subject: TAKE - remove grio code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The grio code in the linux xfs tree is totally non functional, this removes it. Date: Thu Jun 13 10:31:52 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121492a linux/fs/xfs/xfs_buf.h - 1.89 linux/fs/xfs/xfs_grio.c - 1.90 linux/fs/xfs/Makefile - 1.142 linux/fs/xfs/linux/xfs_lrw.c - 1.147 linux/fs/xfs/linux/xfs_griostubs.c - 1.12 linux/fs/xfs/linux/Makefile - 1.52 linux/fs/xfs/linux/xfs_super.h - 1.21 linux/fs/xfs/linux/xfs_super.c - 1.178 linux/fs/xfs/xfs_grio.h - 1.6 linux/fs/xfs/xfs.h - 1.23 linux/fs/xfs/pagebuf/page_buf.h - 1.20 From owner-linux-xfs@oss.sgi.com Thu Jun 13 10:46:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DHkXnC026595 for ; Thu, 13 Jun 2002 10:46:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DHkX1s026594 for linux-xfs-outgoing; Thu, 13 Jun 2002 10:46:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DHkSnC026565 for ; Thu, 13 Jun 2002 10:46:29 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA37728 for ; Thu, 13 Jun 2002 12:48:56 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA13989 for ; Thu, 13 Jun 2002 12:48:56 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id MAA87443 for linux-xfs@oss.sgi.com; Thu, 13 Jun 2002 12:48:56 -0500 (CDT) Date: Thu, 13 Jun 2002 12:48:56 -0500 (CDT) From: Dean Roehrich Message-Id: <200206131748.MAA87443@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - use dm_mode_t rather than mode_t in dmapi X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 13 10:48:43 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121495a linux/include/linux/dmapi.h - 1.10 - use dm_mode_t rather than mode_t in dmapi From owner-linux-xfs@oss.sgi.com Thu Jun 13 10:47:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DHlYnC026752 for ; Thu, 13 Jun 2002 10:47:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DHlXdc026751 for linux-xfs-outgoing; Thu, 13 Jun 2002 10:47:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DHlUnC026722 for ; Thu, 13 Jun 2002 10:47:30 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA37392 for ; Thu, 13 Jun 2002 12:49:58 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA05882 for ; Thu, 13 Jun 2002 12:49:57 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id MAA02012 for linux-xfs@oss.sgi.com; Thu, 13 Jun 2002 12:49:57 -0500 (CDT) Date: Thu, 13 Jun 2002 12:49:57 -0500 (CDT) From: Dean Roehrich Message-Id: <200206131749.MAA02012@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - use dm_mode_t rather than mode_t in dmapi X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 13 10:49:48 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:121496a cmd/dmapi/include/dmapi.h - 1.8 - use dm_mode_t rather than mode_t in dmapi From owner-linux-xfs@oss.sgi.com Thu Jun 13 15:08:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DM8DnC006595 for ; Thu, 13 Jun 2002 15:08:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DM8DMd006594 for linux-xfs-outgoing; Thu, 13 Jun 2002 15:08:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.lbsd.net (mail.lbsd.net [196.25.111.97]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DM82nC006566 for ; Thu, 13 Jun 2002 15:08:04 -0700 Received: from localhost (nkukard@localhost) by mail.lbsd.net (8.12.1/8.12.1) with ESMTP id g5DMAdwX006571 for ; Fri, 14 Jun 2002 00:10:40 +0200 Date: Fri, 14 Jun 2002 00:10:39 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List Subject: [BUG] CONFIG_XFS_QUOTA vs. CONFIG_XFS_QUOTA + CONFIG_QUOTA Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk When compiled 2.4.18 + xfs 1.1, including support only for XFS quota's quota tools 3.06 fails with the quotactl ioctl, claiming no kernel quota support... although xfs can operate without vfs quota's enabled, there is no way to configure it... heh this can be fixed by adding CONFIG_QUOTA to the kernel configuration or selecing vfs quota's when configuring.... as proposed by Eric, we can change the xfs quota configuration dependencies from... dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS to... dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS $CONFIG_QUOTA or fix quota tools to configure xfs quota's without vfs quota support. imho, the prior fix would be more sane. -- Nigel Kukard From owner-linux-xfs@oss.sgi.com Thu Jun 13 15:18:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DMIpnC006808 for ; Thu, 13 Jun 2002 15:18:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DMIp30006807 for linux-xfs-outgoing; Thu, 13 Jun 2002 15:18:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DMIknC006778 for ; Thu, 13 Jun 2002 15:18:46 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA40080; Thu, 13 Jun 2002 17:21:14 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA17128; Thu, 13 Jun 2002 17:21:13 -0500 (CDT) Subject: Re: [BUG] CONFIG_XFS_QUOTA vs. CONFIG_XFS_QUOTA + CONFIG_QUOTA From: Eric Sandeen To: Nigel Kukard Cc: Linux XFS Mailing List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 13 Jun 2002 17:18:06 -0500 Message-Id: <1024006687.8496.7.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-13 at 17:10, Nigel Kukard wrote: > > When compiled 2.4.18 + xfs 1.1, including support only for XFS quota's > quota tools 3.06 fails with the quotactl ioctl, claiming no kernel quota > support... although xfs can operate without vfs quota's enabled, there > is no way to configure it... heh > > this can be fixed by adding CONFIG_QUOTA to the kernel configuration > or selecing vfs quota's when configuring.... > > as proposed by Eric, we can change the xfs quota configuration dependencies > from... .... but Nathan tells me that XFS quota does not depend on VFS quota, so scratch that idea. :) -Eric From owner-linux-xfs@oss.sgi.com Thu Jun 13 15:42:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DMgInC007123 for ; Thu, 13 Jun 2002 15:42:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DMgIns007122 for linux-xfs-outgoing; Thu, 13 Jun 2002 15:42:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DMg9nC007094 for ; Thu, 13 Jun 2002 15:42:09 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA07946 for ; Thu, 13 Jun 2002 15:44:41 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA11131; Fri, 14 Jun 2002 08:43:22 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5DMfsBs002126; Fri, 14 Jun 2002 08:41:54 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5DMfqPg002124; Fri, 14 Jun 2002 08:41:52 +1000 Date: Fri, 14 Jun 2002 08:41:52 +1000 From: Nathan Scott To: Nigel Kukard Cc: Linux XFS Mailing List Subject: Re: [BUG] CONFIG_XFS_QUOTA vs. CONFIG_XFS_QUOTA + CONFIG_QUOTA Message-ID: <20020613224151.GC490@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk howzit Nigel, ;) On Fri, Jun 14, 2002 at 12:10:39AM +0200, Nigel Kukard wrote: > > When compiled 2.4.18 + xfs 1.1, including support only for XFS quota's > quota tools 3.06 fails with the quotactl ioctl, claiming no kernel quota > support... although xfs can operate without vfs quota's enabled, there > is no way to configure it... heh Can you be more specific about what fails and your setup? This works as expected for me... and has for a long time. > this can be fixed by adding CONFIG_QUOTA to the kernel configuration > or selecing vfs quota's when configuring.... > > as proposed by Eric, we can change the xfs quota configuration dependencies > from... That is the wrong thing to do. > or fix quota tools to configure xfs quota's without vfs quota support. This should just work (I have used the quota tools for, well, years now this way). > imho, the prior fix would be more sane. I would like to understand the real problem here, and not just hack around it like this. There are no dependencies between CONFIG_QUOTA and CONFIG_XFS_QUOTA and I'm not going to add one just because userspace has a bug. I recall Steve had a problem with detection of XFS quota for awhile, and I think Jan changed something in CVS quota-tools - maybe a CVS checkout will help? I'd still be interested in all the details though so I can reproduce the problem here. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 13 15:47:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DMlJnC007354 for ; Thu, 13 Jun 2002 15:47:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DMlJeX007353 for linux-xfs-outgoing; Thu, 13 Jun 2002 15:47:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DMlFnC007320 for ; Thu, 13 Jun 2002 15:47:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA39499; Thu, 13 Jun 2002 17:49:43 -0500 (CDT) Received: from [192.168.1.101] (IDENT:gT+Np3b43WzKIoZOP/VUj+j3usduMRyi@cf-vpn-sw-corp-64-55.corp.sgi.com [134.15.64.55]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA11177; Thu, 13 Jun 2002 17:49:42 -0500 (CDT) Subject: Re: [BUG] CONFIG_XFS_QUOTA vs. CONFIG_XFS_QUOTA + CONFIG_QUOTA From: Stephen Lord To: Nathan Scott Cc: Nigel Kukard , Linux XFS Mailing List In-Reply-To: <20020613224151.GC490@frodo> References: <20020613224151.GC490@frodo> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 13 Jun 2002 17:49:39 -0500 Message-Id: <1024008582.12427.26.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-13 at 17:41, Nathan Scott wrote: bug. > > I recall Steve had a problem with detection of XFS quota for > awhile, and I think Jan changed something in CVS quota-tools > - maybe a CVS checkout will help? I'd still be interested in > all the details though so I can reproduce the problem here. Nathan, 3.0.6 has the xfs detection fix in there supposedly. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jun 13 16:21:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DNLrnC007975 for ; Thu, 13 Jun 2002 16:21:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DNLr7i007974 for linux-xfs-outgoing; Thu, 13 Jun 2002 16:21:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.lbsd.net (mail.lbsd.net [196.25.111.97]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DNLinC007946 for ; Thu, 13 Jun 2002 16:21:46 -0700 Received: from localhost (nkukard@localhost) by mail.lbsd.net (8.12.1/8.12.1) with ESMTP id g5DNOLnG006706; Fri, 14 Jun 2002 01:24:21 +0200 Date: Fri, 14 Jun 2002 01:24:20 +0200 (SAST) From: Nigel Kukard To: Nathan Scott cc: Linux XFS Mailing List Subject: Re: [BUG] CONFIG_XFS_QUOTA vs. CONFIG_XFS_QUOTA + CONFIG_QUOTA In-Reply-To: <20020613224151.GC490@frodo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 14 Jun 2002, Nathan Scott wrote: > > When compiled 2.4.18 + xfs 1.1, including support only for XFS quota's > > quota tools 3.06 fails with the quotactl ioctl, claiming no kernel quota > > support... although xfs can operate without vfs quota's enabled, there > > is no way to configure it... heh > > Can you be more specific about what fails and your setup? > This works as expected for me... and has for a long time. > please refer to the post i made yesterday to the list, about quota + xfs, logs are all there, aswell as an strace -- Nigel Kukard From owner-linux-xfs@oss.sgi.com Thu Jun 13 16:44:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DNiWnC008201 for ; Thu, 13 Jun 2002 16:44:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DNiW67008200 for linux-xfs-outgoing; Thu, 13 Jun 2002 16:44:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DNiLnC008167 for ; Thu, 13 Jun 2002 16:44:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA06510 for ; Thu, 13 Jun 2002 16:46:51 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA11645; Fri, 14 Jun 2002 09:45:28 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5DNi0Bs002399; Fri, 14 Jun 2002 09:44:00 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5DNhxXe002397; Fri, 14 Jun 2002 09:43:59 +1000 Date: Fri, 14 Jun 2002 09:43:59 +1000 From: Nathan Scott To: Nigel Kukard Cc: Linux XFS Mailing List Subject: Re: [BUG] CONFIG_XFS_QUOTA vs. CONFIG_XFS_QUOTA + CONFIG_QUOTA Message-ID: <20020613234359.GD490@frodo> References: <20020613224151.GC490@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5DNiPnC008172 X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Fri, Jun 14, 2002 at 01:24:20AM +0200, Nigel Kukard wrote: > On Fri, 14 Jun 2002, Nathan Scott wrote: > > > > When compiled 2.4.18 + xfs 1.1, including support only for XFS quota's > > > quota tools 3.06 fails with the quotactl ioctl, claiming no kernel quota > > > support... although xfs can operate without vfs quota's enabled, there > > > is no way to configure it... heh > > > > Can you be more specific about what fails and your setup? > > This works as expected for me... and has for a long time. > > please refer to the post i made yesterday to the list, about quota + xfs, > logs are all there, aswell as an strace > >From yesterdays mail it seemed quota weren't actually switched on on your root fs, looking at the strace output, so the tools seemed to me to be behaving as expected. These suggestions might help diagnose the problem a bit more: - start with a non-root filesystem, its easier that way as the mount options are sufficient to enable quota; (/mnt/hdd from your system looks like a candidate); - "repquota -va" will give quota status of all mount points, & more conclusively than other tools (like edquota); - "xfs_db -r /dev/XXX -c sb -c 'p qflags'" will tell you the status of the XFS superblock quota flags. eg. for usrquota only, this'd have the value 0x7 (0x0 means no quota is enabled at all). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 13 16:54:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5DNsInC008431 for ; Thu, 13 Jun 2002 16:54:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5DNsI6K008430 for linux-xfs-outgoing; Thu, 13 Jun 2002 16:54:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5DNsDnC008392 for ; Thu, 13 Jun 2002 16:54:13 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA07765 for ; Thu, 13 Jun 2002 16:56:42 -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 JAA89931 for linux-xfs@oss.sgi.com; Fri, 14 Jun 2002 09:57:56 +1000 (EST) Date: Fri, 14 Jun 2002 09:57:56 +1000 (EST) From: Nathan Scott Message-Id: <200206132357.JAA89931@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - doc X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 13 16:54:13 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121564a linux/Documentation/Configure.help - 1.132 - update words describing quota - point to additional docs and describe the relationship to generic quota a bit. From owner-linux-xfs@oss.sgi.com Thu Jun 13 21:16:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5E4GanC011008 for ; Thu, 13 Jun 2002 21:16:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5E4GaGh011007 for linux-xfs-outgoing; Thu, 13 Jun 2002 21:16:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.dyndns.org (12-237-16-92.client.attbi.com [12.237.16.92]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5E4GUnC010978 for ; Thu, 13 Jun 2002 21:16:31 -0700 Received: from attbi.com (localhost [127.0.0.1]) by ledzep.dyndns.org (8.11.6/8.11.6) with ESMTP id g5E4Iwa02785 for ; Thu, 13 Jun 2002 23:18:59 -0500 Message-ID: <3D096EAF.1050000@attbi.com> Date: Thu, 13 Jun 2002 23:18:55 -0500 From: Jordan Breeding User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020607 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Support for journaling modes other than writeback? Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I believe I read somewhere that even with all of XFS' cool features it is only a writeback journaling fs. Is there any chance that at least in the 2.5.x tree XFS will become capable of full data and ordered journaling? Thanks for any info. Jordan From owner-linux-xfs@oss.sgi.com Thu Jun 13 22:04:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5E54MnC011948 for ; Thu, 13 Jun 2002 22:04:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5E54Mnh011947 for linux-xfs-outgoing; Thu, 13 Jun 2002 22:04:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5E54GnC011919 for ; Thu, 13 Jun 2002 22:04:16 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id WAA01743 for ; Thu, 13 Jun 2002 22:06:37 -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 PAA08920 for linux-xfs@oss.sgi.com; Fri, 14 Jun 2002 15:07:52 +1000 (EST) Date: Fri, 14 Jun 2002 15:07:52 +1000 (EST) From: Nathan Scott Message-Id: <200206140507.PAA08920@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - reduce stack use - ACLs X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 13 22:04:15 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121593a linux/fs/xfs/xfs_vfsops.c - 1.350 linux/fs/xfs/linux/xfs_iops.c - 1.150 linux/fs/xfs/xfs_acl.h - 1.13 linux/fs/xfs/xfs_acl.c - 1.25 - Take xfs_acl_t off the stack - allocate it from an xfs_acl zone instead; wrap up use of acls in macros such that an alternate implementation could be plugged in potentially - for the guys investigating large ACE counts & extended permission bits. From owner-linux-xfs@oss.sgi.com Fri Jun 14 04:04:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EB4UnC003228 for ; Fri, 14 Jun 2002 04:04:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EB4UD8003225 for linux-xfs-outgoing; Fri, 14 Jun 2002 04:04:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EB4OnC003197 for ; Fri, 14 Jun 2002 04:04:25 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA54112; Fri, 14 Jun 2002 06:06:55 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-15.corp.sgi.com [134.15.64.15]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA08806; Fri, 14 Jun 2002 06:06:53 -0500 (CDT) Subject: Re: Support for journaling modes other than writeback? From: Stephen Lord To: Jordan Breeding Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D096EAF.1050000@attbi.com> References: <3D096EAF.1050000@attbi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 06:05:27 -0500 Message-Id: <1024052730.1502.19.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-13 at 23:18, Jordan Breeding wrote: > I believe I read somewhere that even with all of XFS' cool features it > is only a writeback journaling fs. Is there any chance that at least in > the 2.5.x tree XFS will become capable of full data and ordered > journaling? Thanks for any info. > > Jordan These are concepts XFS does not have at all, and adding them in would be a considerable project. Given the workload here on other projects I would say there is no chance of SGI doing this in the forseeable future. Of the two ordered journaling stands the best chance of being possible. Steve From owner-linux-xfs@oss.sgi.com Fri Jun 14 09:52:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EGqPnC011143 for ; Fri, 14 Jun 2002 09:52:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EGqPhu011142 for linux-xfs-outgoing; Fri, 14 Jun 2002 09:52:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EGqJnC011106 for ; Fri, 14 Jun 2002 09:52:20 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA74356 for ; Fri, 14 Jun 2002 11:54:51 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA38666; Fri, 14 Jun 2002 11:54:51 -0500 (CDT) Received: (from mkulima@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id LAA85170; Fri, 14 Jun 2002 11:54:51 -0500 (CDT) Date: Fri, 14 Jun 2002 11:54:51 -0500 (CDT) From: John Kihonge Message-Id: <200206141654.LAA85170@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Cc: linux-xfs@oss.sgi.com, mkulima@sgi.com Subject: TAKE - xfsdump/xfsrestore version number print, -i option X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Jun 14 09:29:09 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/mkulima/LINUXK The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:121620a cmd/xfsdump/VERSION - 1.32 - Update version number cmd/xfsdump/doc/CHANGES - 1.40 - Updated the changes in the file cmd/xfsdump/restore/content.c - 1.23 - Changed the xfsrestore -i option messages to emphasize interactive cmd/xfsdump/common/main.c - 1.22 - Fixed the code to print out both the xfsrestore/xfsdump version and dump format version numbers From owner-linux-xfs@oss.sgi.com Fri Jun 14 10:38:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EHcJnC021617 for ; Fri, 14 Jun 2002 10:38:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EHcJEt021616 for linux-xfs-outgoing; Fri, 14 Jun 2002 10:38:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EHc7nC021588 for ; Fri, 14 Jun 2002 10:38:07 -0700 Received: from vrazalla.corp.sgi.com (vrazalla.sgi.com [192.26.57.43]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA91163 for ; Fri, 14 Jun 2002 12:40:17 -0500 (CDT) Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by vrazalla.corp.sgi.com (8.12.3/8.12.3/linux-nospam-1.4) with ESMTP id g5EHe7tQ002134 for ; Fri, 14 Jun 2002 10:40:13 -0700 Received: from [206.246.249.29] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 17Iuv6-000IIm-00; Fri, 14 Jun 2002 13:31:32 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g5EHNp814883; Fri, 14 Jun 2002 13:23:51 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g5EHNoS03103; Fri, 14 Jun 2002 13:23:50 -0400 Date: Fri, 14 Jun 2002 13:23:50 -0400 From: Charles Shannon Hendrix To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump recursive exclusion attribute Message-ID: <20020614172348.GB2603@widomaker.com> References: <20020611111728.33525a97.ivanr@sgi.com> <20020611012632.F9152@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020611012632.F9152@plato.local.lan> User-Agent: Mutt/1.3.99i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,ASCII_FORM_ENTRY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 11, 2002 at 01:26:32AM -0800, Ethan Benson wrote: > however what Ivan was talking about is quite different, say you have > two people, joe and steve, joe is leading some project, project bar, > and steve is also working on it, so they have something like: > > /home/joe/project-bar (owned by joe) > /home/joe/project-bar/fubar (owned by steve) This same discussion came up some months ago on an SGI newsgroup. I say now as I said then: this is an administration issue. Crippling the backup program because someone might abuse it makes no sense because that's not the most serious problem that can occur. The admin does not have to use an option to do exclusion by flags. In most other dump programs this is an option that must be turned on. In years of doing Linux, DEC UNIX, Solaris, and BSD UNIX admin, I've never had this be a problem before. They all allow directory exclusion, and it works out just fine. You have to be aware of things as an admin. You either back everything up, or you honor flags and make sure the users understand what that means. If you are not doing that, you have problems far greater than missing files in your backups. For many systems, especially those which lack large tape backup systems, tree level exclusion is a necessity. > i think ext2/3 only allow the file owner to set chattr flags like > nodump, so for directories assuming xfs wanted to support this (in the > ext2 manner) would need to invent a new system.something namespace just > for this, that involves kernel bloat. XFS is already huge kernel bloat, so a few more K isn't going to matter. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Fri Jun 14 11:14:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EIEFnC022190 for ; Fri, 14 Jun 2002 11:14:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EIEFgk022189 for linux-xfs-outgoing; Fri, 14 Jun 2002 11:14:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EIE7nC022158 for ; Fri, 14 Jun 2002 11:14:07 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA76354 for ; Fri, 14 Jun 2002 13:16:39 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA54053 for ; Fri, 14 Jun 2002 13:16:38 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5EIFvd30035; Fri, 14 Jun 2002 13:15:57 -0500 Subject: TAKE - XFS allocator can spin forever in full filesystem] From: Steve Lord To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 13:15:57 -0500 Message-Id: <1024078557.20553.293.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=0.8 required=5.0 tests=SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Jun 14 11:03:36 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121630a linux/fs/xfs/xfs_alloc.c - 1.152 - add an extra last pass to the allocation group scan to squeeze the last few blocks out of the disk. linux/fs/xfs/linux/xfs_lrw.c - 1.148 - when out of space, flush the log as well as the delalloc buffers Description : We came across an end case on linux where a filesystem had a few blocks free and was continually spinning in the strategy path attempting to allocate space for a delalloc block. xfs_alloc_vextent is responsible for locating an allocation group for the space. In the case where a specific allocation group has been requested, the restriction on leaving some blocks free in the ag is lifted by this function: args->minleft = 0; xfs_alloc_fix_freelist(args, 0); In the case where we are scanning all allocation groups for space, we never do that. I propose adding a third pass to the loop which scans the ags for space. In this third pass we would drop the minleft parameter down to zero which would allow us to extract blocks from the agfl to satisfy the request. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jun 14 11:18:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EIItnC022424 for ; Fri, 14 Jun 2002 11:18:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EIItmh022423 for linux-xfs-outgoing; Fri, 14 Jun 2002 11:18:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EIIlnC022393 for ; Fri, 14 Jun 2002 11:18:47 -0700 Received: (from sl70@localhost) by musuko.uchicago.edu (8.11.6/8.11.2) id g5EILO304306; Fri, 14 Jun 2002 13:21:24 -0500 X-Authentication-Warning: musuko.uchicago.edu: sl70 set sender to s-luppescu@uchicago.edu using -f Subject: Where is the 2.4.19-pre9 or 10 patch? From: Stuart Luppescu To: Linux XFS List Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-zWON9c/R1irRckWkyIpf" X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 13:21:23 -0500 Message-Id: <1024078883.3271.26.camel@musuko.uchicago.edu> Mime-Version: 1.0 X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-zWON9c/R1irRckWkyIpf Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I need the 2.4.19-pre10 patch (or -pre9) because I just got a new Palm M515, support for which first appears in 2.4.19-pre2. Do I have to get it from CVS, or is there a tar ball somewhere? (Or should I wait for the release of 2.4.19? Any indication as to how far away it is?) Thanks very much. --=20 Stuart Luppescu -=3D- s-luppescu@uchicago.edu=20=20=20=20=20=20=20=20 University of Chicago -=3D- CCSR=20 =1B$B:MJ8$HCRF`H~$NIc=1B(B -=3D- Kernel 2.4.18-xfs-1.1=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20 I don't remember it, but I have it written down.=20 =20 --=-zWON9c/R1irRckWkyIpf Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAj0KNCMACgkQDBHcBS0tWxN2wgCfVfGpPspm3NtT8GJFWxX9mORm HjMAoIQytv8/V1B8yCf9pi4gVshD9wIF =myws -----END PGP SIGNATURE----- --=-zWON9c/R1irRckWkyIpf-- From owner-linux-xfs@oss.sgi.com Fri Jun 14 11:25:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EIPZnC022605 for ; Fri, 14 Jun 2002 11:25:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EIPZLT022604 for linux-xfs-outgoing; Fri, 14 Jun 2002 11:25:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EIPRnC022574 for ; Fri, 14 Jun 2002 11:25:28 -0700 Received: from erbenson.alaska.net (124-pm30.nwc.alaska.net [209.112.158.124]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g5EIS1X46365 for ; Fri, 14 Jun 2002 10:28:01 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 12FB93939 for ; Fri, 14 Jun 2002 10:28:00 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id E979210294; Fri, 14 Jun 2002 10:27:59 -0800 (AKDT) Date: Fri, 14 Jun 2002 10:27:59 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: xfsdump recursive exclusion attribute Message-ID: <20020614102759.M9152@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020611111728.33525a97.ivanr@sgi.com> <20020611012632.F9152@plato.local.lan> <20020614172348.GB2603@widomaker.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WuedheRyq6FDfQ9j" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020614172348.GB2603@widomaker.com>; from shannon@widomaker.com on Fri, Jun 14, 2002 at 01:23:50PM -0400 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --WuedheRyq6FDfQ9j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 14, 2002 at 01:23:50PM -0400, Charles Shannon Hendrix wrote: >=20 > For many systems, especially those which lack large tape backup systems, > tree level exclusion is a necessity. that does not mean it needs to be done via an extended attribute. > > i think ext2/3 only allow the file owner to set chattr flags like > > nodump, so for directories assuming xfs wanted to support this (in the > > ext2 manner) would need to invent a new system.something namespace just > > for this, that involves kernel bloat. >=20 > XFS is already huge kernel bloat, so a few more K isn't going to matter. thats a terribly foolish attitude, and will ensure XFS would never go into the mainline kernel. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --WuedheRyq6FDfQ9j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAj0KNa8ACgkQJKx7GixEevyS2gCcDvhy4+agJbthUSAJ1MWxWRVj HkUAn2h8OyadD90gVoaRlAQFGh6DM6yY =lonK -----END PGP SIGNATURE----- --WuedheRyq6FDfQ9j-- From owner-linux-xfs@oss.sgi.com Fri Jun 14 11:30:02 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EIU2nC022819 for ; Fri, 14 Jun 2002 11:30:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EIU2r5022818 for linux-xfs-outgoing; Fri, 14 Jun 2002 11:30:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EITvnC022783 for ; Fri, 14 Jun 2002 11:29:58 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA76764; Fri, 14 Jun 2002 13:32:30 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA24016; Fri, 14 Jun 2002 13:32:30 -0500 (CDT) Subject: Re: Where is the 2.4.19-pre9 or 10 patch? From: Eric Sandeen To: Stuart Luppescu Cc: linux-xfs@oss.sgi.com In-Reply-To: <1024078883.3271.26.camel@musuko.uchicago.edu> References: <1024078883.3271.26.camel@musuko.uchicago.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 14 Jun 2002 13:29:14 -0500 Message-Id: <1024079355.12301.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-06-14 at 13:21, Stuart Luppescu wrote: > I need the 2.4.19-pre10 patch (or -pre9) because I just got a new Palm > M515, support for which first appears in 2.4.19-pre2. Do I have to get > it from CVS, or is there a tar ball somewhere? (Or should I wait for the > release of 2.4.19? Any indication as to how far away it is?) ftp://oss.sgi.com/projects/xfs/download/patches/weekly-snapshot-patch/linux-2.4.18-xfs-2002-06-09.patch.bz2 should be against 2.4.18, and contain the 2.4.19-pre10 patch as well as xfs. -Eric From owner-linux-xfs@oss.sgi.com Fri Jun 14 13:39:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EKdonC023820 for ; Fri, 14 Jun 2002 13:39:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EKdoTs023819 for linux-xfs-outgoing; Fri, 14 Jun 2002 13:39:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from riker.skynet.be (riker.skynet.be [195.238.3.89]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EKdfnC023791 for ; Fri, 14 Jun 2002 13:39:44 -0700 Received: from darkstar (adsl-81457.turboline.skynet.be [217.136.190.49]) by riker.skynet.be (8.11.6/8.11.6/Skynet-OUT-2.19) with ESMTP id g5EKgE902901; Fri, 14 Jun 2002 22:42:14 +0200 (MET DST) (envelope-from ) Content-Type: text/plain; charset="iso-8859-1" From: Olivier Tarnus Reply-To: olivier.tarnus@skynet.be To: linux-xfs@oss.sgi.com, jmesterh@iastate.edu Subject: Re: Saving ACL's Date: Fri, 14 Jun 2002 22:44:50 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Message-Id: <200206142244.50187.olivier.tarnus@skynet.be> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5EKdinC023792 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, A way of doing it is saving acls in a file that will be saved with datas. You can produce this file really efficiently with getfacl and the magic recursive option :-) I wrote on the the subject recently in rsync mail list since i need to synchronize acls between 2 fileservers and rsync don't support them actually. Here you'll find more: http://www.mail-archive.com/rsync@lists.samba.org/msg04310.html But if you just want du dump the full filesystem on tapes, xfsdump is definitively your solution. Olivier From owner-linux-xfs@oss.sgi.com Fri Jun 14 13:49:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EKnMnC025040 for ; Fri, 14 Jun 2002 13:49:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EKnLu4025039 for linux-xfs-outgoing; Fri, 14 Jun 2002 13:49:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EKnHnC025010 for ; Fri, 14 Jun 2002 13:49:17 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA84172 for ; Fri, 14 Jun 2002 15:51:49 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA03572 for ; Fri, 14 Jun 2002 15:51:49 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5EKp7C04584; Fri, 14 Jun 2002 15:51:07 -0500 Message-Id: <200206142051.g5EKp7C04584@jen.americas.sgi.com> Date: Fri, 14 Jun 2002 15:51:07 -0500 Subject: TAKE - more small cleanups To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another round of small cleanups from Christoph Date: Fri Jun 14 13:50:55 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121659a linux/fs/xfs/xfs_dir_leaf.c - 1.102 linux/fs/xfs/linux/xfs_vfs.c - 1.34 linux/fs/xfs/linux/xfs_linux.h - 1.73 linux/fs/xfs/linux/xfs_super.c - 1.179 linux/fs/xfs/linux/xfs_vfs.h - 1.17 From owner-linux-xfs@oss.sgi.com Fri Jun 14 14:02:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EL2nnC025315 for ; Fri, 14 Jun 2002 14:02:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EL2nQB025314 for linux-xfs-outgoing; Fri, 14 Jun 2002 14:02:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EL2hnC025286 for ; Fri, 14 Jun 2002 14:02:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA84212 for ; Fri, 14 Jun 2002 16:05:16 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA70411 for ; Fri, 14 Jun 2002 16:05:16 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5EL4XF06858; Fri, 14 Jun 2002 16:04:33 -0500 Message-Id: <200206142104.g5EL4XF06858@jen.americas.sgi.com> Date: Fri, 14 Jun 2002 16:04:33 -0500 Subject: TAKE - more small cleanups To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This was supposed to be in the last checkin Date: Fri Jun 14 14:03:09 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121667a linux/fs/xfs/xfs_vfsops.c - 1.351 From owner-linux-xfs@oss.sgi.com Fri Jun 14 14:04:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EL4tnC025478 for ; Fri, 14 Jun 2002 14:04:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EL4tXF025477 for linux-xfs-outgoing; Fri, 14 Jun 2002 14:04:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EL4gnC025449 for ; Fri, 14 Jun 2002 14:04:42 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA83350; Fri, 14 Jun 2002 16:07:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA77853; Fri, 14 Jun 2002 16:07:08 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5EL6QM07631; Fri, 14 Jun 2002 16:06:26 -0500 Subject: Re: mmap() problem on xfs From: Steve Lord To: misiek@pld.ORG.PL Cc: linux-xfs@oss.sgi.com In-Reply-To: <200206141826.g5EIQe7K022769@oss.sgi.com> References: <200206141826.g5EIQe7K022769@oss.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 14 Jun 2002 16:06:25 -0500 Message-Id: <1024088785.20553.334.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This message got blocked by a spam filter - probably the binary data in the middle of it. On Fri, 2002-06-14 at 13:26, you wrote: > > Hi, > > We have problem with mmaping files from XFS partition on > our 2.4.18 kernels (xfs 03062002, previously 20020517), x86. > > Testcase - mmapcat.c : > #include > #include > #include > #include > #include > > int main(int argc, char **argv) > { > int fd,n; > char *ptr; > struct stat st; > fd=open(argv[1],O_RDONLY); > if(fd<0){perror(argv[1]);exit(1);} > fstat(fd,&st); > if(st.st_size%4096==0){fprintf(stderr,"bad file size!\n");exit(1);} > ptr = mmap(NULL,st.st_size,PROT_READ,MAP_PRIVATE,fd,0); > while (*ptr!=0) > write(1,ptr++,1); > exit(0); > } > > # mmapcat /usr/include/stdio.h gives at the end > > #endif /* included. */ > > #endif /* !_STDIO_H */ Binary data removed. > (some junk at the end). Sometimes mmapcat even crashes. There is no > problem on ext2 for example. > > Please try to run this simple script on your xfs partitions: > for a in `find /usr/include -type f -print`; do > if [ "$(cat $a 2>&1)" != "$(./mmapcat $a 2>&1)" ]; then > echo "DIFFER: $a" > fi > done > > For me: > [misiek@arm misiek]$ ./xfs-test.sh | grep DIFFER | wc -l > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > Memory fault (core dumped) > 277 This test program works here on the current xfs code base. Which suggests this is either something we have fixed, or a problem with something else in your tree. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Jun 14 15:25:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5EMPlnC026107 for ; Fri, 14 Jun 2002 15:25:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5EMPlUw026106 for linux-xfs-outgoing; Fri, 14 Jun 2002 15:25:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5EMPgnC026075 for ; Fri, 14 Jun 2002 15:25:42 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA85596 for ; Fri, 14 Jun 2002 17:28:14 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA12831 for ; Fri, 14 Jun 2002 17:28:14 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5EMRVo11214; Fri, 14 Jun 2002 17:27:31 -0500 Message-Id: <200206142227.g5EMRVo11214@jen.americas.sgi.com> Date: Fri, 14 Jun 2002 17:27:31 -0500 Subject: TAKE - allow build with acls configured off To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is not the cleanest of fixes, but a configuration would not build. Date: Fri Jun 14 15:27:13 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-newlog The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121687a linux/fs/xfs/linux/xfs_xattr.c - 1.12 - allow build without acls configured From owner-linux-xfs@oss.sgi.com Fri Jun 14 22:20:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F5KonC031341 for ; Fri, 14 Jun 2002 22:20:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F5Ko1x031340 for linux-xfs-outgoing; Fri, 14 Jun 2002 22:20:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ausmail.coremetrics.com ([64.245.50.27]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F5KknC031309 for ; Fri, 14 Jun 2002 22:20:46 -0700 Received: by AUSMAIL with Internet Mail Service (5.5.2653.19) id ; Sat, 15 Jun 2002 00:23:20 -0500 Message-ID: <85063BBE668FD411944400D0B744267A888766@AUSMAIL> From: "Gonyou, Austin" To: "'linux-xfs@oss.sgi.com '" Subject: AIO patch and XFS. Date: Sat, 15 Jun 2002 00:23:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Can anyone tell me what the latest xfs kernel will work with the AIO patch? TIA. Austin From owner-linux-xfs@oss.sgi.com Sat Jun 15 02:57:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5F9vonC000630 for ; Sat, 15 Jun 2002 02:57:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5F9vnaX000629 for linux-xfs-outgoing; Sat, 15 Jun 2002 02:57:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5F9vinC000601 for ; Sat, 15 Jun 2002 02:57:44 -0700 Received: from corsair.sgi.com (corsair.sgi.com [192.26.67.33]) by ledzep.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA77959 for ; Sat, 15 Jun 2002 05:00:18 -0500 (CDT) Received: from misie.k.pl (exim@arm.t19.ds.pwr.wroc.pl [156.17.236.105]) by corsair.sgi.com (8.12.3/8.12.3/linux-nospam-1.4) with ESMTP id g5FA0D7G008203 for ; Sat, 15 Jun 2002 03:00:18 -0700 Received: from amavis by misie.k.pl with scanned-ok (Exim 4.04) id 17JAC3-0003OG-00 for linux-xfs@oss.sgi.com; Sat, 15 Jun 2002 11:50:03 +0200 Received: from misiek by misie.k.pl with local (Exim 4.04) id 17JAC2-0007vW-00; Sat, 15 Jun 2002 11:50:02 +0200 To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: mmap() problem on xfs References: <200206141826.g5EIQe7K022769@oss.sgi.com> <1024088785.20553.334.camel@jen.americas.sgi.com> X-Attribution: arekm X-URL: http://www.t17.ds.pwr.wroc.pl/~misiek/ipv6/ Organization: PLD Linux Distribution Team From: Arkadiusz Miskiewicz Date: 15 Jun 2002 11:50:01 +0200 In-Reply-To: <1024088785.20553.334.camel@jen.americas.sgi.com> Message-ID: <877kl0ub06.fsf@arm.t19.ds.pwr.wroc.pl> Lines: 15 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 X-Virus-Scanned: by AMaViS snapshot-20020300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5F9vinC000602 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord writes: > This test program works here on the current xfs code base. Which > suggests this is either something we have fixed, or a problem > with something else in your tree. Ok, please do one more test - download ftp://misie.k.pl/xfs/xfs-test.img (35MB) and run mmapcat (included in image) on it. Our kernel is heavily patched so one of these patches may break things but we had one raport on such problem on vanilla 2.4.18 + xfs patch. > Steve -- Arkadiusz Mi¶kiewicz IPv6 ready PLD Linux at http://www.pld.org.pl misiek(at)pld.org.pl AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PWr From owner-linux-xfs@oss.sgi.com Sat Jun 15 07:08:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5FE8FnC006316 for ; Sat, 15 Jun 2002 07:08:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FE8FsX006315 for linux-xfs-outgoing; Sat, 15 Jun 2002 07:08:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FE88nC006286 for ; Sat, 15 Jun 2002 07:08:09 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA95275; Sat, 15 Jun 2002 09:10:44 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA52053; Sat, 15 Jun 2002 09:10:43 -0500 (CDT) Date: Sat, 15 Jun 2002 09:07:20 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Arkadiusz Miskiewicz cc: Steve Lord , Subject: Re: mmap() problem on xfs In-Reply-To: <877kl0ub06.fsf@arm.t19.ds.pwr.wroc.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi - I do see DIFFER errors from the script, although I have not seen the test program crash. On ext2, don't get any errors on the include files tested. Something else to look at! -Eric On 15 Jun 2002, Arkadiusz Miskiewicz wrote: > Steve Lord writes: > > > This test program works here on the current xfs code base. Which > > suggests this is either something we have fixed, or a problem > > with something else in your tree. > Ok, please do one more test - download ftp://misie.k.pl/xfs/xfs-test.img > (35MB) and run mmapcat (included in image) on it. > > Our kernel is heavily patched so one of these patches may break things > but we had one raport on such problem on vanilla 2.4.18 + xfs patch. > > > Steve > -- > Arkadiusz Mi6kiewicz IPv6 ready PLD Linux at http://www.pld.org.pl > misiek(at)pld.org.pl AM2-6BONE, 1024/3DB19BBD, arekm(at)ircnet, PWr > From owner-linux-xfs@oss.sgi.com Sat Jun 15 07:11:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5FEBVnC006483 for ; Sat, 15 Jun 2002 07:11:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FEBV20006481 for linux-xfs-outgoing; Sat, 15 Jun 2002 07:11:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FEBRnC006452 for ; Sat, 15 Jun 2002 07:11:28 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA94990; Sat, 15 Jun 2002 09:14:03 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA64732; Sat, 15 Jun 2002 09:14:03 -0500 (CDT) Date: Sat, 15 Jun 2002 09:10:40 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Arkadiusz Miskiewicz cc: Steve Lord , Subject: Re: mmap() problem on xfs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 15 Jun 2002, Eric Sandeen wrote: > Hi - I do see DIFFER errors from the script, although I have > not seen the test program crash. I take it back, I am also seeing segmentation faults. -Eric From owner-linux-xfs@oss.sgi.com Sat Jun 15 09:28:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5FGSwnC007996 for ; Sat, 15 Jun 2002 09:28:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5FGSvcm007995 for linux-xfs-outgoing; Sat, 15 Jun 2002 09:28:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5FGSonC007963 for ; Sat, 15 Jun 2002 09:28:50 -0700 Received: from [209.96.179.215] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 17JGSY-000KZa-00; Sat, 15 Jun 2002 12:31:30 -0400 Received: from daydream.shannon.net (root@daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g5FFpL814109; Sat, 15 Jun 2002 11:51:21 -0400 (EDT) Received: (from shannon@localhost) by daydream.shannon.net (8.11.6/8.11.4) id g5FFpLN12074; Sat, 15 Jun 2002 11:51:21 -0400 Date: Sat, 15 Jun 2002 11:51:21 -0400 From: Charles Shannon Hendrix To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump recursive exclusion attribute Message-ID: <20020615155119.GA11179@widomaker.com> References: <20020611111728.33525a97.ivanr@sgi.com> <20020611012632.F9152@plato.local.lan> <20020614172348.GB2603@widomaker.com> <20020614102759.M9152@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020614102759.M9152@plato.local.lan> User-Agent: Mutt/1.3.99i X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO,ASCII_FORM_ENTRY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Jun 14, 2002 at 10:27:59AM -0800, Ethan Benson wrote: > On Fri, Jun 14, 2002 at 01:23:50PM -0400, Charles Shannon Hendrix wrote: > > > > For many systems, especially those which lack large tape backup systems, > > tree level exclusion is a necessity. > > that does not mean it needs to be done via an extended attribute. I said that tree-level exclusion is necessary. I said nothing about extended attributes. > > XFS is already huge kernel bloat, so a few more K isn't going to matter. > > thats a terribly foolish attitude, and will ensure XFS would never go > into the mainline kernel. The changes being talked about might not even amount to a few K. They could be very small. You won't know until it's done. But otherwise, I'm only stating the facts: XFS is huge, and a few K more or less is not likely to affect its inclusion into the kernel. The Linux kernel on my system is 28MB of code compressed. A build directory on my system is 180MB. XFS itself is over 5MB. I have trimmed my kernel to only necessary components. The kernel is ~3MB with 2.1MB of loadable modules. The days of a lean kernel have long been gone. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Sun Jun 16 13:18:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5GKIJnC002251 for ; Sun, 16 Jun 2002 13:18:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5GKIJAA002250 for linux-xfs-outgoing; Sun, 16 Jun 2002 13:18:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta9n.bluewin.ch (mta9n.bluewin.ch [195.186.1.215]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5GKI8nC002222 for ; Sun, 16 Jun 2002 13:18:09 -0700 Received: from tobias (213.3.192.202) by mta9n.bluewin.ch (Bluewin AG 6.0.040) id 3D047B0C0010FFF9 for linux-xfs@oss.sgi.com; Sun, 16 Jun 2002 13:50:19 +0200 Content-Type: text/plain; charset="iso-8859-15" From: Tobias Wittlin To: linux-xfs@oss.sgi.com Subject: kernel oops after copying to a resized lvm partition Date: Tue, 18 Jun 2002 13:52:25 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Message-Id: <200206181352.25779.tmmw@fenixnet.de> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5GKIAnC002223 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi After i resized my lvm partition i tried to copy 800MB little files to it. The first time i got a segfault, the second time i got the following: Jun 18 13:06:49 tobias kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000008 Jun 18 13:06:49 tobias kernel: printing eip: Jun 18 13:06:49 tobias kernel: c0189e16 Jun 18 13:06:49 tobias kernel: *pde = 00000000 Jun 18 13:06:49 tobias kernel: Oops: 0000 Jun 18 13:06:49 tobias kernel: CPU: 0 Jun 18 13:06:49 tobias kernel: EIP: 0010:[xfs_alloc_mark_busy+38/160] Tainted: P Jun 18 13:06:49 tobias kernel: EFLAGS: 00210046 Jun 18 13:06:49 tobias kernel: eax: 00000048 ebx: 00000000 ecx: d773e400 edx: 00000000 Jun 18 13:06:49 tobias kernel: esi: 00000000 edi: 00000008 ebp: ca633958 esp: ca633948 Jun 18 13:06:49 tobias kernel: ds: 0018 es: 0018 ss: 0018 Jun 18 13:06:49 tobias kernel: Process cp (pid: 1222, stackpage=ca633000) Jun 18 13:06:49 tobias kernel: Stack: 00000000 c664e200 c6926248 00200282 ca633980 c01896bd c6926248 00000008 Jun 18 13:06:49 tobias kernel: 00000004 00000001 d38a0920 c6926248 c664e200 c664e600 ca633a10 c0189417 Jun 18 13:06:49 tobias kernel: c6926248 d423b6c0 d423bc00 00000004 ca633b2c 00000001 00018000 d423b6c0 Jun 18 13:06:49 tobias kernel: Call Trace: [xfs_alloc_put_freelist+205/224] [xfs_alloc_fix_freelist+839/912] [do_rw_disk+329/848] [xfs_alloc_vextent+315/1072] [_pagebuf_lookup_pages+627/848] Jun 18 13:06:49 tobias kernel: [xfs_ialloc_ag_alloc+380/1888] [avl_delete+101/144] [_pagebuf_free_object+208/256] [pagebuf_rele+107/128] [xfs_trans_brelse+224/240] [xfs_alloc_pagf_init+54/80] Jun 18 13:06:49 tobias kernel: [xfs_dialloc+269/1952] [ide_dmaproc+309/512] [xfs_ialloc+83/896] [xfs_dir_ialloc+107/560] [xfs_mkdir+926/1632] [xfs_cmountfs+543/1488] Jun 18 13:06:49 tobias kernel: [linvfs_common_cr+361/608] [xfs_acl_iaccess+41/144] [xfs_iget_core+1258/1280] [xfs_dir2_lookup+150/288] [xfs_dir_lookup_int+191/656] [xfs_trans_unlocked_item+35/64] Jun 18 13:06:49 tobias kernel: [xfs_iunlock+76/96] [linvfs_mkdir+24/32] [vfs_mkdir+168/240] [sys_mkdir+157/224] [system_call+51/56] Jun 18 13:06:49 tobias kernel: Jun 18 13:06:49 tobias kernel: Code: 83 7a 08 00 74 13 8d 74 26 00 83 c2 0c 46 83 fe 53 7f 47 83 I had to kill cp. I use SuSE 8 and a self made kernel 2.4.18-xfs grüessli tmmw@fenixnet.de From owner-linux-xfs@oss.sgi.com Sun Jun 16 23:57:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5H6vsnC012669 for ; Sun, 16 Jun 2002 23:57:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5H6vsEZ012668 for linux-xfs-outgoing; Sun, 16 Jun 2002 23:57:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5H6vnnC012640 for ; Sun, 16 Jun 2002 23:57:49 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA07386 for ; Mon, 17 Jun 2002 00:00:32 -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 RAA37619 for linux-xfs@oss.sgi.com; Mon, 17 Jun 2002 17:01:21 +1000 (EST) Date: Mon, 17 Jun 2002 17:01:21 +1000 (EST) From: Nathan Scott Message-Id: <200206170701.RAA37619@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - cleanup ACL code (minor) X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Jun 16 23:53:26 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121725a linux/fs/xfs/linux/xfs_iops.c - 1.151 linux/fs/xfs/xfs_acl.h - 1.14 linux/fs/xfs/xfs_acl.c - 1.27 linux/fs/xfs/linux/xfs_xattr.c - 1.13 - Rework the test for default acls to be CONFIG setting friendly, and still keep related pieces all together. Added some hints for the folks starting to look at the cap and mac attributes. From owner-linux-xfs@oss.sgi.com Mon Jun 17 07:48:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HEmXnC023014 for ; Mon, 17 Jun 2002 07:48:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HEmXEe023013 for linux-xfs-outgoing; Mon, 17 Jun 2002 07:48:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HEmPnC022652 for ; Mon, 17 Jun 2002 07:48:25 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA12388; Mon, 17 Jun 2002 09:51:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA16816; Mon, 17 Jun 2002 09:51:06 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5HEnua19929; Mon, 17 Jun 2002 09:49:56 -0500 Subject: Re: mmap() problem on xfs From: Steve Lord To: Arkadiusz Miskiewicz Cc: linux-xfs@oss.sgi.com In-Reply-To: <877kl0ub06.fsf@arm.t19.ds.pwr.wroc.pl> References: <200206141826.g5EIQe7K022769@oss.sgi.com> <1024088785.20553.334.camel@jen.americas.sgi.com> <877kl0ub06.fsf@arm.t19.ds.pwr.wroc.pl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 17 Jun 2002 09:49:56 -0500 Message-Id: <1024325396.9291.1.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2002-06-15 at 04:50, Arkadiusz Miskiewicz wrote: > Steve Lord writes: > > > This test program works here on the current xfs code base. Which > > suggests this is either something we have fixed, or a problem > > with something else in your tree. > Ok, please do one more test - download ftp://misie.k.pl/xfs/xfs-test.img > (35MB) and run mmapcat (included in image) on it. > > Our kernel is heavily patched so one of these patches may break things > but we had one raport on such problem on vanilla 2.4.18 + xfs patch. This does indeed look like a real problem, it is dependent on which kernel wrote the files in the first place, so this explains why I did not see it originally. Moving to a different test box made it happen. I know what has to change, just not sure how yet. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Jun 17 08:13:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HFDZnC024438 for ; Mon, 17 Jun 2002 08:13:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HFDZYm024437 for linux-xfs-outgoing; Mon, 17 Jun 2002 08:13:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HFDMnC024406 for ; Mon, 17 Jun 2002 08:13:23 -0700 Received: (qmail 1178 invoked from network); 17 Jun 2002 15:17:01 -0000 Received: from unknown (HELO unaropia.dw) (207.61.129.120) by coredump.sh0n.net with SMTP; 17 Jun 2002 15:17:01 -0000 Subject: [Fwd: Re: cpp0 error and strangeness with gcc 3.1.0] from XFS-CVS 2.4 From: Shawn Starr To: SGI XFS Mailing List Content-Type: multipart/mixed; boundary="=-n4X7mI7u+9QDf7xqfzcK" X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 17 Jun 2002 11:16:58 -0400 Message-Id: <1024327019.3107.12.camel@unaropia> Mime-Version: 1.0 X-Spam-Status: No, hits=2.7 required=5.0 tests=SUBJ_HAS_SPACES version=2.20 X-Spam-Level: ** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-n4X7mI7u+9QDf7xqfzcK Content-Type: text/plain Content-Transfer-Encoding: 7bit -- Shawn Starr, sh0n.net, Maintainer: -shawn kernel patches: http://xfs.sh0n.net/2.4/ Developer Support Engineer Datawire Communication Networks Inc. 10 Carlson Court, Suite 300 Toronto, ON, M9W 6L2 T: 416.213.2001 ext 179 F: 416.213.2008 --=-n4X7mI7u+9QDf7xqfzcK Content-Disposition: inline Content-Description: Forwarded message - Re: cpp0 error and strangeness with gcc 3.1.0 Content-Type: message/rfc822 Return-Path: Delivered-To: spstarr@sh0n.net Received: (qmail 689 invoked from network); 15 Jun 2002 20:38:21 -0000 Received: from sources.redhat.com (209.249.29.67) by coredump.sh0n.net with SMTP; 15 Jun 2002 20:38:21 -0000 Received: (qmail 16398 invoked by alias); 15 Jun 2002 20:37:26 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 16387 invoked from network); 15 Jun 2002 20:37:26 -0000 Received: from unknown (HELO egil.codesourcery.com) (66.92.14.122) by sources.redhat.com with SMTP; 15 Jun 2002 20:37:26 -0000 Received: from zack by egil.codesourcery.com with local (Exim 3.35 #1 (Debian)) id 17JKIU-0002MB-00; Sat, 15 Jun 2002 13:37:22 -0700 Date: Sat, 15 Jun 2002 13:37:22 -0700 To: Shawn Starr Cc: gcc-bugs@gcc.gnu.org Subject: Re: cpp0 error and strangeness with gcc 3.1.0 Message-ID: <20020615203722.GC6252@codesourcery.com> References: <004401c214aa$9b0f6b30$030aa8c0@unknown> <008301c214b0$b8d176d0$030aa8c0@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008301c214b0$b8d176d0$030aa8c0@unknown> User-Agent: Mutt/1.4i From: Zack Weinberg Content-Transfer-Encoding: On Sat, Jun 15, 2002 at 04:07:56PM -0500, Shawn Starr wrote: > I've heard from some people the XFS Filesystem broke gcc 3.1 :( Ask the kernel people if XFS fills out the partial page at the end of a memory mapped file with zero bytes. SUS requires this be done, and to do otherwise is a security hole. The Cygwin bootstrap bug you found was indeed a case of Windows (9x) not doing this. We believe we have properly worked around that. zw --=-n4X7mI7u+9QDf7xqfzcK-- From owner-linux-xfs@oss.sgi.com Mon Jun 17 08:15:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HFFlnC024640 for ; Mon, 17 Jun 2002 08:15:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HFFldf024639 for linux-xfs-outgoing; Mon, 17 Jun 2002 08:15:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HFFanC024608 for ; Mon, 17 Jun 2002 08:15:37 -0700 Received: (qmail 1283 invoked from network); 17 Jun 2002 15:19:16 -0000 Received: from unknown (HELO unaropia.dw) (207.61.129.120) by coredump.sh0n.net with SMTP; 17 Jun 2002 15:19:16 -0000 Subject: [Fwd: Re: cpp0 error and strangeness with gcc 3.1.0] - More info From: Shawn Starr To: SGI XFS Mailing List Content-Type: multipart/mixed; boundary="=-/oC2j9btBe7XHSp4x0Wv" X-Mailer: Ximian Evolution 1.0.2.99 Preview Release Date: 17 Jun 2002 11:19:13 -0400 Message-Id: <1024327154.26568.14.camel@unaropia> Mime-Version: 1.0 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-/oC2j9btBe7XHSp4x0Wv Content-Type: text/plain Content-Transfer-Encoding: 7bit -- Shawn Starr, sh0n.net, Maintainer: -shawn kernel patches: http://xfs.sh0n.net/2.4/ Developer Support Engineer Datawire Communication Networks Inc. 10 Carlson Court, Suite 300 Toronto, ON, M9W 6L2 T: 416.213.2001 ext 179 F: 416.213.2008 --=-/oC2j9btBe7XHSp4x0Wv Content-Disposition: inline Content-Description: Forwarded message - Re: cpp0 error and strangeness with gcc 3.1.0 Content-Type: message/rfc822 Return-Path: Delivered-To: spstarr@sh0n.net Received: (qmail 1168 invoked from network); 17 Jun 2002 15:17:00 -0000 Received: from ip68-9-71-221.ri.ri.cox.net (HELO mail.blue-labs.org) (68.9.71.221) by coredump.sh0n.net with SMTP; 17 Jun 2002 15:17:00 -0000 Received: from monkey.daikokuya.demon.co.uk (213-152-55-49.dsl.eclipse.net.uk [213.152.55.49]) by mail.blue-labs.org (8.12.3/8.12.3) with ESMTP id g5HDe67G004033 for ; Mon, 17 Jun 2002 09:40:43 -0400 Received: from neil by monkey.daikokuya.demon.co.uk with local (Exim 3.35 #1 (Debian)) id 17Jpkp-0007zW-00 for ; Mon, 17 Jun 2002 07:12:43 +0100 Date: Mon, 17 Jun 2002 07:12:43 +0100 To: Shawn Starr Subject: Re: cpp0 error and strangeness with gcc 3.1.0 Message-ID: <20020617061243.GA30703@daikokuya.demon.co.uk> References: <004401c214aa$9b0f6b30$030aa8c0@unknown> <008301c214b0$b8d176d0$030aa8c0@unknown> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <008301c214b0$b8d176d0$030aa8c0@unknown> User-Agent: Mutt/1.4i From: Neil Booth Content-Transfer-Encoding: Shawn Starr wrote:- > I've heard from some people the XFS Filesystem broke gcc 3.1 :( Like Zack said, this is almost certainly an XFS bug, in that the filesystem is not zeroing out the excess bytes, for getting the mapping up to a page boundary, when using mmap(). CPP relies on this behaviour. Please confirm this with the XFS people. Neil. --=-/oC2j9btBe7XHSp4x0Wv-- From owner-linux-xfs@oss.sgi.com Mon Jun 17 09:40:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HGeHnC025664 for ; Mon, 17 Jun 2002 09:40:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HGeHLf025663 for linux-xfs-outgoing; Mon, 17 Jun 2002 09:40:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HGe8nC025635 for ; Mon, 17 Jun 2002 09:40:09 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.35 #1) id 17Jzae-0006r6-00; Mon, 17 Jun 2002 18:42:52 +0200 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Michael Meskes" Date: Mon, 17 Jun 2002 18:42:52 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2502) For Windows 2000 (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: xfs and warnquota on Debian stable: no go Message-Id: X-Spam-Status: No, hits=-1.2 required=5.0 tests=GAPPY_TEXT version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi gang, I'm running Debian 2.2 (stable) with kernel 2.4.18-XFS (cvs checkout on 05/27) and quota 3.05-3 ("unstable" version hacked by me to compile under stable.) Everything seems to be fine APART FROM warnquota. It won't send mail, whatever I do. I straced the binary, and I spotted lots of errors like the following, but this doesn't give me any clues: quotactl(0x580300, 0x80592d8, 0x3, 0xbfffcbec) = -1 ENOENT (No such file or dire ctory) quotactl(0x580300, 0x80592d8, 0x4, 0xbfffcbec) = -1 ENOENT (No such file or dire ctory) quotactl(0x580300, 0x80592d8, 0x5, 0xbfffcbec) = -1 ENOENT (No such file or dire ctory) quotactl(0x580300, 0x80592d8, 0x6, 0xbfffcbec) = -1 ENOENT (No such file or dire ctory) Any idea what could be going wrong? Thanks, Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Mon Jun 17 09:41:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HGfunC025796 for ; Mon, 17 Jun 2002 09:41:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HGfuic025795 for linux-xfs-outgoing; Mon, 17 Jun 2002 09:41:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailcity.com (fes.mail.lycos.com [209.185.123.154]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HGfonC025760 for ; Mon, 17 Jun 2002 09:41:50 -0700 Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Jun 17 09:44:15 2002 To: linux-xfs@oss.sgi.com Date: Mon, 17 Jun 2002 17:44:15 +0100 From: "TOUCHE Julien" Message-ID: Mime-Version: 1.0 X-Sent-Mail: on Reply-To: julien.touche@lycos.com X-Expiredinmiddle: true X-Mailer: MailCity Service X-Priority: 3 Subject: other platforms X-Sender-Ip: 80.14.56.62 Organization: Lycos Mail (http://www.mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.2 required=5.0 tests=FOR_FREE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello i want to ask a simple question : will SGI make an XFS port for other platforms ? i think first to windows (where CXFS exists, so don't be much difficult, maybe) or for other UNIX, like *BSD, MacOS X. it would permit to have a unique, performant and journalized fs on all platform. Thanks bye Julien Touche _________________________________________ Communicate with others using Lycos Mail for FREE! http://mail.lycos.com/ From owner-linux-xfs@oss.sgi.com Mon Jun 17 12:12:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HJCknC028647 for ; Mon, 17 Jun 2002 12:12:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HJCkht028644 for linux-xfs-outgoing; Mon, 17 Jun 2002 12:12:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HJCcnC028606 for ; Mon, 17 Jun 2002 12:12:39 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA21145; Mon, 17 Jun 2002 14:15:24 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA05936; Mon, 17 Jun 2002 14:15:24 -0500 (CDT) Subject: Re: other platforms From: Eric Sandeen To: julien.touche@lycos.com Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-6) Date: 17 Jun 2002 14:11:41 -0500 Message-Id: <1024341101.2205.51.camel@stout.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Julien - I can't speak officially for SGI on this, but the basic answer is "not unless there's something in it for SGI." - porting takes time and money and lawyers, and if there is no return on that investment, SGI is not going to do it. re: Windows - CXFS clients and local XFS filesystems are very different pieces of code. re: other Unices, if they're not under the GPL, SGI won't do it, since that would mean various undesirable things like competitors picking up XFS code for use in their OS. Again, there is no good business reason for SGI to do this. If there were some other GPL'd OS, someone could take the GPL'd XFS code and port it. SGI probably won't, back to the problem of return on investment. If some other Unix vendor wanted to _pay_ SGI for the rights to use XFS in their OS, that might be a different story. Again, these are my personal impressions, not the official stance of SGI. -Eric On Mon, 2002-06-17 at 11:44, TOUCHE Julien wrote: > > hello > > > i want to ask a simple question : will SGI make an XFS port for > other platforms ? > i think first to windows (where CXFS exists, so don't be much difficult, maybe) > or for other UNIX, like *BSD, MacOS X. > > it would permit to have a unique, performant and journalized fs on all platform. From owner-linux-xfs@oss.sgi.com Mon Jun 17 15:58:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HMw4nC031771 for ; Mon, 17 Jun 2002 15:58:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HMw4Vc031770 for linux-xfs-outgoing; Mon, 17 Jun 2002 15:58:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HMvsnC031741 for ; Mon, 17 Jun 2002 15:57:55 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id QAA06261 for ; Mon, 17 Jun 2002 16:00:45 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with SMTP id g5HLgrEf10522018 for ; Mon, 17 Jun 2002 14:44:11 -0700 (PDT) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA10236; Tue, 18 Jun 2002 07:42:45 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5HLfF5L000911; Tue, 18 Jun 2002 07:41:15 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5HLfDRa000909; Tue, 18 Jun 2002 07:41:13 +1000 Date: Tue, 18 Jun 2002 07:41:13 +1000 From: Nathan Scott To: "Ralf G. R. Bergs" Cc: Linux XFS Mailing List , Michael Meskes Subject: Re: xfs and warnquota on Debian stable: no go Message-ID: <20020617214113.GC469@frodo> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 17, 2002 at 06:42:52PM +0200, Ralf G. R. Bergs wrote: > Hi gang, hi there, > I'm running Debian 2.2 (stable) with kernel 2.4.18-XFS (cvs checkout on 05/27) > and quota 3.05-3 ("unstable" version hacked by me to compile under stable.) > > Everything seems to be fine APART FROM warnquota. It won't send mail, whatever I > do. Can you send "repquota -va" output from your system? > I straced the binary, and I spotted lots of errors like the following, but > this doesn't give me any clues: These are harmless - warnquota is just trying to figure out which users have dquots allocated, and these ones don't. > Any idea what could be going wrong? Need some more info. I haven't used warnquota for awhile now, but it certainly used to work - I turned it off after all those annoying mail messages got to me. ;) I'll try it out again later today though and see if I can reproduce this problem. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jun 17 16:37:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5HNb9nC032261 for ; Mon, 17 Jun 2002 16:37:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5HNb9tb032260 for linux-xfs-outgoing; Mon, 17 Jun 2002 16:37:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5HNb0nC032231 for ; Mon, 17 Jun 2002 16:37:00 -0700 Received: from snort.melbourne.sgi.com (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 QAA08568 for ; Mon, 17 Jun 2002 16:40:04 -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 JAA81298 for linux-xfs@oss.sgi.com; Tue, 18 Jun 2002 09:40:53 +1000 (EST) Date: Tue, 18 Jun 2002 09:40:53 +1000 (EST) From: Nathan Scott Message-Id: <200206172340.JAA81298@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota headers (minor) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 17 16:22:28 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121806a linux/include/linux/quota.h - 1.13 linux/include/linux/dqblk_xfs.h - 1.2 linux/include/linux/quotaio_xfs.h - 1.3 - sync up with the way Jan & Linus have this kernel code - we want no changes from what they have in their trees. Date: Mon Jun 17 16:23:55 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121807a linux/include/linux/quotaio_xfs.h 1.4 renamed to linux/include/linux/dqblk_xfs.h 1.3 Date: Mon Jun 17 16:35:27 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121809a linux/include/linux/quota.h - 1.14 - remove reference to a non-existent type. From owner-linux-xfs@oss.sgi.com Mon Jun 17 20:15:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I3FjnC002454 for ; Mon, 17 Jun 2002 20:15:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I3Fju3002453 for linux-xfs-outgoing; Mon, 17 Jun 2002 20:15:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I3FTnC002419 for ; Mon, 17 Jun 2002 20:15:29 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id UAA01641 for ; Mon, 17 Jun 2002 20:18:16 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA13086; Tue, 18 Jun 2002 13:16:49 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5I3FI5L004632; Tue, 18 Jun 2002 13:15:18 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5I3FHJK004630; Tue, 18 Jun 2002 13:15:17 +1000 Date: Tue, 18 Jun 2002 13:15:17 +1000 From: Nathan Scott To: "Ralf G. R. Bergs" Cc: Linux XFS Mailing List , Michael Meskes Subject: Re: xfs and warnquota on Debian stable: no go Message-ID: <20020618031517.GB4503@frodo> References: <20020617214113.GC469@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020617214113.GC469@frodo> User-Agent: Mutt/1.4i Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5I3FWnC002421 X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,DONT_DELETE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Ralf, On Tue, Jun 18, 2002 at 07:41:13AM +1000, Nathan Scott wrote: > ... > Can you send "repquota -va" output from your system? > ... > annoying mail messages got to me. ;) I'll try it out again > later today though and see if I can reproduce this problem. Just tried it out and warnquota still seems to be working for me. frodo:~> quota -V Quota utilities version 3.05. Compiled with RPC Bugs to mvw@planets.elm.net, jack@suse.cz frodo:~> cat /etc/debian_version 3.0 frodo:~> frodo:~> frodo:~> sudo repquota -v /mnt/test *** Report for user quotas on device /dev/hda6 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 0 0 0 4 0 0 nathans +- 500 300 400 6days 1 8 10 *** Status for user quotas on device /dev/hda6 Accounting: ON; Enforcement: ON Inode: #70 (2 blocks, 2 extents) frodo:~> cat /etc/warnquota.conf MAIL_CMD = "/usr/sbin/sendmail -t" FROM = "Hired Goons " SUBJECT = "Over quota" CC_TO = SUPPORT = "root@localhost" PHONE = "1-800-NO-SPACE" frodo:~> sudo warnquota frodo:~> And sure enough, a few seconds later... ----- Forwarded message from Hired Goons ----- Date: Tue, 18 Jun 2002 12:39:49 +1000 To: nathans@frodo.melbourne.sgi.com Reply-To: root@frodo.melbourne.sgi.com From: Hired Goons Subject: Over quota Hi, We noticed that you are in violation with the quotasystem used on this system. We have found the following violations: /dev/hda6 Block limits File limits Filesystem used soft hard grace used soft hard grace /dev/hda6 +- 500 300 400 6days 1 8 10 We hope that you will cleanup before your grace period expires. Basically, this means that the system thinks you are using more disk space on the above partition(s) than you are allowed. If you do not delete files and get below your quota before the grace period expires, the system will prevent you from creating new files. For additional assistance, please contact us at root@localhost or via phone at 1-800-NO-SPACE. ----- End forwarded message ----- -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jun 17 21:47:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5I4lmnC003603 for ; Mon, 17 Jun 2002 21:47:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5I4lmM7003602 for linux-xfs-outgoing; Mon, 17 Jun 2002 21:47:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5I4lgnC003574 for ; Mon, 17 Jun 2002 21:47:42 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id VAA00523 for ; Mon, 17 Jun 2002 21:50:33 -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 OAA96427 for linux-xfs@oss.sgi.com; Tue, 18 Jun 2002 14:49:19 +1000 (EST) Date: Tue, 18 Jun 2002 14:49:19 +1000 (EST) From: Nathan Scott Message-Id: <200206180449.OAA96427@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - xfstests X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 17 21:37:18 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:121836a cmd/xfstests/src/fstest.c - 1.1 cmd/xfstests/src/mmapcat.c - 1.1 cmd/xfstests/src/Makefile - 1.12 - add fstest.c and mmapcat.c - keep a copy of these here so they don't get lost and so that I can write some QA tests which make use of 'em. authors are listed at the head of each file, minor mods made to fix warnings, etc. From owner-linux-xfs@oss.sgi.com Tue Jun 18 06:42:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IDg4nC015074 for ; Tue, 18 Jun 2002 06:42:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IDg4uj015073 for linux-xfs-outgoing; Tue, 18 Jun 2002 06:42:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from kendy.up.ac.za (kendy.up.AC.za [137.215.101.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IDfrnC015044 for ; Tue, 18 Jun 2002 06:41:56 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.35 #1) id 17KInC-0000QL-00; Tue, 18 Jun 2002 15:13:06 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 17KInB-0004JY-00; Tue, 18 Jun 2002 15:13:05 +0200 Message-ID: <3D0F31E1.A4B6627@up.ac.za> Date: Tue, 18 Jun 2002 15:13:05 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19-pre10-20020612i i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: linux-xfs@oss.sgi.com Subject: Re: TAKE - XFS allocator can spin forever in full filesystem] References: <1024078557.20553.293.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *17KInB-0004JY-00*Fn30oUg9x/I* (University of Pretoria, South Africa) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have seen a releated problem when the space is tight. When you untar a lot of small files onto a partition that is tight on space, you get out of space errors. After the delalloc blocks are commited to disk, some space become available and files get written to disk again. All the space get delalloced again with resulting out of space errors. This cycle continues until all the space are really gone or the tar exits. You end up where not all the files in the tar file get extracted to disk, eventhough everything would have fitted onto the partition. If you write the files synchronously, they all fit onto the partition. I am not sure if this fix will address this issue. If you flush before giving an "Out of space error", it should fix it. (I tried fixing this myself, but ended up with a kernel that deadlocks) I also observed a similar behaviour within the allocation groups. When all the space in an ag(#1) are delalloced, xfs switches to the next ag(#2). This is not bad if inode and data blocks would both switch to #2, but I observed that the inode blocks stayed in #1, while the data blocks switched to #2 (#1,#2 situation). This results in very bad inode vs data block layout. Xfs switches back to the previous ag (#1,#1 situation) once the delalloced blocks are commited. Paul > linux/fs/xfs/linux/xfs_lrw.c - 1.148 > - when out of space, flush the log as well as the delalloc buffers > Description : > We came across an end case on linux where a filesystem had a few blocks > free and was continually spinning in the strategy path attempting to > allocate space for a delalloc block. From owner-linux-xfs@oss.sgi.com Tue Jun 18 07:02:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IE2inC015754 for ; Tue, 18 Jun 2002 07:02:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IE2h3B015753 for linux-xfs-outgoing; Tue, 18 Jun 2002 07:02:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IE2XnC015725 for ; Tue, 18 Jun 2002 07:02:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA28902; Tue, 18 Jun 2002 09:05:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA31585; Tue, 18 Jun 2002 09:05:15 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IE3uw12666; Tue, 18 Jun 2002 09:03:56 -0500 Subject: Re: TAKE - XFS allocator can spin forever in full filesystem] From: Steve Lord To: Paul Schutte Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D0F31E1.A4B6627@up.ac.za> References: <1024078557.20553.293.camel@jen.americas.sgi.com> <3D0F31E1.A4B6627@up.ac.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 09:03:56 -0500 Message-Id: <1024409036.12631.3.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 08:13, Paul Schutte wrote: > I have seen a releated problem when the space is tight. > > When you untar a lot of small files onto a partition that is tight on space, you get > out of space errors. > After the delalloc blocks are commited to disk, some space become available and > files get written to disk again. > All the space get delalloced again with resulting out of space errors. > This cycle continues until all the space are really gone or the tar exits. > You end up where not all the files in the tar file get extracted to disk, eventhough > everything would have fitted onto the partition. If you write the files > synchronously, they all fit onto the partition. > > I am not sure if this fix will address this issue. If you flush before giving an > "Out of space error", it should fix it. > (I tried fixing this myself, but ended up with a kernel that deadlocks) There were two things in this fix - one was a pathological end case where we sat in a cpu loop and never completed, the other was to flush the log out to disk after we flush delalloc space - the log flush is what actually releases the overcommitted space in the transactions. This latter part of the fix should help your case. > > I also observed a similar behaviour within the allocation groups. > When all the space in an ag(#1) are delalloced, xfs switches to the next ag(#2). > This is not bad if inode and data blocks would both switch to #2, but I observed > that the inode blocks stayed in #1, while the data blocks switched to #2 (#1,#2 > situation). > This results in very bad inode vs data block layout. > Xfs switches back to the previous ag (#1,#1 situation) once the delalloced blocks > are commited. > Interesting point about the delalloc within an allocation group. Not sure off the top of my head how to deal with it - a single allocation group is not the answer, there are definite deadlock scenarios if you do that. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 18 07:14:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IEEgnC016100 for ; Tue, 18 Jun 2002 07:14:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IEEgdC016099 for linux-xfs-outgoing; Tue, 18 Jun 2002 07:14:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IEEYnC016065 for ; Tue, 18 Jun 2002 07:14:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA26912 for ; Tue, 18 Jun 2002 09:17:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA86035 for ; Tue, 18 Jun 2002 09:17:22 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IEG4E12849; Tue, 18 Jun 2002 09:16:04 -0500 Message-Id: <200206181416.g5IEG4E12849@jen.americas.sgi.com> Date: Tue, 18 Jun 2002 09:16:04 -0500 Subject: TAKE - fix last block mmap problems To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is the fix for the problem reported by Arkadiusz Miskiewicz and for the problems with cpp in gcc 3.1 The problem originates in the write path, which means even after the fix there will be files on the disk with non-zero contents after the end of file. I will be posting a program to fix up filesystems shortly. Date: Tue Jun 18 07:14:30 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121849a linux/fs/xfs/linux/xfs_lrw.c - 1.149 - remove PBMF_NEW it was not doing any good linux/fs/xfs/linux/xfs_iops.c - 1.152 - Change how we set BH_New From owner-linux-xfs@oss.sgi.com Tue Jun 18 07:34:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IEYmnC016410 for ; Tue, 18 Jun 2002 07:34:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IEYm40016409 for linux-xfs-outgoing; Tue, 18 Jun 2002 07:34:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IEYTnC016378 for ; Tue, 18 Jun 2002 07:34:29 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA25686 for ; Tue, 18 Jun 2002 09:37:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA83779; Tue, 18 Jun 2002 09:37:17 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IEZxO13032; Tue, 18 Jun 2002 09:35:59 -0500 Subject: Re: TAKE - fix last block mmap problems From: Steve Lord To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <200206181416.g5IEG4E12849@jen.americas.sgi.com> References: <200206181416.g5IEG4E12849@jen.americas.sgi.com> Content-Type: multipart/mixed; boundary="=-3+XyB8GMxQV3U5jTdquY" X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 09:35:58 -0500 Message-Id: <1024410958.12631.18.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM,COPYRIGHT_CLAIMED,FROM_AND_TO_SAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-3+XyB8GMxQV3U5jTdquY Content-Type: text/plain Content-Transfer-Encoding: 7bit > > The problem originates in the write path, which > means even after the fix there will be files on > the disk with non-zero contents after the end > of file. I will be posting a program to fix up > filesystems shortly. > This is the program to fix up the files left behind by this bug. It does a tree walk of a directory and mmaps files looking for candidates, if it finds a file with space in the last block beyond end of file which has non-zero data in it, it will zero the remainder of the block. It prints '.' for each 100 files processed, and '+' for each 100 files fixed. The test program assumes a 4K block and 4K page size, it takes a directory as the starting point. Run it as root. If you are not experiencing problems then you do not need to run this, you also probably need to have run a kernel built from cvs or patch source after May 15th to have this happen to your filesystems. This bug got into the kernel with the multiple blocksize support. I have run this on my source tree, root and usr partitions without any problems. Since it takes any dir tree as a starting point, and can be re-run without harm, try it on something inconsequential first if you are worried about it. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com --=-3+XyB8GMxQV3U5jTdquY Content-Disposition: attachment; filename=mapcheck.c Content-Transfer-Encoding: quoted-printable Content-Type: text/x-c; name=mapcheck.c; charset=ISO-8859-1 /* This fixes up a filesystem which has bad data in the last block * of the file out beyond eof. This confuses some applications. * * Copyright Stephen Lord 2002, All Rights Reserved. */ #include #include #include #include #include #include #include int verbose =3D 0, readonly =3D 0; int filecount, fixedcount; int checker( const char *file, const struct stat *st, int flag) { int fd, i, n; char *ptr, *ptr2; off_t offset; if (flag !=3D FTW_F) return 0; if (st->st_size % 4096=3D=3D0) { return (0); } fd =3D open(file,O_RDWR); if(fd<0) { return(0); } filecount++; offset =3D 4096 - st->st_size % 4096; ptr =3D mmap(NULL,st->st_size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,0); ptr2 =3D ptr + st->st_size; for (i =3D 0; i < offset; i++, ptr2++) { if (*ptr2 !=3D 0) { if (verbose) printf("%s\n", file); if (!readonly) memset(ptr + st->st_size, 0, offset); fixedcount++; if ((fixedcount % 100) =3D=3D 0) putchar('+'); break; } } munmap(ptr, st->st_size); close(fd); if ((filecount % 100) =3D=3D 0) putchar('.'); return(0); } =20 void catcher(int sig) { printf("\nInterrupted: %d files scanned %d files fixed\n", filecount, fixedcount); exit(0); } int main(int argc, char **argv) { setbuf(stdout, NULL); signal(SIGINT, catcher); ftw(argv[1], checker, 20); printf("%d files scanned %d files fixed\n",=20 filecount, fixedcount); exit (0); } --=-3+XyB8GMxQV3U5jTdquY-- From owner-linux-xfs@oss.sgi.com Tue Jun 18 07:45:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IEjFnC016626 for ; Tue, 18 Jun 2002 07:45:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IEjFMB016625 for linux-xfs-outgoing; Tue, 18 Jun 2002 07:45:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IEj6nC016596 for ; Tue, 18 Jun 2002 07:45:06 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA28492 for ; Tue, 18 Jun 2002 09:47:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA51809 for ; Tue, 18 Jun 2002 09:47:55 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IEkaL13286; Tue, 18 Jun 2002 09:46:36 -0500 Message-Id: <200206181446.g5IEkaL13286@jen.americas.sgi.com> Date: Tue, 18 Jun 2002 09:46:36 -0500 Subject: TAKE - Yet more code removal from Christoph To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another round of killing dead code paths in XFS Date: Tue Jun 18 07:45:50 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:121850a linux/include/linux/fs.h - 1.149 - remove include of xfs_sb info linux/fs/xfs/xfs_dmapi.c - 1.60 - remove need for covered vnode pointer in mount event path linux/fs/xfs/xfs_vfsops.c - 1.352 - remove unneeded check for a directory linux/fs/xfs/xfs_inode.c - 1.340 linux/fs/xfs/xfs_inode.h - 1.161 - remove xfs_get_inode - not called linux/fs/xfs/linux/xfs_vfs.c - 1.35 - remove vfs_busydev - not used linux/fs/xfs/linux/xfs_fs_subr.c - 1.31 - call into linux buffer cache functions directly rather than via pagebuf. linux/fs/xfs/linux/xfs_super.h - 1.22 - define LINVFS_GET_VFS and LINVFS_SET_VFS here to use the generic_sbp pointer. linux/fs/xfs/linux/xfs_super.c - 1.180 - Remove covered vnode pointer - we do not need it linux/include/linux/xfs_fs_sb.h - 1.7 - file no longer needed linux/fs/xfs/linux/xfs_vfs.h - 1.18 - remove vfs_busydev - not used linux/fs/xfs/pagebuf/page_buf_io.c - 1.46 - kill pagebuf_flush, pagebuf_inval and pagebuf_flushinval linux/fs/xfs/pagebuf/page_buf.c - 1.34 - remove the REMAPPING_SUPPORT #ifdefs, we need this code linux/fs/xfs/pagebuf/page_buf.h - 1.21 - kill prototypes for pagebuf_flush, pagebuf_inval and pagebuf_flushinval From owner-linux-xfs@oss.sgi.com Tue Jun 18 08:20:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IFKUnC017461 for ; Tue, 18 Jun 2002 08:20:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IFKUUL017460 for linux-xfs-outgoing; Tue, 18 Jun 2002 08:20:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IFJWnC017425 for ; Tue, 18 Jun 2002 08:19:33 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.35 #1) id 17KKoF-0004Ck-00; Tue, 18 Jun 2002 17:22:19 +0200 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" Cc: "Michael Meskes" , "Nathan Scott" Date: Tue, 18 Jun 2002 17:22:19 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2502) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020617214113.GC469@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: xfs and warnquota on Debian stable: no go Message-Id: X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,GAPPY_TEXT,URI_IS_POUND version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 18 Jun 2002 07:41:13 +1000, Nathan Scott wrote: >Can you send "repquota -va" output from your system? Sure can do. :-) Here you are: ====================== 8x ======================= Fileserver:~# repquota -va *** Report for user quotas on device /dev/sdc5 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 49496204 0 0 264643 0 0 dummy +- 51912012 0 3000000 16808 0 0 dummy -- 608 0 0 55 0 0 dummy -- 927868 0 3000000 1141 0 0 dummy -- 260992 0 3000000 2110 0 0 dummy -- 563228 0 3000000 3749 0 0 dummy -- 460796 0 3000000 1085 0 0 dummy -- 45972 0 3000000 1564 0 0 dummy -- 1817668 0 3000000 24481 0 0 dummy -- 40676 0 3000000 144 0 0 dummy -- 1457908 0 3000000 28274 0 0 dummy -- 2901260 0 3000000 2542 0 0 dummy -- 2936596 0 3000000 5992 0 0 dummy -- 338440 0 3000000 5385 0 0 dummy -- 2953880 0 3000000 4981 0 0 dummy -- 2221788 0 3000000 787 0 0 dummy -- 1276460 0 3000000 7920 0 0 dummy +- 6732972 0 3000000 10570 0 0 dummy -- 2296568 0 3000000 3228 0 0 dummy -- 13732 0 3000000 256 0 0 dummy -- 372288 0 800000 98 0 0 dummy -- 1327592 0 3000000 3331 0 0 dummy -- 13120 0 3000000 140 0 0 dummy -- 42276 0 3000000 729 0 0 dummy -- 2724 0 3000000 21 0 0 dummy -- 413004 0 800000 389 0 0 dummy -- 1053812 0 3000000 4617 0 0 dummy -- 1720900 0 3000000 2601 0 0 dummy -- 128 0 3000000 24 0 0 dummy -- 856 0 3000000 96 0 0 dummy -- 4 0 800000 4 0 0 dummy -- 310824 0 3000000 2168 0 0 dummy -- 18676 0 3000000 821 0 0 dummy +- 4302344 0 3000000 15555 0 0 dummy -- 36 0 3000000 6 0 0 dummy -- 3019368 0 3020000 7819 0 0 dummy -- 8 0 0 3 0 0 dummy -- 2145708 0 3000000 5130 0 0 dummy -- 0 0 3000000 0 0 0 dummy -- 0 0 800000 0 0 0 dummy -- 0 0 3000000 0 0 0 dummy -- 20 0 3000000 8 0 0 dummy -- 4436 0 800000 100 0 0 dummy -- 222104 0 3000000 917 0 0 dummy -- 2844264 0 3000000 2722 0 0 dummy -- 7996 0 3000000 305 0 0 dummy -- 146136 0 3000000 651 0 0 dummy -- 20 0 3000000 8 0 0 dummy -- 832908 0 3000000 1746 0 0 dummy -- 1270168 0 3000000 10021 0 0 dummy -- 64300 0 3000000 182 0 0 dummy -- 1904 0 3000000 16 0 0 dummy -- 22176 0 800000 136 0 0 dummy -- 720268 0 800000 2156 0 0 dummy -- 107936 0 800000 2482 0 0 dummy -- 9276 0 800000 269 0 0 dummy -- 76 0 800000 13 0 0 dummy -- 20 0 800000 8 0 0 dummy -- 20 0 800000 8 0 0 dummy -- 20 0 800000 8 0 0 dummy -- 20 0 800000 8 0 0 dummy -- 20 0 800000 9 0 0 dummy -- 10304 0 800000 1120 0 0 dummy -- 408 0 800000 20 0 0 dummy -- 20000 0 800000 613 0 0 dummy -- 9408 0 3000000 1005 0 0 dummy -- 37024 0 800000 491 0 0 dummy +- 1040528 0 800000 2254 0 0 dummy -- 20384 0 3000000 43 0 0 dummy -- 525000 0 800000 611 0 0 dummy -- 9380 0 800000 793 0 0 dummy -- 360204 0 3000000 3343 0 0 dummy -- 5580 0 3000000 286 0 0 dummy -- 16 0 800000 6 0 0 dummy -- 117440 0 800000 192 0 0 dummy -- 85952 0 800000 280 0 0 dummy -- 0 0 800000 1 0 0 dummy -- 210420 0 800000 524 0 0 dummy -- 4 0 0 2 0 0 dummy -- 1224 0 800000 15 0 0 dummy +- 950584 0 800000 106 0 0 dummy -- 498536 0 800000 1316 0 0 dummy -- 1527720 0 3000000 881 0 0 dummy -- 550260 0 3000000 1631 0 0 dummy -- 32444 0 800000 643 0 0 dummy -- 752436 0 800000 3303 0 0 dummy -- 333280 0 800000 1193 0 0 dummy -- 10636 0 800000 389 0 0 dummy +- 1021720 0 800000 544 0 0 dummy -- 23768 0 3000000 3872 0 0 dummy -- 99240 0 800000 1441 0 0 dummy -- 332376 0 800000 668 0 0 dummy -- 2343620 0 3000000 406 0 0 dummy -- 157112 0 800000 133 0 0 dummy -- 30852 0 800000 456 0 0 dummy -- 414708 0 800000 800 0 0 dummy -- 84144 0 800000 797 0 0 dummy -- 121720 0 800000 473 0 0 dummy -- 750796 0 800000 1555 0 0 dummy -- 734784 0 800000 1438 0 0 dummy -- 774048 0 800000 1851 0 0 dummy +- 856772 0 800000 4758 0 0 dummy -- 7012 0 800000 360 0 0 dummy +- 965504 0 800000 1683 0 0 dummy -- 80 0 800000 14 0 0 dummy +- 1215768 0 800000 6679 0 0 dummy -- 74240 0 800000 55 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 568152 0 3000000 8517 0 0 dummy -- 11372 0 800000 1629 0 0 dummy -- 343284 0 800000 1862 0 0 dummy -- 14332 0 800000 168 0 0 dummy -- 276 0 800000 14 0 0 dummy +- 1063892 0 800000 1106 0 0 dummy -- 80912 0 800000 4091 0 0 dummy -- 672 0 800000 25 0 0 dummy -- 31844 0 800000 408 0 0 dummy -- 32 0 3000000 9 0 0 dummy -- 168 0 3000000 14 0 0 dummy -- 24 0 800000 9 0 0 dummy -- 14372 0 800000 68 0 0 dummy -- 12092 0 800000 185 0 0 dummy -- 99932 0 800000 1108 0 0 dummy -- 36840 0 800000 864 0 0 dummy -- 47868 0 800000 857 0 0 dummy -- 39456 0 800000 761 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 35448 0 3000000 337 0 0 dummy -- 1995864 0 3000000 8893 0 0 dummy -- 140 0 800000 11 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 20 0 800000 7 0 0 dummy +- 1251116 0 800000 5632 0 0 dummy -- 116 0 800000 37 0 0 dummy -- 111248 0 800000 572 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 927868 0 3000000 1141 0 0 dummy -- 3019368 0 3020000 7819 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 1995864 0 3000000 8893 0 0 dummy -- 20 0 800000 8 0 0 dummy -- 2901260 0 3000000 2542 0 0 dummy -- 608 0 0 55 0 0 dummy -- 0 0 800000 1 0 0 dummy -- 750796 0 800000 1555 0 0 dummy -- 408 0 800000 20 0 0 dummy -- 2296568 0 3000000 3228 0 0 dummy -- 16 0 800000 6 0 0 dummy -- 20 0 800000 8 0 0 dummy -- 85952 0 800000 280 0 0 dummy -- 74240 0 800000 55 0 0 dummy -- 99932 0 800000 1108 0 0 dummy -- 18676 0 3000000 821 0 0 dummy -- 116 0 800000 37 0 0 dummy -- 117440 0 800000 192 0 0 dummy -- 45972 0 3000000 1564 0 0 dummy +- 950584 0 800000 106 0 0 dummy -- 13120 0 3000000 140 0 0 dummy -- 20 0 800000 8 0 0 dummy -- 1270168 0 3000000 10021 0 0 dummy -- 2936596 0 3000000 5992 0 0 dummy -- 42276 0 3000000 729 0 0 dummy -- 8 0 0 3 0 0 dummy -- 460796 0 3000000 1085 0 0 dummy -- 1327592 0 3000000 3331 0 0 dummy -- 121720 0 800000 473 0 0 dummy -- 146136 0 3000000 651 0 0 dummy -- 47868 0 800000 857 0 0 dummy -- 35448 0 3000000 337 0 0 dummy -- 37024 0 800000 491 0 0 dummy +- 1251116 0 800000 5632 0 0 dummy -- 12092 0 800000 185 0 0 dummy -- 76 0 800000 13 0 0 dummy -- 774048 0 800000 1851 0 0 dummy -- 36840 0 800000 864 0 0 dummy -- 2221788 0 3000000 787 0 0 dummy -- 260992 0 3000000 2110 0 0 dummy +- 6732972 0 3000000 10570 0 0 dummy -- 222104 0 3000000 917 0 0 dummy -- 20 0 3000000 8 0 0 dummy -- 498536 0 800000 1316 0 0 dummy -- 734784 0 800000 1438 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 24 0 800000 9 0 0 dummy -- 1276460 0 3000000 7920 0 0 dummy -- 2844264 0 3000000 2722 0 0 dummy -- 9276 0 800000 269 0 0 dummy -- 338440 0 3000000 5385 0 0 dummy -- 525000 0 800000 611 0 0 dummy -- 22176 0 800000 136 0 0 dummy -- 2953880 0 3000000 4981 0 0 dummy -- 36 0 3000000 6 0 0 dummy -- 107936 0 800000 2482 0 0 dummy -- 14332 0 800000 168 0 0 dummy -- 4 0 0 2 0 0 dummy -- 5580 0 3000000 286 0 0 dummy +- 51912012 0 3000000 16808 0 0 dummy -- 752436 0 800000 3303 0 0 dummy -- 414708 0 800000 800 0 0 dummy -- 30852 0 800000 456 0 0 dummy -- 0 0 800000 0 0 0 dummy -- 64300 0 3000000 182 0 0 dummy -- 372288 0 800000 98 0 0 dummy +- 1040528 0 800000 2254 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 1457908 0 3000000 28274 0 0 dummy +- 4302344 0 3000000 15555 0 0 dummy -- 672 0 800000 25 0 0 dummy -- 32 0 3000000 9 0 0 dummy -- 7012 0 800000 360 0 0 dummy -- 360204 0 3000000 3343 0 0 dummy -- 1053812 0 3000000 4617 0 0 dummy -- 39456 0 800000 761 0 0 dummy -- 2724 0 3000000 21 0 0 dummy -- 413004 0 800000 389 0 0 dummy -- 4 0 800000 4 0 0 dummy -- 9380 0 800000 793 0 0 dummy -- 0 0 3000000 0 0 0 dummy -- 720268 0 800000 2156 0 0 dummy -- 23768 0 3000000 3872 0 0 dummy -- 99240 0 800000 1441 0 0 dummy -- 276 0 800000 14 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 310824 0 3000000 2168 0 0 dummy -- 1904 0 3000000 16 0 0 dummy -- 20384 0 3000000 43 0 0 dummy -- 157112 0 800000 133 0 0 dummy +- 1021720 0 800000 544 0 0 dummy +- 1215768 0 800000 6679 0 0 dummy -- 568152 0 3000000 8517 0 0 dummy -- 0 0 3000000 0 0 0 dummy -- 7996 0 3000000 305 0 0 dummy -- 84144 0 800000 797 0 0 dummy -- 4436 0 800000 100 0 0 dummy +- 1063892 0 800000 1106 0 0 dummy -- 832908 0 3000000 1746 0 0 dummy -- 20 0 3000000 8 0 0 dummy -- 332376 0 800000 668 0 0 dummy -- 1817668 0 3000000 24481 0 0 dummy -- 80912 0 800000 4091 0 0 dummy -- 1527720 0 3000000 881 0 0 dummy -- 10304 0 800000 1120 0 0 dummy -- 32444 0 800000 643 0 0 dummy +- 856772 0 800000 4758 0 0 dummy -- 80 0 800000 14 0 0 dummy -- 128 0 3000000 24 0 0 dummy -- 2145708 0 3000000 5130 0 0 dummy -- 20000 0 800000 613 0 0 dummy -- 210420 0 800000 524 0 0 dummy -- 10636 0 800000 389 0 0 dummy -- 2343620 0 3000000 406 0 0 dummy -- 343284 0 800000 1862 0 0 dummy -- 20 0 800000 7 0 0 dummy -- 1224 0 800000 15 0 0 dummy -- 31844 0 800000 408 0 0 dummy -- 563228 0 3000000 3749 0 0 dummy -- 20 0 800000 9 0 0 dummy -- 333280 0 800000 1193 0 0 dummy -- 11372 0 800000 1629 0 0 dummy -- 168 0 3000000 14 0 0 dummy -- 550260 0 3000000 1631 0 0 dummy -- 14372 0 800000 68 0 0 dummy -- 140 0 800000 11 0 0 dummy -- 111248 0 800000 572 0 0 dummy -- 20 0 800000 8 0 0 dummy -- 856 0 3000000 96 0 0 dummy -- 13732 0 3000000 256 0 0 dummy -- 40676 0 3000000 144 0 0 dummy +- 965504 0 800000 1683 0 0 dummy -- 9408 0 3000000 1005 0 0 dummy -- 1720900 0 3000000 2601 0 0 *** Status for user quotas on device /dev/sdc5 Accounting: ON; Enforcement: ON Inode: #9781858 (11 blocks, 3 extents) *** Report for user quotas on device /dev/sdc6 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 19126816 0 0 168402 0 0 dummy -- 4 0 0 3 0 0 dummy -- 597008 0 0 231 0 0 dummy -- 1344 0 0 421 0 0 dummy -- 259596 0 0 18 0 0 dummy -- 56 0 0 2 0 0 dummy -- 540 0 0 41 0 0 dummy -- 256 0 0 5 0 0 dummy -- 8980 0 0 311 0 0 dummy -- 1794800 0 0 656 0 0 dummy -- 270112 0 0 50 0 0 dummy -- 37588 0 0 20 0 0 dummy -- 326560 0 0 15 0 0 dummy -- 201364 0 0 159 0 0 dummy -- 1433972 0 0 584 0 0 dummy -- 168 0 0 5 0 0 dummy -- 124 0 0 4 0 0 dummy -- 802524 0 0 1234 0 0 dummy -- 48 0 0 2 0 0 dummy -- 1080976 0 0 2906 0 0 dummy -- 44 0 0 8 0 0 dummy -- 56 0 0 15 0 0 dummy -- 2542328 0 0 2139 0 0 dummy -- 24 0 0 1 0 0 dummy -- 7988 0 0 63 0 0 dummy -- 2316852 0 0 476 0 0 dummy -- 222908 0 0 1937 0 0 dummy -- 184 0 0 6 0 0 dummy -- 3544 0 0 453 0 0 dummy -- 1984 0 0 16 0 0 dummy -- 29236 0 0 194 0 0 dummy -- 48 0 0 12 0 0 dummy -- 24 0 0 1 0 0 dummy -- 40656 0 0 139 0 0 dummy -- 48 0 0 2 0 0 dummy -- 1420508 0 0 441 0 0 dummy -- 36 0 0 3 0 0 dummy -- 32 0 0 1 0 0 dummy -- 544 0 0 113 0 0 dummy -- 1450580 0 0 2534 0 0 dummy -- 256 0 0 40 0 0 dummy -- 196 0 0 4 0 0 dummy -- 207704 0 0 61 0 0 dummy -- 69640 0 0 273 0 0 dummy -- 16 0 0 5 0 0 dummy -- 1340 0 0 12 0 0 dummy -- 28 0 0 1 0 0 dummy -- 92760 0 0 430 0 0 dummy -- 0 0 0 1 0 0 dummy -- 597008 0 0 231 0 0 dummy -- 7988 0 0 63 0 0 dummy -- 28 0 0 1 0 0 dummy -- 1794800 0 0 656 0 0 dummy -- 168 0 0 5 0 0 dummy -- 0 0 0 1 0 0 dummy -- 540 0 0 41 0 0 dummy -- 24 0 0 1 0 0 dummy -- 270112 0 0 50 0 0 dummy -- 48 0 0 2 0 0 dummy -- 56 0 0 2 0 0 dummy -- 802524 0 0 1234 0 0 dummy -- 29236 0 0 194 0 0 dummy -- 1340 0 0 12 0 0 dummy -- 92760 0 0 430 0 0 dummy -- 326560 0 0 15 0 0 dummy -- 1344 0 0 421 0 0 dummy -- 1433972 0 0 584 0 0 dummy -- 184 0 0 6 0 0 dummy -- 201364 0 0 159 0 0 dummy -- 3544 0 0 453 0 0 dummy -- 37588 0 0 20 0 0 dummy -- 24 0 0 1 0 0 dummy -- 4 0 0 3 0 0 dummy -- 1450580 0 0 2534 0 0 dummy -- 2542328 0 0 2139 0 0 dummy -- 36 0 0 3 0 0 dummy -- 1080976 0 0 2906 0 0 dummy -- 1420508 0 0 441 0 0 dummy -- 207704 0 0 61 0 0 dummy -- 69640 0 0 273 0 0 dummy -- 1984 0 0 16 0 0 dummy -- 48 0 0 12 0 0 dummy -- 222908 0 0 1937 0 0 dummy -- 256 0 0 5 0 0 dummy -- 544 0 0 113 0 0 dummy -- 56 0 0 15 0 0 dummy -- 2316852 0 0 476 0 0 dummy -- 40656 0 0 139 0 0 dummy -- 256 0 0 40 0 0 dummy -- 32 0 0 1 0 0 dummy -- 16 0 0 5 0 0 dummy -- 259596 0 0 18 0 0 dummy -- 124 0 0 4 0 0 dummy -- 8980 0 0 311 0 0 dummy -- 196 0 0 4 0 0 dummy -- 48 0 0 2 0 0 dummy -- 44 0 0 8 0 0 *** Status for user quotas on device /dev/sdc6 Accounting: ON; Enforcement: ON Inode: #6084753 (11 blocks, 8 extents) *** Report for user quotas on device /dev/hda5 Block grace time: 7days; Inode grace time: 7days Block limits File limits User used soft hard grace used soft hard grace ---------------------------------------------------------------------- root -- 17967832 0 0 4589 0 0 dummy -- 15697520 0 0 5376 0 0 dummy -- 706544 0 0 152 0 0 dummy -- 178208 0 0 37 0 0 dummy -- 706544 0 0 152 0 0 dummy -- 15697520 0 0 5376 0 0 dummy -- 178208 0 0 37 0 0 *** Status for user quotas on device /dev/hda5 Accounting: ON; Enforcement: ON Inode: #131 (10 blocks, 6 extents) ====================== 8x ======================= >Need some more info. I haven't used warnquota for awhile now, >but it certainly used to work - I turned it off after all those >annoying mail messages got to me. ;) I'll try it out again We already had those annoying messages -- but from the users who have already overdrawn their quotas and now are complaining that they can't write anymore. Sometimes to need to be strong. :-) -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jun 18 08:32:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IFWPnC021233 for ; Tue, 18 Jun 2002 08:32:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IFWPlv021232 for linux-xfs-outgoing; Tue, 18 Jun 2002 08:32:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IFW8nC021204 for ; Tue, 18 Jun 2002 08:32:09 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.35 #1) id 17KL0S-0004F2-00; Tue, 18 Jun 2002 17:34:56 +0200 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" , "Nathan Scott" Cc: "Michael Meskes" Date: Tue, 18 Jun 2002 17:34:56 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2502) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020618031517.GB4503@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: xfs and warnquota on Debian stable: no go Message-Id: X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,GAPPY_TEXT,URI_IS_POUND version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi again, On Tue, 18 Jun 2002 13:15:17 +1000, Nathan Scott wrote: >frodo:~> quota -V >Quota utilities version 3.05. >Compiled with RPC >Bugs to mvw@planets.elm.net, jack@suse.cz Mine looks the same: >Quota utilities version 3.05. >Compiled with RPC >Bugs to mvw@planets.elm.net, jack@suse.cz Moreover I have the quota daemon running (altho I don't think my problem could have anything to do with quotad running or not): Fileserver:~# ps auxw|grep quota root 14158 0.0 0.0 1172 428 ? S Jun17 0:00 /usr/sbin/rpc.rquotad >frodo:~> cat /etc/debian_version >3.0 As I already wrote in my original message we're still running stable: >Fileserver:~# cat /etc/debian_version >2.2 The problem was present with the "stable" quota version (1.65-4) as well as with the "unstable" version I compiled myself (3.05-3). >frodo:~> cat /etc/warnquota.conf >MAIL_CMD = "/usr/sbin/sendmail -t" >FROM = "Hired Goons " >SUBJECT = "Over quota" >CC_TO = >SUPPORT = "root@localhost" >PHONE = "1-800-NO-SPACE" And here is mine: >Fileserver:~# cat /etc/warnquota.conf >; ; and # type comments are allowed ># and even blank lines > ># values can be quoted: >MAIL_CMD = "/usr/sbin/sendmail -t" >FROM = "root@my.domain.DE" ># but they don't have to be: >SUBJECT = "Over quota" >CC_TO = "root@my.domain.DE" >SUPPORT = "root@localhost" >PHONE = "12345" Moreover: >#ls -la /usr/sbin/sendmail >lrwxrwxrwx 1 root root 4 Jan 5 12:12 /usr/sbin/sendmail -> exim >frodo:~> sudo warnquota >frodo:~> When I do this I don't get mail: >Fileserver:~# warnquota >Fileserver:~# tail -10 /var/log/exim/mainlog >2002-06-18 16:00:02 17KJWc-0007r6-00 Completed >2002-06-18 16:08:01 Start queue run: pid=30295 >2002-06-18 16:08:01 End queue run: pid=30295 >2002-06-18 16:38:01 Start queue run: pid=30728 >2002-06-18 16:38:01 End queue run: pid=30728 >2002-06-18 17:00:01 17KKSf-000836-00 <= root@my.domain.DE U=root P=local S= 1011 >2002-06-18 17:00:01 17KKSf-000836-00 => root@my.domain.DE R=smarthost T=remote_smtp H=mail.my.domain.de [aaa.bbb.cc.dd] >2002-06-18 17:00:01 17KKSf-000836-00 Completed >2002-06-18 17:08:01 Start queue run: pid=31042 >2002-06-18 17:08:01 End queue run: pid=31042 >Fileserver:~# date >Tue Jun 18 17:31:27 CEST 2002 Any other ideas where to poke around? Thanks, Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Tue Jun 18 09:58:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IGwHnC023253 for ; Tue, 18 Jun 2002 09:58:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IGwHIn023252 for linux-xfs-outgoing; Tue, 18 Jun 2002 09:58:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta01.algx.net (chimta01.algx.net [216.99.233.34]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IGwAnC023224 for ; Tue, 18 Jun 2002 09:58:11 -0700 Received: from wiley.ceo.com (66-2-81-28.customer.algx.net [66.2.81.28]) by chimmx01.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GXW004JJV9SI2@chimmx01.algx.net> for linux-xfs@oss.sgi.com; Tue, 18 Jun 2002 12:01:04 -0500 (CDT) Date: Tue, 18 Jun 2002 13:01:22 -0400 From: Danny Cox Subject: How To Tell If FS Is Frozen? To: XFS Mailing List Message-id: <1024419682.1156.14.camel@wiley> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.0.7 Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk /me comes out from the lurking rock: Is there a way to tell from user space if an XFS fs is frozen or not? I've checked xfs_db, xfs_info, and a few others, with no success. Failing a way to tell, would it hurt anything to thaw a fs that's NOT frozen (xfs_freeze -u)? Thanks! /me climbs back under the lurking rock -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Tue Jun 18 10:39:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IHdSnC024766 for ; Tue, 18 Jun 2002 10:39:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IHdSiZ024765 for linux-xfs-outgoing; Tue, 18 Jun 2002 10:39:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IHdLnC024737 for ; Tue, 18 Jun 2002 10:39:22 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA70167; Tue, 18 Jun 2002 12:42:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA68907; Tue, 18 Jun 2002 12:31:17 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IHTvN17812; Tue, 18 Jun 2002 12:29:57 -0500 Subject: Re: How To Tell If FS Is Frozen? From: Steve Lord To: Danny Cox Cc: XFS Mailing List In-Reply-To: <1024419682.1156.14.camel@wiley> References: <1024419682.1156.14.camel@wiley> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 12:29:57 -0500 Message-Id: <1024421397.1409.34.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.7 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 12:01, Danny Cox wrote: > /me comes out from the lurking rock: > > Is there a way to tell from user space if an XFS fs is frozen or not? > > I've checked xfs_db, xfs_info, and a few others, with no success. > > Failing a way to tell, would it hurt anything to thaw a fs that's NOT > frozen (xfs_freeze -u)? > > Thanks! > > /me climbs back under the lurking rock > There is no real way to tell - except you cannot change the filesystem. Two unfreezes should not cause problems though. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 18 10:46:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IHk3nC025183 for ; Tue, 18 Jun 2002 10:46:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IHk3iZ025182 for linux-xfs-outgoing; Tue, 18 Jun 2002 10:46:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IHjpnC025148 for ; Tue, 18 Jun 2002 10:45:51 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5IHmdg5250664 for ; Tue, 18 Jun 2002 13:48:39 -0400 Received: from chavez.austin.ibm.com (chavez.austin.ibm.com [9.53.216.228]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g5IHmdr64928 for ; Tue, 18 Jun 2002 11:48:39 -0600 Subject: XFS and I/O alignment From: Luciano Chavez To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 18 Jun 2002 12:46:15 -0500 Message-Id: <1024422375.30888.142.camel@chavez> Mime-Version: 1.0 X-Spam-Status: No, hits=1.0 required=5.0 tests=FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Recently on the EVMS mailing list, we had a gentlemen report a problem using Linux XFS 1.1 on a RAID5 storage object (Linux MD compatibility storage object). See http://sourceforge.net/mailarchive/forum.php?thread_id=799287&forum_id=2003 for the initial post. After some research I found that moving the internal log to another device worked around the problem. In short the problem appears to be related to I/O requests of 4K in length coming in on devices sensitive to alignment such as striped LVs or MD devices (specifically when these unaligned I/O requests cross boundaries like outside a chunksize). This problem should also manifest itself on non-striped entities such as fragmented LVs where a PE may get an unaligned I/O request that may span into a PE corresponding to a different LV. Also, the problem manifested itself most easily with striped devices. I found explanations under man mkfs.xfs of some options specific to striping so I experimented. Below is the output of the several mkfs.xfs attempts on a RAID 5 storage object composed of 6 partitions. root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 blks data = bsize=4096 blocks=250880, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 -d sunit=8,swidth=40 meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 blks data = bsize=4096 blocks=250880, imaxpct=25 = sunit=1 swidth=5 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 -d su=32768,sw=5 meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 blks data = bsize=4096 blocks=250880, imaxpct=25 = sunit=8 swidth=40 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 None of these helped. Not even specifying the same option on the mount. I still ended up with unaligned I/O coming in and crossing chunksize stripe boundaries essentially corrupting data. I also tried the mkfs.xfs options set to sunit=64,swidth=320 which produced sunit=8 and swidth=40 on output and still didn't help. I noticed that xfsprogs libdisk source files make tests of the device to see if it is a MD or LV striped device to automatically set the sunit and swidth values in your superblock to provide proper alignment on log I/O for example. But in my attempts to isolate this, there also must be a mount time check somewhere to determine whether to use these since formatting it correctly and mounting it with these options using the EVMS MD plug-in, they don't seem to get honored. I would appreciate any help the XFS developers could offer in allowing XFS to work on top of block devices sensitive to alignment under Linux. Please cross-post any responses to the evms-devel@lists.sourceforge.net so that others not subscribed to the linux-xfs list can see them. We (EVMS) will offer any assistance we can as we would like to see customers using XFS and EVMS together seamlessly and happily on their enterprise systems. -- regards, Luciano Chavez lnx1138@us.ibm.com http://evms.sourceforge.net From owner-linux-xfs@oss.sgi.com Tue Jun 18 11:03:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5II3QnC028756 for ; Tue, 18 Jun 2002 11:03:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5II3QOv028755 for linux-xfs-outgoing; Tue, 18 Jun 2002 11:03:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5II33nC028724 for ; Tue, 18 Jun 2002 11:03:04 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA84448; Tue, 18 Jun 2002 13:05:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA00764; Tue, 18 Jun 2002 13:05:47 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5II4Rs23292; Tue, 18 Jun 2002 13:04:28 -0500 Subject: Re: XFS and I/O alignment From: Steve Lord To: Luciano Chavez Cc: linux-xfs@oss.sgi.com, evms-devel@lists.sourceforge.net In-Reply-To: <1024422375.30888.142.camel@chavez> References: <1024422375.30888.142.camel@chavez> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 13:04:27 -0500 Message-Id: <1024423467.1392.50.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 12:46, Luciano Chavez wrote: > Hello, > > Recently on the EVMS mailing list, we had a gentlemen report a problem > using Linux XFS 1.1 on a RAID5 storage object (Linux MD compatibility > storage object). See > http://sourceforge.net/mailarchive/forum.php?thread_id=799287&forum_id=2003 for the initial post. > > After some research I found that moving the internal log to another > device worked around the problem. > > In short the problem appears to be related to I/O requests of 4K in > length coming in on devices sensitive to alignment such as striped LVs > or MD devices (specifically when these unaligned I/O requests cross > boundaries like outside a chunksize). This problem should also manifest > itself on non-striped entities such as fragmented LVs where a PE may get > an unaligned I/O request that may span into a PE corresponding to a > different LV. > > Also, the problem manifested itself most easily with striped devices. I > found explanations under man mkfs.xfs of some options specific to > striping so I experimented. Below is the output of the several mkfs.xfs > attempts on a RAID 5 storage object composed of 6 partitions. > > root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 > meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 > blks > data = bsize=4096 blocks=250880, imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 -d sunit=8,swidth=40 > meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 > blks > data = bsize=4096 blocks=250880, imaxpct=25 > = sunit=1 swidth=5 blks, unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > > root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 -d su=32768,sw=5 > meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 > blks > data = bsize=4096 blocks=250880, imaxpct=25 > = sunit=8 swidth=40 blks, > unwritten=0 > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=1200 > realtime =none extsz=65536 blocks=0, rtextents=0 > > None of these helped. Not even specifying the same option on the mount. > I still ended up with unaligned I/O coming in and crossing chunksize > stripe boundaries essentially corrupting data. I also tried the mkfs.xfs > options set to sunit=64,swidth=320 which produced sunit=8 and swidth=40 > on output and still didn't help. > > I noticed that xfsprogs libdisk source files make tests of the device to > see if it is a MD or LV striped device to automatically set the sunit > and swidth values in your superblock to provide proper alignment on log > I/O for example. But in my attempts to isolate this, there also must be > a mount time check somewhere to determine whether to use these since > formatting it correctly and mounting it with these options using the > EVMS MD plug-in, they don't seem to get honored. > > I would appreciate any help the XFS developers could offer in allowing > XFS to work on top of block devices sensitive to alignment under Linux. > > Please cross-post any responses to the evms-devel@lists.sourceforge.net > so that others not subscribed to the linux-xfs list can see them. > > We (EVMS) will offer any assistance we can as we would like to see > customers using XFS and EVMS together seamlessly and happily on their > enterprise systems. > > -- > regards, > > Luciano Chavez > > lnx1138@us.ibm.com > http://evms.sourceforge.net Hi, The answer to this problem is sitting on my workstation right now, and I am trying to decide if pushing it out into the world just before I leave for OLS followed by a week's vacation is a good idea or not. The stripe alignment code in xfs does not apply to the log, the log is written in chunks of upto 32K which can be any multiple of 512 bytes and can start on any 512 byte boundary. The only 'safe' way now to make this work with volumes where that can end up crossing device boundaries is to do all the I/O in 512 byte buffer heads. Which as you are probably aware is not the best thing in the world to do from a cpu and memory usage standpoint. This is why moving the log to a different device made the problem go away. A quick check of if this is going to fix things for EVMS is to take this code in fs/xfs/pagebuf/page_buf.c: if ((MAJOR(dev) != LVM_BLK_MAJOR) && (MAJOR(dev) != MD_MAJOR)) { sector = blk_length << SECTOR_SHIFT; blk_length = 1; } else if ((MAJOR(dev) == MD_MAJOR) && (pg_offset == 0) && (pg_length == PAGE_CACHE_SIZE) && (((unsigned int) bn) & BN_ALIGN_MASK) == 0) { sector = blk_length << SECTOR_SHIFT; blk_length = 1; } else { sector = SECTOR_SIZE; } and replace it with: sector = SECTOR_SIZE; ------------------------ The code I have sitting here introduces a new log format in xfs which can be aligned on different boundaries. It introduces new mkfs options: -l version=2,sunit=xxxx Log writes then become aligned on and padded to the stripe unit specified, 4K is enough in most cases. You can also do larger logwrites with this code, but that is not the issue here. Steve p.s. LVM2 has hit exactly the same problem. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 18 11:32:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IIW5nC029613 for ; Tue, 18 Jun 2002 11:32:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IIW5lH029612 for linux-xfs-outgoing; Tue, 18 Jun 2002 11:32:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ahriman.bucharest.roedu.net (ahriman.Bucharest.roedu.net [141.85.128.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IIVlnC029584 for ; Tue, 18 Jun 2002 11:31:48 -0700 Received: (qmail 6512 invoked by uid 1000); 18 Jun 2002 18:45:44 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Jun 2002 18:45:44 -0000 Date: Tue, 18 Jun 2002 21:45:44 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Linux XFS List Subject: bdflush Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi We are using XFS on many production servers here. We have been running 2.4.9-13 XFS 1.0.2 rel till 2.4.9-31 XFS 1.1 rel with no problems untill now. Today I have found a strange message in the dmesg output I did ksymoops on it and this is the output: ksymoops 2.4.5 on i686 2.4.9-31SGI_XFS_1.1. Options used -v /usr/src/linux/vmlinux (specified) -K (specified) -l /proc/modules (default) -o /lib/modules/2.4.9-31SGI_XFS_1.1/ (default) -m /usr/src/linux/System.map (default) No modules in ksyms, skipping objects No ksyms, skipping lsmod invalid operand: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010287 eax: 00000000 ebx: 00000008 ecx: f45cbcc0 edx: f45cbcc0 esi: 00000001 edi: f45cbcc0 ebp: 00001000 esp: f7da7f58 ds: 0018 es: 0018 ss: 0018 Process bdflush (pid: 7, stackpage=f7da7000) Stack: 00000001 f45cbcc0 c01db2bb 00000001 f45cbcc0 f45cbcc0 0000000d f6b9e720 f7da7fbc 00000001 f7da6000 00000286 c02732f8 f7da633a 00000010 c02708e0 00000000 00000000 f7da7fd4 c013487d 00000001 00000001 f7da7fc4 f45cbcc0 Call Trace: [] [] [] [] [] [] Code: 0f 0b b8 03 00 00 00 f0 0f ab 42 18 0f b7 42 0c 66 89 42 14 >>EIP; c01db07b <===== >>ecx; f45cbcc0 >>edx; f45cbcc0 >>edi; f45cbcc0 >>ebp; 00001000 Before first symbol >>esp; f7da7f58 Trace; c01db2bb Trace; c013487d Trace; c0137bca Trace; c024e8ae Trace; c0137deb Trace; c01055b4 Code; c01db07b 0000000000000000 <_EIP>: Code; c01db07b <===== 0: 0f 0b ud2a <===== Code; c01db07d 2: b8 03 00 00 00 mov $0x3,%eax Code; c01db082 7: f0 0f ab 42 18 lock bts %eax,0x18(%edx) Code; c01db087 c: 0f b7 42 0c movzwl 0xc(%edx),%eax Code; c01db08b 10: 66 89 42 14 mov %ax,0x14(%edx) More info: Linux version 2.4.9-31SGI_XFS_1.1 (dizzy@us) (gcc version 2.95.3 20010315 (release)) #1 SMP Its a -custom compiled version. We had it running for 33 days with no problems at all (until we rebooted for a hw upgrade) on the same machine doing the same thing. Please tell me what to do couse I have a bdflush process which shows to be in a Z(ombie) state and I dont know if this can corrupt my data (althought the system seems to be running ok). ps ax| head PID TTY STAT TIME COMMAND 1 ? S 0:07 init [3] 2 ? SW 0:00 [keventd] 3 ? RWN 0:12 [ksoftirqd_CPU0] 4 ? SWN 0:14 [ksoftirqd_CPU1] 5 ? SW 6:02 [kswapd] 6 ? SW 0:00 [kreclaimd] 7 ? Z 9:20 [bdflush ] 8 ? SW 83:42 [kupdated] 9 ? SW 0:15 [pagebuf_daemon] However recently it started to have problems. The first one was a strange "crash". It responded to ping and trying to connect to its services returned "connection established" but nothing else worked. Not even a new SSH session. I even filtered all the traffic to it from a upstream router and allowed only my machine , didnt got any luck. Trying to put a console on it didnt worked (the screen remained blank). The second problem was 3 days ago when one of our httpd servers died and every I couldnt restart it couse the kernel said "address already in use" althought the netstat command said there is no other process listening there (I even waited for 2 hours). This second problem I have hit it with 2.4.9-13 and 2.4.9-21 too but very rare (3 months interval). Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Tue Jun 18 11:52:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IIqknC029916 for ; Tue, 18 Jun 2002 11:52:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IIqkVL029915 for linux-xfs-outgoing; Tue, 18 Jun 2002 11:52:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IIqMnC029886 for ; Tue, 18 Jun 2002 11:52:23 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5IIt0g5061248; Tue, 18 Jun 2002 14:55:01 -0400 Received: from chavez.austin.ibm.com (chavez.austin.ibm.com [9.53.216.228]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5IIswF23474; Tue, 18 Jun 2002 14:54:58 -0400 Subject: Re: XFS and I/O alignment From: Luciano Chavez To: Steve Lord Cc: linux-xfs@oss.sgi.com, evms-devel@lists.sourceforge.net In-Reply-To: <1024423467.1392.50.camel@jen.americas.sgi.com> References: <1024422375.30888.142.camel@chavez> <1024423467.1392.50.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 18 Jun 2002 13:52:35 -0500 Message-Id: <1024426356.30887.150.camel@chavez> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.4 required=5.0 tests=IN_REP_TO,FROM_ENDS_IN_NUMS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 13:04, Steve Lord wrote: > On Tue, 2002-06-18 at 12:46, Luciano Chavez wrote: > > Hello, > > > > Recently on the EVMS mailing list, we had a gentlemen report a problem > > using Linux XFS 1.1 on a RAID5 storage object (Linux MD compatibility > > storage object). See > > http://sourceforge.net/mailarchive/forum.php?thread_id=799287&forum_id=2003 for the initial post. > > > > After some research I found that moving the internal log to another > > device worked around the problem. > > > > In short the problem appears to be related to I/O requests of 4K in > > length coming in on devices sensitive to alignment such as striped LVs > > or MD devices (specifically when these unaligned I/O requests cross > > boundaries like outside a chunksize). This problem should also manifest > > itself on non-striped entities such as fragmented LVs where a PE may get > > an unaligned I/O request that may span into a PE corresponding to a > > different LV. > > > > Also, the problem manifested itself most easily with striped devices. I > > found explanations under man mkfs.xfs of some options specific to > > striping so I experimented. Below is the output of the several mkfs.xfs > > attempts on a RAID 5 storage object composed of 6 partitions. > > > > root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 > > meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 > > blks > > data = bsize=4096 blocks=250880, imaxpct=25 > > = sunit=0 swidth=0 blks, unwritten=0 > > naming =version 2 bsize=4096 > > log =internal log bsize=4096 blocks=1200 > > realtime =none extsz=65536 blocks=0, rtextents=0 > > root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 -d sunit=8,swidth=40 > > meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 > > blks > > data = bsize=4096 blocks=250880, imaxpct=25 > > = sunit=1 swidth=5 blks, unwritten=0 > > naming =version 2 bsize=4096 > > log =internal log bsize=4096 blocks=1200 > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > root@gunslinger ~ # mkfs.xfs -f /dev/evms/md/md0 -d su=32768,sw=5 > > meta-data=/dev/evms/md/md0 isize=256 agcount=8, agsize=31360 > > blks > > data = bsize=4096 blocks=250880, imaxpct=25 > > = sunit=8 swidth=40 blks, > > unwritten=0 > > naming =version 2 bsize=4096 > > log =internal log bsize=4096 blocks=1200 > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > None of these helped. Not even specifying the same option on the mount. > > I still ended up with unaligned I/O coming in and crossing chunksize > > stripe boundaries essentially corrupting data. I also tried the mkfs.xfs > > options set to sunit=64,swidth=320 which produced sunit=8 and swidth=40 > > on output and still didn't help. > > > > I noticed that xfsprogs libdisk source files make tests of the device to > > see if it is a MD or LV striped device to automatically set the sunit > > and swidth values in your superblock to provide proper alignment on log > > I/O for example. But in my attempts to isolate this, there also must be > > a mount time check somewhere to determine whether to use these since > > formatting it correctly and mounting it with these options using the > > EVMS MD plug-in, they don't seem to get honored. > > > > I would appreciate any help the XFS developers could offer in allowing > > XFS to work on top of block devices sensitive to alignment under Linux. > > > > Please cross-post any responses to the evms-devel@lists.sourceforge.net > > so that others not subscribed to the linux-xfs list can see them. > > > > We (EVMS) will offer any assistance we can as we would like to see > > customers using XFS and EVMS together seamlessly and happily on their > > enterprise systems. > > > > -- > > regards, > > > > Luciano Chavez > > > > lnx1138@us.ibm.com > > http://evms.sourceforge.net > > Hi, > > The answer to this problem is sitting on my workstation right now, and > I am trying to decide if pushing it out into the world just before I > leave for OLS followed by a week's vacation is a good idea or not. > > The stripe alignment code in xfs does not apply to the log, the log is > written in chunks of upto 32K which can be any multiple of 512 bytes and > can start on any 512 byte boundary. The only 'safe' way now to make this > work with volumes where that can end up crossing device boundaries is to > do all the I/O in 512 byte buffer heads. Which as you are probably aware > is not the best thing in the world to do from a cpu and memory usage > standpoint. This is why moving the log to a different device made the > problem go away. > > A quick check of if this is going to fix things for EVMS is to take this > code in fs/xfs/pagebuf/page_buf.c: > > if ((MAJOR(dev) != LVM_BLK_MAJOR) && (MAJOR(dev) != MD_MAJOR)) { > sector = blk_length << SECTOR_SHIFT; > blk_length = 1; > } else if ((MAJOR(dev) == MD_MAJOR) && (pg_offset == 0) && > (pg_length == PAGE_CACHE_SIZE) && > (((unsigned int) bn) & BN_ALIGN_MASK) == 0) { > sector = blk_length << SECTOR_SHIFT; > blk_length = 1; > } else { > sector = SECTOR_SIZE; > } > > and replace it with: > > sector = SECTOR_SIZE; > > ------------------------ > Steve, Thank you much for the speedy reply! My page_buf.c didn't quite look like yours (I assume this was the _pagebuf_page_io routine). I made the following change to version of the source and it now appears to be working. int concat_ok=0; /* <---- I initialized this to zero */ /* if ((MAJOR(dev) != LVM_BLK_MAJOR) && (MAJOR(dev) != MD_MAJOR)) { concat_ok = 1; } else if ((MAJOR(dev) == MD_MAJOR) && (pg_offset == 0) && (pg_length == PAGE_CACHE_SIZE) && ((bn & ((page_buf_daddr_t)(PAGE_CACHE_SIZE - 1) >> 9)) == 0)) { concat_ok = 1; } else { concat_ok = 0; } */ Will the recommended code change be the permanent fix? > The code I have sitting here introduces a new log format in xfs which can > be aligned on different boundaries. It introduces new mkfs options: > > -l version=2,sunit=xxxx > > Log writes then become aligned on and padded to the stripe unit specified, > 4K is enough in most cases. You can also do larger logwrites with this code, > but that is not the issue here. > What about non-striped devices? How are they aligned now? > Steve > > p.s. LVM2 has hit exactly the same problem. > > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com > -- regards, Luciano Chavez lnx1138@us.ibm.com http://evms.sourceforge.net From owner-linux-xfs@oss.sgi.com Tue Jun 18 12:02:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IJ2GnC030173 for ; Tue, 18 Jun 2002 12:02:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IJ2Gqb030172 for linux-xfs-outgoing; Tue, 18 Jun 2002 12:02:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IJ26nC030139 for ; Tue, 18 Jun 2002 12:02:07 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA82923; Tue, 18 Jun 2002 14:04:56 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA02313; Tue, 18 Jun 2002 14:04:31 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IJ3Bh29105; Tue, 18 Jun 2002 14:03:11 -0500 Subject: Re: XFS and I/O alignment From: Steve Lord To: Luciano Chavez Cc: linux-xfs@oss.sgi.com, evms-devel@lists.sourceforge.net In-Reply-To: <1024426356.30887.150.camel@chavez> References: <1024422375.30888.142.camel@chavez> <1024423467.1392.50.camel@jen.americas.sgi.com> <1024426356.30887.150.camel@chavez> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 14:03:11 -0500 Message-Id: <1024426991.1392.55.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 13:52, Luciano Chavez wrote: > Steve, > > Thank you much for the speedy reply! My page_buf.c didn't quite look > like yours (I assume this was the _pagebuf_page_io routine). I made the > following change to version of the source and it now appears to be > working. > > int concat_ok=0; /* <---- I initialized this to zero */ > /* > if ((MAJOR(dev) != LVM_BLK_MAJOR) && (MAJOR(dev) != MD_MAJOR)) { > concat_ok = 1; > } else if ((MAJOR(dev) == MD_MAJOR) && (pg_offset == 0) && > (pg_length == PAGE_CACHE_SIZE) && > ((bn & ((page_buf_daddr_t)(PAGE_CACHE_SIZE - 1) >> > 9)) == 0)) { > concat_ok = 1; > } else { > concat_ok = 0; > } > */ > > Will the recommended code change be the permanent fix? My problem with this is the overhead it adds to the XFS metadata I/O path. My preferred solution is the version 2 log code and striping the log - and ideally mkfs would be able to tell what it was being run on and tell you to use striping. > > > The code I have sitting here introduces a new log format in xfs which can > > be aligned on different boundaries. It introduces new mkfs options: > > > > -l version=2,sunit=xxxx > > > > Log writes then become aligned on and padded to the stripe unit specified, > > 4K is enough in most cases. You can also do larger logwrites with this code, > > but that is not the issue here. > > > > What about non-striped devices? How are they aligned now? That was the any 512 byte boundary for any 512 byte length up to 32K. i.e. they are 512 byte aligned, but unless the code you commented out is turned off, or we are talking to a device type we know cannot cope with this, we will attempt to write a 4K page on a non 4K disk offset. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:03:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IK3QnC031094 for ; Tue, 18 Jun 2002 13:03:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IK3PjR031093 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:03:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from eeyore.med.wayne.edu (eeyore.med.wayne.edu [146.9.19.19]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IK3KnC031065 for ; Tue, 18 Jun 2002 13:03:21 -0700 Received: from med.wayne.edu ([146.9.4.97]) by eeyore.med.wayne.edu (8.12.2/8.12.2) with ESMTP id g5IJt3tg014726 for ; Tue, 18 Jun 2002 15:55:03 -0400 (EDT) Message-ID: <3D0F9253.DFD130D5@med.wayne.edu> Date: Tue, 18 Jun 2002 16:04:35 -0400 From: Philip Martin X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.7-10 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: RH V7.3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-5.1, required 5, EDU_IN_FROM, SUBJ_ALL_CAPS) X-Spam-Status: No, hits=1.9 required=5.0 tests=SUBJ_ALL_CAPS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Will there soon be an install XFS iso image for Red Hat V7.3? -- Philip D. Martin, Ph.D. Biochemistry & Molecular Biology Wayne State University 540 E. Canfield Detroit, MI 48201 Phone: 313-577-1506 From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:06:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IK6BnC031294 for ; Tue, 18 Jun 2002 13:06:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IK6Ber031293 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:06:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IK66nC031265 for ; Tue, 18 Jun 2002 13:06:07 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17KPHf-0006eM-00 for ; Tue, 18 Jun 2002 23:08:59 +0300 Date: Tue, 18 Jun 2002 23:08:59 +0300 To: linux-xfs@oss.sgi.com Subject: mapcheck mmap-fixer has problems.. Message-ID: <20020618200859.GA25557@banix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio X-Spam-Status: No, hits=-0.4 required=5.0 tests=SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk root@jaenoe:~ > /usr/src/xfs-cmd/mapcheck / ..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................zsh: segmentation fault /usr/src/xfs-cmd/mapcheck / That's the output from mapcheck, which i left running and went elsewhere. The machine was completely idle for that time. I tried again, and it crashes at the same point again. That output is from the second run, the first run succesfully fixed many files. From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:07:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IK7enC031457 for ; Tue, 18 Jun 2002 13:07:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IK7eaw031456 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:07:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IK7YnC031428 for ; Tue, 18 Jun 2002 13:07:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA85381; Tue, 18 Jun 2002 15:10:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA34665; Tue, 18 Jun 2002 15:10:21 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IK90110216; Tue, 18 Jun 2002 15:09:00 -0500 Subject: Re: RH V7.3 From: Steve Lord To: Philip Martin Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D0F9253.DFD130D5@med.wayne.edu> References: <3D0F9253.DFD130D5@med.wayne.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 15:09:00 -0500 Message-Id: <1024430940.1392.57.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 15:04, Philip Martin wrote: > Will there soon be an install XFS iso image for Red Hat V7.3? ftp://oss.sgi.com/projects/xfs/download/latest/installer/installer/i386/ And read this file: ftp://oss.sgi.com/projects/xfs/download/latest/installer/installer/REALLY-README Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:10:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IKA8nC031635 for ; Tue, 18 Jun 2002 13:10:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IKA8jq031634 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:10:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IKA2nC031598 for ; Tue, 18 Jun 2002 13:10:02 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA82274; Tue, 18 Jun 2002 15:12:51 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA01401; Tue, 18 Jun 2002 15:12:51 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IKBUX10235; Tue, 18 Jun 2002 15:11:30 -0500 Subject: Re: mapcheck mmap-fixer has problems.. From: Steve Lord To: Juha K Kallio Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020618200859.GA25557@banix> References: <20020618200859.GA25557@banix> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 15:11:30 -0500 Message-Id: <1024431090.1409.60.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.0 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 15:08, Juha K Kallio wrote: > root@jaenoe:~ > /usr/src/xfs-cmd/mapcheck / > ..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................zsh: > segmentation > fault /usr/src/xfs-cmd/mapcheck / > > That's the output from mapcheck, which i left running and went > elsewhere. The machine was completely idle for that time. I tried again, > and it crashes at the same point again. That output is from the second > run, the first run succesfully fixed many files. Edit the source, set verbose=1, this should print out filenames as it works, possibly you have a file with a hole at the end. Also, running from / will traverse into things like /proc which might not be a good idea. The program is rather basic, and will not detect it is crossing into other filesystems etc. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:13:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IKDMnC031807 for ; Tue, 18 Jun 2002 13:13:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IKDMBt031806 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:13:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IKBwnC031772 for ; Tue, 18 Jun 2002 13:11:59 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA82285 for ; Tue, 18 Jun 2002 15:14:48 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA62215 for ; Tue, 18 Jun 2002 15:14:48 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IKDSu10367; Tue, 18 Jun 2002 15:13:28 -0500 Message-Id: <200206182013.g5IKDSu10367@jen.americas.sgi.com> Date: Tue, 18 Jun 2002 15:13:28 -0500 Subject: TAKE - merge up to 2.5.22 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 18 13:10:28 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:121873a linux/drivers/usb/input/aiptek.c - 1.1 linux/arch/x86_64/lib/io.c - 1.1 linux/arch/x86_64/pci/x86-64.c - 1.1 linux/arch/x86_64/lib/csum-wrappers.c - 1.1 linux/arch/x86_64/lib/csum-partial.c - 1.1 linux/arch/x86_64/lib/csum-copy.S - 1.1 linux/arch/x86_64/lib/copy_user.S - 1.1 linux/arch/x86_64/lib/copy_page.S - 1.1 linux/arch/x86_64/lib/clear_page.S - 1.1 linux/arch/x86_64/pci/changelog - 1.1 linux/drivers/net/irda/act200l.c - 1.1 linux/arch/x86_64/pci/irq.c - 1.1 linux/arch/arm/mach-sa1100/leds-badge4.c - 1.1 linux/include/linux/root_dev.h - 1.1 linux/arch/x86_64/pci/legacy.c - 1.1 linux/drivers/net/irda/ma600.c - 1.1 linux/arch/x86_64/pci/pci.h - 1.1 linux/arch/x86_64/lib/memcpy.S - 1.1 linux/arch/x86_64/lib/memmove.c - 1.1 linux/arch/arm/mm/fault.h - 1.1 linux/arch/x86_64/lib/memset.S - 1.1 linux/arch/arm/mm/proc-arm2_3.S - 1.1 linux/arch/x86_64/pci/Makefile - 1.1 linux/arch/arm/mm/proc-arm6_7.S - 1.1 linux/arch/x86_64/pci/fixup.c - 1.1 linux/arch/x86_64/pci/direct.c - 1.1 linux/arch/x86_64/pci/acpi.c - 1.1 linux/arch/x86_64/pci/common.c - 1.1 linux/scripts/Makefile - 1.7 linux/net/socket.c - 1.35 linux/net/irda/wrapper.c - 1.11 linux/net/irda/irttp.c - 1.17 linux/net/irda/irlmp_event.c - 1.16 linux/net/irda/irlmp.c - 1.19 linux/net/irda/irlap_frame.c - 1.16 linux/net/irda/irlap_event.c - 1.23 linux/net/irda/irlap.c - 1.18 linux/net/irda/irias_object.c - 1.12 linux/net/irda/iriap_event.c - 1.9 linux/net/irda/iriap.c - 1.15 linux/net/irda/irda_device.c - 1.26 linux/net/irda/af_irda.c - 1.37 linux/net/ipv4/ipconfig.c - 1.30 linux/net/Makefile - 1.20 linux/mm/vmalloc.c - 1.41 linux/mm/swapfile.c - 1.59 linux/mm/page_io.c - 1.25 linux/mm/mmap.c - 1.52 linux/mm/memory.c - 1.84 linux/mm/filemap.c - 1.122 linux/lib/vsprintf.c - 1.17 linux/kernel/sched.c - 1.71 linux/kernel/ksyms.c - 1.149 linux/kernel/fork.c - 1.59 linux/include/scsi/scsi.h - 1.7 linux/include/net/irda/discovery.h - 1.7 linux/include/linux/vmalloc.h - 1.17 linux/include/linux/types.h - 1.8 linux/include/linux/sched.h - 1.72 linux/include/linux/list.h - 1.13 linux/include/linux/kdev_t.h - 1.6 linux/include/linux/irda.h - 1.12 linux/include/linux/fs.h - 1.175 linux/include/linux/blkdev.h - 1.60 linux/include/linux/blk.h - 1.36 linux/include/asm-sparc64/pgtable.h - 1.37 linux/include/asm-sparc64/mmu_context.h - 1.18 linux/include/asm-ppc/spinlock.h - 1.15 linux/include/asm-i386/system.h - 1.26 linux/include/asm-i386/spinlock.h - 1.25 linux/include/asm-i386/processor.h - 1.40 linux/include/asm-i386/locks.h - 1.4 linux/include/asm-arm/system.h - 1.19 linux/include/asm-arm/bitops.h - 1.12 linux/include/asm-arm/atomic.h - 1.11 linux/fs/super.c - 1.89 linux/fs/stat.c - 1.26 linux/fs/pipe.c - 1.31 linux/fs/open.c - 1.40 linux/fs/nfsd/nfsxdr.c - 1.16 linux/fs/nfsd/nfs3xdr.c - 1.28 linux/fs/nfsd/export.c - 1.37 linux/fs/nfs/nfsroot.c - 1.16 linux/fs/nfs/inode.c - 1.46 linux/fs/nfs/file.c - 1.33 linux/fs/locks.c - 1.25 linux/fs/inode.c - 1.77 linux/fs/hfs/inode.c - 1.18 linux/fs/ext2/inode.c - 1.49 linux/fs/dquot.c - 1.58 linux/fs/coda/inode.c - 1.26 linux/fs/buffer.c - 1.124 linux/fs/block_dev.c - 1.49 linux/fs/adfs/map.c - 1.11 linux/fs/Makefile - 1.59 linux/drivers/video/Makefile - 1.40 linux/drivers/usb/Makefile - 1.55 linux/drivers/scsi/tmscsim.c - 1.17 linux/drivers/scsi/t128.c - 1.10 linux/drivers/scsi/sym53c8xx.c - 1.32 linux/drivers/scsi/st.c - 1.44 linux/drivers/scsi/sr.h - 1.8 linux/drivers/scsi/sr.c - 1.44 linux/drivers/scsi/seagate.c - 1.18 linux/drivers/scsi/sd.h - 1.7 linux/drivers/scsi/sd.c - 1.61 linux/drivers/scsi/scsi_syms.c - 1.18 linux/drivers/scsi/scsi_queue.c - 1.13 linux/drivers/scsi/scsi_ioctl.c - 1.23 linux/drivers/scsi/scsi_error.c - 1.26 linux/drivers/scsi/scsi.h - 1.29 linux/drivers/scsi/scsi.c - 1.55 linux/drivers/scsi/pas16.c - 1.11 linux/drivers/scsi/ncr53c8xx.c - 1.25 linux/drivers/scsi/mac_scsi.c - 1.10 linux/drivers/scsi/ide-scsi.c - 1.38 linux/drivers/scsi/g_NCR5380.c - 1.14 linux/drivers/scsi/dtc.c - 1.10 linux/drivers/scsi/constants.h - 1.3 linux/drivers/scsi/constants.c - 1.10 linux/drivers/scsi/atari_scsi.c - 1.10 linux/drivers/scsi/aha152x.c - 1.29 linux/drivers/scsi/NCR53C9x.c - 1.15 linux/drivers/scsi/Makefile - 1.37 linux/drivers/scsi/Config.in - 1.29 linux/drivers/scsi/AM53C974.c - 1.15 linux/drivers/scsi/53c7xx.c - 1.17 linux/drivers/scsi/53c7,8xx.c - 1.20 linux/drivers/sbus/audio/dbri.c - 1.14 linux/drivers/sbus/Makefile - 1.8 linux/drivers/net/ni65.c - 1.14 linux/drivers/net/irda/Makefile - 1.19 linux/drivers/net/irda/Config.in - 1.14 linux/drivers/net/hamradio/Config.in - 1.7 linux/drivers/net/eexpress.c - 1.19 linux/drivers/net/eepro.c - 1.25 linux/drivers/net/atarilance.c - 1.11 linux/drivers/net/Makefile - 1.60 linux/drivers/isdn/sc/init.c - 1.7 linux/drivers/isdn/icn/icn.c - 1.19 linux/drivers/isdn/Makefile - 1.15 linux/drivers/char/sysrq.c - 1.25 linux/drivers/char/stallion.c - 1.22 linux/drivers/char/istallion.c - 1.22 linux/drivers/char/isicom.c - 1.19 linux/drivers/char/Makefile - 1.62 linux/drivers/char/Config.in - 1.60 linux/drivers/cdrom/sonycd535.c - 1.23 linux/drivers/cdrom/sjcd.c - 1.19 linux/drivers/cdrom/sbpcd.c - 1.25 linux/drivers/cdrom/optcd.c - 1.20 linux/drivers/cdrom/mcdx.c - 1.16 linux/drivers/cdrom/mcd.c - 1.19 linux/drivers/cdrom/gscd.c - 1.19 linux/drivers/cdrom/cm206.c - 1.20 linux/drivers/cdrom/cdu31a.c - 1.18 linux/drivers/cdrom/aztcd.c - 1.21 linux/drivers/block/z2ram.c - 1.17 linux/drivers/block/xd.c - 1.38 linux/drivers/block/swim3.c - 1.17 linux/drivers/block/rd.c - 1.53 linux/drivers/block/ps2esdi.c - 1.40 linux/drivers/block/paride/pf.c - 1.26 linux/drivers/block/paride/pd.c - 1.31 linux/drivers/block/paride/pcd.c - 1.21 linux/drivers/block/nbd.c - 1.40 linux/drivers/block/loop.c - 1.58 linux/drivers/block/ll_rw_blk.c - 1.105 linux/drivers/block/genhd.c - 1.27 linux/drivers/block/floppy.c - 1.41 linux/drivers/block/ataflop.c - 1.24 linux/drivers/block/amiflop.c - 1.25 linux/drivers/block/acsi.c - 1.31 linux/drivers/acorn/scsi/oak.c - 1.10 linux/drivers/acorn/scsi/ecoscsi.c - 1.11 linux/drivers/acorn/scsi/cumana_1.c - 1.8 linux/drivers/acorn/scsi/acornscsi.c - 1.16 linux/drivers/acorn/block/mfmhd.c - 1.25 linux/drivers/acorn/block/fd1772.c - 1.18 linux/drivers/Makefile - 1.34 linux/arch/sparc64/solaris/fs.c - 1.19 linux/arch/sparc64/mm/init.c - 1.44 linux/arch/sparc64/kernel/sys_sunos32.c - 1.39 linux/arch/sparc64/kernel/sys_sparc32.c - 1.52 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.44 linux/arch/sparc64/kernel/smp.c - 1.44 linux/arch/sparc64/kernel/setup.c - 1.29 linux/arch/sparc64/kernel/dtlb_base.S - 1.13 linux/arch/sparc64/kernel/dtlb_backend.S - 1.11 linux/arch/sparc/kernel/setup.c - 1.22 linux/arch/ppc/lib/locks.c - 1.12 linux/arch/ppc/kernel/setup.c - 1.44 linux/arch/ppc/kernel/ppc_ksyms.c - 1.43 linux/arch/mips/kernel/setup.c - 1.13 linux/arch/m68k/atari/stram.c - 1.16 linux/arch/i386/kernel/setup.c - 1.79 linux/arch/i386/kernel/process.c - 1.50 linux/arch/i386/kernel/irq.c - 1.42 linux/arch/i386/kernel/ioport.c - 1.4 linux/arch/i386/kernel/io_apic.c - 1.38 linux/arch/i386/kernel/entry.S - 1.58 linux/arch/i386/kernel/apm.c - 1.45 linux/arch/arm/mm/proc-arm6,7.S - 1.23 linux/arch/arm/mm/proc-arm2,3.S - 1.14 linux/arch/arm/mm/fault-common.c - 1.22 linux/arch/arm/mm/fault-armv.c - 1.26 linux/arch/arm/mm/Makefile - 1.18 linux/arch/arm/kernel/setup.c - 1.32 linux/arch/alpha/kernel/smc37c669.c - 1.5 linux/arch/alpha/kernel/setup.c - 1.29 linux/Rules.make - 1.25 linux/Makefile - 1.203 linux/MAINTAINERS - 1.109 linux/Documentation/Changes - 1.52 linux/include/linux/ide.h - 1.52 linux/drivers/block/blkpg.c - 1.23 linux/drivers/block/cpqarray.c - 1.48 linux/drivers/net/hamradio/yam.c - 1.19 linux/fs/partitions/check.c - 1.42 linux/fs/partitions/acorn.c - 1.16 linux/arch/i386/kernel/i8259.c - 1.30 linux/net/atm/signaling.c - 1.8 linux/net/atm/resources.c - 1.9 linux/net/atm/proc.c - 1.15 linux/net/atm/lec.c - 1.15 linux/net/atm/clip.c - 1.12 linux/include/linux/atmdev.h - 1.11 linux/drivers/block/DAC960.c - 1.48 linux/arch/sh/kernel/setup.c - 1.20 linux/net/irda/parameters.c - 1.10 linux/net/irda/ircomm/ircomm_tty.c - 1.19 linux/net/irda/ircomm/ircomm_core.c - 1.14 linux/include/asm-i386/pci.h - 1.17 linux/drivers/pcmcia/cardbus.c - 1.21 linux/drivers/block/swim_iop.c - 1.13 linux/drivers/pcmcia/ti113x.h - 1.7 linux/include/linux/spinlock.h - 1.18 linux/drivers/net/pcmcia/ray_cs.c - 1.24 linux/drivers/net/wan/Config.in - 1.16 linux/arch/ppc/kernel/m8xx_setup.c - 1.23 linux/arch/i386/kernel/smpboot.c - 1.40 linux/include/linux/pci_ids.h - 1.68 linux/drivers/net/wan/sdlamain.c - 1.12 linux/drivers/net/wan/sdla_fr.c - 1.19 linux/fs/bfs/inode.c - 1.26 linux/drivers/scsi/sun3_scsi.c - 1.11 linux/drivers/pci/pci.ids - 1.50 linux/drivers/scsi/scsi_merge.c - 1.39 linux/drivers/scsi/scsi_lib.c - 1.45 linux/drivers/i2c/i2c-core.c - 1.14 linux/drivers/sbus/char/jsflash.c - 1.18 linux/drivers/pcmcia/yenta.c - 1.31 linux/include/asm-sparc64/pgalloc.h - 1.21 linux/arch/i386/kernel/mpparse.c - 1.21 linux/drivers/scsi/scsi_scan.c - 1.25 linux/arch/ia64/dig/setup.c - 1.9 linux/drivers/usb/serial/usb-serial.h - 1.20 linux/drivers/ide/via82cxxx.c - 1.30 linux/drivers/ide/trm290.c - 1.11 linux/drivers/ide/sl82c105.c - 1.13 linux/drivers/ide/sis5513.c - 1.21 linux/drivers/ide/piix.c - 1.26 linux/drivers/ide/pdc4030.c - 1.18 linux/drivers/ide/pdc202xx.c - 1.23 linux/drivers/ide/opti621.c - 1.12 linux/drivers/ide/ns87415.c - 1.10 linux/drivers/ide/ide.c - 1.56 linux/drivers/ide/ide-tape.c - 1.29 linux/drivers/ide/ide-pmac.c - 1.16 linux/drivers/ide/ide-floppy.c - 1.27 linux/drivers/ide/ide-disk.c - 1.38 linux/drivers/ide/ide-cs.c - 1.11 linux/drivers/ide/ide-cd.c - 1.38 linux/drivers/ide/icside.c - 1.18 linux/drivers/ide/hpt366.c - 1.20 linux/drivers/ide/hpt34x.c - 1.14 linux/drivers/ide/hd.c - 1.23 linux/drivers/ide/cy82c693.c - 1.13 linux/drivers/ide/cmd64x.c - 1.16 linux/drivers/ide/alim15x3.c - 1.18 linux/drivers/ide/Config.in - 1.27 linux/drivers/net/wan/comx-hw-comx.c - 1.8 linux/drivers/scsi/dmx3191d.c - 1.9 linux/fs/ramfs/inode.c - 1.25 linux/drivers/usb/serial/keyspan_pda.c - 1.27 linux/drivers/usb/serial/ftdi_sio.c - 1.37 linux/drivers/usb/serial/usbserial.c - 1.37 linux/drivers/usb/serial/whiteheat.c - 1.26 linux/drivers/usb/serial/visor.c - 1.35 linux/drivers/ide/aec62xx.c - 1.11 linux/drivers/usb/serial/omninet.c - 1.25 linux/drivers/usb/serial/digi_acceleport.c - 1.28 linux/drivers/s390/Makefile - 1.7 linux/arch/s390/kernel/setup.c - 1.8 linux/fs/xfs/linux/xfs_vfs.c - 1.38 linux/fs/xfs/linux/xfs_linux.h - 1.75 linux/fs/xfs/linux/xfs_super.c - 1.194 linux/drivers/usb/storage/debug.c - 1.9 linux/drivers/usb/serial/keyspan.h - 1.11 linux/drivers/acpi/tables/tbutils.c - 1.11 linux/drivers/acpi/resources/rsutils.c - 1.10 linux/drivers/acpi/resources/rscreate.c - 1.10 linux/drivers/acpi/resources/rscalc.c - 1.10 linux/drivers/acpi/parser/psopcode.c - 1.11 linux/drivers/acpi/namespace/nsutils.c - 1.11 linux/drivers/acpi/namespace/nssearch.c - 1.12 linux/drivers/acpi/namespace/nsobject.c - 1.11 linux/fs/jffs/inode-v23.c - 1.27 linux/drivers/acpi/namespace/nseval.c - 1.12 linux/drivers/acpi/namespace/nsaccess.c - 1.12 linux/fs/jffs/intrep.c - 1.14 linux/fs/jffs/jffs_fm.c - 1.8 linux/fs/jffs/jffs_fm.h - 1.4 linux/arch/i386/kernel/i387.c - 1.10 linux/drivers/acpi/include/acpixf.h - 1.12 linux/drivers/acpi/include/acobject.h - 1.11 linux/drivers/acpi/hardware/hwregs.c - 1.12 linux/drivers/acpi/events/evxface.c - 1.11 linux/drivers/acpi/events/evrgnini.c - 1.10 linux/drivers/acpi/events/evregion.c - 1.12 linux/drivers/acpi/dispatcher/dswstate.c - 1.11 linux/drivers/acpi/dispatcher/dswexec.c - 1.11 linux/drivers/acpi/dispatcher/dsutils.c - 1.11 linux/drivers/acpi/dispatcher/dsopcode.c - 1.12 linux/drivers/acpi/dispatcher/dsobject.c - 1.12 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.10 linux/drivers/acpi/Makefile - 1.15 linux/drivers/mtd/Makefile - 1.10 linux/drivers/mtd/ftl.c - 1.18 linux/drivers/mtd/mtdblock.c - 1.17 linux/fs/smbfs/smb_debug.h - 1.3 linux/drivers/media/video/tda9875.c - 1.9 linux/drivers/media/radio/Config.in - 1.10 linux/drivers/media/Makefile - 1.5 linux/drivers/isdn/eicon/pc.h - 1.5 linux/drivers/input/Makefile - 1.5 linux/drivers/md/raid1.c - 1.20 linux/arch/arm/mach-sa1100/Makefile - 1.12 linux/arch/arm/mach-sa1100/leds.c - 1.8 linux/drivers/acpi/include/acconfig.h - 1.12 linux/drivers/acpi/include/acinterp.h - 1.11 linux/drivers/acpi/include/acmacros.h - 1.10 linux/drivers/acpi/include/acoutput.h - 1.8 linux/drivers/acpi/namespace/nsdump.c - 1.8 linux/drivers/md/linear.c - 1.8 linux/drivers/md/md.c - 1.46 linux/drivers/md/raid0.c - 1.8 linux/drivers/usb/serial/belkin_sa.c - 1.20 linux/drivers/usb/serial/mct_u232.c - 1.20 linux/drivers/usb/serial/empeg.c - 1.24 linux/arch/i386/kernel/dmi_scan.c - 1.18 linux/arch/parisc/hpux/sys_hpux.c - 1.3 linux/mm/shmem.c - 1.39 linux/drivers/scsi/osst.c - 1.14 linux/fs/reiserfs/stree.c - 1.25 linux/fs/reiserfs/super.c - 1.25 linux/fs/reiserfs/tail_conversion.c - 1.17 linux/fs/reiserfs/prints.c - 1.17 linux/fs/reiserfs/namei.c - 1.24 linux/fs/reiserfs/journal.c - 1.30 linux/fs/reiserfs/ioctl.c - 1.8 linux/fs/reiserfs/inode.c - 1.33 linux/fs/reiserfs/fix_node.c - 1.22 linux/fs/reiserfs/file.c - 1.12 linux/fs/reiserfs/dir.c - 1.15 linux/include/linux/reiserfs_fs.h - 1.25 linux/include/linux/reiserfs_fs_sb.h - 1.13 linux/fs/reiserfs/bitmap.c - 1.17 linux/arch/s390x/kernel/setup.c - 1.7 linux/arch/cris/drivers/ide.c - 1.15 linux/drivers/s390/block/xpram.c - 1.19 linux/include/asm-cris/locks.h - 1.2 linux/drivers/usb/serial/io_tables.h - 1.6 linux/arch/arm/mach-integrator/pci_v3.c - 1.9 linux/drivers/net/wan/dscc4.c - 1.13 linux/arch/mips/ite-boards/generic/it8172_setup.c - 1.3 linux/drivers/net/irda/irda-usb.c - 1.18 linux/Documentation/usb/philips.txt - 1.6 linux/drivers/mtd/nftlcore.c - 1.18 linux/drivers/mtd/mtdblock_ro.c - 1.10 linux/drivers/acpi/executer/exstore.c - 1.7 linux/drivers/acpi/utilities/utobject.c - 1.6 linux/drivers/acpi/utilities/utmisc.c - 1.6 linux/drivers/acpi/utilities/utglobal.c - 1.7 linux/drivers/acpi/utilities/uteval.c - 1.7 linux/drivers/acpi/utilities/utdelete.c - 1.7 linux/drivers/acpi/utilities/utcopy.c - 1.7 linux/drivers/acpi/include/acutils.h - 1.6 linux/drivers/acpi/include/platform/acenv.h - 1.7 linux/drivers/acpi/include/platform/aclinux.h - 1.6 linux/drivers/acpi/debugger/dbcmds.c - 1.6 linux/drivers/acpi/debugger/dbdisply.c - 1.7 linux/drivers/acpi/debugger/dbstats.c - 1.6 linux/drivers/acpi/executer/exutils.c - 1.6 linux/drivers/acpi/executer/exstoren.c - 1.6 linux/drivers/acpi/executer/exconfig.c - 1.7 linux/drivers/acpi/executer/exconvrt.c - 1.7 linux/drivers/acpi/executer/excreate.c - 1.6 linux/drivers/acpi/executer/exdump.c - 1.7 linux/drivers/acpi/executer/exfield.c - 1.6 linux/drivers/acpi/executer/exfldio.c - 1.7 linux/drivers/acpi/executer/exmisc.c - 1.6 linux/drivers/acpi/executer/exprep.c - 1.7 linux/drivers/acpi/executer/exresnte.c - 1.8 linux/drivers/acpi/executer/exresolv.c - 1.7 linux/drivers/acpi/executer/exresop.c - 1.7 linux/drivers/usb/serial/cyberjack.c - 1.14 linux/drivers/usb/serial/pl2303.c - 1.16 linux/drivers/net/wan/farsync.c - 1.8 linux/drivers/ide/serverworks.c - 1.12 linux/drivers/ide/it8172.c - 1.9 linux/drivers/ide/amd74xx.c - 1.13 linux/arch/arm/mach-sa1100/leds.h - 1.6 linux/arch/mips/au1000/pb1000/setup.c - 1.2 linux/arch/mips/ddb5xxx/ddb5477/setup.c - 1.2 linux/drivers/net/ns83820.c - 1.12 linux/drivers/scsi/53c700.c - 1.7 linux/drivers/scsi/NCR_D700.c - 1.3 linux/drivers/scsi/lasi700.c - 1.4 linux/fs/jffs2/super.c - 1.12 linux/drivers/md/multipath.c - 1.8 linux/include/asm-sparc64/tlb.h - 1.3 linux/include/asm-generic/tlb.h - 1.6 linux/drivers/usb/serial/ir-usb.c - 1.15 linux/fs/quota.c - 1.14 linux/drivers/message/i2o/i2o_block.c - 1.16 linux/drivers/net/8139cp.c - 1.12 linux/drivers/acpi/executer/exoparg6.c - 1.3 linux/drivers/acpi/executer/exoparg3.c - 1.4 linux/drivers/acpi/executer/exoparg2.c - 1.5 linux/drivers/acpi/executer/exoparg1.c - 1.5 linux/drivers/scsi/sym53c8xx_2/sym_glue.h - 1.5 linux/fs/ext3/ialloc.c - 1.12 linux/fs/ext3/namei.c - 1.9 linux/fs/ext3/super.c - 1.18 linux/drivers/hotplug/pci_hotplug_util.c - 1.2 linux/drivers/hotplug/pci_hotplug_core.c - 1.11 linux/fs/reiserfs/procfs.c - 1.9 linux/fs/bio.c - 1.14 linux/init/do_mounts.c - 1.14 linux/include/linux/namespace.h - 1.3 linux/drivers/usb/serial/ipaq.c - 1.9 linux/drivers/usb/serial/kl5kusb105.c - 1.8 linux/arch/arm/mm/alignment.c - 1.3 linux/arch/arm/mach-iop310/iop310-pci.c - 1.4 linux/drivers/ide/ide-taskfile.c - 1.15 linux/arch/i386/Config.help - 1.10 linux/drivers/ide/Config.help - 1.14 linux/drivers/net/irda/Config.help - 1.3 linux/drivers/pnp/pnpbios_proc.c - 1.3 linux/Documentation/filesystems/porting - 1.10 linux/sound/synth/Makefile - 1.6 linux/sound/pci/emu10k1/emuproc.c - 1.5 linux/sound/pci/emu10k1/emupcm.c - 1.5 linux/sound/pci/emu10k1/emumpu401.c - 1.3 linux/sound/pci/emu10k1/emumixer.c - 1.5 linux/sound/pci/emu10k1/emufx.c - 1.4 linux/sound/pci/Makefile - 1.6 linux/arch/ppc/platforms/adir_setup.c - 1.2 linux/arch/ppc/platforms/chrp_setup.c - 1.5 linux/arch/ppc/platforms/ev64260_setup.c - 1.2 linux/arch/ppc/platforms/gemini_setup.c - 1.2 linux/arch/ppc/platforms/iSeries_setup.c - 1.2 linux/arch/ppc/platforms/k2_setup.c - 1.3 linux/arch/ppc/platforms/lopec_setup.c - 1.5 linux/arch/ppc/platforms/mcpn765_setup.c - 1.4 linux/arch/ppc/platforms/menf1_setup.c - 1.3 linux/arch/ppc/platforms/mvme5100_setup.c - 1.2 linux/arch/ppc/platforms/pcore_setup.c - 1.2 linux/arch/ppc/platforms/pmac_setup.c - 1.4 linux/arch/ppc/platforms/powerpmc250.c - 1.2 linux/arch/ppc/platforms/pplus_setup.c - 1.4 linux/arch/ppc/platforms/prep_setup.c - 1.5 linux/arch/ppc/platforms/prpmc750_setup.c - 1.2 linux/arch/ppc/platforms/prpmc800_setup.c - 1.2 linux/arch/ppc/platforms/sandpoint_setup.c - 1.4 linux/arch/ppc/platforms/spruce_setup.c - 1.2 linux/arch/ppc/platforms/zx4500_setup.c - 1.2 linux/arch/x86_64/Makefile - 1.4 linux/arch/x86_64/boot/setup.S - 1.3 linux/arch/x86_64/boot/video.S - 1.3 linux/arch/x86_64/config.in - 1.8 linux/arch/x86_64/defconfig - 1.9 linux/arch/x86_64/ia32/Makefile - 1.5 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.7 linux/arch/x86_64/ia32/ia32_signal.c - 1.4 linux/arch/x86_64/ia32/ia32entry.S - 1.3 linux/arch/x86_64/ia32/sys_ia32.c - 1.4 linux/arch/x86_64/kernel/Makefile - 1.5 linux/arch/x86_64/kernel/early_printk.c - 1.4 linux/arch/x86_64/kernel/entry.S - 1.5 linux/arch/x86_64/kernel/head.S - 1.4 linux/arch/x86_64/kernel/head64.c - 1.3 linux/arch/x86_64/kernel/i387.c - 1.4 linux/arch/x86_64/kernel/i8259.c - 1.3 linux/arch/x86_64/kernel/irq.c - 1.3 linux/arch/x86_64/kernel/ldt.c - 1.3 linux/arch/x86_64/kernel/mpparse.c - 1.3 linux/arch/x86_64/kernel/msr.c - 1.3 linux/arch/x86_64/kernel/mtrr.c - 1.4 linux/arch/x86_64/kernel/nmi.c - 1.2 linux/arch/x86_64/kernel/pci-irq.c - 1.3 linux/arch/x86_64/kernel/pci-pc.c - 1.3 linux/arch/x86_64/kernel/pci-x86_64.c - 1.3 linux/arch/x86_64/kernel/pci-x86_64.h - 1.3 linux/arch/x86_64/kernel/process.c - 1.5 linux/arch/x86_64/kernel/setup.c - 1.3 linux/arch/x86_64/kernel/setup64.c - 1.3 linux/arch/x86_64/kernel/signal.c - 1.5 linux/arch/x86_64/kernel/smp.c - 1.4 linux/arch/x86_64/kernel/smpboot.c - 1.5 linux/arch/x86_64/kernel/sys_x86_64.c - 1.4 linux/arch/x86_64/kernel/time.c - 1.4 linux/arch/x86_64/kernel/traps.c - 1.4 linux/arch/x86_64/kernel/vsyscall.c - 1.4 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.5 linux/arch/x86_64/lib/Makefile - 1.5 linux/arch/x86_64/lib/checksum_copy.S - 1.2 linux/arch/x86_64/lib/generic-checksum.c - 1.2 linux/arch/x86_64/lib/mmx.c - 1.4 linux/arch/x86_64/lib/rwsem_thunk.S - 1.2 linux/arch/x86_64/lib/usercopy.c - 1.2 linux/arch/x86_64/mm/extable.c - 1.2 linux/arch/x86_64/mm/fault.c - 1.5 linux/arch/x86_64/mm/init.c - 1.6 linux/arch/x86_64/mm/ioremap.c - 1.5 linux/arch/x86_64/tools/offset.c - 1.4 linux/arch/x86_64/vmlinux.lds - 1.4 linux/sound/isa/Makefile - 1.5 linux/sound/i2c/Makefile - 1.6 linux/sound/drivers/Makefile - 1.5 linux/sound/core/seq/seq_queue.h - 1.6 linux/sound/core/seq/seq_queue.c - 1.6 linux/sound/core/seq/seq_clientmgr.h - 1.2 linux/sound/core/seq/seq_clientmgr.c - 1.5 linux/sound/core/seq/Makefile - 1.9 linux/sound/core/rawmidi.c - 1.5 linux/sound/core/Makefile - 1.9 linux/sound/Makefile - 1.8 linux/include/asm-x86_64/rwsem.h - 1.4 linux/include/asm-x86_64/ptrace.h - 1.3 linux/include/asm-x86_64/processor.h - 1.4 linux/include/asm-x86_64/pgtable.h - 1.6 linux/include/asm-x86_64/pgalloc.h - 1.4 linux/include/asm-x86_64/pda.h - 1.4 linux/include/asm-x86_64/pci.h - 1.2 linux/include/asm-x86_64/page.h - 1.4 linux/include/asm-x86_64/mmu_context.h - 1.4 linux/include/asm-x86_64/mmu.h - 1.2 linux/include/asm-x86_64/locks.h - 1.2 linux/include/asm-x86_64/ioctls.h - 1.2 linux/include/asm-x86_64/io.h - 1.3 linux/include/asm-x86_64/i387.h - 1.3 linux/include/asm-x86_64/desc.h - 1.3 linux/include/asm-x86_64/cpufeature.h - 1.2 linux/include/asm-x86_64/checksum.h - 1.3 linux/include/asm-x86_64/bootsetup.h - 1.2 linux/include/asm-x86_64/bitops.h - 1.4 linux/include/asm-x86_64/apic.h - 1.3 linux/include/sound/pcm_params.h - 1.4 linux/include/sound/initval.h - 1.2 linux/include/sound/core.h - 1.8 linux/include/sound/ac97_codec.h - 1.4 linux/include/asm-x86_64/signal.h - 1.2 linux/include/asm-x86_64/softirq.h - 1.2 linux/include/asm-x86_64/spinlock.h - 1.2 linux/include/asm-x86_64/string.h - 1.2 linux/include/asm-x86_64/xor.h - 1.2 linux/include/asm-x86_64/user.h - 1.3 linux/include/asm-x86_64/uaccess.h - 1.2 linux/include/asm-x86_64/types.h - 1.3 linux/include/asm-x86_64/tlb.h - 1.2 linux/include/asm-x86_64/timex.h - 1.3 linux/include/asm-x86_64/thread_info.h - 1.3 linux/arch/ppc64/kernel/chrp_setup.c - 1.4 linux/arch/ppc64/kernel/iSeries_setup.c - 1.4 linux/arch/ppc64/kernel/setup.c - 1.5 linux/fs/jfs/jfs_mount.c - 1.5 linux/fs/jfs/jfs_txnmgr.c - 1.6 linux/fs/quota_v2.c - 1.4 linux/fs/quota_v1.c - 1.4 linux/drivers/net/e100/e100_proc.c - 1.4 linux/arch/ia64/sn/kernel/setup.c - 1.2 linux/drivers/acpi/acpi_drivers.h - 1.4 linux/drivers/ide/ata-timing.c - 1.3 linux/drivers/ide/ata-timing.h - 1.4 linux/drivers/net/wan/comx-hw-munich.c - 1.4 linux/fs/libfs.c - 1.4 linux/drivers/usb/class/Config.help - 1.2 linux/drivers/usb/input/Config.help - 1.2 linux/drivers/usb/class/printer.c - 1.5 linux/drivers/usb/core/devices.c - 1.2 linux/drivers/usb/core/devio.c - 1.4 linux/drivers/usb/media/pwc-ioctl.h - 1.2 linux/drivers/usb/host/ohci-hcd.c - 1.5 linux/drivers/usb/host/ohci-q.c - 1.4 linux/drivers/usb/host/ohci.h - 1.3 linux/drivers/usb/media/stv680.c - 1.4 linux/drivers/usb/media/stv680.h - 1.2 linux/drivers/usb/host/uhci.c - 1.5 linux/drivers/usb/image/hpusbscsi.c - 1.3 linux/drivers/usb/image/hpusbscsi.h - 1.2 linux/drivers/usb/input/Config.in - 1.3 linux/drivers/usb/input/Makefile - 1.4 linux/drivers/usb/media/dabusb.c - 1.5 linux/drivers/usb/media/ov511.c - 1.5 linux/drivers/usb/media/pwc-ctrl.c - 1.2 linux/drivers/usb/media/pwc-if.c - 1.3 linux/drivers/usb/media/pwc.h - 1.2 linux/drivers/usb/serial/safe_serial.c - 1.4 linux/drivers/usb/media/se401.c - 1.4 linux/drivers/usb/media/vicam.c - 1.2 linux/drivers/usb/net/kaweth.c - 1.3 linux/drivers/usb/net/cdc-ether.h - 1.2 linux/drivers/usb/net/cdc-ether.c - 1.4 linux/mm/readahead.c - 1.5 linux/fs/exportfs/expfs.c - 1.5 linux/arch/x86_64/kernel/bootflag.c - 1.2 linux/include/asm-x86_64/percpu.h - 1.2 linux/drivers/isdn/hisax/Config.in - 1.3 linux/arch/ia64/hp/sim/hpsim_setup.c - 1.2 linux/drivers/isdn/hardware/avm/avm_cs.c - 1.2 linux/drivers/isdn/hardware/Makefile - 1.3 linux/drivers/ide/tcq.c - 1.5 linux/drivers/usb/host/uhci-hcd.c - 1.3 linux/drivers/ide/pcidma.c - 1.5 linux/drivers/message/Makefile - 1.3 linux/init/Makefile - 1.4 linux/include/asm-sparc64/tlbflush.h - 1.3 linux/kernel/suspend.c - 1.4 linux/drivers/ide/ioctl.c - 1.4 linux/drivers/ide/main.c - 1.3 linux/drivers/ide/probe.c - 1.4 linux/drivers/usb/host/hc_simple.c - 1.2 linux/drivers/video/cfbimgblt.c - 1.3 linux/include/linux/suspend.h - 1.3 linux/fs/mpage.c - 1.2 linux/drivers/usb/core/message.c - 1.3 linux/drivers/acpi/bus.c - 1.2 linux/drivers/acpi/pci_root.c - 1.2 linux/drivers/acpi/system.c - 1.3 linux/drivers/acpi/processor.c - 1.2 linux/drivers/ide/device.c - 1.3 linux/drivers/acpi/utils.c - 1.2 linux/drivers/isdn/hisax/amd7930_fn.c - 1.2 linux/drivers/isdn/hisax/amd7930_fn.h - 1.2 linux/scripts/fixdep.c - 1.2 linux/drivers/usb/core/hcd-pci.c - 1.2 linux/arch/i386/kernel/suspend.c - 1.2 From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:22:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IKMenC032070 for ; Tue, 18 Jun 2002 13:22:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IKMeg4032069 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:22:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IKMZnC032041 for ; Tue, 18 Jun 2002 13:22:36 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17KPXd-0006hZ-00 for ; Tue, 18 Jun 2002 23:25:29 +0300 Date: Tue, 18 Jun 2002 23:25:29 +0300 To: linux-xfs@oss.sgi.com Subject: Re: mapcheck mmap-fixer has problems.. Message-ID: <20020618202529.GA25733@banix> References: <20020618200859.GA25557@banix> <1024431090.1409.60.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1024431090.1409.60.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.28i From: Juha K Kallio X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, it was /proc and /dev causing the problems. I just tried the verbose mode, and it fixed multiple times one file I was downloading at the moment.. Does it break something if i mapcheck a file that's being written? From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:38:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IKcRnC032379 for ; Tue, 18 Jun 2002 13:38:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IKcRxX032378 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:38:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IKc5nC032349 for ; Tue, 18 Jun 2002 13:38:06 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA87834; Tue, 18 Jun 2002 15:40:55 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA95889; Tue, 18 Jun 2002 15:40:55 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IKdY810979; Tue, 18 Jun 2002 15:39:34 -0500 Message-Id: <200206182039.g5IKdY810979@jen.americas.sgi.com> Date: Tue, 18 Jun 2002 15:39:34 -0500 Subject: TAKE - Introduce version 2 log support to XFS To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, new feature time. This hopefully is the answer to performance problems on software raid5, and to issues with EVMS and LVM2 when using XFS. You will need new commands to use this. Basically this adds support for a new log format in XFS, which allows for two things: o larger internal log buffers, and hence larger log writes, the old limit was 32K, the new one is 256K. You must be using version 2 log format to use the larger sizes. o Stripe aligned log writes, log writes can be stripe aligned to the data stripe unit, or to an explicitly specified log stripe unit. This is the part which helps out EVMS, LVM2 and software raid5. How to use it: First build new commands - at some point I hope to put out a utility to convert an existing filesystem, but right now you have to use mkfs to get to the new code. Old filesystems just keep on working without doing anything to them. Use a mkfs command like this: mkfs -t xfs -f -l version=2,sunit=4096 /dev/xxx You can skip the sunit if all you want is larger log writes. Then mount the filesystem. You can use larger logbuffers with -o logbsize=65536 (or another power of 2) on the mount command. Larger log buffers help performance, as does the stripe alignment. Note that Irix does not have support for this yet, so you will not be able to mount filesystems with the new log format on Irix. Steve Date: Tue Jun 18 13:32:20 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-newlog The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:121875a cmd/xfsprogs/db/sb.c - 1.6 - Add logsunit to super block fields cmd/xfsprogs/db/uuid.c - 1.6 - Pass log stripe into log clear code cmd/xfsprogs/VERSION - 1.48 - Bump revision number of version 2 log support cmd/xfsprogs/doc/CHANGES - 1.69 - New version cmd/xfsprogs/man/man8/mkfs.xfs.8 - 1.9 - New options for mkfs cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.29 - Add log v2 support cmd/xfsprogs/libxlog/xfs_log_recover.c - 1.11 - Expand recovery to cope with v2 logs cmd/xfsprogs/include/xfs_log_priv.h - 1.9 - New structures for v2 log format cmd/xfsprogs/include/xfs_sb.h - 1.6 - Add log versioning, and new super block field for the log stripe cmd/xfsprogs/include/xfs_fs.h - 1.18 - Version geometry ioctl cmd/xfsprogs/include/libxfs.h - 1.13 - Add new parameter to libxfs_log_clear, add stripe mask to the mount structure cmd/xfsprogs/include/xfs_mount.h - 1.23 - Add stripe mask to the mount structure cmd/xfsprogs/repair/agheader.c - 1.8 - Account for presence of log stripe in super block cmd/xfsprogs/repair/phase2.c - 1.7 - Tell log clear about the stripe unit cmd/xfsprogs/libxfs/rdwr.c - 1.9 - Make the log clear code know about log versions and striping cmd/xfsprogs/libxfs/xfs_mount.c - 1.9 - Initialize log stripe mask from super block cmd/xfsdump/VERSION - 1.33 - Bump revision number cmd/xfsdump/doc/CHANGES - 1.41 - New version cmd/xfstests/016 - 1.10 - Fix test for v2 striped logs Modid: 2.4.x-xfs:slinx:121875b linux/fs/xfs/xfsidbg.c - 1.185 - Log v2 debug stuff linux/fs/xfs/xfs_log.c - 1.249 - Support for writing v2 logs linux/fs/xfs/xfs_macros.c - 1.42 - Log v2 macro linux/fs/xfs/xfs_log_priv.h - 1.83 - New structures for v2 log format linux/fs/xfs/xfs_sb.h - 1.52 - Add log versioning, and new super block field for the log stripe linux/fs/xfs/xfs_log_recover.c - 1.234 - Support for recovering v2 logs linux/fs/xfs/xfs_vfsops.c - 1.353 - Checks for new logbuf sizes linux/fs/xfs/xfs_mount.h - 1.146 - Add stripemask to xfs_mount_t linux/fs/xfs/xfs_mount.c - 1.287 - Initialize log stripe mask from super block linux/fs/xfs/xfs_fsops.c - 1.79 - New geometry version linux/fs/xfs/linux/xfs_super.c - 1.181 - Parse new bufsize parameters linux/include/linux/xfs_fs.h - 1.34 - Version geometry ioctl linux/fs/xfs/linux/xfs_ioctl.c - 1.63 - Add new version of geometry ioctl linux/fs/xfs/support/debug.c - 1.6 - Make CE_PANIC stop the machine From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:44:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IKiYnC032567 for ; Tue, 18 Jun 2002 13:44:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IKiYbX032566 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:44:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IKiSnC032538 for ; Tue, 18 Jun 2002 13:44:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA85145; Tue, 18 Jun 2002 15:47:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA85665; Tue, 18 Jun 2002 15:47:18 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5IKjvY11731; Tue, 18 Jun 2002 15:45:57 -0500 Subject: Re: mapcheck mmap-fixer has problems.. From: Steve Lord To: Juha K Kallio Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020618202529.GA25733@banix> References: <20020618200859.GA25557@banix> <1024431090.1409.60.camel@jen.americas.sgi.com> <20020618202529.GA25733@banix> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 15:45:56 -0500 Message-Id: <1024433156.1392.67.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 15:25, Juha K Kallio wrote: > Yes, it was /proc and /dev causing the problems. > I just tried the verbose mode, and it fixed multiple times one file I > was downloading at the moment.. Does it break something if i mapcheck a > file that's being written? Ugh, you probably have some zeros in your file. I would not recommend doing this. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 18 13:58:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IKw5nC000392 for ; Tue, 18 Jun 2002 13:58:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IKw5Zg000391 for linux-xfs-outgoing; Tue, 18 Jun 2002 13:58:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IKvwnC000362 for ; Tue, 18 Jun 2002 13:57:58 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA85025 for ; Tue, 18 Jun 2002 16:00:48 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA73534 for ; Tue, 18 Jun 2002 16:00:48 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA44971 for linux-xfs@oss.sgi.com; Tue, 18 Jun 2002 16:00:48 -0500 (CDT) Date: Tue, 18 Jun 2002 16:00:48 -0500 (CDT) From: Dean Roehrich Message-Id: <200206182100.QAA44971@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make dmapi open_by_handle independent of mount event info X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Change dm_open_by_handle() to expect an open file descriptor on the specified filesystem. This removes the unsavory dependence between this function and data from the mount event. We'll make the libdm library work a bit harder. Date: Tue Jun 18 14:00:32 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121882a linux/fs/xfs_dmapi/dmapi_register.c - 1.13 linux/fs/xfs_dmapi/dmapi_private.h - 1.10 linux/fs/xfs_dmapi/dmapi_sysent.c - 1.7 - No Message Supplied From owner-linux-xfs@oss.sgi.com Tue Jun 18 14:03:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5IL3YnC000582 for ; Tue, 18 Jun 2002 14:03:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5IL3YaZ000581 for linux-xfs-outgoing; Tue, 18 Jun 2002 14:03:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5IL3PnC000551 for ; Tue, 18 Jun 2002 14:03:26 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA86625 for ; Tue, 18 Jun 2002 16:06:15 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA33801 for ; Tue, 18 Jun 2002 16:06:15 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA45367 for linux-xfs@oss.sgi.com; Tue, 18 Jun 2002 16:06:15 -0500 (CDT) Date: Tue, 18 Jun 2002 16:06:15 -0500 (CDT) From: Dean Roehrich Message-Id: <200206182106.QAA45367@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - make libdm dm_handle_to_path() do more work, let kernel do less X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In dm_handle_to_path(), use getmntent() to walk through the filesystems, looking for one with an fshandle that matches that of the object we're trying to find. Open that path so we have a filedescriptor, and hence a valid vfsmount structure, to give to dm_open_by_handle(). This simplifies a mess on the kernel side. Date: Tue Jun 18 14:05:48 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:121884a cmd/dmapi/VERSION - 1.13 - No Message Supplied cmd/dmapi/doc/CHANGES - 1.12 - No Message Supplied cmd/dmapi/build/rpm/dmapi.spec.in - 1.11 - No Message Supplied cmd/dmapi/debian/control - 1.8 - No Message Supplied cmd/dmapi/libdm/dm_handle2path.c - 1.11 - No Message Supplied cmd/dmapi/libdm/dmapi_lib.c - 1.12 - No Message Supplied cmd/dmapi/libdm/Makefile - 1.12 - No Message Supplied From owner-linux-xfs@oss.sgi.com Tue Jun 18 14:11:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5ILBDnC001557 for ; Tue, 18 Jun 2002 14:11:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ILBD3n001556 for linux-xfs-outgoing; Tue, 18 Jun 2002 14:11:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ILB4nC001521 for ; Tue, 18 Jun 2002 14:11:05 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA88084 for ; Tue, 18 Jun 2002 16:13:54 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA24124 for ; Tue, 18 Jun 2002 16:13:54 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id QAA52243 for linux-xfs@oss.sgi.com; Tue, 18 Jun 2002 16:13:54 -0500 (CDT) Date: Tue, 18 Jun 2002 16:13:54 -0500 (CDT) From: Dean Roehrich Message-Id: <200206182113.QAA52243@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - move dmapi mount event entirely into xfs X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Move the dmapi mount event entirely into XFS. Add a new mount option, borrowed from the Imprezzo folks, to specify the mountpoint for the dmapi filesystem. Now mount dmapi filesystems this way: mount -o dmapi -o mtpt=/mnts/dmi1 /dev/sda7 /mnts/dmi1 Date: Tue Jun 18 14:13:32 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121886a linux/include/linux/fs.h - 1.150 - remove dmapi mount event hook linux/fs/xfs/xfs_dmapi.c - 1.61 linux/fs/xfs/xfs_clnt.h - 1.30 linux/fs/xfs/linux/xfs_super.c - 1.182 - No Message Supplied linux/fs/namespace.c - 1.11 - remove dmapi mount event hook From owner-linux-xfs@oss.sgi.com Tue Jun 18 17:00:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J00SnC003140 for ; Tue, 18 Jun 2002 17:00:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J00Sku003139 for linux-xfs-outgoing; Tue, 18 Jun 2002 17:00:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5INxrnC003098 for ; Tue, 18 Jun 2002 16:59:54 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA01166 for ; Tue, 18 Jun 2002 17:02:44 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA21964; Wed, 19 Jun 2002 10:01:23 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5INxow1001109; Wed, 19 Jun 2002 09:59:50 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5INxkch001107; Wed, 19 Jun 2002 09:59:46 +1000 Date: Wed, 19 Jun 2002 09:59:46 +1000 From: Nathan Scott To: "Ralf G. R. Bergs" Cc: Linux XFS Mailing List , Michael Meskes , Jan Kara Subject: Re: xfs and warnquota on Debian stable: no go Message-ID: <20020618235946.GA1042@frodo> References: <20020617214113.GC469@frodo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-2.2 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,URI_IS_POUND version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Ralf, On Tue, Jun 18, 2002 at 05:22:19PM +0200, Ralf G. R. Bergs wrote: > On Tue, 18 Jun 2002 07:41:13 +1000, Nathan Scott wrote: > > >Can you send "repquota -va" output from your system? > > Sure can do. :-) > > Here you are: > > ====================== 8x ======================= > > Fileserver:~# repquota -va > *** Report for user quotas on device /dev/sdc5 > Block grace time: 7days; Inode grace time: 7days > Block limits File limits > User used soft hard grace used soft hard grace > ---------------------------------------------------------------------- > root -- 49496204 0 0 264643 0 0 > dummy +- 51912012 0 3000000 16808 0 0 > dummy -- 608 0 0 55 0 0 > dummy -- 927868 0 3000000 1141 0 0 > ... Ahah! - I see the problem [slaps hand to forehead]. Firstly, I'll assume all these 'dummy' entries are users with "names changed to protect the innocent" - otherwise there's something very odd about your /etc/passwd. ;) The reason you're not getting any mail sent is that warnquota is _only_ looking at the soft limit field, and not at all at the hard limit - its trying to tell people that they will be punished soon, not that they are already being punished. If a user's soft limit is zero, it just ignores that entry. So, the right workaround for you would probably be to set the soft limit to something (less than or equal to the hard limit). After a period of time, the soft limit becomes enforced as the hard limit, so it's not all that "soft". Anymore than that and you would have to go hack at the warnquota.c source and make it report to people above their hard limits too (I assume you got into this state by switching quota enforcement on at some point after people had used space). That shouldn't be very hard to do if you're interested in doing that - warnquota.c is quite a simple program - start looking at the check_offence() routine, for example, and go from there (the mail body would need changes too as it makes references to soft limits becoming enforced as hard limits). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jun 18 19:08:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J28mnC004339 for ; Tue, 18 Jun 2002 19:08:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J28m3g004338 for linux-xfs-outgoing; Tue, 18 Jun 2002 19:08:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J28fnC004310 for ; Tue, 18 Jun 2002 19:08:42 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g5J2BVR26012 for ; Wed, 19 Jun 2002 11:11:31 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g5J2BUm09232 for ; Wed, 19 Jun 2002 11:11:30 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g5J2BR218009 for ; Wed, 19 Jun 2002 11:11:28 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA520 for ; Wed, 19 Jun 2002 11:11:27 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Jun 19 11:11:25 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g5J2BPA47603; Wed, 19 Jun 2002 11:11:25 +0900 (JST) Received: from NEC4D4BGTKMOBI (TNES017100.bsd.tnes.nec.co.jp [10.1.104.62]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g5J2BPY18103; Wed, 19 Jun 2002 11:11:25 +0900 Message-ID: <006d01c21736$9d68a930$3e68010a@bsd.tnes.nec.co.jp> From: "Hiroyuki Nakano" To: "Stephen Lord" Cc: References: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp><1023369251.1701.20.camel@snafu> <011f01c20dc8$33a11450$3e68010a@bsd.tnes.nec.co.jp> <1023449770.1178.3.camel@snafu> <1023450889.1178.5.camel@snafu> Subject: Re: XFS force shutdown : EFSCORRUPTED Date: Wed, 19 Jun 2002 11:11:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, Can you replicate this problem? I would like to know your opinion. Thanks. -nak > > > Hi Steve, > > > > I hold factor is reading block device. As I make 8 allocation groups by > > mkfs.xfs, > > and I put log on allocation group1. > > I see that now, thanks, I misread your mkfs command. This must be an > option you have added to mkfs as it is certainly not supported by the > standard code. Could you send me a copy of your mkfs changes please? > > Steve > From owner-linux-xfs@oss.sgi.com Tue Jun 18 19:13:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J2DEnC004529 for ; Tue, 18 Jun 2002 19:13:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J2DDqk004528 for linux-xfs-outgoing; Tue, 18 Jun 2002 19:13:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J2D9nC004500 for ; Tue, 18 Jun 2002 19:13:09 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA09701 for ; Tue, 18 Jun 2002 19:16:05 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g5J2F3Ed10627868; Tue, 18 Jun 2002 19:15:04 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 041F13000BA; Wed, 19 Jun 2002 12:15:02 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id B45D494; Wed, 19 Jun 2002 12:15:02 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE - fix last block mmap problems In-reply-to: Your message of "18 Jun 2002 09:35:58 EST." <1024410958.12631.18.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 19 Jun 2002 12:14:57 +1000 Message-ID: <18069.1024452897@kao2.melbourne.sgi.com> X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 18 Jun 2002 09:35:58 -0500, Steve Lord wrote: >This is the program to fix up the files left behind by this bug. It >does a tree walk of a directory and mmaps files looking for candidates, >if it finds a file with space in the last block beyond end of file >which has non-zero data in it, it will zero the remainder of the >block. Due to a unrelated kernel (not XFS) bug, the program may or may not change the timestamp on the files. Updating an mmapped file without doing an explicit write to the file is not guaranteed to change the timestamp, files can be changed but appear unchanged. This kernel bug messes up rsync --newer, backups and any other programs that rely on the timestamp. Also 4096 should be getpagesize() to cater for IA64. From owner-linux-xfs@oss.sgi.com Tue Jun 18 19:23:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J2NjnC004736 for ; Tue, 18 Jun 2002 19:23:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J2Njfw004735 for linux-xfs-outgoing; Tue, 18 Jun 2002 19:23:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J2NdnC004706 for ; Tue, 18 Jun 2002 19:23:39 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA86540; Tue, 18 Jun 2002 21:26:30 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-63.corp.sgi.com [134.15.64.63]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA64069; Tue, 18 Jun 2002 21:26:29 -0500 (CDT) Subject: Re: TAKE - fix last block mmap problems From: Stephen Lord To: Keith Owens Cc: linux-xfs@oss.sgi.com In-Reply-To: <18069.1024452897@kao2.melbourne.sgi.com> References: <18069.1024452897@kao2.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 21:24:38 -0500 Message-Id: <1024453479.1168.11.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 21:14, Keith Owens wrote: > On 18 Jun 2002 09:35:58 -0500, > Steve Lord wrote: > >This is the program to fix up the files left behind by this bug. It > >does a tree walk of a directory and mmaps files looking for candidates, > >if it finds a file with space in the last block beyond end of file > >which has non-zero data in it, it will zero the remainder of the > >block. > > Due to a unrelated kernel (not XFS) bug, the program may or may not > change the timestamp on the files. Updating an mmapped file without > doing an explicit write to the file is not guaranteed to change the > timestamp, files can be changed but appear unchanged. This kernel bug > messes up rsync --newer, backups and any other programs that rely on > the timestamp. > > Also 4096 should be getpagesize() to cater for IA64. The program was put together quickly and could be better, if someone wants to clean it up that would be good (i.e. prevent it from walking into non-xfs filesystems etc). I would actually say we do not want to update the timestamps here, we are trying to fix the problems in the filesystem here, and not modify the metadata. Steve From owner-linux-xfs@oss.sgi.com Tue Jun 18 19:42:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J2gZnC005084 for ; Tue, 18 Jun 2002 19:42:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J2gZV1005083 for linux-xfs-outgoing; Tue, 18 Jun 2002 19:42:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J2gUnC005054 for ; Tue, 18 Jun 2002 19:42:31 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id VAA92461; Tue, 18 Jun 2002 21:45:21 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-63.corp.sgi.com [134.15.64.63]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA06146; Tue, 18 Jun 2002 21:45:19 -0500 (CDT) Subject: Re: XFS force shutdown : EFSCORRUPTED From: Stephen Lord To: Hiroyuki Nakano Cc: linux-xfs@oss.sgi.com In-Reply-To: <006d01c21736$9d68a930$3e68010a@bsd.tnes.nec.co.jp> References: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp><1023369251.1701.20.camel @snafu> <011f01c20dc8$33a11450$3e68010a@bsd.tnes.nec.co.jp> <1023449770.1178.3.camel@snafu> <1023450889.1178.5.camel@snafu> <006d01c21736$9d68a930$3e68010a@bsd.tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 18 Jun 2002 21:43:29 -0500 Message-Id: <1024454610.1168.14.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-18 at 21:11, Hiroyuki Nakano wrote: > Hi Steve, > > Can you replicate this problem? I would like to know your opinion. At the moment I cannot - it may possibly be very specific to which blocks in the filesystem you read - which in turn would be related to exactly how large the filesystem is. Does varying where you read from the block device make any difference here? Steve From owner-linux-xfs@oss.sgi.com Wed Jun 19 01:38:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J8cYnC010105 for ; Wed, 19 Jun 2002 01:38:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J8cYBd010104 for linux-xfs-outgoing; Wed, 19 Jun 2002 01:38:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J8cKnC010076 for ; Wed, 19 Jun 2002 01:38:21 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.195]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g5J8fHe12175 for ; Wed, 19 Jun 2002 17:41:17 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g5J8fFL00126 for ; Wed, 19 Jun 2002 17:41:15 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g5J8fD212789 for ; Wed, 19 Jun 2002 17:41:13 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA197 for ; Wed, 19 Jun 2002 17:41:12 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Jun 19 17:41:11 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g5J8fCA80128; Wed, 19 Jun 2002 17:41:12 +0900 (JST) Received: from NEC4D4BGTKMOBI (TNES017100.bsd.tnes.nec.co.jp [10.1.104.62]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g5J8fCY12142; Wed, 19 Jun 2002 17:41:12 +0900 Message-ID: <012901c2176d$10e40bd0$3e68010a@bsd.tnes.nec.co.jp> From: "Hiroyuki Nakano" To: "Stephen Lord" Cc: References: <013d01c20d55$28ec6f00$3e68010a@bsd.tnes.nec.co.jp><1023369251.1701.20.camel@snafu> <011f01c20dc8$33a11450$3e68010a@bsd.tnes.nec.co.jp><1023449770.1178.3.camel@snafu> <1023450889.1178.5.camel@snafu> <006d01c21736$9d68a930$3e68010a@bsd.tnes.nec.co.jp> <1024454610.1168.14.camel@snafu> Subject: Re: XFS force shutdown : EFSCORRUPTED Date: Wed, 19 Jun 2002 17:41:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, I executed Shell-scrippt, as I changed lseek second argument value to 4096*12, 4096*14, 4096*15, 4096*17, 4096*18, 4096*20 from 4096*16. Shell-script was normal end. Only 4096*16(10000H) is a problem. Physical address 10000H-13fffH is inode chunk area on dev/hda7. I think Inode chunk area is in page buffers. Read function access to page buffers. If read function access to device, page buffers are broken. My Shell-scrippt (org-g.sh) is : umount /dev/hda7 /usr/src/cmd/xfsprogs/mkfs/mkfs.xfs -f -l agnum=1,size=2000b /dev/hda7 mount /dev/hda7 /mnt/xfs cd /mnt/xfs tar zxvf /test/xfs-cmd.tar.gz /test/test_dev_read cd /test rm -rf /mnt/xfs/cmd and my program (test_dev_read.c) is : #include #include #include #include #include #include int main( argc, argv ) int argc; const char *argv[]; { int fd,ret,i,error; char bufl[4096]; if( ( fd = open( "/dev/hda7" , O_RDONLY , S_IRWXU ) ) < 0 ){ printf( "error= %s\n" , strerror(errno) ); return; } for( i=0; i<1; i++ ){ ret = 40; error = read( fd , bufl , ret ); printf( "test read1 finish = %x \n",(char)bufl[0] ); } if ( lseek( fd, 4096*16, SEEK_CUR ) == -1 ){ printf( "error2= %s\n" , strerror(errno) ); } for( i=0; i<1; i++ ){ ret = 40; error = read( fd , bufl , ret ); printf( "test read2 finish = %x \n",(char)bufl[0] ); } printf( "test program finish \n" ); close( fd ); } Thanks. -nak > > At the moment I cannot - it may possibly be very specific to which > blocks in the filesystem you read - which in turn would be related > to exactly how large the filesystem is. Does varying where you read > from the block device make any difference here? > > Steve > From owner-linux-xfs@oss.sgi.com Wed Jun 19 02:02:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5J928nC010513 for ; Wed, 19 Jun 2002 02:02:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5J9285J010512 for linux-xfs-outgoing; Wed, 19 Jun 2002 02:02:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5J91tnC010484 for ; Wed, 19 Jun 2002 02:01:56 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.35 #1) id 17KbOQ-0000NK-00; Wed, 19 Jun 2002 11:04:46 +0200 From: "Ralf G. R. Bergs" To: "Linux XFS Mailing List" , "Nathan Scott" Cc: "Michael Meskes" , "Jan Kara" Date: Wed, 19 Jun 2002 11:04:45 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2502) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020618235946.GA1042@frodo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: xfs and warnquota on Debian stable: no go Message-Id: X-Spam-Status: No, hits=-4.7 required=5.0 tests=IN_REP_TO,GAPPY_TEXT,URI_IS_POUND version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 19 Jun 2002 09:59:46 +1000, Nathan Scott wrote: >> Fileserver:~# repquota -va >> *** Report for user quotas on device /dev/sdc5 >> Block grace time: 7days; Inode grace time: 7days >> Block limits File limits >> User used soft hard grace used soft hard grace >> ---------------------------------------------------------------------- >> root -- 49496204 0 0 264643 0 0 >> dummy +- 51912012 0 3000000 16808 0 0 >> dummy -- 608 0 0 55 0 0 >> dummy -- 927868 0 3000000 1141 0 0 >> ... > >Ahah! - I see the problem [slaps hand to forehead]. > >Firstly, I'll assume all these 'dummy' entries are users with >"names changed to protect the innocent" - otherwise there's >something very odd about your /etc/passwd. ;) That's right, Sir. :-) >The reason you're not getting any mail sent is that warnquota >is _only_ looking at the soft limit field, and not at all at >the hard limit - its trying to tell people that they will be >punished soon, not that they are already being punished. If >a user's soft limit is zero, it just ignores that entry. That makes perfect sense! >So, the right workaround for you would probably be to set the >soft limit to something (less than or equal to the hard limit). >After a period of time, the soft limit becomes enforced as the >hard limit, so it's not all that "soft". I understand. That should be easy to do. > (I assume you got >into this state by switching quota enforcement on at some point >after people had used space). That shouldn't be very hard to Again you're right. >do if you're interested in doing that - warnquota.c is quite a >simple program - start looking at the check_offence() routine, >for example, and go from there (the mail body would need changes >too as it makes references to soft limits becoming enforced as >hard limits). I don't think it's worth the trouble. We will use it "as is." Thanks for pointing me at our "user error." :-) Cheers, Ralf -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Wed Jun 19 04:19:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JBJknC015510 for ; Wed, 19 Jun 2002 04:19:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JBJk3u015509 for linux-xfs-outgoing; Wed, 19 Jun 2002 04:19:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx1.elte.hu (mx1.elte.hu [157.181.1.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JBJYnC015481 for ; Wed, 19 Jun 2002 04:19:34 -0700 Received: from chiara.elte.hu (chiara.elte.hu [157.181.150.200]) by mx1.elte.hu (Postfix) with ESMTP id 0324C44530 for ; Wed, 19 Jun 2002 13:22:25 +0200 (CEST) Received: by chiara.elte.hu (Postfix, from userid 17000) id 0EABA1FC2; Wed, 19 Jun 2002 13:22:23 +0200 (CEST) Date: Wed, 19 Jun 2002 13:22:22 +0200 From: KELEMEN Peter To: linux-xfs@oss.sgi.com Subject: Re: Tons of empty transactions Message-ID: <20020619112221.GA26158@chiara.elte.hu> Reply-To: KELEMEN Peter Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020526225657.GA4965@chiara.elte.hu> <1022524000.1147.7.camel@snafu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1022524000.1147.7.camel@snafu> User-Agent: Mutt/1.3.28i Organization: ELTE Eotvos Lorand University of Sciences, Budapest, Hungary X-GPG-KeyID: 1024D/EE4C26E8 2000-03-20 X-GPG-Fingerprint: D402 4AF3 7488 165B CC34 4147 7F0C D922 EE4C 26E8 X-PGP-KeyID: 1024/45F83E45 1998/04/04 X-PGP-Fingerprint: 26 87 63 4B 07 28 1F AD 6D AA B5 8A D6 03 0F BF X-Comment: Personal opinion. Paragraphs might have been reformatted. X-Copyright: Forwarding or publishing without permission is prohibited. X-Accept-Language: hu,en X-Spam-Status: No, hits=-9.4 required=5.0 tests=IN_REP_TO,UNIFIED_PATCH version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk * Stephen Lord (lord@sgi.com) [20020527 13:26]: Steve, > There are some paths in xfs which allocate a transaction, and > then discover they do not need it. [...] I suspect the case I > mentioned of truncating excess space on close is probably the > main culprit. Thanks for the explanation. [ For those who haven't followed #xfs: after plotting the stats and finding correlation with xs_ig_attrchg counters, Steve came up with a theory of excessive utime() activity causing the high number of empty transactions. ] Your theory was correct; after six days of monitoring, the culprit application was found to be ncftp. You can reproduce the effect by simply downloading a big file, and it will boost your empty transaction counter. Snippet from the strace output: select(8, [7], NULL, NULL, {1, 0}) = 1 (in [7], left {1, 0}) read(7, "\214Oc\255m\2672\253\241\262\305r\f\0071\2\356\324\232"..., 4096) = 4096 write(6, "\214Oc\255m\2672\253\241\262\305r\f\0071\2\356\324\232"..., 4096) = 4096 utime("PATH/TO/FILE/DOWNLOADED", [2002/06/19-11:33:01, 2002/06/14-11:54:13]) = 0 time([1024479198]) = 1024479198 ... alarm(3600) = 3600 elect(8, [7], NULL, NULL, {1, 0}) = 1 (in [7], left {1, 0}) read(7, "\r\275\355r\335\325\20\0\0\0\1\v\32\246\210\\\214\356\353"..., 4096) = 4096 write(6, "\r\275\355r\335\325\20\0\0\0\1\v\32\246\210\\\214\356\353"..., 4096) = 4096 utime("PATH/TO/FILE/DOWNLOADED", [2002/06/19-11:33:01, 2002/06/14-11:54:13]) = 0 time([1024479199]) = 1024479199 alarm(3600) = 3600 ... ...in repeating pattern. On a slow machine/link I measured about 2-3000 calls per minute. On #xfs, you suggested the following change to turn these empty transactions to async ones: --- xfs_vnodeops.c.orig Wed May 22 14:08:19 2002 +++ xfs_vnodeops.c Wed Jun 12 17:31:18 2002 @@ -820,6 +820,7 @@ timeflags &= ~XFS_ICHGTIME_MOD; timeflags |= XFS_ICHGTIME_CHG; } + xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); } /* There was no definite opinion if we need these transactions at all, and you mentioned that eliminating them would be a more coplex change. Awaiting your comment. Peter -- .+'''+. .+'''+. .+'''+. .+'''+. .+'' Kelemen Péter / \ / \ / fuji@elte.hu .+' `+...+' `+...+' `+...+' `+...+' From owner-linux-xfs@oss.sgi.com Wed Jun 19 08:42:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JFgSnC026825 for ; Wed, 19 Jun 2002 08:42:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JFgSx4026824 for linux-xfs-outgoing; Wed, 19 Jun 2002 08:42:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JFfanC026790 for ; Wed, 19 Jun 2002 08:41:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA92646 for ; Wed, 19 Jun 2002 10:44:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA66076 for ; Wed, 19 Jun 2002 10:44:29 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5JFh1x27572; Wed, 19 Jun 2002 10:43:01 -0500 Message-Id: <200206191543.g5JFh1x27572@jen.americas.sgi.com> Date: Wed, 19 Jun 2002 10:43:01 -0500 Subject: TAKE - merge up to 2.5.23 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another kernel from Linus, kdb seems flakey here, do not turn it on unless you have to. Date: Wed Jun 19 08:34:53 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:121941a linux/net/llc/llc_if.c - 1.1 linux/include/net/llc_sap.h - 1.1 linux/include/net/llc_if.h - 1.1 linux/include/asm-ia64/agp.h - 1.1 linux/include/asm-sparc64/agp.h - 1.1 linux/include/net/llc_s_st.h - 1.1 linux/include/asm-i386/agp.h - 1.1 linux/include/net/llc_s_ev.h - 1.1 linux/include/asm-alpha/agp.h - 1.1 linux/include/asm-x86_64/agp.h - 1.1 linux/include/asm-x86_64/suspend.h - 1.1 linux/net/core/ext8022.c - 1.1 linux/arch/alpha/kernel/asm-offsets.c - 1.1 linux/include/net/llc_s_ac.h - 1.1 linux/include/net/llc_pdu.h - 1.1 linux/include/net/llc_main.h - 1.1 linux/arch/x86_64/ia32/ipc32.c - 1.1 linux/include/linux/llc.h - 1.1 linux/arch/arm/kernel/asm-offsets.c - 1.1 linux/arch/x86_64/kernel/asm-offsets.c - 1.1 linux/net/llc/llc_stat.c - 1.1 linux/net/llc/llc_sock.c - 1.1 linux/net/llc/llc_sap.c - 1.1 linux/net/llc/llc_s_st.c - 1.1 linux/net/llc/llc_s_ac.c - 1.1 linux/net/llc/llc_s_ev.c - 1.1 linux/net/llc/llc_evnt.c - 1.1 linux/net/llc/llc_mac.c - 1.1 linux/net/llc/llc_c_st.c - 1.1 linux/include/net/llc_mac.h - 1.1 linux/net/llc/Makefile - 1.1 linux/net/llc/llc_actn.c - 1.1 linux/net/llc/llc_pdu.c - 1.1 linux/include/net/llc_stat.h - 1.1 linux/net/llc/llc_c_ac.c - 1.1 linux/net/llc/llc_c_ev.c - 1.1 linux/net/llc/llc_main.c - 1.1 linux/net/llc/llc_conn.c - 1.1 linux/include/net/llc_c_st.h - 1.1 linux/include/net/llc_actn.h - 1.1 linux/include/net/llc_c_ac.h - 1.1 linux/include/net/llc_c_ev.h - 1.1 linux/include/net/llc_conn.h - 1.1 linux/include/net/llc_evnt.h - 1.1 linux/arch/i386/mm/pageattr.c - 1.1 linux/net/socket.c - 1.36 linux/net/netsyms.c - 1.47 linux/net/ipv6/tcp_ipv6.c - 1.37 linux/net/ipv6/proc.c - 1.11 linux/net/ipv4/route.c - 1.33 linux/net/ipv4/proc.c - 1.12 linux/net/ipv4/ip_gre.c - 1.20 linux/net/core/skbuff.c - 1.26 linux/net/core/neighbour.c - 1.16 linux/net/core/dev.c - 1.55 linux/net/core/datagram.c - 1.13 linux/net/core/Makefile - 1.9 linux/net/Makefile - 1.21 linux/net/Config.in - 1.23 linux/net/802/p8022.c - 1.7 linux/mm/vmscan.c - 1.103 linux/mm/vmalloc.c - 1.42 linux/mm/swapfile.c - 1.60 linux/mm/swap_state.c - 1.41 linux/mm/slab.c - 1.34 linux/mm/page_io.c - 1.26 linux/mm/page_alloc.c - 1.81 linux/mm/filemap.c - 1.123 linux/kernel/sysctl.c - 1.53 linux/kernel/sys.c - 1.34 linux/kernel/softirq.c - 1.21 linux/kernel/signal.c - 1.33 linux/kernel/sched.c - 1.72 linux/kernel/printk.c - 1.20 linux/kernel/ksyms.c - 1.150 linux/kernel/kmod.c - 1.21 linux/kernel/fork.c - 1.60 linux/init/main.c - 1.84 linux/include/net/p8022.h - 1.4 linux/include/net/datalink.h - 1.4 linux/include/linux/wait.h - 1.15 linux/include/linux/vmalloc.h - 1.18 linux/include/linux/tqueue.h - 1.12 linux/include/linux/timer.h - 1.14 linux/include/linux/sysctl.h - 1.51 linux/include/linux/swap.h - 1.59 linux/include/linux/smp.h - 1.15 linux/include/linux/skbuff.h - 1.25 linux/include/linux/sched.h - 1.73 linux/include/linux/quota.h - 1.20 linux/include/linux/loop.h - 1.8 linux/include/linux/kernel_stat.h - 1.10 linux/include/linux/fs.h - 1.176 linux/include/linux/file.h - 1.15 linux/include/linux/blkdev.h - 1.61 linux/include/linux/auto_fs.h - 1.9 linux/include/asm-sparc64/system.h - 1.20 linux/include/asm-sparc64/oplib.h - 1.8 linux/include/asm-ppc/smp.h - 1.16 linux/include/asm-ppc/hardirq.h - 1.18 linux/include/asm-i386/smp.h - 1.18 linux/include/asm-i386/pgtable.h - 1.36 linux/include/asm-i386/page.h - 1.28 linux/include/asm-i386/io.h - 1.27 linux/include/asm-i386/hardirq.h - 1.19 linux/fs/ufs/truncate.c - 1.20 linux/fs/qnx4/fsync.c - 1.12 linux/fs/proc/array.c - 1.44 linux/fs/ntfs/super.c - 1.16 linux/fs/nfs/dir.c - 1.41 linux/fs/namei.c - 1.57 linux/fs/locks.c - 1.26 linux/fs/inode.c - 1.78 linux/fs/file_table.c - 1.20 linux/fs/coda/dir.c - 1.27 linux/fs/buffer.c - 1.125 linux/drivers/video/fbcon.c - 1.26 linux/drivers/scsi/st_options.h - 1.8 linux/drivers/scsi/st.c - 1.45 linux/drivers/scsi/sr.c - 1.45 linux/drivers/scsi/sd.c - 1.62 linux/drivers/scsi/scsi.c - 1.56 linux/drivers/scsi/constants.c - 1.11 linux/drivers/scsi/README.st - 1.9 linux/drivers/char/random.c - 1.29 linux/drivers/block/rd.c - 1.54 linux/drivers/block/nbd.c - 1.41 linux/drivers/block/loop.c - 1.59 linux/drivers/block/ll_rw_blk.c - 1.106 linux/drivers/block/floppy.c - 1.42 linux/arch/sparc64/prom/misc.c - 1.11 linux/arch/sparc64/kernel/time.c - 1.20 linux/arch/sparc64/kernel/process.c - 1.37 linux/arch/sparc64/kernel/entry.S - 1.24 linux/arch/sparc64/defconfig - 1.69 linux/arch/sparc64/boot/Makefile - 1.3 linux/arch/sparc64/Makefile - 1.18 linux/arch/sparc/kernel/time.c - 1.17 linux/arch/sparc/Makefile - 1.11 linux/arch/ppc/kernel/time.c - 1.19 linux/arch/ppc/kernel/smp.c - 1.39 linux/arch/ppc/kernel/setup.c - 1.45 linux/arch/ppc/kernel/ppc_ksyms.c - 1.44 linux/arch/ppc/kernel/open_pic.c - 1.25 linux/arch/ppc/kernel/irq.c - 1.35 linux/arch/ppc/Makefile - 1.25 linux/arch/mips/kernel/time.c - 1.12 linux/arch/mips/boot/Makefile - 1.12 linux/arch/mips/Makefile - 1.11 linux/arch/m68k/kernel/time.c - 1.6 linux/arch/m68k/Makefile - 1.8 linux/arch/i386/mm/ioremap.c - 1.15 linux/arch/i386/mm/Makefile - 1.6 linux/arch/i386/kernel/time.c - 1.23 linux/arch/i386/kernel/smp.c - 1.47 linux/arch/i386/kernel/mtrr.c - 1.38 linux/arch/i386/kernel/irq.c - 1.43 linux/arch/i386/kernel/io_apic.c - 1.39 linux/arch/i386/kernel/i386_ksyms.c - 1.49 linux/arch/i386/kernel/apm.c - 1.46 linux/arch/i386/kernel/Makefile - 1.31 linux/arch/i386/config.in - 1.83 linux/arch/i386/boot/Makefile - 1.15 linux/arch/i386/Makefile - 1.26 linux/arch/arm/kernel/time.c - 1.16 linux/arch/arm/boot/Makefile - 1.16 linux/arch/arm/Makefile - 1.29 linux/arch/alpha/lib/Makefile - 1.16 linux/arch/alpha/kernel/time.c - 1.22 linux/arch/alpha/kernel/check_asm.c - 1.5 linux/arch/alpha/kernel/Makefile - 1.22 linux/arch/alpha/boot/Makefile - 1.9 linux/arch/alpha/Makefile - 1.15 linux/Rules.make - 1.26 linux/Makefile - 1.204 linux/MAINTAINERS - 1.110 linux/Documentation/sysctl/vm.txt - 1.7 linux/Documentation/networking/ip-sysctl.txt - 1.12 linux/include/linux/ide.h - 1.53 linux/drivers/block/cpqarray.c - 1.49 linux/fs/partitions/check.c - 1.43 linux/fs/partitions/Makefile - 1.10 linux/drivers/block/DAC960.c - 1.49 linux/arch/sparc64/kernel/power.c - 1.9 linux/arch/sh/kernel/time.c - 1.17 linux/arch/sh/boot/Makefile - 1.6 linux/arch/sh/Makefile - 1.9 linux/include/asm-i386/kmap_types.h - 1.9 linux/Documentation/filesystems/proc.txt - 1.9 linux/arch/i386/kernel/smpboot.c - 1.41 linux/mm/highmem.c - 1.41 linux/include/linux/highmem.h - 1.23 linux/include/asm-i386/pgtable-3level.h - 1.10 linux/include/asm-i386/pgtable-2level.h - 1.10 linux/fs/proc/proc_misc.c - 1.35 linux/drivers/net/aironet4500_core.c - 1.18 linux/kernel/timer.c - 1.24 linux/drivers/scsi/scsi_lib.c - 1.46 linux/drivers/char/agp/agpgart_be.c - 1.39 linux/drivers/char/agp/agp.h - 1.25 linux/drivers/pcmcia/yenta.c - 1.32 linux/drivers/pcmcia/pci_socket.c - 1.11 linux/arch/i386/kernel/apic.c - 1.30 linux/arch/ia64/ia32/sys_ia32.c - 1.27 linux/arch/ia64/boot/Makefile - 1.6 linux/arch/ia64/Makefile - 1.14 linux/arch/ia64/kernel/irq.c - 1.19 linux/arch/ia64/tools/Makefile - 1.9 linux/arch/ia64/kernel/smp.c - 1.16 linux/arch/ia64/kernel/time.c - 1.13 linux/arch/ia64/kernel/perfmon.c - 1.14 linux/arch/ia64/kernel/mca.c - 1.12 linux/include/asm-ia64/hardirq.h - 1.13 linux/include/linux/raid/md_k.h - 1.22 linux/include/asm-ia64/smp.h - 1.11 linux/include/linux/raid/md.h - 1.14 linux/arch/i386/kernel/microcode.c - 1.18 linux/arch/mips64/Makefile - 1.9 linux/arch/mips64/kernel/syscall.c - 1.10 linux/arch/mips64/boot/Makefile - 1.9 linux/lib/brlock.c - 1.6 linux/include/linux/brlock.h - 1.7 linux/drivers/block/elevator.c - 1.18 linux/net/ipv4/netfilter/ipchains_core.c - 1.11 linux/net/ipv4/netfilter/ip_tables.c - 1.14 linux/arch/ia64/kernel/smpboot.c - 1.11 linux/fs/partitions/ibm.c - 1.12 linux/drivers/char/rio/func.h - 1.3 linux/include/linux/raid/raid5.h - 1.7 linux/include/linux/raid/raid1.h - 1.9 linux/arch/s390/boot/Makefile - 1.9 linux/arch/s390/Makefile - 1.8 linux/include/asm-s390/system.h - 1.7 linux/drivers/s390/block/dasd.c - 1.26 linux/drivers/s390/Makefile - 1.8 linux/drivers/s390/Config.in - 1.10 linux/drivers/s390/block/dasd_proc.c - 1.5 linux/arch/s390/kernel/time.c - 1.7 linux/arch/s390/mm/ioremap.c - 1.6 linux/net/ipv6/netfilter/ip6_tables.c - 1.12 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.10 linux/kdb/kdbmain.c - 1.30 linux/Documentation/filesystems/Locking - 1.17 linux/drivers/usb/storage/usb.h - 1.12 linux/drivers/usb/storage/usb.c - 1.22 linux/drivers/usb/storage/scsiglue.c - 1.22 linux/arch/ia64/kernel/ia64_ksyms.c - 1.13 linux/include/asm-sparc/kmap_types.h - 1.7 linux/drivers/md/lvm.c - 1.32 linux/drivers/md/raid1.c - 1.21 linux/drivers/md/raid5.c - 1.28 linux/arch/i386/kernel/bluesmoke.c - 1.22 linux/drivers/block/cciss.c - 1.36 linux/drivers/md/linear.c - 1.9 linux/drivers/md/lvm-snap.c - 1.17 linux/drivers/md/md.c - 1.47 linux/drivers/md/raid0.c - 1.9 linux/drivers/scsi/cpqfcTSinit.c - 1.17 linux/include/asm-ppc/kmap_types.h - 1.10 linux/include/asm-i386/xor.h - 1.6 linux/kernel/context.c - 1.8 linux/arch/parisc/kernel/time.c - 1.2 linux/arch/parisc/Makefile - 1.3 linux/mm/shmem.c - 1.40 linux/arch/ia64/kernel/iosapic.c - 1.9 linux/arch/ia64/sn/io/sgi_io_init.c - 1.4 linux/fs/reiserfs/journal.c - 1.31 linux/fs/reiserfs/fix_node.c - 1.23 linux/include/linux/reiserfs_fs.h - 1.26 linux/arch/s390x/kernel/time.c - 1.6 linux/arch/cris/Makefile - 1.11 linux/arch/cris/boot/Makefile - 1.2 linux/arch/cris/kernel/time.c - 1.7 linux/arch/s390x/mm/ioremap.c - 1.5 linux/drivers/s390/block/xpram.h - 1.2 linux/drivers/s390/block/xpram.c - 1.20 linux/include/asm-s390x/system.h - 1.5 linux/arch/s390x/kernel/wrapper32.S - 1.6 linux/arch/s390x/boot/Makefile - 1.8 linux/arch/s390x/Makefile - 1.7 linux/arch/arm/tools/Makefile - 1.6 linux/arch/arm/tools/constants-hdr - 1.2 linux/arch/arm/tools/getconstants.c - 1.8 linux/arch/s390/math-emu/Makefile - 1.2 linux/drivers/md/multipath.c - 1.9 linux/arch/i386/kernel/nmi.c - 1.6 linux/include/asm-generic/tlb.h - 1.7 linux/fs/jbd/journal.c - 1.13 linux/fs/ext3/inode.c - 1.14 linux/include/linux/jbd.h - 1.8 linux/fs/intermezzo/vfs.c - 1.9 linux/include/linux/intermezzo_psdev.h - 1.2 linux/fs/jbd/revoke.c - 1.7 linux/fs/jbd/transaction.c - 1.10 linux/fs/ext3/balloc.c - 1.7 linux/fs/jbd/commit.c - 1.6 linux/fs/intermezzo/dir.c - 1.7 linux/include/linux/bio.h - 1.10 linux/fs/bio.c - 1.15 linux/fs/xfs/pagebuf/page_buf.c - 1.35 linux/fs/xfs/pagebuf/page_buf.h - 1.25 linux/drivers/pci/pci-driver.c - 1.7 linux/Documentation/filesystems/porting - 1.11 linux/sound/pci/cs46xx/cs46xx.c - 1.7 linux/arch/ppc/platforms/chrp_smp.c - 1.2 linux/arch/ppc/platforms/iSeries_smp.c - 1.2 linux/arch/ppc/platforms/pmac_smp.c - 1.4 linux/arch/x86_64/Makefile - 1.5 linux/arch/x86_64/boot/Makefile - 1.5 linux/arch/x86_64/config.in - 1.9 linux/arch/x86_64/ia32/Makefile - 1.6 linux/arch/x86_64/ia32/sys_ia32.c - 1.5 linux/arch/x86_64/kernel/ioport.c - 1.2 linux/arch/x86_64/kernel/mtrr.c - 1.5 linux/arch/x86_64/kernel/process.c - 1.6 linux/arch/x86_64/kernel/setup64.c - 1.4 linux/arch/x86_64/kernel/signal.c - 1.6 linux/arch/x86_64/kernel/smp.c - 1.5 linux/arch/x86_64/kernel/vsyscall.c - 1.5 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.6 linux/arch/x86_64/lib/Makefile - 1.6 linux/arch/x86_64/tools/Makefile - 1.3 linux/arch/x86_64/tools/offset.c - 1.5 linux/arch/x86_64/tools/offset.sed - 1.2 linux/include/asm-x86_64/processor.h - 1.5 linux/include/asm-x86_64/pda.h - 1.5 linux/include/asm-x86_64/mtrr.h - 1.2 linux/include/asm-x86_64/msr.h - 1.3 linux/include/asm-x86_64/mmu_context.h - 1.5 linux/include/asm-x86_64/kmap_types.h - 1.3 linux/include/asm-x86_64/ipc.h - 1.3 linux/include/asm-x86_64/ia32.h - 1.3 linux/include/asm-x86_64/i387.h - 1.4 linux/include/asm-x86_64/system.h - 1.4 linux/include/asm-x86_64/spinlock.h - 1.3 linux/include/asm-x86_64/string.h - 1.3 linux/include/asm-x86_64/timex.h - 1.4 linux/arch/ppc64/Makefile - 1.4 linux/arch/ppc64/boot/Makefile - 1.2 linux/arch/ppc64/kernel/sys_ppc32.c - 1.5 linux/arch/ppc64/kernel/time.c - 1.4 linux/fs/jfs/jfs_logmgr.c - 1.8 linux/drivers/net/tg3.h - 1.6 linux/drivers/net/tg3.c - 1.6 linux/arch/ia64/sn/kernel/sn1/sn1_smp.c - 1.2 linux/arch/ia64/sn/kernel/setup.c - 1.3 linux/mm/msync.c - 1.4 linux/arch/ia64/sn/kernel/llsc4.c - 1.2 linux/arch/ia64/sn/io/sn1/ml_SN_intr.c - 1.2 linux/net/ipv4/netfilter/arp_tables.c - 1.2 linux/lib/radix-tree.c - 1.4 linux/include/asm-i386/cacheflush.h - 1.2 linux/drivers/usb/core/hub.h - 1.3 linux/drivers/usb/host/ohci-dbg.c - 1.3 linux/drivers/usb/host/ohci-hcd.c - 1.6 linux/drivers/usb/host/ohci-mem.c - 1.3 linux/drivers/usb/host/ohci-q.c - 1.5 linux/drivers/usb/host/ohci.h - 1.4 linux/drivers/usb/net/kaweth.c - 1.4 linux/include/asm-x86_64/cacheflush.h - 1.2 linux/include/asm-x86_64/tlbflush.h - 1.2 linux/fs/ntfs/compress.c - 1.4 linux/fs/ntfs/aops.c - 1.4 linux/drivers/ide/tcq.c - 1.6 linux/drivers/block/umem.c - 1.2 linux/mm/page-writeback.c - 1.4 linux/include/linux/buffer_head.h - 1.5 linux/include/linux/writeback.h - 1.4 linux/include/linux/dqblk_xfs.h - 1.4 linux/kernel/suspend.c - 1.5 linux/drivers/ide/ioctl.c - 1.5 linux/include/linux/namei.h - 1.2 linux/drivers/acpi/processor.c - 1.3 linux/drivers/acpi/osl.c - 1.2 linux/drivers/usb/class/usb-midi.c - 1.2 linux/scripts/fixdep.c - 1.3 linux/drivers/s390/qdio.c - 1.2 linux/drivers/s390/block/dasd_genhd.c - 1.2 linux/arch/x86_64/lib/memset.S - 1.2 From owner-linux-xfs@oss.sgi.com Wed Jun 19 08:46:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JFkjnC027922 for ; Wed, 19 Jun 2002 08:46:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JFkjVn027921 for linux-xfs-outgoing; Wed, 19 Jun 2002 08:46:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JFkZnC026977 for ; Wed, 19 Jun 2002 08:46:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA94100; Wed, 19 Jun 2002 10:49:23 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA18168; Wed, 19 Jun 2002 10:49:22 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5JFlsJ27609; Wed, 19 Jun 2002 10:47:54 -0500 Subject: Re: Tons of empty transactions From: Steve Lord To: KELEMEN Peter Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020619112221.GA26158@chiara.elte.hu> References: <20020526225657.GA4965@chiara.elte.hu> <1022524000.1147.7.camel@snafu> <20020619112221.GA26158@chiara.elte.hu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 19 Jun 2002 10:47:54 -0500 Message-Id: <1024501674.27115.45.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-19 at 06:22, KELEMEN Peter wrote: > > [ For those who haven't followed #xfs: after plotting the stats > and finding correlation with xs_ig_attrchg counters, Steve came > up with a theory of excessive utime() activity causing the high > number of empty transactions. ] > > Your theory was correct; after six days of monitoring, the culprit > application was found to be ncftp. You can reproduce the effect > by simply downloading a big file, and it will boost your empty > transaction counter. Snippet from the strace output: > > > There was no definite opinion if we need these transactions at > all, and you mentioned that eliminating them would be a more > coplex change. Awaiting your comment. > > Peter Still pondering this one, I suspect the correct answer is we need both, XFS has a wsync mount option which makes transactions fairly synchronous. In that case we should be logging the inode, in the normal case, I think the transaction should be removed. The transaction would not be written out to disk until something else pushes it out, which would often be periodic sync activity, which would be just as happy to push the inode itself out. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jun 19 08:54:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JFsrnC029232 for ; Wed, 19 Jun 2002 08:54:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JFsra8029231 for linux-xfs-outgoing; Wed, 19 Jun 2002 08:54:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JFsjnC029196 for ; Wed, 19 Jun 2002 08:54:46 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA93664 for ; Wed, 19 Jun 2002 10:57:39 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA27366 for ; Wed, 19 Jun 2002 10:57:39 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA88141 for linux-xfs@oss.sgi.com; Wed, 19 Jun 2002 10:57:38 -0500 (CDT) Date: Wed, 19 Jun 2002 10:57:38 -0500 (CDT) From: Dean Roehrich Message-Id: <200206191557.KAA88141@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - clean out left-over junk from dmapi mount event X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jun 19 08:57:21 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/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:121944a linux/fs/xfs/xfs_dmapi.h - 1.23 linux/fs/xfs/xfs_dmapi.c - 1.62 linux/fs/xfs/linux/xfs_dmistubs.c - 1.16 - No Message Supplied linux/fs/xfs/linux/xfs_super.c - 1.183 - Remove linvfs_dmapi_mount(). linux/include/linux/dmapi_kern.h - 1.12 - No Message Supplied linux/fs/xfs/linux/xfs_vfs.h - 1.19 - Remove unused vfsmount and cvp params from VFSOPS_DMAPI_MOUNT. linux/fs/xfs_dmapi/dmapi_register.c - 1.14 - No Message Supplied linux/fs/xfs_dmapi/dmapi_private.h - 1.11 - Remove vfsmount field from dm_fsreg_t. From owner-linux-xfs@oss.sgi.com Wed Jun 19 08:56:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JFu3nC029403 for ; Wed, 19 Jun 2002 08:56:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JFu3mb029402 for linux-xfs-outgoing; Wed, 19 Jun 2002 08:56:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JFtvnC029373 for ; Wed, 19 Jun 2002 08:55:58 -0700 Received: from thistle-e185.americas.sgi.com (thistle-e185.americas.sgi.com [128.162.185.204]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA91773 for ; Wed, 19 Jun 2002 10:58:51 -0500 (CDT) Received: from clink.americas.sgi.com (clink-eth.americas.sgi.com [128.162.2.8]) by thistle-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA50580 for ; Wed, 19 Jun 2002 10:58:51 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX-news) id KAA89920 for linux-xfs@oss.sgi.com; Wed, 19 Jun 2002 10:58:51 -0500 (CDT) Date: Wed, 19 Jun 2002 10:58:51 -0500 (CDT) From: Dean Roehrich Message-Id: <200206191558.KAA89920@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - synchronize libdm dmapi_kern.h with linux dmapi_kern.h X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jun 19 08:58:36 PDT 2002 Workarea: clink-eth.americas.sgi.com:/data/clink/a67/roehrich/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:121945a cmd/dmapi/include/dmapi_kern.h - 1.8 - synchronize libdm dmapi_kern.h with linux dmapi_kern.h From owner-linux-xfs@oss.sgi.com Wed Jun 19 11:21:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JILbnC016472 for ; Wed, 19 Jun 2002 11:21:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JILb0t016471 for linux-xfs-outgoing; Wed, 19 Jun 2002 11:21:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JILVnC016442 for ; Wed, 19 Jun 2002 11:21:32 -0700 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.194.22]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5JIOOg5181524 for ; Wed, 19 Jun 2002 14:24:25 -0400 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by westrelay01.boulder.ibm.com (8.11.1m3/NCO/VER6.2) with ESMTP id g5JIOOX91454 for ; Wed, 19 Jun 2002 12:24:24 -0600 Subject: Next Release of XFS To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Wed, 19 Jun 2002 13:24:21 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.10 |March 22, 2002) at 06/19/2002 12:24:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Do you have a target date for the next release of XFS (post-1.1)? Thanks, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 From owner-linux-xfs@oss.sgi.com Wed Jun 19 12:06:06 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JJ66nC017488 for ; Wed, 19 Jun 2002 12:06:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JJ65G8017487 for linux-xfs-outgoing; Wed, 19 Jun 2002 12:06:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from asc.ewu.edu (EWU74666.ewu.edu [146.187.124.29]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JJ5wnC017401 for ; Wed, 19 Jun 2002 12:05:58 -0700 Received: from KWINXP (unknown [146.187.13.99]) by asc.ewu.edu (Postfix) with ESMTP id 3271B2F6AF for ; Wed, 19 Jun 2002 14:36:07 -0400 (EDT) From: "Kaleb Pederson" To: Subject: acl-2.0.9 compile errors for EAs Date: Wed, 19 Jun 2002 12:08:52 -0700 Message-ID: <005001c217c4$c0686090$630dbb92@KWINXP> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm trying to compile acl-2.0.9 but running into problems. When doing a ./configure it says... ... checking for attr/xattr.h... yes checking for getxattr in -lattr... no FATAL ERROR: could not find a valid Extended Attributes library... I have installed attr-2.0.7 (both make install and make install-lib). If I do a 'nm /lib/libattr.so.1 | grep getxattr' I get: Addr T fgetxattr Addr T getxattr Addr T lgetxattr Which seems to indicate the library does support it but gcc won't link to it. (Maybe a RH-7.3 gcc-2.96 issue?). Any ideas why it won't compile or what I can do so that it will work? --Kaleb From owner-linux-xfs@oss.sgi.com Wed Jun 19 13:29:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JKTWnC021283 for ; Wed, 19 Jun 2002 13:29:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JKTVlT021282 for linux-xfs-outgoing; Wed, 19 Jun 2002 13:29:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JKTQnC021253 for ; Wed, 19 Jun 2002 13:29:26 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA95621; Wed, 19 Jun 2002 15:32:17 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA53784; Wed, 19 Jun 2002 15:32:17 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5JKUlW30661; Wed, 19 Jun 2002 15:30:47 -0500 Subject: Re: Next Release of XFS From: Steve Lord To: James A Goodwin Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 19 Jun 2002 15:30:47 -0500 Message-Id: <1024518647.27091.175.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-19 at 13:24, James A Goodwin wrote: > Do you have a target date for the next release of XFS (post-1.1)? Not at the moment, but given the multiple blocksize support which has been added and the version 2 log code, and the quantity of other changes, it might be time to think about one. There will not be any sort of decision on this for a few weeks, given various people are going to OLS next week, and the week after being the 4th of July. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Jun 19 15:56:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5JMuPnC025469 for ; Wed, 19 Jun 2002 15:56:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5JMuPvr025468 for linux-xfs-outgoing; Wed, 19 Jun 2002 15:56:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5JMuEnC025440 for ; Wed, 19 Jun 2002 15:56:14 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA06216 for ; Wed, 19 Jun 2002 15:59:12 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA01859; Thu, 20 Jun 2002 08:57:51 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5JMuHYN001251; Thu, 20 Jun 2002 08:56:17 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5JMuGB6001249; Thu, 20 Jun 2002 08:56:16 +1000 Date: Thu, 20 Jun 2002 08:56:16 +1000 From: Nathan Scott To: Kaleb Pederson Cc: Linux-xfs@oss.sgi.com Subject: Re: acl-2.0.9 compile errors for EAs Message-ID: <20020619225616.GB469@frodo> References: <005001c217c4$c0686090$630dbb92@KWINXP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005001c217c4$c0686090$630dbb92@KWINXP> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Jun 19, 2002 at 12:08:52PM -0700, Kaleb Pederson wrote: > I'm trying to compile acl-2.0.9 but running into problems. > > When doing a ./configure it says... > > ... > checking for attr/xattr.h... yes > checking for getxattr in -lattr... no > > FATAL ERROR: could not find a valid Extended Attributes library... > > I have installed attr-2.0.7 (both make install and make install-lib). > > If I do a 'nm /lib/libattr.so.1 | grep getxattr' I get: > > Addr T fgetxattr > Addr T getxattr > Addr T lgetxattr > > Which seems to indicate the library does support it but gcc won't link > to it. (Maybe a RH-7.3 gcc-2.96 issue?). > > Any ideas why it won't compile or what I can do so that it will work? > I find a useful way to diagnose this sort of problem is to run "sh -x ./configure", watch for the failing portion, then extract the gcc command line exactly as configure runs it along with the generated source file and do it by hand. That way you're able to see the error, and you have a fighting chance of diagnosing it. # sh -x ./configure ...[snip]... + echo -n 'checking for getxattr in -lattr... ' checking for getxattr in -lattr... + echo 'configure:1417: checking for getxattr in -lattr' ++ echo attr_getxattr ++ sed y%./+-%__p_% + ac_lib_var=attr_getxattr ++ echo '${ac_cv_lib_attr_getxattr+set}' + eval 'test "${ac_cv_lib_attr_getxattr+set}" = set' ++ test '' = set + ac_save_LIBS= + LIBS=-lattr + cat + eval echo configure:1436: '"${CC-cc}' -o 'conftest${ac_exeext}' '$CFLAGS' '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"' ++ echo configure:1436: 'gcc -o conftest -g -O2 conftest.c -lattr 1>&5' + test -s conftest + rm -rf conftest conftest.c + eval ac_cv_lib_attr_getxattr=yes ++ ac_cv_lib_attr_getxattr=yes + rm -f 'conftest*' So, you'll want to keep a copy of conftest.c before this last rm (edit the generated configure script and copy it somewhere safe) so that you can rerun the gcc line by hand. Once you have that, if the failure is non-obvious, post the gcc error message here. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Jun 19 18:48:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5K1mpnC026836 for ; Wed, 19 Jun 2002 18:48:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5K1mpwj026835 for linux-xfs-outgoing; Wed, 19 Jun 2002 18:48:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K1mknC026806 for ; Wed, 19 Jun 2002 18:48:46 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA02886 for ; Wed, 19 Jun 2002 18:51:44 -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 LAA18054 for linux-xfs@oss.sgi.com; Thu, 20 Jun 2002 11:50:09 +1000 (EST) Date: Thu, 20 Jun 2002 11:50:09 +1000 (EST) From: Nathan Scott Message-Id: <200206200150.LAA18054@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - quota sync up X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jun 19 18:49:14 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/linux-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122025a linux/fs/super.c - 1.76 linux/fs/quota.c - 1.12 - sync up with more recent versions of Jan's 2.4 quota patches -only very minor changes. From owner-linux-xfs@oss.sgi.com Wed Jun 19 23:14:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5K6EcnC029691 for ; Wed, 19 Jun 2002 23:14:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5K6Eclw029690 for linux-xfs-outgoing; Wed, 19 Jun 2002 23:14:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K6EKnC029662 for ; Wed, 19 Jun 2002 23:14:20 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id XAA00137 for ; Wed, 19 Jun 2002 23:17:17 -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 QAA68248 for linux-xfs@oss.sgi.com; Thu, 20 Jun 2002 16:15:57 +1000 (EST) Date: Thu, 20 Jun 2002 16:15:57 +1000 (EST) From: Nathan Scott Message-Id: <200206200615.QAA68248@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - Fix xqm & kdb interaction X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jun 19 21:51:39 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122030a cmd/xfsprogs/include/xfs_cap.h - 1.1 cmd/xfsprogs/include/xfs_mac.h - 1.1 cmd/xfsprogs/include/xfs_acl.h - 1.1 cmd/xfsprogs/doc/CHANGES - 1.70 cmd/xfsprogs/include/xfs_bit.h - 1.9 cmd/xfsprogs/include/libxfs.h - 1.14 cmd/xfsprogs/include/xfs_rtalloc.h - 1.6 cmd/xfsprogs/include/Makefile - 1.12 cmd/xfsprogs/include/xfs_cred.h - 1.12 cmd/xfsprogs/include/xfs_quota.h - 1.8 cmd/xfsprogs/repair/attr_repair.c - 1.12 cmd/xfsprogs/libxfs/xfs_rtalloc.c - 1.10 cmd/xfstests/tools/srcdiff - 1.19 - minor reorg of some bits of code to match kernel changes, no biggie. cmd/xfsdump/debian/changelog - 1.23 cmd/xfsprogs/debian/changelog - 1.46 - bump to latest version. Date: Wed Jun 19 22:33:04 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122032a linux/fs/xfs/xfs_acl.h - 1.15 - move data structure and macro declarations close to the code implementing them. linux/fs/xfs/xfs_cap.h - 1.1 linux/fs/xfs/xfs_mac.h - 1.3 - move data structure and macro declarations close to the code (not yet) implementing them. linux/fs/xfs/xfs_trans_dquot.c - 1.36 - make xfs_trans_mod_dquot_byino a void function, nothing wants an rval here. linux/fs/xfs/xfsidbg.c - 1.186 - fix quota manager data structure so that kdb module can get at it correctly. linux/fs/xfs/xfs_bit.h - 1.13 - remove a func decl for a func not in xfs_bit.c. linux/fs/xfs/xfs_vnodeops.c - 1.531 - xfs_trans_mod_dquot_byino is now void, don't cast to void. linux/fs/xfs/xfsquotasstubs.c - 1.16 - no longer need this - we compile away this stuff now rather than having stubs. file removed. linux/fs/xfs/xfs_rtalloc.h - 1.21 - remove some non-existent func decls. remove xfsrtstubs.c stubs. linux/fs/xfs/xfs_rtalloc.c - 1.73 - fix offsets for xfs_bit_t's and xfs_daddr_t's. linux/fs/xfs/Makefile - 1.143 - rework the quota and rt stub files so that we don't create a bunch of small functions, instead we just define them away via headers. add hook for cap. linux/fs/xfs/xfsrtstubs.c - 1.13 - no longer need this - we compile away this stuff now rather than having stubs. file removed. linux/fs/xfs/xfs_vfsops.c - 1.354 - fix quota manager data structure so that kdb module can get at it correctly. fix a couple of compiler warnings Keith pointed out. linux/fs/xfs/xfs_rtbit.c - 1.12 - this function has been subsumed by xfs_rtalloc, the only user of it. file removed. linux/fs/xfs/xfs_qm.h - 1.23 linux/fs/xfs/xfs_qm.c - 1.77 - fix quota manager data structure so that kdb module can get at it correctly. linux/fs/xfs/xfs_fsops.h - 1.21 - remove a func decl for a func not in xfs_fsops.c. linux/fs/xfs/xfs_quota.h - 1.27 - remove some non-existent func decls. remove xfsquotastubs.c stubs. linux/fs/xfs/linux/xfs_globals.c - 1.28 linux/fs/xfs/linux/Makefile - 1.53 - fix quota manager data structure so that kdb module can get at it correctly. linux/fs/xfs/linux/xfs_cred.h - 1.16 - split this out into acl.h, cap.h and mac.h to keep the ondisk data structs with the code implementing them. this file should go away eventually. linux/fs/xfs/linux/xfs_cred.c - 1.10 - comment out some of the unused fields in struct cred for now. linux/fs/xfs/linux/xfs_globals.h - 1.9 - fix quota manager data structure so that kdb module can get at it correctly. linux/fs/xfs/Makefile.in - 1.17 - rework the quota and rt stub files so that we don't create a bunch of small functions, instead we just define them away via headers. add hook for cap. linux/fs/xfs/linux/Makefile.in - 1.7 - fix quota manager data structure so that kdb module can get at it correctly. remove leftover reference to grio code. From owner-linux-xfs@oss.sgi.com Thu Jun 20 02:25:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5K9PrnC002569 for ; Thu, 20 Jun 2002 02:25:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5K9PrCP002568 for linux-xfs-outgoing; Thu, 20 Jun 2002 02:25:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5K9PjnC002540 for ; Thu, 20 Jun 2002 02:25:46 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5K9SjOl083968; Thu, 20 Jun 2002 11:28:46 +0200 (CEST) Message-Id: <4.3.2.7.2.20020620112540.03275ff8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jun 2002 11:28:46 +0200 To: Steve Lord From: Seth Mos Subject: Re: Next Release of XFS Cc: linux-xfs@oss.sgi.com In-Reply-To: <1024518647.27091.175.camel@jen.americas.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:30 19-6-2002 -0500, Steve Lord wrote: >On Wed, 2002-06-19 at 13:24, James A Goodwin wrote: > > Do you have a target date for the next release of XFS (post-1.1)? > >Not at the moment, but given the multiple blocksize support which has >been added and the version 2 log code, and the quantity of other >changes, it might be time to think about one. It would be a good idea to release a log conversion utility for this release so people have the ability to switch. Does the aligned log also benefit the normal case, or is this only for md raid5, lvm2 and evms? >There will not be any sort of decision on this for a few weeks, given >various people are going to OLS next week, and the week after being >the 4th of July. I'll see if I can do some testing with the CVS tree. Anything special you are looking for? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jun 20 03:23:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KANjnC003499 for ; Thu, 20 Jun 2002 03:23:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KANjfN003498 for linux-xfs-outgoing; Thu, 20 Jun 2002 03:23:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KANanC003464 for ; Thu, 20 Jun 2002 03:23:36 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id FAA97716; Thu, 20 Jun 2002 05:26:33 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-16.corp.sgi.com [134.15.64.16]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id FAA63827; Thu, 20 Jun 2002 05:26:31 -0500 (CDT) Subject: Re: Next Release of XFS From: Stephen Lord To: Seth Mos Cc: linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020620112540.03275ff8@pop.xs4all.nl> References: <4.3.2.7.2.20020620112540.03275ff8@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 20 Jun 2002 05:24:42 -0500 Message-Id: <1024568683.1172.4.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-20 at 04:28, Seth Mos wrote: > At 15:30 19-6-2002 -0500, Steve Lord wrote: > >On Wed, 2002-06-19 at 13:24, James A Goodwin wrote: > > > Do you have a target date for the next release of XFS (post-1.1)? > > > >Not at the moment, but given the multiple blocksize support which has > >been added and the version 2 log code, and the quantity of other > >changes, it might be time to think about one. > > It would be a good idea to release a log conversion utility for this > release so people have the ability to switch. Its on the list, it actually exists in the Irix code base, but there are a few constraints which need adding, and a lot of testing of what happens if you actually do this. The kernel may need work to catch some cases. > > Does the aligned log also benefit the normal case, or is this only for md > raid5, lvm2 and evms? > Yes, striping and larger iclogs help heavily accessed filesystems. Just striping to a 4K boundary helps a little bit, 64K iclogs helps more. > >There will not be any sort of decision on this for a few weeks, given > >various people are going to OLS next week, and the week after being > >the 4th of July. > > I'll see if I can do some testing with the CVS tree. Anything special you > are looking for? People who use raid5 and have volumes they can rebuild would be the best starting point. Last time we checked out the code there we got back to the same speed as ext2 if not slightly faster on a software raid5 device. That was with an internal log. Steve From owner-linux-xfs@oss.sgi.com Thu Jun 20 04:35:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KBZcnC004706 for ; Thu, 20 Jun 2002 04:35:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KBZb1p004705 for linux-xfs-outgoing; Thu, 20 Jun 2002 04:35:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KBZWnC004677 for ; Thu, 20 Jun 2002 04:35:32 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA00480 for ; Thu, 20 Jun 2002 06:38:29 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id GAA79620 for ; Thu, 20 Jun 2002 06:38:29 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5KBarB04267; Thu, 20 Jun 2002 06:36:53 -0500 Message-Id: <200206201136.g5KBarB04267@jen.americas.sgi.com> Date: Thu, 20 Jun 2002 06:36:53 -0500 Subject: TAKE - fix type conflict in min macro To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Fix to statvfs from Christoph Date: Thu Jun 20 04:37:23 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122036a linux/fs/xfs/xfs_vfsops.c - 1.355 - fix types in MIN macro From owner-linux-xfs@oss.sgi.com Thu Jun 20 06:03:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KD3InC011350 for ; Thu, 20 Jun 2002 06:03:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KD3I4t011349 for linux-xfs-outgoing; Thu, 20 Jun 2002 06:03:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KD39nC011321 for ; Thu, 20 Jun 2002 06:03:10 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5KD65e8034320 for ; Thu, 20 Jun 2002 09:06:05 -0400 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5KD63t116616 for ; Thu, 20 Jun 2002 09:06:03 -0400 Subject: xfsdump/restore Not Restoring Regions To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Thu, 20 Jun 2002 08:06:03 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.10 |March 22, 2002) at 06/20/2002 07:06:04 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We have been doing some testing with xfsdump/xfsrestore and have noticed that DMAPI regions present on files at dump time are not restored. We have installed the xfsdump-2.0.1-0 RPM and are running with XFS Release 1.1. Here's a quick rundown of our procedure: 1. # mount -t xfs -o dmapi /dev/hdb10 /mnt/tim3 2. # cd /mnt/tim3 3. Create a file called file1 with filesize 48891 bytes. 4. Create some regions on file1. 5. Verify the regions are really there. 6. # cd ../ 7. # xfsdump -f /tmp/xfsdump.out /mnt/tim3 . . . xfsdump: Dump Status: SUCCESS 8. # cd /mnt/tim3 9. # cd ../ 10. # umount /mnt/tim3 11. # mount -t xfs /dev/hdb10 /mnt/tim3_restore 12. # xfsrestore -f /tmp/xfsdump.out /mnt/tim3_restore . . . xfsrestore: Restore Status: SUCCESS 13. # umount /mnt/tim3_restore 14. # mount -t xfs -o dmapi /dev/hdb10 /mnt/tim3 15. # cd /mnt/tim3 16. /opt/hpss_xfs/bin/getdmattr /mnt/tim3/file1 17. Look for the regions that were on file1, and they are gone. Thanks, James Goodwin IBM Global Services - Federal jagoodwi@us.ibm.com (281) 336-2578 From owner-linux-xfs@oss.sgi.com Thu Jun 20 07:58:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KEwBnC015711 for ; Thu, 20 Jun 2002 07:58:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KEwBu6015710 for linux-xfs-outgoing; Thu, 20 Jun 2002 07:58:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KEw3nC015681 for ; Thu, 20 Jun 2002 07:58:04 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA85900; Thu, 20 Jun 2002 10:01:00 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA78231; Thu, 20 Jun 2002 10:01:00 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id KAA84583; Thu, 20 Jun 2002 10:01:00 -0500 (CDT) Message-Id: <200206201501.KAA84583@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump/restore Not Restoring Regions Date: Thu, 20 Jun 2002 10:01:00 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" >We have been doing some testing with xfsdump/xfsrestore and have noticed >that DMAPI regions present on files at dump time are not restored. We support just one region for the file, but I think you want to use the -D option on xfsrestore. Now you've reminded me of something else... You're probably using dm_set_dmattr() to attach HSM-specific info to the file. Our DMAPI implementation actually uses extended attributes to store that info. Because this is HSM-specific info, only your HSM can decode it. Now look at the -a option on xfsdump. That -a option would be useful to you, I'll bet. To do that, xfsdump knows how to decode the HSM-specific info that comes from our own HSM, "DMF". However, It doesn't know how to decode the info from your HSM. It may be time for you to submit some code to xfsdump. In the xfsdump and xfsrestore manpages the -A option is described from a DMF perspective, but I don't believe this is DMF-specific. Dean From owner-linux-xfs@oss.sgi.com Thu Jun 20 08:19:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KFJQnC016036 for ; Thu, 20 Jun 2002 08:19:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KFJPW1016035 for linux-xfs-outgoing; Thu, 20 Jun 2002 08:19:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KFJInC016006 for ; Thu, 20 Jun 2002 08:19:19 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA06061 for ; Thu, 20 Jun 2002 10:22:16 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA72868 for ; Thu, 20 Jun 2002 10:22:16 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5KFKcr09058; Thu, 20 Jun 2002 10:20:38 -0500 Message-Id: <200206201520.g5KFKcr09058@jen.americas.sgi.com> Date: Thu, 20 Jun 2002 10:20:38 -0500 Subject: TAKE - remove xfs_stickytest To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another function handled by the vfs layer. The call was actually already commented out, but the function itself was still there. Date: Thu Jun 20 08:21:23 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122053a linux/fs/xfs/xfs_vnodeops.c - 1.532 linux/fs/xfs/xfs_utils.c - 1.47 linux/fs/xfs/xfs_utils.h - 1.20 From owner-linux-xfs@oss.sgi.com Thu Jun 20 08:21:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KFL0nC016208 for ; Thu, 20 Jun 2002 08:21:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KFL04a016207 for linux-xfs-outgoing; Thu, 20 Jun 2002 08:21:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KFKcnC016178 for ; Thu, 20 Jun 2002 08:20:39 -0700 Received: from zcard00n.ca.nortel.com (zcard00n.ca.nortel.com [47.129.26.63]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5KFNYQ16236 for ; Thu, 20 Jun 2002 11:23:35 -0400 (EDT) Received: from zcard04u.ca.nortel.com ([47.129.242.92]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M68KVB0D; Thu, 20 Jun 2002 11:23:34 -0400 Received: from wmery000.ca.nortel.com ([47.131.36.101]) by zcard04u.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSZ5J9CJ; Thu, 20 Jun 2002 11:23:35 -0400 Subject: fseek returning incorrect values From: "Sean Kormilo" To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 Jun 2002 11:23:34 -0400 Message-Id: <1024586614.23218.46.camel@wmery000.ca.nortel.com> Mime-Version: 1.0 X-Spam-Status: No, hits=0.8 required=5.0 tests=SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm running XFS under PowerPC linux. Kernel version 2.4.5 with XFS 1.0.1 release code patched in. The problem is that fseek() to the end of the file is returning a value which is actually past the end of the file. I'm attaching the code used to generate this error to this email, and some sample runs on my system. The actual problem was discovered with a zip archive utility, but I wanted a simpler way to reproduce it. Any ideas? Is there a patch I can apply to my 2.4.5 / XFS 1.0.1 to fix this? Test on ext2 filesystem: STORM-47.131.125.203> seektest /testfs/file 1 STORM-47.131.125.203> ls -l /testfs/file -rw-rw-rw- 1 root root 2048 Jun 20 07:04 /testfs/file STORM-47.131.125.203> seektest /testfs/file 2 STORM-47.131.125.203> ls -l /testfs/file -rw-rw-rw- 1 root root 4096 Jun 20 07:04 /testfs/file STORM-47.131.125.203> seektest /testfs/file 3 STORM-47.131.125.203> ls -l /testfs/file -rw-rw-rw- 1 root root 6144 Jun 20 07:04 /testfs/file STORM-47.131.125.203> seektest /testfs/file 4 STORM-47.131.125.203> ls -l /testfs/file -rw-rw-rw- 1 root root 8192 Jun 20 07:06 /testfs/file STORM-47.131.125.203> hexdump /testfs/file 100148c0 0101 0101 0101 0101 0101 0101 0101 0101 * 100148d8 Running the same test on an XFS filesystem: STORM-47.131.125.203> seektest /xfstest/file 1 STORM-47.131.125.203> ls -l /xfstest/file -rw-rw-rw- 1 root root 2048 Jun 20 07:05 /xfstest/file STORM-47.131.125.203> seektest /xfstest/file 2 STORM-47.131.125.203> ls -l /xfstest/file -rw-rw-rw- 1 root root 4096 Jun 20 07:05 /xfstest/file STORM-47.131.125.203> seektest /xfstest/file 3 curroff != totalsize : 8192 != 6144 STORM-47.131.125.203> ls -l /xfstest/file -rw-rw-rw- 1 root root 6144 Jun 20 07:05 /xfstest/file STORM-47.131.125.203> seektest /xfstest/file 4 curroff != totalsize : 8192 != 6144 currentoffset != totalsizewritten 8192 != 6144 curroff != totalsize : 12288 != 8192 STORM-47.131.125.203> ls -l /xfstest/file -rw-rw-rw- 1 root root 10240 Jun 20 07:05 /xfstest/file STORM-47.131.125.203> hexdump /xfstest/file 100148c0 0101 0101 0101 0101 0101 0101 0101 0101 * 100148c0 0000 0000 0000 0000 0000 0000 0000 0000 * 100148d8 0101 0101 0101 0101 0101 0101 0101 0101 * 100148d8 The source code for the seektest program follows: #include #include #include int main(int argc, char* argv[]) { char buffer[1024]; FILE* fp; unsigned long i; unsigned long fsize; unsigned long totalsize = 0; unsigned long wrotesize; unsigned long curroff; if( argc != 3 ) { printf("Usage: %s \n", argv[0]); return(-1); } memset(buffer, 1, 1024); fsize = atoi( argv[2] ); unlink( argv[1] ); fp = fopen( argv[1], "w+"); if( fp == 0 ) { perror("fopen failed"); return(-1); } for(i = 0; i; Thu, 20 Jun 2002 10:23:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KHNUOm031621 for linux-xfs-outgoing; Thu, 20 Jun 2002 10:23:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KHNOnC031593 for ; Thu, 20 Jun 2002 10:23:24 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA00611; Thu, 20 Jun 2002 12:26:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA46550; Thu, 20 Jun 2002 12:26:20 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5KHOf717880; Thu, 20 Jun 2002 12:24:41 -0500 Subject: Re: fseek returning incorrect values From: Steve Lord To: Sean Kormilo Cc: linux-xfs@oss.sgi.com In-Reply-To: <1024586614.23218.46.camel@wmery000.ca.nortel.com> References: <1024586614.23218.46.camel@wmery000.ca.nortel.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 20 Jun 2002 12:24:41 -0500 Message-Id: <1024593881.5039.64.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.6 required=5.0 tests=IN_REP_TO,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-20 at 10:23, Sean Kormilo wrote: > Hi, > > I'm running XFS under PowerPC linux. Kernel version 2.4.5 with XFS 1.0.1 > release code patched in. You are going to hate me for this, but there is no way we can support problems in a kernel this old. Can you possibly try a recent kernel, we definitely changed the lseek path, but I cannot remember when. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jun 20 10:26:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KHQ8nC031746 for ; Thu, 20 Jun 2002 10:26:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KHQ8Wu031743 for linux-xfs-outgoing; Thu, 20 Jun 2002 10:26:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KHQ4nC031705 for ; Thu, 20 Jun 2002 10:26:04 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA08450 for ; Thu, 20 Jun 2002 12:29:02 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA63805 for ; Thu, 20 Jun 2002 12:28:58 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5KHRJQ17957; Thu, 20 Jun 2002 12:27:19 -0500 Message-Id: <200206201727.g5KHRJQ17957@jen.americas.sgi.com> Date: Thu, 20 Jun 2002 12:27:19 -0500 Subject: TAKE - remove unused globals To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More small housekeeping stuff Date: Thu Jun 20 10:27:35 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122064a linux/fs/xfs/linux/xfs_globals.c - 1.29 linux/fs/xfs/linux/xfs_globals.h - 1.10 From owner-linux-xfs@oss.sgi.com Thu Jun 20 10:41:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KHfMnC032229 for ; Thu, 20 Jun 2002 10:41:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KHfMSV032228 for linux-xfs-outgoing; Thu, 20 Jun 2002 10:41:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from CATHY ([146.187.13.233]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KHf6nC032196 for ; Thu, 20 Jun 2002 10:41:06 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by CATHY (8.11.6/8.11.6) id g5KHiIM05055; Thu, 20 Jun 2002 10:44:18 -0700 Content-Type: text/plain; charset="iso-8859-1" From: kibab@EWU74666.ewu.edu To: Nathan Scott Subject: Re: acl-2.0.9 compile errors for EAs Date: Thu, 20 Jun 2002 10:44:17 -0700 User-Agent: KMail/1.4.1 References: <005001c217c4$c0686090$630dbb92@KWINXP> <20020619225616.GB469@frodo> In-Reply-To: <20020619225616.GB469@frodo> MIME-Version: 1.0 Cc: linux-xfs@oss.sgi.com Message-Id: <200206201044.17675.kibab@asc.ewu.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5KHf6nC032199 X-Spam-Status: No, hits=-3.8 required=5.0 tests=IN_REP_TO,NO_REAL_NAME version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday 19 June 2002 03:56 pm, Nathan Scott wrote: ... > > Any ideas why it won't compile or what I can do so that it will work? > > I find a useful way to diagnose this sort of problem is to run > "sh -x ./configure", watch for the failing portion, then extract > the gcc command line exactly as configure runs it along with the > generated source file and do it by hand. That way you're able to > see the error, and you have a fighting chance of diagnosing it. > > # sh -x ./configure > ...[snip]... > + echo -n 'checking for getxattr in -lattr... ' > checking for getxattr in -lattr... + echo 'configure:1417: checking for > getxattr in -lattr' ++ echo attr_getxattr > ++ sed y%./+-%__p_% > + ac_lib_var=attr_getxattr > ++ echo '${ac_cv_lib_attr_getxattr+set}' > + eval 'test "${ac_cv_lib_attr_getxattr+set}" = set' > ++ test '' = set > + ac_save_LIBS= > + LIBS=-lattr > + cat > + eval echo configure:1436: '"${CC-cc}' -o 'conftest${ac_exeext}' '$CFLAGS' > '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"' ++ echo > configure:1436: 'gcc -o conftest -g -O2 conftest.c -lattr 1>&5' + test > -s conftest > + rm -rf conftest conftest.c > + eval ac_cv_lib_attr_getxattr=yes > ++ ac_cv_lib_attr_getxattr=yes > + rm -f 'conftest*' > > > So, you'll want to keep a copy of conftest.c before this last rm > (edit the generated configure script and copy it somewhere safe) > so that you can rerun the gcc line by hand. Once you have that, > if the failure is non-obvious, post the gcc error message here. > > cheers. I tried the sh -x ./configure and it gaves me the following: ... + eval echo configure:1436: '"${CC-cc}' -o 'conftest${ac_exeext}' '$CFLAGS' '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"' ++ echo configure:1436: 'gcc -o conftest -g -O2 conftest.c -lattr 1>&5' + echo 'configure: failed program was:' + cat conftest.c + rm -rf conftest.c + eval ac_cv_lib_attr_getxattr=no ++ ac_cv_lib_attr_getxattr=no + rm -f 'conftest*' + LIBS= ++ echo '$ac_cv_lib_attr_getxattr' + eval 'test "$ac_cv_lib_attr_getxattr" = yes' ++ test no = yes + echo no no + echo + echo 'FATAL ERROR: could not find a valid Extended Attributes library.' FATAL ERROR: could not find a valid Extended Attributes library. + echo 'Install either the libattr (rpm) or the libattr1 (deb) package.' Install either the libattr (rpm) or the libattr1 (deb) package. + echo 'Alternatively, run "make install-lib" from the attr source.' Alternatively, run "make install-lib" from the attr source. + exit 1 The test program that it is trying to use is: #line 1425 "configure" #include "confdefs.h" /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char getxattr(); int main() { getxattr() ; return 0; } When compiled by: gcc -o conftest -g -O2 conftest.c -lattr it says: /usr/bin/ld: cannot find -lattr But... after running ldconfig and with ld.so.conf setup correctly it still doesn't find it (a RH7.3 problem) so I added -L/lib and then it gave me the following: [root@localhost acl-2.0.9]# gcc -L/lib -o conftest -g -O2 conftest.c /tmp/cclRzSPV.o: In function `main': /root/acl-2.0.9/configure:1432: undefined reference to `getxattr' collect2: ld returned 1 exit status [root@localhost acl-2.0.9]# nm /lib/libattr.so.1 | grep getxattr 0000144c T fgetxattr 000013dc T getxattr 00001414 T lgetxattr Apparently it is in the text (data) section, so I would presume it is a valid call, but I'm not sure as I haven't played with nm enough to know how a valid function reference is going to show up. Anyway, I still can't get acl-2.0.9 installed after installing attr-2.0.7 (make installl install-lib). I'd appreciate any suggestions. Thanks. --Kaleb From owner-linux-xfs@oss.sgi.com Thu Jun 20 11:42:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KIg5nC007106 for ; Thu, 20 Jun 2002 11:42:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KIg5Sj007105 for linux-xfs-outgoing; Thu, 20 Jun 2002 11:42:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KIfunC007077 for ; Thu, 20 Jun 2002 11:41:56 -0700 Received: from zcard00m.ca.nortel.com (zcard00m.ca.nortel.com [47.129.26.62]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g5KIioC18724; Thu, 20 Jun 2002 14:44:51 -0400 (EDT) Received: from zcard04u.ca.nortel.com ([47.129.242.92]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NFR0W8Y1; Thu, 20 Jun 2002 14:44:50 -0400 Received: from wmery000.ca.nortel.com ([47.131.36.101]) by zcard04u.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MSZ5J9K6; Thu, 20 Jun 2002 14:44:50 -0400 Subject: Re: fseek returning incorrect values X-Sybari-Space: 00000000 00000000 00000000 From: "Sean Kormilo" To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1024593881.5039.64.camel@jen.americas.sgi.com> References: <1024586614.23218.46.camel@wmery000.ca.nortel.com> <1024593881.5039.64.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.5 Date: 20 Jun 2002 14:44:50 -0400 Message-Id: <1024598691.23217.86.camel@wmery000.ca.nortel.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, I don't hate you. How could I hate the principal engineer for Linux XFS? ;) It isn't feasible for me to change kernels at this point. The downside to being on PowerPC hardware is that I have some 3rd party (read non-open source) dependencies that prevent me upgrading from 2.4.5 until sometime in the fall. I've asked the application owner to make a change to not seek past the end of the file, but to write dummy data instead to achieve the same effect. My only concern is that there may be other applications which attempt to do the same thing and are inadvertently causing file corruption. If you should happen to think of (or happen to run across) the lseek path change, and think it could be patched back into the 1.0.1 XFS release, please let me know. Thanks! Sean. > On Thu, 2002-06-20 at 10:23, Sean Kormilo wrote: > > Hi, > > > > I'm running XFS under PowerPC linux. Kernel version 2.4.5 with XFS 1.0.1 > > release code patched in. > > You are going to hate me for this, but there is no way we can support > problems in a kernel this old. Can you possibly try a recent kernel, > we definitely changed the lseek path, but I cannot remember when. > > Steve > > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com -- Sean C. Kormilo, SAM21/STORM Software Architect, Nortel Networks email: skormilo@nortelnetworks.com From owner-linux-xfs@oss.sgi.com Thu Jun 20 12:21:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KJLonC007834 for ; Thu, 20 Jun 2002 12:21:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KJLoR9007833 for linux-xfs-outgoing; Thu, 20 Jun 2002 12:21:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KJLinC007800 for ; Thu, 20 Jun 2002 12:21:44 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA07061 for ; Thu, 20 Jun 2002 14:24:42 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA97394 for ; Thu, 20 Jun 2002 14:24:42 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5KJN2T25375; Thu, 20 Jun 2002 14:23:02 -0500 Message-Id: <200206201923.g5KJN2T25375@jen.americas.sgi.com> Date: Thu, 20 Jun 2002 14:23:02 -0500 Subject: TAKE - small vnode code cleanups To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 20 12:24:14 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122082a linux/fs/xfs/xfs_inode.c - 1.341 - use linux version of WRITEALLOWED check here linux/fs/xfs/linux/xfs_vnode.c - 1.83 - Make vn_address an inline. define VN_LOCK here directly linux/include/linux/xfs_fs_i.h - 1.9 - fix a macro define to take an expression as a parameter linux/fs/xfs/linux/xfs_vnode.h - 1.42 - define vn_address as an inline, remove VN_LOCK and WRITEALLOWED macros linux/fs/xfs_dmapi/xfsjunk.c - 1.9 - remove vn_address it is inline now From owner-linux-xfs@oss.sgi.com Thu Jun 20 13:22:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KKMunC009062 for ; Thu, 20 Jun 2002 13:22:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KKMu0O009061 for linux-xfs-outgoing; Thu, 20 Jun 2002 13:22:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web13101.mail.yahoo.com (web13101.mail.yahoo.com [216.136.174.146]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KKMknC009032 for ; Thu, 20 Jun 2002 13:22:46 -0700 Message-ID: <20020620202550.87751.qmail@web13101.mail.yahoo.com> Received: from [208.35.40.2] by web13101.mail.yahoo.com via HTTP; Thu, 20 Jun 2002 13:25:50 PDT Date: Thu, 20 Jun 2002 13:25:50 -0700 (PDT) From: Ravi Wijayaratne Subject: Case of the dissapearing files! To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.5 required=5.0 tests=PLING version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi All, I have an xfs root file system. I increased the size of the inodes to 1024 by using mkfs -i size=1024 option. After that I see some of the newly created files in the "/" directory vanishing when I reboot the system gracefully. However the newly created files in subdirectories are persistent accross reboots. If I powercycle the system (ungraceful shutdown) the newly created files in the "/" directory appears. I ran xfs_db to examine the inode of the root directory. I see that when I create a file (even non empty) the files info (inode num, name etc) does not appear in the inodes u.sfdir2.list[x].xxxx components. My guess is that the file creation in the "/" directory gets registered in the xfs meta data logs but does not update the incore inode and hence when the system is shutdown does not write to the disk inodes. When the system is abruptly shutdown xfs_repair reinstates the files. When I run xfs_repair -n on the root partition it complains about unlinked inodes. Furthermore /proc/slabinfo tells me that the object size is 436 bytes for the xfs_inode slab cache. My questions are (a). What is the maximum size for xfs_inode ? 1024 too big ? (b). Why is the behavior different for "/" directory. For instance "/tmp" or "/etc" works fine and I can create and delete files in these directories. Thanks Ravi ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-linux-xfs@oss.sgi.com Thu Jun 20 13:30:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KKUQnC009262 for ; Thu, 20 Jun 2002 13:30:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KKUQOW009261 for linux-xfs-outgoing; Thu, 20 Jun 2002 13:30:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KKULnC009232 for ; Thu, 20 Jun 2002 13:30:21 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA07035 for ; Thu, 20 Jun 2002 15:33:20 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA05556 for ; Thu, 20 Jun 2002 15:33:19 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5KKVd330013; Thu, 20 Jun 2002 15:31:39 -0500 Message-Id: <200206202031.g5KKVd330013@jen.americas.sgi.com> Date: Thu, 20 Jun 2002 15:31:39 -0500 Subject: TAKE - unifdef some dmapi code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 20 13:31:36 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122088a linux/fs/xfs/xfs_dmapi.h - 1.24 - mark going into dmapi calls as being unlikely linux/fs/xfs/xfs_log_recover.c - 1.235 - unifdef some dmapi calls, and add a recovery check which was missing linux/fs/xfs/linux/xfs_lrw.c - 1.150 - unifdef some dmapi calls From owner-linux-xfs@oss.sgi.com Thu Jun 20 13:30:51 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KKUpnC009315 for ; Thu, 20 Jun 2002 13:30:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KKUpES009314 for linux-xfs-outgoing; Thu, 20 Jun 2002 13:30:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KKUfnC009271 for ; Thu, 20 Jun 2002 13:30:41 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA04607; Thu, 20 Jun 2002 15:33:40 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA67877; Thu, 20 Jun 2002 15:33:39 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5KKVxE30021; Thu, 20 Jun 2002 15:31:59 -0500 Subject: Re: Case of the dissapearing files! From: Steve Lord To: Ravi Wijayaratne Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020620202550.87751.qmail@web13101.mail.yahoo.com> References: <20020620202550.87751.qmail@web13101.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 20 Jun 2002 15:31:59 -0500 Message-Id: <1024605119.5039.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,PLING,SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-20 at 15:25, Ravi Wijayaratne wrote: > Hi All, > > I have an xfs root file system. > > I increased the size of the inodes to 1024 by using > mkfs -i size=1024 option. After that I see some of the > newly created files in the "/" directory vanishing > when I reboot the system gracefully. However the newly > created files in subdirectories are persistent > accross > reboots. > > If I powercycle the system (ungraceful shutdown) the > newly created files in the "/" directory appears. > > I ran xfs_db to examine the inode of the root > directory. I see that when I create a file (even non > empty) the files info (inode num, name etc) does not > appear in the inodes u.sfdir2.list[x].xxxx components. > > My guess is that the file creation in the "/" > directory > gets registered in the xfs meta data logs but does not > update the incore inode and hence when the system is > shutdown does not write to the disk inodes. When the > system is abruptly shutdown xfs_repair reinstates the > files. > > When I run xfs_repair -n on the root partition it > complains about unlinked inodes. > > Furthermore /proc/slabinfo tells me that the object > size is 436 bytes for the xfs_inode slab cache. > > My questions are > > (a). What is the maximum size for xfs_inode ? 1024 too > big ? > > (b). Why is the behavior different for "/" directory. > For instance "/tmp" or "/etc" works fine and I can > create and delete files in these directories. It does sound a little like the root inode is not getting flushed during unmount. If your root directoy size is less than 4K then it is all within the inode. Is this a recent kernel? Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Jun 20 13:40:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KKeFnC009615 for ; Thu, 20 Jun 2002 13:40:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KKeEVi009614 for linux-xfs-outgoing; Thu, 20 Jun 2002 13:40:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web13104.mail.yahoo.com (web13104.mail.yahoo.com [216.136.174.149]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KKe0nC009581 for ; Thu, 20 Jun 2002 13:40:00 -0700 Message-ID: <20020620204303.34013.qmail@web13104.mail.yahoo.com> Received: from [208.35.40.2] by web13104.mail.yahoo.com via HTTP; Thu, 20 Jun 2002 13:43:03 PDT Date: Thu, 20 Jun 2002 13:43:03 -0700 (PDT) From: Ravi Wijayaratne Subject: Re: Case of the dissapearing files! To: Steve Lord Cc: linux-xfs@oss.sgi.com In-Reply-To: <1024605119.5039.102.camel@jen.americas.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=-3.9 required=5.0 tests=IN_REP_TO,PLING version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, kernel version is 2.4.18-xfs-1.1 If I create a diretory in the "/" it remains after a reboot and gets to the inode. I verified the inode info with xfs_db. thanks Ravi --- Steve Lord wrote: > On Thu, 2002-06-20 at 15:25, Ravi Wijayaratne wrote: > > Hi All, > > > > I have an xfs root file system. > > > > I increased the size of the inodes to 1024 by > using > > mkfs -i size=1024 option. After that I see some of > the > > newly created files in the "/" directory vanishing > > when I reboot the system gracefully. However the > newly > > created files in subdirectories are persistent > > accross > > reboots. > > > > If I powercycle the system (ungraceful shutdown) > the > > newly created files in the "/" directory appears. > > > > I ran xfs_db to examine the inode of the root > > directory. I see that when I create a file (even > non > > empty) the files info (inode num, name etc) does > not > > appear in the inodes u.sfdir2.list[x].xxxx > components. > > > > My guess is that the file creation in the "/" > > directory > > gets registered in the xfs meta data logs but does > not > > update the incore inode and hence when the system > is > > shutdown does not write to the disk inodes. When > the > > system is abruptly shutdown xfs_repair reinstates > the > > files. > > > > When I run xfs_repair -n on the root partition it > > complains about unlinked inodes. > > > > Furthermore /proc/slabinfo tells me that the > object > > size is 436 bytes for the xfs_inode slab cache. > > > > My questions are > > > > (a). What is the maximum size for xfs_inode ? 1024 > too > > big ? > > > > (b). Why is the behavior different for "/" > directory. > > For instance "/tmp" or "/etc" works fine and I can > > create and delete files in these directories. > > > It does sound a little like the root inode is not > getting > flushed during unmount. If your root directoy size > is less > than 4K then it is all within the inode. Is this a > recent > kernel? > > Steve > > > -- > > Steve Lord > voice: +1-651-683-3511 > Principal Engineer, Filesystem Software > email: lord@sgi.com ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-linux-xfs@oss.sgi.com Thu Jun 20 13:49:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KKn3nC009833 for ; Thu, 20 Jun 2002 13:49:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KKn3cq009832 for linux-xfs-outgoing; Thu, 20 Jun 2002 13:49:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KKmwnC009804 for ; Thu, 20 Jun 2002 13:48:58 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA08315 for ; Thu, 20 Jun 2002 15:51:57 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA83147 for ; Thu, 20 Jun 2002 15:51:57 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5KKoHS30485; Thu, 20 Jun 2002 15:50:17 -0500 Message-Id: <200206202050.g5KKoHS30485@jen.americas.sgi.com> Date: Thu, 20 Jun 2002 15:50:17 -0500 Subject: TAKE - tweak inode handling To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just some small optimizations Date: Thu Jun 20 13:49:07 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122091a linux/fs/xfs/linux/xfs_iops.c - 1.153 From owner-linux-xfs@oss.sgi.com Thu Jun 20 13:58:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KKw7nC010931 for ; Thu, 20 Jun 2002 13:58:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KKw72A010930 for linux-xfs-outgoing; Thu, 20 Jun 2002 13:58:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rope.americas (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KKw1nC010900 for ; Thu, 20 Jun 2002 13:58:02 -0700 Received: (from roehrich@localhost) by rope.americas (8.11.2/8.11.2) id g5KL0od08886 for linux-xfs@oss.sgi.com; Thu, 20 Jun 2002 16:00:50 -0500 Date: Thu, 20 Jun 2002 16:00:50 -0500 From: Dean Roehrich Message-Id: <200206202100.g5KL0od08886@rope.americas> Subject: TAKE - fix some typos in dmapi code X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 20 14:00:33 PDT 2002 Workarea: rope.americas.sgi.com:/ptmp/roehrich/2.4.x-xfs-c The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122096a linux/fs/xfs_dmapi/xfsjunk.c - 1.10 - fix typos From owner-linux-xfs@oss.sgi.com Thu Jun 20 15:30:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KMUcnC012670 for ; Thu, 20 Jun 2002 15:30:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KMUclr012669 for linux-xfs-outgoing; Thu, 20 Jun 2002 15:30:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KMUWnC012641 for ; Thu, 20 Jun 2002 15:30:32 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17LAUf-00060o-00 for ; Fri, 21 Jun 2002 01:33:33 +0300 Date: Fri, 21 Jun 2002 01:33:33 +0300 To: linux-xfs@oss.sgi.com Subject: about the mmap problem Message-ID: <20020620223333.GA23109@banix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is the problem really fixed? This doesn't look like it.. root@jaenoe:/ > /usr/src/xfs-cmd/mapcheck boot boot/map 13 files scanned 1 files fixed root@jaenoe:/ > lilo Added linux * Added linux.old root@jaenoe:/ > /usr/src/xfs-cmd/mapcheck boot boot/map 13 files scanned 1 files fixed From owner-linux-xfs@oss.sgi.com Thu Jun 20 16:14:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KNEknC013154 for ; Thu, 20 Jun 2002 16:14:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KNEk0c013153 for linux-xfs-outgoing; Thu, 20 Jun 2002 16:14:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KNEenC013125 for ; Thu, 20 Jun 2002 16:14:41 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA09364; Thu, 20 Jun 2002 18:17:39 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-47.corp.sgi.com [134.15.64.47]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id SAA24107; Thu, 20 Jun 2002 18:17:38 -0500 (CDT) Subject: Re: about the mmap problem From: Stephen Lord To: Juha K Kallio Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020620223333.GA23109@banix> References: <20020620223333.GA23109@banix> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 20 Jun 2002 18:15:49 -0500 Message-Id: <1024614950.1168.0.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-20 at 17:33, Juha K Kallio wrote: > Is the problem really fixed? This doesn't look like it.. > > root@jaenoe:/ > /usr/src/xfs-cmd/mapcheck boot > boot/map > 13 files scanned 1 files fixed > root@jaenoe:/ > lilo > Added linux * > Added linux.old > root@jaenoe:/ > /usr/src/xfs-cmd/mapcheck boot > boot/map > 13 files scanned 1 files fixed Are you running the fixed kernel as well? Steve From owner-linux-xfs@oss.sgi.com Thu Jun 20 16:53:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5KNr5nC013480 for ; Thu, 20 Jun 2002 16:53:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5KNr4PH013479 for linux-xfs-outgoing; Thu, 20 Jun 2002 16:53:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5KNqtnC013451 for ; Thu, 20 Jun 2002 16:52:55 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id QAA02958 for ; Thu, 20 Jun 2002 16:55:56 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA13697; Fri, 21 Jun 2002 09:54:32 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5KNqtOM001162; Fri, 21 Jun 2002 09:52:55 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5KNqsHu001160; Fri, 21 Jun 2002 09:52:54 +1000 Date: Fri, 21 Jun 2002 09:52:54 +1000 From: Nathan Scott To: kibab@EWU74666.ewu.edu Cc: linux-xfs@oss.sgi.com Subject: Re: acl-2.0.9 compile errors for EAs Message-ID: <20020620235254.GA480@frodo> References: <005001c217c4$c0686090$630dbb92@KWINXP> <20020619225616.GB469@frodo> <200206201044.17675.kibab@asc.ewu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200206201044.17675.kibab@asc.ewu.edu> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Jun 20, 2002 at 10:44:17AM -0700, kibab@EWU74666.ewu.edu wrote: > ... > > I tried the sh -x ./configure and it gaves me the following: > ... > + eval echo configure:1436: '"${CC-cc}' -o 'conftest${ac_exeext}' '$CFLAGS' > '$CPPFLAGS' '$LDFLAGS' 'conftest.$ac_ext' '$LIBS' '1>&5"' > ++ echo configure:1436: 'gcc -o conftest -g -O2 conftest.c -lattr 1>&5' > The test program that it is trying to use is: > > #line 1425 "configure" > #include "confdefs.h" > /* Override any gcc2 internal prototype to avoid an error. */ > /* We use char because int might match the return type of a gcc2 > builtin and then its argument prototype would still apply. */ > char getxattr(); > > int main() { > getxattr() > ; return 0; } > > When compiled by: gcc -o conftest -g -O2 conftest.c -lattr > it says: /usr/bin/ld: cannot find -lattr > > But... after running ldconfig and with ld.so.conf setup correctly it still > doesn't find it (a RH7.3 problem) so I added -L/lib and then it gave me the [Hmm.. something very suspect about your compiler setup if you have to do that! -- maybe a gcc installation/configuration problem?] > following: > > [root@localhost acl-2.0.9]# gcc -L/lib -o conftest -g -O2 conftest.c > /tmp/cclRzSPV.o: In function `main': > /root/acl-2.0.9/configure:1432: undefined reference to `getxattr' > collect2: ld returned 1 exit status You seem to be missing -lattr on the above command line. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Jun 20 17:03:58 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5L03wnC013793 for ; Thu, 20 Jun 2002 17:03:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5L03w89013791 for linux-xfs-outgoing; Thu, 20 Jun 2002 17:03:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mathserv.math.ohio-state.edu (mathserv.math.ohio-state.edu [128.146.111.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5L03hnC013761 for ; Thu, 20 Jun 2002 17:03:43 -0700 Received: from mathserv.math.ohio-state.edu (localhost [127.0.0.1]) by mathserv.math.ohio-state.edu (8.12.3/8.12.3) with ESMTP id g5L06lZL008710 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 20 Jun 2002 20:06:47 -0400 Received: (from alden@localhost) by mathserv.math.ohio-state.edu (8.12.3/8.12.3/Submit) id g5L06lx8008708 for linux-xfs@oss.sgi.com; Thu, 20 Jun 2002 20:06:47 -0400 Date: Thu, 20 Jun 2002 20:06:47 -0400 From: Dave Alden To: linux-xfs@oss.sgi.com Subject: Kernel oops with XFS and NFS Message-ID: <20020620200647.A8102@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="X1bOJ3K7DJ5YkBrT" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i X-RAVMilter-Version: 8.3.2(snapshot 20020213) (mathserv) X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, Help. I'm having nfsd oops on my system. I'm currently running 2.4.18-xfs-1.1, but I've tried the CVS as of about 8:30am this morning (06/20/2002) with similar results. I'm new to this, but from what I gather I'm supposed to run ksymoops on the output (retrieved from dmesg). I've attached the output of a "ksymoops dmesg.out". Please help me, this system is crashing at least once a day. This system was totally stable for the past 4 months with 50 users (~100G), so I added the remainder of my userbase on Tuesday (an additional 450 users, for a total of 120G). ...thnx, ...dave alden ps I tried recompiling with the NFS server as a module, but I keep getting: Starting NFS daemon: nfssvc: Function not implemented when I tried to start nfs (with "/etc/init.d/nfs start"). I was hoping maybe I'd be able to just unload and reload the module whenever it oops'ed instead of rebooting. :-( --X1bOJ3K7DJ5YkBrT Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ksymoops.out" ksymoops 2.4.1 on i686 2.4.18-xfs-1.1. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.18-xfs-1.1/ (default) -m /boot/System.map-2.4.18-xfs-1.1 (default) Warning: You did not tell me where to find symbol information. I will assume that the log matches the kernel and modules that are running right now and I'll use the default options above for symbol resolution. If the current kernel and/or modules do not match the log, you can get more accurate output by telling me the kernel version and where to find map, modules, ksyms etc. ksymoops -h explains the options. Oops: 0000 CPU: 0 EIP: 0010:[] Tainted: P Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010246 eax: 00000000 ebx: ffffffe8 ecx: c7b9f978 edx: 00000000 esi: c0340300 edi: 00000000 ebp: c7b9f964 esp: f6d65dac ds: 0018 es: 0018 ss: 0018 Process nfsd (pid: 947, stackpage=f6d65000) Stack: 00000000 00000000 c71ee55c 00000000 00000008 c71ee55c c01f6c51 f783b800 00000000 2a00fa48 00000000 00000000 f6d65e38 00000000 00000000 00000000 00000008 00000002 f6d65e5c 00000080 c71ee574 c71ee55c 00000008 c71ee55c Call Trace: [] [] [] [] [] [] [] [] [] [] [] [] [] [] Code: 66 83 bb 4a 01 00 00 00 75 0f 66 83 a3 3c 01 00 00 f7 53 e8 >>EIP; c01e1687 <===== Trace; c01f6c51 Trace; c01fb1d6 Trace; c0207f05 Trace; c0149307 Trace; c0189f93 Trace; c018a3c9 Trace; c018a6f9 Trace; c018b999 Trace; c0190ecc Trace; c0188576 Trace; c02da559 Trace; c018838f Trace; c0105866 Trace; c01881a0 Code; c01e1687 00000000 <_EIP>: Code; c01e1687 <===== 0: 66 83 bb 4a 01 00 00 cmpw $0x0,0x14a(%ebx) <===== Code; c01e168e 7: 00 Code; c01e168f 8: 75 0f jne 19 <_EIP+0x19> c01e16a0 Code; c01e1691 a: 66 83 a3 3c 01 00 00 andw $0xfffffff7,0x13c(%ebx) Code; c01e1698 11: f7 Code; c01e1699 12: 53 push %ebx Code; c01e169a 13: e8 00 00 00 00 call 18 <_EIP+0x18> c01e169f 1 warning issued. Results may not be reliable. --X1bOJ3K7DJ5YkBrT-- From owner-linux-xfs@oss.sgi.com Thu Jun 20 17:13:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5L0DlnC014010 for ; Thu, 20 Jun 2002 17:13:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5L0Dlck014009 for linux-xfs-outgoing; Thu, 20 Jun 2002 17:13:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5L0DgnC013981 for ; Thu, 20 Jun 2002 17:13:42 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA01680 for ; Thu, 20 Jun 2002 17:16:45 -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 KAA14522 for linux-xfs@oss.sgi.com; Fri, 21 Jun 2002 10:14:53 +1000 (EST) Date: Fri, 21 Jun 2002 10:14:53 +1000 (EST) From: Nathan Scott Message-Id: <200206210014.KAA14522@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - test 021 X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Jun 20 17:14:20 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122109a cmd/xfstests/021 - 1.12 - small fixups - might help fix this test on Steve's machine. From owner-linux-xfs@oss.sgi.com Thu Jun 20 17:29:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5L0TLnC014198 for ; Thu, 20 Jun 2002 17:29:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5L0TLaS014197 for linux-xfs-outgoing; Thu, 20 Jun 2002 17:29:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5L0TFnC014169 for ; Thu, 20 Jun 2002 17:29:16 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA09140 for ; Thu, 20 Jun 2002 19:32:15 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id TAA25530 for ; Thu, 20 Jun 2002 19:32:15 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5L0UXI01058; Thu, 20 Jun 2002 19:30:33 -0500 Message-Id: <200206210030.g5L0UXI01058@jen.americas.sgi.com> Date: Thu, 20 Jun 2002 19:30:33 -0500 Subject: TAKE - rationalize locking code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More from Christoph, this streamlines the locking implementation inside XFS. Date: Thu Jun 20 17:29:42 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122112a linux/fs/xfs/support/sv.h - 1.7 linux/fs/xfs/support/sv.c - 1.7 linux/fs/xfs/support/spin.h - 1.6 linux/fs/xfs/support/mutex.h - 1.8 linux/fs/xfs/support/mutex.c - 1.5 linux/fs/xfs/support/Makefile - 1.10 From owner-linux-xfs@oss.sgi.com Thu Jun 20 17:54:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5L0svnC014578 for ; Thu, 20 Jun 2002 17:54:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5L0svSC014577 for linux-xfs-outgoing; Thu, 20 Jun 2002 17:54:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from c007.snv.cp.net (h015.c007.snv.cp.net [209.228.33.243]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5L0srnC014547 for ; Thu, 20 Jun 2002 17:54:53 -0700 Received: (cpmta 24125 invoked from network); 20 Jun 2002 17:57:52 -0700 Received: from 65.187.198.65 (HELO ?192.168.0.67?) by smtp.directvinternet.com (209.228.33.243) with SMTP; 20 Jun 2002 17:57:52 -0700 X-Sent: 21 Jun 2002 00:57:52 GMT Mime-Version: 1.0 X-Sender: aaronm@mail.cs.brandeis.edu (Unverified) Message-Id: In-Reply-To: <200206202100.g5KL0od08886@rope.americas> References: <200206202100.g5KL0od08886@rope.americas> Date: Thu, 20 Jun 2002 20:58:51 -0400 To: linux-xfs@oss.sgi.com From: Aaron Macks Subject: Version string Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This may be a bit OT, but how does one change the version string returned by the kernel, for example with uname? I want to install a modified kernel, but have it see a different module directory, so I can play with using XFS and no ramdisk thanks Aaron -- _______________________________________________________ Aaron Macks(aaronm@cs.brandeis.edu) My sheep has seven gall bladders, that makes me the King of the Universe! From owner-linux-xfs@oss.sgi.com Thu Jun 20 18:10:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5L1ANnC015118 for ; Thu, 20 Jun 2002 18:10:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5L1AMuM015117 for linux-xfs-outgoing; Thu, 20 Jun 2002 18:10:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5L1AGnC015087 for ; Thu, 20 Jun 2002 18:10:16 -0700 Received: from user-2ivfla9.dialup.mindspring.com ([165.247.213.73] helo=[192.168.30.210]) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 17LCz9-0002J6-00; Thu, 20 Jun 2002 18:13:12 -0700 Subject: Re: Version string From: Brian Lauer To: Aaron Macks Cc: linux-xfs@oss.sgi.com In-Reply-To: References: <200206202100.g5KL0od08886@rope.americas> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 20 Jun 2002 17:59:11 -0700 Message-Id: <1024621155.32307.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.9 required=5.0 tests=IN_REP_TO,LINES_OF_YELLING version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Edit the top level Makefile. Look for the lines that read: VERSION = 2 PATCHLEVEL = 4 SUBLEVEL = 9 EXTRAVERSION =-xfs KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) Changing those values and rebuilding the kernel with change the result of a uname -r. brian. On Thu, 2002-06-20 at 17:58, Aaron Macks wrote: > This may be a bit OT, but how does one change the version string > returned by the kernel, for example with uname? I want to install a > modified kernel, but have it see a different module directory, so I > can play with using XFS and no ramdisk > thanks > Aaron > -- > _______________________________________________________ > Aaron Macks(aaronm@cs.brandeis.edu) > My sheep has seven gall bladders, that makes me the King of the Universe! > > From owner-linux-xfs@oss.sgi.com Fri Jun 21 01:49:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5L8nknC004102 for ; Fri, 21 Jun 2002 01:49:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5L8nkuW004101 for linux-xfs-outgoing; Fri, 21 Jun 2002 01:49:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from banix (mail@psychedelic.baana.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5L8ngnC004073 for ; Fri, 21 Jun 2002 01:49:42 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 17LK9r-0006tJ-00 for ; Fri, 21 Jun 2002 11:52:43 +0300 Date: Fri, 21 Jun 2002 11:52:43 +0300 To: linux-xfs@oss.sgi.com Subject: Re: about the mmap problem.. Message-ID: <20020621085243.GA26488@banix> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Yes, I'm running a 12 hours old kernel from the CVS. From owner-linux-xfs@oss.sgi.com Fri Jun 21 05:37:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LCbinC006148 for ; Fri, 21 Jun 2002 05:37:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LCbiZJ006147 for linux-xfs-outgoing; Fri, 21 Jun 2002 05:37:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LCbdnC006119 for ; Fri, 21 Jun 2002 05:37:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA06284 for ; Fri, 21 Jun 2002 07:40:41 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-71.corp.sgi.com [134.15.64.71]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id HAA22573 for ; Fri, 21 Jun 2002 07:40:40 -0500 (CDT) From: Steve Lord Received: by snafu (8.11.6/SGI-client-1.7) id g5LCcpe01328; Fri, 21 Jun 2002 07:38:51 -0500 Message-Id: <200206211238.g5LCcpe01328@snafu> Date: Fri, 21 Jun 2002 07:38:51 -0500 Subject: TAKE - clean up makefile ifdefs To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Fri Jun 21 05:39:03 PDT 2002 Workarea: cf-vpn-sw-corp-64-71.corp.sgi.com:/home/lord/src/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122136a linux/fs/xfs/Makefile - 1.144 From owner-linux-xfs@oss.sgi.com Fri Jun 21 05:58:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LCwdnC006417 for ; Fri, 21 Jun 2002 05:58:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LCwdYw006416 for linux-xfs-outgoing; Fri, 21 Jun 2002 05:58:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LCwSnC006387 for ; Fri, 21 Jun 2002 05:58:28 -0700 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.56.224.149]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g5LD1Te8043086; Fri, 21 Jun 2002 09:01:29 -0400 Received: from d03nm800.boulder.ibm.com (avpilot.boulder.ibm.com [9.17.203.135]) by northrelay01.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g5LD1SH62488; Fri, 21 Jun 2002 09:01:28 -0400 Subject: Re: xfsdump/restore Not Restoring Regions To: Dean Roehrich Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "James A Goodwin" Date: Fri, 21 Jun 2002 08:01:27 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.10 |March 22, 2002) at 06/21/2002 07:01:28 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk You were right about the -D option, the xfsrestore works fine now. As for using the -a, it is not important. I think that DMF must work a bit differently than HPSS. We actually punch holes in the file after migrating the data. I guess that DMF does not, which requires use of the -a option to xfsdump in order to keep the migrated data from being dumped. For us the data isn't there at all, so xfsdump doesn't have a choice to make. Thanks for the advice, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@us.ibm.com Phone: (281) 336 2578 Fax: (281) 335 4231 T/L 260-2578 Dean Roehrich cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump/restore Not Restoring Regions 06/20/2002 10:01 AM >From: "James A Goodwin" >We have been doing some testing with xfsdump/xfsrestore and have noticed >that DMAPI regions present on files at dump time are not restored. We support just one region for the file, but I think you want to use the -D option on xfsrestore. Now you've reminded me of something else... You're probably using dm_set_dmattr() to attach HSM-specific info to the file. Our DMAPI implementation actually uses extended attributes to store that info. Because this is HSM-specific info, only your HSM can decode it. Now look at the -a option on xfsdump. That -a option would be useful to you, I'll bet. To do that, xfsdump knows how to decode the HSM-specific info that comes from our own HSM, "DMF". However, It doesn't know how to decode the info from your HSM. It may be time for you to submit some code to xfsdump. In the xfsdump and xfsrestore manpages the -A option is described from a DMF perspective, but I don't believe this is DMF-specific. Dean From owner-linux-xfs@oss.sgi.com Fri Jun 21 07:50:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LEoonC008233 for ; Fri, 21 Jun 2002 07:50:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LEoovp008232 for linux-xfs-outgoing; Fri, 21 Jun 2002 07:50:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LEognC008204 for ; Fri, 21 Jun 2002 07:50:42 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA10105; Fri, 21 Jun 2002 09:53:43 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA14228; Fri, 21 Jun 2002 09:53:43 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id JAA08303; Fri, 21 Jun 2002 09:53:42 -0500 (CDT) Message-Id: <200206211453.JAA08303@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump/restore Not Restoring Regions Date: Fri, 21 Jun 2002 09:53:42 -0500 From: Dean Roehrich X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" > >You were right about the -D option, the xfsrestore works fine now. > >As for using the -a, it is not important. I think that DMF must work a bit >differently than HPSS. We actually punch holes in the file after migrating >the data. I guess that DMF does not, which requires use of the -a option >to xfsdump in order to keep the migrated data from being dumped. For us >the data isn't there at all, so xfsdump doesn't have a choice to make. DMF might punch, or it might not. It's possible for the file to be online, and to also have a valid offline copy at the same time. We call this a dual-state file. When DMF is otherwise idle, it sometimes starts picking candidates of least-recently-accessed files and copying them out to tape, making them dual-state. Then we don't punch the files until we absolutely have to punch them. These dual-state files allow DMF to stay ahead of the game, so to speak. When someone starts to quickly suck up disk space, and we need to quickly make room to keep the filesystem below the high-water mark, we just have to punch the dual-state files. We don't slow down the users by making them wait while we copy some files out to tape. On the other hand, if they decide that now they're going to access one of these dual-state files, well...it's already online, so they don't have to wait for us to copy it in from tape. So, the -a option tells xfsdump that it should not try to read the file when it has a valid off-line copy of a file that is also online (why make yet another backup of the file when it's already on tape?) Dean From owner-linux-xfs@oss.sgi.com Fri Jun 21 11:05:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LI5DnC012248 for ; Fri, 21 Jun 2002 11:05:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LI5DtH012247 for linux-xfs-outgoing; Fri, 21 Jun 2002 11:05:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LI4EnC012185 for ; Fri, 21 Jun 2002 11:04:14 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA09742 for ; Fri, 21 Jun 2002 13:07:16 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA90605 for ; Fri, 21 Jun 2002 13:07:16 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5LI5Rd15764; Fri, 21 Jun 2002 13:05:27 -0500 Message-Id: <200206211805.g5LI5Rd15764@jen.americas.sgi.com> Date: Fri, 21 Jun 2002 13:05:27 -0500 Subject: TAKE - merge up to 2.5.24 To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.7 required=5.0 tests=PORN_12,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As Linus said when he put this out, he is on his way to Ottawa for the Kernel Summit and the OLS. Me too, Coverage on the list is going to be a little thin for the next couple of weeks. Steve Date: Fri Jun 21 11:02:58 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:122161a linux/drivers/message/fusion/lsi/mpi_raid.h - 1.1 linux/sound/ppc/tumbler_volume.h - 1.1 linux/drivers/scsi/53c700_d.h_shipped - 1.1 linux/drivers/scsi/53c7xx_d.h_shipped - 1.1 linux/drivers/scsi/53c7xx_u.h_shipped - 1.1 linux/drivers/scsi/53c8xx_d.h_shipped - 1.1 linux/drivers/scsi/53c8xx_u.h_shipped - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_reg.h_shipped - 1.1 linux/sound/pci/rme9652/multiface_firmware.dat - 1.1 linux/sound/pci/rme9652/hdsp.c - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_seq.h_shipped - 1.1 linux/drivers/scsi/sim710_d.h_shipped - 1.1 linux/drivers/message/fusion/mptctl.h - 1.1 linux/include/net/irda/af_irda.h - 1.1 linux/sound/pci/rme9652/hammerfall_mem.c - 1.1 linux/sound/pci/rme9652/digiface_firmware.dat - 1.1 linux/drivers/isdn/hisax/avma1_cs.c - 1.1 linux/sound/isa/sb/emu8000_pcm.c - 1.1 linux/scripts/patch-kernel - 1.6 linux/net/irda/timer.c - 1.9 linux/net/irda/irttp.c - 1.18 linux/net/irda/irsysctl.c - 1.10 linux/net/irda/irqueue.c - 1.9 linux/net/irda/irproc.c - 1.11 linux/net/irda/irlmp.c - 1.20 linux/net/irda/irlap_event.c - 1.24 linux/net/irda/irlap.c - 1.19 linux/net/irda/irlan/irlan_common.c - 1.18 linux/net/irda/irias_object.c - 1.13 linux/net/irda/iriap.c - 1.16 linux/net/irda/irda_device.c - 1.27 linux/net/irda/af_irda.c - 1.38 linux/net/ipv6/udp.c - 1.28 linux/net/ipv6/tcp_ipv6.c - 1.38 linux/net/ipv6/sysctl_net_ipv6.c - 1.3 linux/net/ipv6/sit.c - 1.21 linux/net/ipv6/route.c - 1.22 linux/net/ipv6/reassembly.c - 1.12 linux/net/ipv6/raw.c - 1.26 linux/net/ipv6/proc.c - 1.12 linux/net/ipv6/ndisc.c - 1.22 linux/net/ipv6/mcast.c - 1.19 linux/net/ipv6/ipv6_sockglue.c - 1.16 linux/net/ipv6/icmp.c - 1.19 linux/net/ipv6/exthdrs.c - 1.6 linux/net/ipv6/af_inet6.c - 1.22 linux/net/ipv6/addrconf.c - 1.25 linux/net/ipv6/Makefile - 1.7 linux/net/ipv4/Makefile - 1.10 linux/net/core/dev.c - 1.56 linux/net/Makefile - 1.22 linux/net/Config.in - 1.24 linux/net/802/transit/timertr.h - 1.3 linux/net/802/transit/pdutr.h - 1.3 linux/net/802/transit/Makefile - 1.4 linux/net/802/pseudo/pseudocode.h - 1.3 linux/net/802/pseudo/actionnm.h - 1.3 linux/net/802/pseudo/Makefile - 1.3 linux/net/802/cl2llc.pre - 1.5 linux/net/802/cl2llc.c - 1.5 linux/net/802/Makefile - 1.7 linux/mm/page_alloc.c - 1.82 linux/mm/mmap.c - 1.53 linux/kernel/softirq.c - 1.22 linux/kernel/signal.c - 1.34 linux/kernel/sched.c - 1.73 linux/kernel/ksyms.c - 1.151 linux/kernel/fork.c - 1.61 linux/include/net/irda/wrapper.h - 1.7 linux/include/net/irda/timer.h - 1.7 linux/include/net/irda/irttp.h - 1.11 linux/include/net/irda/irmod.h - 1.10 linux/include/net/irda/irlmp_event.h - 1.5 linux/include/net/irda/irlmp.h - 1.13 linux/include/net/irda/irlap_frame.h - 1.8 linux/include/net/irda/irlap_event.h - 1.8 linux/include/net/irda/irlap.h - 1.15 linux/include/net/irda/iriap.h - 1.9 linux/include/net/irda/irda_device.h - 1.14 linux/include/net/irda/irda.h - 1.17 linux/include/net/irda/discovery.h - 1.8 linux/include/net/ip6_route.h - 1.7 linux/include/linux/smp.h - 1.16 linux/include/linux/sched.h - 1.74 linux/include/linux/proc_fs.h - 1.36 linux/include/linux/interrupt.h - 1.20 linux/include/linux/i2c.h - 1.14 linux/include/linux/blk.h - 1.37 linux/include/asm-sparc64/smp.h - 1.14 linux/include/asm-sparc64/signal.h - 1.5 linux/include/asm-sparc64/hardirq.h - 1.15 linux/include/asm-alpha/unistd.h - 1.20 linux/include/asm-alpha/signal.h - 1.4 linux/fs/smbfs/sock.c - 1.13 linux/fs/ntfs/super.c - 1.17 linux/fs/ntfs/inode.h - 1.7 linux/fs/ntfs/inode.c - 1.19 linux/fs/ntfs/dir.h - 1.7 linux/fs/ntfs/dir.c - 1.14 linux/fs/ntfs/Makefile - 1.20 linux/fs/ext2/super.c - 1.34 linux/fs/ext2/ioctl.c - 1.12 linux/fs/ext2/balloc.c - 1.22 linux/fs/Config.in - 1.91 linux/drivers/zorro/Makefile - 1.9 linux/drivers/video/Makefile - 1.41 linux/drivers/scsi/script_asm.pl - 1.6 linux/drivers/scsi/jazz_esp.c - 1.8 linux/drivers/scsi/Makefile - 1.38 linux/drivers/scsi/Config.in - 1.30 linux/drivers/sbus/char/Makefile - 1.13 linux/drivers/pci/Makefile - 1.22 linux/drivers/net/irda/w83977af_ir.c - 1.24 linux/drivers/net/irda/tekram.c - 1.9 linux/drivers/net/irda/irtty.c - 1.28 linux/drivers/net/irda/irport.c - 1.25 linux/drivers/net/irda/girbil.c - 1.11 linux/drivers/net/irda/esi.c - 1.9 linux/drivers/net/irda/actisys.c - 1.10 linux/drivers/net/hamradio/soundmodem/Makefile - 1.6 linux/drivers/net/Config.in - 1.62 linux/drivers/net/3c509.c - 1.31 linux/drivers/isdn/pcbit/pcbit.h - 1.8 linux/drivers/isdn/hisax/Makefile - 1.21 linux/drivers/char/defkeymap.c - 1.10 linux/drivers/char/Makefile - 1.63 linux/drivers/char/Config.in - 1.61 linux/drivers/cdrom/cm206.c - 1.21 linux/drivers/block/nbd.c - 1.42 linux/drivers/block/genhd.c - 1.28 linux/drivers/block/Config.in - 1.37 linux/drivers/acorn/char/Makefile - 1.12 linux/drivers/Makefile - 1.35 linux/arch/sparc64/solaris/misc.c - 1.25 linux/arch/sparc64/kernel/traps.c - 1.20 linux/arch/sparc64/kernel/starfire.c - 1.10 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.45 linux/arch/sparc64/kernel/smp.c - 1.45 linux/arch/sparc64/kernel/setup.c - 1.30 linux/arch/sparc64/kernel/irq.c - 1.24 linux/arch/sparc64/kernel/devices.c - 1.11 linux/arch/sparc64/kernel/cpu.c - 1.7 linux/arch/sparc64/config.in - 1.56 linux/arch/sparc/kernel/sys_sparc.c - 1.15 linux/arch/sparc/config.in - 1.38 linux/arch/ppc/kernel/syscalls.c - 1.13 linux/arch/ppc/config.in - 1.52 linux/arch/mips/kernel/traps.c - 1.12 linux/arch/mips/kernel/sysmips.c - 1.8 linux/arch/mips/config.in - 1.30 linux/arch/m68k/kernel/traps.c - 1.13 linux/arch/m68k/kernel/sys_m68k.c - 1.9 linux/arch/m68k/config.in - 1.29 linux/arch/i386/kernel/traps.c - 1.55 linux/arch/i386/kernel/sys_i386.c - 1.8 linux/arch/i386/kernel/i386_ksyms.c - 1.50 linux/arch/i386/kernel/apm.c - 1.47 linux/arch/i386/boot/compressed/misc.c - 1.14 linux/arch/i386/Makefile - 1.27 linux/arch/arm/kernel/sys_arm.c - 1.20 linux/arch/arm/config.in - 1.42 linux/arch/alpha/kernel/traps.c - 1.20 linux/arch/alpha/config.in - 1.47 linux/Rules.make - 1.27 linux/Makefile - 1.205 linux/Documentation/filesystems/ntfs.txt - 1.16 linux/include/linux/ide.h - 1.54 linux/drivers/net/irda/toshoboe.c - 1.29 linux/drivers/net/irda/smc-ircc.c - 1.25 linux/drivers/net/irda/litelink.c - 1.9 linux/drivers/isdn/eicon/eicon_idi.c - 1.14 linux/drivers/tc/Makefile - 1.4 linux/net/khttpd/make_times_h.c - 1.2 linux/net/khttpd/Makefile - 1.6 linux/fs/partitions/Config.in - 1.17 linux/drivers/atm/Makefile - 1.19 linux/arch/sh/kernel/sys_sh.c - 1.10 linux/net/irda/ircomm/ircomm_tty.c - 1.20 linux/net/irda/ircomm/ircomm_param.c - 1.8 linux/net/irda/ircomm/ircomm_lmp.c - 1.6 linux/net/irda/ircomm/ircomm_core.c - 1.15 linux/include/net/irda/ircomm_tty.h - 1.9 linux/include/net/irda/ircomm_event.h - 1.2 linux/include/net/irda/ircomm_core.h - 1.5 linux/drivers/pcmcia/tcic.c - 1.15 linux/drivers/pcmcia/i82365.c - 1.25 linux/drivers/net/wan/Config.in - 1.17 linux/arch/i386/kernel/smpboot.c - 1.42 linux/kernel/timer.c - 1.25 linux/include/linux/i2c-id.h - 1.11 linux/drivers/i2c/i2c-velleman.c - 1.7 linux/drivers/i2c/i2c-elv.c - 1.8 linux/drivers/i2c/i2c-philips-par.c - 1.7 linux/drivers/i2c/i2c-elektor.c - 1.11 linux/drivers/i2c/i2c-algo-pcf.c - 1.11 linux/drivers/i2c/i2c-dev.c - 1.18 linux/drivers/i2c/i2c-core.c - 1.15 linux/drivers/i2c/i2c-algo-bit.c - 1.12 linux/drivers/i2c/Config.in - 1.6 linux/include/linux/i2c-dev.h - 1.8 linux/drivers/net/irda/old_belkin.c - 1.4 linux/arch/i386/kernel/mpparse.c - 1.22 linux/drivers/scsi/3w-xxxx.h - 1.11 linux/drivers/scsi/3w-xxxx.c - 1.19 linux/drivers/net/irda/nsc-ircc.c - 1.22 linux/arch/ia64/config.in - 1.31 linux/include/asm-ia64/delay.h - 1.5 linux/include/asm-ia64/processor.h - 1.21 linux/include/asm-ia64/pgalloc.h - 1.13 linux/include/asm-ia64/softirq.h - 1.8 linux/include/asm-ia64/signal.h - 1.6 linux/drivers/net/8139too.c - 1.38 linux/drivers/net/skfp/h/smt.h - 1.3 linux/arch/mips64/kernel/traps.c - 1.7 linux/arch/mips64/config.in - 1.21 linux/arch/mips64/kernel/syscall.c - 1.11 linux/drivers/ide/trm290.c - 1.12 linux/drivers/ide/pdc202xx.c - 1.24 linux/drivers/ide/ns87415.c - 1.11 linux/drivers/ide/ide.c - 1.57 linux/drivers/ide/ide-pmac.c - 1.17 linux/drivers/ide/ide-disk.c - 1.39 linux/drivers/ide/icside.c - 1.19 linux/drivers/ide/hpt366.c - 1.21 linux/drivers/ide/hpt34x.c - 1.15 linux/drivers/ide/cmd64x.c - 1.17 linux/drivers/ide/Config.in - 1.28 linux/drivers/block/elevator.c - 1.19 linux/include/linux/elevator.h - 1.10 linux/arch/ppc/8260_io/Config.in - 1.4 linux/arch/s390/kernel/traps.c - 1.10 linux/arch/s390/kernel/sys_s390.c - 1.5 linux/drivers/net/tun.c - 1.14 linux/include/linux/if_tun.h - 1.3 linux/drivers/media/video/cpia_pp.c - 1.5 linux/drivers/media/video/Config.in - 1.6 linux/drivers/md/md.c - 1.48 linux/net/irda/irsyms.c - 1.6 linux/net/irda/irnet/irnet_ppp.c - 1.10 linux/net/irda/irnet/irnet_irda.c - 1.12 linux/net/irda/irnet/irnet.h - 1.11 linux/include/asm-i386/xor.h - 1.7 linux/include/linux/ethtool.h - 1.12 linux/arch/parisc/kernel/traps.c - 1.3 linux/arch/parisc/kernel/sys_parisc.c - 1.3 linux/arch/parisc/config.in - 1.6 linux/fs/reiserfs/journal.c - 1.32 linux/arch/s390x/kernel/traps.c - 1.6 linux/arch/s390x/kernel/sys_s390.c - 1.5 linux/arch/cris/kernel/sys_cris.c - 1.8 linux/arch/cris/kernel/traps.c - 1.9 linux/drivers/pcmcia/hd64465_ss.c - 1.5 linux/drivers/scsi/aic7xxx/Makefile - 1.7 linux/drivers/net/sungem.c - 1.18 linux/drivers/net/irda/irda-usb.c - 1.19 linux/drivers/net/wireless/Config.in - 1.6 linux/include/net/irda/irda-usb.h - 1.6 linux/drivers/mtd/maps/Config.in - 1.4 linux/drivers/isdn/tpam/tpam.h - 1.4 linux/drivers/net/irda/ali-ircc.c - 1.8 linux/drivers/net/dl2k.h - 1.9 linux/Documentation/networking/dl2k.txt - 1.7 linux/drivers/net/dl2k.c - 1.14 linux/drivers/message/fusion/scsi3.h - 1.4 linux/drivers/message/fusion/mptscsih.h - 1.3 linux/drivers/message/fusion/mptscsih.c - 1.7 linux/drivers/message/fusion/mptlan.h - 1.3 linux/drivers/message/fusion/mptlan.c - 1.5 linux/drivers/message/fusion/mptctl.c - 1.8 linux/drivers/message/fusion/mptbase.h - 1.5 linux/drivers/message/fusion/mptbase.c - 1.5 linux/drivers/message/fusion/lsi/mpi_type.h - 1.2 linux/drivers/message/fusion/lsi/mpi_targ.h - 1.3 linux/drivers/message/fusion/lsi/mpi_lan.h - 1.3 linux/drivers/message/fusion/lsi/mpi_ioc.h - 1.3 linux/drivers/message/fusion/lsi/mpi_init.h - 1.3 linux/drivers/message/fusion/lsi/mpi_fc.h - 1.3 linux/drivers/message/fusion/lsi/mpi_cnfg.h - 1.3 linux/drivers/message/fusion/lsi/mpi.h - 1.3 linux/drivers/message/fusion/Config.in - 1.3 linux/drivers/message/fusion/isense.c - 1.6 linux/drivers/message/fusion/linux_compat.h - 1.2 linux/drivers/message/fusion/lsi/fc_log.h - 1.4 linux/drivers/net/irda/vlsi_ir.c - 1.10 linux/drivers/ide/serverworks.c - 1.13 linux/drivers/video/radeonfb.c - 1.10 linux/fs/namespace.c - 1.19 linux/drivers/i2c/i2c-proc.c - 1.4 linux/include/linux/i2c-proc.h - 1.2 linux/drivers/net/8139cp.c - 1.13 linux/drivers/net/irda/ep7211_ir.c - 1.2 linux/drivers/net/irda/sa1100_ir.c - 1.5 linux/drivers/pcmcia/i82092.c - 1.5 linux/drivers/atm/idt77252.h - 1.3 linux/fs/ext3/ioctl.c - 1.5 linux/drivers/hotplug/cpqphp_proc.c - 1.3 linux/drivers/hotplug/cpqphp_pci.c - 1.3 linux/drivers/hotplug/cpqphp_nvram.c - 1.2 linux/drivers/hotplug/cpqphp_ctrl.c - 1.2 linux/drivers/hotplug/cpqphp_core.c - 1.4 linux/drivers/ide/ide-taskfile.c - 1.16 linux/fs/ext2/ext2.h - 1.6 linux/sound/synth/emux/emux_synth.c - 1.4 linux/sound/synth/emux/emux_oss.c - 1.2 linux/sound/synth/emux/emux_effect.c - 1.3 linux/sound/synth/emux/emux.c - 1.3 linux/sound/synth/emux/Makefile - 1.4 linux/sound/ppc/tumbler.c - 1.3 linux/sound/ppc/powermac.c - 1.4 linux/sound/ppc/pmac.h - 1.2 linux/sound/ppc/pmac.c - 1.4 linux/sound/ppc/keywest.c - 1.3 linux/sound/ppc/daca.c - 1.2 linux/sound/ppc/burgundy.c - 1.2 linux/sound/ppc/awacs.h - 1.2 linux/sound/ppc/awacs.c - 1.4 linux/sound/pci/ymfpci/ymfpci_main.c - 1.5 linux/sound/pci/via8233.c - 1.7 linux/sound/pci/trident/trident_memory.c - 1.3 linux/sound/pci/trident/trident_main.c - 1.5 linux/sound/pci/rme9652/rme9652_mem.c - 1.3 linux/sound/pci/rme9652/rme9652.c - 1.8 linux/sound/pci/rme9652/Makefile - 1.4 linux/sound/pci/rme96.c - 1.7 linux/sound/pci/korg1212/korg1212.c - 1.8 linux/sound/pci/intel8x0.c - 1.7 linux/sound/pci/ice1712.c - 1.7 linux/sound/pci/es1968.c - 1.7 linux/sound/pci/emu10k1/emufx.c - 1.5 linux/sound/pci/emu10k1/emu10k1_synth.c - 1.3 linux/sound/pci/cs46xx/cs46xx.c - 1.8 linux/sound/pci/cs4281.c - 1.7 linux/sound/pci/cmipci.c - 1.8 linux/sound/pci/ac97/ac97_codec.c - 1.6 linux/sound/pci/ac97/Makefile - 1.6 linux/sound/pci/Config.in - 1.4 linux/arch/x86_64/kernel/sys_x86_64.c - 1.5 linux/arch/x86_64/kernel/traps.c - 1.5 linux/sound/oss/Makefile - 1.6 linux/sound/oss/Config.in - 1.2 linux/sound/last.c - 1.5 linux/sound/isa/sb/sb16_csp.c - 1.4 linux/sound/isa/sb/es968.c - 1.5 linux/sound/isa/sb/emu8000_synth.c - 1.3 linux/sound/isa/sb/emu8000_local.h - 1.3 linux/sound/isa/sb/emu8000_callback.c - 1.2 linux/sound/isa/sb/emu8000.c - 1.5 linux/sound/isa/sb/Makefile - 1.6 linux/sound/isa/gus/interwave.c - 1.6 linux/sound/isa/gus/gus_synth.c - 1.4 linux/sound/isa/gus/gus_pcm.c - 1.3 linux/sound/isa/gus/Makefile - 1.5 linux/sound/isa/cs423x/cs4236.c - 1.7 linux/sound/isa/cs423x/Makefile - 1.5 linux/sound/isa/ad1848/Makefile - 1.5 linux/sound/isa/Makefile - 1.6 linux/sound/i2c/Makefile - 1.7 linux/sound/drivers/opl3/opl3_voice.h - 1.2 linux/sound/drivers/opl3/opl3_seq.c - 1.3 linux/sound/drivers/opl3/Makefile - 1.6 linux/sound/drivers/mpu401/Makefile - 1.6 linux/sound/drivers/dummy.c - 1.6 linux/sound/core/timer.c - 1.4 linux/sound/core/sound.c - 1.5 linux/sound/core/seq/seq_queue.h - 1.7 linux/sound/core/seq/seq_clientmgr.h - 1.3 linux/sound/core/seq/seq_clientmgr.c - 1.6 linux/sound/core/seq/oss/Makefile - 1.5 linux/sound/core/seq/instr/Makefile - 1.7 linux/sound/core/seq/Makefile - 1.10 linux/sound/core/rawmidi.c - 1.6 linux/sound/core/pcm_native.c - 1.6 linux/sound/core/pcm_lib.c - 1.5 linux/sound/core/pcm.c - 1.4 linux/sound/core/oss/pcm_oss.c - 1.7 linux/sound/core/misc.c - 1.6 linux/sound/core/memory.c - 1.8 linux/sound/core/init.c - 1.4 linux/sound/core/info.c - 1.5 linux/sound/core/control.c - 1.4 linux/sound/core/Makefile - 1.10 linux/sound/core/Config.in - 1.8 linux/include/sound/ymfpci.h - 1.3 linux/include/sound/version.h - 1.8 linux/include/sound/timer.h - 1.2 linux/include/sound/soundfont.h - 1.2 linux/include/sound/emux_synth.h - 1.3 linux/include/sound/pcm.h - 1.4 linux/include/sound/opl3.h - 1.3 linux/include/sound/mixer_oss.h - 1.2 linux/include/sound/emu8000.h - 1.3 linux/include/sound/emu10k1.h - 1.5 linux/include/sound/core.h - 1.9 linux/include/sound/asound.h - 1.7 linux/include/sound/ac97_codec.h - 1.5 linux/arch/ppc64/config.in - 1.7 linux/arch/ppc64/kernel/syscalls.c - 1.2 linux/fs/jfs/file.c - 1.5 linux/fs/jfs/jfs_dmap.c - 1.5 linux/fs/jfs/jfs_inode.c - 1.3 linux/fs/jfs/jfs_imap.c - 1.4 linux/fs/jfs/namei.c - 1.6 linux/fs/jfs/jfs_logmgr.c - 1.9 linux/fs/jfs/super.c - 1.8 linux/fs/jfs/jfs_txnmgr.c - 1.7 linux/sound/pci/Config.help - 1.3 linux/sound/core/ioctl32/ioctl32.c - 1.3 linux/include/linux/futex.h - 1.3 linux/kernel/futex.c - 1.4 linux/drivers/usb/net/usbnet.c - 1.6 linux/drivers/isdn/icn/Config.in - 1.2 linux/drivers/isdn/hisax/Config.in - 1.4 linux/drivers/isdn/hisax/Config.help - 1.2 linux/drivers/isdn/act2000/Config.in - 1.2 linux/drivers/isdn/tpam/Config.in - 1.2 linux/drivers/isdn/sc/Config.in - 1.2 linux/drivers/isdn/pcbit/Config.in - 1.2 linux/drivers/isdn/hardware/avm/t1pci.c - 1.4 linux/drivers/isdn/hardware/avm/c4.c - 1.4 linux/drivers/isdn/hardware/avm/Config.in - 1.3 linux/drivers/isdn/hardware/avm/b1pci.c - 1.4 linux/fs/ntfs/attrib.c - 1.4 linux/fs/ntfs/volume.h - 1.3 linux/fs/ntfs/compress.c - 1.5 linux/fs/ntfs/namei.c - 1.4 linux/fs/ntfs/mft.c - 1.3 linux/sound/pci/rme32.c - 1.3 linux/fs/ntfs/layout.h - 1.3 linux/fs/ntfs/ChangeLog - 1.4 linux/sound/arm/sa11xx-uda1341.c - 1.3 linux/drivers/ide/tcq.c - 1.7 linux/drivers/ide/pcidma.c - 1.6 linux/drivers/net/irda/mcp2120.c - 1.2 linux/init/Makefile - 1.5 linux/drivers/scsi/aic7xxx/shipped_aic7xxx_reg.h - 1.2 linux/drivers/ide/ioctl.c - 1.6 linux/drivers/scsi/aic7xxx/shipped_aic7xxx_seq.h - 1.2 linux/drivers/acpi/pci_irq.c - 1.2 linux/net/llc/Makefile - 1.2 From owner-linux-xfs@oss.sgi.com Fri Jun 21 11:46:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LIkPnC012784 for ; Fri, 21 Jun 2002 11:46:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LIkPaS012783 for linux-xfs-outgoing; Fri, 21 Jun 2002 11:46:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mathserv.math.ohio-state.edu (mathserv.math.ohio-state.edu [128.146.111.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LIkJnC012752 for ; Fri, 21 Jun 2002 11:46:20 -0700 Received: from mathserv.math.ohio-state.edu (localhost [127.0.0.1]) by mathserv.math.ohio-state.edu (8.12.3/8.12.3) with ESMTP id g5LInRn9001716 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 21 Jun 2002 14:49:27 -0400 Received: (from alden@localhost) by mathserv.math.ohio-state.edu (8.12.3/8.12.3/Submit) id g5LInRlk001714 for linux-xfs@oss.sgi.com; Fri, 21 Jun 2002 14:49:27 -0400 Date: Fri, 21 Jun 2002 14:49:27 -0400 From: Dave Alden To: linux-xfs@oss.sgi.com Subject: Re: Kernel oops with XFS and NFS Message-ID: <20020621144927.A1528@math.ohio-state.edu> References: <20020620200647.A8102@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020620200647.A8102@math.ohio-state.edu>; from alden@math.ohio-state.edu on Thu, Jun 20, 2002 at 08:06:47PM -0400 X-RAVMilter-Version: 8.3.2(snapshot 20020213) (mathserv) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, Sorry to follup to my own message, but I'm getting extremely desperate. I'm now at the point that I can't bring the system up for more than a few minutes before it does the oops. I'm afraid I'm going to be forced to go back to EXT3, and once I go back I probably won't get the opportunity to try XFS again (please don't take this as a threat, it's just a plea for help -- I really, really, really want to stay with XFS, but with 500 users breaking down my door I don't know if it will be an option). Does anyone have any suggestions? ...thnx, ...dave alden From owner-linux-xfs@oss.sgi.com Fri Jun 21 12:32:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LJWMnC013287 for ; Fri, 21 Jun 2002 12:32:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LJWMrb013286 for linux-xfs-outgoing; Fri, 21 Jun 2002 12:32:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ADSL-Bergs.RZ.RWTH-Aachen.DE (adsl-bergs.rz.RWTH-Aachen.DE [137.226.80.218]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LJWFnC013258 for ; Fri, 21 Jun 2002 12:32:16 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.35 #1) id 17LUBh-0007wj-00; Fri, 21 Jun 2002 21:35:17 +0200 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Dave Alden" Date: Fri, 21 Jun 2002 21:35:17 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2502) For Windows 2000 (5.0.2195;2) In-Reply-To: <20020621144927.A1528@math.ohio-state.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: Kernel oops with XFS and NFS Message-Id: X-Spam-Status: No, hits=-5.6 required=5.0 tests=IN_REP_TO,GAPPY_TEXT version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 21 Jun 2002 14:49:27 -0400, Dave Alden wrote: >I'm now at the point that I can't bring the system up for more than a few >minutes before it does the oops. Are you absolutely sure your hardware isn't flaky? Just a wild shot in the dark... -- Sign the EU petition against SPAM: L I N U X .~. http://www.politik-digital.de/spam/ The Choice /V\ of a GNU /( )\ Generation ^^-^^ From owner-linux-xfs@oss.sgi.com Fri Jun 21 12:46:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LJk5nC013481 for ; Fri, 21 Jun 2002 12:46:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LJk5UY013480 for linux-xfs-outgoing; Fri, 21 Jun 2002 12:46:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mathserv.math.ohio-state.edu (mathserv.math.ohio-state.edu [128.146.111.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LJjwnC013452 for ; Fri, 21 Jun 2002 12:45:59 -0700 Received: from mathserv.math.ohio-state.edu (localhost [127.0.0.1]) by mathserv.math.ohio-state.edu (8.12.3/8.12.3) with ESMTP id g5LJn6Ih012306 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Fri, 21 Jun 2002 15:49:06 -0400 Received: (from alden@localhost) by mathserv.math.ohio-state.edu (8.12.3/8.12.3/Submit) id g5LJn6KV012302 for linux-xfs@oss.sgi.com; Fri, 21 Jun 2002 15:49:06 -0400 Date: Fri, 21 Jun 2002 15:49:06 -0400 From: Dave Alden To: linux-xfs@oss.sgi.com Subject: Re: Kernel oops with XFS and NFS Message-ID: <20020621154906.A11133@math.ohio-state.edu> References: <20020621144927.A1528@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from rabe@RWTH-Aachen.DE on Fri, Jun 21, 2002 at 09:35:17PM +0200 X-RAVMilter-Version: 8.3.2(snapshot 20020213) (mathserv) X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, On Fri, Jun 21, 2002 at 09:35:17PM +0200, Ralf G. R. Bergs wrote: > Are you absolutely sure your hardware isn't flaky? > > Just a wild shot in the dark... Of course not, one can never be absolutely sure. But I'm almost absolutely sure. :-) The server is also a mail server and I tried running it for a few hours with just the mail partition being shared (which is EXT3) and had no problems. Now that leaves the possibility of the RAID controller (the mail isn't on the RAID controller) being flakey, but I highly doubt it (It's a Mylex ExtremeRAID 2000). I have a spare, I'll try swapping it in to see if that makes a difference. ...dave From owner-linux-xfs@oss.sgi.com Fri Jun 21 13:57:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LKvKnC014230 for ; Fri, 21 Jun 2002 13:57:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LKvK0w014229 for linux-xfs-outgoing; Fri, 21 Jun 2002 13:57:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LKvBnC014201 for ; Fri, 21 Jun 2002 13:57:12 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5LKxie0080431; Fri, 21 Jun 2002 22:59:44 +0200 (CEST) Message-Id: <4.3.2.7.2.20020621225412.03914c68@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jun 2002 22:59:47 +0200 To: Dave Alden , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: Kernel oops with XFS and NFS In-Reply-To: <20020621144927.A1528@math.ohio-state.edu> References: <20020620200647.A8102@math.ohio-state.edu> <20020620200647.A8102@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:49 21-6-2002 -0400, Dave Alden wrote: >Hi, > Sorry to follup to my own message, but I'm getting extremely desperate. >I'm now at the point that I can't bring the system up for more than a few >minutes before it does the oops. I'm afraid I'm going to be forced to go >back to EXT3, and once I go back I probably won't get the opportunity to >try XFS again (please don't take this as a threat, it's just a plea for >help -- I really, really, really want to stay with XFS, but with 500 users >breaking down my door I don't know if it will be an option). Does anyone >have any suggestions? If the system oopses really fast after rebooting you may have some file system corruption. very slight corruption. You probably won't even have lost something but one of the structures might have gotten off for some reason which is causing this. When you do have the opportunity pleased update to a newer kernel. The 1.1 release from the 7.3 kernel has come a _really_ long way since 2.4.5 (IRC) If you can upgrade please do so. I had good luck with NFS and a XFS kernel (as in decent speed) starting with 2.4.6-pre5 which had numerous important fixes in the NFS path. There have been a lot more since that one as well. You are just unlucky at the moment that you have not hit that one yet. Try a clean reboot and then a xfs_repair. This has solved some issues in the past. Sorry for the slow response, I have a headache which makes pondering hurt. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Jun 21 16:06:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5LN6ZnC010916 for ; Fri, 21 Jun 2002 16:06:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5LN6ZRi010915 for linux-xfs-outgoing; Fri, 21 Jun 2002 16:06:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5LN6SnC010887 for ; Fri, 21 Jun 2002 16:06:29 -0700 Received: from online.no (213-187-165-28.dd.nextgentel.com [213.187.165.28]) by mail.broadpark.no (Postfix) with ESMTP id 100957D06; Fri, 21 Jun 2002 22:35:45 +0200 (MEST) Message-ID: <3D138D1E.6BFC7FAA@online.no> Date: Fri, 21 Jun 2002 22:31:26 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-4SGI_XFS_1.1custom i686) X-Accept-Language: en MIME-Version: 1.0 To: Dave Alden Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel oops with XFS and NFS References: <20020621144927.A1528@math.ohio-state.edu> <20020621154906.A11133@math.ohio-state.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dave Alden wrote: > Hi, > > On Fri, Jun 21, 2002 at 09:35:17PM +0200, Ralf G. R. Bergs wrote: > > Are you absolutely sure your hardware isn't flaky? > > > > Just a wild shot in the dark... > > Of course not, one can never be absolutely sure. But I'm almost > absolutely sure. :-) The server is also a mail server and I tried > running it for a few hours with just the mail partition being shared > (which is EXT3) and had no problems. Now that leaves the possibility > of the RAID controller (the mail isn't on the RAID controller) being > flakey, but I highly doubt it (It's a Mylex ExtremeRAID 2000). I > have a spare, I'll try swapping it in to see if that makes a difference. > > ...dave Redhat updates it kernel with nfs fixes in kernel 2.4.18-5, to get xfs does nor patch cleanly with 2.4.18-4 patch. From owner-linux-xfs@oss.sgi.com Fri Jun 21 19:42:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5M2g5nC014133 for ; Fri, 21 Jun 2002 19:42:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M2g5nE014132 for linux-xfs-outgoing; Fri, 21 Jun 2002 19:42:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M2g1nC014104 for ; Fri, 21 Jun 2002 19:42:01 -0700 Received: from dhcp50.cn.mvd (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with ESMTP id 73530B70D for ; Fri, 21 Jun 2002 19:45:09 -0700 (PDT) Date: Sat, 22 Jun 2002 10:51:49 +0800 (CST) From: Harrison Xing X-X-Sender: To: Subject: Open file corruption? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=1.2 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, There has been reports and FAQ about an open file which is modified is corrupted after power failure. But is it possible for a file that is opened for read-only access becomes corrupted after accidental power failure? We have met once or twice that some open files get lost even though there doesn't seem to have any process which modifies them. Thanks. -- Best Regards, Harrison From owner-linux-xfs@oss.sgi.com Fri Jun 21 20:11:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5M3BZnC014897 for ; Fri, 21 Jun 2002 20:11:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M3BZnN014896 for linux-xfs-outgoing; Fri, 21 Jun 2002 20:11:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M3BQnC014867 for ; Fri, 21 Jun 2002 20:11:27 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA18172; Fri, 21 Jun 2002 22:14:30 -0500 (CDT) Received: from snafu (cf-vpn-sw-corp-64-31.corp.sgi.com [134.15.64.31]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id WAA21458; Fri, 21 Jun 2002 22:14:29 -0500 (CDT) Subject: Re: Kernel oops with XFS and NFS From: Stephen Lord To: Dave Alden Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020621144927.A1528@math.ohio-state.edu> References: <20020620200647.A8102@math.ohio-state.edu> <20020621144927.A1528@math.ohio-state.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 21 Jun 2002 22:12:22 -0500 Message-Id: <1024715543.2828.18.camel@snafu> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-06-21 at 13:49, Dave Alden wrote: > Hi, > Sorry to follup to my own message, but I'm getting extremely desperate. > I'm now at the point that I can't bring the system up for more than a few > minutes before it does the oops. I'm afraid I'm going to be forced to go > back to EXT3, and once I go back I probably won't get the opportunity to > try XFS again (please don't take this as a threat, it's just a plea for > help -- I really, really, really want to stay with XFS, but with 500 users > breaking down my door I don't know if it will be an option). Does anyone > have any suggestions? > ...thnx, > ...dave alden Sorry for the lack of response from us, we are a bit thin on the ground at the moment, and there are going to be less of us around for a couple of weeks. All I can really recommend is getting the filesystems unmounted and running xfs_repair on them. Also while the fs is idle and after it is clean as far as repair is concerned, try running xfs_fsr on it. We have seen some issues with fragmented files causing problems - however, the defragmenter seems to have issues running whilst nfs is active - hence run it without the filesystem being used via nfs. Steve From owner-linux-xfs@oss.sgi.com Fri Jun 21 20:15:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5M3F5nC015060 for ; Fri, 21 Jun 2002 20:15:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M3F4rj015059 for linux-xfs-outgoing; Fri, 21 Jun 2002 20:15:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M3F0nC015028 for ; Fri, 21 Jun 2002 20:15:00 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA15570 for ; Fri, 21 Jun 2002 22:18:04 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA93639 for ; Fri, 21 Jun 2002 22:18:04 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5M3GBQ16171; Fri, 21 Jun 2002 22:16:11 -0500 Message-Id: <200206220316.g5M3GBQ16171@jen.americas.sgi.com> Date: Fri, 21 Jun 2002 22:16:11 -0500 Subject: TAKE - fix mkfs stripe calculation problem To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A problem in the new mkfs log stripe code. Using just a data stripe unit would cause a divide by zero error. Date: Fri Jun 21 20:16:25 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122199a cmd/xfsprogs/mkfs/xfs_mkfs.c - 1.30 - fix log stripe alignment code in the case where there is a data stripe but no log stripe specified. From owner-linux-xfs@oss.sgi.com Sat Jun 22 01:55:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5M8t3nC016991 for ; Sat, 22 Jun 2002 01:55:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M8t2mH016990 for linux-xfs-outgoing; Sat, 22 Jun 2002 01:55:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M8sunC016960 for ; Sat, 22 Jun 2002 01:54:57 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5M8w4Wn010522; Sat, 22 Jun 2002 10:58:04 +0200 (CEST) Message-Id: <4.3.2.7.2.20020622105730.0385d488@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 22 Jun 2002 10:58:04 +0200 To: Harrison Xing , From: Seth Mos Subject: Re: Open file corruption? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:51 22-6-2002 +0800, Harrison Xing wrote: >Hi, > >There has been reports and FAQ about an open file which is modified is >corrupted after power failure. But is it possible for a file that is opened >for read-only access becomes corrupted after accidental power failure? We >have met once or twice that some open files get lost even though there doesn't >seem to have any process which modifies them. Thanks. What kernel, distro, hardware? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sat Jun 22 02:32:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5M9WknC017419 for ; Sat, 22 Jun 2002 02:32:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5M9WkgD017418 for linux-xfs-outgoing; Sat, 22 Jun 2002 02:32:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5M9WdnC017390 for ; Sat, 22 Jun 2002 02:32:39 -0700 Received: from dhcp50.cn.mvd (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with ESMTP id DB275B70D; Sat, 22 Jun 2002 02:35:48 -0700 (PDT) Date: Sat, 22 Jun 2002 17:42:28 +0800 (CST) From: Harrison Xing X-X-Sender: To: Seth Mos Cc: Subject: Re: Open file corruption? In-Reply-To: <4.3.2.7.2.20020622105730.0385d488@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 22 Jun 2002, Seth Mos wrote: > At 10:51 22-6-2002 +0800, Harrison Xing wrote: > >Hi, > > > >There has been reports and FAQ about an open file which is modified is > >corrupted after power failure. But is it possible for a file that is opened > >for read-only access becomes corrupted after accidental power failure? We > >have met once or twice that some open files get lost even though there doesn't > >seem to have any process which modifies them. Thanks. > > What kernel, distro, hardware? > The XFS 1.0.1 release with 2.4.5. A little bit old. Intel HW. > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. > -- Best Regards, Harrison From owner-linux-xfs@oss.sgi.com Sat Jun 22 06:01:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5MD1KnC019001 for ; Sat, 22 Jun 2002 06:01:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5MD1Ko0019000 for linux-xfs-outgoing; Sat, 22 Jun 2002 06:01:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5MD18nC018970 for ; Sat, 22 Jun 2002 06:01:09 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5MD4Gd2029520; Sat, 22 Jun 2002 15:04:17 +0200 (CEST) Message-Id: <4.3.2.7.2.20020622150124.02dbf5c0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 22 Jun 2002 15:04:16 +0200 To: Harrison Xing From: Seth Mos Subject: Re: Open file corruption? Cc: In-Reply-To: References: <4.3.2.7.2.20020622105730.0385d488@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:42 22-6-2002 +0800, Harrison Xing wrote: >On Sat, 22 Jun 2002, Seth Mos wrote: > > > At 10:51 22-6-2002 +0800, Harrison Xing wrote: > > >Hi, > > > > > >There has been reports and FAQ about an open file which is modified is > > >corrupted after power failure. But is it possible for a file that is > opened > > >for read-only access becomes corrupted after accidental power failure? We > > >have met once or twice that some open files get lost even though there > doesn't > > >seem to have any process which modifies them. Thanks. > > > > What kernel, distro, hardware? > > > >The XFS 1.0.1 release with 2.4.5. A little bit old. Intel HW. Better update to something more recent like the 1.1 release. It fixes a lot of issues including the file corruption during power-off. I do remember that someone else encountered this with a read_only opened file as well but not what the cause was. Upgrading to 1.1 gives you a lot more robust XFS kernel then what yuo have now and it's handling of open files will possibly be very different in behaviour then what you see now. Cheers > > Cheers > > > > -- > > Seth > > It might just be your lucky day, if you only knew. > > > >-- >Best Regards, >Harrison -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sat Jun 22 15:20:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5MMKRnC022743 for ; Sat, 22 Jun 2002 15:20:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5MMKRQP022742 for linux-xfs-outgoing; Sat, 22 Jun 2002 15:20:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from www.zachlowry.net (cisco1.midtnn.net [12.153.14.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5MMKInC022712 for ; Sat, 22 Jun 2002 15:20:19 -0700 Reply-To: From: "Zach Lowry" To: Subject: Slight problem with XFS/Linux and Indy Drive Date: Sat, 22 Jun 2002 17:25:55 -0500 Message-ID: <000201c21a3b$c74cffa0$6401a8c0@WORKGROUP> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello all! I've gotten my hands here recently on an R5k Indy, with IRIX 6.5 and a 2 gb HD. Unfortunately, the seller didn't leave me with a root password (Yuck). So, I figured my first course of action would be to mount the drive up in My Linux/XFS box and change the /etc/passwd file. But, after checking out the archives, it seems that I'm falling victim to the page size restriction. Now, here are my questions: 1. What is the status of the 2.5.16 patch? Has it overcome this problem yet? (I'm already building the 2.5.16 kernel, so I'll peobably find out, unless there is some fiddling to be done) 2. Is there any way to check what the block size of the disk is from Linux? If not, could I tell from the console in Irix? I ask because I've got some sparcs and alphas, and if there's a pretty good chance it might be 8k, I'll build them a new kernel. Thanks a lot! And by the way, I run XFS on several of my systems, and I gotta say, keep up the good work! Zach -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPRT5c4HWQmQc5olOEQL6XQCgrEfoL4i2cSRH0xZxE0JvQ7pOFxYAn0Ih yHaQ8NvOJs2dLaMFLfhdCVXB =AXCN -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Jun 22 17:01:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5N018nC023563 for ; Sat, 22 Jun 2002 17:01:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5N018ox023562 for linux-xfs-outgoing; Sat, 22 Jun 2002 17:01:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5N010nC023532 for ; Sat, 22 Jun 2002 17:01:01 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5N04CfB009267; Sun, 23 Jun 2002 02:04:12 +0200 (CEST) Message-Id: <4.3.2.7.2.20020623020124.0336de30@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Jun 2002 02:04:07 +0200 To: , From: Seth Mos Subject: Re: Slight problem with XFS/Linux and Indy Drive In-Reply-To: <000201c21a3b$c74cffa0$6401a8c0@WORKGROUP> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 17:25 22-6-2002 -0500, Zach Lowry wrote: > But, after checking out the archives, it seems that I'm falling >victim to the page size restriction. Now, here are my questions: The XFS CVS has support for the smaller then pagesize volumes so I think there is a chance it will work. The -current CVS is based on 2.4.19-pre which should have everything you need for this. Asuming that the fs was formatted with a block size of <4K that is. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sat Jun 22 21:31:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5N4VBnC026674 for ; Sat, 22 Jun 2002 21:31:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5N4VBa6026673 for linux-xfs-outgoing; Sat, 22 Jun 2002 21:31:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from www.zachlowry.net (cisco1.midtnn.net [12.153.14.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5N4V2nC026645 for ; Sat, 22 Jun 2002 21:31:03 -0700 Reply-To: From: "Zach Lowry" To: "'Seth Mos'" , Subject: RE: Slight problem with XFS/Linux and Indy Drive Date: Sat, 22 Jun 2002 23:36:40 -0500 Message-ID: <001001c21a6f$91f1cc30$6401a8c0@WORKGROUP> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <4.3.2.7.2.20020623020124.0336de30@pop.xs4all.nl> X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > At 17:25 22-6-2002 -0500, Zach Lowry wrote: > > But, after checking out the archives, it seems that > I'm falling > >victim to the page size restriction. Now, here are my questions: > > The XFS CVS has support for the smaller then pagesize volumes > so I think > there is a chance it will work. The -current CVS is based on > 2.4.19-pre > which should have everything you need for this. > > Asuming that the fs was formatted with a block size of <4K that is. > Well, I got that built. Now, is there an option to pass to mount to have it pick up the different block size? Also, BTW, I get these messages in the kernel log. Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) XFS: dirty log written in incompatible format - can't recover XFS: log mount/recovery failed XFS: log mount failed XFS: unknown mount option [blocksize]. Thanks! Zach -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPRVQWIHWQmQc5olOEQLD1gCg8A0BdFxq3y/IDbFYy6EkmI1VMukAoOnl VDQUhtk4+uXAQdH2zFrAYCsi =+FHU -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sat Jun 22 21:46:45 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5N4kjnC026864 for ; Sat, 22 Jun 2002 21:46:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5N4ki3k026863 for linux-xfs-outgoing; Sat, 22 Jun 2002 21:46:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5N4kTnC026835 for ; Sat, 22 Jun 2002 21:46:29 -0700 Received: from mailto.t-online-com.de (mailto.t-online-com.de [62.156.145.215] (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 VAA08843 for ; Sat, 22 Jun 2002 21:49:58 -0700 (PDT) mail_from (be@berdmann.de) Received: from mail pickup service by mailto.t-online-com.de with Microsoft SMTPSVC; Sun, 23 Jun 2002 06:23:12 +0200 Received: from guiness.omniscient.com ([64.134.101.78]) by mail.t-intra.de with Microsoft SMTPSVC(5.5.1877.507.50); Wed, 30 Jan 2002 01:42:08 +0100 Received: from surly.omniscient.com (surly.omniscient.com [64.134.101.69]) by guiness.omniscient.com (8.12.1/8.12.1) with ESMTP id g0U0S3mQ022328; Tue, 29 Jan 2002 19:28:55 -0500 (EST) Received: (from root@localhost) by surly.omniscient.com (8.11.6/8.11.6) id g0U0OmE265920 for amanda.org.amanda-users-list; Wed, 30 Jan 2002 00:24:48 GMT Received: from ente.berdmann.de (frnk-d514e173.dsl.mediaWays.net [213.20.225.115]) by surly.omniscient.com (8.11.6/8.11.6) with ESMTP id g0U0Oiv264793 for ; Tue, 29 Jan 2002 19:24:44 -0500 (EST) Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16ViYC-000844-00; Wed, 30 Jan 2002 01:24:32 +0100 Message-ID: <3C573D40.A36C9083@berdmann.de> Date: Wed, 30 Jan 2002 01:24:32 +0100 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.17-xfs i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: jrj@cc.purdue.edu CC: "amanda-users@amanda.org" , Linux XFS Mailing List Subject: Re: Using Amanda with Linux/XFS: "failed to get (valid) bulkstat information" References: <200201292238.RAA28586@gandalf.cc.purdue.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.4 required=5.0 tests=MAY_BE_FORGED,PORN_10 version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Before I put this in, is there any particular reason you're adding > DMP_WARNING? Why not just add these entries as DMP_NORMAL? First reason (beauty): I decided to put the warnings into a different group than the normal output, just to be ready for further additions of warnings of other dump programs and to have the ability to treat them differently in the future. In this case, the warnings seem to be quite normal for busy XFS filesystems. But xfsdump prints a warning and hopefully the xfsdump developers will have had their reasons for it: why don't recognize it as a warning but continue as you would do on the command line? ("A warning? I've got the backups - who cares if I can recover?" ;-)) Second reason (technical nature): the dmpline_t/regex pairs in the array re_table (client-src/sendbackup-dump.c, line 44) are matched against dump's output in order of array index in parse_dumpline(). client-src/sendbackup.c: 729 dmpline_t parse_dumpline(str) 730 char *str; 731 /* 732 * Checks the dump output line in str against the regex table. 733 */ 734 { 735 regex_t *rp; 736 737 /* check for error match */ 738 for(rp = program->re_table; rp->regex != NULL; rp++) { 739 if(match(rp->regex, str)) 740 break; 741 } The array re_table is initialized with pairs in order of DMP_SIZE, DMP_STRANGE, DMP_NORMAL and DMP_STRANGE (for all other lines). One of the regexps of dmpline_t DMP_STRANGE is "[Ff]ail". client-src/sendbackup-dump.c: 100 /* strange dump lines */ 101 { DMP_STRANGE, "should not happen" }, 102 { DMP_STRANGE, "Cannot open" }, 103 { DMP_STRANGE, "[Ee]rror" }, 104 { DMP_STRANGE, "[Ff]ail" }, 105 /* XXX add more ERROR entries here by scanning dump sources? */ 106 107 /* any blank or non-strange DUMP: lines are marked as normal */ 108 { DMP_NORMAL, "^ *DUMP:" }, If you added "failed to get bulkstat" to DMP_NORMAL, you would never match DMP_NORMAL because DMP_STRANGE would have been matched first. So I inserted DMP_WARNING between DMP_SIZE and DMP_STRANGE. The XFS boys of SGI told me not to bang my head on these warnings. Bulkstat is a special XFS feature to get lots of inodes in a single rush. Sometimes an inode cannot be caught by bulkstat due to filesystem activity; instead, xfsdump will do a single stat call later on it. From owner-linux-xfs@oss.sgi.com Sun Jun 23 01:19:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5N8JFnC001330 for ; Sun, 23 Jun 2002 01:19:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5N8JFOw001329 for linux-xfs-outgoing; Sun, 23 Jun 2002 01:19:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@[216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5N8J5nC001301 for ; Sun, 23 Jun 2002 01:19:06 -0700 Received: from localhost (localhost.localdomain [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id E77734B7EB6; Sun, 23 Jun 2002 04:22:18 -0400 (EDT) Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 24E36401A40; Sun, 23 Jun 2002 04:22:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 1E949C00469; Sun, 23 Jun 2002 04:22:16 -0400 (EDT) Date: Sun, 23 Jun 2002 04:22:15 -0400 (EDT) From: Mike Burger To: Zach Lowry Cc: linux-xfs@oss.sgi.com Subject: Re: Slight problem with XFS/Linux and Indy Drive In-Reply-To: <000201c21a3b$c74cffa0$6401a8c0@WORKGROUP> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS new-20020517 X-Spam-Status: No, hits=-6.5 required=5.0 tests=IN_REP_TO,PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does the Irix box give you the option to boot into a single user mode, whereby you can change the root password? Or, failing that, can you get in touch with the seller, and ask them for the root password? On Sat, 22 Jun 2002, Zach Lowry wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello all! > > I've gotten my hands here recently on an R5k Indy, with IRIX 6.5 and > a 2 gb HD. Unfortunately, the seller didn't leave me with a root > password (Yuck). So, I figured my first course of action would be to > mount the drive up in My Linux/XFS box and change the /etc/passwd > file. > > But, after checking out the archives, it seems that I'm falling > victim to the page size restriction. Now, here are my questions: > > 1. What is the status of the 2.5.16 patch? Has it overcome this > problem yet? (I'm already building the 2.5.16 kernel, so I'll > peobably find out, unless there is some fiddling to be done) > > 2. Is there any way to check what the block size of the disk is from > Linux? If not, could I tell from the console in Irix? I ask because > I've got some sparcs and alphas, and if there's a pretty good chance > it might be 8k, I'll build them a new kernel. > > Thanks a lot! > > And by the way, I run XFS on several of my systems, and I gotta say, > keep up the good work! > > Zach > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use > > iQA/AwUBPRT5c4HWQmQc5olOEQL6XQCgrEfoL4i2cSRH0xZxE0JvQ7pOFxYAn0Ih > yHaQ8NvOJs2dLaMFLfhdCVXB > =AXCN > -----END PGP SIGNATURE----- > > From owner-linux-xfs@oss.sgi.com Sun Jun 23 01:44:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5N8ignC001601 for ; Sun, 23 Jun 2002 01:44:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5N8igXU001600 for linux-xfs-outgoing; Sun, 23 Jun 2002 01:44:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5N8ianC001572 for ; Sun, 23 Jun 2002 01:44:37 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5N8loMb060313; Sun, 23 Jun 2002 10:47:50 +0200 (CEST) Message-Id: <4.3.2.7.2.20020623104629.03ff6548@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 23 Jun 2002 10:47:41 +0200 To: , From: Seth Mos Subject: RE: Slight problem with XFS/Linux and Indy Drive In-Reply-To: <001001c21a6f$91f1cc30$6401a8c0@WORKGROUP> References: <4.3.2.7.2.20020623020124.0336de30@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 23:36 22-6-2002 -0500, Zach Lowry wrote: >Well, I got that built. Now, is there an option to pass to mount to >have it pick up the different block size? > >Also, BTW, I get these messages in the kernel log. > >Starting XFS recovery on filesystem: sd(8,17) (dev: 8/17) >XFS: dirty log written in incompatible format - can't recover >XFS: log mount/recovery failed >XFS: log mount failed >XFS: unknown mount option [blocksize]. The log is different between irix and linux. Make sure the disk was cleanly unmounted. So boot the box and reboot it from there if you can. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Sun Jun 23 15:09:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5NM9BnC011740 for ; Sun, 23 Jun 2002 15:09:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5NM9BOp011739 for linux-xfs-outgoing; Sun, 23 Jun 2002 15:09:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from netmail.netcologne.de (netmail.netcologne.de [194.8.194.109]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5NM92nC011707 for ; Sun, 23 Jun 2002 15:09:03 -0700 Received: from jungle (xdsl-213-168-111-13.netcologne.de [213.168.111.13]) by netmail.netcologne.de (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id AXF60736; Mon, 24 Jun 2002 00:12:01 +0200 (CEST) Content-Type: text/plain; charset="iso-8859-15" From: =?iso-8859-15?q?J=F6rg=20Prante?= Reply-To: joergprante@netcologne.de Organization: Linux Kernel To: kbuild-devel@lists.sourceforge.net, linux-xfs@oss.sgi.com Subject: XFS 2.4.19-pre10 and kbuild 2.5 Date: Mon, 24 Jun 2002 00:10:47 +0200 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200206240010.47152.joergprante@netcologne.de> X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I am trying to build XFS from CVS (2.4.19-pre10) with the backport of kbuild 2.5 by Paul P Komkoff Jr http://www.uwsg.iu.edu/hypermail/linux/kernel/0206.0/0044.html Unfortunately, the build structure in XFS CVS for the 2.4 kernel is giving me headache. It looks like these are simply the files copied from the XFS 2.5 kernel tree. E.g. the fs/xfs_support subdirectory is not addressed. I played around with the existing files in XFS CVS (Makefile.in/Makefile.in.append), added "link_subdirs(xfs xfs_dmapi xfs_support)" to fs/Makefile.in, and it compiles, but got linker errors when linking vmlinux (multiple definitions). --------------snip 'make -f Makefile-2.5'--------------------- [...] USER include/linux/compile.h CC init/version.o USER vmlinux fs/xfs_dmapi/xfs_dmapi.o: In function `dm_send_destroy_event': fs/xfs_dmapi/xfs_dmapi.o(.text+0x18c8): multiple definition of `dm_send_destroy_event' fs/xfs/xfs.o(.text+0x61358): first defined here ld: Warning: size of symbol `dm_send_destroy_event' changed from 6 to 514 in fs/xfs_dmapi/xfs_dmapi.o fs/xfs_dmapi/xfs_dmapi.o: In function `dm_send_unmount_event': fs/xfs_dmapi/xfs_dmapi.o(.text+0x1e94): multiple definition of `dm_send_unmount_event' fs/xfs/xfs.o(.text+0x61368): first defined here ld: Warning: size of symbol `dm_send_unmount_event' changed from 1 to 358 in fs/xfs_dmapi/xfs_dmapi.o [...very long error list deleted...] --------------snap--------------------- I think I didn't set up kbuild 2.5 correctly. I am not a kbuild expert so please forgive me if this is a newbie question: Can somebody help me out with working Makefile.in's for 2.4 XFS CVS tree and kbuild 2.5 Version 3.0? It would be great to supply the 2.4 XFS kernel tree in the SGI CVS ready for kbuild 2.5. Many thanks, and keep up the good work, I enjoy XFS very much! Jörg From owner-linux-xfs@oss.sgi.com Sun Jun 23 17:15:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5O0FnnC013639 for ; Sun, 23 Jun 2002 17:15:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O0FnIc013638 for linux-xfs-outgoing; Sun, 23 Jun 2002 17:15:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5O0FenC013609 for ; Sun, 23 Jun 2002 17:15:41 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id RAA03640 for ; Sun, 23 Jun 2002 17:18:57 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA03462; Mon, 24 Jun 2002 10:17:38 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5O0Gx7G001188; Mon, 24 Jun 2002 10:16:59 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5O0GwsO001186; Mon, 24 Jun 2002 10:16:58 +1000 Date: Mon, 24 Jun 2002 10:16:58 +1000 From: Nathan Scott To: Zach Lowry Cc: linux-xfs@oss.sgi.com Subject: Re: Slight problem with XFS/Linux and Indy Drive Message-ID: <20020624001658.GB961@frodo> References: <000201c21a3b$c74cffa0$6401a8c0@WORKGROUP> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000201c21a3b$c74cffa0$6401a8c0@WORKGROUP> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.0 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED,PORN_10 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sat, Jun 22, 2002 at 05:25:55PM -0500, Zach Lowry wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello all! > > I've gotten my hands here recently on an R5k Indy, with IRIX 6.5 and > a 2 gb HD. Unfortunately, the seller didn't leave me with a root Boot IRIX into the miniroot - when booting up you will be prompted to "Stop for maintenance" (or something along those lines)... and from there you'll be able to get a root shell. The root filesystem is mounted at /root when in the miniroot, iirc, so you'll need to edit /root/etc/passwd. You should be able to find full details on this in the IRIX admin guides on http://techpubs.sgi.com/. > 2. Is there any way to check what the block size of the disk is from > Linux? If not, could I tell from the console in Irix? I ask because > I've got some sparcs and alphas, and if there's a pretty good chance > it might be 8k, I'll build them a new kernel. (you have to have root access for this:) # xfs_db -r -c sb -c "'p blocksize'" /dev/XXX The default blocksize is 4K in IRIX. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jun 23 18:45:46 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5O1jknC016715 for ; Sun, 23 Jun 2002 18:45:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O1jk60016714 for linux-xfs-outgoing; Sun, 23 Jun 2002 18:45:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5O1jQnC016685 for ; Sun, 23 Jun 2002 18:45:26 -0700 Received: from larry.melbourne.sgi.com (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 SAA07911 for ; Sun, 23 Jun 2002 18:48:57 -0700 (PDT) mail_from (ivanr@sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA04204; Mon, 24 Jun 2002 11:47:24 +1000 Received: from omen (localhost [127.0.0.1]) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with SMTP id LAA79437; Mon, 24 Jun 2002 11:47:26 +1000 (EST) Date: Mon, 24 Jun 2002 11:47:26 +1000 From: Ivan Rayner To: zach@zachlowry.net Cc: linux-xfs@oss.sgi.com Subject: Re: Slight problem with XFS/Linux and Indy Drive Message-Id: <20020624114726.79d1b1da.ivanr@sgi.com> In-Reply-To: <20020624001658.GB961@frodo> References: <000201c21a3b$c74cffa0$6401a8c0@WORKGROUP> <20020624001658.GB961@frodo> Organization: SGI X-Mailer: Sylpheed version 0.7.5 (GTK+ 1.2.10; mips-sgi-irix6.5) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 24 Jun 2002 10:16:58 +1000, Nathan Scott wrote: > On Sat, Jun 22, 2002 at 05:25:55PM -0500, Zach Lowry wrote: > > I've gotten my hands here recently on an R5k Indy, with IRIX 6.5 > > and a 2 gb HD. Unfortunately, the seller didn't leave me with a root > > Boot IRIX into the miniroot - when booting up you will be > prompted to "Stop for maintenance" (or something along those > lines)... and from there you'll be able to get a root shell. > The root filesystem is mounted at /root when in the miniroot, > iirc, so you'll need to edit /root/etc/passwd. > > You should be able to find full details on this in the IRIX > admin guides on http://techpubs.sgi.com/. To get into the miniroot, you'll need your IRIX 6.5 base CDs or 6.5.x overlay CDs. 1. Insert the 6.5 Foundation 1, Foundation 2 or first Ovelays CD into your CDROM drive 2. Boot the Indy 3. Click on "Stop for Maintenance" 4. Click on "Install software" 5. Click on "Local CD" and then OK 6. Now it should load the installation tools and eventually put you at a "inst> " prompt 7. Drop to a shell by using the "sh" command (you might have to go into the admin menu first ... can't remember) 8. And as Nathan says, you can now edit your passwd file under /root/etc/passwd 9. Exit the shell and quit inst, and the Indy should reboot If you don't have the IRIX media, then I suggest you get it. However, if you can't afford it then it's possible that your Indy has an open guest account and depending on the IRIX version you might be able to exploit some old security hole to gain root access. Ivan -- Ivan Rayner ivanr@sgi.com From owner-linux-xfs@oss.sgi.com Sun Jun 23 18:57:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5O1vmnC016949 for ; Sun, 23 Jun 2002 18:57:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O1vmpU016948 for linux-xfs-outgoing; Sun, 23 Jun 2002 18:57:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from www.zachlowry.net (cisco1.midtnn.net [12.153.14.102]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5O1venC016919 for ; Sun, 23 Jun 2002 18:57:41 -0700 Reply-To: From: "Zach Lowry" To: Subject: How Embarrasing... Date: Sun, 23 Jun 2002 21:03:24 -0500 Message-ID: <002601c21b23$53220920$6401a8c0@WORKGROUP> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-2.1 required=5.0 tests=PGP_SIGNATURE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First, I want to thank every one for your help with my little problem. I got the -current kernel and utilities compiled, and got the drive successfully mounted in my Linux box. I had to get it to not check the journal, apparently it saw something there it didn't like. Anyhow, I got it up, copied the passwd and shadow files off, and powered down. After working on this an entire day, I dropped the files in to John the Ripper on my Dual 1GHz machine and started to get ready for bed. But, much to my dismay, John was already done. Sometimes I forget that there are some people with no sense of security (or no need of it). Login: root Password: root Doh! Thanks again! Zach Lowry -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use iQA/AwUBPRZ97IHWQmQc5olOEQJrJwCeNjIxDFRaSk7raOsvOCH6l3TkPSEAnjun c4kItWVZWaYyAmsfrU8YYQg5 =f2Eq -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Mon Jun 24 02:03:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5O93HnC022821 for ; Mon, 24 Jun 2002 02:03:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5O93Hn3022820 for linux-xfs-outgoing; Mon, 24 Jun 2002 02:03:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from email.seznam.cz (omx.seznam.cz [212.80.76.41]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5O939nC022792 for ; Mon, 24 Jun 2002 02:03:10 -0700 Received: (qmail 71630 invoked by uid 0); 24 Jun 2002 09:06:13 -0000 Received: from [80.95.105.170] by email.seznam.cz with HTTP; Mon, 24 Jun 2002 11:06:11 +0200 (CEST) To: linux-xfs@oss.sgi.com From: =?iso-8859-2?Q?Michal=20Ambroz?= Subject: =?iso-8859-2?Q?getfacl=2Cchacl=3A=20=2D=20Argument=20list=20too=20long?= In-Reply-To: <200206240736.g5O7atIU020570@oss.sgi.com> Content-Type: text/plain; charset=ISO-8859-2 Date: Mon, 24 Jun 2002 11:06:11 +0200 (CEST) Reply-To: =?iso-8859-2?Q?Michal=20Ambroz?= Mime-Version: 1.0 Message-Id: <3968.9225-19335-113214235-1024909571@seznam.cz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g5O93AnC022793 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I am using RH 7.3 installed by SGI XFS installator for RedHat from this place ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/installer/i386/ When I give to some file more than 11 acls (including u,g,o,m), it is not possible to show the list of the currently set acls anyhow. Neither "chacl -l" nor "getfacl" seems to work. I've tried to upgrade acl libacl packages to 2.0.11, but it didn't help. Please is there any workaround how to obtain current acl from file which has set more 12 on it? Or Is there any updated patched kernel for RH 7.3? thank you Michal Ambroz (o_o) ______________________________________________________________________ Reklama: Konec tichych spolecniku! Nyni bude mluvit opravdu kazdy. - Nove tarify pro firemni zakazniky. http://ad2.seznam.cz/redir.cgi?instance=28784%26url=http://www.oskarmobil.cz/cz/business/novinky.html From owner-linux-xfs@oss.sgi.com Mon Jun 24 03:43:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OAhhnC024357 for ; Mon, 24 Jun 2002 03:43:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OAhhQp024356 for linux-xfs-outgoing; Mon, 24 Jun 2002 03:43:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OAhZnC024306 for ; Mon, 24 Jun 2002 03:43:35 -0700 Received: from mountainviewdata.com (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with ESMTP id 2BD4CB70D for ; Mon, 24 Jun 2002 03:46:54 -0700 (PDT) Message-ID: <3D16F61F.FCAFC63B@mountainviewdata.com> Date: Mon, 24 Jun 2002 18:36:15 +0800 From: tom X-Mailer: Mozilla 4.61 [zh_CN] (X11; I; Linux 2.4.18-xfs-1.1 i686) X-Accept-Language: zh-CN, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: question about inode count. Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry, maybe some one had asked the same question. But I really want to figure out the phenomenon shown below. $ mkfs.xfs -f /dev/hda6 $ xfs_db /dev/hda6 xfs_db: agi 0 xfs_db: p magicnum = 0x58414749 versionnum = 1 seqno = 0 length = 78317 count = 64 ----> the already allocated inode count root = 3 level = 1 freecount = 61 ----> why the freecount is 61? I guess one of the used inode is rootip, but what's the remaining two? newino = 128 dirino = null unlinked[0-63] = ## after we mount the system. $mount -t xfs /dev/hda6 /mnt ## and touch a file, $ touch /mnt/a $ ls -i /mnt/a 131 a # the inode num is counted from 131, not 129(the root inode is 128), # where are the inodes of 129 and 130? Best regards. From owner-linux-xfs@oss.sgi.com Mon Jun 24 04:48:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OBm4nC026339 for ; Mon, 24 Jun 2002 04:48:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OBm4rD026338 for linux-xfs-outgoing; Mon, 24 Jun 2002 04:48:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OBlvnC026308 for ; Mon, 24 Jun 2002 04:47:57 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id GAA28384; Mon, 24 Jun 2002 06:51:12 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id GAA33205; Mon, 24 Jun 2002 06:51:11 -0500 (CDT) Date: Mon, 24 Jun 2002 06:46:26 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: tom cc: linux-xfs@oss.sgi.com Subject: Re: question about inode count. In-Reply-To: <3D16F61F.FCAFC63B@mountainviewdata.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Tom - if you look at the xfs superblock in kdb, you'll see: [0]kdb> xsb 0xc6140824 ... rootino 128 rbmino 129 rsumino 130 ... and these are: xfs_ino_t sb_rbmino; /* bitmap inode for realtime extents */ xfs_ino_t sb_rsumino; /* summary inode for rt bitmap */ However, I'm not sure offhand why these show up even if CONFIG_XFS_RT is not enabled. -Eric On Mon, 24 Jun 2002, tom wrote: > Sorry, maybe some one had asked the same question. > But I really want to figure out the phenomenon shown below. > $mount -t xfs /dev/hda6 /mnt > ## and touch a file, > $ touch /mnt/a > $ ls -i /mnt/a > 131 a > # the inode num is counted from 131, not 129(the root inode is 128), > # where are the inodes of 129 and 130? From owner-linux-xfs@oss.sgi.com Mon Jun 24 11:28:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OISvnC003602 for ; Mon, 24 Jun 2002 11:28:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OISvk0003601 for linux-xfs-outgoing; Mon, 24 Jun 2002 11:28:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OISnnC003571 for ; Mon, 24 Jun 2002 11:28:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA31575 for ; Mon, 24 Jun 2002 13:32:05 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA40701 for ; Mon, 24 Jun 2002 13:32:05 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g5OIRHG16818; Mon, 24 Jun 2002 13:27:17 -0500 Message-Id: <200206241827.g5OIRHG16818@stout.americas.sgi.com> Date: Mon, 24 Jun 2002 13:27:17 -0500 Subject: TAKE - fix mount -o remount,noatime & other mounting bits X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Started out as just making "mount -o remount,noatime" work on XFS, to make it easier to get this flag set on the root fs of my laptop. :) (before, simply adding "noatime" to the rootfs flags in fstab did not work, since linvfs_remount was a no-op for all but "-o remount,r[o,w]"). Also some general cleanup of mount flags etc, see below. Remounting could still use some more work; you can, for example, specify a new logdev as a remount parameter, and XFS won't complain. (It won't change the logdev, but it won't complain, either). Ideally, XFS should allow remounting as many options as possible, and complain if a non-remountable option is specified with MS_REMOUNT... Date: Mon Jun 24 11:25:14 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122231a linux/fs/xfs/xfsidbg.c - 1.187 - add more mount flag names to xmount output linux/fs/xfs/xfs_vfsops.c - 1.356 - Don't look for 32BITINODES in args; just set it directly linux/fs/xfs/linux/xfs_super.c - 1.184 - Remove XFS mount opt flags that are handled in the Linux VFS: noatime, rw, ro Don't assign MS_RDONLY VFS flag to xfs args flags Don't fake out 32BITINODES as an argument, just default it later Message about "osyncisdsync" going away Rework linvfs_remount to allow modification of "noatime" From owner-linux-xfs@oss.sgi.com Mon Jun 24 14:34:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OLYBnC007965 for ; Mon, 24 Jun 2002 14:34:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OLYB3E007964 for linux-xfs-outgoing; Mon, 24 Jun 2002 14:34:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OLXmnC007936 for ; Mon, 24 Jun 2002 14:33:48 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA30348 for ; Mon, 24 Jun 2002 16:37:04 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA39440 for ; Mon, 24 Jun 2002 16:37:04 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g5OLWFI28870; Mon, 24 Jun 2002 16:32:15 -0500 Message-Id: <200206242132.g5OLWFI28870@stout.americas.sgi.com> Date: Mon, 24 Jun 2002 16:32:15 -0500 Subject: TAKE - Merge up to 2.4.19-rc1 X-Spam-Status: No, hits=1.6 required=5.0 tests=PORN_12,PORN_10,MISSING_HEADERS version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hope this works, we're all off to Ottawa tomorrow. :) Merge up to 2.4.19-rc1 Date: Mon Jun 24 14:35:10 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/merge/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122256a linux/scripts/patch-kernel - 1.6 linux/net/packet/af_packet.c - 1.29 linux/net/ipv4/ipconfig.c - 1.28 linux/net/802/Makefile - 1.6 linux/mm/swapfile.c - 1.49 linux/mm/page_io.c - 1.20 linux/mm/page_alloc.c - 1.73 linux/mm/filemap.c - 1.112 linux/kernel/signal.c - 1.22 linux/kernel/panic.c - 1.17 linux/kernel/ksyms.c - 1.128 linux/include/linux/serial.h - 1.17 linux/include/linux/kdev_t.h - 1.6 linux/include/asm-alpha/unistd.h - 1.17 linux/fs/ufs/super.c - 1.23 linux/fs/read_write.c - 1.17 linux/fs/fcntl.c - 1.18 linux/drivers/video/Config.in - 1.33 linux/drivers/usb/audio.c - 1.36 linux/drivers/sound/sound_config.h - 1.6 linux/drivers/scsi/scsi_error.c - 1.22 linux/drivers/scsi/jazz_esp.c - 1.7 linux/drivers/net/hamradio/soundmodem/smdma.h - 1.3 linux/drivers/net/hamradio/soundmodem/sm_wss.c - 1.7 linux/drivers/net/hamradio/soundmodem/sm_sbc.c - 1.6 linux/drivers/net/hamradio/soundmodem/sm_afsk2666.c - 1.3 linux/drivers/net/hamradio/soundmodem/sm_afsk2400_8.c - 1.3 linux/drivers/net/hamradio/soundmodem/sm_afsk2400_7.c - 1.3 linux/drivers/net/hamradio/soundmodem/sm_afsk1200.c - 1.3 linux/drivers/net/hamradio/soundmodem/sm.h - 1.9 linux/drivers/net/hamradio/baycom_ser_fdx.c - 1.17 linux/drivers/net/hamradio/baycom_epp.c - 1.19 linux/drivers/net/3c501.c - 1.17 linux/drivers/isdn/pcbit/capi.h - 1.5 linux/drivers/isdn/isdn_common.c - 1.32 linux/drivers/isdn/act2000/capi.h - 1.8 linux/drivers/isdn/act2000/act2000.h - 1.8 linux/drivers/char/specialix.c - 1.13 linux/drivers/char/serial.c - 1.55 linux/drivers/char/pc_keyb.c - 1.28 linux/drivers/char/isicom.c - 1.16 linux/drivers/char/ftape/zftape/zftape-vtbl.h - 1.3 linux/drivers/char/ftape/lowlevel/ftape-rw.h - 1.4 linux/drivers/block/rd.c - 1.44 linux/drivers/block/nbd.c - 1.27 linux/drivers/block/genhd.c - 1.23 linux/arch/ppc/mm/init.c - 1.40 linux/arch/i386/kernel/setup.c - 1.66 linux/arch/i386/kernel/apm.c - 1.39 linux/arch/i386/defconfig - 1.87 linux/Makefile - 1.172 linux/Documentation/scsi.txt - 1.4 linux/Documentation/scsi-generic.txt - 1.10 linux/Documentation/networking/ip-sysctl.txt - 1.12 linux/Documentation/kernel-docs.txt - 1.9 linux/Documentation/Configure.help - 1.133 linux/CREDITS - 1.71 linux/drivers/video/cyber2000fb.h - 1.13 linux/drivers/video/cyber2000fb.c - 1.29 linux/drivers/isdn/eicon/eicon.h - 1.14 linux/drivers/net/arlan.c - 1.23 linux/fs/partitions/check.c - 1.36 linux/fs/partitions/Makefile - 1.8 linux/include/asm-i386/pci.h - 1.15 linux/drivers/pcmcia/Config.in - 1.12 linux/include/linux/pci_ids.h - 1.58 linux/fs/proc/proc_misc.c - 1.30 linux/drivers/pci/pci.ids - 1.43 linux/drivers/sound/trident.h - 1.14 linux/drivers/net/aironet4500.h - 1.10 linux/drivers/char/agp/agpgart_be.c - 1.32 linux/drivers/char/agp/agp.h - 1.22 linux/drivers/ieee1394/Config.in - 1.7 linux/drivers/scsi/3w-xxxx.h - 1.10 linux/drivers/scsi/3w-xxxx.c - 1.17 linux/drivers/net/8139too.c - 1.37 linux/drivers/net/skfp/h/smt.h - 1.3 linux/drivers/net/bonding.c - 1.12 linux/include/linux/if_bonding.h - 1.6 linux/drivers/video/riva/fbdev.c - 1.19 linux/drivers/ide/piix.c - 1.15 linux/drivers/ide/ide-pci.c - 1.20 linux/drivers/ide/ide-disk.c - 1.20 linux/drivers/ide/ide-cd.c - 1.22 linux/net/ipv4/netfilter/ipchains_core.c - 1.11 linux/arch/i386/kernel/pci-irq.c - 1.21 linux/Documentation/sound/PAS16 - 1.3 linux/fs/partitions/ibm.c - 1.10 linux/drivers/s390/char/con3215.c - 1.8 linux/drivers/s390/block/dasd.c - 1.19 linux/include/linux/sisfb.h - 1.5 linux/drivers/char/i810_rng.c - 1.9 linux/drivers/media/video/videodev.c - 1.11 linux/drivers/media/video/pms.c - 1.7 linux/drivers/media/video/bw-qcam.c - 1.9 linux/drivers/char/i810-tco.h - 1.3 linux/drivers/char/i810-tco.c - 1.11 linux/include/asm-i386/xor.h - 1.3 linux/arch/alpha/lib/ev6-memset.S - 1.2 linux/mm/shmem.c - 1.30 linux/Documentation/DocBook/sis900.tmpl - 1.2 linux/drivers/acpi/acpi_ksyms.c - 1.6 linux/drivers/s390/net/fsm.h - 1.4 linux/Documentation/i810_rng.txt - 1.4 linux/drivers/s390/char/tubio.h - 1.4 linux/arch/ppc/boot/chrp/start.c - 1.3 linux/drivers/net/au1000_eth.c - 1.5 linux/drivers/char/w83877f_wdt.c - 1.5 linux/drivers/message/fusion/linux_compat.h - 1.3 linux/drivers/s390/block/dasd_int.h - 1.5 linux/drivers/video/sstfb.c - 1.7 linux/drivers/video/radeonfb.c - 1.11 linux/drivers/sound/nec_vrc5477.c - 1.5 linux/drivers/sound/ite8172.c - 1.6 linux/drivers/net/ns83820.c - 1.10 linux/include/asm-ppc/commproc.h - 1.2 linux/drivers/net/8139cp.c - 1.7 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.4 linux/drivers/video/tridentfb.h - 1.3 linux/drivers/video/tridentfb.c - 1.4 linux/drivers/block/umem.c - 1.3 linux/drivers/char/hcdp_serial.c - 1.2 linux/drivers/net/tg3.c - 1.3 linux/drivers/net/tg3.h - 1.3 linux/drivers/net/wan/8253x/8253xmode.c - 1.2 linux/init/do_mounts.c - 1.2 linux/drivers/net/wan/8253x/Makefile - 1.3 linux/drivers/net/wan/8253x/clean - 1.2 linux/drivers/net/wan/8253x/crc32.c - 1.2 linux/drivers/net/wan/8253x/crc32dcl.h - 1.2 linux/include/linux/hcdp_serial.h - 1.2 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.2 linux/drivers/sound/au1000.c - 1.3 linux/arch/ppc/boot/common/relocate.S - 1.2 linux/drivers/usb/emi26.c - 1.2 linux/drivers/video/neofb.c - 1.2 From owner-linux-xfs@oss.sgi.com Mon Jun 24 14:43:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OLhVnC008163 for ; Mon, 24 Jun 2002 14:43:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OLhV5Y008162 for linux-xfs-outgoing; Mon, 24 Jun 2002 14:43:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web13008.mail.yahoo.com (web13008.mail.yahoo.com [216.136.174.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OLhKnC008133 for ; Mon, 24 Jun 2002 14:43:20 -0700 Message-ID: <20020624214641.15654.qmail@web13008.mail.yahoo.com> Received: from [24.192.32.111] by web13008.mail.yahoo.com via HTTP; Mon, 24 Jun 2002 14:46:41 PDT Date: Mon, 24 Jun 2002 14:46:41 -0700 (PDT) From: nero one Subject: getting 2.4-xfs from cvs tree To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi .. i'm not sure if this is the right list to post this on. I'm currently trying to get linux-2.4-xfs from the cvs tree. This is what's going on: I'm using immunix v7.0 (hardened redhat) on a 2.4.18 kernel. Script started on Mon Jun 24 16:42:28 2002 [04:59pm][flamingfw] [root][~/install] export CVSROOT=':pserver:cvs@oss.sgi.com:/cvs' [04:59pm][flamingfw] [root][~/install] cvs login (Logging in to cvs@oss.sgi.com) CVS password: *** [05:00pm][flamingfw] [root][~/install] cvs -z3 co linux-2.4-xfs cvs server: Updating linux-2.4-xfs cvs server: Updating linux-2.4-xfs/cmd U linux-2.4-xfs/cmd/Makefile cvs server: Updating linux-2.4-xfs/cmd/acl U linux-2.4-xfs/cmd/acl/Makefile U linux-2.4-xfs/cmd/acl/Makepkgs U linux-2.4-xfs/cmd/acl/README U linux-2.4-xfs/cmd/acl/VERSION U linux-2.4-xfs/cmd/acl/configure.in U linux-2.4-xfs/cmd/acl/install-sh cvs server: Updating linux-2.4-xfs/cmd/acl/build U linux-2.4-xfs/cmd/acl/build/Makefile cvs server: Updating linux-2.4-xfs/cmd/acl/build/rpm U linux-2.4-xfs/cmd/acl/build/rpm/Makefile U linux-2.4-xfs/cmd/acl/build/rpm/acl.spec.in U linux-2.4-xfs/cmd/acl/build/rpm/macros.template U linux-2.4-xfs/cmd/acl/build/rpm/rpm-2.rc.template cvs server: Updating linux-2.4-xfs/cmd/acl/build/tar U linux-2.4-xfs/cmd/acl/build/tar/Makefile cvs server: Updating linux-2.4-xfs/cmd/acl/chacl U linux-2.4-xfs/cmd/acl/chacl/Makefile U linux-2.4-xfs/cmd/acl/chacl/chacl.c cvs server: Updating linux-2.4-xfs/cmd/acl/debian U linux-2.4-xfs/cmd/acl/debian/Makefile U linux-2.4-xfs/cmd/acl/debian/changelog U linux-2.4-xfs/cmd/acl/debian/control U linux-2.4-xfs/cmd/acl/debian/copyright U linux-2.4-xfs/cmd/acl/debian/rules [ ** cropped a bit cause it's the same thing over and over again ** ] cvs server: Updating linux-2.4-xfs/linux/drivers/telephony U linux-2.4-xfs/linux/drivers/telephony/Config.in U linux-2.4-xfs/linux/drivers/telephony/Makefile U linux-2.4-xfs/linux/drivers/telephony/ixj-ver.h cvs [checkout aborted]: writing linux-2.4-xfs/linux/drivers/telephony/ixj.c: No such file or directory Any ideas what's going on? __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com From owner-linux-xfs@oss.sgi.com Mon Jun 24 14:59:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OLxlnC008489 for ; Mon, 24 Jun 2002 14:59:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OLxkVc008488 for linux-xfs-outgoing; Mon, 24 Jun 2002 14:59:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OLxcnC008460 for ; Mon, 24 Jun 2002 14:59:39 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA07714 for ; Mon, 24 Jun 2002 15:02:54 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA12167; Tue, 25 Jun 2002 08:01:35 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5OM0rSC000983; Tue, 25 Jun 2002 08:00:53 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5OM0qOj000981; Tue, 25 Jun 2002 08:00:52 +1000 Date: Tue, 25 Jun 2002 08:00:52 +1000 From: Nathan Scott To: Michal Ambroz Cc: linux-xfs@oss.sgi.com Subject: Re: getfacl,chacl: - Argument list too long Message-ID: <20020624220052.GC468@frodo> References: <200206240736.g5O7atIU020570@oss.sgi.com> <3968.9225-19335-113214235-1024909571@seznam.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3968.9225-19335-113214235-1024909571@seznam.cz> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Jun 24, 2002 at 11:06:11AM +0200, Michal Ambroz wrote: > Hello, > > I am using RH 7.3 installed by SGI XFS installator for RedHat from > this place > ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/installer/i386/ > When I give to some file more than 11 acls (including u,g,o,m), it is > not possible to show the list of the currently set acls anyhow. > Neither "chacl -l" nor "getfacl" seems to work. > > I've tried to upgrade acl libacl packages to 2.0.11, but it didn't > help. Please is there any workaround how to obtain current acl from > file which has set more 12 on it? Or Is there any updated patched > kernel for RH 7.3? > You'll need to use a CVS kernel to fix this issue, until the next release is out (AFAIK no patched kernel exists yet, but maybe one of the distributors have a fixed kernel by now). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jun 24 15:09:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5OM91nC008720 for ; Mon, 24 Jun 2002 15:09:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5OM91Yd008719 for linux-xfs-outgoing; Mon, 24 Jun 2002 15:09:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5OM8rnC008691 for ; Mon, 24 Jun 2002 15:08:53 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id PAA06273 for ; Mon, 24 Jun 2002 15:12:13 -0700 (PDT) mail_from (nathans@larry.melbourne.sgi.com) Received: from frodo.melbourne.sgi.com (frodo.melbourne.sgi.com [134.14.55.153]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA12216; Tue, 25 Jun 2002 08:10:51 +1000 Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) with ESMTP id g5OMA8SC001033; Tue, 25 Jun 2002 08:10:08 +1000 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.4/8.12.4/Debian-2) id g5OMA8kO001031; Tue, 25 Jun 2002 08:10:08 +1000 Date: Tue, 25 Jun 2002 08:10:08 +1000 From: Nathan Scott To: tom Cc: linux-xfs@oss.sgi.com Subject: Re: question about inode count. Message-ID: <20020624221008.GD468@frodo> References: <3D16F61F.FCAFC63B@mountainviewdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D16F61F.FCAFC63B@mountainviewdata.com> User-Agent: Mutt/1.4i X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Mon, Jun 24, 2002 at 06:36:15PM +0800, tom wrote: > Sorry, maybe some one had asked the same question. > But I really want to figure out the phenomenon shown below. > > $ mkfs.xfs -f /dev/hda6 > $ xfs_db /dev/hda6 > > xfs_db: agi 0 > xfs_db: p The db commands... xfs_db: sb 0 xfs_db: p will show all three inode numbers (root, rt bitmap, and rt summary); all three are always allocated at mkfs time (incl. when an rt device is not in use). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jun 24 16:38:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5ONcunC013385 for ; Mon, 24 Jun 2002 16:38:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5ONcupR013384 for linux-xfs-outgoing; Mon, 24 Jun 2002 16:38:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gusi.leathercollection.ph (gusi.leathercollection.ph [202.163.192.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5ONcknC013356 for ; Mon, 24 Jun 2002 16:38:48 -0700 Received: from localhost (localhost [127.0.0.1]) by localhost.leathercollection.ph (Postfix) with ESMTP id A91CCC01216 for ; Tue, 25 Jun 2002 07:42:07 +0800 (PHT) Received: from kalabaw.leathercollection.ph (kalabaw.leathercollection.ph [192.168.0.12]) by gusi.leathercollection.ph (Postfix) with ESMTP id 15167C01210 for ; Tue, 25 Jun 2002 07:41:59 +0800 (PHT) Date: Tue, 25 Jun 2002 07:41:59 +0800 (PHT) From: Federico Sevilla III X-X-Sender: jijo@kalabaw To: Linux XFS Mailing List Subject: Re: getting 2.4-xfs from cvs tree In-Reply-To: <20020624214641.15654.qmail@web13008.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS snapshot-20020316 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 24 Jun 2002 at 14:46, nero one wrote: [ ... ] > cvs server: Updating linux-2.4-xfs/linux/drivers/telephony > U linux-2.4-xfs/linux/drivers/telephony/Config.in > U linux-2.4-xfs/linux/drivers/telephony/Makefile > U linux-2.4-xfs/linux/drivers/telephony/ixj-ver.h > cvs [checkout aborted]: writing linux-2.4-xfs/linux/drivers/telephony/ixj.c: No such file or > directory > > Any ideas what's going on? This email of yours came a mere few minutes after Eric Sandeen's checkin upgrading the tree to 2.4.19-rc1. I'm guessing that maybe you got hit by checking things out at almost the same time he was checking things in. Your procedure otherwise looks correct, so you may want to try it again (minus the cvs login, since you only have to do that once and it saves the information to ~/.cvspass). To the Linux XFS kernel hackers, ENJOY OTTAWA! I hope you all bring back nice happy hackerish memories. ;) --> Jijo -- Federico Sevilla III : Network Administrator : The Leather Collection, Inc. GnuPG Key ID : 0x93B746BE From owner-linux-xfs@oss.sgi.com Mon Jun 24 17:22:10 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5P0MAnC013934 for ; Mon, 24 Jun 2002 17:22:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P0MAMv013933 for linux-xfs-outgoing; Mon, 24 Jun 2002 17:22:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5P0M3nC013905 for ; Mon, 24 Jun 2002 17:22:03 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id RAA00974 for ; Mon, 24 Jun 2002 17:25:24 -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 KAA35828 for linux-xfs@oss.sgi.com; Tue, 25 Jun 2002 10:21:33 +1000 (EST) Date: Tue, 25 Jun 2002 10:21:33 +1000 (EST) From: Nathan Scott Message-Id: <200206250021.KAA35828@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - bump libacl version number X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Jun 24 17:21:22 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122265a cmd/acl/VERSION - 1.29 cmd/acl/doc/CHANGES - 1.33 cmd/acl/debian/changelog - 1.24 cmd/acl/libacl/Makefile - 1.17 - Changed libacl version number, since we haven't done so although several bugs've been fixed - libacl.1.0.0 --> libacl.so.1.0.1, IOW. no other changes in this version of the acl package. This fix is specifically for debian bug #150854. From owner-linux-xfs@oss.sgi.com Mon Jun 24 20:19:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5P3JrnC024508 for ; Mon, 24 Jun 2002 20:19:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P3Jr1w024507 for linux-xfs-outgoing; Mon, 24 Jun 2002 20:19:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5P3JfnC024478 for ; Mon, 24 Jun 2002 20:19:41 -0700 Received: from harris.cn.mvd (unknown [210.72.245.13]) by srv.dmz.us.mvd (Postfix) with ESMTP id 70B55B70D; Mon, 24 Jun 2002 20:23:02 -0700 (PDT) Date: Tue, 25 Jun 2002 12:28:26 +0800 (CST) From: Harrison Xing X-X-Sender: To: Seth Mos Cc: Subject: Re: Open file corruption? In-Reply-To: <4.3.2.7.2.20020622150124.02dbf5c0@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks for your suggestion. My concern is that whether my current XFS 1.0.1 release may lose data for files opened as read-only. Someone has seen once or twice that "fstab" is corrupted after power off. I know XFS 1.1 has made lots of enhancements, is it ever possible this also happens with XFS 1.1? Can anyone give a clear answer on this for both 1.0.1 and 1.1? Thanks. On Sat, 22 Jun 2002, Seth Mos wrote: > At 17:42 22-6-2002 +0800, Harrison Xing wrote: > > >On Sat, 22 Jun 2002, Seth Mos wrote: > > > > > At 10:51 22-6-2002 +0800, Harrison Xing wrote: > > > >Hi, > > > > > > > >There has been reports and FAQ about an open file which is modified is > > > >corrupted after power failure. But is it possible for a file that is > > opened > > > >for read-only access becomes corrupted after accidental power failure? We > > > >have met once or twice that some open files get lost even though there > > doesn't > > > >seem to have any process which modifies them. Thanks. > > > > > > What kernel, distro, hardware? > > > > > > >The XFS 1.0.1 release with 2.4.5. A little bit old. Intel HW. > > Better update to something more recent like the 1.1 release. It fixes a lot > of issues including the file corruption during power-off. I do remember > that someone else encountered this with a read_only opened file as well but > not what the cause was. > > Upgrading to 1.1 gives you a lot more robust XFS kernel then what yuo have > now and it's handling of open files will possibly be very different in > behaviour then what you see now. > > Cheers > > > > > > Cheers > > > > > > -- > > > Seth > > > It might just be your lucky day, if you only knew. > > > > > > >-- > >Best Regards, > >Harrison > > -- > Seth > It might just be your lucky day, if you only knew. > -- Best Regards, Harrison From owner-linux-xfs@oss.sgi.com Mon Jun 24 21:06:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5P46anC027319 for ; Mon, 24 Jun 2002 21:06:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P46aFY027318 for linux-xfs-outgoing; Mon, 24 Jun 2002 21:06:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail10b.sbc-webhosting.net (mail10b.sbc-webhosting.net [209.238.184.74]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5P46UnC027290 for ; Mon, 24 Jun 2002 21:06:31 -0700 Received: from www.75andsunny.com (168.143.156.115) by mail10b.sbc-webhosting.net (RS ver 1.0.63s) with SMTP id 052487 for ; Tue, 25 Jun 2002 00:09:45 -0400 (EDT) Message-ID: <00bd01c21bfe$1a547160$6401a8c0@fatboy> From: "John Stevens" To: Subject: XFS NFS and umask Date: Mon, 24 Jun 2002 21:09:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am running kernel 2.4.18 XFS, a clean install using the SGI installer. I have searched the archive for a solution to the umask not being set properly on NFS mounted volumes. I am mounting the Linux box on multiple Onyx and Onyx 2, is there a solution to this problem?? John Stevens Encore Hollywood From owner-linux-xfs@oss.sgi.com Mon Jun 24 22:57:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5P5vLnC028015 for ; Mon, 24 Jun 2002 22:57:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P5vLXb028014 for linux-xfs-outgoing; Mon, 24 Jun 2002 22:57:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.hs.tecmath.com (www.tecmath.com [194.55.1.65]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5P5v9nC027976 for ; Mon, 24 Jun 2002 22:57:10 -0700 Received: from [192.168.98.1] (helo=superserver.humanmodeling.tecmath.de) by mail.hs.tecmath.com with esmtp (Exim 3.33 #1) id 17MjNO-0007pS-00; Tue, 25 Jun 2002 08:00:30 +0200 Received: from [192.168.98.14] (helo=tmsgi7.humanmodeling.tecmath.de) by superserver.humanmodeling.tecmath.de with esmtp (Exim 3.22 #1) id 17MjNO-000643-00; Tue, 25 Jun 2002 08:00:30 +0200 Date: Tue, 25 Jun 2002 08:00:30 +0200 From: Martin Apel X-X-Sender: apel@tmsgi7.humanmodeling.tecmath.de To: john@75andsunny.con.sgi.com cc: linux-xfs@oss.sgi.com Subject: Re: XFS NFS and umask Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-1062706674-1015477701-1024984830=:746452" X-Spam-Status: No, hits=-1.0 required=5.0 tests=MIME_NULL_BLOCK,GAPPY_TEXT version=2.20 X-Spam-Level: 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. ---1062706674-1015477701-1024984830=:746452 Content-Type: TEXT/PLAIN; charset=US-ASCII > I am running kernel 2.4.18 XFS, a clean install using the SGI installer. I > have searched the archive for a solution to the umask not being set properly > on NFS mounted volumes. I am mounting the Linux box on multiple Onyx and > Onyx 2, is there a solution to this problem?? Hi John, everytime I compile a new kernel with XFS and NFS support in it, I apply the attached patch. It is originally dated from the days of 2.4.9 or the like, but it still (2.4.18) works for me now. Multiple SGI Octanes are NFS V2 clients for this Linux server and all works very well (though I had problems with NFS V3 on this combination). Martin ________________________________________________________________________ Martin Apel, Dipl.-Inform. t e c m a t h A G Group Manager Software Development Human Solutions Division phone +49 (0)631 303-5600 Europaallee 10, 67657 Kaiserslautern fax +49 (0)631 303-5700 Germany apel@hs.tecmath.com http://www.tecmath.com ________________________________________________________________________ ---1062706674-1015477701-1024984830=:746452 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=test Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=test ZGlmZiAtY3IgLi9uZnNzdmMuYyAvdXNyL3NyYy9saW51eC0yLjQuMTgteGZz L2ZzL25mc2QvbmZzc3ZjLmMNCioqKiAuL25mc3N2Yy5jICBXZWQgSnVuIDE5 IDEzOjQ1OjEyIDIwMDINCi0tLSAvdXNyL3NyYy9saW51eC0yLjQuMTgteGZz L2ZzL25mc2QvbmZzc3ZjLmMgIFdlZCBKdW4gMTkgMTM6NDQ6NTYgMjAwMg0K KioqKioqKioqKioqKioqDQoqKiogMTYxLDE2NiAqKioqDQotLS0gMTYxLDE2 NyAtLS0tDQogICAgICAgIE1PRF9JTkNfVVNFX0NPVU5UOw0KICAgICAgICBs b2NrX2tlcm5lbCgpOw0KICAgICAgICBkYWVtb25pemUoKTsNCisgICAgICAg Y3VycmVudC0+ZnMtPnVtYXNrID0gMDsNCiAgICAgICAgc3ByaW50ZihjdXJy ZW50LT5jb21tLCAibmZzZCIpOw0KICAgICAgICBjdXJyZW50LT5ybGltW1JM SU1JVF9GU0laRV0ucmxpbV9jdXIgPSBSTElNX0lORklOSVRZOw0KDQo= ---1062706674-1015477701-1024984830=:746452-- From owner-linux-xfs@oss.sgi.com Mon Jun 24 23:30:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5P6UqnC028521 for ; Mon, 24 Jun 2002 23:30:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P6UqJg028520 for linux-xfs-outgoing; Mon, 24 Jun 2002 23:30:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla2.xs4all.nl (smtpzilla2.xs4all.nl [194.109.127.138]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5P6UknC028492 for ; Mon, 24 Jun 2002 23:30:47 -0700 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5P6Y302039863; Tue, 25 Jun 2002 08:34:07 +0200 (CEST) Message-Id: <4.3.2.7.2.20020625083147.032322f0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jun 2002 08:33:56 +0200 To: Harrison Xing From: Seth Mos Subject: Re: Open file corruption? Cc: In-Reply-To: References: <4.3.2.7.2.20020622150124.02dbf5c0@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 12:28 25-6-2002 +0800, Harrison Xing wrote: >Thanks for your suggestion. >My concern is that whether my current XFS 1.0.1 release may >lose data for files opened as read-only. Someone has seen once or twice that >"fstab" is corrupted after power off. I know XFS 1.1 has made >lots of enhancements, is it ever possible this also happens >with XFS 1.1? A lot has changed since then. It might behave very different. The delete path has been made asynchronous but all of that should not make read only files get corrupted. Install a newer version and test again. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Jun 25 00:44:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5P7iXnC031325 for ; Tue, 25 Jun 2002 00:44:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5P7iXPw031324 for linux-xfs-outgoing; Tue, 25 Jun 2002 00:44:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5P7iQnC031293 for ; Tue, 25 Jun 2002 00:44:26 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id AAA01952 for ; Tue, 25 Jun 2002 00:47:48 -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 RAA07845; Tue, 25 Jun 2002 17:46:29 +1000 (EST) Date: Tue, 25 Jun 2002 17:46:29 +1000 (EST) From: Nathan Scott Message-Id: <200206250746.RAA07845@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - libacl X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 25 00:45:27 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122277a cmd/acl/VERSION - 1.30 cmd/acl/doc/CHANGES - 1.34 cmd/acl/man/man3/acl_get_file.3 - 1.8 cmd/acl/debian/changelog - 1.25 cmd/acl/libacl/Makefile - 1.18 cmd/acl/libacl/acl_set_file.c - 1.3 cmd/acl/libacl/acl_get_file.c - 1.4 cmd/acl/man/man3/acl_set_file.3 - 1.3 - Patch from AndreasG - acl_get_file/acl_set_file have been made to follow the draft standard to the letter. Bump versions. From owner-linux-xfs@oss.sgi.com Tue Jun 25 07:06:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5PE6nnC021961 for ; Tue, 25 Jun 2002 07:06:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PE6n3o021960 for linux-xfs-outgoing; Tue, 25 Jun 2002 07:06:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp.ht.net.tw (smtp.ht.net.tw [203.79.224.62]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5PE6gnC021932 for ; Tue, 25 Jun 2002 07:06:44 -0700 Received: from michael ([210.201.167.2]) by smtp.ht.net.tw (8.9.3/8.9.3) with SMTP id WAA25850368 for ; Tue, 25 Jun 2002 22:10:05 +0800 (CST) From: "apol" To: Subject: problem for xfs Date: Tue, 25 Jun 2002 22:11:06 +0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id g5PE6jnC021933 X-Spam-Status: No, hits=-0.5 required=5.0 tests=DEAR_SOMEBODY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dear Sir: I am trying to new install xfs 1.0.2 from iso image. But fail everytime in transfering install image to disk.... It always say that it might be out of disk space. But I am sure the hardware is all right and If I install instead of RedHat 7.2 original CD. All system can be installed correctly without error. Can you help to explain these errors ? Best Regards, Michael From owner-linux-xfs@oss.sgi.com Tue Jun 25 11:48:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5PImKnC001009 for ; Tue, 25 Jun 2002 11:48:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PImKAR001008 for linux-xfs-outgoing; Tue, 25 Jun 2002 11:48:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5PImFnC000980 for ; Tue, 25 Jun 2002 11:48:15 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA32711 for ; Tue, 25 Jun 2002 13:51:35 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA43742 for ; Tue, 25 Jun 2002 13:51:35 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g5PIn6J19122; Tue, 25 Jun 2002 13:49:06 -0500 Message-Id: <200206251849.g5PIn6J19122@jen.americas.sgi.com> Date: Tue, 25 Jun 2002 13:49:06 -0500 Subject: TAKE - fix preempt build with new spinlock code To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 25 11:50:41 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122302a linux/fs/xfs/support/spin.h - 1.7 - Include sched.h for the preempt case From owner-linux-xfs@oss.sgi.com Tue Jun 25 14:33:32 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5PLXWnC007787 for ; Tue, 25 Jun 2002 14:33:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PLXWNq007784 for linux-xfs-outgoing; Tue, 25 Jun 2002 14:33:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dns.securities.com (mail01.securities.com [57.69.15.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5PLXNnC007755 for ; Tue, 25 Jun 2002 14:33:24 -0700 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g5PLaj927641; Tue, 25 Jun 2002 17:36:46 -0400 Date: Tue, 25 Jun 2002 17:36:45 -0400 (EDT) From: Benito Venegas To: Harrison Xing cc: Seth Mos , Subject: Re: Open file corruption? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I experience some problems after some reboots in my 2550 and 2450. After to apply 2.4.9-31 with xfs version 1.1, I haven't experienced same problem (I did some test open some files with vi and other internal web tools and I reboot the servers) My $0.02 of experience. On Tue, 25 Jun 2002, Harrison Xing wrote: > > Thanks for your suggestion. > My concern is that whether my current XFS 1.0.1 release may > lose data for files opened as read-only. Someone has seen once or twice that > "fstab" is corrupted after power off. I know XFS 1.1 has made > lots of enhancements, is it ever possible this also happens > with XFS 1.1? > > Can anyone give a clear answer on this for both 1.0.1 and 1.1? Thanks. > > -- Benito A. Venegas System Engineer, Technology 225 Park Ave. South (6th floor ISI) New York, NY 10003 A Euromoney Institutional Investor company. From owner-linux-xfs@oss.sgi.com Tue Jun 25 15:29:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5PMTKnC008476 for ; Tue, 25 Jun 2002 15:29:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PMTKl8008475 for linux-xfs-outgoing; Tue, 25 Jun 2002 15:29:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5PMTEnC008447 for ; Tue, 25 Jun 2002 15:29:14 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA09374 for ; Tue, 25 Jun 2002 15:32:38 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA34147; Wed, 26 Jun 2002 08:31:13 +1000 (EST) Date: Wed, 26 Jun 2002 08:31:13 +1000 (EST) From: Nathan Scott Message-Id: <200206252231.IAA34147@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: ag@bestbits.at Subject: TAKE - chacl X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Jun 25 15:30:24 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:122330a cmd/acl/doc/CHANGES - 1.35 cmd/acl/chacl/chacl.c - 1.15 - Minor update to make chacl behave correctly with acl_[set|get]_file change. From owner-linux-xfs@oss.sgi.com Tue Jun 25 15:49:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5PMnNnC008832 for ; Tue, 25 Jun 2002 15:49:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5PMnNS5008831 for linux-xfs-outgoing; Tue, 25 Jun 2002 15:49:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5PMnHnC008803 for ; Tue, 25 Jun 2002 15:49:17 -0700 Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id PAA02240 for ; Tue, 25 Jun 2002 15:52:42 -0700 (PDT) mail_from (shepardl@sgi.com) Received: from mtv-mven006e--n.corp.sgi.com (mtv-mven006e--n.corp.sgi.com [192.26.57.106]) by cthulhu.engr.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id PAA34320; Tue, 25 Jun 2002 15:51:27 -0700 (PDT) Received: by mtv-mven006e--n.corp.sgi.com with Internet Mail Service (5.5.2655.55) id ; Tue, 25 Jun 2002 15:51:26 -0700 Message-ID: From: Laura Shepard To: "'linux-xfs@oss.sgi.com'" Cc: Eric Eppe Subject: Can you tell me how many downloads there have been of XFS? Date: Tue, 25 Jun 2002 15:51:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=1.2 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK,MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there, There is significant business planning interest in knowing our XFS Linux installed base. I have a method of inferring this from the number of downloads. Ideally we would like to know how many downloads there have been of XFS since v1.0 was put on the site... can anyone assist? -Laura Laura Shepard SGI Marketing Manager : SANs & File Systems Phone: 650-933-5045 V-net 933-5045 Pager: 888-576-0185 Fax: 650-933-0977 Chatty Page at: shepardl_p@pager.sgi.com From owner-linux-xfs@oss.sgi.com Tue Jun 25 17:59:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5Q0x0nC016451 for ; Tue, 25 Jun 2002 17:59:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5Q0x0jJ016450 for linux-xfs-outgoing; Tue, 25 Jun 2002 17:59:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5Q0wqnC016422 for ; Tue, 25 Jun 2002 17:58:53 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA45458; Tue, 25 Jun 2002 20:02:07 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id UAA30945; Tue, 25 Jun 2002 20:02:07 -0500 (CDT) Date: Tue, 25 Jun 2002 19:57:08 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: apol cc: linux-xfs@oss.sgi.com Subject: Re: problem for xfs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.9 required=5.0 tests=IN_REP_TO,DEAR_SOMEBODY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Can you try the 7.3/1.1 installer and see if it works better for you? ftp://oss.sgi.com/projects/xfs/download/Release-1.1/installer/installer/i386/RH7.3-SGI-XFS-1.1.iso -Eric On Tue, 25 Jun 2002, apol wrote: > Dear Sir: > I am trying to new install xfs 1.0.2 from iso image. > But fail everytime in transfering install image to disk.... > It always say that it might be out of disk space. > But I am sure the hardware is all right and If I install instead of RedHat 7.2 original CD. > All system can be installed correctly without error. > Can you help to explain these errors ? > > Best Regards, > > > Michael > From owner-linux-xfs@oss.sgi.com Tue Jun 25 22:28:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5Q5SNnC027912 for ; Tue, 25 Jun 2002 22:28:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5Q5SNX9027911 for linux-xfs-outgoing; Tue, 25 Jun 2002 22:28:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wilma.widomaker.com (root@wilma.widomaker.com [204.17.220.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5Q5SHnC027883 for ; Tue, 25 Jun 2002 22:28:17 -0700 Received: from [209.96.179.167] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 17N5P5-0004v7-00; Wed, 26 Jun 2002 01:31:44 -0400 Received: from daydream.shannon.net (daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g5Q5G6807279; Wed, 26 Jun 2002 01:16:06 -0400 (EDT) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id g5Q5G3on005621; Wed, 26 Jun 2002 01:16:03 -0400 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id g5Q5FvXY005620; Wed, 26 Jun 2002 01:15:57 -0400 Date: Wed, 26 Jun 2002 01:15:57 -0400 From: Charles Shannon Hendrix To: Laura Shepard Cc: "'linux-xfs@oss.sgi.com'" , Eric Eppe Subject: Re: Can you tell me how many downloads there have been of XFS? Message-ID: <20020626051556.GF4670@widomaker.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.99i X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,ASCII_FORM_ENTRY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Jun 25, 2002 at 03:51:18PM -0700, Laura Shepard wrote: > > Hi there, > > There is significant business planning interest in knowing our XFS Linux > installed base. > > I have a method of inferring this from the number of downloads. > > Ideally we would like to know how many downloads there have been of XFS > since v1.0 was put on the site... can anyone assist? I find it a little odd that you asked on this mailing list. Shouldn't you be talking to an SGI system admin about this? Most of the people on this list are likely to be non-SGI people. -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Wed Jun 26 00:47:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5Q7lcnC029112 for ; Wed, 26 Jun 2002 00:47:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5Q7lc6F029111 for linux-xfs-outgoing; Wed, 26 Jun 2002 00:47:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5Q7lSnC029083 for ; Wed, 26 Jun 2002 00:47:29 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-163-7.quicknet.nl [212.58.163.7]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5Q7osmM061977; Wed, 26 Jun 2002 09:50:54 +0200 (CEST) Message-Id: <4.3.2.7.2.20020626094652.02d07ea0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jun 2002 09:50:38 +0200 To: Laura Shepard , "'linux-xfs@oss.sgi.com'" From: Seth Mos Subject: Re: Can you tell me how many downloads there have been of XFS? Cc: Eric Eppe In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:51 25-6-2002 -0700, Laura Shepard wrote: >Hi there, > >There is significant business planning interest in knowing our XFS Linux >installed base. > >I have a method of inferring this from the number of downloads. That does not mean a thing. - There are a number of people on this list that download the iso once and setup a complete server farm afterwards. - I redistribute the iso/cd to friends who are also interested in XFS. - At work we downloaded the ISO once but we have 3 systems running from that installer. - People download the newer iso to upgrade their distribution to the latest version. >Ideally we would like to know how many downloads there have been of XFS >since v1.0 was put on the site... can anyone assist? Take those numbers with a heap of salt. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jun 26 01:00:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5Q803nC029451 for ; Wed, 26 Jun 2002 01:00:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5Q803hK029450 for linux-xfs-outgoing; Wed, 26 Jun 2002 01:00:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from K-7.stesmi.com (as4-1-7.has.s.bonet.se [217.215.31.238]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5Q7xvnC029413 for ; Wed, 26 Jun 2002 00:59:57 -0700 Received: from stesmi.com (voyager.stesmi.com [192.168.1.11]) by K-7.stesmi.com (8.12.4/8.12.4) with ESMTP id g5Q80ltO001311; Wed, 26 Jun 2002 10:00:48 +0200 Message-ID: <3D197533.8080006@stesmi.com> Date: Wed, 26 Jun 2002 10:02:59 +0200 From: Stefan Smietanowski User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seth Mos CC: Laura Shepard , "'linux-xfs@oss.sgi.com'" , Eric Eppe Subject: Re: Can you tell me how many downloads there have been of XFS? References: <4.3.2.7.2.20020626094652.02d07ea0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.3(snapshot 20020312) (K-7.stesmi.com) X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> There is significant business planning interest in knowing our XFS Linux >> installed base. >> I have a method of inferring this from the number of downloads. > That does not mean a thing. > - There are a number of people on this list that download the iso once > and setup a complete server farm afterwards. > - I redistribute the iso/cd to friends who are also interested in XFS. > - At work we downloaded the ISO once but we have 3 systems running from > that installer. > - People download the newer iso to upgrade their distribution to the > latest version. And naturally there are people that download it but never install it. Or download it, forget to take the CD with them to where they need it and download it again. I know I've fit in the later category myself :) // Stefan From owner-linux-xfs@oss.sgi.com Wed Jun 26 01:21:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5Q8LanC029795 for ; Wed, 26 Jun 2002 01:21:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5Q8LaPv029794 for linux-xfs-outgoing; Wed, 26 Jun 2002 01:21:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from goliath.sylaba.poznan.pl (goliath.sylaba.poznan.pl [195.216.104.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5Q8LRnC029764 for ; Wed, 26 Jun 2002 01:21:28 -0700 Received: by goliath.sylaba.poznan.pl (8.11.6/8.10.1) id g5Q8OmB06604 for linux-xfs@oss.sgi.com.KAV; Wed, 26 Jun 2002 10:24:48 +0200 (CEST) Received: from venus.local.navi.pl (ps103.poznan.sdi.tpnet.pl [217.97.72.103]) by goliath.sylaba.poznan.pl (8.11.6/8.10.1) with ESMTP id g5Q8Ol306566; Wed, 26 Jun 2002 10:24:47 +0200 (CEST) Received: from venus.local.navi.pl (venus.local.navi.pl [192.168.1.10]) by venus.local.navi.pl (8.11.6/8.11.6) with ESMTP id g5Q8Pda03157; Wed, 26 Jun 2002 10:25:39 +0200 Subject: Re: Can you tell me how many downloads there have been of XFS? From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Seth Mos Cc: Laura Shepard , "'linux-xfs@oss.sgi.com'" , Eric Eppe In-Reply-To: <4.3.2.7.2.20020626094652.02d07ea0@pop.xs4all.nl> References: <4.3.2.7.2.20020626094652.02d07ea0@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 (1.0.3-4) Date: 26 Jun 2002 10:25:39 +0200 Message-Id: <1025079939.1229.13.camel@venus> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-26 at 09:50, Seth Mos wrote: > At 15:51 25-6-2002 -0700, Laura Shepard wrote: > > >Hi there, > > > >There is significant business planning interest in knowing our XFS Linux > >installed base. > > > >I have a method of inferring this from the number of downloads. > > That does not mean a thing. > > - There are a number of people on this list that download the iso once and > setup a complete server farm afterwards. > - I redistribute the iso/cd to friends who are also interested in XFS. > - At work we downloaded the ISO once but we have 3 systems running from > that installer. > - People download the newer iso to upgrade their distribution to the latest > version. > Hi, People don't need to download iso. When I started to use XFS I downloaded patch. Now I use CVS. And I think many other people don't use iso either. It could be that the people using iso images are in minority. And think about downloads from mirrors. Regards, Olaf Fraczyk From owner-linux-xfs@oss.sgi.com Wed Jun 26 06:04:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QD4KnC002739 for ; Wed, 26 Jun 2002 06:04:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QD4Kg3002738 for linux-xfs-outgoing; Wed, 26 Jun 2002 06:04:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QD4BnC002710 for ; Wed, 26 Jun 2002 06:04:12 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA43187; Wed, 26 Jun 2002 08:07:32 -0500 (CDT) Received: from n236.ols.wavesec.net (cf-vpn-sw-corp-64-70.corp.sgi.com [134.15.64.70]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA71408; Wed, 26 Jun 2002 08:07:29 -0500 (CDT) Subject: Re: Can you tell me how many downloads there have been of XFS? From: Stephen Lord To: Laura Shepard Cc: "'linux-xfs@oss.sgi.com'" , Eric Eppe In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 26 Jun 2002 08:02:33 -0500 Message-Id: <1025096555.1108.6.camel@n236> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-25 at 17:51, Laura Shepard wrote: > > Hi there, > > There is significant business planning interest in knowing our XFS Linux > installed base. > > I have a method of inferring this from the number of downloads. > > Ideally we would like to know how many downloads there have been of XFS > since v1.0 was put on the site... can anyone assist? I do not think we have hard numbers, the logs on the machine have been purged several times. We are probably talking about a number somewhere between 10 and 100 thousand - the range really could be that wide. And of course one download does not mean one install, it can mean a failed install, and it can mean 100 installs. There are also several mirror sites people can download from. Eric can probably parse the logs on oss and get some numbers for a smaller time period. We would also have to factor in the distributions which ship XFS now: Suse, Mandrake (soon available on pc's in Walmart!), Debian and a number of less well known ones. Then do not forget the NAS boxes: Quantum, HP, Brocade, NEC, Sun and several others. The set top and embedded applications we do not really have any idea about. There is a good chance out install base is bigger than Irix by now. Steve > > -Laura > > Laura Shepard > SGI Marketing Manager : SANs & File Systems > Phone: 650-933-5045 V-net 933-5045 Pager: 888-576-0185 > Fax: 650-933-0977 Chatty Page at: shepardl_p@pager.sgi.com From owner-linux-xfs@oss.sgi.com Wed Jun 26 06:09:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QD9snC003091 for ; Wed, 26 Jun 2002 06:09:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QD9sd7003090 for linux-xfs-outgoing; Wed, 26 Jun 2002 06:09:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QD9nnC003062 for ; Wed, 26 Jun 2002 06:09:49 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA44827 for ; Wed, 26 Jun 2002 08:13:13 -0500 (CDT) Received: from n236 (cf-vpn-sw-corp-64-70.corp.sgi.com [134.15.64.70]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA22462 for ; Wed, 26 Jun 2002 08:13:11 -0500 (CDT) From: Steve Lord Received: by n236 (8.11.6/SGI-client-1.7) id g5QD8DL01259; Wed, 26 Jun 2002 08:08:13 -0500 Message-Id: <200206261308.g5QD8DL01259@n236> Date: Wed, 26 Jun 2002 08:08:13 -0500 Subject: TAKE - remove some unused cred structs from the stack To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Jun 26 06:12:10 PDT 2002 Workarea: cf-vpn-sw-corp-64-70.corp.sgi.com:/home/lord/src/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122363a linux/fs/xfs/linux/xfs_file.c - 1.67 linux/fs/xfs/linux/xfs_ioctl.c - 1.64 From owner-linux-xfs@oss.sgi.com Wed Jun 26 06:16:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QDGqnC003283 for ; Wed, 26 Jun 2002 06:16:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QDGq7Q003282 for linux-xfs-outgoing; Wed, 26 Jun 2002 06:16:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from casbah.gatech.edu (IDENT:root@casbah.gatech.edu [130.207.165.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QDGlnC003254 for ; Wed, 26 Jun 2002 06:16:48 -0700 Received: from ransom (ransom.datahostage.com [130.207.197.177]) by casbah.gatech.edu (8.9.2/8.9.2) with ESMTP id JAA17478; Wed, 26 Jun 2002 09:20:00 -0400 (EDT) Subject: Re: Can you tell me how many downloads there have been of XFS? From: Rob Myers To: Laura Shepard Cc: "'linux-xfs@oss.sgi.com'" , Eric Eppe In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 26 Jun 2002 09:19:09 -0400 Message-Id: <1025097549.3196.71.camel@ransom> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-06-25 at 18:51, Laura Shepard wrote: > > Hi there, > > There is significant business planning interest in knowing our XFS Linux > installed base. > > I have a method of inferring this from the number of downloads. does this method account for those of us who keep local mirrors and then deploy on 100+ boxes? what about now that xfs is in the aa tree? good luck! ;) rob. From owner-linux-xfs@oss.sgi.com Wed Jun 26 06:17:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QDHUnC003430 for ; Wed, 26 Jun 2002 06:17:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QDHU09003429 for linux-xfs-outgoing; Wed, 26 Jun 2002 06:17:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from peter.giprovostokneft.ru ([195.128.153.227]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QDHOnC003394 for ; Wed, 26 Jun 2002 06:17:25 -0700 Received: from pisem.net (IDENT:peter@peter.giprovostokneft.ru [127.0.0.1]) by peter.giprovostokneft.ru (8.12.2/8.12.2) with ESMTP id g5QDLidK004352 for ; Wed, 26 Jun 2002 18:21:45 +0500 Message-ID: <3D19BFE8.8040905@pisem.net> Date: Wed, 26 Jun 2002 18:21:44 +0500 From: Peter Vereshagin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020312 X-Accept-Language: ru, en, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: smbfs nls oops? Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello friends, I had downloaded the source RH package I built it and have same trouble as I saw with kernel.org source and manual 1.1 patch: while listing some drectory full of Cyrillic filenames on smbfs I get the kernel oops. I observe it with unpatched kernel too. But! there's no such bug in original distributed with ISOs kernel supplied. I wonder what could I do - I wrote to some newsgroups and From owner-linux-xfs@oss.sgi.com Wed Jun 26 08:36:49 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QFannC010805 for ; Wed, 26 Jun 2002 08:36:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QFanHU010804 for linux-xfs-outgoing; Wed, 26 Jun 2002 08:36:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QFahnC010776 for ; Wed, 26 Jun 2002 08:36:44 -0700 Received: from wilma.widomaker.com (wilma.widomaker.com [204.17.220.5]) 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 IAA07958 for ; Wed, 26 Jun 2002 08:40:28 -0700 (PDT) mail_from (shannon@escape.shannon.net) Received: from [209.96.179.167] (helo=escape.shannon.net) by wilma.widomaker.com with esmtp (Exim 3.22 #2) id 17NEla-0006lt-00 for linux-xfs@oss.sgi.com; Wed, 26 Jun 2002 11:31:35 -0400 Received: from daydream.shannon.net (daydream [192.168.1.10]) by escape.shannon.net (8.11.3nb1/8.11.3) with ESMTP id g5QEwV818066 for ; Wed, 26 Jun 2002 10:58:31 -0400 (EDT) Received: from daydream.shannon.net (localhost [127.0.0.1]) by daydream.shannon.net (8.12.4/8.11.4) with ESMTP id g5QEwVon008244 for ; Wed, 26 Jun 2002 10:58:31 -0400 Received: (from shannon@localhost) by daydream.shannon.net (8.12.4/8.12.4/Submit) id g5QEwVOm008243 for linux-xfs@oss.sgi.com; Wed, 26 Jun 2002 10:58:31 -0400 Date: Wed, 26 Jun 2002 10:58:31 -0400 From: Charles Shannon Hendrix To: linux-xfs@oss.sgi.com Subject: C compiler... Message-ID: <20020626145830.GB7973@widomaker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.99i X-Spam-Status: No, hits=0.0 required=5.0 tests=ASCII_FORM_ENTRY version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I note that the XFS patches suggest using egcs 2.91.66 to build the kernel. However, some new distributions (like Slackware) don't even ship with that compiler any more. While it's easy enough to get, I believe the kernel is supposed to be stable on later releases now. What are your feelings on using other versions of gcc for XFS builds? What about GCC 3.1.latest? -- UNIX/Perl/C/Pizza__________________________________shannon@widomaker.com From owner-linux-xfs@oss.sgi.com Wed Jun 26 09:23:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QGNinC011384 for ; Wed, 26 Jun 2002 09:23:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QGNi3q011383 for linux-xfs-outgoing; Wed, 26 Jun 2002 09:23:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla5.xs4all.nl (smtpzilla5.xs4all.nl [194.109.127.141]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QGNYnC011355 for ; Wed, 26 Jun 2002 09:23:35 -0700 Received: from auto-nb1.xs4all.nl (213-84-100-130.adsl.xs4all.nl [213.84.100.130]) by smtpzilla5.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5QGR2W6002477; Wed, 26 Jun 2002 18:27:02 +0200 (CEST) Message-Id: <4.3.2.7.2.20020626181932.039d32a8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 26 Jun 2002 18:26:16 +0200 To: Charles Shannon Hendrix , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: C compiler... In-Reply-To: <20020626145830.GB7973@widomaker.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:58 26-6-2002 -0400, Charles Shannon Hendrix wrote: >I note that the XFS patches suggest using egcs 2.91.66 to build >the kernel. However, some new distributions (like Slackware) don't >even ship with that compiler any more. While it's easy enough to get, >I believe the kernel is supposed to be stable on later releases now. > >What are your feelings on using other versions of gcc for XFS builds? 2.95.3 is used out there in various distributions and works for most people. I have not seen any take messages in a while that fixed bugs with respect to compilers. 2.91.66 is the most tested compiler and is used for any SGI releases/installers. it's not that it won't work with other compilers. That period is long gone. >What about GCC 3.1.latest? People are using it. No real problems AFAIK (or they are not speaking up). we have seen more reports on the various 2.96 compilers then the gcc 3 branch. The latest errata gcc-2.96 from redhat (or from 7.3) does works as advertised. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Wed Jun 26 09:56:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QGuhnC011744 for ; Wed, 26 Jun 2002 09:56:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QGuhY9011743 for linux-xfs-outgoing; Wed, 26 Jun 2002 09:56:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itspec.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QGuZnC011696 for ; Wed, 26 Jun 2002 09:56:36 -0700 Received: (from ctooley@localhost) by itspec.amoa.org (8.11.6/8.11.6) id g5QH04b03872; Wed, 26 Jun 2002 12:00:04 -0500 X-Authentication-Warning: itspec.amoa.org: ctooley set sender to ctooley@amoa.org using -f Subject: Re: Can you tell me how many downloads there have been of XFS? From: Chris Tooley To: linux-xfs@oss.sgi.com Cc: Laura Shepard In-Reply-To: <1025097549.3196.71.camel@ransom> References: <1025097549.3196.71.camel@ransom> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 26 Jun 2002 12:00:04 -0500 Message-Id: <1025110804.3801.7.camel@itspec.amoa.org> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I know there are at least 100 machines running XFS directly from my 7 or 8 downloads of the RedHat installer. You'd need to get a large base of people to do an accurate analysis and of course this list is probably not the best place to do it. :) On Wed, 2002-06-26 at 08:19, Rob Myers wrote: > On Tue, 2002-06-25 at 18:51, Laura Shepard wrote: > > > > Hi there, > > > > There is significant business planning interest in knowing our XFS Linux > > installed base. > > > > I have a method of inferring this from the number of downloads. > > does this method account for those of us who keep local mirrors and then > deploy on 100+ boxes? > > what about now that xfs is in the aa tree? > > good luck! ;) > > rob. > From owner-linux-xfs@oss.sgi.com Wed Jun 26 10:33:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QHXMnC012725 for ; Wed, 26 Jun 2002 10:33:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QHXMf6012724 for linux-xfs-outgoing; Wed, 26 Jun 2002 10:33:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QHWqnC012674 for ; Wed, 26 Jun 2002 10:32:53 -0700 Received: from poplar.sucs.soton.ac.uk (poplar.sucs.soton.ac.uk [152.78.128.30]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g5QHaLq05819; Wed, 26 Jun 2002 18:36:21 +0100 (BST) Received: from soton.ac.uk (pluto.sucs.soton.ac.uk [152.78.128.80]) (authenticated as idh) by poplar.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g5QHa4020495; Wed, 26 Jun 2002 18:36:04 +0100 (BST) Message-ID: <3D19FB83.DABDD538@soton.ac.uk> Date: Wed, 26 Jun 2002 18:36:03 +0100 From: "Ian D. Hardy" Organization: University of Southampton X-Mailer: Mozilla 4.7C-SGI [en] (X11; I; IRIX 6.5 IP32) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord , linux-xfs@oss.sgi.com CC: idh@soton.ac.uk, oz@soton.ac.uk Subject: Re: Re-occurance of NFS server panics References: <200203201906.g2KJ69q10974@jen.americas.sgi.com> <3CB5B736.3F588C69@soton.ac.uk> <1018964322.24401.0.camel@jen.americas.sgi.com> <3CFFABF9.5BFD2B80@soton.ac.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean X-Spam-Status: No, hits=0.8 required=5.0 tests=SIGNATURE_DELIM version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve ++ Colleagues, Sorry to bother you (I understand that your busy & short staffed) - it would be useful to get some feedback on the problems/issues I raised a couple of weeks ago (I did note that you mentioned continuing problems due to fragmentation in another thread a few days ago). Do you have any idea if/when it should be possible to fix this problem? (I feel bad asking; but I'm getting preasure to look again at alternatives ...... which I'd rather not do - as I'm sure they have their own problems!). FYI: in the last ~20 days we've had another panic, that looked like another memory alloc error (I was on leave - so didn't get the full details) + a couple of system lockups (high load average and failing to fileserve); possibly not related. We reduced the load by introducing another server/filesystem (reiserfs !!) and moving some users onto that, today we had some scheduled maintenance time and did an ofline defrag of the XFS filesystem bringing it down from ~28% to <1%. Is there anything that I can do (remember I'm not a kernel writer/expert) to help, any further diagnostics that would help. Again many thanks for your help. Ian Hardy "Ian D. Hardy" wrote: > > Steve, ++++ > > Some bad news, you may remember a couple of months ago I was > having problems with an NFS server that kept panicing, you > diagnosed a number of potential problems and patches; these > seemed to help! (many thanks) indeed this did work for ~45 > days but recently we started to get a re-occurance of these > failures (again with crashes ~every 4-6 days). > > I then remembered that one of your suggestions/fixes concerned > potential problems with high levels of filesystem fragmentation > (at the time I ran 'xfs_fsr' to defrag the filesystem and you > also introduced a change to the CVS tree intended to help > prevent these crashes). Anyway, I then noticed that at the > time that my crashes started to re-occur that the filesystem > fragmentation had increased to ~60% (!!!) as reported via > 'xfs_db' (some files having >3000 extents). Is it possible that > there is still a issue in the XFS kernel (I'm currently using a > kernel compiled from the CVS tree as of 17th May)? Oops/ksymoops > output below. > > I've ran xfs_fsr to defrag the filesystem (getting it back > down to <1%), however, I've (again) had a couple of instances > in which shortly after running 'xfs_fsr' the filesystem has > gone off-line, the system log shows: > > Jun 6 07:53:18 blue00 kernel: xfs_force_shutdown(md(9,0),0x8) called from line > 1039 of file xfs_trans.c. Return address = 0xc01e1fb9 > Jun 6 07:53:18 blue00 kernel: Corruption of in-memory data detected. Shutting > down filesystem: md(9,0) > > This was on an active filesystem. Is it possible that there > is a interaction between xfs_fsr and NFS? (I'd guess that xfs_fsr > may have a harder time detecting that a NFS client is accessing > a file than for local file access?. > > Our current intention, now we've defraged the filesystem is to > see how it goes for a couple of weeks if it seems better we will > then schedule regular (2-4 weeks) maintenance periods to run > 'xfs_fsr' on the filesytem without other filesystem activity. Does > this seem sensible too you? > > One question, if there is a problem associated with high levels > of fragmentation, is it overall high levels of fragmentation within > the filesytem that causes the failure or could it potentially be a > single file with a large number of extents? (I believe that we are > getting some highly fragmented files as we have a number of users/ > applications that frequently open, apend and then close a log file, > these files soon get fragmented as the close releases any pre-allocated > blocks). > > For various reasons I've not managed to capture the Oops outupt from > most of the recent crashes but here's one (passed through ksymoops) > that I did get. May help to identify the problem (does look to me > as though it is related to filesystem extents/fragmentation, > 'xfs_iext_realloc' in the trace, though I'm not a kernel code expert!). > > invalid operand: 0000 > CPU: 1 > EIP: 0010:[] Not tainted > Using defaults from ksymoops -t elf32-i386 -a i386 > EFLAGS: 00010086 > eax: 0000001d ebx: 00e350c0 ecx: 0000002e edx: 00000026 > esi: f8d4b000 edi: f8d43000 ebp: 00010000 esp: f3ba5a44 > ds: 0018 es: 0018 ss: 0018 > Process nfsd (pid: 615, stackpage=f3ba5000) > Stack: c02b4082 f8d43000 00008000 f8d4b000 c0e20000 00010000 00000286 f8d43000 > c01fd146 f8d43000 c01fd1a4 f8d43000 00010000 f4a5224c f8d43000 f8d4b000 > 00008000 c0e18000 c01d04f1 f8d43000 00008000 00010000 00000001 ffffffff > Call Trace: [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] [] [] [] [] > [] [] > Code: 0f 0b 83 c4 08 8b 15 2c 95 3f c0 8b 2c 1a 89 7c 24 14 b8 00 > > >>EIP; c012ff76 <===== > Trace; c01fd146 > Trace; c01fd1a4 > Trace; c01d04f0 > Trace; c01a6996 > Trace; c01a5f12 > Trace; c01d6474 > Trace; c01fd2e0 > Trace; c01aac14 > Trace; c01cf962 > Trace; c01e6e22 > Trace; c01e6340 > Trace; c026cf44 > Trace; c01f696e > Trace; c01e6340 > Trace; c014f45c > Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> > Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> > Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> > Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> > Trace; f8d2b348 <[nfsd]nfsd+1b8/370> > Trace; c01057ea > Code; c012ff76 > 00000000 <_EIP>: > Code; c012ff76 <===== > 0: 0f 0b ud2a <===== > Code; c012ff78 > 2: 83 c4 08 add $0x8,%esp > Code; c012ff7a > 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx > Code; c012ff80 > b: 8b 2c 1a mov (%edx,%ebx,1),%ebp > Code; c012ff84 > e: 89 7c 24 14 mov %edi,0x14(%esp,1) > Code; c012ff88 > 12: b8 00 00 00 00 mov $0x0,%eax > > > Many thanks for your past (and continued) support. I'll be > away from the 9th to the 23rd of June, I'd therefore be > grateful if you could copy any replies to my colleague Oz > Parchment at 'O.G.Parchment@soton.ac.uk'. > > Thanks again. > > Ian Hardy > > Steve Lord wrote: > > > > On Thu, 2002-04-11 at 11:17, Ian D. Hardy wrote: > > > Steve, +++ > > > > > > Good news! (though posting this is tempting fait a bit). Since > > > installing the XFS/CVS containing this fix my server has now > > > been up for 21+days, this is a record (it's average was ~4 days > > > but it did manage up to 14 days). > > > > > > I also applied the 'vnode.patch' that you posted in response > > > to my problems on 6th March, as far as I'm aware that has not > > > gone into the CVS tree? Is this still a valid patch? My > > > understanding is that I'd probably seen at least these two bugs > > > at various times? > > > > The vnode code changes should be in the tree as well. > > > > > > > > Many thanks for all your help. > > > > Thanks for perservering with xfs! > > > > Steve > > > > -- > > > > Steve Lord voice: +1-651-683-3511 > > Principal Engineer, Filesystem Software email: lord@sgi.com > > -- > > /////////////Technical Coordination, Research Services//////////////////// > Ian Hardy Tel: 023 80 593577 > Computing Services > Southampton University email: idh@soton.ac.uk > Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk > \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ -- /////////////Technical Coordination, Research Services//////////////////// Ian Hardy Tel: 023 80 593577 Computing Services Mobile: 0709 2127503 Southampton University email: idh@soton.ac.uk Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Wed Jun 26 11:10:27 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QIARnC013264 for ; Wed, 26 Jun 2002 11:10:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QIARJO013263 for linux-xfs-outgoing; Wed, 26 Jun 2002 11:10:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QI9rnC013166 for ; Wed, 26 Jun 2002 11:09:53 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA49098; Wed, 26 Jun 2002 13:13:16 -0500 (CDT) Received: from n236.ols.wavesec.net (cf-vpn-sw-corp-64-89.corp.sgi.com [134.15.64.89]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA64844; Wed, 26 Jun 2002 13:13:12 -0500 (CDT) Subject: Re: Re-occurance of NFS server panics From: Stephen Lord To: "Ian D. Hardy" Cc: linux-xfs@oss.sgi.com, idh@soton.ac.uk, oz@soton.ac.uk In-Reply-To: <3D19FB83.DABDD538@soton.ac.uk> References: <200203201906.g2KJ69q10974@jen.americas.sgi.com> <3CB5B736.3F588C69@soton.ac.uk> <1018964322.24401.0.camel@jen.americas.sgi.com> <3CFFABF9.5BFD2B80@soton.ac.uk> <3D19FB83.DABDD538@soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 26 Jun 2002 13:08:11 -0500 Message-Id: <1025114895.1280.10.camel@n236> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-06-26 at 12:36, Ian D. Hardy wrote: Sorry, you dropped through the cracks there, and I am currently sitting in the back of a talk at the Ottawa Linux Symposium, so my coding time is a little limited this week. Next week there will also be no one in the office (except the Australian contingent). Seems you have two issues, first file fragmentation and the fact that fsr appears to have issues on a live system. Yes I agree that running fsr during down time is the best solution available right now. I do not know if you have an idle time where you could actually run fsr on a known idle system. I think it has options to run for a fixed amount of time instead of running to completion. If you have known times when activity is low you could possibly run fsr during this period. The fundamental issue is the amount of memory which one of these fragmented files needs to hold its extents and the ideal solution to to change how this memory is organized. I have tinkered with the idea, but it is a non-trivial project and I do not know when I might get to do it. So I don't really have a code solution for you right now, we need to look into what is happening to fsr under nfs load, there should be something we can do to fix that faster than the extent allocation code. Steve > Steve ++ Colleagues, > > Sorry to bother you (I understand that your busy & short > staffed) - it would be useful to get some feedback on > the problems/issues I raised a couple of weeks ago (I did > note that you mentioned continuing problems due to > fragmentation in another thread a few days ago). Do you > have any idea if/when it should be possible to fix this > problem? (I feel bad asking; but I'm getting preasure to > look again at alternatives ...... which I'd rather not do - as I'm > sure they have their own problems!). > > FYI: in the last ~20 days we've had another panic, that looked > like another memory alloc error (I was on leave - so didn't > get the full details) + a couple of system lockups (high > load average and failing to fileserve); possibly not related. > We reduced the load by introducing another server/filesystem > (reiserfs !!) and moving some users onto that, today we had some > scheduled maintenance time and did an ofline defrag of the > XFS filesystem bringing it down from ~28% to <1%. > > Is there anything that I can do (remember I'm not a kernel > writer/expert) to help, any further diagnostics that would > help. > > Again many thanks for your help. > > Ian Hardy > > "Ian D. Hardy" wrote: > > > > Steve, ++++ > > > > Some bad news, you may remember a couple of months ago I was > > having problems with an NFS server that kept panicing, you > > diagnosed a number of potential problems and patches; these > > seemed to help! (many thanks) indeed this did work for ~45 > > days but recently we started to get a re-occurance of these > > failures (again with crashes ~every 4-6 days). > > > > I then remembered that one of your suggestions/fixes concerned > > potential problems with high levels of filesystem fragmentation > > (at the time I ran 'xfs_fsr' to defrag the filesystem and you > > also introduced a change to the CVS tree intended to help > > prevent these crashes). Anyway, I then noticed that at the > > time that my crashes started to re-occur that the filesystem > > fragmentation had increased to ~60% (!!!) as reported via > > 'xfs_db' (some files having >3000 extents). Is it possible that > > there is still a issue in the XFS kernel (I'm currently using a > > kernel compiled from the CVS tree as of 17th May)? Oops/ksymoops > > output below. > > > > I've ran xfs_fsr to defrag the filesystem (getting it back > > down to <1%), however, I've (again) had a couple of instances > > in which shortly after running 'xfs_fsr' the filesystem has > > gone off-line, the system log shows: > > > > Jun 6 07:53:18 blue00 kernel: xfs_force_shutdown(md(9,0),0x8) called from line > > 1039 of file xfs_trans.c. Return address = 0xc01e1fb9 > > Jun 6 07:53:18 blue00 kernel: Corruption of in-memory data detected. Shutting > > down filesystem: md(9,0) > > > > This was on an active filesystem. Is it possible that there > > is a interaction between xfs_fsr and NFS? (I'd guess that xfs_fsr > > may have a harder time detecting that a NFS client is accessing > > a file than for local file access?. > > > > Our current intention, now we've defraged the filesystem is to > > see how it goes for a couple of weeks if it seems better we will > > then schedule regular (2-4 weeks) maintenance periods to run > > 'xfs_fsr' on the filesytem without other filesystem activity. Does > > this seem sensible too you? > > > > One question, if there is a problem associated with high levels > > of fragmentation, is it overall high levels of fragmentation within > > the filesytem that causes the failure or could it potentially be a > > single file with a large number of extents? (I believe that we are > > getting some highly fragmented files as we have a number of users/ > > applications that frequently open, apend and then close a log file, > > these files soon get fragmented as the close releases any pre-allocated > > blocks). > > > > For various reasons I've not managed to capture the Oops outupt from > > most of the recent crashes but here's one (passed through ksymoops) > > that I did get. May help to identify the problem (does look to me > > as though it is related to filesystem extents/fragmentation, > > 'xfs_iext_realloc' in the trace, though I'm not a kernel code expert!). > > > > invalid operand: 0000 > > CPU: 1 > > EIP: 0010:[] Not tainted > > Using defaults from ksymoops -t elf32-i386 -a i386 > > EFLAGS: 00010086 > > eax: 0000001d ebx: 00e350c0 ecx: 0000002e edx: 00000026 > > esi: f8d4b000 edi: f8d43000 ebp: 00010000 esp: f3ba5a44 > > ds: 0018 es: 0018 ss: 0018 > > Process nfsd (pid: 615, stackpage=f3ba5000) > > Stack: c02b4082 f8d43000 00008000 f8d4b000 c0e20000 00010000 00000286 f8d43000 > > c01fd146 f8d43000 c01fd1a4 f8d43000 00010000 f4a5224c f8d43000 f8d4b000 > > 00008000 c0e18000 c01d04f1 f8d43000 00008000 00010000 00000001 ffffffff > > Call Trace: [] [] [] [] [] > > [] [] [] [] [] [] > > [] [] [] [] [] [] > > [] [] [] [] [] [] > > [] [] > > Code: 0f 0b 83 c4 08 8b 15 2c 95 3f c0 8b 2c 1a 89 7c 24 14 b8 00 > > > > >>EIP; c012ff76 <===== > > Trace; c01fd146 > > Trace; c01fd1a4 > > Trace; c01d04f0 > > Trace; c01a6996 > > Trace; c01a5f12 > > Trace; c01d6474 > > Trace; c01fd2e0 > > Trace; c01aac14 > > Trace; c01cf962 > > Trace; c01e6e22 > > Trace; c01e6340 > > Trace; c026cf44 > > Trace; c01f696e > > Trace; c01e6340 > > Trace; c014f45c > > Trace; f8d2e972 <[nfsd]nfsd_setattr+3ea/524> > > Trace; f8d33f7a <[nfsd]nfsd3_proc_setattr+b6/c4> > > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > > Trace; f8d2b5d2 <[nfsd]nfsd_dispatch+d2/19a> > > Trace; f8d3b4a0 <[nfsd]nfsd_procedures3+40/2c0> > > Trace; f8cf6f88 <[sunrpc]svc_process+28c/51c> > > Trace; f8d3b400 <[nfsd]nfsd_svcstats+0/40> > > Trace; f8d3aed8 <[nfsd]nfsd_version3+0/10> > > Trace; f8d2b348 <[nfsd]nfsd+1b8/370> > > Trace; c01057ea > > Code; c012ff76 > > 00000000 <_EIP>: > > Code; c012ff76 <===== > > 0: 0f 0b ud2a <===== > > Code; c012ff78 > > 2: 83 c4 08 add $0x8,%esp > > Code; c012ff7a > > 5: 8b 15 2c 95 3f c0 mov 0xc03f952c,%edx > > Code; c012ff80 > > b: 8b 2c 1a mov (%edx,%ebx,1),%ebp > > Code; c012ff84 > > e: 89 7c 24 14 mov %edi,0x14(%esp,1) > > Code; c012ff88 > > 12: b8 00 00 00 00 mov $0x0,%eax > > > > > > Many thanks for your past (and continued) support. I'll be > > away from the 9th to the 23rd of June, I'd therefore be > > grateful if you could copy any replies to my colleague Oz > > Parchment at 'O.G.Parchment@soton.ac.uk'. > > > > Thanks again. > > > > Ian Hardy > > > > Steve Lord wrote: > > > > > > On Thu, 2002-04-11 at 11:17, Ian D. Hardy wrote: > > > > Steve, +++ > > > > > > > > Good news! (though posting this is tempting fait a bit). Since > > > > installing the XFS/CVS containing this fix my server has now > > > > been up for 21+days, this is a record (it's average was ~4 days > > > > but it did manage up to 14 days). > > > > > > > > I also applied the 'vnode.patch' that you posted in response > > > > to my problems on 6th March, as far as I'm aware that has not > > > > gone into the CVS tree? Is this still a valid patch? My > > > > understanding is that I'd probably seen at least these two bugs > > > > at various times? > > > > > > The vnode code changes should be in the tree as well. > > > > > > > > > > > Many thanks for all your help. > > > > > > Thanks for perservering with xfs! > > > > > > Steve > > > > > > -- > > > > > > Steve Lord voice: +1-651-683-3511 > > > Principal Engineer, Filesystem Software email: lord@sgi.com > > > > -- > > > > /////////////Technical Coordination, Research Services//////////////////// > > Ian Hardy Tel: 023 80 593577 > > Computing Services > > Southampton University email: idh@soton.ac.uk > > Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk > > \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ > > -- > > /////////////Technical Coordination, Research Services//////////////////// > Ian Hardy Tel: 023 80 593577 > Computing Services Mobile: 0709 2127503 > Southampton University email: idh@soton.ac.uk > Southampton S017 1BJ, UK. i.d.hardy@soton.ac.uk > \\'BUGS: The notion of errors is ill-defined' (IRIX man page for netstat)\ From owner-linux-xfs@oss.sgi.com Wed Jun 26 12:04:03 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QJ43nC013713 for ; Wed, 26 Jun 2002 12:04:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QJ43ax013712 for linux-xfs-outgoing; Wed, 26 Jun 2002 12:04:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta02ps.bigpond.com (mta02ps.bigpond.com [144.135.25.134]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QJ3tnC013684 for ; Wed, 26 Jun 2002 12:03:56 -0700 Message-Id: <200206261903.g5QJ3tnC013684@oss.sgi.com> Received: from there ([144.135.25.81]) by mta02ps.bigpond.com (Netscape Messaging Server 4.15 mta02ps Apr 29 2002 13:22:02) with SMTP id GYBUG700.89I; Thu, 27 Jun 2002 05:07:19 +1000 Received: from CPE-144-137-130-109.qld.bigpond.net.au ([144.137.130.109]) by psmam05.mailsvc.email.bigpond.com(MailRouter V3.0n 107/21031150); 27 Jun 2002 05:07:18 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Seth Mos , Charles Shannon Hendrix , linux-xfs@oss.sgi.com Subject: Re: C compiler... Date: Thu, 27 Jun 2002 05:07:13 +1000 X-Mailer: KMail [version 1.3.1] References: <4.3.2.7.2.20020626181932.039d32a8@pop.xs4all.nl> In-Reply-To: <4.3.2.7.2.20020626181932.039d32a8@pop.xs4all.nl> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=-2.0 required=5.0 tests=IN_REP_TO,MSG_ID_ADDED_BY_MTA_2 version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 27 Jun 2002 02:26, Seth Mos wrote: > At 10:58 26-6-2002 -0400, Charles Shannon Hendrix wrote: > >What are your feelings on using other versions of gcc for XFS builds? > > 2.95.3 is used out there in various distributions and works for most > people. I have not seen any take messages in a while that fixed bugs with > respect to compilers. > > 2.91.66 is the most tested compiler and is used for any SGI > releases/installers. it's not that it won't work with other compilers. That > period is long gone. > > >What about GCC 3.1.latest? > > People are using it. No real problems AFAIK (or they are not speaking up). > we have seen more reports on the various 2.96 compilers then the gcc 3 > branch. The latest errata gcc-2.96 from redhat (or from 7.3) does works as > advertised. >From my experience I have successfully compiled XFS on a couple versions of gcc: 2.91.66, 2.96, 3.0.x. However, from experience the issue is with debugging as kdb doesn't always show the truth with anything but 2.91.66 -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Wed Jun 26 14:06:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QL64nC020334 for ; Wed, 26 Jun 2002 14:06:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QL64g3020333 for linux-xfs-outgoing; Wed, 26 Jun 2002 14:06:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from maple.sucs.soton.ac.uk (maple.sucs.soton.ac.uk [152.78.128.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QL5knC020295 for ; Wed, 26 Jun 2002 14:05:50 -0700 Received: from yew.sucs.soton.ac.uk (yew.sucs.soton.ac.uk [152.78.128.19]) by maple.sucs.soton.ac.uk (8.10.0/8.10.0) with ESMTP id g5QL9Fq17987; Wed, 26 Jun 2002 22:09:15 +0100 (BST) From: "Ian D. Hardy" Received: (from nobody@localhost) by yew.sucs.soton.ac.uk (8.9.3/8.9.3) id WAA07532; Wed, 26 Jun 2002 22:09:15 +0100 X-Authentication-Warning: yew.sucs.soton.ac.uk: nobody set sender to idh@soton.ac.uk using -f To: Stephen Lord Subject: Re: Re-occurance of NFS server panics Message-ID: <1025125755.3d1a2d7b4e940@webmail.soton.ac.uk> Date: Wed, 26 Jun 2002 22:09:15 +0100 (BST) Cc: "Ian D. Hardy" , linux-xfs@oss.sgi.com, I.D.Hardy@soton.ac.uk, O.G.Parchment@soton.ac.uk References: <200203201906.g2KJ69q10974@jen.americas.sgi.com> <3CB5B736.3F588C69@soton.ac.uk> <1018964322.24401.0.camel@jen.americas.sgi.com> <3CFFABF9.5BFD2B80@soton.ac.uk> <3D19FB83.DABDD538@soton.ac.uk> <1025114895.1280.10.camel@n236> In-Reply-To: <1025114895.1280.10.camel@n236> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.6 X-Originating-IP: 172.186.117.207 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve, Many thanks for the reply. I know how difficult it is to keep track of all support requests! (+ I've only got back from 2 weeks leave so am in no position to complain!) I'm looking into developing a script that uses 'find' to identify individual files that are candidates to defrag and that have not recently changed (& are therefore not likely to be currently active) and then run 'xfs_fsr' on the individual files, my guess is that this should then be reasonably safe to run on an active filesystem? Anyway hope that you're gettting some well earned holiday next week! Looking forwards to hearing from you when you/your colleagues have some time. Ian Hardy Quoting Stephen Lord : > On Wed, 2002-06-26 at 12:36, Ian D. Hardy wrote: > > Sorry, you dropped through the cracks there, and I am currently > sitting in the back of a talk at the Ottawa Linux Symposium, so > my coding time is a little limited this week. Next week there > will also be no one in the office (except the Australian > contingent). > > Seems you have two issues, first file fragmentation and the > fact that fsr appears to have issues on a live system. Yes > I agree that running fsr during down time is the best solution > available right now. I do not know if you have an idle time > where you could actually run fsr on a known idle system. I > think it has options to run for a fixed amount of time > instead of running to completion. If you have known times > when activity is low you could possibly run fsr during this > period. > > The fundamental issue is the amount of memory which one of > these fragmented files needs to hold its extents and the > ideal solution to to change how this memory is organized. > I have tinkered with the idea, but it is a non-trivial > project and I do not know when I might get to do it. > > So I don't really have a code solution for you right now, > we need to look into what is happening to fsr under nfs > load, there should be something we can do to fix that > faster than the extent allocation code. > > Steve > > > Steve ++ Colleagues, > > > > Sorry to bother you (I understand that your busy & short > > staffed) - it would be useful to get some feedback on > > the problems/issues I raised a couple of weeks ago (I did > > note that you mentioned continuing problems due to > > fragmentation in another thread a few days ago). Do you > > have any idea if/when it should be possible to fix this > > problem? (I feel bad asking; but I'm getting preasure to > > look again at alternatives ...... which I'd rather not do - as I'm > > sure they have their own problems!). > > > > FYI: in the last ~20 days we've had another panic, that looked > > like another memory alloc error (I was on leave - so didn't > > get the full details) + a couple of system lockups (high > > load average and failing to fileserve); possibly not related. > > We reduced the load by introducing another server/filesystem > > (reiserfs !!) and moving some users onto that, today we had some > > scheduled maintenance time and did an ofline defrag of the > > XFS filesystem bringing it down from ~28% to <1%. > > > > Is there anything that I can do (remember I'm not a kernel > > writer/expert) to help, any further diagnostics that would > > help. > > > > Again many thanks for your help. > > > > Ian Hardy > > From owner-linux-xfs@oss.sgi.com Wed Jun 26 15:21:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5QMLMnC022752 for ; Wed, 26 Jun 2002 15:21:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5QMLMJM022751 for linux-xfs-outgoing; Wed, 26 Jun 2002 15:21:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.190]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5QMLBnC022721 for ; Wed, 26 Jun 2002 15:21:11 -0700 Received: (qmail 26225 invoked by uid 500); 26 Jun 2002 22:24:32 -0000 Subject: Re: C compiler... From: Austin Gonyou To: Seth Mos Cc: Charles Shannon Hendrix , linux-xfs@oss.sgi.com In-Reply-To: <4.3.2.7.2.20020626181932.039d32a8@pop.xs4all.nl> References: <4.3.2.7.2.20020626181932.039d32a8@pop.xs4all.nl> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1yQ1O16yt1dxwHoJdMcz" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 26 Jun 2002 17:24:32 -0500 Message-Id: <1025130272.26008.1.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-1yQ1O16yt1dxwHoJdMcz Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've been using gcc 3.1 for kernels, glibc, and anything else I compile. so far so good without any compiler related issues AFAIK ATM. Nothing but *blazing* speed and usually good optimizations.=20 On Wed, 2002-06-26 at 11:26, Seth Mos wrote: > At 10:58 26-6-2002 -0400, Charles Shannon Hendrix wrote: >=20 > >I note that the XFS patches suggest using egcs 2.91.66 to build > >the kernel. However, some new distributions (like Slackware) don't > >even ship with that compiler any more. While it's easy enough to > get, > >I believe the kernel is supposed to be stable on later releases now. > > > >What are your feelings on using other versions of gcc for XFS builds? >=20 > 2.95.3 is used out there in various distributions and works for most=20 > people. I have not seen any take messages in a while that fixed bugs > with=20 > respect to compilers. >=20 > 2.91.66 is the most tested compiler and is used for any SGI=20 > releases/installers. it's not that it won't work with other compilers. > That=20 > period is long gone. >=20 > >What about GCC 3.1.latest? >=20 > People are using it. No real problems AFAIK (or they are not speaking > up). > we have seen more reports on the various 2.96 compilers then the gcc 3 > branch. The latest errata gcc-2.96 from redhat (or from 7.3) does > works as=20 > advertised. >=20 > Cheers >=20 > -- > Seth > It might just be your lucky day, if you only knew. --=20 Austin Gonyou Coremetrics, Inc. --=-1yQ1O16yt1dxwHoJdMcz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9Gj8g94g6ZVmFMoIRAuRkAJ0RsX38HFyFC+7EAdKlvutSNQlulACePP/N n/7H2y74FEeyiXqumcz93KQ= =CgX5 -----END PGP SIGNATURE----- --=-1yQ1O16yt1dxwHoJdMcz-- From owner-linux-xfs@oss.sgi.com Wed Jun 26 18:37:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5R1bqnC026777 for ; Wed, 26 Jun 2002 18:37:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5R1bqF3026776 for linux-xfs-outgoing; Wed, 26 Jun 2002 18:37:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mymail.canadawired.com (209-139-208-5.canadawired.com [209.139.208.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5R1binC026747 for ; Wed, 26 Jun 2002 18:37:45 -0700 Received: from alexa.myfakedomain.not (209-139-208-103.canadawired.com [209.139.208.103]) by mymail.canadawired.com (8.9.3/8.9.1) with ESMTP id SAA19395 for ; Wed, 26 Jun 2002 18:41:09 -0700 (PDT) (envelope-from rep@canadawired.com) Received: by alexa.myfakedomain.not (Postfix, from userid 1000) id AEB34D1CE7; Wed, 26 Jun 2002 18:41:39 -0700 (PDT) Date: Wed, 26 Jun 2002 18:41:39 -0700 From: Ron Peterson To: linux-xfs@oss.sgi.com Subject: 2.5-cvs and gcc-3.1 oops Message-ID: <20020627014139.GA4422@alexa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I am trying to compile today's 2.5-xfs from cvs using gcc-3.1. I get the following error: gcc -Wp,-MD,./.page_buf_locking.o.d -D__KERNEL__ -I/usr/src/linux-2.5-xfs/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O3 -march=i686 -fomit-frame-pointer -fno-strict-aliasing -fno-common -pipe -mpreferred-stack-boundary=2 -march=i686 -nostdinc -iwithprefix include -I. -funsigned-char -DKBUILD_BASENAME=page_buf_locking -c -o page_buf_locking.o pagebuf/page_buf_locking.c {standard input}: Assembler messages: {standard input}:404: Error: suffix or operands invalid for `bsf' make[2]: *** [page_buf_locking.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.5-xfs/linux/fs/xfs' make[1]: *** [xfs] Error 2 make[1]: Leaving directory `/usr/src/linux-2.5-xfs/linux/fs' make: *** [fs] Error 2 The system I am using was built with gcc-3.1 and the 2.5-xfs cvs kernel headers. It uses the 2.5-xfs cvs kernel from a few days ago, built with gcc-3.04 and the 2.4.18 kernel headers. Today's 2.5-xfs cvs builds ok with these. I found a mention of a similar problem mentioned on the web, with a suggestion to make a change to the ffs() function from asm/bitops.h. This didn't work. The error message was the same. Does anyone have any suggestions? Thanks, Ron From owner-linux-xfs@oss.sgi.com Wed Jun 26 19:28:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5R2SlnC027464 for ; Wed, 26 Jun 2002 19:28:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5R2SlGB027463 for linux-xfs-outgoing; Wed, 26 Jun 2002 19:28:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dns.securities.com (mail01.securities.com [57.69.15.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5R2SUnC027429 for ; Wed, 26 Jun 2002 19:28:31 -0700 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g5R2W0t15103; Wed, 26 Jun 2002 22:32:01 -0400 Date: Wed, 26 Jun 2002 22:32:00 -0400 (EDT) From: Benito Venegas To: cc: Marek Kubita Subject: kswapd Oops with 2.4.9-31SGI_XFS_1.1smp Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Boys (any girl here :P) System was running ok until today. I had to reboot server manually. This is the first one Oops since a long time ago (last was on xfs 1.0.2) This server is not using NFS server. We use some perl script, java tools for internal worflow system. I am checking if one of them used too much resources, but it looks like it was random. HW: PE6450 Mem: 2GB Swap: 2104432K (around 2GB) CPU: 4 PIII 700Mhz RAID Card: Perc2 with MegaRAID chip. (Vendor: MegaRAID Model: LD0 RAID1 8232R Rev: 161J) OS: RH 7.2 (Obvious, plus XFS 1.1) I will check if I need update firmware. If you have experienced similar Oops (Paul Petersen??) Please give me your comments about how did you fix it. Thanks Vene ksymoops 2.4.1 on i686 2.4.9-31SGI_XFS_1.1smp. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.4.9-31SGI_XFS_1.1smp/ (default) -m /boot/System.map-2.4.9-31SGI_XFS_1.1smp (default) Unable to handle kernel paging request at virtual address 29c8a8f0 printing eip:c0152ee4 *pde = 00000000 Oops: 0000 Kernel 2.4.9-31SGI_XFS_1.1smp CPU: 2 EIP: 0010:[clear_inode+296/380] Tainted: P EIP: 0010:[] Tainted: P EFLAGS: 00010206 EIP is at clear_inode [kernel] 0x128 eax: 29c8a8c0 ebx: cd439208 ecx: ea9b0580 edx: f7dd1fa4 esi: cd439200 edi: f7dd1fa4 ebp: f7dd1fa4 esp: f7dd1f68 ds: 0018 es: 0018 ss: 0018 Process kswapd (pid: 7, stackpage=f7dd1000) Stack: cd439208 cd439200 c0152f90 cd439200 f36b9048 f36b9040 c0386ce4 c015323f f7dd1fa4 00010965 000000c0 f7dd0339 0008e000 00000000 00018964 de6bd588 f52c6588 c0153299 fffe769c c01354a3 00000000 000000c0 00000000 000000c0 Call Trace: [dispose_list+88/116] dispose_list [kernel] 0x58 Call Trace: [] dispose_list [kernel] 0x58 [prune_icache+267/324] prune_icache [kernel] 0x10b [] prune_icache [kernel] 0x10b [shrink_icache_memory+33/48] shrink_icache_memory [kernel] 0x21 [] shrink_icache_memory [kernel] 0x21 [do_try_to_free_pages+35/80] do_try_to_free_pages [kernel] 0x23 [] do_try_to_free_pages [kernel] 0x23 [copyrite+20465/22593] copyrite [kernel] 0x4ff1 [] copyrite [kernel] 0x4ff1 [kswapd+77/232] kswapd [kernel] 0x4d [] kswapd [kernel] 0x4d [_stext+0/88] stext [kernel] 0x0 [] stext [kernel] 0x0 [kernel_thread+35/48] kernel_thread [kernel] 0x23 [] kernel_thread [kernel] 0x23 Code: 8b 40 30 85 c0 74 06 56 ff d0 83 c4 04 8b 86 00 01 00 00 85 >>EIP; c0152ee4 <===== Trace; c0152f90 Trace; c015323f Trace; c0153299 Trace; c01354a3 Trace; c02af751 Trace; c013551d Trace; c0105000 <_stext+0/0> Trace; c010580f Code; c0152ee4 00000000 <_EIP>: Code; c0152ee4 <===== 0: 8b 40 30 mov 0x30(%eax),%eax <===== Code; c0152ee7 3: 85 c0 test %eax,%eax Code; c0152ee9 5: 74 06 je d <_EIP+0xd> c0152ef1 Code; c0152eeb 7: 56 push %esi Code; c0152eec 8: ff d0 call *%eax Code; c0152eee a: 83 c4 04 add $0x4,%esp Code; c0152ef1 d: 8b 86 00 01 00 00 mov 0x100(%esi),%eax Code; c0152ef7 13: 85 00 test %eax,(%eax) -- Benito A. Venegas System Engineer, Technology 225 Park Ave. South (6th floor ISI) New York, NY 10003 A Euromoney Institutional Investor company. From owner-linux-xfs@oss.sgi.com Wed Jun 26 22:16:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5R5GMnC001798 for ; Wed, 26 Jun 2002 22:16:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5R5GMLm001796 for linux-xfs-outgoing; Wed, 26 Jun 2002 22:16:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.broadpark.no (217-13-4-9.dd.nextgentel.com [217.13.4.9]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5R5GHnC001768 for ; Wed, 26 Jun 2002 22:16:17 -0700 Received: from online.no (213-187-165-28.dd.nextgentel.com [213.187.165.28]) by mail.broadpark.no (Postfix) with ESMTP id 19E777D55 for ; Thu, 27 Jun 2002 07:19:40 +0200 (MEST) Message-ID: <3D1A9F57.98E4BB4F@online.no> Date: Thu, 27 Jun 2002 07:15:03 +0200 From: Knut J Bjuland X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-rc1-xfs i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Updated redhat kernel with bugfixes available.Are ther any plans for an XFS patch. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk http://lwn.net/Articles/3593/. Are ther any plans for an XFS patch for this updatet Redhat kernel? From owner-linux-xfs@oss.sgi.com Wed Jun 26 23:03:53 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5R63rnC002369 for ; Wed, 26 Jun 2002 23:03:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5R63qF3002368 for linux-xfs-outgoing; Wed, 26 Jun 2002 23:03:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from CoNetUX (IDENT:NqFC/Ne9POPATXgwJw1VnqpKPLL2aaOm@firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5R63hnC002340 for ; Wed, 26 Jun 2002 23:03:44 -0700 Received: from conet.cz (Libor [192.168.1.130]) by CoNetUX (8.11.6/8.11.6) with ESMTP id g5R67CE12927 for ; Thu, 27 Jun 2002 08:07:12 +0200 Message-ID: <3D1AAB70.4060400@conet.cz> Date: Thu, 27 Jun 2002 08:06:40 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS corruption! Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=PLING,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, we are selling Linux file servers and we wanted to use XFS. Our internal tests passed OK but when we installed first server at customer and migrated data an error occured (usually after copying 60-100 GB). In /var/log/messages we saw this messages: Jun 27 03:09:56 localhost kernel: xfs_btree_check_sblock: Not OK: Jun 27 03:09:56 localhost kernel: magic 0x41425443 level 0 numrecs 394 leftsib -1 rightsib -129 Jun 27 03:09:56 localhost kernel: xfs_btree_check_sblock: Not OK: Jun 27 03:09:56 localhost kernel: magic 0x41425443 level 0 numrecs 394 leftsib -1 rightsib -129 ...MANY MANY SAME... Jun 27 03:09:56 localhost kernel: xfs_btree_check_sblock: Not OK: Jun 27 03:09:56 localhost kernel: magic 0x41425443 level 0 numrecs 394 leftsib -1 rightsib -129 Jun 27 03:10:30 localhost kernel: xfs_force_shutdown(md(9,0),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xc01e816a Jun 27 03:10:30 localhost kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,0) Jun 27 03:10:30 localhost kernel: Please umount the filesystem, and rectify the problem(s) We tried migrating 160 GB of data using "cp -a" (over NFS), scp and rsync from old server using RH7.0 (ext2) - all resulted in this. The system is running software RAID5 (10x60GB), 1 GHz Celeron, 128 MB RAM, standard RH7.3 with SGI XFS modified installation CD. When we rebooted system everything seems OK (nothing lost) but after copying few more MB the same error occurs. We have built up 2 VERY same machines from same system image and both behave the very same so I think that it's some software failure. I have stress tested system with doing lot of "dd if=/dev/md0 of=/raid/tmp bs=10MB count=100" and recursive directories (about 50 levels deep) and nothing similar occured. Only when copying data over network from the old system. Thanks, Libor From owner-linux-xfs@oss.sgi.com Thu Jun 27 00:00:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5R70QnC003068 for ; Thu, 27 Jun 2002 00:00:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5R70QS8003067 for linux-xfs-outgoing; Thu, 27 Jun 2002 00:00:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla3.xs4all.nl (smtpzilla3.xs4all.nl [194.109.127.139]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5R70GnC003039 for ; Thu, 27 Jun 2002 00:00:16 -0700 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla3.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5R73hn4062594; Thu, 27 Jun 2002 09:03:47 +0200 (CEST) Message-Id: <4.3.2.7.2.20020627085551.03c50ce8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jun 2002 09:03:29 +0200 To: Benito Venegas , From: Seth Mos Subject: Re: kswapd Oops with 2.4.9-31SGI_XFS_1.1smp Cc: Marek Kubita In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 22:32 26-6-2002 -0400, Benito Venegas wrote: >Hi Boys (any girl here :P) > >System was running ok until today. I had to reboot server manually. >This is the first one Oops since a long time ago (last was on xfs 1.0.2) >This server is not using NFS server. >We use some perl script, java tools for internal worflow system. checking/repairing your filesystem might be a good idea. Even when it's not damaged it would not hurt to check. >I will check if I need update firmware. There have been both raid and bios updates in the past. I know of at least one PERC2 update that fixes corruption during poweroff with write back cache enabled. (even with the battery pack). Do you get this oops at every boot of the machine or very frequent? Checking your system after an Oops is always a good idea in my opinion. Journaling filesystems can recover from a poweroff and have filesystem integrity. But they can NOT protect you from data corruption when your kernel oopses. If something is clobbering some important part of memory that just got written to you have a serious problem. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jun 27 00:08:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5R78unC003296 for ; Thu, 27 Jun 2002 00:08:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5R78u99003295 for linux-xfs-outgoing; Thu, 27 Jun 2002 00:08:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5R78lnC003267 for ; Thu, 27 Jun 2002 00:08:48 -0700 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g5R7CHTC012710; Thu, 27 Jun 2002 09:12:17 +0200 (CEST) Message-Id: <4.3.2.7.2.20020627090504.03c4f4a0@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 27 Jun 2002 09:12:03 +0200 To: Libor Vanek , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: XFS corruption! In-Reply-To: <3D1AAB70.4060400@conet.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Status: No, hits=-3.9 required=5.0 tests=IN_REP_TO,PLING version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 08:06 27-6-2002 +0200, Libor Vanek wrote: >Hi, >we are selling Linux file servers and we wanted to use XFS. Our internal >tests passed OK but when we installed first server at customer and >migrated data an error occured (usually after copying 60-100 GB). In >/var/log/messages we saw this messages: One of the developers better comment on those messages. >We tried migrating 160 GB of data using "cp -a" (over NFS), scp and rsync >from old server using RH7.0 (ext2) - all resulted in this. >The system is running software RAID5 (10x60GB), 1 GHz Celeron, 128 MB RAM, >standard RH7.3 with SGI XFS modified installation CD. >When we rebooted system everything seems OK (nothing lost) but after >copying few more MB the same error occurs. >We have built up 2 VERY same machines from same system image and both >behave the very same so I think that it's some software failure. It sounds like it. Did you build this filesystem with any special mkfs options? What IDE controllers are you using? Did you use the 2.4.18 kernel that came on the installer disk or is this a selfcompiled version or even a CVS checkout? >I have stress tested system with doing lot of "dd if=/dev/md0 of=/raid/tmp >bs=10MB count=100" and recursive directories (about 50 levels deep) and >nothing similar occured. Only when copying data over network from the old >system. Weird. I frequently have to copy large amounts of data over the network and it works fine so I suspect that something in your filesystem is not right and causing it to fail again as soon as you try to copy to it again. Can you check/repair the filesystem and see if it appears again? Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Jun 27 03:55:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5RAt8nC013355 for ; Thu, 27 Jun 2002 03:55:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5RAt8ZK013354 for linux-xfs-outgoing; Thu, 27 Jun 2002 03:55:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from CoNetUX (IDENT:Pwe7odLTmj9RDGg/6rxLgh9ypgV7K0PK@firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5RAstnC013324 for ; Thu, 27 Jun 2002 03:54:56 -0700 Received: from conet.cz (Libor [192.168.1.130]) by CoNetUX (8.11.6/8.11.6) with ESMTP id g5RAwQE20207; Thu, 27 Jun 2002 12:58:26 +0200 Message-ID: <3D1AEFB0.3070609@conet.cz> Date: Thu, 27 Jun 2002 12:57:52 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seth Mos CC: linux-xfs@oss.sgi.com Subject: Re: XFS corruption! References: <4.3.2.7.2.20020627090504.03c4f4a0@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=PLING,SIGNATURE_DELIM version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > >> Hi, >> we are selling Linux file servers and we wanted to use XFS. Our >> internal tests passed OK but when we installed first server at >> customer and migrated data an error occured (usually after copying >> 60-100 GB). In /var/log/messages we saw this messages: > > One of the developers better comment on those messages. I also think so thats why I post my message here. >> We tried migrating 160 GB of data using "cp -a" (over NFS), scp and >> rsync from old server using RH7.0 (ext2) - all resulted in this. >> The system is running software RAID5 (10x60GB), 1 GHz Celeron, 128 MB >> RAM, standard RH7.3 with SGI XFS modified installation CD. >> When we rebooted system everything seems OK (nothing lost) but after >> copying few more MB the same error occurs. >> We have built up 2 VERY same machines from same system image and both >> behave the very same so I think that it's some software failure. > > It sounds like it. Did you build this filesystem with any special mkfs > options? > What IDE controllers are you using? Did you use the 2.4.18 kernel that > came on the installer disk or is this a selfcompiled version or even a > CVS checkout? I used default 2.4.18-4-XFS-1.1 and also custom build (same version) - no difference. >> I have stress tested system with doing lot of "dd if=/dev/md0 >> of=/raid/tmp bs=10MB count=100" and recursive directories (about 50 >> levels deep) and nothing similar occured. Only when copying data over >> network from the old system. > > Weird. I frequently have to copy large amounts of data over the > network and it works fine so I suspect that something in your > filesystem is not right and causing it to fail again as soon as you > try to copy to it again. Now I remember I had also tried to do this "dd" over NFS between the two same machines also whithout any corruption. Very strange. > Can you check/repair the filesystem and see if it appears again? I can - it does the same but sooner (not after copying tens of GB but after copying GBs). As it is production system (from which I'm copying) my tests are very limited. -- S pozdravem, Libor Vanek Kontakt: +-------------------------------------+ | Email: libor@conet.cz | | ICQ: 124529939 | | WWW: http://www.discobolos.net | | Tel/fax: 05/4122 5091, 6293, 6003 | | Mobil: 0603 536 946 | +-------------------------------------+ From owner-linux-xfs@oss.sgi.com Thu Jun 27 07:16:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5REFxnC016549 for ; Thu, 27 Jun 2002 07:16:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5REFxmP016548 for linux-xfs-outgoing; Thu, 27 Jun 2002 07:15:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dns.securities.com (mail01.securities.com [57.69.15.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5REFmnC016520 for ; Thu, 27 Jun 2002 07:15:49 -0700 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g5REJJK07917; Thu, 27 Jun 2002 10:19:19 -0400 Date: Thu, 27 Jun 2002 10:19:19 -0400 (EDT) From: Benito Venegas To: Seth Mos cc: , Marek Kubita Subject: Re: kswapd Oops with 2.4.9-31SGI_XFS_1.1smp In-Reply-To: <4.3.2.7.2.20020627085551.03c50ce8@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 27 Jun 2002, Seth Mos wrote: > At 22:32 26-6-2002 -0400, Benito Venegas wrote: > >Hi Boys (any girl here :P) > > > >System was running ok until today. I had to reboot server manually. > >This is the first one Oops since a long time ago (last was on xfs 1.0.2) > >This server is not using NFS server. > >We use some perl script, java tools for internal worflow system. > > checking/repairing your filesystem might be a good idea. Even when it's not > damaged it would not hurt to check. I did it of course. > > >I will check if I need update firmware. > > There have been both raid and bios updates in the past. I know of at least > one PERC2 update that fixes corruption during poweroff with write back > cache enabled. (even with the battery pack). > > Do you get this oops at every boot of the machine or very frequent? > Checking your system after an Oops is always a good idea in my opinion. This oops happened when my server was on production. It freeze from one momment to other. That ' s all. So it wasn't on reboot process.. > > Journaling filesystems can recover from a poweroff and have filesystem > integrity. > But they can NOT protect you from data corruption when your kernel oopses. > If something is clobbering some important part of memory that just got > written to you have a serious problem. After to be in the list for almost a year, yeah!! I have always in my considerations. Thanks Seth > Salu2 Vene From owner-linux-xfs@oss.sgi.com Thu Jun 27 07:21:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5RELqnC016831 for ; Thu, 27 Jun 2002 07:21:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5RELqiW016830 for linux-xfs-outgoing; Thu, 27 Jun 2002 07:21:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5RELhnC016792 for ; Thu, 27 Jun 2002 07:21:43 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA57488; Thu, 27 Jun 2002 09:25:10 -0500 (CDT) Received: from n236.ols.wavesec.net (cf-vpn-sw-corp-64-72.corp.sgi.com [134.15.64.72]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA51438; Thu, 27 Jun 2002 09:25:06 -0500 (CDT) Subject: Re: XFS corruption! From: Stephen Lord To: Libor Vanek Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D1AAB70.4060400@conet.cz> References: <3D1AAB70.4060400@conet.cz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 27 Jun 2002 09:18:59 -0500 Message-Id: <1025187574.1622.5.camel@n236> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.3 required=5.0 tests=IN_REP_TO,PLING,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-06-27 at 01:06, Libor Vanek wrote: > Hi, > we are selling Linux file servers and we wanted to use XFS. Our internal > tests passed OK but when we installed first server at customer and > migrated data an error occured (usually after copying 60-100 GB). In > /var/log/messages we saw this messages: > > Jun 27 03:09:56 localhost kernel: xfs_btree_check_sblock: Not OK: > Jun 27 03:09:56 localhost kernel: magic 0x41425443 level 0 numrecs 394 leftsib -1 rightsib -129 > Jun 27 03:09:56 localhost kernel: xfs_btree_check_sblock: Not OK: > Jun 27 03:09:56 localhost kernel: magic 0x41425443 level 0 numrecs 394 leftsib -1 rightsib -129 > ...MANY MANY SAME... > Jun 27 03:09:56 localhost kernel: xfs_btree_check_sblock: Not OK: > Jun 27 03:09:56 localhost kernel: magic 0x41425443 level 0 numrecs 394 leftsib -1 rightsib -129 > Jun 27 03:10:30 localhost kernel: xfs_force_shutdown(md(9,0),0x8) called from line 1039 of file xfs_trans.c. Return address > = 0xc01e816a > Jun 27 03:10:30 localhost kernel: Corruption of in-memory data detected. Shutting down filesystem: md(9,0) > Jun 27 03:10:30 localhost kernel: Please umount the filesystem, and rectify the problem(s) > > > We tried migrating 160 GB of data using "cp -a" (over NFS), scp and rsync from old server using RH7.0 (ext2) - all resulted in this. > The system is running software RAID5 (10x60GB), 1 GHz Celeron, 128 MB RAM, standard RH7.3 with SGI XFS modified installation CD. > When we rebooted system everything seems OK (nothing lost) but after copying few more MB the same error occurs. > We have built up 2 VERY same machines from same system image and both behave the very same so I think that it's some software failure. > > I have stress tested system with doing lot of "dd if=/dev/md0 of=/raid/tmp bs=10MB count=100" and recursive directories (about 50 levels deep) and nothing similar occured. Only when copying data over network from the old system. > > > Thanks, > Libor > > Can you please run xfs_check on the filesystem after this has happened. I suspect you may have found a hole in the endian conversion code in XFS. Doing the copy into the filesystem over NFS is probably generating more fragmentation and hence more complex free space structures than doing it locally. Steve From owner-linux-xfs@oss.sgi.com Thu Jun 27 13:11:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5RKBgnC022110 for ; Thu, 27 Jun 2002 13:11:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5RKBgSv022109 for linux-xfs-outgoing; Thu, 27 Jun 2002 13:11:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5RKBanC022081 for ; Thu, 27 Jun 2002 13:11:36 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA59992 for ; Thu, 27 Jun 2002 15:15:05 -0500 (CDT) Received: from n236 (mtv-vpn-sw-corp-0-56.corp.sgi.com [134.15.0.56]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA33134 for ; Thu, 27 Jun 2002 15:15:02 -0500 (CDT) From: Steve Lord Received: by n236 (8.11.6/SGI-client-1.7) id g5RK99A01348; Thu, 27 Jun 2002 15:09:09 -0500 Message-Id: <200206272009.g5RK99A01348@n236> Date: Thu, 27 Jun 2002 15:09:09 -0500 Subject: TAKE - remove unneeded locking implementation from dmapi To: linux-xfs@oss.sgi.com X-Spam-Status: No, hits=0.1 required=5.0 tests=SUBJ_REMOVE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Another one from Christoph Date: Thu Jun 27 13:09:16 PDT 2002 Workarea: mtv-vpn-sw-corp-0-56.corp.sgi.com:/home/lord/src/xfs-linux.2.4 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122496a linux/fs/xfs/support/sv.h - 1.8 linux/fs/xfs_dmapi/Makefile - 1.5 linux/fs/xfs_dmapi/sv.c - 1.2 linux/fs/xfs_dmapi/sv.h - 1.2 From owner-linux-xfs@oss.sgi.com Thu Jun 27 22:17:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5S5HcnC031291 for ; Thu, 27 Jun 2002 22:17:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5S5HcSp031290 for linux-xfs-outgoing; Thu, 27 Jun 2002 22:17:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mymail.canadawired.com (209-139-208-5.canadawired.com [209.139.208.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5S5HXnC031261 for ; Thu, 27 Jun 2002 22:17:33 -0700 Received: from alexa.myfakedomain.not (209-139-208-113.canadawired.com [209.139.208.113]) by mymail.canadawired.com (8.9.3/8.9.1) with ESMTP id WAA96850 for ; Thu, 27 Jun 2002 22:21:01 -0700 (PDT) (envelope-from rep@canadawired.com) Received: by alexa.myfakedomain.not (Postfix, from userid 1000) id 7B0704210D3; Thu, 27 Jun 2002 22:21:31 -0700 (PDT) Date: Thu, 27 Jun 2002 22:21:31 -0700 From: Ron Peterson To: linux-xfs@oss.sgi.com Subject: Re: 2.5-cvs and gcc-3.1 oops Message-ID: <20020628052131.GA1267@alexa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I tried changing the ffs call in xfs/pagebuf/page_buf_locking.c function pagebuf_target_blocksize to generic_ffs, and it seems to work. The result is running now. The two *ffs functions generate identical code with "gcc -S", so I'm hoping this kernel will be ok. If anyone thinks there will be a problem with this I'd appreciate hearing about it. Thanks, Ron From owner-linux-xfs@oss.sgi.com Thu Jun 27 23:02:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5S62enC031848 for ; Thu, 27 Jun 2002 23:02:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5S62edD031847 for linux-xfs-outgoing; Thu, 27 Jun 2002 23:02:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.190]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5S62TnC031815 for ; Thu, 27 Jun 2002 23:02:29 -0700 Received: (qmail 3021 invoked by uid 500); 28 Jun 2002 06:05:55 -0000 Subject: Re: Can you tell me how many downloads there have been of XFS? From: Austin Gonyou To: Rob Myers Cc: Laura Shepard , "'linux-xfs@oss.sgi.com'" , Eric Eppe In-Reply-To: <1025097549.3196.71.camel@ransom> References: <1025097549.3196.71.camel@ransom> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-FEGZfkX1BJhjKlrAgL1h" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 28 Jun 2002 01:05:55 -0500 Message-Id: <1025244355.2955.6.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.5 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-FEGZfkX1BJhjKlrAgL1h Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Sounds to me like the real question is the ISOs. How many people have downloaded the XFS ISO's. Knowing that is a good generalization of popularity, but that's about it.=20 On Wed, 2002-06-26 at 08:19, Rob Myers wrote: > On Tue, 2002-06-25 at 18:51, Laura Shepard wrote: > >=20 > > Hi there, > >=20 > > There is significant business planning interest in knowing our XFS > Linux > > installed base. > >=20 > > I have a method of inferring this from the number of downloads. >=20 > does this method account for those of us who keep local mirrors and > then > deploy on 100+ boxes? >=20 > what about now that xfs is in the aa tree? >=20 > good luck! ;) >=20 > rob. --=20 Austin Gonyou Coremetrics, Inc. --=-FEGZfkX1BJhjKlrAgL1h Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9G/zD94g6ZVmFMoIRAggZAKDYZJW3As5n9PMiuLyxb76JehBWZwCfRLAL voBUGHlY15sX4j8VuBXUZxo= =zyEe -----END PGP SIGNATURE----- --=-FEGZfkX1BJhjKlrAgL1h-- From owner-linux-xfs@oss.sgi.com Thu Jun 27 23:49:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5S6nFnC000922 for ; Thu, 27 Jun 2002 23:49:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5S6nFj9000921 for linux-xfs-outgoing; Thu, 27 Jun 2002 23:49:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5S6n8nC000882 for ; Thu, 27 Jun 2002 23:49:09 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.193]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g5S6qdR25087 for ; Fri, 28 Jun 2002 15:52:39 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g5S6qcr06800 for ; Fri, 28 Jun 2002 15:52:38 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (secsv2.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g5S6qZN25816 for ; Fri, 28 Jun 2002 15:52:36 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA529 for ; Fri, 28 Jun 2002 15:52:34 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Fri Jun 28 15:52:33 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g5S6qXA35544; Fri, 28 Jun 2002 15:52:33 +0900 (JST) Received: from NEC4D4BGTKMOBI (TNES017100.bsd.tnes.nec.co.jp [10.1.104.62]) by rifu.bsd.tnes.nec.co.jp (8.11.6/3.7W/BSD-TNES-MX01) with SMTP id g5S6qXY09406; Fri, 28 Jun 2002 15:52:33 +0900 Message-ID: <014201c21e70$611e47a0$3e68010a@bsd.tnes.nec.co.jp> From: "Hiroyuki Nakano" To: "Stephen Lord" Cc: Subject: Re: XFS force shutdown : EFSCORRUPTED Date: Fri, 28 Jun 2002 15:52:33 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Steve, I attempted to ascertain what this problem happened, as I read XFS source program. But I don't understand a thing. Can you see what happened ? Thanks. -nak > Hi Steve, > > I executed Shell-scrippt, as I changed lseek second argument value > to 4096*12, 4096*14, 4096*15, 4096*17, 4096*18, 4096*20 from 4096*16. > Shell-script was normal end. Only 4096*16(10000H) is a problem. > > Physical address 10000H-13fffH is inode chunk area on dev/hda7. > I think > Inode chunk area is in page buffers. Read function access to page > buffers. > If read function access to device, page buffers are broken. > > From owner-linux-xfs@oss.sgi.com Fri Jun 28 06:25:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5SDPLnC005117 for ; Fri, 28 Jun 2002 06:25:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5SDPLWq005116 for linux-xfs-outgoing; Fri, 28 Jun 2002 06:25:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5SDPCnC005088 for ; Fri, 28 Jun 2002 06:25:13 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA63685; Fri, 28 Jun 2002 08:28:42 -0500 (CDT) Received: from n236.ols.wavesec.net (cf-vpn-sw-corp-64-88.corp.sgi.com [134.15.64.88]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA19879; Fri, 28 Jun 2002 08:28:37 -0500 (CDT) Subject: Re: XFS force shutdown : EFSCORRUPTED From: Stephen Lord To: Hiroyuki Nakano Cc: linux-xfs@oss.sgi.com In-Reply-To: <014201c21e70$611e47a0$3e68010a@bsd.tnes.nec.co.jp> References: <014201c21e70$611e47a0$3e68010a@bsd.tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 28 Jun 2002 08:27:27 -0500 Message-Id: <1025270852.1090.4.camel@n236> Mime-Version: 1.0 X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-06-28 at 01:52, Hiroyuki Nakano wrote: > Hi Steve, > > I attempted to ascertain what this problem happened, as I read > XFS source program. But I don't understand a thing. Can you > see what happened ? I happened to be sitting next to another filesystem developer when I read this, and he remembered an old ext2 race condition. I think I understand what is happening - and how to fix it, the only problem is that fixing it will potentially be a major performance issue - so the question is, why do you need this to work? Would a solution which disallowed block access to the device when it was mounted be sufficient, or do you really want to look at metadata live via the block device. The xfsdump program does not need this, the only thing which does is running xfs_db on a live filesystem, but that is not really of use to anyone but developers. Steve > > Thanks. > > -nak > > > > Hi Steve, > > > > I executed Shell-scrippt, as I changed lseek second argument value > > to 4096*12, 4096*14, 4096*15, 4096*17, 4096*18, 4096*20 from 4096*16. > > Shell-script was normal end. Only 4096*16(10000H) is a problem. > > > > Physical address 10000H-13fffH is inode chunk area on dev/hda7. > > I think > > Inode chunk area is in page buffers. Read function access to page > > buffers. > > If read function access to device, page buffers are broken. > > > > From owner-linux-xfs@oss.sgi.com Fri Jun 28 08:20:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5SFKsnC008379 for ; Fri, 28 Jun 2002 08:20:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5SFKrZY008378 for linux-xfs-outgoing; Fri, 28 Jun 2002 08:20:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from 217.7.147.131 ([217.7.147.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5SFKjnC008350 for ; Fri, 28 Jun 2002 08:20:47 -0700 Message-Id: <200206281520.g5SFKjnC008350@oss.sgi.com> From: Alina To: Undisclosed.Recipients@oss.sgi.com Cc: Subject: Re: Alina Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 28 Jun 2002 17:24:33 +0200 X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-Spam-Status: No, hits=3.4 required=5.0 tests=FAKED_UNDISC_RECIPS version=2.20 X-Spam-Level: *** Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Und wie gesagt.. Für Dich habe ich immer Zeit :-) Küsschen Alina PS: Lass uns doch wieder chatten?! http://alina-privat.dd.vu From owner-linux-xfs@oss.sgi.com Fri Jun 28 10:45:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5SHjNnC012987 for ; Fri, 28 Jun 2002 10:45:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5SHjNfU012986 for linux-xfs-outgoing; Fri, 28 Jun 2002 10:45:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5SHjHnC012958 for ; Fri, 28 Jun 2002 10:45:18 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e185.americas.sgi.com [128.162.185.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA66548 for ; Fri, 28 Jun 2002 12:48:50 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id MAA00115 for ; Fri, 28 Jun 2002 12:48:50 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g5SHmWh29678; Fri, 28 Jun 2002 12:48:32 -0500 Message-Id: <200206281748.g5SHmWh29678@stout.americas.sgi.com> Date: Fri, 28 Jun 2002 12:48:32 -0500 Subject: TAKE - fix root access() and non-executables X-Spam-Status: No, hits=0.9 required=5.0 tests=MISSING_HEADERS version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk "access -x foo" or bash [ -x foo ] was giving false positives for root; i.e. a file with no executable bits set was reporting as executable to the access() call. This change ensures that at least 1 executable bit is set before letting root execute it. Also a couple minor cosmetic cleanups in xfs_iaccess(). Date: Fri Jun 28 10:44:54 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122557a linux/fs/xfs/xfs_inode.c - 1.342 - Don't let CAP_DAC_OVERRIDE override if no execute bits are set other minor cleanup in xfs_iaccess() From owner-linux-xfs@oss.sgi.com Fri Jun 28 10:58:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5SHwunC013265 for ; Fri, 28 Jun 2002 10:58:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5SHwuRk013264 for linux-xfs-outgoing; Fri, 28 Jun 2002 10:58:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from CoNetUX (IDENT:Q0sK+nGXCqgSoBjZ/mgRPJVuigjqXKhe@firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5SHvinC013228 for ; Fri, 28 Jun 2002 10:57:45 -0700 Received: from conet.cz (Libor [192.168.1.130]) by CoNetUX (8.11.6/8.11.6) with ESMTP id g5SI15E29943; Fri, 28 Jun 2002 20:01:05 +0200 Message-ID: <3D1CA432.9030904@conet.cz> Date: Fri, 28 Jun 2002 20:00:18 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Lord CC: linux-xfs@oss.sgi.com Subject: Re: XFS corruption! References: <3D1AAB70.4060400@conet.cz> <1025187574.1622.5.camel@n236> Content-Type: multipart/mixed; boundary="------------050607040907070506080900" X-Spam-Status: No, hits=0.5 required=5.0 tests=PLING version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------050607040907070506080900 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit > > >Can you please run xfs_check on the filesystem after this has happened. >I suspect you may have found a hole in the endian conversion code in >XFS. Doing the copy into the filesystem over NFS is probably >generating more fragmentation and hence more complex free space >structures than doing it locally. > >Steve > > > Hi, I attach the output of xfs_check. The filesystem is fragmented a lot - there is lot quite big (300-500 MB) files and many many office/CAD documents with few MB each. If you want I can do some more tests but only till sunday morning - then I have to format it to ext3 :-( Thanks, Libor --------------050607040907070506080900 Content-Type: application/x-zip-compressed; name="log.zip" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="log.zip" UEsDBBQAAAAIAO6e3Cz39naU6VcAAABXBwADAAAAbG9nzN1PrxxXeh/gfT7F BbKJgSDu99+pagNZZBPDGy+SRbILRA1nLMwMZYw0tufb55JDXsq6rOruJ4tc Lbvqd5s878NT5wdJxXff/ebpu9/99umP3/3uh++f/uPT5emHD88fPF3+w7vP V/7l/Z9++uHHD//+2h9+/P73T5e/vTy9/7d/fv/9z+9/8/TzX/75/dOfP/z+ w4//+uHpdz/+/PTTu88/4oevP/zf+vJ+u9SvvuOHX37H8y0d37+/bP/upq8/ YfZeU50fL7/7+d2HH59efjGnd37/4ee77vzhw4/vfnnn803/5/sf//yc7ohe l9lz+89Pnz55/l1/XZKP9/32T+/f//XeqpnuyoM7nxfqDz98+P3zx+/+/P3v 3//88epPz19w7br0lxuf/tPzr+U37//r54//5pvB+Bi8/Dpy+fbN+fHm2J9X eDov8+vU1yvfjtfH+HXL/dfBj599O9KfvrEve2yZ+6vg1yvfjs+n+Nq2LWO9 Cn/+/NvR9TFa/fzT51Lr1e/165Vvx7eP8Xm+p/dXq/v5428H90cGcvXfX1we +aKIz6Ofvtb2+qu+XDhIf4KT0VvvtfrVGL9eOch/krO2uOz7euX7y+cH2U+E vvx5ejXGz58fZP8f/MRfAUVt15iVrxb665WD/PbXP9L75SPxV1/+cuEg/YlR 7te8xPQWr1b85cpB/q+ycs1sE/Uq//XKwU7xkK58bBfKh+6uh+7uh+6eh+5e D929PXT3Q9tGXh+5ux6aZT00y3polvXQLOuhWdZDs6yHZlkPzbIemmU9NMt+ aJb90Cz7oVn2Q7Psh2bZD82yP80yns9vsX3jcPJy4SD90Gz7odn2Q7Odh2Y7 D812HprtPDTbeWi289Bs56E/p/PQLOehWc5Ds1wPzXI9NMv10CzX4Sw/dqCf 3v2iBtXl0z+fb40vN7wugPFSDn9dG+OkNsbrPvjqylHq/2v/+3Zbe/kF3nme hExCpiDTkBnILMhskNkhc5WZEgSREEIhxEIIhhANIRxCPISACBGRIiJpbxAR KSJSRKSISBGRIiJFRIqIEhElIooeFyKiRESJiBIRJSJKRJSIaBHRIqJFRNMJ QkS0iGgR0SKiRUSLiBERIyJGRIyIGDpUiogRESMiRkSMiFgiYomIJSLWLRE3 umUed8s87JZ50i3zsFvmSbfMt94t885/zwGZhExBpiEzkFmQ2SCzQ+YqMyUI IiGEQoiFEAwhGkI4hHgIAREiIkVE0t4gIlJEpIhIEZEiIkVEiogUESUiSkQU PS5ERImIEhElIkpElIgoEdEiokVEi4imE4SIaBHRIqJFRIuIFhEjIkZEjIgY ETF0qBQRIyJGRIyIGBGxRMQSEUtErFsibnTLOu6Wddgt66Rb1mG3rJNuWW+9 W9aXlZ1LVRz/t3uQScgUZBoyA5kFmQ0yO2SuMlOCIBJCKIRYCMEQoiGEQ4iH EBAhIlJEJO0NIiJFRIqIFBEpIlJEpIhIEVEiokRE0eNCRJSIKBFRIqJERImI EhEtIlpEtIhoOkGIiBYRLSJaRLSIaBExImJExIiIERFDh0oRMSJiRMSIiBER S0QsEbFExLol4ka37ONu2Yfdsk+6ZR92yz7plv3Wu2V/Wdkb/28XZBIyBZmG zEBmQWaDzA6Zq8yUIIiEEAohFkIwhGgI4RDiIQREiIgUEUl7g4hIEZEiIkVE iogUESkiUkSUiCgRUfS4EBElIkpElIgoEVEiokREi4gWES0imk4QIqJFRIuI FhEtIlpEjIgYETEiYkTE0KFSRIyIGBExImJExBIRS0QsEbFuibjRLee4W85h t5yTbjmH3XJOuuW89W45X1Z2r+d1vRy9hyUgk5ApyDRkBjILMhtkdshcZaYE QSSEUAixEIIhREMIhxAPISBCRKSISNobRESKiBQRKSJSRKSISBGRIqJERImI oseFiCgRUSKiRESJiBIRJSJaRLSIaBHRdIIQES0iWkS0iGgR0SJiRMSIiBER IyKGDpUiYkTEiIgRESMilohYImKJiHVLxP/6b//jH//hH//+755+/qfnG//4 3V+e3r1/+u7pw/t/ff+np//93//n029/+MP7n/7y08/v//hfbhXRdVxE12ER XSdFdB0W0XVSRNdbL6Lryxjiclmr8nrPm3/uDaWESkItoZHQktAmoV1CVxqu kSATQSiCVASxCHIRBCNIRhCNIBtJNtL2C7KRZCPJRpKNJBtJNpJsJNkoslFk o+xhQjaKbBTZKLJRZKPIRpGNJhtNNppstJ00yEaTjSYbTTaabDTZGLIxZGPI xpCNsWMo2RiyMWRjyMaQjUU2FtlYZGPdtHGjm27H3XQ77KbbSTfdDrvpdtJN t7feTbeXpY2t+zJxz5uD7g2lhEpCLaGR0JLQJqFdQlcarpEgE0EoglQEsQhy EQQjSEYQjSAbSTbS9guykWQjyUaSjSQbSTaSbCTZKLJRZKPsYUI2imwU2Siy UWSjyEaRjSYbTTaabLSdNMhGk40mG002mmw02RiyMWRjyMaQjbFjKNkYsjFk Y8jGkI1FNhbZWGRj3bRxo5vux910P+ym+0k33Q+76X7STfe33k33l6U9/5uZ QkIpoZJQS2gktCS0SWiX0JWGayTIRBCKIBVBLIJcBMEIkhFEI8hGko20/YJs JNlIspFkI8lGko0kG0k2imwU2Sh7mJCNIhtFNopsFNkoslFko8lGk40mG20n DbLRZKPJRpONJhtNNoZsDNkYsjFkY+wYSjaGbAzZGLIxZGORjUU2FtlYN23c 6KbX4256Peym15Nuej3spteTbnp96930+rK0c7le+9r3vLno3lBKqCTUEhoJ LQltEtoldKXhGgkyEYQiSEUQiyAXQTCCZATRCLKRZCNtvyAbSTaSbCTZSLKR ZCPJRpKNIhtFNsoeJmSjyEaRjSIbRTaKbBTZaLLRZKPJRttJg2w02Wiy0WSj yUaTjSEbQzaGbAzZGDuGko0hG0M2hmwM2VhkY5GNRTbWTRs3umlcjsvp52vf aqe/uHSSe91Pf3HpMPeGG+pzOfmywp//ttV7XoB0dyopVZRqSg2lFqU2Su2U utqUEYfpCOMR5iMMSJiQMCJhRsKQhClJU5K4h5iSNCVpStKUpClJU5KmJE1J mZIyJYWPGlNSpqRMSZmSMiVlSsqUtClpU9KmpPFEYkralLQpaVPSpqRNyZiS MSVjSsaUDB5cTcmYkjElY0rGlCxTskzJMiXrtpJbDTdOGm4cN9w4a7hx3HDj rOHGm2+48bLCe09fa7vnxUp3p5JSRamm1FBqUWqj1E6pq00ZcZiOMB5hPsKA hAkJIxJmJAxJmJI0JYl7iClJU5KmJE1JmpI0JWlK0pSUKSlTUvioMSVlSsqU lCkpU1KmpExJm5I2JW1KGk8kpqRNSZuSNiVtStqUjCkZUzKmZEzJ4MHVlIwp GVMypmRMyTIly5QsU7JuK7nVcPOk4eZxw82zhpvHDTfPGm6++YabX1Y4L1G5 5nrP65nuTiWlilJNqaHUotRGqZ1SV5sy4jAdYTzCfIQBCRMSRiTMSBiSMCVp ShL3EFOSpiRNSZqSNCVpStKUpCkpU1KmpPBRY0rKlJQpKVNSpqRMSZmSNiVt StqUNJ5ITEmbkjYlbUralLQpGVMypmRMyZiSwYOrKRlTMqZkTMmYkmVKlilZ pmTdVnKr4dZJw63jhltnDbeOG26dNdx68w23XlY49rjUfrnnJU93p5JSRamm 1FBqUWqj1E6pq00ZcZiOMB5hPsKAhAkJIxJmJAxJmJI0JYl7iClJU5KmJE1J mpI0JWlK0pSUKSlTUvioMSVlSsqUlCkpU1KmpExJm5I2JW1KGk8kpqRNSZuS NiVtStqUjCkZUzKmZEzJ4MHVlIwpGVMypmRMyTIly5QsU7JuK7nVcPuk4fZx w+2zhtvHDbfPGm6/+YbbLytcvT+vcd7zqqi7U0mpolRTaii1KLVRaqfU1aaM OExHGI8wH2FAwoSEEQkzEoYkTEmaksQ9xJSkKUlTkqYkTUmakjQlaUrKlJQp KXzUmJIyJWVKypSUKSlTUqakTUmbkjYljScSU9KmpE1Jm5I2JW1KxpSMKRlT MqZk8OBqSsaUjCkZUzKmZJmSZUqWKVm3ldxquHPScOe44c5Zw53jhjtnDXfe fMOdlxWeWLNn3/WmqXtTSamiVFNqKLUotVFqp9TVpow4TEcYjzAfYUDChIQR CTMShiRMSZqSxD3ElKQpSVOSpiRNSZqSNCVpSsqUlCkpfNSYkjIlZUrKlJQp KVNSpqRNSZuSNiWNJxJT0qakTUmbkjYlbUrGlIwpGVMypmTw4GpKxpSMKRlT MqZkmZJlSpYpWbeV3Gq466ThruOGu84a7jpuuOus4a4333DXywqvvWt67nrT 1L2ppFRRqik1lFqU2ii1U+pqU0YcpiOMR5iPMCBhQsKIhBkJQxKmJE1J4h5i StKUpClJU5KmJE1JmpI0JWVKypQUPmpMSZmSMiVlSsqUlCkpU9KmpE1Jm5LG E4kpaVPSpqRNSZuSNiVjSsaUjCkZUzJ4cDUlY0rGlIwpGVOyTMkyJcuUrNtK bjXc7aThbscNdztruNtxw93OGu725hvu9rLC+2Tk2u5609S9qaRUUaopNZRa lNootVPqalNGHKYjjEeYjzAgYULCiIQZCUMSpiRNSeIeYkrSlKQpSVOSpiRN SZqSNCVlSsqUFD5qTEmZkjIlZUrKlJQpKVPSpqRNSZuSxhOJKWlT0qakTUmb kjYlY0rGlIwpGVMyeHA1JWNKxpSMKRlTskzJMiXLlKzbSm413P2k4e7HDXc/ a7j7ccPdzxru/uYb7v5lhesS1/2673e9aereVFKqKNWUGkotSm2U2il1tSkj DtMRxiPMRxiQMCFhRMKMhCEJU5KmJHEPMSVpStKUpClJU5KmJE1JmpIyJWVK Ch81pqRMSZmSMiVlSsqUlClpU9KmpE1J44nElLQpaVPSpqRNSZuSMSVjSsaU jCkZPLiakjElY0rGlIwpWaZkmZJlStZtJbca7vWk4V6PG+71rOFejxvu9azh Xt98w72+rHDs29rictebpu5NJaWKUk2podSi1EapnVJXmzLiMB1hPMJ8hAEJ ExJGJMxIGJIwJWlKEvcQU5KmJE1JmpI0JWlK0pSkKSlTUqak8FFjSsqUlCkp U1KmpExJmZI2JW1K2pQ0nkhMSZuSNiVtStqUtCkZUzKmZEzJmJLBg6spGVMy pmRMyZiSZUqWKVmmZN1WcqPh5uW44X6+9q2G+4tLJ7nXDfcXlw5zb7jhPh9W v6xwzXRX3vOmqbtTSamiVFNqKLUotVFqp9TVpow4TEcYjzAfYUDChIQRCTMS hiRMSZqSxD3ElKQpSVOSpiRNSZqSNCVpSsqUlCkpfNSYkjIlZUrKlJQpKVNS pqRNSZuSNiWNJxJT0qakTUmbkjYlbUrGlIwpGVMypmTw4GpKxpSMKRlTMqZk mZJlSpYpWbeV3Gq4cdJw47jhxlnDjeOGG2cNN958w42XFZ6sjKl73jR1dyop VZRqSg2lFqU2Su2UutqUEYfpCOMR5iMMSJiQMCJhRsKQhClJU5K4h5iSNCVp StKUpClJU5KmJE1JmZIyJYWPGlNSpqRMSZmSMiVlSsqUtClpU9KmpPFEYkra lLQpaVPSpqRNyZiSMSVjSsaUDB5cTcmYkjElY0rGlCxTskzJMiXrtpJbDTdP Gm4eN9w8a7h53HDzrOHmm2+4+bLC63q57tvc86apu1NJqaJUU2ootSi1UWqn 1NWmjDhMRxiPMB9hQMKEhBEJMxKGJExJmpLEPcSUpClJU5KmJE1JmpI0JWlK ypSUKSl81JiSMiVlSsqUlCkpU1KmpE1Jm5I2JY0nElPSpqRNSZuSNiVtSsaU jCkZUzKmZPDgakrGlIwpGVMypmSZkmVKlilZt5Xcarh10nDruOHWWcOt44Zb Zw233nzDrZcV3ud5fa/rnjdN3Z1KShWlmlJDqUWpjVI7pa42ZcRhOsJ4hPkI AxImJIxImJEwJGFK0pQk7iGmJE1JmpI0JWlK0pSkKUlTUqakTEnho8aUlCkp U1KmpExJmZIyJW1K2pS0KWk8kZiSNiVtStqUtClpUzKmZEzJmJIxJYMHV1My pmRMyZiSMSXLlCxTskzJuq3kVsPtk4bbxw23zxpuHzfcPmu4/eYbbn9Z4b7k 84+J/Z43Td2dSkoVpZpSQ6lFqY1SO6WuNmXEYTrCeIT5CAMSJiSMSJiRMCRh StKUJO4hpiRNSZqSNCVpStKUpClJU1KmpExJ4aPGlJQpKVNSpqRMSZmSMiVt StqUtClpPJGYkjYlbUralLQpaVMypmRMyZiSMSWDB1dTMqZkTMmYkjEly5Qs U7JMybqt5FbDnZOGO8cNd84a7hw33DlruPPmG+68rHBcuy59uetNU/emklJF qabUUGpRaqPUTqmrTRlxmI4wHmE+woCECQkjEmYkDEmYkjQliXuIKUlTkqYk TUmakjQlaUrSlJQpKVNS+KgxJWVKypSUKSlTUqakTEmbkjYlbUoaTySmpE1J m5I2JW1K2pSMKRlTMqZkTMngwdWUjCkZUzKmZEzJMiXLlCxTsm4rudVw10nD XccNd5013HXccNdZw11vvuGulxWulZdtxV1vmro3lZQqSjWlhlKLUhuldkpd bcqIw3SE8QjzEQYkTEgYkTAjYUjClKQpSdxDTEmakjQlaUrSlKQpSVOSpqRM SZmSwkeNKSlTUqakTEn93+buJUdyZMu24JRcz0dJzn9iLx9wKyKhdY12Slre NixHgBSQujsMU5KmJE1JmZIyJWVKCk8kpqRMSZmSMiVlSsqUtClpU9KmpE1J 48HVlLQpaVPSpqRNyTYl25RsU7K/K/m2cK+XhXt9XrjX28K9Pi/c623hXr9+ 4V5/rnDHc9edoy9NTaugKqkqqpqqTdVF1U3VY3cZcZiOZTyW+VgGZJmQZUSW GVmGZJmSMCWBzxBTEqYkTEmYkjAlYUrClIQpSVOSpiTxVWNK0pSkKUlTkqYk TUmakjIlZUrKlBSeSExJmZIyJWVKypSUKWlT0qakTUmbksaDqylpU9KmpE1J m5JtSrYp2aZkf1fybeHeLwv3/rxw77eFe39euPfbwr1//cK9/1zh/Vw7fmr0 palpFVQlVUVVU7Wpuqi6qXrsLiMO07GMxzIfy4AsE7KMyDIjy5AsUxKmJPAZ YkrClIQpCVMSpiRMSZiSMCVpStKUJL5qTEmakjQlaUrSlKQpSVNSpqRMSZmS whOJKSlTUqakTEmZkjIlbUralLQpaVPSeHA1JW1K2pS0KWlTsk3JNiXblOzv Sr4t3Odl4T6fF+7ztnCfzwv3eVu4z69fuM+fK3z/81ee2KMvTU2roCqpKqqa qk3VRdVN1WN3GXGYjmU8lvlYBmSZkGVElhlZhmSZkjAlgc8QUxKmJExJmJIw JWFKwpSEKUlTkqYk8VVjStKUpClJU5KmJE1JmpIyJWVKypQUnkhMSZmSMiVl SsqUlClpU9KmpE1Jm5LGg6spaVPSpqRNSZuSbUq2KdmmZH9X8mXh5s/nhfuf 3/7bwv3XTy/d/164//rpY/eLF+4/x5D/XOH+yVy77smXpsZVUJVUFVVN1abq ouqm6rG7jDhMxzIey3wsA7JMyDIiy4wsQ7JMSZiSwGeIKQlTEqYkTEmYkjAl YUrClKQpSVOS+KoxJWlK0pSkKUlTkqYkTUmZkjIlZUoKTySmpExJmZIyJWVK ypS0KWlT0qakTUnjwdWUtClpU9KmpE3JNiXblGxTsr8r+bZw18vCXZ8X7npb uOvzwl1vC3f9+oW7/lzh+Pl5cj+TL02Nq6AqqSqqmqpN1UXVTdVjdxlxmI5l PJb5WAZkmZBlRJYZWYZkmZIwJYHPEFMSpiRMSZiSMCVhSsKUhClJU5KmJPFV Y0rSlKQpSVOSpiRNSZqSMiVlSsqUFJ5ITEmZkjIlZUrKlJQpaVPSpqRNSZuS xoOrKWlT0qakTUmbkm1KtinZpmR/V/Jt4cbLwo3PCzfeFm58XrjxtnDj1y/c +HOFc9/Xz7MmX5oaV0FVUlVUNVWbqouqm6rH7jLiMB3LeCzzsQzIMiHLiCwz sgzJMiVhSgKfIaYkTEmYkjAlYUrClIQpCVOSpiRNSeKrxpSkKUlTkqYkTUma kjQlZUrKlJQpKTyRmJIyJWVKypSUKSlT0qakTUmbkjYljQdXU9KmpE1Jm5I2 JduUbFOyTcn+ruTbws2XhZufF26+Ldz8vHDzbeHmr1+4+ecK/3OJ614x+dLU uAqqkqqiqqnaVF1U3VQ9dpcRh+lYxmOZj2VAlglZRmSZkWVIlikJUxL4DDEl YUrClIQpCVMSpiRMSZiSNCVpShJfNaYkTUmakjQlaUrSlKQpKVNSpqRMSeGJ xJSUKSlTUqakTEmZkjYlbUralLQpaTy4mpI2JW1K2pS0KdmmZJuSbUr2dyXf Fm69LNz6vHDrbeHW54Vbbwu3fv3CrT9X+Pqp+OfvTL40Na6CqqSqqGqqNlUX VTdVj91lxGE6lvFY5mMZkGVClhFZZmQZkmVKwpQEPkNMSZiSMCVhSsKUhCkJ UxKmJE1JmpLEV40pSVOSpiRNSZqSNCVpSsqUlCkpU1J4IjElZUrKlJQpKVNS pqRNSZuSNiVtShoPrqakTUmbkjYlbUq2KdmmZJuS/V3Jt4XbLwu3Py/cflu4 /Xnh9tvC7V+/cPvPFb6v+Ineoy9NTaugKqkqqpqqTdVF1U3VY3cZcZiOZTyW +VgGZJmQZUSWGVmGZJmSMCWBzxBTEqYkTEmYkjAlYUrClIQpSVOSpiTxVWNK 0pSkKUlTkqYkTUmakjIlZUrKlBSeSExJmZIyJWVKypSUKWlT0qakTUmbksaD qylpU9KmpE1Jm5JtSrYp2aZkf1fybeHul4W7Py/c/bZw9+eFu98W7v71C3f/ zxXeP/lcz3WNvjQ1rYKqpKqoaqo2VRdVN1WP3WXEYTqW8VjmYxmQZUKWEVlm ZBmSZUrClAQ+Q0xJmJIwJWFKwpSEKQlTEqYkTUmaksRXjSlJU5KmJE1JmpI0 JWlKypSUKSlTUngiMSVlSsqUlCkpU1KmpE1Jm5I2JW1KGg+upqRNSZuSNiVt SrYp2aZkm5L9Xcm3hXu9LNzr88K93hbu9XnhXm8L9/r1C/f6c4Xj5+r9PKMv TU2roCqpKqqaqk3VRdVN1WN3GXGYjmU8lvlYBmSZkGVElhlZhmSZkjAlgc8Q UxKmJExJmJIwJWFKwpSEKUlTkqYk8VVjStKUpClJU5KmJE1JmpIyJWVKypQU nkhMSZmSMiVlSsqUlClpU9KmpE1Jm5LGg6spaVPSpqRNSZuSbUq2KdmmZH9X 8m3h3i8L9/68cO+3hXt/Xrj328K9f/3Cvf9c4bz+/1/5GX1paloFVUlVUdVU baouqm6qHrvLiMN0LOOxzMcyIMuELCOyzMgyJMuUhCkJfIaYkjAlYUrClIQp CVMSpiRMSZqSNCWJrxpTkqYkTUmakjQlaUrSlJQpKVNSpqTwRGJKypSUKSlT UqakTEmbkjYlbUralDQeXE1Jm5I2JW1K2pRsU7JNyTYl+7uSbwv3eVm4z+eF +7wt3Ofzwn3eFu7z6xfu8+cKd+VaFaMvTU2roCqpKqqaqk3VRdVN1WN3GXGY jmU8lvlYBmSZkGVElhlZhmSZkjAlgc8QUxKmJExJmJIwJWFKwpSEKUlTkqYk 8VVjStKUpClJU5KmJE1JmpIyJWVKypQUnkhMSZmSMiVlSsqUlClpU9KmpE1J m5LGg6spaVPSpqRNSZuSbUq2KdmmZH9X8mXh1s/nhfuf3/7bwv3XTy/d/164 //rpY/eLF+4/L5j/ucLX+rnvXZMvTY2roCqpKqqaqk3VRdVN1WN3GXGYjmU8 lvlYBmSZkGVElhlZhmSZkjAlgc8QUxKmJExJmJIwJWFKwpSEKUlTkqYk8VVj StKUpClJU5KmJE1JmpIyJWVKypQUnkhMSZmSMiVlSsqUlClpU9KmpE1Jm5LG g6spaVPSpqRNSZuSbUq2KdmmZH9X8m3hrpeFuz4v3PW2cNfnhbveFu769Qt3 /bnC93XvvnvypalxFVQlVUVVU7Wpuqi6qXrsLiMO07GMxzIfy4AsE7KMyDIj y5AsUxKmJPAZYkrClIQpCVMSpiRMSZiSMCVpStKUJL5qTEmakjQlaUrSlKQp SVNSpqRMSZmSwhOJKSlTUqakTEmZkjIlbUralLQpaVPSeHA1JW1K2pS0KWlT sk3JNiXblOzvSr4t3HhZuPF54cbbwo3PCzfeFm78+oUb/3OFr5/alT/X5EtT 4yqoSqqKqqZqU3VRdVP12F1GHKZjGY9lPpYBWSZkGZFlRpYhWaYkTEngM8SU hCkJUxKmJExJmJIwJWFK0pSkKUl81ZiSNCVpStKUpClJU5KmpExJmZIyJYUn ElNSpqRMSZmSMiVlStqUtClpU9KmpPHgakralLQpaVPSpmSbkm1KtinZ35V8 W7j5snDz88LNt4Wbnxduvi3c/PULN/9c4VgVP3FPvjQ1roKqpKqoaqo2VRdV N1WP3WXEYTqW8VjmYxmQZUKWEVlmZBmSZUrClAQ+Q0xJmJIwJWFKwpSEKQlT EqYkTUmaksRXjSlJU5KmJE1JmpI0JWlKypSUKSlTUngiMSVlSsqUlCkpU1Km pE1Jm5I2JW1KGg+upqRNSZuSNiVtSrYp2aZkm5L9Xcm3hVsvC7c+L9x6W7j1 eeHW28KtX79w688Vzns9V/9MvjQ1roKqpKqoaqo2VRdVN1WP3WXEYTqW8Vjm YxmQZUKWEVlmZBmSZUrClAQ+Q0xJmJIwJWFKwpSEKQlTEqYkTUmaksRXjSlJ U5KmJE1JmpI0JWlKypSUKSlTUngiMSVlSsqUlCkpU1KmpE1Jm5I2JW1KGg+u pqRNSZuSNiVtSrYp2aZkm5L9Xcm3hdsvC7c/L9x+W7j9eeH228LtX79w+88V 7nquumL0palpFVQlVUVVU7Wpuqi6qXrsLiMO07GMxzIfy4AsE7KMyDIjy5As UxKmJPAZYkrClIQpCVMSpiRMSZiSMCVpStKUJL5qTEmakjQlaUrSlKQpSVNS pqRMSZmSwhOJKSlTUqakTEmZkjIlbUralLQpaVPSeHA1JW1K2pS0KWlTsk3J NiXblOzvSr4t3P2ycPfnhbvfFu7+vHD328Ldv37h7j9X+FpXrydHX5qaVkFV UlVUNVWbqouqm6rH7jLiMB3LeCzzsQzIMiHLiCwzsgzJMiVhSgKfIaYkTEmY kjAlYUrClIQpCVOSpiRNSeKrxpSkKUlTkqYkTUmakjQlZUrKlJQpKTyRmJIy JWVKypSUKSlT0qakTUmbkjYljQdXU9KmpE1Jm5I2JduUbFOyTcn+ruTbwr1e Fu71eeFebwv3+rxwr7eFe/36hXv9ucL33fGsHn1paloFVUlVUdVUbaouqm6q HrvLiMN0LOOxzMcyIMuELCOyzMgyJMuUhCkJfIaYkjAlYUrClIQpCVMSpiRM SZqSNCWJrxpTkqYkTUmakjQlaUrSlJQpKVNSpqTwRGJKypSUKSlTUqakTEmb kjYlbUralDQeXE1Jm5I2JW1K2pRsU7JNyTYl+7uSbwv3flm49+eFe78t3Pvz wr3fFu796xfu/T9X+P7p/Nm5R1+amlZBVVJVVDVVm6qLqpuqx+4y4jAdy3gs 87EMyDIhy4gsM7IMyTIlYUoCnyGmJExJmJIwJWFKwpSEKQlTkqYkTUniq8aU pClJU5KmJE1JmpI0JWVKypSUKSk8kZiSMiVlSsqUlCkpU9KmpE1Jm5I2JY0H V1PSpqRNSZuSNiXblGxTsk3J/q7k28J9Xhbu83nhPm8L9/m8cJ+3hfv8+oX7 /LnCET93/vPHJgt3WgVVSVVR1VRtqi6qbqoeu8uIw3Qs47HMxzIgy4QsI7LM yDIky5SEKQl8hpiSMCVhSsKUhCkJUxKmJExJmpI0JYmvGlOSpiRNSZqSNCVp StKUlCkpU1KmpPBEYkrKlJQpKVNSpqRMSZuSNiVtStqUNB5cTUmbkjYlbUra lGxTsk3JNiX7u5IvC7d/Pi/c//z23xbuv3566f73wv3XTx+7X7xw/3l0/M8V zvveP/fP5EtT4yqoSqqKqqZqU3VRdVP12F1GHKZjGY9lPpYBWSZkGZFlRpYh WaYkTEngM8SUhCkJUxKmJExJmJIwJWFK0pSkKUl81ZiSNCVpStKUpClJU5Km pExJmZIyJYUnElNSpqRMSZmSMiVlStqUtClpU9KmpPHgakralLQpaVPSpmSb km1KtinZ35V8W7jrZeGuzwt3vS3c9XnhrreFu379wl1/rnD3zvtnTb40Na6C qqSqqGqqNlUXVTdVj91lxGE6lvFY5mMZkGVClhFZZmQZkmVKwpQEPkNMSZiS MCVhSsKUhCkJUxKmJE1JmpLEV40pSVOSpiRNSZqSNCVpSsqUlCkpU1J4IjEl ZUrKlJQpKVNSpqRNSZuSNiVtShoPrqakTUmbkjYlbUq2KdmmZJuS/V3Jt4Ub Lws3Pi/ceFu48XnhxtvCjV+/cOPPFb6iVkdOvjQ1roKqpKqoaqo2VRdVN1WP 3WXEYTqW8VjmYxmQZUKWEVlmZBmSZUrClAQ+Q0xJmJIwJWFKwpSEKQlTEqYk TUmaksRXjSlJU5KmJE1JmpI0JWlKypSUKSlTUngiMSVlSsqUlCkpU1KmpE1J m5I2JW1KGg+upqRNSZuSNiVtSrYp2aZkm5L9Xcm3hZsvCzc/L9x8W7j5eeHm 28LNX79w888Vvp/1RNXkS1PjKqhKqoqqpmpTdVF1U/XYXUYcpmMZj2U+lgFZ JmQZkWVGliFZpiRMSeAzxJSEKQlTEqYkTEmYkjAlYUrSlKQpSXzVmJI0JWlK 0pSkKUlTkqakTEmZkjIlhScSU1KmpExJmZIyJWVK2pS0KWlT0qak8eBqStqU tClpU9KmZJuSbUq2KdnflXxbuPWycOvzwq23hVufF269Ldz69Qu3/ucKPz/9 7GfvyZemxlVQlVQVVU3Vpuqi6qbqsbuMOEzHMh7LfCwDskzIMiLLjCxDskxJ mJLAZ4gpCVMSpiRMSZiSMCVhSsKUpClJU5L4qjElaUrSlKQpSVOSpiRNSZmS MiVlSgpPJKakTEmZkjIlZUrKlLQpaVPSpqRNSePB1ZS0KWlT0qakTck2JduU bFOyvyv5tnD7ZeH254Xbbwu3Py/cflu4/esXbv+5whFX7fsefWlqWgVVSVVR 1VRtqi6qbqoeu8uIw3Qs47HMxzIgy4QsI7LMyDIky5SEKQl8hpiSMCVhSsKU hCkJUxKmJExJmpI0JYmvGlOSpiRNSZqSNCVpStKUlCkpU1KmpPBEYkrKlJQp KVNSpqRMSZuSNiVtStqUNB5cTUmbkjYlbUralGxTsk3JNiX7u5JvC3e/LNz9 eeHut4W7Py/c/bZw969fuPvPFc6no36e0ZemplVQlVQVVU3Vpuqi6qbqsbuM OEzHMh7LfCwDskzIMiLLjCxDskxJmJLAZ4gpCVMSpiRMSZiSMCVhSsKUpClJ U5L4qjElaUrSlKQpSVOSpiRNSZmSMiVlSgpPJKakTEmZkjIlZUrKlLQpaVPS pqRNSePB1ZS0KWlT0qakTck2JduUbFOyvyv5tnCvl4V7fV6419vCvT4v3Ott 4V6/fuFef65w7/xZuUZfmppWQVVSVVQ1VZuqi6qbqsfuMuIwHct4LPOxDMgy IcuILDOyDMkyJWFKAp8hpiRMSZiSMCVhSsKUhCkJU5KmJE1J4qvGlKQpSVOS piRNSZqSNCVlSsqUlCkpPJGYkjIlZUrKlJQpKVPSpqRNSZuSNiWNB1dT0qak TUmbkjYl25RsU7JNyf6u5NvCvV8W7v154d5vC/f+vHDvt4V7//qFe/+5wlf+ XHfH6EtT0yqoSqqKqqZqU3VRdVP12F1GHKZjGY9lPpYBWSZkGZFlRpYhWaYk TEngM8SUhCkJUxKmJExJmJIwJWFK0pSkKUl81ZiSNCVpStKUpClJU5KmpExJ mZIyJYUnElNSpqRMSZmSMiVlStqUtClpU9KmpPHgakralLQpaVPSpmSbkm1K tinZ35V8W7jPy8J9Pi/c523hPp8X7vO2cJ9fv3CfP1f4fu7uq0ZfmppWQVVS VVQ1VZuqi6qbqsfuMuIwHct4LPOxDMgyIcuILDOyDMkyJWFKAp8hpiRMSZiS MCVhSsKUhCkJU5KmJE1J4qvGlKQpSVOSpiRNSZqSNCVlSsqUlCkpPJGYkjIl ZUrKlJQpKVPSpqRNSZuSNiWNB1dT0qakTUmbkjYl25RsU7JNyf6u5MvC3T+f F+5/fvtvC/dfP710/3vh/uunj90vXrj/oPjPFV4/P3tnPHvyqal5FpalZWVZ W7Ytuyy7LXvwdisTdLIQykIpC6kstLIQy0ItC7ks9BLoJfS5gl4CvQR6CfQS 6CXQS6CXQC+JXhK9pL6I0Euil0QviV4SvSR6SfRS6KXQS6GX0pMLein0Uuil 0Euhl0IvjV4avTR6afTSetRFL41eGr00emn0stHLRi8bveyBl28Leb0s5PV5 Ia+3hbw+L+T1tpDXr1/I6+8ljqz1s67Jp6rmWViWlpVlbdm27LLstuzB261M 0MlCKAulLKSy0MpCLAu1LOSy0Eugl9DnCnoJ9BLoJdBLoJdAL4FeAr0kekn0 kvoiQi+JXhK9JHpJ9JLoJdFLoZdCL4VeSk8u6KXQS6GXQi+FXgq9NHpp9NLo pdFL61EXvTR6afTS6KXRy0YvG71s9LIHXr4t5HhZyPF5IcfbQo7PCzneFnL8 +oUcfy9x/az7ymfyqat5FpalZWVZW7Ytuyy7LXvwdisTdLIQykIpC6kstLIQ y0ItC7ks9BLoJfS5gl4CvQR6CfQS6CXQS6CXQC+JXhK9pL6I0Euil0QviV4S vSR6SfRS6KXQS6GX0pMLein0Uuil0Euhl0IvjV4avTR6afTSetRFL41eGr00 emn0stHLRi8bveyBl28LOV8Wcn5eyPm2kPPzQs63hZy/fiHn30vc+9m1fyaf yppnYVlaVpa1Zduyy7LbsgdvtzJBJwuhLJSykMpCKwuxLNSykMtCL4FeQp8r 6CXQS6CXQC+BXgK9BHoJ9JLoJdFL6osIvSR6SfSS6CXRS6KXRC+FXgq9FHop Pbmgl0IvhV4KvRR6KfTS6KXRS6OXRi+tR1300uil0Uujl0YvG71s9LLRyx54 +baQ62Uh1+eFXG8LuT4v5HpbyPXrF3L9vcRXXrXumHxqa56FZWlZWdaWbcsu y27LHrzdygSdLISyUMpCKgutLMSyUMtCLgu9BHoJfa6gl0AvgV4CvQR6CfQS 6CXQS6KXRC+pLyL0kugl0Uuil0QviV4SvRR6KfRS6KX05IJeCr0Uein0Uuil 0Eujl0YvjV4avbQeddFLo5dGL41eGr1s9LLRy0Yve+Dl20Lul4Xcnxdyvy3k /ryQ+20h969fyP33Ej8/vZ6fGn2pa5yFZWlZWdaWbcsuy27LHrzdygSdLISy UMpCKgutLMSyUMtCLgu9BHoJfa6gl0AvgV4CvQR6CfQS6CXQS6KXRC+pLyL0 kugl0Uuil0QviV4SvRR6KfRS6KX05IJeCr0Uein0Uuil0Eujl0YvjV4avbQe ddFLo5dGL41eGr1s9LLRy0Yve+Dl20LeLwt5f17I+20h788Leb8t5P3rF/L+ c4nXzxXPjh59qWuchWVpWVnWlm3LLstuyx683coEnSyEslDKQioLrSzEslDL Qi4LvQR6CX2uoJdAL4FeAr0Eegn0Eugl0Euil0QvqS8i9JLoJdFLopdEL4le Er0Uein0Uuil9OSCXgq9FHop9FLopdBLo5dGL41eGr20HnXRS6OXRi+NXhq9 bPSy0ctGL3vg5dtCvl4W8vV5IV9vC/n6vJCvt4V8/fqFfP29xFE/V9Y1+lLX OAvL0rKyrC3bll2W3ZY9eLuVCTpZCGWhlIVUFlpZiGWhloVcFnoJ9BL6XEEv gV4CvQR6CfQS6CXQS6CXRC+JXlJfROgl0Uuil0QviV4SvSR6KfRS6KXQS+nJ Bb0Uein0Uuil0Euhl0YvjV4avTR6aT3qopdGL41eGr00etnoZaOXjV72wMu3 hXy/LOT780K+3xby/Xkh328L+f71C/n+e4nr5+6ffY++1DXOwrK0rCxry7Zl l2W3ZQ/ebmWCThZCWShlIZWFVhZiWahlIZeFXgK9hD5X0Eugl0AvgV4CvQR6 CfQS6CXRS6KX1BcRekn0kugl0Uuil0QviV4KvRR6KfRSenJBL4VeCr0Uein0 Uuil0Uujl0YvjV5aj7ropdFLo5dGL41eNnrZ6GWjlz3w8m0hPy8L+fm8kJ+3 hfx8XsjP20J+fv1Cfv5e4r52XM/P6Etd4ywsS8vKsrZsW3ZZdlv24O1WJuhk IZSFUhZSWWhlIZaFWhZyWegl0EvocwW9BHoJ9BLoJdBLoJdAL4FeEr0kekl9 EaGXRC+JXhK9JHpJ9JLopdBLoZdCL6UnF/RS6KXQS6GXQi+FXhq9NHpp9NLo pfWoi14avTR6afTS6GWjl41eNnrZAy9fFvL183kh/+e3/7aQ//XTS/e/F/K/ fvrY/eKFfP38vcRX1U+vmHypa56FZWlZWdaWbcsuy27LHrzdygSdLISyUMpC KgutLMSyUMtCLgu9BHoJfa6gl0AvgV4CvQR6CfQS6CXQS6KXRC+pLyL0kugl 0Uuil0QviV4SvRR6KfRS6KX05IJeCr0Uein0Uuil0Eujl0YvjV4avbQeddFL o5dGL41eGr1s9LLRy0Yve+Dl20JeLwt5fV7I620hr88Leb0t5PXrF/L6e4mf te7InHypa56FZWlZWdaWbcsuy27LHrzdygSdLISyUMpCKgutLMSyUMtCLgu9 BHoJfa6gl0AvgV4CvQR6CfQS6CXQS6KXRC+pLyL0kugl0Uuil0QviV4SvRR6 KfRS6KX05IJeCr0Uein0Uuil0Eujl0YvjV4avbQeddFLo5dGL41eGr1s9LLR y0Yve+Dl20KOl4UcnxdyvC3k+LyQ420hx69fyPHnEsfP9fTTPflS1zwLy9Ky sqwt25Zdlt2WPXi7lQk6WQhloZSFVBZaWYhloZaFXBZ6CfQS+lxBL4FeAr0E egn0Eugl0Eugl0QviV5SX0ToJdFLopdEL4leEr0kein0Uuil0EvpyQW9FHop 9FLopdBLoZdGL41eGr00emk96qKXRi+NXhq9NHrZ6GWjl41e9sDLt4WcLws5 Py/kfFvI+Xkh59tCzl+/kPPvJY66cl978qWueRaWpWVlWVu2Lbssuy178HYr E3SyEMpCKQupLLSyEMtCLQu5LPQS6CX0uYJeAr0Eegn0Eugl0Eugl0AviV4S vaS+iNBLopdEL4leEr0kekn0Uuil0Euhl9KTC3op9FLopdBLoZdCL41eGr00 emn00nrURS+NXhq9NHpp9LLRy0YvG73sgZdvC7leFnJ9Xsj1tpDr80Kut4Vc v34h199LXKtXPvfkS13zLCxLy8qytmxbdll2W/bg7VYm6GQhlIVSFlJZaGUh loVaFnJZ6CXQS+hzBb0Eegn0Eugl0Eugl0AvgV4SvSR6SX0RoZdEL4leEr0k ekn0kuil0Euhl0IvpScX9FLopdBLoZdCL4VeGr00emn00uil9aiLXhq9NHpp 9NLoZaOXjV42etkDL98Wcr8s5P68kPttIffnhdxvC7l//ULuv5e473hW/Iy+ 1DXOwrK0rCxry7Zll2W3ZQ/ebmWCThZCWShlIZWFVhZiWahlIZeFXgK9hD5X 0Eugl0AvgV4CvQR6CfQS6CXRS6KX1BcRekn0kugl0Uuil0QviV4KvRR6KfRS enJBL4VeCr0Uein0Uuil0Uujl0YvjV5aj7ropdFLo5dGL41eNnrZ6GWjlz3w 8m0h75eFvD8v5P22kPfnhbzfFvL+9Qt5/73E1///77Rqjb7UNc7CsrSsLGvL tmWXZbdlD95uZYJOFkJZKGUhlYVWFmJZqGUhl4VeAr2EPlfQS6CXQC+BXgK9 BHoJ9BLoJdFLopfUFxF6SfSS6CXRS6KXRC+JXgq9FHop9FJ6ckEvhV4KvRR6 KfRS6KXRS6OXRi+NXlqPuuil0Uujl0YvjV42etnoZaOXPfDybSFfLwv5+ryQ r7eFfH1eyNfbQr5+/UK+/l7iZ93VO0df6hpnYVlaVpa1Zduyy7LbsgdvtzJB JwuhLJSykMpCKwuxLNSykMtCL4FeQp8r6CXQS6CXQC+BXgK9BHoJ9JLoJdFL 6osIvSR6SfSS6CXRS6KXRC+FXgq9FHopPbmgl0IvhV4KvRR6KfTS6KXRS6OX Ri+tR1300uil0Uujl0YvG71s9LLRyx54+baQ75eFfH9eyPfbQr4/L+T7bSHf v34h338ucf7cO+Ku0Ze6xllYlpaVZW3Ztuyy7LbswdutTNDJQigLpSykstDK QiwLtSzkstBLoJfQ5wp6CfQS6CXQS6CXQC+BXgK9JHpJ9JL6IkIviV4SvSR6 SfSS6CXRS6GXQi+FXkpPLuil0Euhl0IvhV4KvTR6afTS6KXRS+tRF700emn0 0uil0ctGLxu9bPSyB16+LeTnZSE/nxfy87aQn88L+XlbyM+vX8jP30scXf9c xj36Utc4C8vSsrKsLduWXZbdlj14u5UJOlkIZaGUhVQWWlmIZaGWhVwWegn0 EvpcQS+BXgK9BHoJ9BLoJdBLoJdEL4leUl9E6CXRS6KXRC+JXhK9JHop9FLo pdBL6ckFvRR6KfRS6KXQS6GXRi+NXhq9NHppPeqil0YvjV4avTR62ehlo5eN XvbAy5eFfP98Xsj/+e2/LeR//fTS/e+F/K+fPna/eCHfP38vccW6rrgnX+qa Z2FZWlaWtWXbssuy27IHb7cyQScLoSyUspDKQisLsSzUspDLQi+BXkKfK+gl 0Eugl0AvgV4CvQR6CfSS6CXRS+qLCL0kekn0kugl0Uuil0QvhV4KvRR6KT25 oJdCL4VeCr0Uein00uil0Uujl0YvrUdd9NLopdFLo5dGLxu9bPSy0cseePm2 kNfLQl6fF/J6W8jr80Jebwt5/fqFvP5e4r6frnomX+qaZ2FZWlaWtWXbssuy 27IHb7cyQScLoSyUspDKQisLsSzUspDLQi+BXkKfK+gl0Eugl0AvgV4CvQR6 CfSS6CXRS+qLCL0kekn0kugl0Uuil0QvhV4KvRR6KT25oJdCL4VeCr0Uein0 0uil0Uujl0YvrUdd9NLopdFLo5dGLxu9bPSy0cseePm2kONlIcfnhRxvCzk+ L+R4W8jx6xdy/L3EV1+5rjX5Utc8C8vSsrKsLduWXZbdlj14u5UJOlkIZaGU hVQWWlmIZaGWhVwWegn0EvpcQS+BXgK9BHoJ9BLoJdBLoJdEL4leUl9E6CXR S6KXRC+JXhK9JHop9FLopdBL6ckFvRR6KfRS6KXQS6GXRi+NXhq9NHppPeqi l0YvjV4avTR62ehlo5eNXvbAy7eFnC8LOT8v5HxbyPl5IefbQs5fv5Dz7yV+ on/uJyZf6ppnYVlaVpa1Zduyy7LbsgdvtzJBJwuhLJSykMpCKwuxLNSykMtC L4FeQp8r6CXQS6CXQC+BXgK9BHoJ9JLoJdFL6osIvSR6SfSS6CXRS6KXRC+F Xgq9FHopPbmgl0IvhV4KvRR6KfTS6KXRS6OXRi+tR1300uil0Uujl0YvG71s 9LLRyx54+baQ62Uh1+eFXG8LuT4v5HpbyPXrF3L9ucT188/l3asmX+qaZ2FZ WlaWtWXbssuy27IHb7cyQScLoSyUspDKQisLsSzUspDLQi+BXkKfK+gl0Eug l0AvgV4CvQR6CfSS6CXRS+qLCL0kekn0kugl0Uuil0QvhV4KvRR6KT25oJdC L4VeCr0Uein00uil0Uujl0YvrUdd9NLopdFLo5dGLxu9bPSy0cseePm2kPtl IffnhdxvC7k/L+R+W8j96xdy/73EsX925h59qWuchWVpWVnWlm3LLstuyx68 3coEnSyEslDKQioLrSzEslDLQi4LvQR6CX2uoJdAL4FeAr0Eegn0Eugl0Eui l0QvqS8i9JLoJdFLopdEL4leEr0Uein0Uuil9OSCXgq9FHop9FLopdBLo5dG L41eGr20HnXRS6OXRi+NXhq9bPSy0ctGL3vg5dtC3i8LeX9eyPttIe/PC3m/ LeT96xfy/nuJK+766Wv0pa5xFpalZWVZW7Ytuyy7LXvwdisTdLIQykIpC6ks tLIQy0ItC7ks9BLoJfS5gl4CvQR6CfQS6CXQS6CXQC+JXhK9pL6I0Euil0Qv iV4SvSR6SfRS6KXQS6GX0pMLein0Uuil0Euhl0IvjV4avTR6afTSetRFL41e Gr00emn0stHLRi8bveyBl28L+XpZyNfnhXy9LeTr80K+3hby9esX8vX3Evez 13U9oy91jbOwLC0ry9qybdll2W3Zg7dbmaCThVAWSllIZaGVhVgWalnIZaGX QC+hzxX0Eugl0Eugl0AvgV4CvQR6SfSS6CX1RYReEr0kekn0kugl0Uuil0Iv hV4KvZSeXNBLoZdCL4VeCr0Uemn00uil0Uujl9ajLnpp9NLopdFLo5eNXjZ6 2ehlD7x8W8j3y0K+Py/k+20h358X8v22kO9fv5Dvv5f42vn0z8/oS13jLCxL y8qytmxbdll2W/bg7VYm6GQhlIVSFlJZaGUhloVaFnJZ6CXQS+hzBb0Eegn0 Eugl0Eugl0AvgV4SvSR6SX0RoZdEL4leEr0kekn0kuil0Euhl0IvpScX9FLo pdBLoZdCL4VeGr00emn00uil9aiLXhq9NHpp9NLoZaOXjV42etkDL98W8vOy kJ/PC/l5W8jP54X8vC3k59cv5OfvJX5yXREx+lLXOAvL0rKyrC3bll2W3ZY9 eLuVCTpZCGWhlIVUFlpZiGWhloVcFnoJ9BL6XEEvgV4CvQR6CfQS6CXQS6CX RC+JXlJfROgl0Uuil0QviV4SvSR6KfRS6KXQS+nJBb0Uein0Uuil0Euhl0Yv jV4avTR6aT3qopdGL41eGr00etnoZaOXjV72wMuXhfz8fF7I//ntvy3kf/30 0v3vhfyvnz52v3ghPz9/LnH/PE89VZMvdc2zsCwtK8vasm3ZZdlt2YO3W5mg k4VQFkpZSGWhlYVYFmpZyGWhl0Avoc8V9BLoJdBLoJdAL4FeAr0Eekn0kugl 9UWEXhK9JHpJ9JLoJdFLopdCL4VeCr2UnlzQS6GXQi+FXgq9FHpp9NLopdFL o5fWoy56afTS6KXRS6OXjV42etnoZQ+8fFvI62Uhr88Leb0t5PV5Ia+3hbx+ /UJefy9x7Cv27smXuuZZWJaWlWVt2bbssuy27MHbrUzQyUIoC6UspLLQykIs C7Us5LLQS6CX0OcKegn0Eugl0Eugl0AvgV4CvSR6SfSS+iJCL4leEr0kekn0 kugl0Uuhl0IvhV5KTy7opdBLoZdCL4VeCr00emn00uil0UvrURe9NHpp9NLo pdHLRi8bvWz0sgdevi3keFnI8Xkhx9tCjs8LOd4Wcvz6hRx/L3Fl/+R9Tb7U Nc/CsrSsLGvLtmWXZbdlD95uZYJOFkJZKGUhlYVWFmJZqGUhl4VeAr2EPlfQ S6CXQC+BXgK9BHoJ9BLoJdFLopfUFxF6SfSS6CXRS6KXRC+JXgq9FHop9FJ6 ckEvhV4KvRR6KfRS6KXRS6OXRi+NXlqPuuil0Uujl0YvjV42etnoZaOXPfDy bSHny0LOzws53xZyfl7I+baQ89cv5Px7ifdP3Ovnnnypa56FZWlZWdaWbcsu y27LHrzdygSdLISyUMpCKgutLMSyUMtCLgu9BHoJfa6gl0AvgV4CvQR6CfQS 6CXQS6KXRC+pLyL0kugl0Uuil0QviV4SvRR6KfRS6KX05IJeCr0Uein0Uuil 0Eujl0YvjV4avbQeddFLo5dGL41eGr1s9LLRy0Yve+Dl20Kul4VcnxdyvS3k +ryQ620h169fyPX3El/XT9/5M/lS1zwLy9Kysqwt25Zdlt2WPXi7lQk6WQhl oZSFVBZaWYhloZaFXBZ6CfQS+lxBL4FeAr0Eegn0Eugl0Eugl0QviV5SX0To JdFLopdEL4leEr0kein0Uuil0EvpyQW9FHop9FLopdBLoZdGL41eGr00emk9 6qKXRi+NXhq9NHrZ6GWjl41e9sDLt4XcLwu5Py/kflvI/Xkh99tC7l+/kPvv JX7yzu4YfalrnIVlaVlZ1pZtyy7LbssevN3KBJ0shLJQykIqC60sxLJQy0Iu C70Eegl9rqCXQC+BXgK9BHoJ9BLoJdBLopdEL6kvIvSS6CXRS6KXRC+JXhK9 FHop9FLopfTkgl4KvRR6KfRS6KXQS6OXRi+NXhq9tB510Uujl0YvjV4avWz0 stHLRi974OXbQt4vC3l/Xsj7bSHvzwt5vy3k/esX8v5ziff62SuuHH2pa5yF ZWlZWdaWbcsuy27LHrzdygSdLISyUMpCKgutLMSyUMtCLgu9BHoJfa6gl0Av gV4CvQR6CfQS6CXQS6KXRC+pLyL0kugl0Uuil0QviV4SvRR6KfRS6KX05IJe Cr0Uein0Uuil0Eujl0YvjV4avbQeddFLo5dGL41eGr1s9LLRy0Yve+Dl20K+ Xhby9XkhX28L+fq8kK+3hXz9+oV8/b3E/1ze+3l69KWucRaWpWVlWVu2Lbss uy178HYrE3SyEMpCKQupLLSyEMtCLQu5LPQS6CX0uYJeAr0Eegn0Eugl0Eug l0AviV4SvaS+iNBLopdEL4leEr0kekn0Uuil0Euhl9KTC3op9FLopdBLoZdC L41eGr00emn00nrURS+NXhq9NHpp9LLRy0YvG73sgZdvC/l+Wcj354V8vy3k +/NCvt8W8v3rF/L99xJXrX2tPfpS1zgLy9Kysqwt25Zdlt2WPXi7lQk6WQhl oZSFVBZaWYhloZaFXBZ6CfQS+lxBL4FeAr0Eegn0Eugl0Eugl0QviV5SX0To JdFLopdEL4leEr0kein0Uuil0EvpyQW9FHop9FLopdBLoZdGL41eGr00emk9 6qKXRi+NXhq9NHrZ6GWjl41e9sDLt4X8vCzk5/NCft4W8vN5IT9vC/n59Qv5 +XuJ989TlffoS13jLCxLy8qytmxbdll2W/bg7VYm6GQhlIVSFlJZaGUhloVa FnJZ6CXQS+hzBb0Eegn0Eugl0Eugl0AvgV4SvSR6SX0RoZdEL4leEr0kekn0 kuil0Euhl0IvpScX9FLopdBLoZdCL4VeGr00emn00uil9aiLXhq9NHpp9NLo ZaOXjV42etkDL18W8vr5+TyR/+fH/7aR//3bW/m/V/K/f/tc/uKd/M8/8e+V vq4r1v6ZfLDr/9AFdoldYdfYbewu7G7sHr3vDEbFLCWz1MxSNEvVLGWz1M1S OEvlhMoJftaonFA5oXJC5YTKCZUTKidUTqqcVDnJrymVkyonVU6qnFQ5qXJS 5ZTKKZVTKqf4hKNySuWUyimVUyqnVE6rnFY5rXJa5TQfjlVOq5xWOa1yWuVs lbNVzlY5eyLn685ebzt7vezs9bqz18vOXq87e/3+nb3+Xumn6rnvNfns1/+h C+wSu8KusdvYXdjd2D163xmMijl39jxUM+fOnoeq5tzZ81DdnDt7Hqqcc2fP Q37WqJxzZ89DlXPu7Hmocs6dPQ9Vzrmz589+lXPu7HnIrymVc+7seahyzp09 D1XOubPnoco5d/Y8VDnnzp6HfMJROefOnocq59zZ81DlnDt7fv5TOefOnocq 59zZ85APxyrn3NnzUOWcO3seqpxzZ89DlXPu7Hk4kfN1Z8fbzo6XnR2vOzte dna87uz4/Ts7/lzpa6249k9OPh72f+gCu8SusGvsNnYXdjd2j953BqNizp09 D9XMubPnoao5d/Y8VDfnzp6HKufc2fOQnzUq59zZ81DlnDt7Hqqcc2fPQ5Vz 7uz5s1/lnDt7HvJrSuWcO3seqpxzZ89DlXPu7Hmocs6dPQ9Vzrmz5yGfcFTO ubPnoco5d/Y8VDnnzp6f/1TOubPnoco5d/Y85MOxyjl39jxUOefOnocq59zZ 81DlnDt7Hk7kfN3Z+baz82Vn5+vOzpedna87O3//zs6/Vzrun86oySfI/g9d YJfYFXaN3cbuwu7G7tH7zmBUzLmz56GaOXf2PFQ1586eh+rm3NnzUOWcO3se 8rNG5Zw7ex6qnHNnz0OVc+7seahyzp09f/arnHNnz0N+Tamcc2fPQ5Vz7ux5 qHLOnT0PVc65s+ehyjl39jzkE47KOXf2PFQ5586ehyrn3Nnz85/KOXf2PFQ5 586eh3w4Vjnnzp6HKufc2fNQ5Zw7ex6qnHNnz8OJnK87u952dr3s7Hrd2fWy s+t1Z9fv39n190pX3flTe/Ihs/9DF9gldoVdY7exu7C7sXv0vjMYFXPu7Hmo Zs6dPQ9Vzbmz56G6OXf2PFQ5586eh/ysUTnnzp6HKufc2fNQ5Zw7ex6qnHNn z5/9Kufc2fOQX1Mq59zZ81DlnDt7Hqqcc2fPQ5Vz7ux5qHLOnT0P+YSjcs6d PQ9Vzrmz56HKOXf2/Pyncs6dPQ9Vzrmz5yEfjlXOubPnoco5d/Y8VDnnzp6H Kufc2fNwIufrzu63nd0vO7tfd3a/7Ox+3dn9+3d2/73Se+2fa9+z76CNu8Au sSvsGruN3YXdjd2j953BqJhzZ89DNXPu7Hmoas6dPQ/Vzbmz56HKOXf2PORn jco5d/Y8VDnnzp6HKufc2fNQ5Zw7e/7sVznnzp6H/JpSOefOnocq59zZ81Dl nDt7Hqqcc2fPQ5Vz7ux5yCcclXPu7Hmocs6dPQ9Vzrmz5+c/lXPu7Hmocs6d PQ/5cKxyzp09D1XOubPnoco5d/Y8VDnnzp6HEzlfd/Z+29n7ZWfv1529X3b2 ft3Z+/fv7P33Sl933nU/s++gjbvALrEr7Bq7jd2F3Y3do/edwaiYc2fPQzVz 7ux5qGrOnT0P1c25s+ehyjl39jzkZ43KOXf2PFQ5586ehyrn3NnzUOWcO3v+ 7Fc5586eh/yaUjnnzp6HKufc2fNQ5Zw7ex6qnHNnz0OVc+7secgnHJVz7ux5 qHLOnT0PVc65s+fnP5Vz7ux5qHLOnT0P+XCscs6dPQ9Vzrmz56HKOXf2PFQ5 586ehxM5X3f29bazr5edfb3u7OtlZ1+vO/v6/Tv7+nuln1471pp9B23cBXaJ XWHX2G3sLuxu7B697wxGxZw7ex6qmXNnz0NVc+7seahuzp09D1XOubPnIT9r VM65s+ehyjl39jxUOefOnocq59zZ82e/yjl39jzk15TKOXf2PFQ5586ehyrn 3NnzUOWcO3seqpxzZ89DPuGonHNnz0OVc+7seahyzp09P/+pnHNnz0OVc+7s eciHY5Vz7ux5qHLOnT0PVc65s+ehyjl39jycyPm6s++3nX2/7Oz7dWffLzv7 ft3Z9+/f2fefK32v9eSTMfsO2rgL7BK7wq6x29hd2N3YPXrfGYyKOXf2PFQz 586eh6rm3NnzUN2cO3seqpxzZ89DftaonHNnz0OVc+7seahyzp09D1XOubPn z36Vc+7secivKZVz7ux5qHLOnT0PVc65s+ehyjl39jxUOefOnod8wlE5586e hyrn3NnzUOWcO3t+/lM5586ehyrn3NnzkA/HKufc2fNQ5Zw7ex6qnHNnz0OV c+7seTiR83VnP287+3nZ2c/rzn5edvbzurOf37+zn79XOu5r7a7Zd9DGXWCX 2BV2jd3G7sLuxu7R+85gVMy5s+ehmjl39jxUNefOnofq5tzZ81DlnDt7HvKz RuWcO3seqpxzZ89DlXPu7Hmocs6dPX/2q5xzZ89Dfk2pnHNnz0OVc+7seahy zp09D1XOubPnoco5d/Y85BOOyjl39jxUOefOnocq59zZ8/Ofyjl39jxUOefO nod8OFY5586ehyrn3NnzUOWcO3seqpxzZ8/DiZxvO3v9vOzs//z4X3f2v357 K//Lzv7Xb5/L37yz/1lRf650dT157dF30OZdYJfYFXaN3cbuwu7G7tH7zmBU zFIyS80sRbNUzVI2S90shbNUTqic4GeNygmVEyonVE6onFA5oXJC5aTKSZWT /JpSOalyUuWkykmVkyonVU6pnFI5pXKKTzgqp1ROqZxSOaVySuW0ymmV0yqn VU7z4VjltMppldMqp1XOVjlb5WyVsydyvu7s9baz18vOXq87e73s7PW6s9fv 39nr75XeEdfPc42+gzbvArvErrBr7DZ2F3Y3do/edwajYs6dPQ/VzLmz56Gq OXf2PFQ3586ehyrn3NnzkJ81Kufc2fNQ5Zw7ex6qnHNnz0OVc+7s+bNf5Zw7 ex7ya0rlnDt7Hqqcc2fPQ5Vz7ux5qHLOnT0PVc65s+chn3BUzrmz56HKOXf2 PFQ5586en/9Uzrmz56HKOXf2POTDsco5d/Y8VDnnzp6HKufc2fNQ5Zw7ex5O 5Hzd2fG2s+NlZ8frzo6XnR2vOzt+/86Ov1f6en7qXs/oO2jzLrBL7Aq7xm5j d2F3Y/fofWcwKubc2fNQzZw7ex6qmnNnz0N1c+7seahyzp09D/lZo3LOnT0P Vc65s+ehyjl39jxUOefOnj/7Vc65s+chv6ZUzrmz56HKOXf2PFQ5586ehyrn 3NnzUOWcO3se8glH5Zw7ex6qnHNnz0OVc+7s+flP5Zw7ex6qnHNnz0M+HKuc c2fPQ5Vz7ux5qHLOnT0PVc65s+fhRM7XnZ1vOztfdna+7ux82dn5urPz9+/s /Huln76j62f0HbR5F9gldoVdY7exu7C7sXv0vjMYFXPu7HmoZs6dPQ9Vzbmz 56G6OXf2PFQ5586eh/ysUTnnzp6HKufc2fNQ5Zw7ex6qnHNnz5/9Kufc2fOQ X1Mq59zZ81DlnDt7Hqqcc2fPQ5Vz7ux5qHLOnT0P+YSjcs6dPQ9Vzrmz56HK OXf2/Pyncs6dPQ9Vzrmz5yEfjlXOubPnoco5d/Y8VDnnzp6HKufc2fNwIufr zq63nV0vO7ted3a97Ox63dn1+3d2/bnSz4r9EztG30Gbd4FdYlfYNXYbuwu7 G7tH7zuDUTHnzp6Haubc2fNQ1Zw7ex6qm3Nnz0OVc+7secjPGpVz7ux5qHLO nT0PVc65s+ehyjl39vzZr3LOnT0P+TWlcs6dPQ9Vzrmz56HKOXf2PFQ5586e hyrn3NnzkE84Kufc2fNQ5Zw7ex6qnHNnz89/Kufc2fNQ5Zw7ex7y4VjlnDt7 Hqqcc2fPQ5Vz7ux5qHLOnT0PJ3K+7ux+29n9srP7dWf3y87u153dv39n998r HU9ez12z76CNu8AusSvsGruN3YXdjd2j953BqJhzZ89DNXPu7Hmoas6dPQ/V zbmz56HKOXf2PORnjco5d/Y8VDnnzp6HKufc2fNQ5Zw7e/7sVznnzp6H/JpS OefOnocq59zZ81DlnDt7Hqqcc2fPQ5Vz7ux5yCcclXPu7Hmocs6dPQ9Vzrmz 5+c/lXPu7Hmocs6dPQ/5cKxyzp09D1XOubPnoco5d/Y8VDnnzp6HEzlfd/Z+ 29n7ZWfv1529X3b2ft3Z+/fv7P33Stdeff307Dto4y6wS+wKu8ZuY3dhd2P3 6H1nMCrm3NnzUM2cO3seqppzZ89DdXPu7Hmocs6dPQ/5WaNyzp09D1XOubPn oco5d/Y8VDnnzp4/+1XOubPnIb+mVM65s+ehyjl39jxUOefOnocq59zZ81Dl nDt7HvIJR+WcO3seqpxzZ89DlXPu7Pn5T+WcO3seqpxzZ89DPhyrnHNnz0OV c+7seahyzp09D1XOubPn4UTO1519ve3s62VnX687+3rZ2dfrzr5+/86+/l7p Hc8/f+eafQdt3AV2iV1h19ht7C7sbuweve8MRsWcO3seqplzZ89DVXPu7Hmo bs6dPQ9Vzrmz5yE/a1TOubPnoco5d/Y8VDnnzp6HKufc2fNnv8o5d/Y85NeU yjl39jxUOefOnocq59zZ81DlnDt7Hqqcc2fPQz7hqJxzZ89DlXPu7Hmocs6d PT//qZxzZ89DlXPu7HnIh2OVc+7seahyzp09D1XOubPnoco5d/Y8nMj5urPv t519v+zs+3Vn3y87+37d2ffv39n33yt9Pddadc++gzbuArvErrBr7DZ2F3Y3 do/edwajYs6dPQ/VzLmz56GqOXf2PFQ3586ehyrn3NnzkJ81Kufc2fNQ5Zw7 ex6qnHNnz0OVc+7s+bNf5Zw7ex7ya0rlnDt7Hqqcc2fPQ5Vz7ux5qHLOnT0P Vc65s+chn3BUzrmz56HKOXf2PFQ5586en/9Uzrmz56HKOXf2POTDsco5d/Y8 VDnnzp6HKufc2fNQ5Zw7ex5O5Hzd2c/bzn5edvbzurOfl539vO7s5/fv7Ofv lX72P5f5+pl9B23cBXaJXWHX2G3sLuxu7B697wxGxZw7ex6qmXNnz0NVc+7s eahuzp09D1XOubPnIT9rVM65s+ehyjl39jxUOefOnocq59zZ82e/yjl39jzk 15TKOXf2PFQ5586ehyrn3NnzUOWcO3seqpxzZ89DPuGonHNnz0OVc+7seahy zp09P/+pnHNnz0OVc+7seciHY5Vz7ux5qHLOnT0PVc65s+ehyjl39jycyPm2 s+PnZWf/58f/urP/9dtb+V929r9++1z+5p39z1n4P1c6flbG7idG30Gbd4Fd YlfYNXYbuwu7G7tH7zuDUTFLySw1sxTNUjVL2Sx1sxTOUjmhcoKfNSonVE6o nFA5oXJC5YTKCZWTKidVTvJrSuWkykmVkyonVU6qnFQ5pXJK5ZTKKT7hqJxS OaVySuWUyimV0yqnVU6rnFY5zYdjldMqp1VOq5xWOVvlbJWzVc6eyPm6s9fb zl4vO3u97uz1srPX685ev39nr79X+p/LWbly9B20eRfYJXaFXWO3sbuwu7F7 9L4zGBVz7ux5qGbOnT0PVc25s+ehujl39jxUOefOnof8rFE5586ehyrn3Nnz UOWcO3seqpxzZ8+f/Srn3NnzkF9TKufc2fNQ5Zw7ex6qnHNnz0OVc+7seahy zp09D/mEo3LOnT0PVc65s+ehyjl39vz8p3LOnT0PVc65s+chH45Vzrmz56HK OXf2PFQ5586ehyrn3NnzcCLn686Ot50dLzs7Xnd2vOzseN3Z8ft3dvy90rXv fy53j76DNu8Cu8SusGvsNnYXdjd2j953BqNizp09D9XMubPnoao5d/Y8VDfn zp6HKufc2fOQnzUq59zZ81DlnDt7Hqqcc2fPQ5Vz7uz5s1/lnDt7HvJrSuWc O3seqpxzZ89DlXPu7Hmocs6dPQ9Vzrmz5yGfcFTOubPnoco5d/Y8VDnnzp6f /1TOubPnoco5d/Y85MOxyjl39jxUOefOnocq59zZ81DlnDt7Hk7kfN3Z+baz 82Vn5+vOzpedna87O3//zs6/V3pnP1fv0XfQ5l1gl9gVdo3dxu7C7sbu0fvO YFTMubPnoZo5d/Y8VDXnzp6H6ubc2fNQ5Zw7ex7ys0blnDt7Hqqcc2fPQ5Vz 7ux5qHLOnT1/9qucc2fPQ35NqZxzZ89DlXPu7Hmocs6dPQ9Vzrmz56HKOXf2 POQTjso5d/Y8VDnnzp6HKufc2fPzn8o5d/Y8VDnnzp6HfDhWOefOnocq59zZ 81DlnDt7Hqqcc2fPw4mcrzu73nZ2vezset3Z9bKz63Vn1+/f2fX3St8/edV1 j76DNu8Cu8SusGvsNnYXdjd2j953BqNizp09D9XMubPnoao5d/Y8VDfnzp6H Kufc2fOQnzUq59zZ81DlnDt7Hqqcc2fPQ5Vz7uz5s1/lnDt7HvJrSuWcO3se qpxzZ89DlXPu7Hmocs6dPQ9Vzrmz5yGfcFTOubPnoco5d/Y8VDnnzp6f/1TO ubPnoco5d/Y85MOxyjl39jxUOefOnocq59zZ81DlnDt7Hk7k/D9QSwECFgAU AAAACADuntws9/Z2lOlXAAAAVwcAAwAAAAAAAAABAAAAAAAAAAAAbG9nUEsF BgAAAAABAAEAMQAAAApYAAAAAA== --------------050607040907070506080900-- From owner-linux-xfs@oss.sgi.com Fri Jun 28 15:50:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5SMotnC018942 for ; Fri, 28 Jun 2002 15:50:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5SMottv018941 for linux-xfs-outgoing; Fri, 28 Jun 2002 15:50:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.190]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5SMojnC018897 for ; Fri, 28 Jun 2002 15:50:45 -0700 Received: (qmail 7164 invoked by uid 500); 28 Jun 2002 22:53:49 -0000 Subject: Re: XFS corruption! From: Austin Gonyou To: Libor Vanek Cc: Stephen Lord , linux-xfs@oss.sgi.com In-Reply-To: <3D1CA432.9030904@conet.cz> References: <3D1CA432.9030904@conet.cz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-9ZXy7QJSe5xqXDqq3W1K" Organization: Coremetrics, Inc. X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 28 Jun 2002 17:53:49 -0500 Message-Id: <1025304829.6674.13.camel@UberGeek> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.9 required=5.0 tests=IN_REP_TO,PLING version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-9ZXy7QJSe5xqXDqq3W1K Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I'd recommend Reiser before EXT3. Reiser, I've found, is much quicker at most things than EXT3, unless you want to some benefits of journaling. On Fri, 2002-06-28 at 13:00, Libor Vanek wrote: > > > > > >Can you please run xfs_check on the filesystem after this has > happened. > >I suspect you may have found a hole in the endian conversion code in > >XFS. Doing the copy into the filesystem over NFS is probably > >generating more fragmentation and hence more complex free space > >structures than doing it locally.=20 > > > >Steve > > > >=20=20 > > > Hi, > I attach the output of xfs_check. The filesystem is fragmented a lot - > there is lot quite big (300-500 MB) files and many many office/CAD=20 > documents with few MB each. If you want I can do some more tests but=20 > only till sunday morning - then I have to format it to ext3 :-( >=20 > Thanks, > Libor >=20 >=20=20 --=20 Austin Gonyou Coremetrics, Inc. --=-9ZXy7QJSe5xqXDqq3W1K Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQA9HOj994g6ZVmFMoIRAgVGAKDFMDq4AdCwLLQ3RkumF6vkUqT1wwCeMN05 6RsMLqy1z4z0Mq5dNDuwfSw= =SlaV -----END PGP SIGNATURE----- --=-9ZXy7QJSe5xqXDqq3W1K-- From owner-linux-xfs@oss.sgi.com Fri Jun 28 15:55:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5SMt1nC019136 for ; Fri, 28 Jun 2002 15:55:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5SMt03r019135 for linux-xfs-outgoing; Fri, 28 Jun 2002 15:55:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from CoNetUX (IDENT:DmyeLw98v1hM0nO14dpQT1SK1vmO6keG@firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5SMssnC019102 for ; Fri, 28 Jun 2002 15:54:55 -0700 Received: from conet.cz (Libor [192.168.1.130]) by CoNetUX (8.11.6/8.11.6) with ESMTP id g5SMwQE03394; Sat, 29 Jun 2002 00:58:26 +0200 Message-ID: <3D1CE9C1.90108@conet.cz> Date: Sat, 29 Jun 2002 00:57:05 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Austin Gonyou CC: Stephen Lord , linux-xfs@oss.sgi.com Subject: Re: XFS corruption! References: <3D1CA432.9030904@conet.cz> <1025304829.6674.13.camel@UberGeek> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=PLING,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > >I'd recommend Reiser before EXT3. Reiser, I've found, is much quicker at >most things than EXT3, unless you want to some benefits of journaling. > > As the speed is not the problem (this is fileserver ONLY (no database etc.) and 100 Mbit/s is here the limit) I prefer ext3 because I still don't trust Reiser a lot (there still some "small" bugfixes...). But what I wanted to say - do you have any numbers? Some Reiser/ext2/ext3/XFS comparison? Or it's just subjective meaning? Libor From owner-linux-xfs@oss.sgi.com Fri Jun 28 15:58:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5SMwKnC019334 for ; Fri, 28 Jun 2002 15:58:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5SMwKm6019333 for linux-xfs-outgoing; Fri, 28 Jun 2002 15:58:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from CoNetUX (IDENT:SZgdE+RgyiG8UUSYnrxqCRPZSyLm/6ll@firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5SMwFnC019305 for ; Fri, 28 Jun 2002 15:58:16 -0700 Received: from conet.cz (Libor [192.168.1.130]) by CoNetUX (8.11.6/8.11.6) with ESMTP id g5SN1sE03509; Sat, 29 Jun 2002 01:01:54 +0200 Message-ID: <3D1CEA91.4080700@conet.cz> Date: Sat, 29 Jun 2002 01:00:33 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1a) Gecko/20020611 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, samba@lists.samba.org Subject: SOLUTION! Samba + XFS + ACL support Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.1 required=5.0 tests=PLING,SUPERLONG_LINE version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, information for everybody, who is using XFS modified RedHat 7.3 system and tries to compile SRPMS with Samba 2.2.5 (maybe also 2.2.4) with ACL support and Samba doesn't detect any ACL support: upgrade your XFS utilities from ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/i386/ - I think that libacl what helps but other upgrades doesn't hurt also ;-) Enjoy, Libor From owner-linux-xfs@oss.sgi.com Sat Jun 29 00:48:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5T7munC001470 for ; Sat, 29 Jun 2002 00:48:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5T7mu3x001469 for linux-xfs-outgoing; Sat, 29 Jun 2002 00:48:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5T7menC001441 for ; Sat, 29 Jun 2002 00:48:40 -0700 Received: from mountainviewdata.com (unknown [202.237.246.10]) by srv.dmz.us.mvd (Postfix) with ESMTP id C471CB713; Sat, 29 Jun 2002 00:52:19 -0700 (PDT) Message-ID: <3D1D647F.3070302@mountainviewdata.com> Date: Sat, 29 Jun 2002 15:40:47 +0800 From: Eric Mei User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: zh-cn, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com, eric@mountainviewdata.com Subject: Bug about XFS-1.0.1 on 2.4.5 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Team, This is a long report. I know some of you might be busy on kernel summit, we just can's believe XFS has such a serious bug. For some reason, we must stick on 2.4.5-xfs-1.0.1. We have the super-pcserver, connect with 5 Mac clients via Giga switch. All of the clients also have Gigaether NIC. After about 2-3 hours stressing, load average goes as high as 21, and continue increasing. All clients have lost connection. During the tests, there are many error messages: __alloc_pages: 0-order allocation failed __alloc_pages: 0-order allocation failed __alloc_pages: 0-order allocation failed ............ and such bulk of messages appear nearly every 10 minutes, 2 more hours later, system goes to dead... server is Duel Xeon 2.0G, 2GB Rambus RAM, ADTX 500G Raid storage, BCM gigaether card. Hyperthread is on, with "noapic" option, kernel 2.4.5-xfs-1.0.1, compiled *without* XFS_DEBUG. partition size is 500G. At the dead time, kdb show the zone infomations: DMA(4096 pages): free 559, inactive_clean 0, inactive_dirty 119 watermark is (128, 256, 384) Normal(225280 pages): free 21332, inactive_clean 92, inactive_dirty 4495 watermark is (255, 510, 765) High(294784 pages): free 516, inactive_clean 189311, inactive_dirty 23466 system overall active pages is 204281, inactive_dirty is 28080 bt shows kswapd is wait on xfs_ilock. and atalkd's backtrace is fsync_dev sys_sync panic kmem_zone_zalloc xfs_btree_init_cursor xfs_alloc_ag_vextend_near xfs_alloc_ag_vextend xfs_alloc_vextend xfs_bmap_alloc xfs_bmapi pagebuf_delalloc_convert pagebuf_write_full_page linvfs_write_full_page_nounlock _write_buffer sync_buffers fsync_dev sys_sync panic kmem_zone_zalloc xfs_btree_init_cursor xfs_alloc_ag_vextend_near xfs_alloc_ag_vextend xfs_alloc_vextend xfs_bmap_alloc xfs_bmapi xfs_strategy linvfs_pb_bmap pagebuf_delalloc_convert pagebuf_write_full_page linvfs_write_full_page_nounlock try_to_free_buffers page_launder do_try_to_free_buffers try_to_free_pages __alloc_pages __get_free_pages __pollwait datagram_poll .... do_select sys_select at that time no other processes in xfs or vm code. During the test, I found the inactive_clean+inactive_dirty in Normal zone is keeping decreasing. Is that a correct vm behaviour? Are there any page leaking in XFS? I appreciate anyone's help. If any further information needed, I'd be glad to do. thanks. Eric From owner-linux-xfs@oss.sgi.com Sat Jun 29 08:42:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5TFgCnC005173 for ; Sat, 29 Jun 2002 08:42:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5TFgCPL005172 for linux-xfs-outgoing; Sat, 29 Jun 2002 08:42:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5TFg6nC005144 for ; Sat, 29 Jun 2002 08:42:06 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id IAA01842 for ; Sat, 29 Jun 2002 08:45:47 -0700 (PDT) mail_from (sandeen@sgi.com) Received: from liberator (sshgate.corp.sgi.com [169.238.216.146]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id IAA50931; Sat, 29 Jun 2002 08:45:14 -0700 (PDT) Subject: Re: Bug about XFS-1.0.1 on 2.4.5 From: Eric Sandeen To: Eric Mei Cc: linux-xfs@oss.sgi.com In-Reply-To: <3D1D647F.3070302@mountainviewdata.com> References: <3D1D647F.3070302@mountainviewdata.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.7 Date: 29 Jun 2002 11:45:13 -0400 Message-Id: <1025365517.20112.18.camel@Liberator> Mime-Version: 1.0 X-Spam-Status: No, hits=-3.1 required=5.0 tests=IN_REP_TO,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 2002-06-29 at 03:40, Eric Mei wrote: > Hi Team, > > This is a long report. I know some of you might be busy on kernel > summit, we just can's believe XFS has such a serious bug. s/has/had/ > For some reason, we must stick on 2.4.5-xfs-1.0.1. You're essentially saying that you must stick with old, (apparently) buggy code. We simply don't have the bandwidth to support xfs & kernel code from 1 year ago. Your best bet would be to look through the mailing list archives to see if anyone has had a similar problem, and see if a mod was checked in to fix it; then try to backport that fix. http://oss.sgi.com/projects/xfs/mail_archive/200108/msg00307.html This thread makes it sound like it may well be an underlying kernel problem with 2.4.5-era kernels. -Eric From owner-linux-xfs@oss.sgi.com Sat Jun 29 09:20:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5TGKEnC005668 for ; Sat, 29 Jun 2002 09:20:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5TGKEer005667 for linux-xfs-outgoing; Sat, 29 Jun 2002 09:20:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from srv.dmz.us.mvd (namodn.com [209.0.100.50] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5TGK6nC005639 for ; Sat, 29 Jun 2002 09:20:06 -0700 Received: from mountainviewdata.com (unknown [202.237.246.10]) by srv.dmz.us.mvd (Postfix) with ESMTP id 95D5AB713 for ; Sat, 29 Jun 2002 09:23:47 -0700 (PDT) Message-ID: <3D1DDC5E.1010403@mountainviewdata.com> Date: Sun, 30 Jun 2002 00:12:14 +0800 From: Eric Mei User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020605 X-Accept-Language: zh-cn, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Bug about XFS-1.0.1 on 2.4.5 References: <3D1D647F.3070302@mountainviewdata.com> <1025365517.20112.18.camel@Liberator> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks a lot! As you know, if we try to backport vm fixes to 2.4.5, which kernel have most probably addressed this issue? 2.4.7? There is no evidence about it from kenrel ChangeLog. Sorry to occupy XFS's bandwidth again :-) Eric Sandeen wrote: > On Sat, 2002-06-29 at 03:40, Eric Mei wrote: > >>Hi Team, >> >>This is a long report. I know some of you might be busy on kernel >>summit, we just can's believe XFS has such a serious bug. > > > s/has/had/ > > >>For some reason, we must stick on 2.4.5-xfs-1.0.1. > > > You're essentially saying that you must stick with old, (apparently) > buggy code. We simply don't have the bandwidth to support xfs & kernel > code from 1 year ago. > > Your best bet would be to look through the mailing list archives to see > if anyone has had a similar problem, and see if a mod was checked in to > fix it; then try to backport that fix. > > http://oss.sgi.com/projects/xfs/mail_archive/200108/msg00307.html > > This thread makes it sound like it may well be an underlying kernel > problem with 2.4.5-era kernels. > > -Eric From owner-linux-xfs@oss.sgi.com Sat Jun 29 09:57:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5TGvmnC006076 for ; Sat, 29 Jun 2002 09:57:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5TGvmZx006075 for linux-xfs-outgoing; Sat, 29 Jun 2002 09:57:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sgi.com (sgi-too.SGI.COM [204.94.211.39]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5TGvcnC006047 for ; Sat, 29 Jun 2002 09:57:38 -0700 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) 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 KAA05226 for ; Sat, 29 Jun 2002 10:01:38 -0700 (PDT) mail_from (waltabbyh@mindspring.com) Received: from user-2iniaah.dialup.mindspring.com ([165.121.41.81] helo=waltsathlon.localhost.net) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 17OLRg-0004iA-00 for linux-xfs@oss.sgi.com; Sat, 29 Jun 2002 12:51:36 -0400 Received: from mindspring.com (localhost.localdomain [127.0.0.1]) by waltsathlon.localhost.net (Postfix) with ESMTP id D5EF8EAF489; Sat, 29 Jun 2002 09:50:50 -0700 (PDT) Message-ID: <3D1DE56A.50001@mindspring.com> Date: Sat, 29 Jun 2002 09:50:50 -0700 From: Walt H User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1a) Gecko/20020618 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Mei Cc: linux-xfs@oss.sgi.com Subject: Re: Bug about XFS-1.0.1 on 2.4.5 References: <3D1D647F.3070302@mountainviewdata.com> <1025365517.20112.18.camel@Liberator> <3D1DDC5E.1010403@mountainviewdata.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric, There were many VM issues all the way up to the current kernels IMHO. However, the most recent stable kernel, 2.4.18, seems to work quite well. I've got a couple of servers at work running 2.4.18 with no problems. One of them with over 100 days of continuous uptime running on XFS that's used as a samba/netatalk fileserver for 25+ clients, DNS, DHCP and squid proxy server. So far, it's been solid. The Linux VM was completely redone in 2.4.10 and took a few kernel releases after that to really settle down. 2.4.18 seems to be the first really solid 2.4 series kernel for me. Hope that helps, -Walt Eric Mei wrote: > Thanks a lot! > > As you know, if we try to backport vm fixes to 2.4.5, which kernel have > most probably addressed this issue? 2.4.7? There is no evidence about it > from kenrel ChangeLog. > > Sorry to occupy XFS's bandwidth again :-) > > > Eric Sandeen wrote: > >>On Sat, 2002-06-29 at 03:40, Eric Mei wrote: >> >> >>>Hi Team, >>> >>>This is a long report. I know some of you might be busy on kernel >>>summit, we just can's believe XFS has such a serious bug. >> >> >>s/has/had/ >> >> >> >>>For some reason, we must stick on 2.4.5-xfs-1.0.1. >> >> >>You're essentially saying that you must stick with old, (apparently) >>buggy code. We simply don't have the bandwidth to support xfs & kernel >>code from 1 year ago. >> >>Your best bet would be to look through the mailing list archives to see >>if anyone has had a similar problem, and see if a mod was checked in to >>fix it; then try to backport that fix. >> >>http://oss.sgi.com/projects/xfs/mail_archive/200108/msg00307.html >> >>This thread makes it sound like it may well be an underlying kernel >>problem with 2.4.5-era kernels. >> >>-Eric > > From owner-linux-xfs@oss.sgi.com Sat Jun 29 12:57:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5TJvhnC007731 for ; Sat, 29 Jun 2002 12:57:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5TJvh7o007730 for linux-xfs-outgoing; Sat, 29 Jun 2002 12:57:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ns.caxopen.de (IDENT:root@caxopen-gw.caxopen.com [194.55.1.251]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5TJvTnC007700 for ; Sat, 29 Jun 2002 12:57:30 -0700 Received: from caxopen.de (Jeb/faFcqdJK6H4alebya8RkANsEXEoq@minos.intern.net [192.168.1.28]) by ns.caxopen.de (8.8.7/8.8.7) with ESMTP id WAA01329 for ; Sat, 29 Jun 2002 22:01:46 +0200 Message-ID: <3D1E1206.5080405@caxopen.de> Date: Sat, 29 Jun 2002 22:01:10 +0200 From: Andreas Korn Reply-To: korn@caxopen.de Organization: CAxOPEN GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020606 X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: kernel oops Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just had a kernel oops and maybe it is caused by xfs. It's a small PC used as fileserver with nfs, samba and some more services. The OS is Redhat linux 7.3 with the XFS-installer and the kernel from this installer. uname says: 2.4.18-4SGI_XFS_1.1 If anyone has an idea what the real problem is and if I can fix it with a newer kernel, please tell me. I appended the /var/log/messages entry from the crash. ------------------------------------------------------------------------------------------------------------------------------------ Jun 29 21:16:52 earth kernel: Unable to handle kernel paging request at virtual address 00001130 Jun 29 21:16:52 earth kernel: printing eip: Jun 29 21:16:52 earth kernel: c01c8544 Jun 29 21:16:52 earth kernel: *pde = 00000000 Jun 29 21:16:52 earth kernel: Oops: 0002 Jun 29 21:16:52 earth kernel: nfsd lockd sunrpc 8139too mii gdth sd_mod scsi_mod Jun 29 21:16:52 earth kernel: CPU: 0 Jun 29 21:16:52 earth kernel: EIP: 0010:[] Not tainted Jun 29 21:16:52 earth kernel: EFLAGS: 00010202 Jun 29 21:16:52 earth kernel: Jun 29 21:16:52 earth kernel: EIP is at _mutex_lock [kernel] 0x4 (2.4.18-4SGI_XFS_1.1) Jun 29 21:16:52 earth kernel: eax: 00001000 ebx: 00001000 ecx: 0000111c edx: 00001000 Jun 29 21:16:52 earth kernel: esi: cc601e30 edi: cc601e30 ebp: 00000000 esp: c1371e84 Jun 29 21:16:52 earth kernel: ds: 0018 es: 0018 ss: 0018 Jun 29 21:16:52 earth kernel: Process kswapd (pid: 5, stackpage=c1371000) Jun 29 21:16:52 earth kernel: Stack: c01638f7 0000111c cc601e30 c0167592 00001000 cc601e30 c019d128 cc601e30 Jun 29 21:16:52 earth kernel: 00000001 c01b8df4 cc601e30 cc601e30 c5219364 00000000 c01b8cb9 cc601e30 Jun 29 21:16:52 earth kernel: 00000000 00000000 c5219364 00000000 c5219364 c5219364 c01c69db cc601e48 Jun 29 21:16:52 earth kernel: Call Trace: [] xfs_qm_dqrele [kernel] 0xb Jun 29 21:16:52 earth kernel: [] xfs_qm_dqdettach_inode [kernel] 0x12 Jun 29 21:16:52 earth kernel: [] xfs_ireclaim [kernel] 0x30 Jun 29 21:16:52 earth kernel: [] xfs_finish_reclaim [kernel] 0x118 Jun 29 21:16:52 earth kernel: [] xfs_reclaim [kernel] 0x1c1 Jun 29 21:16:52 earth kernel: [] vn_reclaim [kernel] 0x1f Jun 29 21:16:52 earth kernel: [] vn_purge [kernel] 0x78 Jun 29 21:16:52 earth kernel: [] vn_remove [kernel] 0x43 Jun 29 21:16:52 earth kernel: [] schedule [kernel] 0x1ec Jun 29 21:16:52 earth kernel: [] linvfs_clear_inode [kernel] 0x9 Jun 29 21:16:52 earth kernel: [] clear_inode [kernel] 0xca Jun 29 21:16:52 earth kernel: [] destroy_inode [kernel] 0x2c Jun 29 21:16:52 earth kernel: [] dispose_list [kernel] 0x54 Jun 29 21:16:52 earth kernel: [] prune_icache [kernel] 0x123 Jun 29 21:16:52 earth kernel: [] shrink_icache_memory [kernel] 0x20 Jun 29 21:16:52 earth kernel: [] do_try_to_free_pages [kernel] 0x24 Jun 29 21:16:52 earth kernel: [] kswapd [kernel] 0xf8 Jun 29 21:16:52 earth kernel: [] stext [kernel] 0x0 Jun 29 21:16:52 earth kernel: [] kernel_thread [kernel] 0x26 Jun 29 21:16:52 earth kernel: [] kswapd [kernel] 0x0 Jun 29 21:16:52 earth kernel: Jun 29 21:16:52 earth kernel: Jun 29 21:16:52 earth kernel: Code: ff 49 14 ff 09 78 28 c3 8b 4c 24 04 ff 41 14 ff 01 7e 23 c3 ------------------------------------------------------------------------------------------------------------------------------------- Thanks Andreas From owner-linux-xfs@oss.sgi.com Sat Jun 29 23:52:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g5U6qDnC012049 for ; Sat, 29 Jun 2002 23:52:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g5U6qCLL012048 for linux-xfs-outgoing; Sat, 29 Jun 2002 23:52:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ids.org.au (ids.tuu.utas.edu.au [131.217.24.100]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g5U6q5nC012020 for ; Sat, 29 Jun 2002 23:52:06 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 7FBC5C3EE89; Sun, 30 Jun 2002 16:55:43 +1000 (EST) Date: Sun, 30 Jun 2002 16:55:43 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: patch file corrupt? Message-ID: <20020630065543.GA28541@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I just tried to apply this patch to my 2.4.18 tree: ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18/xfs-2.4.18-all-i386.bz2 After extracting the patch, it seems that the diff had "line wrapping" applied to it. It won't patch, because lines longer than 72 characters have had carriage returns inserted into it, and patch breaks as a result. I had a copy of the patch on another machine from a few months ago, and that works fine. I pretty sure that i didnt do anything stupid to the patch (I downloaded it again to make sure), so perhaps someone wants to check this? cheers, Ian. -- Ian Cumming, ian@semisphere.org "The number of Unix installations has grown to 10, with more expected." -- The Unix Programmer's Manual, 2nd Edition, June, 1972 From owner-linux-xfs@oss.sgi.com Sun Jun 30 18:08:44 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g6118inC030890 for ; Sun, 30 Jun 2002 18:08:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g6118hOS030889 for linux-xfs-outgoing; Sun, 30 Jun 2002 18:08:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g6118cnC030858 for ; Sun, 30 Jun 2002 18:08:38 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id SAA09433 for ; Sun, 30 Jun 2002 18:12:02 -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 LAA46046 for linux-xfs@oss.sgi.com; Mon, 1 Jul 2002 11:10:16 +1000 (EST) Date: Mon, 1 Jul 2002 11:10:16 +1000 (EST) From: Nathan Scott Message-Id: <200207010110.LAA46046@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - kdev_val X-Spam-Status: No, hits=1.3 required=5.0 tests=MAY_BE_FORGED version=2.20 X-Spam-Level: * Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Sun Jun 30 18:09:33 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/2.4.x-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:122586a linux/include/linux/kdev_t.h - 1.7 - add missing brace to kdev_val() - assume this will get picked up by Marcelo before 2.4.19-final... linux/fs/xfs/linux/xfs_linux.h - 1.74 linux/fs/xfs/pagebuf/page_buf_internal.h - 1.9 - make our kdev_val() 2.5 compat macro dependent on kernel version as 2.4.19 looks like it will have a kdev_val now. this fixes up some warnings introduced in the 2.4.19-rc1 merge. From owner-linux-xfs@oss.sgi.com Sun Jun 30 19:51:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g612p4nC003958 for ; Sun, 30 Jun 2002 19:51:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g612p4PC003957 for linux-xfs-outgoing; Sun, 30 Jun 2002 19:51:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.SGI.COM [204.94.214.10] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g612ownC003929 for ; Sun, 30 Jun 2002 19:50:58 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via ESMTP id TAA09927 for ; Sun, 30 Jun 2002 19:54:47 -0700 (PDT) mail_from (kaos@sgi.com) Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.12.3/8.11.4/nodin-1.0) with ESMTP id g611cEEd12088395; Sun, 30 Jun 2002 18:38:15 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id C8A153000BA; Mon, 1 Jul 2002 11:38:13 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id A095BA0; Mon, 1 Jul 2002 11:38:13 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ian Cumming Cc: linux-xfs@oss.sgi.com Subject: Re: patch file corrupt? In-reply-to: Your message of "Sun, 30 Jun 2002 16:55:43 +1000." <20020630065543.GA28541@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 01 Jul 2002 11:38:08 +1000 Message-ID: <20667.1025487488@kao2.melbourne.sgi.com> X-Spam-Status: No, hits=-3.2 required=5.0 tests=IN_REP_TO,SUBJ_ENDS_IN_Q_MARK,MAY_BE_FORGED version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 30 Jun 2002 16:55:43 +1000, Ian Cumming wrote: >I just tried to apply this patch to my 2.4.18 tree: >ftp://oss.sgi.com/projects/xfs/download/patches/2.4.18/xfs-2.4.18-all-i386.bz2 > >After extracting the patch, it seems that the diff had "line wrapping" >applied to it. It won't patch, because lines longer than 72 characters >have had carriage returns inserted into it, and patch breaks as a >result. I just checked that patch, it is fine and it patches cleanly against a pristine 2.4.18 tree. md5sums 0411a3921a553c8566f8dc1770f5bf34 xfs-2.4.18-all-i386.bz2 f154a5ad3376cf54095cb158e5f54338 xfs-2.4.18-all-i386