From owner-linux-xfs@oss.sgi.com Mon Apr 1 00:33:33 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g318XXU26350 for linux-xfs-outgoing; Mon, 1 Apr 2002 00:33:33 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g318XAv26313 for ; Mon, 1 Apr 2002 00:33:10 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g318WP6G023492 for ; Mon, 1 Apr 2002 00:32:26 -0800 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA19905; Mon, 1 Apr 2002 18:31:07 +1000 (EST) Date: Mon, 1 Apr 2002 18:31:07 +1000 (EST) From: Nathan Scott Message-Id: <200204010831.SAA19905@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - acl man pages Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 1 00:28:34 PST 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:115268a acl/include/builddefs.in - 1.16 attr/include/builddefs.in - 1.14 - fix INSTALL_MAN macro so that mandoc style man pages are grokked also. acl/man/man3/acl_free.3 - 1.7 acl/man/man3/acl_size.3 - 1.6 acl/man/man3/acl_copy_ext.3 - 1.6 acl/man/man3/acl_from_text.3 - 1.7 acl/man/man3/acl_get_file.3 - 1.7 acl/man/man3/acl_delete_def_file.3 - 1.6 acl/man/man3/acl_get_fd.3 - 1.7 acl/man/man3/acl_valid.3 - 1.6 acl/man/man3/acl_dup.3 - 1.6 acl/man/man3/acl_delete_perm.3 - 1.2 acl/man/man3/acl_to_text.3 - 1.2 acl/man/man3/acl_to_any_text.3 - 1.2 acl/man/man3/acl_set_tag_type.3 - 1.2 acl/man/man3/acl_set_qualifier.3 - 1.2 acl/man/man3/acl_set_permset.3 - 1.2 acl/man/man3/acl_set_file.3 - 1.2 acl/man/man3/acl_set_fd.3 - 1.2 acl/man/man3/acl_init.3 - 1.2 acl/man/man3/acl_get_tag_type.3 - 1.2 acl/man/man3/acl_get_qualifier.3 - 1.2 acl/man/man3/acl_get_permset.3 - 1.2 acl/man/man3/acl_get_perm.3 - 1.2 acl/man/man3/acl_get_entry.3 - 1.2 acl/man/man3/acl_from_mode.3 - 1.2 acl/man/man3/acl_extended_file.3 - 1.2 acl/man/man3/acl_add_perm.3 - 1.2 acl/man/man3/acl_calc_mask.3 - 1.2 acl/man/man3/acl_check.3 - 1.2 acl/man/man3/acl_clear_perms.3 - 1.2 acl/man/man3/acl_cmp.3 - 1.2 acl/man/man3/acl_copy_entry.3 - 1.2 acl/man/man3/acl_extended_fd.3 - 1.2 acl/man/man3/acl_copy_int.3 - 1.2 acl/man/man3/acl_create_entry.3 - 1.2 acl/man/man3/acl_error.3 - 1.2 acl/man/man3/acl_delete_entry.3 - 1.2 acl/man/man3/acl_equiv_mode.3 - 1.2 acl/man/man3/acl_entries.3 - 1.2 acl/man/man5/acl.5 - 1.12 - revert to mandoc style man pages, fixed the INSTALL_MAN macro instead of reformatting the man source. From owner-linux-xfs@oss.sgi.com Mon Apr 1 04:21:53 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31CLrS29549 for linux-xfs-outgoing; Mon, 1 Apr 2002 04:21:53 -0800 Received: from mta06bw.bigpond.com (mta06bw.bigpond.com [139.134.6.96]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31CLVv29523 for ; Mon, 1 Apr 2002 04:21:31 -0800 Message-Id: <200204011221.g31CLVv29523@oss.sgi.com> Received: from there ([144.135.24.78]) by mta06bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GTW2AL00.GEP for ; Mon, 1 Apr 2002 22:20:45 +1000 Received: from CPE-144-137-136-216.qld.bigpond.net.au ([144.137.136.216]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0i 35/174115); 01 Apr 2002 22:20:45 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Linux XFS Mailing List Subject: Decrease in ability to handle heavy I/O between CVS 16/3 & 29/3 Date: Mon, 1 Apr 2002 22:20:37 +1000 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk First off - I hope everyone had a good Easter break if you follow Easter in your part of the world. The Easter break allowed me to catch up on a bit of testing of XFS & LVM that I hadn't had time for over the last couple of weeks What I found was that with a minor modification to a LVM patch the combination of 2.4.18-xfs CVS & LVM-1.1rc1 seem more stable now than 5-7 weeks ago with regard to general usage including snapshots. My LVM test script actually completes without taking down the box. Previously I was able to run the LVM test by hand but if I used a script the machine would go belly-up. After quite a few runs of the test script - this seems to be no longer the case. I will be continuing to test this under different circumstances in the future to make sure. However I have noticed a huge reduction in the ability of 2.4.18-xfs CVS to handle very high I/O loads. Another test I run is using many background `cp` processes to copy a 266M directory across a volume. The XFS CVS of the 20020316-1356 EST (+10hrs from UTC) can handle without problems 100 background `cp` processes - the test takes 14+hrs but the machine emerges from the test still standing. Whereas the XFS CVS of the 20020329-1644 EST does not survive even 80 background `cp` processes. (40 completes - 60 is currently in test) After reading the mailing list I have seen many posts between the 16th March and the 29th March regarding changing the memory handling of XFS. The following links are some of the major ones I found: http://marc.theaimsgroup.com/?l=linux-xfs&m=101655982111751&w=2 http://marc.theaimsgroup.com/?l=linux-xfs&m=101665141802936&w=2 http://marc.theaimsgroup.com/?l=linux-xfs&m=101734523225131&w=2 How can I help in tracking down which change modified the heavy I/O behaviour? and what can I do to help fix it? What further information do people need/want? On a positive note it appears that the deleting of large amounts of data is much faster with the XFS CVS of the 20020329-1644 EST. I do not have actual times but it suprised me - I went to get a coffee and it was finished when I got back - that never happened before. Thanks for those that improved this part of XFS. An example of the test script: # ==== High I/O test script ==== #!/bin/sh cp -fr 01 2 for (( i=80; i!=2; i-- )) ; do cp -fr 01 $i & # echo $i done -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Mon Apr 1 07:03:04 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31F34032724 for linux-xfs-outgoing; Mon, 1 Apr 2002 07:03:04 -0800 Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31F2lv32693 for ; Mon, 1 Apr 2002 07:02:47 -0800 Received: from Francis ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g319teW05911; Mon, 1 Apr 2002 09:55:40 GMT Message-ID: <007301c1d98e$30f54b90$8d02a8c0@consensys.com> From: "Francis Qu" To: "Dean Roehrich" Cc: "Linux XFS" References: <200203221855.MAA14972@slobber.americas.sgi.com> Subject: Re: DMAPI Attribute Event and Append Date: Mon, 1 Apr 2002 10:02:06 -0500 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 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I tried to modify the source as you suggested and rebuilt the kernel. But it didn't work. It appeared just as before. An append to the end of a file doesn't trigger an attribute event. I used two test case: 1. open a file with append (O_APPEND) and write(2). 2. $ cat >> filename Francis ----- Original Message ----- From: "Dean Roehrich" To: "Francis Qu" Cc: "Linux XFS" Sent: Friday, March 22, 2002 1:55 PM Subject: Re: DMAPI Attribute Event and Append > > >From: "Francis Qu" > >Hi Dean, > > > >When appending data to the end of a file, the file modification time and > >change time are updated. But this operation cannot be caught as an attribute > >event. Do you have any idea about it? > > My guess is that we're getting out early in xfs_setattr(), before the > DM_EVENT_ATTRIBUTE is generated. > > At the end of xfs_setattr() you'll find a dm_send_namesp_event() and its > corresponding if-wrapper. Put a copy of that if-block earlier in > xfs_setattr(), inside the "if (mask & AT_UPDTIMES)" conditional. > > Let me know if that has anything to do with what you're seeing. > > Dean From owner-linux-xfs@oss.sgi.com Mon Apr 1 07:10:38 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31FAch00498 for linux-xfs-outgoing; Mon, 1 Apr 2002 07:10:38 -0800 Received: from imf06bis.bellsouth.net (mail106.mail.bellsouth.net [205.152.58.46]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31FA6v00450 for ; Mon, 1 Apr 2002 07:10:06 -0800 Received: from taz ([65.81.169.166]) by imf06bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020401151042.LRWT24294.imf06bis.bellsouth.net@taz>; Mon, 1 Apr 2002 10:10:42 -0500 Date: Mon, 1 Apr 2002 10:00:49 -0500 From: Greg Freemyer Subject: re[2]: XFS and kernel 2.4.18 To: James A Goodwin , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020401151042.LRWT24294.imf06bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g31FA7v00451 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk James, I'm just an observer on this list, but I've been trying to make the same decision you are. Someone on the XFS team stated during Feb. that they hope to get the next release of XFS out by the end of March. They obviously missed that, but they have put out XFS 1.1 pre-release 2 on Mar. 21. It seems to have lots of fixes relative to 1.0.2. If you can stand to wait a while longer, you might want to wait for that to be released. I'm planning on waiting, but my target is to have something ready by June. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com >> We are going to release a product that will have a certain release of XFS >> as a prerequisite, so we have to support a fixed version. As far as I can >> tell, 1.0.2 is the latest release, so we're going with it. If that >> dictates that we have to stay with kernel 2.4.14, so be it. If not, I'd >> really like to move on up to 2.4.18. >> So, I guess my real questions are: >> a) Is 1.0.2 that latest release of XFS? >> b) What is the latest kernel that I can use with the latest XFS >> release? >> c) If it's not kernel 2.4.14, then how to I upgrade? >> 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 >> >> >> Steve Lord >> >> To: James A >> Goodwin/Houston/IBM@IBMUS >> cc: >> linux-xfs@oss.sgi.com >> >> 03/29/2002 12:49 Subject: Re: XFS and >> kernel 2.4.18 >> PM >> >> >> >> >> >> On Fri, 2002-03-29 at 12:47, James A Goodwin wrote: >> > I'd like to create a 2.4.18 kernel with XFS 1.0.2 support, but all the >> > migration paths for 1.0.2 that I've seen end with a 2.4.14 kernel. Is >> > there any way to get this to 2.4.18? >> Money? ;-) >> You really want the old code base? >> Steve >> -- >> Steve Lord voice: +1-651-683-3511 >> Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Mon Apr 1 08:02:49 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id g31FwOr00882 for linux-xfs-outgoing; Mon, 1 Apr 2002 07:58:24 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id g31FwIS00844 for ; Mon, 1 Apr 2002 07:58:18 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g31H6Tkw000733 for ; Mon, 1 Apr 2002 11:06:29 -0600 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 JAA43086 for ; Mon, 1 Apr 2002 09:57:33 -0600 (CST) Received: from sgi.com (da+nrwnAuJYiwGrB+Gh1BUxY4YvIySKv@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA82482 for ; Mon, 1 Apr 2002 09:57:33 -0600 (CST) Message-ID: <3CA883C5.5060906@sgi.com> Date: Mon, 01 Apr 2002 09:59:01 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: oss.sgi.com is moving Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Just so people are aware this is coming, I expect the usual breakage as dns slowly sorts itself out. Steve -------- Original Message -------- This is to notify all users of oss.sgi.com that we will be moving all co-location servers from Exodus Datacenter to a new location -- Genuity. This will take place between 5:00pm PST - 12:00am PST on Friday April 5th. This system will be unavailable during this time. There will also be DNS changes so there may be a wait period while new DNS entries are propagated world wide. Sorry for the inconvenience this may impose. Regards, DCO -- Mountain View Data Center Services From owner-linux-xfs@oss.sgi.com Mon Apr 1 14:55:01 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31Mt1W03155 for linux-xfs-outgoing; Mon, 1 Apr 2002 14:55:01 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31Msqo03119 for ; Mon, 1 Apr 2002 14:54:52 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g31Msl6G024260 for ; Mon, 1 Apr 2002 14:54:47 -0800 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA98988 for ; Mon, 1 Apr 2002 16:54:47 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA58054; Mon, 1 Apr 2002 16:54:46 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g31MskZ18432; Mon, 1 Apr 2002 16:54:46 -0600 Message-Id: <200204012254.g31MskZ18432@stout.americas.sgi.com> Date: Mon, 1 Apr 2002 16:54:46 -0600 From: Eric Sandeen Subject: TAKE - Optimize endian code when setting / testing 0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Lots of xfs code does endian-flipping of on-disk data, but in the case where we're setting to zero or testing for zero, endian-flipping is a waste of time. There are stock macros for this: INT_ZERO and INT_ISZERO, they just do "= 0" and "== 0" respectively. So, where used to do INT_SET(var, ARCH_CONVERT, 0) now we do INT_ZERO(var, ARCH_CONVERT) and we don't endian-flip the zero. Same for if (INT_GET(var, ARCH_CONVERT) == 0) changed to if (INT_ISZERO(var, ARCH_CONVERT)) so we don't flip "var" before testing whether it's zero. Doing these via the macros is good, because it points out that in general, these variables still need endian care. This change should shrink the size of xfs a fair amount (I think I saw ~20k on my fully-loaded xfs.o) and may even speed up the code a bit. A few more changes in this respect coming tomorrow... This mod also touches a LOT of lines, so if odd things start happening... shout. :) -Eric Date: Mon Apr 1 14:46:06 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/2.4.x-xfs/workarea-endian The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:115339a linux/fs/xfs/xfs_trans_dquot.c - 1.34 linux/fs/xfs/xfsidbg.c - 1.179 linux/fs/xfs/xfs_quota_priv.h - 1.20 linux/fs/xfs/xfs_ialloc.c - 1.152 linux/fs/xfs/xfs_da_btree.c - 1.125 linux/fs/xfs/xfs_dir2_block.c - 1.22 linux/fs/xfs/xfs_qm_syscalls.c - 1.57 linux/fs/xfs/xfs_dquot.c - 1.60 linux/fs/xfs/xfs_dir_leaf.c - 1.99 linux/fs/xfs/xfs_btree.c - 1.96 linux/fs/xfs/xfs_dir2_data.c - 1.16 linux/fs/xfs/xfs_inode.c - 1.332 linux/fs/xfs/xfs_dir2_leaf.c - 1.25 linux/fs/xfs/xfs_attr_leaf.c - 1.57 linux/fs/xfs/xfs_alloc.c - 1.148 linux/fs/xfs/xfs_fsops.c - 1.74 linux/fs/xfs/xfs_dir2_node.c - 1.22 linux/fs/xfs/xfs_attr.c - 1.89 linux/fs/xfs/xfs_dinode.h - 1.59 - Optimize endian flipping code when setting to or testing for zero Use INT_ZERO and INT_ISZERO instead of INT_SET and INT_GET From owner-linux-xfs@oss.sgi.com Mon Apr 1 15:01:02 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31N12P03541 for linux-xfs-outgoing; Mon, 1 Apr 2002 15:01:02 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31N0io03503 for ; Mon, 1 Apr 2002 15:00:44 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with SMTP id g3209Ykw006376 for ; Mon, 1 Apr 2002 18:09:35 -0600 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 IAA09468; Tue, 2 Apr 2002 08:59:16 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA69818; Tue, 2 Apr 2002 08:59:13 +1000 (AEST) Date: Tue, 2 Apr 2002 08:59:12 +1000 From: Nathan Scott To: Adrian Head Cc: Jan Kara , Bas , linux-xfs@oss.sgi.com, linux-lvm@sistina.com Subject: Re: DQUOT_SYNC undefined in XFS CVS kernel (was: Can't build CVS kernels of 20020321 & 20020327) Message-ID: <20020402085912.G52863@wobbly.melbourne.sgi.com> References: <004a01c1d56b$cae7cb50$3b00a8c0@aplabwp0368359> <20020328083015.G47866@wobbly.melbourne.sgi.com> <200203291222.EAA25283@deliverator.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: <200203291222.EAA25283@deliverator.sgi.com>; from ahead@bigpond.net.au on Fri, Mar 29, 2002 at 10:26:41PM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Mar 29, 2002 at 10:26:41PM +1000, Adrian Head wrote: > I have also run into the XFS CVS kernel compile failing because of an > undefined DQUOT_SYNC. > > Using the information given by Nathan I have tracked down the offending patch > that causes the problems. In my case it was the LVM VFS-lock patch from the > Sistina LVM project. What they seem to do is use DQUOT_SYNC to force the > writing of cached Quota infomation before they lock the VFS during snapshot > creation. It would also seem that EVMS does the same thing. Aha, thanks for tracking this down Adrian. > I expect that the XFS CVS kernel tree is actually ahead of the standard > 2.4.18 kernel tree in this respect so we'll have to wait until 2.4.19 is > released with the updated API's before other projects update their kernel > patches. Yes, the XFS trees contain all of the quota patches from: ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/ I wouldn't expect these patches to be in 2.4.19 -- they are not in 2.5 yet and I think Jan is concentrating on that step first. > Grep'ing through the kernel I have not been able to find any comments or > explanations regarding this - so I have assumed that DQUOT_SYNC can be > changed to DQUOT_SYNC_DEV without problems. Yes, by my understanding of the VFS quota subsystem that would be the correct thing to do. > After making that change the kernel compiles cleanly and boots. I'm unsure > as yet if I have done the correct thing here. Hopefuly someone will be able > to help us out and correct me if I'm incorrect. I believe your change is correct, I've CC'd Jan in case there is anything that I've overlooked. cheers. > The offending part of the VF-lock patch follows below: > > Index: linus.21/fs/buffer.c > --- linus.21/fs/buffer.c Mon, 28 Jan 2002 09:51:50 -0500 root > (linux/i/45_buffer.c 1.5.2.6 644) > +++ linus.21(w)/fs/buffer.c Mon, 28 Jan 2002 11:54:36 -0500 root > (linux/i/45_buffer.c 1.5.2.6 644) > @@ -361,6 +361,34 @@ > fsync_dev(dev); > } > > +int fsync_dev_lockfs(kdev_t dev) > +{ > + /* 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. > + */ > + if (!dev) > + return fsync_dev(dev) ; > + > + sync_buffers(dev, 0); > + > + lock_kernel(); > + /* note, the FS might need to start transactions to > + ** sync the inodes, or the quota, no locking until > + ** after these are done > + */ > + sync_inodes(dev); > + DQUOT_SYNC(dev); > ^<==== ****All I did was to change this to DQUOT_SYNC_DEV(dev);**** > + /* if inodes or quotas could be dirtied during the > + ** sync_supers_lockfs call, the FS is responsible for getting > + ** them on disk, without deadlocking against the lock > + */ > + sync_supers_lockfs(dev) ; > + unlock_kernel(); > + > + return sync_buffers(dev, 1) ; > +} > + > asmlinkage long sys_sync(void) > { > fsync_dev(0); > > > On Thu, 28 Mar 2002 07:30, Nathan Scott wrote: > > Hello, > > > > On Wed, Mar 27, 2002 at 09:45:48AM +0100, Bas wrote: > > > Hi, > > > > > > It's not possible for me to build the kernel mentioned above. I saw the > > > new qouta options and suspect it has something to do with it, but I'm not > > > sure. > > > > > > Building everything goes fine, but at the end of the run it's not able to > > > produce a kernel because of DQUOT_SYNC. I don't have the exact error > > > here. > > > > Hmm... 20020327 - that's yesterday. DQUOT_SYNC doesn't appear in > > the source at all anymore (for awhile now), so I suspect the problem > > must be at your end. Try getting a fresh CVS copy and/or "make clean". > > [ The other patches you mentioned should not have anything to do with > > this problem. ] > > > > $ find . -type f | xargs fgrep DQUOT_SYNC > > ./fs/buffer.c: DQUOT_SYNC_SB(sb); > > ./fs/buffer.c: DQUOT_SYNC_DEV(dev); > > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) > > sync_dquots_dev(dev, -1) ./include/linux/quotaops.h:#define > > DQUOT_SYNC_SB(sb) sync_dquots_sb(sb, -1) > > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) do > > { } while(0) ./include/linux/quotaops.h:#define DQUOT_SYNC_SB(sb) > > do { } while(0) $ > > > > FWIW, DQUOT_SYNC used to come from include/linux/quotaops.h > > too, and its definition was also dependent on CONFIG_QUOTA. > > The reason you'd be getting an unresolved symbol would be a > > file referencing DQUOT_SYNC wasn't #include'ing quotaops.h; > > but thats all by-the-by - the real problem is related to the > > source you're using I suspect - it certainly doesn't match > > CVS of yesterday. > > > > cheers. > > -- > Adrian Head > > (Public Key available on request.) -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 1 15:25:31 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31NPVq04364 for linux-xfs-outgoing; Mon, 1 Apr 2002 15:25:31 -0800 Received: from mta05bw.bigpond.com (mta05bw.bigpond.com [139.134.6.95]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31NPNo04338 for ; Mon, 1 Apr 2002 15:25:23 -0800 Message-Id: <200204012325.g31NPNo04338@oss.sgi.com> Received: from there ([144.135.24.84]) by mta05bw.bigpond.com (Netscape Messaging Server 4.15) with SMTP id GTWX2300.JOO; Tue, 2 Apr 2002 09:25:15 +1000 Received: from CPE-144-137-136-216.qld.bigpond.net.au ([144.137.136.216]) by bwmam06.mailsvc.email.bigpond.com(MailRouter V3.0i 53/2154469); 02 Apr 2002 09:25:15 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Nathan Scott Subject: Re: DQUOT_SYNC undefined in XFS CVS kernel (was: Can't build CVS kernels of 20020321 & 20020327) Date: Tue, 2 Apr 2002 09:25:10 +1000 X-Mailer: KMail [version 1.3.1] Cc: Jan Kara , Bas , linux-xfs@oss.sgi.com, linux-lvm@sistina.com References: <004a01c1d56b$cae7cb50$3b00a8c0@aplabwp0368359> <200203291222.EAA25283@deliverator.sgi.com> <20020402085912.G52863@wobbly.melbourne.sgi.com> In-Reply-To: <20020402085912.G52863@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2 Apr 2002 08:59, Nathan Scott wrote: > On Fri, Mar 29, 2002 at 10:26:41PM +1000, Adrian Head wrote: > > I have also run into the XFS CVS kernel compile failing because of an > > undefined DQUOT_SYNC. > > > > Using the information given by Nathan I have tracked down the offending > > patch that causes the problems. In my case it was the LVM VFS-lock patch > > from the Sistina LVM project. What they seem to do is use DQUOT_SYNC to > > force the writing of cached Quota infomation before they lock the VFS > > during snapshot creation. It would also seem that EVMS does the same > > thing. > > Aha, thanks for tracking this down Adrian. No worries - thanks for the original info that got me started in the correct direction. > > > I expect that the XFS CVS kernel tree is actually ahead of the standard > > 2.4.18 kernel tree in this respect so we'll have to wait until 2.4.19 is > > released with the updated API's before other projects update their kernel > > patches. > > Yes, the XFS trees contain all of the quota patches from: > ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/ > > I wouldn't expect these patches to be in 2.4.19 -- they are > not in 2.5 yet and I think Jan is concentrating on that step > first. Fine - as I would expect. > > > Grep'ing through the kernel I have not been able to find any comments or > > explanations regarding this - so I have assumed that DQUOT_SYNC can be > > changed to DQUOT_SYNC_DEV without problems. > > Yes, by my understanding of the VFS quota subsystem that would > be the correct thing to do. Thanks - my concern at the time was whether DQUOT_SYNC_SB should be included as well. I had difficulty tracing it through so I took the easier way and assumed that it wasn't needed. ;-) > > > After making that change the kernel compiles cleanly and boots. I'm > > unsure as yet if I have done the correct thing here. Hopefuly someone > > will be able to help us out and correct me if I'm incorrect. > > I believe your change is correct, I've CC'd Jan in case there is > anything that I've overlooked. Thanks Nathan & Jan - if I don't get any feedback I will assume that everything is OK and I will post patches to the LVM list latter today explaining & fixing the issue with their VFS-lock patch. > > cheers. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Mon Apr 1 15:48:22 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31NmMF05254 for linux-xfs-outgoing; Mon, 1 Apr 2002 15:48:22 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31NmJo05220 for ; Mon, 1 Apr 2002 15:48:19 -0800 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g31MX5kw005357 for ; Mon, 1 Apr 2002 16:33:05 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA48343 for ; Mon, 1 Apr 2002 15:24:08 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA45772; Mon, 1 Apr 2002 15:24:07 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g31LO7L08618; Mon, 1 Apr 2002 15:24:07 -0600 Message-Id: <200204012124.g31LO7L08618@stout.americas.sgi.com> Date: Mon, 1 Apr 2002 15:24:07 -0600 From: Eric Sandeen Subject: TAKE - fix endian optimization Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve got a little carried away w/ the last optimization here, using a pre-flipped value in a wrong spot. Date: Mon Apr 1 13:22:14 PST 2002 Workarea: stout.americas.sgi.com:/localhome/eric/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:115318a linux/fs/xfs/xfs_da_btree.c - 1.124 - endian optimization of pre-converting some variables got a little carried away magic1 is for data->hdr.magic, not free->hdr.magic From owner-linux-xfs@oss.sgi.com Mon Apr 1 15:48:16 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g31NmGt05205 for linux-xfs-outgoing; Mon, 1 Apr 2002 15:48:16 -0800 Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g31NmDo05178 for ; Mon, 1 Apr 2002 15:48:13 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g31Mt4kw005671 for ; Mon, 1 Apr 2002 16:55:04 -0600 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id HAA53262 for linux-xfs@oss.sgi.com; Tue, 2 Apr 2002 07:44:50 +1000 (EST) Date: Tue, 2 Apr 2002 07:44:50 +1000 (EST) From: Nathan Scott Message-Id: <200204012144.HAA53262@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - dmapi build Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 1 13:44:24 PST 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:115326a dmapi/include/buildrules - 1.4 - use LTLIBS instead of LDLIBS in LTLIBRARY build, allowing malloc debug libraries to be linked in again. qa tripped over this. From owner-linux-xfs@oss.sgi.com Mon Apr 1 19:10:48 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g323AmP09812 for linux-xfs-outgoing; Mon, 1 Apr 2002 19:10:48 -0800 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g323Afo09777 for ; Mon, 1 Apr 2002 19:10:41 -0800 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g323AZ6G001512 for ; Mon, 1 Apr 2002 19:10:35 -0800 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA58777; Tue, 2 Apr 2002 13:09:17 +1000 (AEST) Date: Tue, 2 Apr 2002 13:09:17 +1000 From: Timothy Shimmin To: Joe Bacom Cc: linux-xfs@oss.sgi.com Subject: Re: xfsdump parameters not working Message-ID: <20020402130917.N5356@boing.melbourne.sgi.com> References: <200203310522.AAA00056@webcube2.volstate.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <200203310522.AAA00056@webcube2.volstate.net>; from joebacom@volstate.net on Sat, Mar 30, 2002 at 11:22:05PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Joe, On Sat, Mar 30, 2002 at 11:22:05PM -0600, Joe Bacom wrote: > Hi Folks; > I am using the following xfsdump command to dump system backups to 650m files > so they will fit on CD. xfsdump does not seem to be creating individual > files but rather a single file. > xfsdump -d 650 -f usr.xfsdump.3-30-2002 -l 0 -p 30 -L "Usr Dump 3/30/2002" -T > /usr > > Creates a 2.4G file > also I set the SGI_XFSDUMP_SKIP_FILE attribute on each of my dump files so > that I could backup the partition that the dump files were on and xfsdump did > not ignore them at but gave the error: > xfsdump: WARNING: could not open regular file ino 99652 mode 0x000081a4: File > too large: not dumped > any ideas? > Joe Questions --------- There are 3 parts to this question: a) -d doesn't work b) SGI_XFSDUMP_SKIP_FILE doesn't work c) why is the warning msg about large file produced Answers ------- (a) -d is used to specify the size of "media files" for tapes. This is _not_ the same as a dump to a disk file. Dumps to a disk file, always use one "media file". Check out: xfsdump/doc/xfsdump.html Writing to multiple disk files (at once), is only supported by xfsdump on IRIX which has the multiple thread support. (b) It looks like you forgot the -e option. (c) Is a bug in xfsdump/libhandle. This will be fixed shortly. --Tim From owner-linux-xfs@oss.sgi.com Mon Apr 1 19:19:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g323JaG10142 for linux-xfs-outgoing; Mon, 1 Apr 2002 19:19:36 -0800 Received: from smtp10.atl.mindspring.net (smtp10.atl.mindspring.net [207.69.200.246]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g323JHo10113 for ; Mon, 1 Apr 2002 19:19:17 -0800 Received: from user-1120gmi.dsl.mindspring.com ([66.32.66.210] helo=jtsdell) by smtp10.atl.mindspring.net with esmtp (Exim 3.33 #1) id 16sEp1-0000kj-00; Mon, 01 Apr 2002 22:18:59 -0500 Message-ID: X-Mailer: XFMail 1.5.2 on Linux X-Priority: 3 (Normal) Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20020402085912.G52863@wobbly.melbourne.sgi.com> Date: Mon, 01 Apr 2002 22:18:18 -0500 (EST) Reply-To: jtrostel@snapserver.com Organization: Quantum Corp. / NASD From: jtrostel@snapserver.com To: Nathan Scott Subject: Re: DQUOT_SYNC undefined in XFS CVS kernel (was: Can't build CVS Cc: linux-lvm@sistina.com, linux-xfs@oss.sgi.com, Bas , Jan Kara , Adrian Head Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry.... I should have been paying attention... I too found this last week when I was updating our XFS builds. I also just changed the DQUOT_SYNC(dev) to DQUOT_SYN_DEV(dev) and have not noticed any more strange manifestations from that. So... there's at least one more data point for you. On 01-Apr-2002 Nathan Scott wrote: > On Fri, Mar 29, 2002 at 10:26:41PM +1000, Adrian Head wrote: >> I have also run into the XFS CVS kernel compile failing because of an >> undefined DQUOT_SYNC. >> >> Using the information given by Nathan I have tracked down the offending >> patch >> that causes the problems. In my case it was the LVM VFS-lock patch from the >> Sistina LVM project. What they seem to do is use DQUOT_SYNC to force the >> writing of cached Quota infomation before they lock the VFS during snapshot >> creation. It would also seem that EVMS does the same thing. > > Aha, thanks for tracking this down Adrian. > >> I expect that the XFS CVS kernel tree is actually ahead of the standard >> 2.4.18 kernel tree in this respect so we'll have to wait until 2.4.19 is >> released with the updated API's before other projects update their kernel >> patches. > > Yes, the XFS trees contain all of the quota patches from: > ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/ > > I wouldn't expect these patches to be in 2.4.19 -- they are > not in 2.5 yet and I think Jan is concentrating on that step > first. > >> Grep'ing through the kernel I have not been able to find any comments or >> explanations regarding this - so I have assumed that DQUOT_SYNC can be >> changed to DQUOT_SYNC_DEV without problems. > > Yes, by my understanding of the VFS quota subsystem that would > be the correct thing to do. > >> After making that change the kernel compiles cleanly and boots. I'm unsure >> as yet if I have done the correct thing here. Hopefuly someone will be able >> to help us out and correct me if I'm incorrect. > > I believe your change is correct, I've CC'd Jan in case there is > anything that I've overlooked. > > cheers. > > >> The offending part of the VF-lock patch follows below: >> >> Index: linus.21/fs/buffer.c >> --- linus.21/fs/buffer.c Mon, 28 Jan 2002 09:51:50 -0500 root >> (linux/i/45_buffer.c 1.5.2.6 644) >> +++ linus.21(w)/fs/buffer.c Mon, 28 Jan 2002 11:54:36 -0500 root >> (linux/i/45_buffer.c 1.5.2.6 644) >> @@ -361,6 +361,34 @@ >> fsync_dev(dev); >> } >> >> +int fsync_dev_lockfs(kdev_t dev) >> +{ >> + /* 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. >> + */ >> + if (!dev) >> + return fsync_dev(dev) ; >> + >> + sync_buffers(dev, 0); >> + >> + lock_kernel(); >> + /* note, the FS might need to start transactions to >> + ** sync the inodes, or the quota, no locking until >> + ** after these are done >> + */ >> + sync_inodes(dev); >> + DQUOT_SYNC(dev); >> ^<==== ****All I did was to change this to >> DQUOT_SYNC_DEV(dev);**** >> + /* if inodes or quotas could be dirtied during the >> + ** sync_supers_lockfs call, the FS is responsible for getting >> + ** them on disk, without deadlocking against the lock >> + */ >> + sync_supers_lockfs(dev) ; >> + unlock_kernel(); >> + >> + return sync_buffers(dev, 1) ; >> +} >> + >> asmlinkage long sys_sync(void) >> { >> fsync_dev(0); >> >> >> On Thu, 28 Mar 2002 07:30, Nathan Scott wrote: >> > Hello, >> > >> > On Wed, Mar 27, 2002 at 09:45:48AM +0100, Bas wrote: >> > > Hi, >> > > >> > > It's not possible for me to build the kernel mentioned above. I saw the >> > > new qouta options and suspect it has something to do with it, but I'm >> > > not >> > > sure. >> > > >> > > Building everything goes fine, but at the end of the run it's not able >> > > to >> > > produce a kernel because of DQUOT_SYNC. I don't have the exact error >> > > here. >> > >> > Hmm... 20020327 - that's yesterday. DQUOT_SYNC doesn't appear in >> > the source at all anymore (for awhile now), so I suspect the problem >> > must be at your end. Try getting a fresh CVS copy and/or "make clean". >> > [ The other patches you mentioned should not have anything to do with >> > this problem. ] >> > >> > $ find . -type f | xargs fgrep DQUOT_SYNC >> > ./fs/buffer.c: DQUOT_SYNC_SB(sb); >> > ./fs/buffer.c: DQUOT_SYNC_DEV(dev); >> > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) >> > sync_dquots_dev(dev, -1) ./include/linux/quotaops.h:#define >> > DQUOT_SYNC_SB(sb) sync_dquots_sb(sb, -1) >> > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) do >> > { } while(0) ./include/linux/quotaops.h:#define DQUOT_SYNC_SB(sb) >> > do { } while(0) $ >> > >> > FWIW, DQUOT_SYNC used to come from include/linux/quotaops.h >> > too, and its definition was also dependent on CONFIG_QUOTA. >> > The reason you'd be getting an unresolved symbol would be a >> > file referencing DQUOT_SYNC wasn't #include'ing quotaops.h; >> > but thats all by-the-by - the real problem is related to the >> > source you're using I suspect - it certainly doesn't match >> > CVS of yesterday. >> > >> > cheers. >> >> -- >> Adrian Head >> >> (Public Key available on request.) > > -- > Nathan -- John M. Trostel Senior Software Engineer Quantum Corp. / NASD jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Mon Apr 1 19:59:36 2002 Received: (from majordomo@localhost) by oss.sgi.com (8.11.6/8.11.3) id g323xaY10722 for linux-xfs-outgoing; Mon, 1 Apr 2002 19:59:36 -0800 Received: from coredump.sh0n.net (qmailremote@CPEdeadbeef0000.cpe.net.cable.rogers.com [24.100.234.67]) by oss.sgi.com (8.11.6/8.11.3) with SMTP id g323xGo10695 for ; Mon, 1 Apr 2002 19:59:16 -0800 Received: (qmail 30301 invoked from network); 2 Apr 2002 03:40:57 -0000 Received: from cpedeadbeef0000.cpe.net.cable.rogers.com (HELO sh0n.net) (sh0n@24.100.234.67) by cpedeadbeef0000.cpe.net.cable.rogers.com with SMTP; 2 Apr 2002 03:40:57 -0000 Date: Mon, 1 Apr 2002 22:40:56 -0500 (EST) From: Shawn Starr To: jtrostel@snapserver.com cc: Nathan Scott , , , Bas , Jan Kara , Adrian Head Subject: Re: DQUOT_SYNC undefined in XFS CVS kernel (was: Can't build CVS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Had this as well. On Mon, 1 Apr 2002 jtrostel@snapserver.com wrote: > Sorry.... I should have been paying attention... I too found this last week > when I was updating our XFS builds. I also just changed the DQUOT_SYNC(dev) to > DQUOT_SYN_DEV(dev) and have not noticed any more strange manifestations from > that. > > So... there's at least one more data point for you. > > On 01-Apr-2002 Nathan Scott wrote: > > On Fri, Mar 29, 2002 at 10:26:41PM +1000, Adrian Head wrote: > >> I have also run into the XFS CVS kernel compile failing because of an > >> undefined DQUOT_SYNC. > >> > >> Using the information given by Nathan I have tracked down the offending > >> patch > >> that causes the problems. In my case it was the LVM VFS-lock patch from the > >> Sistina LVM project. What they seem to do is use DQUOT_SYNC to force the > >> writing of cached Quota infomation before they lock the VFS during snapshot > >> creation. It would also seem that EVMS does the same thing. > > > > Aha, thanks for tracking this down Adrian. > > > >> I expect that the XFS CVS kernel tree is actually ahead of the standard > >> 2.4.18 kernel tree in this respect so we'll have to wait until 2.4.19 is > >> released with the updated API's before other projects update their kernel > >> patches. > > > > Yes, the XFS trees contain all of the quota patches from: > > ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/v2.4/ > > > > I wouldn't expect these patches to be in 2.4.19 -- they are > > not in 2.5 yet and I think Jan is concentrating on that step > > first. > > > >> Grep'ing through the kernel I have not been able to find any comments or > >> explanations regarding this - so I have assumed that DQUOT_SYNC can be > >> changed to DQUOT_SYNC_DEV without problems. > > > > Yes, by my understanding of the VFS quota subsystem that would > > be the correct thing to do. > > > >> After making that change the kernel compiles cleanly and boots. I'm unsure > >> as yet if I have done the correct thing here. Hopefuly someone will be able > >> to help us out and correct me if I'm incorrect. > > > > I believe your change is correct, I've CC'd Jan in case there is > > anything that I've overlooked. > > > > cheers. > > > > > >> The offending part of the VF-lock patch follows below: > >> > >> Index: linus.21/fs/buffer.c > >> --- linus.21/fs/buffer.c Mon, 28 Jan 2002 09:51:50 -0500 root > >> (linux/i/45_buffer.c 1.5.2.6 644) > >> +++ linus.21(w)/fs/buffer.c Mon, 28 Jan 2002 11:54:36 -0500 root > >> (linux/i/45_buffer.c 1.5.2.6 644) > >> @@ -361,6 +361,34 @@ > >> fsync_dev(dev); > >> } > >> > >> +int fsync_dev_lockfs(kdev_t dev) > >> +{ > >> + /* 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. > >> + */ > >> + if (!dev) > >> + return fsync_dev(dev) ; > >> + > >> + sync_buffers(dev, 0); > >> + > >> + lock_kernel(); > >> + /* note, the FS might need to start transactions to > >> + ** sync the inodes, or the quota, no locking until > >> + ** after these are done > >> + */ > >> + sync_inodes(dev); > >> + DQUOT_SYNC(dev); > >> ^<==== ****All I did was to change this to > >> DQUOT_SYNC_DEV(dev);**** > >> + /* if inodes or quotas could be dirtied during the > >> + ** sync_supers_lockfs call, the FS is responsible for getting > >> + ** them on disk, without deadlocking against the lock > >> + */ > >> + sync_supers_lockfs(dev) ; > >> + unlock_kernel(); > >> + > >> + return sync_buffers(dev, 1) ; > >> +} > >> + > >> asmlinkage long sys_sync(void) > >> { > >> fsync_dev(0); > >> > >> > >> On Thu, 28 Mar 2002 07:30, Nathan Scott wrote: > >> > Hello, > >> > > >> > On Wed, Mar 27, 2002 at 09:45:48AM +0100, Bas wrote: > >> > > Hi, > >> > > > >> > > It's not possible for me to build the kernel mentioned above. I saw the > >> > > new qouta options and suspect it has something to do with it, but I'm > >> > > not > >> > > sure. > >> > > > >> > > Building everything goes fine, but at the end of the run it's not able > >> > > to > >> > > produce a kernel because of DQUOT_SYNC. I don't have the exact error > >> > > here. > >> > > >> > Hmm... 20020327 - that's yesterday. DQUOT_SYNC doesn't appear in > >> > the source at all anymore (for awhile now), so I suspect the problem > >> > must be at your end. Try getting a fresh CVS copy and/or "make clean". > >> > [ The other patches you mentioned should not have anything to do with > >> > this problem. ] > >> > > >> > $ find . -type f | xargs fgrep DQUOT_SYNC > >> > ./fs/buffer.c: DQUOT_SYNC_SB(sb); > >> > ./fs/buffer.c: DQUOT_SYNC_DEV(dev); > >> > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) > >> > sync_dquots_dev(dev, -1) ./include/linux/quotaops.h:#define > >> > DQUOT_SYNC_SB(sb) sync_dquots_sb(sb, -1) > >> > ./include/linux/quotaops.h:#define DQUOT_SYNC_DEV(dev) do > >> > { } while(0) ./include/linux/quotaops.h:#define DQUOT_SYNC_SB(sb) > >> > do { } while(0) $ > >> > > >> > FWIW, DQUOT_SYNC used to come from include/linux/quotaops.h > >> > too, and its definition was also dependent on CONFIG_QUOTA. > >> > The reason you'd be getting an unresolved symbol would be a > >> > file referencing DQUOT_SYNC wasn't #include'ing quotaops.h; > >> > but thats all by-the-by - the real problem is related to the > >> > source you're using I suspect - it certainly doesn't match > >> > CVS of yesterday. > >> > > >> > cheers. > >> > >> -- > >> Adrian Head > >> > >> (Public Key available on request.) > > > > -- > > Nathan > > -- > John M. Trostel > Senior Software Engineer > Quantum Corp. / NASD > jtrostel@snapserver.com > > > From owner-linux-xfs@lips.thebarn.com Wed Apr 3 19:17:57 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g341Hv47036520 for linux-xfs-outgoing; Wed, 3 Apr 2002 19:17:57 -0600 (CST) Received: from lupo.thebarn.com (lupo.thebarn.com [24.245.56.2]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g341Hton036515 for ; Wed, 3 Apr 2002 19:17:56 -0600 (CST) Received: (from cattelan@localhost) by lupo.thebarn.com (8.11.6/8.11.0) id g341HtG88097 for linux-xfs@thebarn.com; Wed, 3 Apr 2002 19:17:55 -0600 (CST) (envelope-from cattelan) Date: Wed, 3 Apr 2002 19:17:55 -0600 (CST) From: Russell Cattelan Message-Id: <200204040117.g341HtG88097@lupo.thebarn.com> To: linux-xfs@thebarn.com Sender: owner-linux-xfs@thebarn.com Precedence: bulk bark From owner-linux-xfs@lips.thebarn.com Wed Apr 3 19:21:36 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g341LaO3036604 for linux-xfs-outgoing; Wed, 3 Apr 2002 19:21:36 -0600 (CST) Received: from lupo (lupo.thebarn.com [24.245.56.2]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g341LZon036599 for ; Wed, 3 Apr 2002 19:21:35 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host lupo.thebarn.com [24.245.56.2] claimed to be lupo Subject: Ok got the perms right finally From: Russell Cattelan To: linux-xfs@thebarn.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 03 Apr 2002 19:21:35 -0600 Message-Id: <1017883295.87053.78.camel@lupo.thebarn.com> Mime-Version: 1.0 Sender: owner-linux-xfs@thebarn.com Precedence: bulk Ok hopefully this will be the last test message. I finally figured out my permission snafu (didn't have the setuid bit set on sendmail binary) (Can't count the number of times I've made that mistake) Anyways the list should be up and running now at linux-xfs@thebarn.com temporally of course. oss will return shortly. -Russell From owner-linux-xfs@lips.thebarn.com Wed Apr 3 19:34:07 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g341Y7Wm037027 for linux-xfs-outgoing; Wed, 3 Apr 2002 19:34:07 -0600 (CST) Received: from congo.borg.umn.edu (congo.borg.umn.edu [160.94.232.1]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g341Y5on037007 for ; Wed, 3 Apr 2002 19:34:06 -0600 (CST) Received: from lupo.thebarn.com (c-24-245-56-2.mn.client2.attbi.com [24.245.56.2]) by congo.borg.umn.edu (8.11.6/8.11.2) with ESMTP id g341Cr248393 for ; Wed, 3 Apr 2002 19:12:53 -0600 (CST) Received: (from cattelan@localhost) by lupo.thebarn.com (8.11.6/8.11.0) id g341Cp688074 for linux-xfs@thebarn.com; Wed, 3 Apr 2002 19:12:51 -0600 (CST) (envelope-from cattelan) Date: Wed, 3 Apr 2002 19:12:51 -0600 (CST) From: Russell Cattelan Message-Id: <200204040112.g341Cp688074@lupo.thebarn.com> To: linux-xfs@thebarn.com Sender: owner-linux-xfs@thebarn.com Precedence: bulk test From owner-linux-xfs@lips.thebarn.com Wed Apr 3 19:34:07 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g341Y78f037028 for linux-xfs-outgoing; Wed, 3 Apr 2002 19:34:07 -0600 (CST) Received: from congo.borg.umn.edu (congo.borg.umn.edu [160.94.232.1]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g341Y5op037007 for ; Wed, 3 Apr 2002 19:34:06 -0600 (CST) Received: from lupo.thebarn.com (c-24-245-56-2.mn.client2.attbi.com [24.245.56.2]) by congo.borg.umn.edu (8.11.6/8.11.2) with ESMTP id g341D0248398 for ; Wed, 3 Apr 2002 19:13:00 -0600 (CST) Received: (from cattelan@localhost) by lupo.thebarn.com (8.11.6/8.11.0) id g341D0l88079 for linux-xfs@thebarn.com; Wed, 3 Apr 2002 19:13:00 -0600 (CST) (envelope-from cattelan) Date: Wed, 3 Apr 2002 19:13:00 -0600 (CST) From: Russell Cattelan Message-Id: <200204040113.g341D0l88079@lupo.thebarn.com> To: linux-xfs@thebarn.com Sender: owner-linux-xfs@thebarn.com Precedence: bulk test From owner-linux-xfs@lips.thebarn.com Wed Apr 3 20:11:08 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g342B81g038756 for linux-xfs-outgoing; Wed, 3 Apr 2002 20:11:08 -0600 (CST) Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g342B5on038751 for ; Wed, 3 Apr 2002 20:11:06 -0600 (CST) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g342B56G019872 for ; Wed, 3 Apr 2002 18:11:05 -0800 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g342B4036426404 for <@relay.sgi.com:linux-xfs@thebarn.com>; Wed, 3 Apr 2002 18:11:04 -0800 (PST) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA00719 for ; Thu, 4 Apr 2002 12:11:02 +1000 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA17352 for linux-xfs@thebarn.com; Thu, 4 Apr 2002 12:11:01 +1000 (EST) Date: Thu, 4 Apr 2002 12:11:01 +1000 (EST) From: Timothy Shimmin Message-Id: <200204040211.MAA17352@snort.melbourne.sgi.com> To: linux-xfs@thebarn.com Subject: TAKE - xfsprogs/libhandle/xfsdump Sender: owner-linux-xfs@thebarn.com Precedence: bulk Forgot to update the VERSION and CHANGES files. xfsprogs-2.0.2 (4 April 2002) - Bumped version of libhandle to libhandle.so.1.0.1 This changes open_by_handle() and friends so that O_LARGEFILE is added to the open flags. This allows xfsdump to dump files greater than 2^31-1 bytes instead of not dumping the large files and giving warning messages. --Tim Date: Wed Apr 3 18:07:49 PST 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:115640a cmd/xfsprogs/VERSION - 1.43 - bump version for libhandle changes for O_LARGEFILE cmd/xfsprogs/doc/CHANGES - 1.58 - Mention libhandle change for O_LARGEFILE for xfsprogs-2.0.2. From owner-linux-xfs@lips.thebarn.com Wed Apr 3 20:14:14 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g342EEYk039018 for linux-xfs-outgoing; Wed, 3 Apr 2002 20:14:14 -0600 (CST) Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g342EDon039007 for ; Wed, 3 Apr 2002 20:14:13 -0600 (CST) Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g342E7kw028954 for ; Wed, 3 Apr 2002 20:14:07 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA90317 for ; Wed, 3 Apr 2002 20:14:07 -0600 (CST) Received: from chuckle.americas.sgi.com (IDENT:sandeen@chuckle.americas.sgi.com [128.162.211.44]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id UAA91475 for ; Wed, 3 Apr 2002 20:14:07 -0600 (CST) Date: Wed, 3 Apr 2002 20:14:07 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Subject: Temporary Linux XFS resources Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@thebarn.com Precedence: bulk Hi gang - Sorry about all the turbulence, but we have some temporary resources to tide us over until oss.sgi.com comes back. This address (linux-xfs@thebarn.com) should handle the mailing list activity, and http://www.thebarn.com/xfs/ and http://www.thebarn.com/cgi-bin/cvsweb.cgi have most of the web content. You can still do CVS checkouts from cvs -d :pserver:cvs@ftp.thebarn.com:/export/burn/xfsCVS login password: cvs cvs -d :pserver:cvs@ftp.thebarn.com:/export/burn/xfsCVS co linux-2.4-xfs Many thanks to Russell for setting this up, and thanks for bearing with us through all this. oss should be back in a few days. -Eric From owner-linux-xfs@lips.thebarn.com Thu Apr 4 10:13:53 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g34GDr7s045135 for linux-xfs-outgoing; Thu, 4 Apr 2002 10:13:53 -0600 (CST) Received: from atlrel7.hp.com (atlrel7.hp.com [156.153.255.213]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g34GDnon045130 for ; Thu, 4 Apr 2002 10:13:50 -0600 (CST) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel7.hp.com (Postfix) with ESMTP id 09D518051F5 for ; Thu, 4 Apr 2002 11:13:42 -0500 (EST) Received: from xatlbh1.atl.hp.com (xatlbh1.atl.hp.com [15.45.89.186]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id B3704129 for ; Thu, 4 Apr 2002 11:13:41 -0500 (EST) Received: by xatlbh1.atl.hp.com with Internet Mail Service (5.5.2653.19) id <2FHDLDGK>; Thu, 4 Apr 2002 11:13:41 -0500 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@thebarn.com'" Subject: heavy VM load due to revamped pagebuf locking? Date: Thu, 4 Apr 2002 11:13:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@thebarn.com Precedence: bulk I've updated to 2.4.18 w/ a XFS CVS download from 03/29/2002. During SPEC testing, the VM takes over all CPU load as pagebuf_iostart starts waiting for memory, and then kmalloc starts waiting for memory. All of this time spent in shrink_cache causes the SPEC test to time out. Once the test stops, the box settles down and VM CPU load goes away. All of the shrink_cache functions are waiting for schedule() to come back, because of the test for current->need_resched at the top of the shrink_cache loop. For grins, I commented out that test, and now many nfsd processes are sitting in _pagebuf_find_lockable_buffer->pagebuf_iostart's call to pagebuf_iowait. Could the revamped pagebuf locking cause this behaviour? Erik Here are some decoded Alt-Sysrq traces during the tests: Trace 1: both kswapd and nfsd decided to go into shrink_cache code task: kswapd (pid: 7) c014b9bc: c014b885 t _text_lock_inode c014aae7: c014aaac t dispose_list c014ad39: c014ac7c T prune_icache c014ad77: c014ad5c T shrink_icache_memory c012eb09: c012ea9c t shrink_caches c012eb5c: c012eb20 T try_to_free_pages c012ebf3: c012ebb0 t kswapd_balance_pgdat c012ec4e: c012ec3c t kswapd_balance c012ed5d: c012ecc4 T kswapd c01055a4: c010557c T kernel_thread task: nfsd (pid: 619) c0114c08: c0114b8e t _text_lock_sched c012e6bd: c012e624 t shrink_cache c012eaf2: c012ea9c t shrink_caches c012eb5c: c012eb20 T try_to_free_pages c012f460: c012f404 t balance_classzone c012f682: c012f57c T __alloc_pages c01dd40b: c01dd274 T _pagebuf_lookup_pages c012f402: c012f3ec T _alloc_pages c01dd430: c01dd274 T _pagebuf_lookup_pages c01dd7f3: c01dd790 T pagebuf_get c01d2184: c01d2148 T xfs_trans_read_buf c01a9413: c01a8f3c t xfs_da_do_buf c01a96a9: c01a967c T xfs_da_read_buf c01ace45: c01ace10 t xfs_dir2_block_lookup_int c01ace45: c01ace10 t xfs_dir2_block_lookup_int c019cce3: c019cc04 T xfs_bmap_last_offset c01acd6f: c01acd54 T xfs_dir2_block_lookup c01ab500: c01ab43c t xfs_dir2_lookup c01ab51a: c01ab43c t xfs_dir2_lookup c028c443: c028c430 T qdisc_restart c01d34d6: c01d3418 T xfs_dir_lookup_int c01be2f7: c01be28c T xfs_ilock c01d7ad7: c01d7a44 t xfs_lookup c01d686b: c01d683c t xfs_access c01e44d2: c01e4454 t linvfs_lookup c0140b31: c0140a98 T lookup_hash c0140bc7: c0140b70 T lookup_one_len c016720d: c0166f40 T nfsd_lookup c016c9c8: c016c8f4 t nfsd3_proc_lookup c01644f3: c0164420 t nfsd_dispatch c02c66b5: c02c6428 T svc_process c01642ef: c01640f8 t nfsd c01055a4: c010557c T kernel_thread Trace 2: kmalloc starts to fail as both pagebuf_get and kmalloc go looking for pages task: nfsd (pid: 687) c012e6bd: c012e624 t shrink_cache c012eaf2: c012ea9c t shrink_caches c012eb5c: c012eb20 T try_to_free_pages c012f460: c012f404 t balance_classzone c012f682: c012f57c T __alloc_pages c01dd40b: c01dd274 T _pagebuf_lookup_pages c012f402: c012f3ec T _alloc_pages c01dd430: c01dd274 T _pagebuf_lookup_pages c01dd7f3: c01dd790 T pagebuf_get c01d2184: c01d2148 T xfs_trans_read_buf c01be9a8: c01be8a8 T xfs_itobp c01bf9b7: c01bf96c T xfs_iread c01bda32: c01bd82c T xfs_iget_core c01bddee: c01bdd64 T xfs_iget c01d353f: c01d3418 T xfs_dir_lookup_int c01be2f7: c01be28c T xfs_ilock c01d7ad7: c01d7a44 t xfs_lookup c01e44d2: c01e4454 t linvfs_lookup c0140b31: c0140a98 T lookup_hash c0140bc7: c0140b70 T lookup_one_len c016720d: c0166f40 T nfsd_lookup c016c9c8: c016c8f4 t nfsd3_proc_lookup c01644f3: c0164420 t nfsd_dispatch c02c66b5: c02c6428 T svc_process c01642ef: c01640f8 t nfsd c01055a4: c010557c T kernel_thread task: nfsd (pid: 732) c012e6bd: c012e624 t shrink_cache c012eaf2: c012ea9c t shrink_caches c012eb5c: c012eb20 T try_to_free_pages c012f460: c012f404 t balance_classzone c0114c0f: c0114b8e t _text_lock_sched c012f682: c012f57c T __alloc_pages c012f402: c012f3ec T _alloc_pages c012f6ea: c012f6e0 T __get_free_pages c012cdfe: c012cd50 t kmem_cache_grow c012d328: c012d1f8 T kmalloc c01e193f: c01e18e8 t linvfs_readdir c01a9823: c01a9808 t xfs_da_buf_make c01a94eb: c01a8f3c t xfs_da_do_buf c01ace45: c01ace10 t xfs_dir2_block_lookup_int c029331a: c0293000 T ip_rcv c028638e: c0286224 t net_rx_action c0144bd4: c0144b40 T vfs_readdir c0165a40: c0165a40 t filldir_one c0165b35: c0165a8c t nfsd_get_name c0165a40: c0165a40 t filldir_one c0165f20: c0165efc t splice c01d5bd6: c01d5990 T xfs_getattr c01e9d8b: c01e9d54 T vn_revalidate c01e4aea: c01e4ad4 T linvfs_revalidate_core c01e4513: c01e4454 t linvfs_lookup c0148bb9: c0148ba0 T dput c0165ef1: c0165dfc T nfsd_findparent c01662d0: c0166078 t find_fh_dentry c01665a8: c01663ac T fh_verify c0113547: c01132e8 t reschedule_idle c0166fb2: c0166f40 T nfsd_lookup c016c9c8: c016c8f4 t nfsd3_proc_lookup c01644f3: c0164420 t nfsd_dispatch c02c66b5: c02c6428 T svc_process c01642ef: c01640f8 t nfsd c01055a4: c010557c T kernel_thread Trace 3: now only kmalloc is failing. Lots of nfsd's are stuck in the exact same place task: nfsd (pid: 646) c012e6bd: c012e624 t shrink_cache c012eaf2: c012ea9c t shrink_caches c012eb5c: c012eb20 T try_to_free_pages c012f460: c012f404 t balance_classzone c012f682: c012f57c T __alloc_pages c012f402: c012f3ec T _alloc_pages c012f6ea: c012f6e0 T __get_free_pages c012cdfe: c012cd50 t kmem_cache_grow c012d328: c012d1f8 T kmalloc c01e193f: c01e18e8 t linvfs_readdir c01a9823: c01a9808 t xfs_da_buf_make c01e0c7b: c01e0bb0 T _pagebuf_find_lockable_buffer c0127608: c01275e8 T __find_lock_page c01dd40b: c01dd274 T _pagebuf_lookup_pages c01dd522: c01dd274 T _pagebuf_lookup_pages c01dd7f3: c01dd790 T pagebuf_get c01d2184: c01d2148 T xfs_trans_read_buf c0144bd4: c0144b40 T vfs_readdir c0165a40: c0165a40 t filldir_one c0165b35: c0165a8c t nfsd_get_name c0165a40: c0165a40 t filldir_one c0165f20: c0165efc t splice c01d5bd6: c01d5990 T xfs_getattr c01e9d8b: c01e9d54 T vn_revalidate c01492f3: c01492d8 T d_alloc c0148bb9: c0148ba0 T dput c0165ef1: c0165dfc T nfsd_findparent c01662d0: c0166078 t find_fh_dentry c01665a8: c01663ac T fh_verify c0113547: c01132e8 t reschedule_idle c0166fb2: c0166f40 T nfsd_lookup c016c9c8: c016c8f4 t nfsd3_proc_lookup c01644f3: c0164420 t nfsd_dispatch c02c66b5: c02c6428 T svc_process c01642ef: c01640f8 t nfsd c01055a4: c010557c T kernel_thread Trace 4: test with no need_resched check in shrink_cache task: nfsd (pid: 566) c0105ae4: c0105a78 T __down c0105c80: c0105c78 T __down_failed c01def4e: c01deea5 t _text_lock_page_buf c01ddd0f: c01ddc98 T pagebuf_iostart c01dd7d8: c01dd730 T pagebuf_get c01d2124: c01d20e8 T xfs_trans_read_buf c01a93b3: c01a8edc t xfs_da_do_buf c01e0c1b: c01e0b50 T _pagebuf_find_lockable_buffer c0127608: c01275e8 T __find_lock_page c01dd3ab: c01dd214 T _pagebuf_lookup_pages c01a9649: c01a961c T xfs_da_read_buf c01acde5: c01acdb0 t xfs_dir2_block_lookup_int c01acde5: c01acdb0 t xfs_dir2_block_lookup_int c019cc83: c019cba4 T xfs_bmap_last_offset c01acd0f: c01accf4 T xfs_dir2_block_lookup c01ab4a0: c01ab3dc t xfs_dir2_lookup c01ab4ba: c01ab3dc t xfs_dir2_lookup c01b3a06: c01b39b4 T xfs_dir2_sf_create c01d3476: c01d33b8 T xfs_dir_lookup_int c01be297: c01be22c T xfs_ilock c01d7a77: c01d79e4 t xfs_lookup c01e4472: c01e43f4 t linvfs_lookup c0165dd0: c0165d9c T nfsd_findparent c0166246: c0166018 t find_fh_dentry c0166548: c016634c T fh_verify c011334a: c01132e8 t reschedule_idle c0166f52: c0166ee0 T nfsd_lookup c016c968: c016c894 t nfsd3_proc_lookup c0164493: c01643c0 t nfsd_dispatch c02c6655: c02c63c8 T svc_process c016428f: c0164098 t nfsd c01055a4: c010557c T kernel_thread From owner-linux-xfs@lips.thebarn.com Thu Apr 4 10:44:31 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g34GiV39045621 for linux-xfs-outgoing; Thu, 4 Apr 2002 10:44:31 -0600 (CST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g34GiPon045613 for ; Thu, 4 Apr 2002 10:44:26 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host ns.suse.de [213.95.15.193] claimed to be Cantor.suse.de Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id C22961E55E; Thu, 4 Apr 2002 18:44:24 +0200 (MEST) Date: Thu, 4 Apr 2002 18:44:24 +0200 From: Andi Kleen To: "HABBINGA,ERIK (HP-Loveland,ex1)" Cc: "'linux-xfs@thebarn.com'" Subject: Re: heavy VM load due to revamped pagebuf locking? Message-ID: <20020404184424.A26480@oldwotan.suse.de> 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 erik_habbinga@hp.com on Thu, Apr 04, 2002 at 11:13:39AM -0500 Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Thu, Apr 04, 2002 at 11:13:39AM -0500, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > I've updated to 2.4.18 w/ a XFS CVS download from 03/29/2002. During SPEC > testing, the VM takes over all CPU load as pagebuf_iostart starts waiting > for memory, and then kmalloc starts waiting for memory. All of this time > spent in shrink_cache causes the SPEC test to time out. Once the test > stops, the box settles down and VM CPU load goes away. All of the > shrink_cache functions are waiting for schedule() to come back, because of > the test for current->need_resched at the top of the shrink_cache loop. For > grins, I commented out that test, and now many nfsd processes are sitting in > _pagebuf_find_lockable_buffer->pagebuf_iostart's call to pagebuf_iowait. > Could the revamped pagebuf locking cause this behaviour? You could test ist. Just revert that TAKE and test again. -Andi From owner-linux-xfs@lips.thebarn.com Thu Apr 4 11:04:48 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g34H4mtX046016 for linux-xfs-outgoing; Thu, 4 Apr 2002 11:04:48 -0600 (CST) Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g34H4ion046011 for ; Thu, 4 Apr 2002 11:04:46 -0600 (CST) Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g34H4Skw002227; Thu, 4 Apr 2002 11:04:30 -0600 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 LAA99848; Thu, 4 Apr 2002 11:04:27 -0600 (CST) Received: from sgi.com (R/l7NJb8WwI5eSLZcJctWRjbX491PIXc@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA28672; Thu, 4 Apr 2002 11:04:27 -0600 (CST) Message-ID: <3CAC87F6.7060207@sgi.com> Date: Thu, 04 Apr 2002 11:05:58 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: "HABBINGA,ERIK (HP-Loveland,ex1)" CC: Andi Kleen , "'linux-xfs@thebarn.com'" Subject: Re: heavy VM load due to revamped pagebuf locking? References: <20020404184424.A26480@oldwotan.suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@thebarn.com Precedence: bulk Andi Kleen wrote: >On Thu, Apr 04, 2002 at 11:13:39AM -0500, HABBINGA,ERIK (HP-Loveland,ex1) wrote: > >>I've updated to 2.4.18 w/ a XFS CVS download from 03/29/2002. During SPEC >>testing, the VM takes over all CPU load as pagebuf_iostart starts waiting >>for memory, and then kmalloc starts waiting for memory. All of this time >>spent in shrink_cache causes the SPEC test to time out. Once the test >>stops, the box settles down and VM CPU load goes away. All of the >>shrink_cache functions are waiting for schedule() to come back, because of >>the test for current->need_resched at the top of the shrink_cache loop. For >>grins, I commented out that test, and now many nfsd processes are sitting in >>_pagebuf_find_lockable_buffer->pagebuf_iostart's call to pagebuf_iowait. >>Could the revamped pagebuf locking cause this behaviour? >> > >You could test ist. Just revert that TAKE and test again. > >-Andi > Andi's suggestion is a good one, we have not seen this here, your configuation is clearly larger than anything we have locally. You might also try just reverting the changes in page_buf_io.c (you will need the header file change). The locking changes should not affect memory consumption that much, but changes went into this file which put buffer heads on pages in more circumstances than we used to. Steve From owner-linux-xfs@lips.thebarn.com Fri Apr 5 05:32:24 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35BWOCM060747 for linux-xfs-outgoing; Fri, 5 Apr 2002 05:32:24 -0600 (CST) Received: from voyager.st-peter.stw.uni-erlangen.de (mail@voyager.st-peter.stw.uni-erlangen.de [131.188.24.132]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35BWKon060742 for ; Fri, 5 Apr 2002 05:32:21 -0600 (CST) 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 16tRwx-00028e-00; Fri, 05 Apr 2002 13:32:11 +0200 Message-ID: <3CAD8B9D.8070902@st-peter.stw.uni-erlangen.de> Date: Fri, 05 Apr 2002 13:33:49 +0200 From: svetljo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/00200203 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-kernel@vger.kernel.org, linux-xfs@thebarn.com Subject: REPOST : linux-2.5.5-xfs-dj1 - 2.5.7-dj2 (raid0_make_request bug) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16tRwx-00028e-00*ZaPlpTkJJx2* (Studentenwohnanlage Nuernberg St.-Peter) Sender: owner-linux-xfs@thebarn.com Precedence: bulk Hi i'd like to ask you to CC me because i'm not subscribed to the lists i'm having some interesting troubles i have lvm over soft RAID-0 with LV's formated with XFS and JFS i can work with the JFS LV's, but i can not with the XFS one's, i can not mount them ( no troubles with XFS normal partitions) so i'd like to ask is this problem with XFS or with raid or lvm and is there a way to fix it thanks for your help here is what i found in dmesg ##################################################################################### id0: zone 2 raid0: checking ide/host2/bus0/target0/lun0/part8 ... contained as device 0 (2859456) is smallest!. raid0: checking ide/host3/bus0/target0/lun0/part10 ... nope. raid0: checking ide/host3/bus0/target1/lun0/part6 ... nope. raid0: zone->nb_dev: 1, size: 249024 raid0: current zone offset: 2859456 raid0: done. raid0 : md_size is 8064256 blocks. raid0 : conf->smallest->size is 32128 blocks. raid0 : nb_zone is 252. raid0 : Allocating 2016 bytes for hash. md: updating md0 RAID superblock on device md: ide/host3/bus0/target1/lun0/part6 [events: 000002f3]<6>(write) ide/host3/bus0/target1/lun0/part6's sb offset: 2610432 md: ide/host3/bus0/target0/lun0/part10 [events: 000002f3]<6>(write) ide/host3/bus0/target0/lun0/part10's sb offset: 2594368 md: ide/host2/bus0/target0/lun0/part8 [events: 000002f3]<6>(write) ide/host2/bus0/target0/lun0/part8's sb offset: 2859456 md: considering ide/host3/bus0/target1/lun0/part5 ... md: adding ide/host3/bus0/target1/lun0/part5 ... md: adding ide/host3/bus0/target0/lun0/part8 ... md: adding ide/host2/bus0/target0/lun0/part7 ... md: created md2 md: bind md: bind md: bind md: running: md: ide/host3/bus0/target1/lun0/part5's event counter: 0000031a md: ide/host3/bus0/target0/lun0/part8's event counter: 0000031a md: ide/host2/bus0/target0/lun0/part7's event counter: 0000031a md2: max total readahead window set to 744k md2: 3 data-disks, max readahead per data-disk: 248k raid0: looking at ide/host2/bus0/target0/lun0/part7 raid0: comparing ide/host2/bus0/target0/lun0/part7(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: END raid0: ==> UNIQUE raid0: 1 zones raid0: looking at ide/host3/bus0/target0/lun0/part8 raid0: comparing ide/host3/bus0/target0/lun0/part8(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: EQUAL raid0: looking at ide/host3/bus0/target1/lun0/part5 raid0: comparing ide/host3/bus0/target1/lun0/part5(4096448) with ide/host2/bus0/target0/lun0/part7(4096448) raid0: EQUAL raid0: FINAL 1 zones raid0: zone 0 raid0: checking ide/host2/bus0/target0/lun0/part7 ... contained as device 0 (4096448) is smallest!. raid0: checking ide/host3/bus0/target0/lun0/part8 ... contained as device 1 raid0: checking ide/host3/bus0/target1/lun0/part5 ... contained as device 2 raid0: zone->nb_dev: 3, size: 12289344 raid0: current zone offset: 4096448 raid0: done. raid0 : md_size is 12289344 blocks. raid0 : conf->smallest->size is 12289344 blocks. raid0 : nb_zone is 1. raid0 : Allocating 8 bytes for hash. md: updating md2 RAID superblock on device md: ide/host3/bus0/target1/lun0/part5 [events: 0000031b]<6>(write) ide/host3/bus0/target1/lun0/part5's sb offset: 4096448 md: ide/host3/bus0/target0/lun0/part8 [events: 0000031b]<6>(write) ide/host3/bus0/target0/lun0/part8's sb offset: 4096448 md: ide/host2/bus0/target0/lun0/part7 [events: 0000031b]<6>(write) ide/host2/bus0/target0/lun0/part7's sb offset: 4096448 md: considering ide/host3/bus0/target0/lun0/part12 ... md: adding ide/host3/bus0/target0/lun0/part12 ... md: adding ide/host3/bus0/target0/lun0/part6 ... md: adding ide/host3/bus0/target0/lun0/part5 ... md: adding ide/host3/bus0/target0/lun0/part1 ... md: created md6 md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part5 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part1. True protection against single-disk failure might be compromised. md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part6 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part5. True protection against single-disk failure might be compromised. md: bind md6: WARNING: ide/host3/bus0/target0/lun0/part12 appears to be on the same physical disk as ide/host3/bus0/target0/lun0/part6. True protection against single-disk failure might be compromised. md: bind md: running: md: ide/host3/bus0/target0/lun0/part12's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part6's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part5's event counter: 00000391 md: ide/host3/bus0/target0/lun0/part1's event counter: 00000391 md6: max total readahead window set to 124k md6: 1 data-disks, max readahead per data-disk: 124k md: updating md6 RAID superblock on device md: ide/host3/bus0/target0/lun0/part12 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part12's sb offset: 9759360 md: ide/host3/bus0/target0/lun0/part6 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part6's sb offset: 513984 md: ide/host3/bus0/target0/lun0/part5 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part5's sb offset: 2088320 md: ide/host3/bus0/target0/lun0/part1 [events: 00000392]<6>(write) ide/host3/bus0/target0/lun0/part1's sb offset: 2048192 md: considering ide/host2/bus0/target0/lun0/part11 ... md: adding ide/host2/bus0/target0/lun0/part11 ... md: adding ide/host2/bus0/target0/lun0/part6 ... md: created md7 md: bind md7: WARNING: ide/host2/bus0/target0/lun0/part11 appears to be on the same physical disk as ide/host2/bus0/target0/lun0/part6. True protection against single-disk failure might be compromised. md: bind md: running: md: ide/host2/bus0/target0/lun0/part11's event counter: 000003bf md: ide/host2/bus0/target0/lun0/part6's event counter: 000003bf md7: max total readahead window set to 124k md7: 1 data-disks, max readahead per data-disk: 124k md: updating md7 RAID superblock on device md: ide/host2/bus0/target0/lun0/part11 [events: 000003c0]<6>(write) ide/host2/bus0/target0/lun0/part11's sb offset: 10514432 md: ide/host2/bus0/target0/lun0/part6 [events: 000003c0]<6>(write) ide/host2/bus0/target0/lun0/part6's sb offset: 3421696 md: ... autorun DONE. LVM version 1.0.1-rc4(ish)(03/10/2001) IEEE 802.2 LLC for Linux 2.1 (c) 1996 Tim Alpaerts NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 4096 buckets, 32Kbytes TCP: Hash tables configured (established 131072 bind 65536) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. found reiserfs format "3.6" with standard journal Reiserfs journal params: device 22:4b, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 reiserfs: checking transaction log (ide3(34,75)) for (ide3(34,75)) Using r5 hash to sort names VFS: Mounted root (reiserfs filesystem) readonly. Mounted devfs on /dev Freeing unused kernel memory: 256k freed Real Time Clock Driver v1.10e loop: loaded (max 32 devices) mice: PS/2 mouse device common for all mice cdrom: open failed. VFS: Disk change detected on device ide1(22,0) Adding Swap: 473876k swap-space (priority 1) Adding Swap: 457812k swap-space (priority 1) Adding Swap: 473876k swap-space (priority 1) XFS mounting filesystem lvm(58,2) raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323317 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323445 64 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x601f7d ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8324829 29 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x602565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,3) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: lvm(58,3) (dev: 58/3) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,1) raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610115 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610243 64 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa0218b ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23611101 29 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa02565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,2) raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323317 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8323445 64 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x601f7d ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 8324829 29 I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block 0x602565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,3) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: lvm(58,3) (dev: 58/3) XFS: xlog_recover_process_data: bad clientid XFS: log mount/recovery failed XFS: log mount failed XFS mounting filesystem lvm(58,1) raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610115 64 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23610243 64 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa0218b ("xlog_bread") error 5 buf count 131072 raid0_make_request bug: can't convert block across chunks or bigger than 16k 23611101 29 I/O error in filesystem ("lvm(58,1)") meta-data dev 0xc0223a01 block 0xa02565 ("xlog_bread") error 5 buf count 30208 XFS: failed to find log head XFS: log mount/recovery failed XFS: log mount failed From owner-linux-xfs@lips.thebarn.com Fri Apr 5 08:00:18 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35E0IvQ061890 for linux-xfs-outgoing; Fri, 5 Apr 2002 08:00:18 -0600 (CST) Received: from lupo.thebarn.com (lupo.thebarn.com [24.245.56.2]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35E0Fon061885 for ; Fri, 5 Apr 2002 08:00:17 -0600 (CST) Received: (from cattelan@localhost) by lupo.thebarn.com (8.11.6/8.11.0) id g35E0Ef30830; Fri, 5 Apr 2002 08:00:14 -0600 (CST) (envelope-from cattelan) Date: Fri, 5 Apr 2002 08:00:14 -0600 (CST) Message-Id: <200204051400.g35E0Ef30830@lupo.thebarn.com> From: Nathan Scott To: linux-xfs@thebarn.com Subject: TAKE - minor user build changes Sender: owner-linux-xfs@thebarn.com Precedence: bulk Date: Thu Apr 4 22:07:45 PST 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:115790a cmd/dmapi/include/buildmacros - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/dmapi/include/buildmacros cmd/xfsprogs/include/buildmacros - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsprogs/include/buildmacros cmd/acl/include/buildmacros - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/acl/include/buildmacros cmd/attr/include/buildmacros - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr/include/buildmacros cmd/xfsdump/include/buildmacros - 1.1 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsdump/include/buildmacros cmd/acl/include/buildrules - 1.6 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/acl/include/buildrules.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h cmd/acl/include/Makefile - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/acl/include/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h cmd/acl/include/builddefs.in - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/acl/include/builddefs.in.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - split out builddefs into configurable and static parts, should help in keeping track of differences between packages. cmd/attr/VERSION - 1.17 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr/VERSION.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h - missed an update here at some point.. cmd/attr/include/Makefile - 1.5 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr/include/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h cmd/attr/include/builddefs.in - 1.15 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/attr/include/builddefs.in.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h cmd/xfsprogs/include/Makefile - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsprogs/include/Makefile.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h cmd/xfsprogs/include/builddefs.in - 1.20 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsprogs/include/builddefs.in.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h - split out builddefs into configurable and static parts, should help in keeping track of differences between packages. cmd/xfsprogs/libxfs/xfs_ialloc.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsprogs/libxfs/xfs_ialloc.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h cmd/xfsprogs/libxfs/xfs_inode.c - 1.7 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsprogs/libxfs/xfs_inode.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h - fix some compiler warnings. cmd/xfsdump/include/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsdump/include/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h cmd/xfsdump/include/builddefs.in - 1.13 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfsdump/include/builddefs.in.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - split out builddefs into configurable and static parts, should help in keeping track of differences between packages. cmd/xfstests/tools/srcdiff - 1.12 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/xfstests/tools/srcdiff.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h - start making an effort to keep user packages in sync where they can be. cmd/dmapi/include/Makefile - 1.2 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/dmapi/include/Makefile.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h cmd/dmapi/include/builddefs.in - 1.14 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/dmapi/include/builddefs.in.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h - split out builddefs into configurable and static parts, should help in keeping track of differences between packages. cmd/dmapi/debian/changelog - 1.10 http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.4-xfs/cmd/dmapi/debian/changelog.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h - needs to be in magic format for upload. From owner-linux-xfs@lips.thebarn.com Fri Apr 5 09:25:31 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35FPVPp062662 for linux-xfs-outgoing; Fri, 5 Apr 2002 09:25:31 -0600 (CST) Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35FPTon062657 for ; Fri, 5 Apr 2002 09:25:30 -0600 (CST) Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g35FIrkw021107; Fri, 5 Apr 2002 09:18:54 -0600 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 JAA16094; Fri, 5 Apr 2002 09:18:53 -0600 (CST) Received: from sgi.com (fUIuBtU1DNMTrAWskfWjIIu8slCS+oKc@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA48626; Fri, 5 Apr 2002 09:18:51 -0600 (CST) Message-ID: <3CADC0AD.4080601@sgi.com> Date: Fri, 05 Apr 2002 09:20:13 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: svetljo CC: linux-kernel@vger.kernel.org, linux-xfs@thebarn.com, mkp@mkp.net Subject: Re: REPOST : linux-2.5.5-xfs-dj1 - 2.5.7-dj2 (raid0_make_request bug) References: <3CAD8B9D.8070902@st-peter.stw.uni-erlangen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@thebarn.com Precedence: bulk svetljo wrote: > Hi > i'd like to ask you to CC me because i'm not subscribed to the lists > > i'm having some interesting troubles > i have lvm over soft RAID-0 with LV's formated with XFS and JFS > i can work with the JFS LV's, > but i can not with the XFS one's, i can not mount them ( no troubles > with XFS normal partitions) > > so > i'd like to ask is this problem with XFS or with raid or lvm > and is there a way to fix it > > thanks for your help > > here is what i found in dmesg > > > XFS mounting filesystem lvm(58,2) > raid0_make_request bug: can't convert block across chunks or bigger than > 16k 8323317 64 > raid0_make_request bug: can't convert block across chunks or bigger than > 16k 8323445 64 > I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block > 0x601f7d > ("xlog_bread") error 5 buf count 131072 > raid0_make_request bug: can't convert block across chunks or bigger than > 16k 8324829 29 > I/O error in filesystem ("lvm(58,2)") meta-data dev 0xc0223a02 block > 0x602565 > ("xlog_bread") error 5 buf count 30208 > This is your problem, in the 2.5 code base, the bio infrastructure and the raid code do not work well together. It is being worked on - slowly. If you want to dumb down xfs to make it function then I suspect you can do it by editing fs/xfs/pagebuf/page_buf.c looking for the line which uses BIO_MAX_SECTORS and replace nr_pages = BIO_MAX_SECTORS >> (PAGE_SHIFT - 9); with nr_pages = 1; And for extra bonus points, only do it when pb->pb_dev is on the MD_MAJOR device. This will make xfs send smaller bio structures down to the block layer and hopefully avoid the problem. I have not tested this - don't have any time right now, on a plane in 6 hours and way too much to do. Steve From owner-linux-xfs@lips.thebarn.com Fri Apr 5 10:41:13 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35GfDaa063786 for linux-xfs-outgoing; Fri, 5 Apr 2002 10:41:13 -0600 (CST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35Gf9on063781 for ; Fri, 5 Apr 2002 10:41:09 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host ns.suse.de [213.95.15.193] claimed to be Cantor.suse.de Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id DD26A1E8EF; Fri, 5 Apr 2002 18:41:03 +0200 (MEST) Date: Fri, 5 Apr 2002 18:41:03 +0200 From: Dave Jones To: svetljo Cc: linux-kernel@vger.kernel.org, linux-xfs@thebarn.com Subject: Re: REPOST : linux-2.5.5-xfs-dj1 - 2.5.7-dj2 (raid0_make_request bug) Message-ID: <20020405184103.F14828@suse.de> Mail-Followup-To: Dave Jones , svetljo , linux-kernel@vger.kernel.org, linux-xfs@thebarn.com References: <3CAD8B9D.8070902@st-peter.stw.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CAD8B9D.8070902@st-peter.stw.uni-erlangen.de>; from galia@st-peter.stw.uni-erlangen.de on Fri, Apr 05, 2002 at 01:33:49PM +0200 Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Fri, Apr 05, 2002 at 01:33:49PM +0200, svetljo wrote: > i'm having some interesting troubles > i have lvm over soft RAID-0 with LV's formated with XFS and JFS > i can work with the JFS LV's, > but i can not with the XFS one's, i can not mount them ( no troubles > with XFS normal partitions) > so i'd like to ask is this problem with XFS or with raid or lvm > and is there a way to fix it IIRC, this was reported a while ago, and it was something to do with XFS creating too large requests that upset the raid code. -- | Dave Jones. http://www.codemonkey.org.uk | SuSE Labs From owner-linux-xfs@lips.thebarn.com Fri Apr 5 10:54:14 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35GsEf0064034 for linux-xfs-outgoing; Fri, 5 Apr 2002 10:54:14 -0600 (CST) Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35GsCon064029 for ; Fri, 5 Apr 2002 10:54:13 -0600 (CST) Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g35GrEkw022494; Fri, 5 Apr 2002 10:53:14 -0600 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 KAA18004; Fri, 5 Apr 2002 10:53:14 -0600 (CST) Received: from sgi.com (iCmozvkfX+6l0pd5gMOeo/3MqBlZu4nr@lord-h1.americas.sgi.com [206.11.101.42]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA95405; Fri, 5 Apr 2002 10:53:13 -0600 (CST) Message-ID: <3CADD6CA.8010600@sgi.com> Date: Fri, 05 Apr 2002 10:54:34 -0600 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Dave Jones CC: svetljo , linux-kernel@vger.kernel.org, linux-xfs@thebarn.com Subject: Re: REPOST : linux-2.5.5-xfs-dj1 - 2.5.7-dj2 (raid0_make_request bug) References: <3CAD8B9D.8070902@st-peter.stw.uni-erlangen.de> <20020405184103.F14828@suse.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@thebarn.com Precedence: bulk Dave Jones wrote: >On Fri, Apr 05, 2002 at 01:33:49PM +0200, svetljo wrote: > > i'm having some interesting troubles > > i have lvm over soft RAID-0 with LV's formated with XFS and JFS > > i can work with the JFS LV's, > > but i can not with the XFS one's, i can not mount them ( no troubles > > with XFS normal partitions) > > so i'd like to ask is this problem with XFS or with raid or lvm > > and is there a way to fix it > >IIRC, this was reported a while ago, and it was something to do with >XFS creating too large requests that upset the raid code. > Or the raid code not handling the bio layer too well, depends on your point of view ;-) Steve From owner-linux-xfs@lips.thebarn.com Fri Apr 5 12:38:29 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35IcTPX065099 for linux-xfs-outgoing; Fri, 5 Apr 2002 12:38:29 -0600 (CST) Received: from www.linux.org.uk (IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35IcQon065094 for ; Fri, 5 Apr 2002 12:38:27 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host IDENT:exim@parcelfarce.linux.theplanet.co.uk [195.92.249.252] claimed to be www.linux.org.uk Received: from adsl-64-174-91-61.dsl.sntc01.pacbell.net ([64.174.91.61] helo=zip.com.au) by www.linux.org.uk with esmtp (Exim 3.33 #5) id 16tYbM-0004zA-00; Fri, 05 Apr 2002 19:38:21 +0100 Message-ID: <3CADEEF5.1A73C602@zip.com.au> Date: Fri, 05 Apr 2002 10:37:41 -0800 From: Andrew Morton X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.19-pre5 i686) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Lord CC: Dave Jones , svetljo , linux-kernel@vger.kernel.org, linux-xfs@thebarn.com Subject: Re: REPOST : linux-2.5.5-xfs-dj1 - 2.5.7-dj2 (raid0_make_request bug) References: <3CAD8B9D.8070902@st-peter.stw.uni-erlangen.de> <20020405184103.F14828@suse.de> <3CADD6CA.8010600@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@thebarn.com Precedence: bulk Stephen Lord wrote: > > Dave Jones wrote: > > >On Fri, Apr 05, 2002 at 01:33:49PM +0200, svetljo wrote: > > > i'm having some interesting troubles > > > i have lvm over soft RAID-0 with LV's formated with XFS and JFS > > > i can work with the JFS LV's, > > > but i can not with the XFS one's, i can not mount them ( no troubles > > > with XFS normal partitions) > > > so i'd like to ask is this problem with XFS or with raid or lvm > > > and is there a way to fix it > > > >IIRC, this was reported a while ago, and it was something to do with > >XFS creating too large requests that upset the raid code. > > > Or the raid code not handling the bio layer too well, depends on your point > of view ;-) > Stephen's point of view is correct. RAID0 fails in the same manner with the large pagecache BIOs which I'm feeding it. It fails in the same manner with O_DIRECT on ext2. Neil knows about it, and will get to it. mkp has a 2.4 request splitter which he will turn into a 2.5 BIO splitter. As you said - it's being worked on. - From owner-linux-xfs@lips.thebarn.com Fri Apr 5 14:49:35 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35KnZKr066594 for linux-xfs-outgoing; Fri, 5 Apr 2002 14:49:35 -0600 (CST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35KnXon066589 for ; Fri, 5 Apr 2002 14:49:33 -0600 (CST) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel11.hp.com (Postfix) with ESMTP id 7E02360048F; Fri, 5 Apr 2002 12:49:27 -0800 (PST) Received: from xpabh4.corp.hp.com (xpabh4.corp.hp.com [15.58.136.1]) by xparelay1.corp.hp.com (Postfix) with ESMTP id 3C52AE000AD; Fri, 5 Apr 2002 12:49:17 -0800 (PST) Received: by xpabh4.corp.hp.com with Internet Mail Service (5.5.2653.19) id <2FG7MWZD>; Fri, 5 Apr 2002 12:49:10 -0800 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'Stephen Lord'" Cc: Andi Kleen , "'linux-xfs@thebarn.com'" Subject: RE: heavy VM load due to revamped pagebuf locking? Date: Fri, 5 Apr 2002 12:49:06 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@thebarn.com Precedence: bulk I did a run this morning following Andi's suggestion, reverting all the files in the "TAKE: revamped pagebuf locking" posting. The first SPEC test ran faster, but kswapd still went mad during the second SPEC test init. I didn't get an Alt-Sysrq trace of it, but will later this afternoon. Are there any other XFS changes between Feb 7th and Mar 29th that might affect VM behaviour? Erik > -----Original Message----- > From: Stephen Lord [mailto:lord@sgi.com] > Sent: Thursday, April 04, 2002 10:06 AM > To: HABBINGA,ERIK (HP-Loveland,ex1) > Cc: Andi Kleen; 'linux-xfs@thebarn.com' > Subject: Re: heavy VM load due to revamped pagebuf locking? > > > Andi Kleen wrote: > > >On Thu, Apr 04, 2002 at 11:13:39AM -0500, HABBINGA,ERIK > (HP-Loveland,ex1) wrote: > > > >>I've updated to 2.4.18 w/ a XFS CVS download from > 03/29/2002. During SPEC > >>testing, the VM takes over all CPU load as pagebuf_iostart > starts waiting > >>for memory, and then kmalloc starts waiting for memory. > All of this time > >>spent in shrink_cache causes the SPEC test to time out. > Once the test > >>stops, the box settles down and VM CPU load goes away. All of the > >>shrink_cache functions are waiting for schedule() to come > back, because of > >>the test for current->need_resched at the top of the > shrink_cache loop. For > >>grins, I commented out that test, and now many nfsd > processes are sitting in > >>_pagebuf_find_lockable_buffer->pagebuf_iostart's call to > pagebuf_iowait. > >>Could the revamped pagebuf locking cause this behaviour? > >> > > > >You could test ist. Just revert that TAKE and test again. > > > >-Andi > > > Andi's suggestion is a good one, we have not seen this here, your > configuation is > clearly larger than anything we have locally. > > You might also try just reverting the changes in > page_buf_io.c (you will > need > the header file change). The locking changes should not affect memory > consumption that much, but changes went into this file which > put buffer > heads on pages in more circumstances than we used to. > > Steve > > > From owner-linux-xfs@lips.thebarn.com Fri Apr 5 15:02:34 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35L2YGY066872 for linux-xfs-outgoing; Fri, 5 Apr 2002 15:02:34 -0600 (CST) Received: from structbio.vanderbilt.edu (IDENT:root@reef.structbio.Vanderbilt.Edu [160.129.152.246]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35L2Ton066867 for ; Fri, 5 Apr 2002 15:02:30 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host IDENT:root@reef.structbio.Vanderbilt.Edu [160.129.152.246] claimed to be structbio.vanderbilt.edu Received: from coral (coral [160.129.152.242]) by structbio.vanderbilt.edu (8.11.0/8.11.0) with ESMTP id g35L2Sf18664 for ; Fri, 5 Apr 2002 15:02:29 -0600 Date: Fri, 5 Apr 2002 15:02:28 -0600 From: "Brandon D. Valentine" To: linux-xfs@thebarn.com Subject: block device issues (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@thebarn.com Precedence: bulk Hello, I sent his bug report to linux-kernel@vger.kernel.org recently due to a but of confusion over where XFS related bug reports should go. A reader of that list was kind enough to inform me that you guys are hiding out here until oss.sgi.com is back in good health. Thanks, -- Brandon D. Valentine Computer Geek, Center for Structural Biology "This isn't rocket science -- but it _is_ computer science." - Terry Lambert on current@FreeBSD.org. ---------- Forwarded message ---------- Date: Wed, 3 Apr 2002 16:15:48 -0600 From: Brandon D. Valentine To: linux-kernel@vger.kernel.org Subject: block device issues [Not subscribed so please keep me in the Cc list] Greetings, This past weekend one of our Linux 2.4/XFS fileservers crashed pretty badly. I am attempting to diagnose the cause of the crash so that I may prevent it from recurring. My analysis so far follows. I am hoping that a few of you out there might have seen this before or have ideas on its cause. The symptoms: Saturday morning I discovered the machine had stopped responding to NFS requests. It was still responding to ICMP and I could ssh in. I logged in and found out the load average was at 34. Top revealed no processes using any appreciable amount of CPU time. I tried to tail the logs, but everytime I launched a process like tail, which hit the disk, the process and the terminal it was attached to hung. I attempted the reboot command, but it segfaulted when invoked. Eventually the ssh daemon stopped responding and I was unable to login again. I drug myself into the office on a Saturday morning to find out what was up. When I arrived on the scene and pulled up a console I found the screen littered with a mess of printk's and various other log messages. Most of it was indecipherable due to a healthy smattering of hex addresses and control characters. Since I was unable to get any sort of response on the console, I hit the big red button and waited. The machine came back up, everything appeared to be working, and I went home. When I got there I began diagnosis, which follows, and the machine has been running without incident ever since. The diagnosis: An analysis of the logs reveals that the printk's I had been unable to decipher were in fact triggered by calls to BUG() on line 1033 of linux/drivers/block/ll_rw_blk.c. This particular BUG occurs inside ll_rw_block() as follows: void ll_rw_block(int rw, int nr, struct buffer_head * bhs[]) { ... if (buffer_delay(bh) || !buffer_mapped(bh)) BUG(); ... } Instances of this BUG were logged 22 times before the machine became unresponsive, though it doesn't appear to have ever actually oops'd, just become so heavily loaded that nothing, not even getty at the console, was responding. All of the BUGs that were logged appear to have happened inside processes which would have been heavy on disk io. Some examples include bdflush, amanda's dumper binary (there happened to be a backup run happening at the time), gzip (also via amanda), kupdated, lpd, and updatedb (from locate). I have posted an excerpt of the logs containing all 22 BUGs plus a full dmesg from the reboot here if anyone wants to take a closer look: http://structbio.vanderbilt.edu/~bandix/linux/messages You can also see the amount of time between when syslog quit logging and when the machine was rebooted in that log excerpt. A bit of background on the machine: It's a SuperMicro SuperServer 6041G, in very good shape. We have had no previous problems with it, or with the Linux installation on it. It is presently running RedHat 7.1 XFS (using SGI's install ISO) and the kernel is a known good copy of 2.4.7/XFS pulled from SGI's CVS at the time that this fileserver was setup. At that time 2.4.7 was HEAD in SGI's CVS. This machine had over a 100 day uptime when the crash occured, and had previoulsy only gone down for scheduled maintainence at my discretion. This same combination (RH71 + 2.4.7/XFS) is in use on quite a few of our fileservers here at the Center without incident. It was under fairly heavy disk io at the time the problem developed, but not any amount of disk io that is unusual to this fileserver, it is pretty heavily used. I am not presently familiar with the particulars of linux kernel internals, but I would like to figure out why my fileserver crashed, and if possible, prevent it from happening again. Do any of you have any ideas on what would have caused those kernel BUGs or the subsequent crash? Unfortunately I don't have an Oops.file, since it never actually Oops'd. Awaiting your thoughts, -- Brandon D. Valentine Computer Geek, Center for Structural Biology "This isn't rocket science -- but it _is_ computer science." - Terry Lambert on current@FreeBSD.org. From owner-linux-xfs@lips.thebarn.com Fri Apr 5 15:24:46 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35LOkVB067211 for linux-xfs-outgoing; Fri, 5 Apr 2002 15:24:46 -0600 (CST) Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35LOjon067206 for ; Fri, 5 Apr 2002 15:24:45 -0600 (CST) Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g35LOYkw025911; Fri, 5 Apr 2002 15:24:34 -0600 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 PAA77976; Fri, 5 Apr 2002 15:24:34 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA34378; Fri, 5 Apr 2002 15:24:33 -0600 (CST) Subject: Re: block device issues (fwd) From: Eric Sandeen To: "Brandon D. Valentine" Cc: linux-xfs@thebarn.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 05 Apr 2002 15:24:33 -0600 Message-Id: <1018041873.7110.36.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@thebarn.com Precedence: bulk Hi Brandon - On Fri, 2002-04-05 at 15:02, Brandon D. Valentine wrote: > [Not subscribed so please keep me in the Cc list] > > Greetings, > > This past weekend one of our Linux 2.4/XFS fileservers crashed pretty > badly. I am attempting to diagnose the cause of the crash so that I may > prevent it from recurring. My analysis so far follows. I am hoping > that a few of you out there might have seen this before or have ideas on > its cause. > void ll_rw_block(int rw, int nr, struct buffer_head * bhs[]) > { > ... > if (buffer_delay(bh) || !buffer_mapped(bh)) > BUG(); > ... > } > presently running RedHat 7.1 XFS (using SGI's install ISO) and the > kernel is a known good copy of 2.4.7/XFS pulled from SGI's CVS at the > time that this fileserver was setup The reason that BUG() is there is that if we get to ll_rw_block, ready to send a buffer to disk, but we have no place to put it (i.e. it's a delalloc buffer, or it's not mapped) then we're in trouble. How you got here, I'm not certain, but going back to debug a 2.4.7 kernel is going to be rough - there have been so many changes since then. We are working on a release for XFS 1.1 (yours was 1.0 or 1.0.1, I think?) and if possible, I would suggest that you upgrade a box or two and see how that goes. If nothing else, the updated kernels based on Red Hat code have some security issues fixed. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@lips.thebarn.com Fri Apr 5 15:51:55 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35LptoP067585 for linux-xfs-outgoing; Fri, 5 Apr 2002 15:51:55 -0600 (CST) Received: from mathserv.math.ohio-state.edu (IDENT:root@mathserv.math.ohio-state.edu [128.146.111.31]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35Lpron067580 for ; Fri, 5 Apr 2002 15:51:53 -0600 (CST) Received: from math.ohio-state.edu (zaphod.math.ohio-state.edu [128.146.111.36]) by mathserv.math.ohio-state.edu (8.12.2/8.12.2) with ESMTP id g35LpqxQ024979 for ; Fri, 5 Apr 2002 16:51:52 -0500 Received: by math.ohio-state.edu (Postfix, from userid 500) id 805102D8421; Fri, 5 Apr 2002 16:51:52 -0500 (EST) Date: Fri, 5 Apr 2002 16:51:52 -0500 From: Dave Alden To: linux-xfs@thebarn.com Subject: latest quota tools? Message-ID: <20020405165152.A2763@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-RAVMilter-Version: 8.3.2(snapshot 20020213) (mathserv) Sender: owner-linux-xfs@thebarn.com Precedence: bulk Hi, I'm running a recent kernel from the XFS CVS tree. :-) I'm also running quota-tools 3.04 from http://www.sf.net/projects/linuxquota. I'm getting the error "Kernel quota is newer than supported." I've tried downloading the CVS version from sourceforge, but it looks like it isn't complete (it tries to use "quotaio_generic.h", but that doesn't seem to be in the tree). Anyone know how to get the latest version of quota-tools? ...thnx, ...dave From owner-linux-xfs@lips.thebarn.com Fri Apr 5 16:10:10 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35MAApJ067866 for linux-xfs-outgoing; Fri, 5 Apr 2002 16:10:10 -0600 (CST) Received: from UberGeek ([209.184.141.163]) by lips.thebarn.com (8.12.2/8.12.0) with SMTP id g35MA7on067858 for ; Fri, 5 Apr 2002 16:10:08 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host [209.184.141.163] claimed to be UberGeek Received: (qmail 23634 invoked by uid 500); 5 Apr 2002 22:09:32 -0000 Subject: Re: block device issues (fwd) From: Austin Gonyou To: Eric Sandeen Cc: "Brandon D. Valentine" , linux-xfs@thebarn.com In-Reply-To: <1018041873.7110.36.camel@stout.americas.sgi.com> References: <1018041873.7110.36.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 05 Apr 2002 16:09:32 -0600 Message-Id: <1018044572.23584.2.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@thebarn.com Precedence: bulk Agreed. I think that anything pre 2.4.10 is not worth using. There are too many generic scalability issues that gave 2.4 it's reputation. On Fri, 2002-04-05 at 15:24, Eric Sandeen wrote: > Hi Brandon - > > On Fri, 2002-04-05 at 15:02, Brandon D. Valentine wrote: > > > [Not subscribed so please keep me in the Cc list] > > > > Greetings, > > > > This past weekend one of our Linux 2.4/XFS fileservers crashed pretty > > badly. I am attempting to diagnose the cause of the crash so that I > may > > prevent it from recurring. My analysis so far follows. I am hoping > > that a few of you out there might have seen this before or have ideas > on > > its cause. > > > void ll_rw_block(int rw, int nr, struct buffer_head * bhs[]) > > { > > ... > > if (buffer_delay(bh) || !buffer_mapped(bh)) > > BUG(); > > ... > > } > > > presently running RedHat 7.1 XFS (using SGI's install ISO) and the > > kernel is a known good copy of 2.4.7/XFS pulled from SGI's CVS at the > > time that this fileserver was setup > > The reason that BUG() is there is that if we get to ll_rw_block, ready > to send a buffer to disk, but we have no place to put it (i.e. it's a > delalloc buffer, or it's not mapped) then we're in trouble. > > How you got here, I'm not certain, but going back to debug a 2.4.7 > kernel is going to be rough - there have been so many changes since > then. > > We are working on a release for XFS 1.1 (yours was 1.0 or 1.0.1, I > think?) and if possible, I would suggest that you upgrade a box or two > and see how that goes. If nothing else, the updated kernels based on > Red Hat code have some security issues fixed. :) > > -Eric > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@lips.thebarn.com Fri Apr 5 17:55:11 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g35NtBFj068925 for linux-xfs-outgoing; Fri, 5 Apr 2002 17:55:11 -0600 (CST) Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g35Nt5on068919 for ; Fri, 5 Apr 2002 17:55:09 -0600 (CST) Received: from erbenson.alaska.net (75-pm18.nwc.alaska.net [209.112.142.75]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g35NsQQ08040 for ; Fri, 5 Apr 2002 14:54:39 -0900 (AKST) (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 E7EA73939 for ; Fri, 5 Apr 2002 14:53:35 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 0AA5710281; Fri, 5 Apr 2002 14:53:36 -0900 (AKST) Date: Fri, 5 Apr 2002 14:53:36 -0900 From: Ethan Benson To: linux-xfs@thebarn.com Subject: Re: latest quota tools? Message-ID: <20020405145335.E1524@plato.local.lan> References: <20020405165152.A2763@math.ohio-state.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020405165152.A2763@math.ohio-state.edu>; from alden@math.ohio-state.edu on Fri, Apr 05, 2002 at 04:51:52PM -0500 X-OS: Debian GNU Sender: owner-linux-xfs@thebarn.com Precedence: bulk --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 05, 2002 at 04:51:52PM -0500, Dave Alden wrote: > Hi, > I'm running a recent kernel from the XFS CVS tree. :-) I'm also runni= ng > quota-tools 3.04 from http://www.sf.net/projects/linuxquota. I'm getting > the error "Kernel quota is newer than supported." I've tried downloading > the CVS version from sourceforge, but it looks like it isn't complete (it > tries to use "quotaio_generic.h", but that doesn't seem to be in the tree= ). > Anyone know how to get the latest version of quota-tools? > ...thnx, > ...dave the current debian packages work, they have version 3.0.4 but some patches were applied by debian, you could compile thier source package with the patches, or just install the binary, if your not using debian with this command: (after deinstalling any quota packages you already have) cd / ar -p data.tar.gz quota_3.04-1_i386.deb | tar -zxvp ftp://mirrors.kernel.org/debian/pool/main/q/quota/ --=20 Ethan Benson http://www.alaska.net/~erbenson/ --iVCmgExH7+hIHJ1A 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 iEYEARECAAYFAjyuOP8ACgkQJKx7GixEevxLrgCfXGN7T6XofshJ+nChObTkoCke 07AAoIma+nd9oT6R59Snd7rGZX1mjTiI =4Omo -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A-- From owner-linux-xfs@lips.thebarn.com Fri Apr 5 22:23:12 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g364NCbb070337 for linux-xfs-outgoing; Fri, 5 Apr 2002 22:23:12 -0600 (CST) Received: from localhost.localdomain (dsl092-196-016.sea1.dsl.speakeasy.net [66.92.196.16]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g364NAon070332 for ; Fri, 5 Apr 2002 22:23:10 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host dsl092-196-016.sea1.dsl.speakeasy.net [66.92.196.16] claimed to be localhost.localdomain Received: (from jcoffin@localhost) by localhost.localdomain (8.11.6/8.11.2) id g364YU124949; Fri, 5 Apr 2002 20:34:30 -0800 X-Authentication-Warning: localhost.localdomain: jcoffin set sender to jcoffin@brown-dog.org using -f To: linux-xfs@thebarn.com Subject: xfsdump question From: Jeff Coffin Date: 05 Apr 2002 20:34:30 -0800 Message-ID: Lines: 44 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@thebarn.com Precedence: bulk Hi All, Another happy XFS user with a question. I just did an xfsdump which appeared normal, but at the end I got: [snipped] xfsdump: creating dump session media file 37 (media 0, file 38) xfsdump: dumping ino map xfsdump: dumping directories xfsdump: dumping non-directory files xfsdump: ending media file xfsdump: media file size 36700160 bytes xfsdump: dumping session inventory xfsdump: beginning inventory media file xfsdump: media file 38 (media 0, file 39) xfsdump: ending inventory media file xfsdump: inventory media file size 2097152 bytes xfsdump: writing stream terminator xfsdump: beginning media stream terminator xfsdump: media file 39 (media 0, file 40) xfsdump: ending media stream terminator xfsdump: media stream terminator size 1048576 bytes xfsdump: dump size (non-dir files) : 10021758872 bytes xfsdump: dump complete: 8012 seconds elapsed xfsdump: Dump Status: INCOMPLETE So is there a problem or not? No complaints from the kernel or anything. I'm running a 2.4.18 CVS kernel (3/1/2002), prememt 2.4.18-4 and an openssl/mppe patch (ftp://planetmirror.com/pub/mppe/linux-2.4.16-openssl-0.9.6b-mppe.patch.gz) so I can use a pptp tunnel for work. I recently updated all the xfs cmd's from the RPMs built from the same cvs update as the kernel via the build scripts. I'm writing to a Quantum DLT4000. --jeff From owner-linux-xfs@lips.thebarn.com Sat Apr 6 02:41:16 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g368fGcV072005 for linux-xfs-outgoing; Sat, 6 Apr 2002 02:41:16 -0600 (CST) Received: from iris.slb.nwc.acsalaska.net (iris.slb.nwc.acsalaska.net [209.112.155.43]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g368fDon072000 for ; Sat, 6 Apr 2002 02:41:14 -0600 (CST) Received: from erbenson.alaska.net (227-pm32.nwc.alaska.net [209.112.158.227]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g368f4B75937; Fri, 5 Apr 2002 23:41:05 -0900 (AKST) (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 61BA13939; Fri, 5 Apr 2002 23:41:03 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 31DA410281; Fri, 5 Apr 2002 23:41:03 -0900 (AKST) Date: Fri, 5 Apr 2002 23:41:03 -0900 From: Ethan Benson To: linux-xfs@thebarn.com Cc: Andreas Gruenbacher Subject: extended attributes security problem Message-ID: <20020405234103.F1524@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xA/XKXTdy9G3iaIz" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Sender: owner-linux-xfs@thebarn.com Precedence: bulk --xA/XKXTdy9G3iaIz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I have found an annoying problem with extended attributes in regards to security. =20 normal user.* attributes are controlled by the file's standard permission bits (or acl), however this becomes a bit of a problem on device files in /dev many of which must be world writable. my security policy involves farming off /usr, /var, /tmp, and /home to other filesystems to ensure unprivileged users have NO write access to / whatsoever, world writable devices don't count since writing to them does not actually write to the root filesystem. given this policy there is no need for quotas on / however users are allowed to apply an unlimited number of extended attributes to /dev/pty*, /dev/null and other assorted devices which must be writable. not only does this potentially allow users to fill up the / partition with hundreds of attributes containing irrelevant data, it allows them to squirrel away data in a semi hidden way. i have also found that this has the interesting side affect of making symlink permissions not so irrelevant, users may apply extended attributes to world writable symlinks (using the -h switch to setfattr) but not to non-writable symlinks. again this is annoying given filesystems converted from ext2 or similar via cpio will have all symlinks world writable instead of 755 (or whatever the umask dictates on creation of the link). the way i see it there are only a few options for fixing these issues: 1) some sort of mount options to change xattr semantecs, for example perhaps nouattr to disallow unprivileged users to apply user.* attributes (or maybe restrict to file owner regardless of the permission bits), this would be mostly sufficient to fix my gripe, i would just mount / with nouattr, it may not solve other world writable directories on the system, or symlinks. 2) apply a different sementec on special files, for regular files and directories use the current method of using the permission bits to control access to xattrs, but for special files such as block devices, char devices, sockets etc only allow the file's owner to add/remove xattrs. =20 3) for directories, only allow xattrs to be written by the directories owner if the sticky bit is set (this would prevent users from spewing attrs on /tmp /var/tmp and other world writable sticky system directories. =20 4) add a seperate ACL for control of xattrs, this is the approach NT takes (actually to be more specific NT ACLs have seperate read and write permission bits for the xattr and the file data itself). IMO option 4 is probably the cleanest most consistent solution, but also the least trivial to implement. a combination of option 2 and 3 seems to be to be fairly natural and would solve the most common places where using permission bits to control xattrs is clearly innappropriate (/dev/* 1777 system dirs symlinks etc). ignoring it is not an acceptable option IMO since i consider it a security hole that users may attach attributes to system files. the symlink issue is especially annoying since there isn't a real way to change symlink permissions other then changing your umask and recreating the symlink (it also violates the anchient understanding that symlink permissions are irrelevant). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --xA/XKXTdy9G3iaIz 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 iEYEARECAAYFAjyutJ8ACgkQJKx7GixEevxGkgCeNb860afB5QHUW/fbKOsGpYT7 lVEAn0A2nfCfGVaSWzD7qkdHAvu2Yiee =qs91 -----END PGP SIGNATURE----- --xA/XKXTdy9G3iaIz-- From owner-linux-xfs@lips.thebarn.com Sat Apr 6 02:58:34 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g368wYE0072354 for linux-xfs-outgoing; Sat, 6 Apr 2002 02:58:34 -0600 (CST) Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g368wWon072349 for ; Sat, 6 Apr 2002 02:58:32 -0600 (CST) Received: from erbenson.alaska.net (227-pm32.nwc.alaska.net [209.112.158.227]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g368wUw77741 for ; Fri, 5 Apr 2002 23:58:30 -0900 (AKST) (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 5F2CA3939 for ; Fri, 5 Apr 2002 23:58:29 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 8333210281; Fri, 5 Apr 2002 23:58:29 -0900 (AKST) Date: Fri, 5 Apr 2002 23:58:29 -0900 From: Ethan Benson To: linux-xfs@thebarn.com Subject: mtime permission Message-ID: <20020405235829.G1524@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V4b9U9vrdWczvw78" Content-Disposition: inline User-Agent: Mutt/1.2.5i X-OS: Debian GNU Sender: owner-linux-xfs@thebarn.com Precedence: bulk --V4b9U9vrdWczvw78 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable after more thought regarding xattrs, i looked at the sementecs regarding users changing traditional attributes on world writable files they don't own, in this case mtime and noticed a bug in XFS. on ext2 filesystems if i attempt to set the mtime of a file i don't own (but do have write permission to) to anything but the current time i get -EPERM, but on XFS im allowed to do whatever i want: eb@dogbert ~$ mount | grep -w / /dev/hda3 on / type xfs (rw) eb@dogbert ~$ mount | grep /mnt /dev/hda4 on /mnt type ext2 (rw) eb@dogbert ~$ ls -l /dev/null /mnt/null crw-rw-rw- 1 root root 1, 3 Jun 28 2001 /dev/null crw-rw-rw- 1 root root 1, 3 Apr 5 23:47 /mnt/null eb@dogbert ~$ touch -r /etc/passwd /mnt/null touch: setting times of `/mnt/null': Operation not permitted eb@dogbert ~$ touch -r /etc/passwd /dev/null eb@dogbert ~$ ls -l /etc/passwd /dev/null crw-rw-rw- 1 root root 1, 3 Feb 16 06:00 /dev/null -rw-r--r-- 1 root root 1408 Feb 16 06:00 /etc/passwd eb@dogbert ~$ ls -l /dev/null /mnt/null crw-rw-rw- 1 root root 1, 3 Feb 16 06:00 /dev/null crw-rw-rw- 1 root root 1, 3 Apr 5 23:47 /mnt/null eb@dogbert ~$ the same is true for setting time in the future, also the same applies to normal files as opposed to regular files. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --V4b9U9vrdWczvw78 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 iEYEARECAAYFAjyuuLUACgkQJKx7GixEevzybQCeMNCYbQhTwNj9jTQBnZRb8mGK vY4An2952z6ll6FIzKVq5bM/37yHZXAA =ZWy0 -----END PGP SIGNATURE----- --V4b9U9vrdWczvw78-- From owner-linux-xfs@lips.thebarn.com Sat Apr 6 04:10:23 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g36AAN6A073131 for linux-xfs-outgoing; Sat, 6 Apr 2002 04:10:23 -0600 (CST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g36AALon073126 for ; Sat, 6 Apr 2002 04:10:21 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host ns.suse.de [213.95.15.193] claimed to be Cantor.suse.de Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 10A811EA7E; Sat, 6 Apr 2002 12:10:18 +0200 (MEST) Date: Sat, 6 Apr 2002 12:10:11 +0200 From: Andi Kleen To: Ethan Benson Cc: linux-xfs@thebarn.com, Andreas Gruenbacher Subject: Re: extended attributes security problem Message-ID: <20020406121011.B11177@wotan.suse.de> References: <20020405234103.F1524@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020405234103.F1524@plato.local.lan> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Fri, Apr 05, 2002 at 11:41:03PM -0900, Ethan Benson wrote: > > Hi, > > I have found an annoying problem with extended attributes in regards > to security. Have you actually tested this? The EA limit is 64K per inode and there is an inode space limit on the XFS fs too (normally 25% of the disk space). So you can never actually allocate more than 25% of disk space this way or even less if you use a different mkfs option. If you set the maximum inode space to 5% and always keep >5% free you should be pretty safe. -Andi From owner-linux-xfs@lips.thebarn.com Sat Apr 6 04:42:56 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g36Agu7K075937 for linux-xfs-outgoing; Sat, 6 Apr 2002 04:42:56 -0600 (CST) Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g36Agson075932 for ; Sat, 6 Apr 2002 04:42:54 -0600 (CST) Received: from erbenson.alaska.net (227-pm32.nwc.alaska.net [209.112.158.227]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g36AgdQ26870; Sat, 6 Apr 2002 01:42:39 -0900 (AKST) (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 BEF6C3939; Sat, 6 Apr 2002 01:42:37 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id C44B610281; Sat, 6 Apr 2002 01:42:37 -0900 (AKST) Date: Sat, 6 Apr 2002 01:42:37 -0900 From: Ethan Benson To: Andi Kleen Cc: linux-xfs@thebarn.com, Andreas Gruenbacher Subject: Re: extended attributes security problem Message-ID: <20020406014237.H1524@plato.local.lan> References: <20020405234103.F1524@plato.local.lan> <20020406121011.B11177@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1giRMj6yz/+FOIRq" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020406121011.B11177@wotan.suse.de>; from ak@suse.de on Sat, Apr 06, 2002 at 12:10:11PM +0200 X-OS: Debian GNU Sender: owner-linux-xfs@thebarn.com Precedence: bulk --1giRMj6yz/+FOIRq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 06, 2002 at 12:10:11PM +0200, Andi Kleen wrote: > On Fri, Apr 05, 2002 at 11:41:03PM -0900, Ethan Benson wrote: > >=20 > > Hi, > >=20 > > I have found an annoying problem with extended attributes in regards > > to security. =20 >=20 > Have you actually tested this? The EA limit is 64K per inode and there=20 s/per inode/per attribute/ > is an inode space limit on the XFS fs too (normally 25% of the disk space= ). > So you can never actually allocate more than 25% of disk space this way > or even less if you use a different mkfs option. If you set the maximum > inode space to 5% and always keep >5% free you should be pretty safe. please try this: for i in `seq 2000` ; do setfattr -n user.bloat$i -v `perl -e 'print "a" x = 65536'` /dev/null ; done this started failing with: setfattr: /dev/null: No space left on device setfattr: /dev/null: No space left on device setfattr: /dev/null: No space left on device setfattr: /dev/null: No space left on device setfattr: /dev/null: No space left on device setfattr: /dev/null: No space left on device =2E.. when it completly filled my 68MB / filesystem (it was only about 50% full). if you have a larger filesystem increase the argument to seq until it provides desired DoS. =20 it gets worse, i could not remove the attributes due to No space left on device, i had to rm /dev/null and recreate it, (then kill all processes holding it open) before i was able to recover the disk space. so having done a full scale test i think this is a severe security hole. i also just realized since /dev/null is owned by root quotas can't help much since you would have to apply quotas against root which is really quite silly and non-useful. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --1giRMj6yz/+FOIRq 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 iEYEARECAAYFAjyu0R0ACgkQJKx7GixEevzyZQCdGEYgFgm76J6p8m5vHS5Zs6NN KkYAnjT+OQW2+s6XO+i1pNfpF5zSOMiZ =g3fk -----END PGP SIGNATURE----- --1giRMj6yz/+FOIRq-- From owner-linux-xfs@lips.thebarn.com Sat Apr 6 04:53:24 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g36ArOUa076135 for linux-xfs-outgoing; Sat, 6 Apr 2002 04:53:24 -0600 (CST) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g36ArMon076130 for ; Sat, 6 Apr 2002 04:53:23 -0600 (CST) X-Authentication-Warning: lips.thebarn.com: Host ns.suse.de [213.95.15.193] claimed to be Cantor.suse.de Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 6C1E01E9F3; Sat, 6 Apr 2002 12:53:22 +0200 (MEST) Date: Sat, 6 Apr 2002 12:53:20 +0200 From: Andi Kleen To: Ethan Benson Cc: Andi Kleen , linux-xfs@thebarn.com, Andreas Gruenbacher Subject: Re: extended attributes security problem Message-ID: <20020406125320.A17644@wotan.suse.de> References: <20020405234103.F1524@plato.local.lan> <20020406121011.B11177@wotan.suse.de> <20020406014237.H1524@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020406014237.H1524@plato.local.lan> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Sat, Apr 06, 2002 at 01:42:37AM -0900, Ethan Benson wrote: > On Sat, Apr 06, 2002 at 12:10:11PM +0200, Andi Kleen wrote: > > On Fri, Apr 05, 2002 at 11:41:03PM -0900, Ethan Benson wrote: > > > > > > Hi, > > > > > > I have found an annoying problem with extended attributes in regards > > > to security. > > > > Have you actually tested this? The EA limit is 64K per inode and there > > s/per inode/per attribute/ True. > > > is an inode space limit on the XFS fs too (normally 25% of the disk space). > > So you can never actually allocate more than 25% of disk space this way > > or even less if you use a different mkfs option. If you set the maximum > > inode space to 5% and always keep >5% free you should be pretty safe. > > please try this: > > for i in `seq 2000` ; do setfattr -n user.bloat$i -v `perl -e 'print "a" x 65536'` /dev/null ; done > > this started failing with: > setfattr: /dev/null: No space left on device > setfattr: /dev/null: No space left on device > setfattr: /dev/null: No space left on device > setfattr: /dev/null: No space left on device > setfattr: /dev/null: No space left on device > setfattr: /dev/null: No space left on device > ... > > when it completly filled my 68MB / filesystem (it was only about 50% > full). if you have a larger filesystem increase the argument to seq > until it provides desired DoS. > > it gets worse, i could not remove the attributes due to No space left > on device, i had to rm /dev/null and recreate it, (then kill all > processes holding it open) before i was able to recover the disk > space. > > so having done a full scale test i think this is a severe security > hole. i also just realized since /dev/null is owned by root quotas > can't help much since you would have to apply quotas against root > which is really quite silly and non-useful. I agree. -Andi From owner-linux-xfs@lips.thebarn.com Sat Apr 6 10:28:51 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g36GSpc4078399 for linux-xfs-outgoing; Sat, 6 Apr 2002 10:28:51 -0600 (CST) Received: from muriel.parsec.at (muriel.parsec.at [212.236.50.199]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g36GSlon078394 for ; Sat, 6 Apr 2002 10:28:49 -0600 (CST) Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g36GSg817963; Sat, 6 Apr 2002 18:28:42 +0200 Date: Sat, 6 Apr 2002 18:28:42 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Ethan Benson cc: Subject: Re: extended attributes security problem In-Reply-To: <20020405234103.F1524@plato.local.lan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Fri, 5 Apr 2002, Ethan Benson wrote: > > Hi, > > I have found an annoying problem with extended attributes in regards > to security. I just *knew* user EA's on symlinks and special files were fishy. It was only recently that I have removed the code that was blocking user EA's for those inodes, to conform with XFS semantics. How stupid of me! > normal user.* attributes are controlled by the file's standard > permission bits (or acl), however this becomes a bit of a problem on > device files in /dev many of which must be world writable. my > security policy involves farming off /usr, /var, /tmp, and /home to > other filesystems to ensure unprivileged users have NO write access to > / whatsoever, world writable devices don't count since writing to them > does not actually write to the root filesystem. given this policy > there is no need for quotas on / > > however users are allowed to apply an unlimited number of extended > attributes to /dev/pty*, /dev/null and other assorted devices which > must be writable. not only does this potentially allow users to fill > up the / partition with hundreds of attributes containing irrelevant > data, it allows them to squirrel away data in a semi hidden way. > > i have also found that this has the interesting side affect of making > symlink permissions not so irrelevant, users may apply extended > attributes to world writable symlinks (using the -h switch to > setfattr) but not to non-writable symlinks. again this is > annoying given filesystems converted from ext2 or similar via cpio > will have all symlinks world writable instead of 755 (or whatever the > umask dictates on creation of the link). > > the way i see it there are only a few options for fixing these issues: > > 1) some sort of mount options to change xattr semantecs, for example > perhaps nouattr to disallow unprivileged users to apply user.* > attributes (or maybe restrict to file owner regardless of the > permission bits), this would be mostly sufficient to fix my gripe, i > would just mount / with nouattr, it may not solve other > world writable directories on the system, or symlinks. This does not address the real problem, and therefore makes no sense. > 2) apply a different sementec on special files, for regular files and > directories use the current method of using the permission bits to > control access to xattrs, but for special files such as block devices, > char devices, sockets etc only allow the file's owner to add/remove > xattrs. This would be at least possible. > 3) for directories, only allow xattrs to be written by the directories > owner if the sticky bit is set (this would prevent users from spewing > attrs on /tmp /var/tmp and other world writable sticky system > directories. Why should we introduce quircks like this? All the messing around with the sticky bit for directories has a single reason: The rwx permission scheme just is too weak to allow everybody to create files, without also allowing everybody to delete arbitrary files. For many it may be hard to admit that the directory sticky bit thing is an ugly workaround for emulating create permissions. Even POSIX ACLs don't solve this, but additional permissions such as create and delete would provide a clean solution. > 4) add a seperate ACL for control of xattrs, this is the approach NT > takes (actually to be more specific NT ACLs have seperate read and > write permission bits for the xattr and the file data itself). > > IMO option 4 is probably the cleanest most consistent solution, but > also the least trivial to implement. a combination of option 2 and 3 > seems to be to be fairly natural and would solve the most common places > where using permission bits to control xattrs is clearly > innappropriate (/dev/* 1777 system dirs symlinks etc). Apart from being more complicated to implement, permissions for individual EA's would also be much more difficult to understand, and to use correctly, and we would need a tool for manipulating them. I am very much opposed to this idea, as this seems overly complex, and completely unnecessary. The comparison with Windows NT is not valid for several reasons: (a) Windows NT does not have device special files, so we have to deal with different semantics. (b) Windows NT does not use EA's, but uses forks, similar to the Macintosh HFS. Forks are the same as regular files, they are only "hidden" behind the name of another file. The first question we should try to answer is, what are the semantics of user EA's for special files and inodes, and do they make sense. We have defined user EA's as attributes users may associate with a file, according to the same access restrictions as the file contents. I think these semantics are clear, and easy to understand. Now for symlinks and special files the permissions have a different meaning. Let's first discuss special files. The permissions of a special file inode denote which accesses are permitted to the device the inode is describing. It is possible to have a device inode, such as /dev/null, on a read-only file system, and it's still permitted to make information disappear by piping it to /dev/null. If we use the same permissions to determine the permissions for special file EA's, then we end up with the anomaly (and security hole) that Ethan has described. If we use different rules such as inode ownership to determine access, then the semantics become relatively complicated. I think this is neither necessary nor useful. So my conclusion is that we should disallow user EA's for special files. For symlinks the situation is similar. The permissions of a symlink have nothing to do with the contents of the symlink, but they denote permission to traverse the symlink. Also, the traditional Linux file systems ext2 and ext3 don't even allow permissions for symlinks; the permissions are always initialized with S_IRWXUGO. Again, one of the questions that come to mind is, do we have a need for symlink user EA's? With the existing user EA permission model, I don't see any reason supporting this. My conclusion, again, is to disallow user EA's for symlinks. We have been discussing useful EA namespaces before. In addition to the system and user namespaces, we had two additional namespaces that might be useful future extensions. I have recently given this description of these EA namespace on the ext2-devel mailing list: SYSTEM Used internally by the kernel; access permissions depend on the policy implemented in the kernel, and may differ from attribute to attribute. There may be restrictions on the values that a system attribute may obtain, e.g., ACL values must be valid. USER Attributes regular users can use. Read and write access is controlled by the usual file permissions, so everyone who is allowed X access to the file data is also allowed X acces on its user EA's. TRUSTED Attributes only trusted processes may use. This would be useful for implementing OS extensions in user space that use EA's which must not otherwise be accessible to users. Another application could be backup labels, for example. The trust status of a process could be defined by a capability. OWNER Attributes only accessible to the owner of an object. This is a bit obscure; I have no good example for this namespace. The set of namespaces proposed above ties the permissions needed for accessing a class of EA's to the namespace. I think this is a very useful simplification. The system namespace is a bit of an exception, since the permissions differ between individual system attributes. This is necessary to support the semantics of ACLs, Capabilities, MAC and audit labels, etc. through the EA interfaces; I think this special role of the system namespace is an acceptable compromise, instead of introducing separate namespaces for each slightly differing new concept we may add in the future. Ethan's option (2) amounts to the semantics of the proposed owner namespace. I suggest not to mix semantics within the user namespace. It may some day turn out that the owner namespace is a useful thing, for files, directories, special files, etc. That would be the day to introduce the owner namespace. Keeping the user and owner namespaces distinct is much more transparent semantically. > ignoring it is not an acceptable option IMO since i consider it a > security hole that users may attach attributes to system files. Quite right. Did my arguing and conclusions make sense to you? Cheers, Andreas. From owner-linux-xfs@lips.thebarn.com Sat Apr 6 13:34:49 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g36JYnBM079751 for linux-xfs-outgoing; Sat, 6 Apr 2002 13:34:49 -0600 (CST) Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g36JYion079746 for ; Sat, 6 Apr 2002 13:34:48 -0600 (CST) Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g36JYMkw028571 for ; Sat, 6 Apr 2002 13:34:22 -0600 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA34910 for ; Sat, 6 Apr 2002 13:34:22 -0600 (CST) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA86941 for ; Sat, 6 Apr 2002 13:34:22 -0600 (CST) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g36JYMR26898; Sat, 6 Apr 2002 13:34:22 -0600 Message-Id: <200204061934.g36JYMR26898@stout.americas.sgi.com> Date: Sat, 6 Apr 2002 13:34:22 -0600 From: Eric Sandeen Subject: TAKE - Merge merge irix6.5f:irix:115876a Sender: owner-linux-xfs@thebarn.com Precedence: bulk If you don't have filesystems over 1 Terabyte, you had no problem with this. The 32-bit inode feature introduced previously can cause a system to panic or return an EFSCORRUPTED error when used on a filesystem that was created prior to the introduction of that feature. The problem occurs when starting a search for space to allocate an inode in an allocation group > 1 Terabyte. The code does not properly check for the last AG to scan. Date: Sat Apr 6 11:32:00 PST 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:115905a linux/fs/xfs/xfs_ialloc.c - 1.154 - merge irix6.5f:irix:115876a fix xfs_ialloc_ag_select to not walk off the end of the perag list when the starting inode number is beyond the maximum AG to put inodes in. From owner-linux-xfs@lips.thebarn.com Sat Apr 6 18:19:23 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g370JNdq081474 for linux-xfs-outgoing; Sat, 6 Apr 2002 18:19:23 -0600 (CST) Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g370JLon081469 for ; Sat, 6 Apr 2002 18:19:21 -0600 (CST) Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g370Io6G021076; Sat, 6 Apr 2002 16:18:50 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA41520; Sat, 6 Apr 2002 16:18:48 -0800 (PST) Date: Sat, 6 Apr 2002 18:18:47 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Andi Kleen cc: Ethan Benson , , Andreas Gruenbacher Subject: Re: extended attributes security problem In-Reply-To: <20020406121011.B11177@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Sat, 6 Apr 2002, Andi Kleen wrote: > Have you actually tested this? The EA limit is 64K per inode and there > is an inode space limit on the XFS fs too (normally 25% of the disk space). Are you sure about this? I think the limit is 64k per attribute; you can still have multiple 64k attributes. I made a tiny xfs filesystem to test this, then made a 0-byte file and added 64K attributes until I ran out of space: [root@lite sda2]# pwd /mnt/sda2 [root@lite sda2]# ls -la total 4 drwxr-xr-x 2 root root 16 Apr 6 18:01 . drwxr-xr-x 11 root root 4096 Mar 19 11:44 .. -rw-r--r-- 1 root root 0 Apr 6 17:58 foo [root@lite sda2]# df -h | grep sda2 /dev/sda2 1.3M 1.3M 28k 98% /mnt/sda2 [root@lite sda2]# xfs_info /mnt/sda2 meta-data=/mnt/sda2 isize=256 agcount=1, agsize=1536 blks data = bsize=4096 blocks=1536, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 so apparently the attr stored outside the inode does not count as inode space in imaxpct. -Eric From owner-linux-xfs@lips.thebarn.com Sat Apr 6 18:26:34 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g370QYUx081646 for linux-xfs-outgoing; Sat, 6 Apr 2002 18:26:34 -0600 (CST) Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g370QWon081641 for ; Sat, 6 Apr 2002 18:26:33 -0600 (CST) Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g370Q56G021306; Sat, 6 Apr 2002 16:26:05 -0800 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id QAA03105; Sat, 6 Apr 2002 16:26:03 -0800 (PST) Date: Sat, 6 Apr 2002 18:26:02 -0600 (CST) From: Eric Sandeen X-X-Sender: To: Andi Kleen cc: Ethan Benson , , Andreas Gruenbacher Subject: Re: extended attributes security problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Sat, 6 Apr 2002, Eric Sandeen wrote: > I made a tiny xfs filesystem to test this, then made a 0-byte file and > added 64K attributes until I ran out of space: And then I read Ethan's mail from earlier today... whoops. :) -Eric From owner-linux-xfs@lips.thebarn.com Sat Apr 6 19:10:52 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g371Aq52082102 for linux-xfs-outgoing; Sat, 6 Apr 2002 19:10:52 -0600 (CST) Received: from malik.slb.nwc.acsalaska.net (malik.slb.nwc.acsalaska.net [209.112.155.41]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g371Anon082097 for ; Sat, 6 Apr 2002 19:10:50 -0600 (CST) Received: from erbenson.alaska.net (136-pm3.nwc.alaska.net [209.112.138.136]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g371AfQ04449; Sat, 6 Apr 2002 16:10:41 -0900 (AKST) (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 9F2A6393A; Sat, 6 Apr 2002 16:10:40 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 0BD7310281; Sat, 6 Apr 2002 16:10:40 -0900 (AKST) Date: Sat, 6 Apr 2002 16:10:40 -0900 From: Ethan Benson To: Andreas Gruenbacher Cc: linux-xfs@thebarn.com Subject: Re: extended attributes security problem Message-ID: <20020406161039.J1524@plato.local.lan> References: <20020405234103.F1524@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h22Fi9ANawrtbNPX" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ag@bestbits.at on Sat, Apr 06, 2002 at 06:28:42PM +0200 X-OS: Debian GNU Sender: owner-linux-xfs@thebarn.com Precedence: bulk --h22Fi9ANawrtbNPX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 06, 2002 at 06:28:42PM +0200, Andreas Gruenbacher wrote: > > 1) some sort of mount options to change xattr semantecs, for example >=20 > This does not address the real problem, and therefore makes no sense. i agree, i was mainly looking for options to let me close this hole as fast as possible. > > 2) apply a different sementec on special files, for regular files and > > directories use the current method of using the permission bits to > > control access to xattrs, but for special files such as block devices, > > char devices, sockets etc only allow the file's owner to add/remove > > xattrs. >=20 > This would be at least possible. yes. > > 3) for directories, only allow xattrs to be written by the directories > > owner if the sticky bit is set (this would prevent users from spewing > > attrs on /tmp /var/tmp and other world writable sticky system > > directories. >=20 > Why should we introduce quircks like this? All the messing around with the > sticky bit for directories has a single reason: The rwx permission scheme > just is too weak to allow everybody to create files, without also allowing > everybody to delete arbitrary files. because if you don't the DoS is not solved, there are several directories on my system which must be mode 1777 (/tmp /var/tmp and so on) they also must be owned by root, this allows me to use them to bypass quota and completly fill the filesystem with xattrs. just take my previous for loop and replace /dev/null with /tmp or /var/tmp or any other convenient world writable root owned directory. =20 its NOT the same as cp /dev/zero /tmp since that can be controled with quota, xattrs cannot. > For many it may be hard to admit that the directory sticky bit thing is an > ugly workaround for emulating create permissions. Even POSIX ACLs don't > solve this, but additional permissions such as create and delete would > provide a clean solution. as would seperate permission bits for xattrs, but this is an extremely intrusive change and means you have to start looking at abandoning posix and adopting something closer to NTs. (personally i find NT acls a major PITA, for 90 of files standard unix mode bits are fine and must be avialable in the tradidional manner...) > Apart from being more complicated to implement, permissions for individual > EA's would also be much more difficult to understand, and to use > correctly, and we would need a tool for manipulating them. I am very much > opposed to this idea, as this seems overly complex, and completely > unnecessary. i tend to agree, however we MUST address the issue of special files which must be 1) world writable and 2) owned by root, this includes 1777 directories, they are just as vulnerable as /dev/null. > The comparison with Windows NT is not valid for several reasons: (a) > Windows NT does not have device special files, so we have to deal with > different semantics. (b) Windows NT does not use EA's, but uses forks, > similar to the Macintosh HFS. Forks are the same as regular files, they > are only "hidden" behind the name of another file. i was merly referencing the permission bits they named `write extended attribute' `append to extended attribute' and i think there is a `create extended attribute' too but im not sure on that (i avoid having to deal with NT like a root canal). note im actually referencing 2000/XP which have a slightly different ACL model then NT4 but anyway... > The first question we should try to answer is, what are the semantics of > user EA's for special files and inodes, and do they make sense. We have > defined user EA's as attributes users may associate with a file, according > to the same access restrictions as the file contents. I think these > semantics are clear, and easy to understand. for regular files yes, directories are more complicated IMO. lets examine it further: a group of users are working on some project, and have various files writable by a group which they are all members, only one may own the file and he gets to bear the hit the file takes on his quota, he also must accept that if one of the other group members decides to be a prick he could cat /dev/zero into one of his group writable files and exhaust his quota, the other user could equally well use xattrs too, the affect is the same. so given this having different permissions for xattr and file data doesn't get you anything (i really can't think of situations with *regular* files where it really does, theoretically depending on what sort of things you might start putting in xattrs you might want to protect them more, but i doubt it). essentially we can reasonably say `if you trust someone with read and/or write access to the file content you also trust them to the same with xattrs' now lets look at a user who has one or more either group or world writable directories for people to `drop things off' this includes people he may not trust as much as the above group scenerio, thus he is careful not to leave any files writable by either world or lesstrustedgroup, he need not worry about quota since anyone creating files in his directory will retain ownership, and thus the quota impact of the files they create, copying /dev/zero into his public directory only b0rks thier own quota, not this user. here however xattrs break this assumption, now the hostile user can apply hundreds or thousands of xattrs filled with as much irrelevant data as they will hold to exhaust the users quota. =20 the directory case also applies to sockets and fifos since these are sometimes world writable (though perhaps this is just brokeness of gnome/kde etc) so i think that keeping the regular file semantecs of xattr permissions on these special files users are allowed to create is also innappropriate. also note that sockets don't really have file data so it doesn't hold the `if you trust the user to alter the data you trust them to alter the xattrs' reasoning we established in scenerio #1. > Now for symlinks and special files the permissions have a different > meaning. Let's first discuss special files. >=20 > The permissions of a special file inode denote which accesses are > permitted to the device the inode is describing. It is possible to have a > device inode, such as /dev/null, on a read-only file system, and it's > still permitted to make information disappear by piping it to /dev/null. indeed. > If we use the same permissions to determine the permissions for special > file EA's, then we end up with the anomaly (and security hole) that Ethan > has described. indeed, this breaks the reasoning in scenerio #1 since device files have no file content (not in the conventional sense anyway). > If we use different rules such as inode ownership to determine access, > then the semantics become relatively complicated. I think this is neither > necessary nor useful. >=20 > So my conclusion is that we should disallow user EA's for special files. i really can't think of any reason why you would need a user.* attribute on a device, so i agree this is an acceptable solution. system.* however should not be disallowed since its reasonable one may wish to apply an ACL to a device file. however it occurs to me that this could open another potential hole, in the pty/tty case there is a hangup mechenism to ensure any process holding a file descriptor is cut off when the tty is reset (you logout and getty or whatever takes back the tty), getty also ensures to reset permissions and ownership on the tty so past users cannot retain access and thus sniff it for passwords or other useful data typed by a future occupant. if however a user may apply an ACL which ensures they are a supplimental user with read/write access to the tty and login/getty whatever don't ensure to remove it a user could sucessfully retain access to ttys after they relinquish it. i have not yet attempted any tests on this. > For symlinks the situation is similar. The permissions of a symlink have > nothing to do with the contents of the symlink, but they denote permission > to traverse the symlink. Also, the traditional Linux file systems ext2 and > ext3 don't even allow permissions for symlinks; the permissions are always > initialized with S_IRWXUGO. what systems actually make use of symlink permissions? i have yet to encounter a unix where symlink perms were not entirely irrelevant, even if you could change them (most you cannot). with XFS the permissions are set to whatever your current umask dictates, however setting umask to 0000 and creating a symlink which then has l--------- permissions still works fine for everyone (though looks quite odd).=20 > Again, one of the questions that come to mind is, do we have a need for > symlink user EA's? With the existing user EA permission model, I don't see > any reason supporting this. i suppose it all depends on what people end up wanting to do with EAs, i tend to agree that there is unlikly to be very many if any useful uses for such a thing, and it clearly won't work with the current permission model. > My conclusion, again, is to disallow user EA's for symlinks. this would not bother me at all. =20 > We have been discussing useful EA namespaces before. In addition to the > system and user namespaces, we had two additional namespaces that might be > useful future extensions. I have recently given this description of these > EA namespace on the ext2-devel mailing list: >=20 > SYSTEM >=20 > Used internally by the kernel; access permissions depend on the policy > implemented in the kernel, and may differ from attribute to attribute. > There may be restrictions on the values that a system attribute may > obtain, e.g., ACL values must be valid. >=20 > USER >=20 > Attributes regular users can use. Read and write access is controlled > by the usual file permissions, so everyone who is allowed X access to > the file data is also allowed X acces on its user EA's. >=20 > TRUSTED >=20 > Attributes only trusted processes may use. This would be useful for > implementing OS extensions in user space that use EA's which must not > otherwise be accessible to users. Another application could be backup > labels, for example. The trust status of a process could be defined by > a capability. >=20 > OWNER >=20 > Attributes only accessible to the owner of an object. This is a bit > obscure; I have no good example for this namespace. i think the OWNER namespace could be useful, but i don't have specific examples either. > The set of namespaces proposed above ties the permissions needed for > accessing a class of EA's to the namespace. I think this is a very useful > simplification. The system namespace is a bit of an exception, since the > permissions differ between individual system attributes. This is necessary > to support the semantics of ACLs, Capabilities, MAC and audit labels, etc. > through the EA interfaces; I think this special role of the system > namespace is an acceptable compromise, instead of introducing separate > namespaces for each slightly differing new concept we may add in the > future. i agree. > Ethan's option (2) amounts to the semantics of the proposed owner > namespace. I suggest not to mix semantics within the user namespace. It > may some day turn out that the owner namespace is a useful thing, for > files, directories, special files, etc. That would be the day to introduce > the owner namespace. Keeping the user and owner namespaces distinct is > much more transparent semantically. agreed. > Did my arguing and conclusions make sense to you? yes, in truth i was not at all sure of a correct solution so i proposed a few somewhat half baked ones in the hope it would trigger useful discussion, i see it worked perfectly ;-) --=20 Ethan Benson http://www.alaska.net/~erbenson/ --h22Fi9ANawrtbNPX 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 iEYEARECAAYFAjyvnI8ACgkQJKx7GixEevwp0wCbBeD/h5ai+AxiRanPwTwk7Fcu gbsAn2Z7dUpI3vmPaRRsbOaPwQdzm0AI =I0S1 -----END PGP SIGNATURE----- --h22Fi9ANawrtbNPX-- From owner-linux-xfs@lips.thebarn.com Sun Apr 7 00:35:47 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g376ZlgY083303 for linux-xfs-outgoing; Sun, 7 Apr 2002 00:35:47 -0600 (CST) Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g376Zjon083298 for ; Sun, 7 Apr 2002 00:35:45 -0600 (CST) Received: from sweeney.demon.co.uk ([158.152.71.87] helo=pereskia.sweeney.demon.co.uk) by anchor-post-30.mail.demon.net with esmtp (Exim 3.35 #1) id 16u6H9-000G09-0U for linux-xfs@thebarn.com; Sun, 07 Apr 2002 07:35:43 +0100 Received: from rebutia.sweeney.demon.co.uk (rebutia.sweeney.demon.co.uk [10.0.0.3]) by pereskia.sweeney.demon.co.uk (Postfix) with ESMTP id C833D1F58 for ; Sun, 7 Apr 2002 07:35:13 +0100 (BST) Received: by rebutia.sweeney.demon.co.uk (Postfix, from userid 1001) id E4970125E6; Sun, 7 Apr 2002 07:35:14 +0100 (BST) Date: Sun, 7 Apr 2002 07:35:14 +0100 (BST) From: Keith Matthews Subject: Re[2]: extended attributes security problem To: linux-xfs@thebarn.com In-Reply-To: References: X-Mailer: Mahogany, 0.60 'Redmond', compiled for Linux 2.2.13 i686 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Disposition: INLINE Message-Id: <20020407063514.E4970125E6@rebutia.sweeney.demon.co.uk> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by lips.thebarn.com id g376Zkon083299 Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Sat, 6 Apr 2002 18:26:02 -0600 (CST) Eric Sandeen > wrote: > On Sat, 6 Apr 2002, Eric Sandeen wrote: > > I made a tiny xfs filesystem to test this, then made a 0-byte file and > > added 64K attributes until I ran out of space: > And then I read Ethan's mail from earlier today... whoops. :) Sorry if this is a red herring, as it's an area I have not managed to study properly. A thought - what happens to the space taken up by EAs against special device files on shutdown/reboot if devfs is in use ? -- Keith Matthews Frequentous Consultants - Linux Services, Oracle development & database administration From owner-linux-xfs@lips.thebarn.com Sun Apr 7 01:09:30 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g3779ULv083633 for linux-xfs-outgoing; Sun, 7 Apr 2002 01:09:30 -0600 (CST) Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g3779Son083628 for ; Sun, 7 Apr 2002 01:09:29 -0600 (CST) Received: from erbenson.alaska.net (68-pm14.nwc.alaska.net [209.112.141.68]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3779Rw83314 for ; Sat, 6 Apr 2002 22:09:27 -0900 (AKST) (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 3F067393A for ; Sat, 6 Apr 2002 22:09:26 -0900 (AKST) Received: by plato.local.lan (Postfix, from userid 1000) id 000C010281; Sat, 6 Apr 2002 22:09:25 -0900 (AKST) Date: Sat, 6 Apr 2002 22:09:25 -0900 From: Ethan Benson To: linux-xfs@thebarn.com Subject: Re: extended attributes security problem Message-ID: <20020406220925.K1524@plato.local.lan> References: <20020407063514.E4970125E6@rebutia.sweeney.demon.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cN519qCC4CN1mUcX" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020407063514.E4970125E6@rebutia.sweeney.demon.co.uk>; from keith_m@sweeney.demon.co.uk on Sun, Apr 07, 2002 at 07:35:14AM +0100 X-OS: Debian GNU Sender: owner-linux-xfs@thebarn.com Precedence: bulk --cN519qCC4CN1mUcX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 07, 2002 at 07:35:14AM +0100, Keith Matthews wrote: > On Sat, 6 Apr 2002 18:26:02 -0600 (CST) Eric Sandeen > wrote: >=20 > > On Sat, 6 Apr 2002, Eric Sandeen wrote: >=20 > > > I made a tiny xfs filesystem to test this, then made a 0-byte file and > > > added 64K attributes until I ran out of space: >=20 > > And then I read Ethan's mail from earlier today... whoops. :) >=20 > Sorry if this is a red herring, as it's an area I have not managed to > study properly. it is a red herring. > A thought - what happens to the space taken up by EAs against special > device files on shutdown/reboot if devfs is in use ? devfs does not support extended attributes. but this is irrelevant, using devfs is not a solution but a workaround. =20 and i for one will never ever use devfs, but again its irrelevant, the real problem needs to be fixed not ignored and kludged around. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --cN519qCC4CN1mUcX 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 iEYEARECAAYFAjyv8KUACgkQJKx7GixEevxG6gCfc7dBaEfVmHQijdQ9o0fy69wZ jKkAni713OqWI/mBKvsccFF/E1sRqC5Z =AmMR -----END PGP SIGNATURE----- --cN519qCC4CN1mUcX-- From owner-linux-xfs@lips.thebarn.com Sun Apr 7 06:16:23 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g37BGNM3085434 for linux-xfs-outgoing; Sun, 7 Apr 2002 06:16:23 -0500 (CDT) Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37BGKon085429 for ; Sun, 7 Apr 2002 06:16:21 -0500 (CDT) X-Authentication-Warning: lips.thebarn.com: Host ns.suse.de [213.95.15.193] claimed to be Cantor.suse.de Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 0FE511E39D; Sun, 7 Apr 2002 13:16:20 +0200 (MEST) Date: Sun, 7 Apr 2002 13:16:19 +0200 From: Andi Kleen To: Ethan Benson Cc: Andreas Gruenbacher , linux-xfs@thebarn.com Subject: Re: extended attributes security problem Message-ID: <20020407131619.A13788@wotan.suse.de> References: <20020405234103.F1524@plato.local.lan> <20020406161039.J1524@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020406161039.J1524@plato.local.lan> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Sat, Apr 06, 2002 at 04:10:40PM -0900, Ethan Benson wrote: > On Sat, Apr 06, 2002 at 06:28:42PM +0200, Andreas Gruenbacher wrote: > > > 1) some sort of mount options to change xattr semantecs, for example > > > > This does not address the real problem, and therefore makes no sense. > > i agree, i was mainly looking for options to let me close this hole as > fast as possible. I'm proposing this patch. As Andreas pointed out it doesn't make much sense to set ACLs on symlinks or special devices. I still allow it for root. Not allowing them for symlinks could be a problem for some other non ACL uses of EAs (e.g. if a GUI fs browser wanted to store an icon in there), but this is probably not a too big problem right now. Of course this makes the existence of l{get,list,remove}attr a bit questionable, but then at least root can do something with them still. -Andi --- linux-work/fs/xattr.c-o Thu Mar 21 18:15:26 2002 +++ linux-work/fs/xattr.c Sun Apr 7 13:03:06 2002 @@ -67,6 +67,11 @@ if (flags & ~(XATTR_CREATE|XATTR_REPLACE)) return -EINVAL; + /* Do not allow creation of EAs on special files and symlinks. */ + if (!S_ISREG(d->d_inode->i_mode) && !S_ISDIR(d->d_inode->i_mode) && + !capable(CAP_SYS_ADMIN)) + return -EPERM; + error = strncpy_from_user(kname, name, sizeof(kname)); if (error == 0 || error == sizeof(kname)) error = -ERANGE; From owner-linux-xfs@lips.thebarn.com Sun Apr 7 06:56:46 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g37BukvI085761 for linux-xfs-outgoing; Sun, 7 Apr 2002 06:56:46 -0500 (CDT) Received: from hob.slb.nwc.acsalaska.net (hob.slb.nwc.acsalaska.net [209.112.155.42]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37Buion085756 for ; Sun, 7 Apr 2002 06:56:45 -0500 (CDT) Received: from erbenson.alaska.net (68-pm14.nwc.alaska.net [209.112.141.68]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g37BuWw18372; Sun, 7 Apr 2002 03:56:32 -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 6571A393A; Sun, 7 Apr 2002 03:56:31 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id A53CA10281; Sun, 7 Apr 2002 03:56:31 -0800 (AKDT) Date: Sun, 7 Apr 2002 03:56:31 -0800 From: Ethan Benson To: Andi Kleen Cc: Andreas Gruenbacher , linux-xfs@thebarn.com Subject: Re: extended attributes security problem Message-ID: <20020407035631.L1524@plato.local.lan> References: <20020405234103.F1524@plato.local.lan> <20020406161039.J1524@plato.local.lan> <20020407131619.A13788@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rnP2AJ7yb1j09OW/" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020407131619.A13788@wotan.suse.de>; from ak@suse.de on Sun, Apr 07, 2002 at 01:16:19PM +0200 X-OS: Debian GNU Sender: owner-linux-xfs@thebarn.com Precedence: bulk --rnP2AJ7yb1j09OW/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 07, 2002 at 01:16:19PM +0200, Andi Kleen wrote: >=20 > I'm proposing this patch. As Andreas pointed out it doesn't make much sen= se > to set ACLs on symlinks or special devices. I still allow it for root. sounds reasonable. however this patch is not sufficent, we must do something about world writable directories like /tmp, otherwise my exploit will still work fine, just target /tmp instead of /dev/null. i think that restricting creation of user.* attrs to the owner when the sticky bit is set is really the only sensible solution here, i agree its not ideal but as its been stated the meaning of the sticky bit is a bit of a hack anyway. > Not allowing them for symlinks could be a problem for some other non ACL > uses of EAs (e.g. if a GUI fs browser wanted to store an icon in there), = but=20 > this is probably not a too big problem right now.=20 >=20 > Of course this makes the existence of l{get,list,remove}attr a bit > questionable, but then at least root can do something with them still. >=20 > -Andi >=20 >=20 > --- linux-work/fs/xattr.c-o Thu Mar 21 18:15:26 2002 > +++ linux-work/fs/xattr.c Sun Apr 7 13:03:06 2002 > @@ -67,6 +67,11 @@ > if (flags & ~(XATTR_CREATE|XATTR_REPLACE)) > return -EINVAL; > =20 > + /* Do not allow creation of EAs on special files and symlinks. */ > + if (!S_ISREG(d->d_inode->i_mode) && !S_ISDIR(d->d_inode->i_mode) && > + !capable(CAP_SYS_ADMIN))=09 > + return -EPERM;=20 > + > error =3D strncpy_from_user(kname, name, sizeof(kname)); > if (error =3D=3D 0 || error =3D=3D sizeof(kname)) > error =3D -ERANGE; --=20 Ethan Benson http://www.alaska.net/~erbenson/ --rnP2AJ7yb1j09OW/ 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 iEYEARECAAYFAjywM+8ACgkQJKx7GixEevz2iQCdGQlXNcqEiHknYbS8vyJRkSdG U8cAnipZzRoERucSIu/YpMTYSOkxXNBb =JXTB -----END PGP SIGNATURE----- --rnP2AJ7yb1j09OW/-- From owner-linux-xfs@lips.thebarn.com Sun Apr 7 09:12:39 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g37ECd3X086645 for linux-xfs-outgoing; Sun, 7 Apr 2002 09:12:39 -0500 (CDT) Received: from mta06bw.bigpond.com (mta06bw.bigpond.com [139.134.6.96]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37ECZon086640 for ; Sun, 7 Apr 2002 09:12:36 -0500 (CDT) Message-Id: <200204071412.g37ECZon086640@lips.thebarn.com> Received: from there ([144.135.24.84]) by mta06bw.bigpond.com (Netscape Messaging Server 4.15 mta06bw Feb 26 2002 03:44:21) with SMTP id GU7BGU00.C25 for ; Mon, 8 Apr 2002 00:12:30 +1000 Received: from CPE-144-137-137-105.qld.bigpond.net.au ([144.137.137.105]) by bwmam06.mailsvc.email.bigpond.com(MailRouter V3.0i 53/2903955); 08 Apr 2002 00:12:30 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-xfs@thebarn.com Subject: Current OSS XFS CVS is currently very old at 2.4.15-pre5-xfs Date: Mon, 8 Apr 2002 00:12:24 +1000 X-Mailer: KMail [version 1.3.1] References: <20020405235829.G1524@plato.local.lan> In-Reply-To: <20020405235829.G1524@plato.local.lan> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@thebarn.com Precedence: bulk Since OSS was back up I thought that I would bring my local CVS into line. After quite some time I found that the CVS was 2.4.15-pre5-xfs. Therefore, for the moment until this is rectified by the good folks at SGI don't waste your bandwidth ;-) -- Adrian Head (Public Key available on request.) From owner-linux-xfs@lips.thebarn.com Sun Apr 7 09:16:00 2002 Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.0) id g37EG0r0086799 for linux-xfs-outgoing; Sun, 7 Apr 2002 09:16:00 -0500 (CDT) Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37EFwon086786 for ; Sun, 7 Apr 2002 09:15:59 -0500 (CDT) Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g37EFrkw032615 for ; Sun, 7 Apr 2002 09:15:53 -0500 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA45236 for ; Sun, 7 Apr 2002 09:15:53 -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 JAA67545 for ; Sun, 7 Apr 2002 09:15:52 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g37EFqL03305; Sun, 7 Apr 2002 09:15:52 -0500 Message-Id: <200204071415.g37EFqL03305@stout.americas.sgi.com> Date: Sun, 7 Apr 2002 09:15:52 -0500 Subject: TAKE - Fix nfs refcache superblock dirty timer Sender: owner-linux-xfs@thebarn.com Precedence: bulk The nfs refcache uses a timer to mark the superblock as dirty whenever items are left in the refcache, to ensure that on the next sync, more items will be purged. The previous implementation had 2 problems - the timer was not deleted on unmount, so it could go off and cause an oops if the superblock pointer had gone away after an unmount. Also, we really needed a timer per filesystem, not one global timer. This mod adds the timer to the xfs_mount_t struct, so there is 1 per fs, and also deletes the timer on unmount. Date: Sun Apr 7 07:12:06 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-refcache The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:115908a cmd/xfsprogs/include/xfs_mount.h - 1.13 - add m_sbdirty_timer to mount struct Modid: 2.4.x-xfs:slinx:115908b linux/fs/xfs/xfs_rw.c - 1.354 - use a per-fs sbdirty timer rather than one global timer linux/fs/xfs/xfs_vfsops.c - 1.340 - delete sbdirty timer on unmount linux/fs/xfs/xfs_mount.h - 1.138 - add m_sbdirty_timer to mount struct linux/fs/xfs/xfs_mount.c - 1.278 - set up sbdirty timer in xfs_mountfs From owner-linux-xfs@lips.thebarn.com Sun Apr 7 09:42:50 2002 Received: from lips.thebarn.com (localhost [127.0.0.1]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37EgnKa099028 for ; Sun, 7 Apr 2002 09:42:49 -0500 (CDT) Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.2/Submit) id g37EgnMu099027 for linux-xfs-outgoing; Sun, 7 Apr 2002 09:42:49 -0500 (CDT) (envelope-from owner-linux-xfs@thebarn.com) X-Authentication-Warning: lips.thebarn.com: majordom set sender to owner-linux-xfs@thebarn.com using -f Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37EglKa099022 for ; Sun, 7 Apr 2002 09:42:48 -0500 (CDT) Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g37Egi6G013113; Sun, 7 Apr 2002 07:42:44 -0700 Received: from chuckle.americas.sgi.com (sandeen@chuckle.americas.sgi.com [128.162.211.44]) by relay1.corp.sgi.com (980427.SGI.8.8.8/970903.SGI.AUTOCF) via ESMTP id HAA61267; Sun, 7 Apr 2002 07:42:43 -0700 (PDT) Date: Sun, 7 Apr 2002 09:42:43 -0500 (CDT) From: Eric Sandeen X-X-Sender: To: Adrian Head cc: Subject: Re: Current OSS XFS CVS is currently very old at 2.4.15-pre5-xfs In-Reply-To: <200204071412.g37ECZon086640@lips.thebarn.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@thebarn.com Precedence: bulk Thanks Adrian, should be good now. (the 2.5 tree is still not pushing out, should be fixed shortly) -Eric On Mon, 8 Apr 2002, Adrian Head wrote: > Since OSS was back up I thought that I would bring my local CVS into line. > After quite some time I found that the CVS was 2.4.15-pre5-xfs. > > Therefore, for the moment until this is rectified by the good folks at SGI > don't waste your bandwidth ;-) > > > From owner-linux-xfs@lips.thebarn.com Sun Apr 7 09:45:56 2002 Received: from lips.thebarn.com (localhost [127.0.0.1]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37EjtKa099189 for ; Sun, 7 Apr 2002 09:45:55 -0500 (CDT) Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.2/Submit) id g37EjtiV099188 for linux-xfs-outgoing; Sun, 7 Apr 2002 09:45:55 -0500 (CDT) (envelope-from owner-linux-xfs@thebarn.com) X-Authentication-Warning: lips.thebarn.com: majordom set sender to owner-linux-xfs@thebarn.com using -f Received: from mta06bw.bigpond.com (mta06bw.bigpond.com [139.134.6.96]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37EjqKa099183 for ; Sun, 7 Apr 2002 09:45:53 -0500 (CDT) Message-Id: <200204071445.g37EjqKa099183@lips.thebarn.com> Received: from there ([144.135.24.84]) by mta06bw.bigpond.com (Netscape Messaging Server 4.15 mta06bw Feb 26 2002 03:44:21) with SMTP id GU7D0C00.IGG for ; Mon, 8 Apr 2002 00:45:48 +1000 Received: from CPE-144-137-137-105.qld.bigpond.net.au ([144.137.137.105]) by bwmam06.mailsvc.email.bigpond.com(MailRouter V3.0i 53/2923264); 08 Apr 2002 00:45:48 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: linux-xfs@thebarn.com Subject: Re: Current OSS XFS CVS is now up to date 2.4.18-xfs Date: Mon, 8 Apr 2002 00:45:44 +1000 X-Mailer: KMail [version 1.3.1] References: <20020405235829.G1524@plato.local.lan> <200204071412.g37ECZon086640@lips.thebarn.com> In-Reply-To: <200204071412.g37ECZon086640@lips.thebarn.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@thebarn.com Precedence: bulk Ok - just talked to Eric and everything should be fine now. Thanks On Mon, 8 Apr 2002 00:12, Adrian Head wrote: > Since OSS was back up I thought that I would bring my local CVS into line. > After quite some time I found that the CVS was 2.4.15-pre5-xfs. > > Therefore, for the moment until this is rectified by the good folks at SGI > don't waste your bandwidth ;-) -- Adrian Head (Public Key available on request.) From owner-linux-xfs@lips.thebarn.com Sun Apr 7 10:00:57 2002 Received: from lips.thebarn.com (localhost [127.0.0.1]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37F0uKa099527 for ; Sun, 7 Apr 2002 10:00:56 -0500 (CDT) Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.2/Submit) id g37F0uEA099526 for linux-xfs-outgoing; Sun, 7 Apr 2002 10:00:56 -0500 (CDT) (envelope-from owner-linux-xfs@thebarn.com) X-Authentication-Warning: lips.thebarn.com: majordom set sender to owner-linux-xfs@thebarn.com using -f Received: from Cantor.suse.de (ns.suse.de [213.95.15.193]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37F0sKa099521 for ; Sun, 7 Apr 2002 10:00:55 -0500 (CDT) X-Authentication-Warning: lips.thebarn.com: Host ns.suse.de [213.95.15.193] claimed to be Cantor.suse.de Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 628861EE62; Sun, 7 Apr 2002 16:50:33 +0200 (MEST) Date: Sun, 7 Apr 2002 16:50:32 +0200 From: Andi Kleen To: Ethan Benson Cc: Andi Kleen , Andreas Gruenbacher , linux-xfs@thebarn.com Subject: Re: extended attributes security problem Message-ID: <20020407165032.A8535@wotan.suse.de> References: <20020405234103.F1524@plato.local.lan> <20020406161039.J1524@plato.local.lan> <20020407131619.A13788@wotan.suse.de> <20020407035631.L1524@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020407035631.L1524@plato.local.lan> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Sun, Apr 07, 2002 at 03:56:31AM -0800, Ethan Benson wrote: > On Sun, Apr 07, 2002 at 01:16:19PM +0200, Andi Kleen wrote: > > > > I'm proposing this patch. As Andreas pointed out it doesn't make much sense > > to set ACLs on symlinks or special devices. I still allow it for root. > > sounds reasonable. > > however this patch is not sufficent, we must do something about world > writable directories like /tmp, otherwise my exploit will still work > fine, just target /tmp instead of /dev/null. In /tmp you can create files anyways and they're usually not even counted to your quota (at least few sites seem to run quota in /tmp) > > i think that restricting creation of user.* attrs to the owner when > the sticky bit is set is really the only sensible solution here, i > agree its not ideal but as its been stated the meaning of the sticky > bit is a bit of a hack anyway. Hmm. Ok. Revised patch. Also do not allow setting on sticky bit. --- linux-work/fs/xattr.c-o Thu Mar 21 18:15:26 2002 +++ linux-work/fs/xattr.c Sun Apr 7 16:41:15 2002 @@ -63,10 +63,22 @@ int error; void *kvalue; char kname[XATTR_NAME_MAX + 1]; + struct inode *i = d->d_inode; if (flags & ~(XATTR_CREATE|XATTR_REPLACE)) return -EINVAL; + /* Some checks to prevent people abusing EAs to get over their quota: */ + /* Do not allow creation of EAs on special files and symlinks */ + if (!S_ISREG(i->i_mode) && !S_ISDIR(i->i_mode) && + !capable(CAP_SYS_ADMIN)) + return -EPERM; + /* Do not allow creation EAs in directories with sticky bit unless you're + the owner. */ + if (S_ISDIR(i->i_mode) && (i->i_mode & S_ISVTX) && + (current->fsuid != i->i_uid) && !capable(CAP_FOWNER)) + return -EPERM; + error = strncpy_from_user(kname, name, sizeof(kname)); if (error == 0 || error == sizeof(kname)) error = -ERANGE; @@ -83,9 +95,9 @@ } error = -EOPNOTSUPP; - if (d->d_inode->i_op && d->d_inode->i_op->setxattr) { + if (i->i_op && i->i_op->setxattr) { lock_kernel(); - error = d->d_inode->i_op->setxattr(d, kname, kvalue, size, flags); + error = i->i_op->setxattr(d, kname, kvalue, size, flags); unlock_kernel(); } -Andi From owner-linux-xfs@lips.thebarn.com Sun Apr 7 10:28:01 2002 Received: from lips.thebarn.com (localhost [127.0.0.1]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37FS0Ka099934 for ; Sun, 7 Apr 2002 10:28:00 -0500 (CDT) Received: (from majordom@localhost) by lips.thebarn.com (8.12.2/8.12.2/Submit) id g37FS0o6099933 for linux-xfs-outgoing; Sun, 7 Apr 2002 10:28:00 -0500 (CDT) (envelope-from owner-linux-xfs@thebarn.com) X-Authentication-Warning: lips.thebarn.com: majordom set sender to owner-linux-xfs@thebarn.com using -f Received: from muriel.parsec.at (muriel.parsec.at [212.236.50.199]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g37FRvKa099928 for ; Sun, 7 Apr 2002 10:27:58 -0500 (CDT) Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g37FRr405741; Sun, 7 Apr 2002 17:27:54 +0200 Date: Sun, 7 Apr 2002 17:27:53 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Andi Kleen cc: Ethan Benson , Subject: Re: extended attributes security problem In-Reply-To: <20020407131619.A13788@wotan.suse.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@thebarn.com Precedence: bulk On Sun, 7 Apr 2002, Andi Kleen wrote: > On Sat, Apr 06, 2002 at 04:10:40PM -0900, Ethan Benson wrote: > > On Sat, Apr 06, 2002 at 06:28:42PM +0200, Andreas Gruenbacher wrote: > > > > 1) some sort of mount options to change xattr semantecs, for example > > > > > > This does not address the real problem, and therefore makes no sense. > > > > i agree, i was mainly looking for options to let me close this hole as > > fast as possible. > > I'm proposing this patch. As Andreas pointed out it doesn't make much sense > to set ACLs on symlinks or special devices. I still allow it for root. There seems to be some misunderstanding here. I was only talking about extended attributes in the user namespace in my previous reply to Ethan. I think that user EA's should be disallowed for symlinks and special files. Which files shall have ACLs is specified in POSIX 1003.1e draft 17: Symlinks don't have ACLs; all other files do. We have no security problem with ACLs. --Andreas. ------------------------------------------------------------------------ Andreas Gruenbacher, a.gruenbacher@computer.org Contact information: http://www.bestbits.at/~ag/ From owner-linux-xfs@oss.sgi.com Mon Apr 8 09:47:01 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38Gl18d029844 for ; Mon, 8 Apr 2002 09:47:01 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38Gl1Mk029843 for linux-xfs-outgoing; Mon, 8 Apr 2002 09:47:01 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38Gkv8d029630 for ; Mon, 8 Apr 2002 09:46:57 -0700 Received: (qmail 31019 invoked by uid 500); 8 Apr 2002 16:46:46 -0000 Subject: 2.4.19 merging? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 08 Apr 2002 11:46:46 -0500 Message-Id: <1018284406.30714.25.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is this happening in the CVS tree? I checked out linux-2.4-xfs and it was 2.4.15, Is that no longer correct? Please advise -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Apr 8 11:06:10 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38I6A8d032148 for ; Mon, 8 Apr 2002 11:06:10 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38I6AUd032147 for linux-xfs-outgoing; Mon, 8 Apr 2002 11:06:10 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38I668d032121 for ; Mon, 8 Apr 2002 11:06:06 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 16udWv-00036p-00; Mon, 08 Apr 2002 19:06:13 +0100 Date: Mon, 8 Apr 2002 19:06:13 +0100 From: Christoph Hellwig To: Austin Gonyou Cc: linux-xfs@oss.sgi.com Subject: Re: 2.4.19 merging? Message-ID: <20020408190613.A11785@infradead.org> References: <1018284406.30714.25.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1018284406.30714.25.camel@UberGeek>; from austin@coremetrics.com on Mon, Apr 08, 2002 at 11:46:46AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Apr 08, 2002 at 11:46:46AM -0500, Austin Gonyou wrote: > Is this happening in the CVS tree? I checked out linux-2.4-xfs and it > was 2.4.15, Is that no longer correct? Please advise It's back at 2.4.18. But this brings up another issue I wondered about for some time: In the good old days every prerelease was merged, nowdays it's just the full releases. Is there a reason behing this as the actual XFS releases are for specific versions anyway and the CVS basically is a current top-of-tree branch? From owner-linux-xfs@oss.sgi.com Mon Apr 8 11:37:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38IbV8d032756 for ; Mon, 8 Apr 2002 11:37:31 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38IbVD2032754 for linux-xfs-outgoing; Mon, 8 Apr 2002 11:37:31 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38IbR8d032728 for ; Mon, 8 Apr 2002 11:37: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 NAA61328; Mon, 8 Apr 2002 13:37:42 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA14255; Mon, 8 Apr 2002 13:37:42 -0500 (CDT) Subject: Re: 2.4.19 merging? From: Eric Sandeen To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1018284406.30714.25.camel@UberGeek> References: <1018284406.30714.25.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 08 Apr 2002 13:37:42 -0500 Message-Id: <1018291062.8166.52.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There was a problem w/ the cvs on oss.sgi.com when it came back online, but it should be up to date now. 2.4.19 will be merged when it is released. -Eric On Mon, 2002-04-08 at 11:46, Austin Gonyou wrote: > Is this happening in the CVS tree? I checked out linux-2.4-xfs and it > was 2.4.15, Is that no longer correct? Please advise -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Apr 8 11:50:17 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38IoH8d000594 for ; Mon, 8 Apr 2002 11:50:17 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38IoH0o000593 for linux-xfs-outgoing; Mon, 8 Apr 2002 11:50:17 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38IoB8d000561 for ; Mon, 8 Apr 2002 11:50:11 -0700 Received: (qmail 31333 invoked by uid 500); 8 Apr 2002 18:49:52 -0000 Subject: Re: 2.4.19 merging? From: Austin Gonyou To: Eric Sandeen Cc: linux-xfs@oss.sgi.com In-Reply-To: <1018291062.8166.52.camel@stout.americas.sgi.com> References: <1018291062.8166.52.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 08 Apr 2002 13:49:52 -0500 Message-Id: <1018291792.30653.35.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I was mainly referring to the dev tree. On Mon, 2002-04-08 at 13:37, Eric Sandeen wrote: > There was a problem w/ the cvs on oss.sgi.com when it came back online, > but it should be up to date now. > > 2.4.19 will be merged when it is released. > > -Eric > > On Mon, 2002-04-08 at 11:46, Austin Gonyou wrote: > > Is this happening in the CVS tree? I checked out linux-2.4-xfs and it > > was 2.4.15, Is that no longer correct? Please advise > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Apr 8 11:57:36 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38Iva8d000860 for ; Mon, 8 Apr 2002 11:57:36 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38Iva2u000859 for linux-xfs-outgoing; Mon, 8 Apr 2002 11:57:36 -0700 X-Authentication-Warning: oss.sgi.com: mail 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 g38IvV8d000832 for ; Mon, 8 Apr 2002 11:57:31 -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 NAA19250 for ; Mon, 8 Apr 2002 13:57:46 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.35 #1 (Debian)) id 16ueKn-0003Io-00 for ; Mon, 08 Apr 2002 13:57:45 -0500 Date: Mon, 8 Apr 2002 13:57:45 -0500 From: Nathan Straz To: linux-xfs@oss.sgi.com Subject: Re: 2.4.19 merging? Message-ID: <20020408185745.GV16203@sgi.com> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1018284406.30714.25.camel@UberGeek> <20020408190613.A11785@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020408190613.A11785@infradead.org> User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Apr 08, 2002 at 07:06:13PM +0100, Christoph Hellwig wrote: > It's back at 2.4.18. But this brings up another issue I wondered about > for some time: In the good old days every prerelease was merged, nowdays > it's just the full releases. Is there a reason behing this as the actual > XFS releases are for specific versions anyway and the CVS basically is > a current top-of-tree branch? It's because it can take a fair amount of work to get the latest pre-release patch to merge into XFS. 2.5 is now the main development tree. That tree is keeping up with pre-patches as Steve has time to merge them. The 2.4 xfs tree is only being merged with major releases so Eric can spend less time merging and more time hunting down XFS bugs. -- 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 Apr 8 12:09:48 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g38J9m8d001165 for ; Mon, 8 Apr 2002 12:09:48 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g38J9mRs001164 for linux-xfs-outgoing; Mon, 8 Apr 2002 12:09:48 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from UberGeek ([209.184.141.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g38J9g8d001138 for ; Mon, 8 Apr 2002 12:09:42 -0700 Received: (qmail 31387 invoked by uid 500); 8 Apr 2002 19:09:26 -0000 Subject: Re: 2.4.19 merging? From: Austin Gonyou To: Nathan Straz Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020408185745.GV16203@sgi.com> References: <20020408185745.GV16203@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 08 Apr 2002 14:09:26 -0500 Message-Id: <1018292966.30714.37.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ahhh! Ok. I understand. I guess I was getting confused. Sorry for the static. On Mon, 2002-04-08 at 13:57, Nathan Straz wrote: > On Mon, Apr 08, 2002 at 07:06:13PM +0100, Christoph Hellwig wrote: > > It's back at 2.4.18. But this brings up another issue I wondered > about > > for some time: In the good old days every prerelease was merged, > nowdays > > it's just the full releases. Is there a reason behing this as the > actual > > XFS releases are for specific versions anyway and the CVS basically is > > a current top-of-tree branch? > > It's because it can take a fair amount of work to get the latest > pre-release patch to merge into XFS. 2.5 is now the main development > tree. That tree is keeping up with pre-patches as Steve has time to > merge them. The 2.4 xfs tree is only being merged with major releases > so Eric can spend less time merging and more time hunting down XFS bugs. > > > -- > Nate Straz nstraz@sgi.com > sgi, inc http://www.sgi.com/ > Linux Test Project http://ltp.sf.net/ -- Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb From owner-linux-xfs@oss.sgi.com Mon Apr 8 18:08:29 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3918T8d008964 for ; Mon, 8 Apr 2002 18:08:29 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3918To2008963 for linux-xfs-outgoing; Mon, 8 Apr 2002 18:08:29 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3918M8d008935 for ; Mon, 8 Apr 2002 18:08:22 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.2/8.12.0) with ESMTP id g3918gKa015138 for ; Mon, 8 Apr 2002 20:08:43 -0500 (CDT) Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3918f6G001130 for ; Mon, 8 Apr 2002 18:08:41 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3918dL40028566 for <@relay.sgi.com:linux-xfs@thebarn.com>; Mon, 8 Apr 2002 18:08:40 -0700 (PDT) Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA01695 for ; Tue, 9 Apr 2002 11:08:36 +1000 Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id LAA44920 for linux-xfs@thebarn.com; Tue, 9 Apr 2002 11:08:35 +1000 (AEST) Date: Tue, 9 Apr 2002 11:08:35 +1000 From: Timothy Shimmin To: linux-xfs@thebarn.com Subject: TAKE - EA short-form conversion bug in XFS kernel Message-ID: <20020409110835.C144037@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Resending to thebarn... as it didn't get thru on oss. Nathan, could you p_modmerge to 2.5 please. Date: Mon, 8 Apr 2002 16:33:14 +1000 (EST) From: Timothy Shimmin To: linux-xfs@oss.sgi.com Subject: TAKE - EA short-form conversion bug in XFS kernel This bug is evident, for example, when one has more than one EA and one deletes an EA and the remaining EAs can now fit into the inode but their individual sizes are greater than 254 bytes. The bug then puts the EAs into the short form format in the inode but the lengths are truncated to fit into 1 byte. This was evident with 1K inodes (large enough to fit an ACL) and changing the default and access ACLs on a file with existing default and access ACLs. In this case we delete an ACL/EA and then go to convert the remaining ACL/EA to shortform as it now fits in the inode. But its size of 304 bytes (fixed size for ACLs) means the EA valuelen field (1 byte in size) is now wrong. --Tim Date: Sun Apr 7 23:19:06 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:115916a linux/fs/xfs/xfs_attr_leaf.c - 1.59 - Apply olaf@sgi.com's fix for xfs_attr_shortform_allfit(). xfs_attr_shortform_allfit() determines if an EA will fit into the short form format but forgets to test if the valuelen will fit into 1 byte. We limit the length of the value even if it fits into the inode's attribute fork. pv#853637 From owner-linux-xfs@oss.sgi.com Mon Apr 8 23:10:03 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g396A38d018961 for ; Mon, 8 Apr 2002 23:10:03 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g396A3WC018960 for linux-xfs-outgoing; Mon, 8 Apr 2002 23:10:03 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail3.caramail.com (mail3.caramail.com [213.193.13.94]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3969s8d018922 for ; Mon, 8 Apr 2002 23:09:55 -0700 Received: from caramail.com (www22.caramail.com [213.193.13.32]) by mail3.caramail.com (8.8.8/8.8.8) with SMTP id JAB04733 for linux-xfs@oss.sgi.com; Tue, 9 Apr 2002 09:10:15 +0300 (DST) Posted-Date: Tue, 9 Apr 2002 09:10:15 +0300 (DST) From: LENHOF Jean-Yves To: linux-xfs@oss.sgi.com Message-ID: <1018332604026666@caramail.com> X-Mailer: Caramail - www.caramail.com X-Originating-IP: [193.251.61.154] Mime-Version: 1.0 Subject: LVM and the testing kernel Date: Tue, 09 Apr 2002 08:10:04 GMT+1 Content-Type: multipart/mixed; boundary="=_NextPart_Caramail_0266661018332604_ID" 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_Caramail_0266661018332604_ID Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi guys, The LVM does'nt seem to be enabled on the XFS 1.1 kernel under testing. It will be a good idea to enabled it because you already give LVM with previous release. The second problem I have depend on the first part : Which package I have to use for LVM (If I make a compile on my own of the 1.1 XFS version of the kernel)...as I read it seems to be the 1.0.3 of LVM release you provide with the 2.4.9-31 kernel. Can you provide one package on your website somewhere or would I have to take the rawhide one on the RedHat site or somewhere else ? For information, when building installation with buildinstall the 2.4.9-31 kernel (kernel-BOOT) does'nt seem to fit on the image files, it is too big. Have fun, PS : As a mail I send you some day before, there is still a problem with http://oss.sgi.com/projects/xfs/ml.html, there is not a lot about the 2002 year :-( .... For now I read info on http://marc.theaimsgroup.com/?l=3Dlinux-xfs&r=3D1&w=3D2 but I think It will be a good idea to make it work. (I'm already on a lot of mailing list so I don't want to receive more on my mail) Jy ______________________________________________________ Bo=EEte aux lettres - Caramail - http://www.caramail.com --=_NextPart_Caramail_0266661018332604_ID-- From owner-linux-xfs@oss.sgi.com Tue Apr 9 00:06:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3976J8d007244 for ; Tue, 9 Apr 2002 00:06:19 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3976J1Z007243 for linux-xfs-outgoing; Tue, 9 Apr 2002 00:06:19 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from finearts.uvic.ca (mail@khan.finearts.UVic.CA [142.104.26.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3976E8d007200 for ; Tue, 9 Apr 2002 00:06:14 -0700 Received: from rusty.finearts.uvic.ca ([142.104.26.11] helo=rusty) by finearts.uvic.ca with esmtp (Exim) id 16upi2-0000i3-00; Tue, 09 Apr 2002 00:06:30 -0700 Received: from www-data by rusty with local (Exim 3.34 #1 (Debian)) id 16upjB-0006s5-00; Tue, 09 Apr 2002 00:07:41 -0700 Received: from 24.80.200.43 ( [24.80.200.43]) as user dbroome@imap.finearts.uvic.ca by imp3.finearts.uvic.ca with HTTP; Tue, 9 Apr 2002 00:07:41 -0700 Message-ID: <1018336061.3cb2933d270f8@imp3.finearts.uvic.ca> Date: Tue, 9 Apr 2002 00:07:41 -0700 From: David Broome To: linux-xfs@oss.sgi.com Cc: dbroome@finearts.uvic.ca Subject: XFS newbie filesystem set-up suggestions. 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: 24.80.200.43 X-VirusScanned-by-Sophos-via-MailScanner: Found to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I have I would like to ask those on the list for some set-up suggestions. I am setting up 2 partitions on a hardware raid-5 (on a Mylex Extremeraid 2000) under Debian Linux 2.2 on intel with a 2.4.18 kernel with the version: 1.0.2+ 20020304-2 kernel patch. The 2 virtual drives for XFS will be 120GB and 378GB each. The files are varying between small .files and larger media files from faculty and student works (Faculty of Fine Arts at the University of Victoria, Canada). Looking at the current files the Average File Size (1K blocks / # of files) is 1681.6K. What suggestions are there for this setup: 1. best block size to use? 2. log file size config? 3. allocation groups? BTW is the slow delete problem fixed in the 20020304 CVS code? Dave, -- David Broome Programmer-Analyst.FineArts.UVic.CA /BSc /CNA /MCP 250.721-6307 dbroome@finearts.uvic.ca FIA 221 From owner-linux-xfs@oss.sgi.com Tue Apr 9 05:51:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39CpJ8d016109 for ; Tue, 9 Apr 2002 05:51:19 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39CpJqq016108 for linux-xfs-outgoing; Tue, 9 Apr 2002 05:51:19 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from msg.ecetra.com (dollar.ecetra.com [193.164.224.209]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39Cp48d016076 for ; Tue, 9 Apr 2002 05:51:05 -0700 Received: from vie-ac.office.ecetra.com (vie-ac.office.ecetra.com [10.251.148.148] (may be forged)) by msg.ecetra.com (8.9.3/8.9.3) with ESMTP id OAA08661 for ; Tue, 9 Apr 2002 14:51:06 +0200 Received: from vie-ac.office.ecetra.com (localhost [127.0.0.1]) by vie-ac.office.ecetra.com (8.12.2/8.12.1) with ESMTP id g39Cp6s2003822 for ; Tue, 9 Apr 2002 14:51:06 +0200 Received: (from alciocca@localhost) by vie-ac.office.ecetra.com (8.12.2/8.12.1/Submit) id g39Cp6rW003821 for linux-xfs@oss.sgi.com; Tue, 9 Apr 2002 14:51:06 +0200 Date: Tue, 9 Apr 2002 14:51:06 +0200 From: Adam Cioccarelli To: linux-xfs@oss.sgi.com Subject: Slackware Message-ID: <20020409125105.GC3785@ecetra.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="69pVuxX8awAiJ7fD" Content-Disposition: inline User-Agent: Mutt/1.5.0i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --69pVuxX8awAiJ7fD Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, it looks like XFS will be included in the next release of Slackware, from t= he slackware homepage... "The testing version of Slackware has seen many upgrades recently, includin= g improvements in nearly every package, the installer, and the package mana= gement system. Highlights include the 2.4.18 kernel, support for all four o= f the journaling filesystems for Linux (ext3, reiserfs, jfs, and xfs), and = glibc-2.2.5. Looks like Slackware 8.1 is getting closer. :-) More to come s= oon..." Adam --=20 --69pVuxX8awAiJ7fD Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIILKQYJKoZIhvcNAQcCoIILGjCCCxYCAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCCPwwggKAMIIB6aADAgECAgMGolwwDQYJKoZIhvcNAQEEBQAw gZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0 aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwg UlNBIDIwMDAuOC4zMDAeFw0wMjAxMzAxMTI2NDdaFw0wMzAxMzAxMTI2NDda MEUxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIjAgBgkqhkiG 9w0BCQEWE2FsY2lvY2NhQGVjZXRyYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQAD gY0AMIGJAoGBAMaNxCdMsXUhBtSj3H/+JxuptUDNATlUx51MBchxmGAu81z3 SW5+DpkXZuvMlsbnDOrlFH/VnBU/NtfrHFUfot10EccJhSiY3mp+uuzPVVgZ hymRIwuAai8isg/rgbKZhxKF3bZiow/6s/L2UCe29JmS+hTPYZMK21mUT3Yo AeHbAgMBAAGjMDAuMB4GA1UdEQQXMBWBE2FsY2lvY2NhQGVjZXRyYS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQDQfbv5Kp1u1nvAaRYL dsNxk+EN2BmRNAMlZi2i6FhZa5uig6So9COmgOxkik+M48QYoMvuciyPwCQ4 W7pJpEhMN80VlyVG9wa6gUB6+JQimoMLgki4MfT9rclJ7+BbujfmVNaYE7GT g4O7UWhIMOuA6KoBh7Rms6nh0GFKBv3I7zCCAzgwggKhoAMCAQICEGZFcrfM dPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgG A1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTla MIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD VQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2Vy dGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls IFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4z MqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0 caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr 4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMBAAGjTjBM MCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzAS BgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQF AAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/Oby JOuR+r3sDSo491BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJA XWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZph39Ins6ln+eE2MliYq0FxjCC AzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEEBQAw gdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNV BAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJ ARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAw MDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRo YXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMT H1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcN AQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO40QpimM1 Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqd knWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYA LQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQ cml2YXRlTGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQE AwIBBjANBgkqhkiG9w0BAQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KB IqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3sDSo491BVqGz3Da1MG7wD9LXrokef bKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0fnQLzWtvKPPZE6iZp h39Ins6ln+eE2MliYq0FxjGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJa QTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24x DzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2Vydmlj ZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzAC AwaiXDAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTAyMDQwOTEyNTEwNVowIwYJKoZIhvcNAQkEMRYE FM9epolsscnqt0lC1pKsjunf2DAWMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGADflrqqD6JIDkNkiO feZeT5LQqnfIiQXCnp9LgXiQrcSDdbytIaFL0vzmIFQlTlo/sNuBnrG2FXr8 J6VDzC/6E2q3zv+b4BY4M2j4K9GkLyS8/zXImJRVvzMfQpjrAPlTUg1vNTLJ VhXZB1gdbUgrTLsnl6G6ErQHFjKM++arhfc= --69pVuxX8awAiJ7fD-- From owner-linux-xfs@oss.sgi.com Tue Apr 9 06:32:48 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39DWm8d017225 for ; Tue, 9 Apr 2002 06:32:48 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39DWl0R017223 for linux-xfs-outgoing; Tue, 9 Apr 2002 06:32:47 -0700 X-Authentication-Warning: oss.sgi.com: mail 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 g39DWf8d017194 for ; Tue, 9 Apr 2002 06:32:42 -0700 Received: (qmail 4280 invoked by uid 1000); 9 Apr 2002 13:40:51 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 9 Apr 2002 13:40:51 -0000 Date: Tue, 9 Apr 2002 16:40:51 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Adam Cioccarelli cc: Subject: Re: Slackware In-Reply-To: <20020409125105.GC3785@ecetra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 9 Apr 2002, Adam Cioccarelli wrote: > Hi, > > it looks like XFS will be included in the next release of Slackware, > from the slackware homepage... > > "The testing version of Slackware has seen many upgrades recently, > including improvements in nearly every package, the installer, and the > package management system. Highlights include the 2.4.18 kernel, > support for all four of the journaling filesystems for Linux (ext3, > reiserfs, jfs, and xfs), and glibc-2.2.5. Looks like Slackware 8.1 is > getting closer. :-) More to come soon..." > Hi Adam, XFS Folks, I am a Slackware user and I like very much this distro. It seems that its taking a different aproach. Slackware used to ship with the kernel.org kernel, and including XFS, jfs means patches. Im curious on what kernel will that be based... ---------------------------- 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 Apr 9 07:51:42 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39Epg8d021631 for ; Tue, 9 Apr 2002 07:51:42 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39Epfk9021630 for linux-xfs-outgoing; Tue, 9 Apr 2002 07:51:41 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cellus.no (ns.cellus.no [193.91.191.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39EpZ8d021600 for ; Tue, 9 Apr 2002 07:51:36 -0700 Received: from ip02 (ip02.cellus.no [193.91.191.122]) by cellus.no (8.9.3/8.9.3) with SMTP id QAA04594 for ; Tue, 9 Apr 2002 16:51:57 +0200 From: =?iso-8859-1?Q?Christian_Sander_R=F8snes?= To: Subject: XFS and User Land Mode (UML - Virtual Server) ? Date: Tue, 9 Apr 2002 16:52:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, Has anyone tested XFS with User Land Mode (UML) or some other virtual server (chroot style). I'm looking into ways of setting up an application server to run Linux (preferable XFS over our RAID 0+1 70 GB diskssystem), mysql, java, plus some application server (Orion). The plan is to allow different external consultants develop and setup application services on this machine. However, should their applications run amok, or someone get the desire to snoop around, I'd like to chroot or limit what they can do to the rest of the system and network. A virtual server looks promising for this type of scenario. I'm in the process of checking out the different solutions, and UML looks like a contender. The linux box (Compaq DL380 G2) has dual cpus (1266Mhz P3), 1280 MB RAM, 70 GB RAID 0+1, so I hope this would suffice to handle up to 20 virtual servers. Anyway, I plan to see if I can get XFS and UML up and running. So, if anyone has experience with this combo, the info would be appreciated. Thanks Christian From owner-linux-xfs@oss.sgi.com Tue Apr 9 07:58:12 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39EwC8d021903 for ; Tue, 9 Apr 2002 07:58:12 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39EwCwK021901 for linux-xfs-outgoing; Tue, 9 Apr 2002 07:58:12 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cellus.no (ns.cellus.no [193.91.191.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39Ew88d021875 for ; Tue, 9 Apr 2002 07:58:09 -0700 Received: from ip02 (ip02.cellus.no [193.91.191.122]) by cellus.no (8.9.3/8.9.3) with SMTP id QAA04844 for ; Tue, 9 Apr 2002 16:58:31 +0200 From: =?iso-8859-1?Q?Christian_Sander_R=F8snes?= To: Subject: RE: XFS and User-Mode Linux (UML - Virtual Server) ? Date: Tue, 9 Apr 2002 16:58:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sorry, that should read: UML ==> User-Mode Linux From owner-linux-xfs@oss.sgi.com Tue Apr 9 10:27:42 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g39HRf8d027539 for ; Tue, 9 Apr 2002 10:27:42 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g39HRfRZ027538 for linux-xfs-outgoing; Tue, 9 Apr 2002 10:27:41 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g39HRV8d027509 for ; Tue, 9 Apr 2002 10:27:32 -0700 Received: from blaze.homeip.net (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 233D822998; Tue, 9 Apr 2002 13:27:37 -0400 (EDT) Subject: Re: Slackware From: Paul Blazejowski To: Mihai RUSU Cc: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-igWRPUKgfbpGMHU5srjx" Organization: BlazeBox.HomeIp.Net X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 09 Apr 2002 13:27:52 -0400 Message-Id: <1018373273.858.3.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-igWRPUKgfbpGMHU5srjx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-04-09 at 09:40, Mihai RUSU wrote:=20 >=20 > Hi Adam, XFS Folks, >=20 > I am a Slackware user and I like very much this distro. It seems that its > taking a different aproach. Slackware used to ship with the kernel.org > kernel, and including XFS, jfs means patches. Im curious on what kernel > will that be based... >=20 Hi,=20 Slackware always shipped with kernel.org kernel sources and it's not going to be different this time, i think.=20 And looking at http://carroll.cac.psu.edu/pub/linux/distributions/slackware/slackware-curr= ent/source/k shows jfs-0.1.16 and xfs-20020329.diff.patch.bz2 patches that are currently being used but i think this might change before 8.1 ships...=20 Only thing that is missing from slack is the ksymoops package.Currently it does not build on 8.0 coz the bfd utils is missing some symbols.It would be great if Pat would include ksymoops for when the kernels oops. How are we supposed to generate kernel bug reports? not that oopses on slack happen often but still it would be nice to have it...=20 Regards,=20 Paul --=-igWRPUKgfbpGMHU5srjx 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 iEYEABECAAYFAjyzJJgACgkQOkMJCMfleaIVBwCgp8C9XL/L2gzdXkg2eQ3nz30F 5goAn2+dYlZ/qXiI5ThJa0OVhYJdoqgV =issJ -----END PGP SIGNATURE----- --=-igWRPUKgfbpGMHU5srjx-- From owner-linux-xfs@oss.sgi.com Tue Apr 9 17:05:34 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3A05Y8d017486 for ; Tue, 9 Apr 2002 17:05:34 -0700 Received: (from mail@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3A05Yqv017485 for linux-xfs-outgoing; Tue, 9 Apr 2002 17:05:34 -0700 X-Authentication-Warning: oss.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from muriel.parsec.at (muriel.parsec.at [212.236.50.199]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3A05U8d017459 for ; Tue, 9 Apr 2002 17:05:31 -0700 Received: from localhost (ag@localhost) by muriel.parsec.at (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g3A05qU14026; Wed, 10 Apr 2002 02:05:52 +0200 Date: Wed, 10 Apr 2002 02:05:52 +0200 (CEST) From: Andreas Gruenbacher X-X-Sender: To: Nathan Scott cc: , Subject: Re: TAKE - acl 2.0.7 In-Reply-To: <200204100002.KAA88446@snort.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks! --Andreas. From owner-linux-xfs@oss.sgi.com Wed Apr 10 01:02:21 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3A82L8d031538 for ; Wed, 10 Apr 2002 01:02:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3A82LDZ031537 for linux-xfs-outgoing; Wed, 10 Apr 2002 01:02:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from femail.waymark.net (femail.waymark.net [206.176.148.84]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3A82I8d031511 for ; Wed, 10 Apr 2002 01:02:18 -0700 Received: (qmail 14408 invoked from network); 10 Apr 2002 08:02:43 -0000 Received: from ip-249-ppp.waymark.net (HELO ?192.168.0.2?) (206.176.129.249) by femail.waymark.net with SMTP; 10 Apr 2002 08:02:43 -0000 Subject: Thanks! From: Roger Davenport To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 10 Apr 2002 02:02:05 -0500 Message-Id: <1018422131.1201.18.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hey.. just dropping you all a line... thanks for all the great work! XFS is incredible, reliable, fast, and I'm converting all my boxen tonight. Thanks! Roger From owner-linux-xfs@oss.sgi.com Wed Apr 10 09:00:33 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AG0X8d005365 for ; Wed, 10 Apr 2002 09:00:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AG0XA8005364 for linux-xfs-outgoing; Wed, 10 Apr 2002 09:00: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AG0Q8d005333 for ; Wed, 10 Apr 2002 09:00: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 LAA91877 for ; Wed, 10 Apr 2002 11:00:49 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA63851 for ; Wed, 10 Apr 2002 11:00:49 -0500 (CDT) Subject: XFS 1.1 PR4 test release From: Eric Sandeen To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 10 Apr 2002 11:00:49 -0500 Message-Id: <1018454449.22404.11.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all - What better way to celebrate the return of oss.sgi.com than by pounding it to death, downloading updated XFS kernels? We stayed busy while oss was down, and we are pleased to release the fourth (and final?) test release of XFS 1.1. Only minor changes since the last version: * LVM compile / config fix * refcache dirty timer fix * ia64 warnings fix * inode32 fix * pabebuf_read_full_page error handling fix Available at ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1/ and mirrors worldwide... Have fun, -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Wed Apr 10 10:17:00 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AHH08d012667 for ; Wed, 10 Apr 2002 10:17:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AHGxIL012666 for linux-xfs-outgoing; Wed, 10 Apr 2002 10:16:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhub-1.iastate.edu (mailhub-1.iastate.edu [129.186.140.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AHGf8d012634 for ; Wed, 10 Apr 2002 10:16:41 -0700 Received: from mailout-1.iastate.edu (mailout-1.iastate.edu [129.186.140.1]) by mailhub-1.iastate.edu (8.9.3/8.9.3) with SMTP id MAA03951 for ; Wed, 10 Apr 2002 12:17:03 -0500 Received: from akrherz.agron.iastate.edu(129.186.26.51) by mailout-1.iastate.edu via csmap id 9187; Wed, 10 Apr 2002 12:18:48 -0500 (CDT) Date: Wed, 10 Apr 2002 12:17:03 -0500 (CDT) From: Daryl Herzmann X-X-Sender: akrherz@akrherz.agron.iastate.edu To: linux-xfs@oss.sgi.com Subject: Oops 2.4.18 + RAID5 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I have a box that had been running RH 7.1 + XFS for a year without a single problem. Recently, I put 3 120G Maxtor 4G120J6 drives on the onboard Promise Controller (pdc202xx) and did software RAID 5. And wow, have the problems started! I went from running a 2.4.3 something kernel to a custom compiled 2.4.18 w/ SGI patch dated March 3. Still no luck. It seems under heavy NFS load, that these problems will start occuring. Any thoughts? I have been trying to follow the ongoing NFS + XFS + RAID 5 discussions, but I am not sure where I should be at regarding kernel + patches. My ksymoops is below. Thanks! Daryl Other info that may be helpful. # lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40) 00:08.0 VGA compatible controller: Trident Microsystems Blade 3D PCI/AGP (rev 3a) 00:0c.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) 00:0f.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02) # free total used free shared buffers cached Mem: 900644 897436 3208 0 0 842932 -/+ buffers/cache: 54504 846140 Swap: 1028152 0 1028152 # cat /proc/ide/pdc202xx PDC20265 Chipset. ------------------------------- General Status --------------------------------- Burst Mode : enabled Host Mode : Normal Bus Clocking : 33 PCI Internal IO pad select : 10 mA Status Polling Period : 0 Interrupt Check Status Polling Delay : 2 --------------- Primary Channel ---------------- Secondary Channel ------------- enabled enabled 66 Clocking enabled enabled Mode MASTER Mode MASTER FIFO Empty ???????????? --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------ DMA enabled: no yes yes yes DMA Mode: NOTSET UDMA 4 UDMA 4 UDMA 4 PIO Mode: NOTSET PIO ? PIO ? PIO ? Here is my ksymoops from this morning's crash. >>EIP; c013f736 <===== Trace; c013d70c Trace; c0126e78 Trace; c013da00 Trace; c0127037 Trace; c012708c Trace; c0127141 Trace; c01271b6 Trace; c0127311 Trace; c0127270 Trace; c0105000 Trace; c0105536 Trace; c0127270 Code; c013f736 00000000 <_EIP>: Code; c013f736 <===== 0: 8b 46 20 mov 0x20(%esi),%eax <===== Code; c013f739 3: 85 c0 test %eax,%eax Code; c013f73b 5: 0f 45 f8 cmovne %eax,%edi Code; c013f73e 8: 85 ff test %edi,%edi Code; c013f740 a: 74 0b je 17 <_EIP+0x17> c013f74d Code; c013f742 c: 8b 47 10 mov 0x10(%edi),%eax Code; c013f745 f: 85 c0 test %eax,%eax Code; c013f747 11: 74 04 je 17 <_EIP+0x17> c013f74d Code; c013f749 13: 53 push %ebx and then the next immediate oops >>EIP; c013f736 <===== Trace; c013d70c Trace; c0126e78 Trace; c013da00 Trace; c0127037 Trace; c012708c Trace; c0127951 <_alloc_pages+71/1c0> Trace; c0127bbb <__alloc_pages+11b/180> Trace; c0127c30 <__get_free_pages+10/20> Trace; c0139d73 <__pollwait+33/1040> Trace; c025137e Trace; c023abdf Trace; c0139fcb <__pollwait+28b/1040> Trace; c013a43c <__pollwait+6fc/1040> Trace; c0106cfb <__up_wakeup+110f/23e4> Code; c013f736 00000000 <_EIP>: Code; c013f736 <===== 0: 8b 46 20 mov 0x20(%esi),%eax <===== Code; c013f739 3: 85 c0 test %eax,%eax Code; c013f73b 5: 0f 45 f8 cmovne %eax,%edi Code; c013f73e 8: 85 ff test %edi,%edi Code; c013f740 a: 74 0b je 17 <_EIP+0x17> c013f74d Code; c013f742 c: 8b 47 10 mov 0x10(%edi),%eax Code; c013f745 f: 85 c0 test %eax,%eax Code; c013f747 11: 74 04 je 17 <_EIP+0x17> c013f74d Code; c013f749 13: 53 push %ebx -- /** * Daryl Herzmann (akrherz@iastate.edu) * Program Assistant -- Iowa Environmental Mesonet * http://mesonet.agron.iastate.edu */ From owner-linux-xfs@oss.sgi.com Wed Apr 10 10:52:36 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AHqZ8d013853 for ; Wed, 10 Apr 2002 10:52:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AHqZdD013852 for linux-xfs-outgoing; Wed, 10 Apr 2002 10:52:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf24bis.bellsouth.net (mail024.mail.bellsouth.net [205.152.58.64]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3AHqE8d013819 for ; Wed, 10 Apr 2002 10:52:14 -0700 Received: from taz ([65.81.169.34]) by imf24bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020410175237.DJAW1154.imf24bis.bellsouth.net@taz>; Wed, 10 Apr 2002 13:52:37 -0400 Date: Wed, 10 Apr 2002 13:51:16 -0400 From: Greg Freemyer Subject: re: Oops 2.4.18 + RAID5 To: Daryl Herzmann , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020410175237.DJAW1154.imf24bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3AHqE8d013822 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Daryl, We tried setting up something similar in out lab. We ended up with a big mess as well. We decided that what we really needed to do was ignore that Promise Controller and go get a 3ware controller. They are very reasonably priced. The 3ware controller is supported in the base kernel without any patches. It is also certified by Redhat. To be honest we have not actually done this yet, but all indications show that this is the way to go. Greg >> Hi, >> I have a box that had been running RH 7.1 + XFS for a year without >> a single problem. Recently, I put 3 120G Maxtor 4G120J6 drives on the >> onboard Promise Controller (pdc202xx) and did software RAID 5. And wow, >> have the problems started! I went from running a 2.4.3 something kernel >> to a custom compiled 2.4.18 w/ SGI patch dated March 3. Still no luck. >> It seems under heavy NFS load, that these problems will start occuring. >> Any thoughts? I have been trying to follow the ongoing NFS + >> XFS + RAID 5 discussions, but I am not sure where I should be at >> regarding kernel + patches. >> My ksymoops is below. >> Thanks! Daryl >> Other info that may be helpful. >> # lspci >> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev >> >> 03) >> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] >> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] >> (rev 40) >> 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) >> 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] >> (rev 40) >> 00:08.0 VGA compatible controller: Trident Microsystems Blade 3D PCI/AGP >> (rev 3a) >> 00:0c.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] >> (rev 30) >> 00:0f.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02) >> # free >> total used free shared buffers cached >> Mem: 900644 897436 3208 0 0 842932 >> -/+ buffers/cache: 54504 846140 >> Swap: 1028152 0 1028152 >> # cat /proc/ide/pdc202xx >> PDC20265 Chipset. >> ------------------------------- General Status >> --------------------------------- >> Burst Mode : enabled >> Host Mode : Normal >> Bus Clocking : 33 PCI Internal >> IO pad select : 10 mA >> Status Polling Period : 0 >> Interrupt Check Status Polling Delay : 2 >> --------------- Primary Channel ---------------- Secondary Channel >> ------------- >> enabled enabled >> 66 Clocking enabled enabled >> Mode MASTER Mode MASTER >> FIFO Empty ???????????? >> --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 >> ------ >> DMA enabled: no yes yes yes >> DMA Mode: NOTSET UDMA 4 UDMA 4 UDMA 4 >> PIO Mode: NOTSET PIO ? PIO ? PIO ? >> Here is my ksymoops from this morning's crash. >> >>EIP; c013f736 <===== >> Trace; c013d70c >> Trace; c0126e78 >> Trace; c013da00 >> Trace; c0127037 >> Trace; c012708c >> Trace; c0127141 >> Trace; c01271b6 >> Trace; c0127311 >> Trace; c0127270 >> Trace; c0105000 >> Trace; c0105536 >> Trace; c0127270 >> Code; c013f736 >> 00000000 <_EIP>: >> Code; c013f736 <===== >> 0: 8b 46 20 mov 0x20(%esi),%eax <===== >> Code; c013f739 >> 3: 85 c0 test %eax,%eax >> Code; c013f73b >> 5: 0f 45 f8 cmovne %eax,%edi >> Code; c013f73e >> 8: 85 ff test %edi,%edi >> Code; c013f740 >> a: 74 0b je 17 <_EIP+0x17> c013f74d >> >> Code; c013f742 >> c: 8b 47 10 mov 0x10(%edi),%eax >> Code; c013f745 >> f: 85 c0 test %eax,%eax >> Code; c013f747 >> 11: 74 04 je 17 <_EIP+0x17> c013f74d >> >> Code; c013f749 >> 13: 53 push %ebx >> and then the next immediate oops >> >>EIP; c013f736 <===== >> Trace; c013d70c >> Trace; c0126e78 >> Trace; c013da00 >> Trace; c0127037 >> Trace; c012708c >> Trace; c0127951 <_alloc_pages+71/1c0> >> Trace; c0127bbb <__alloc_pages+11b/180> >> Trace; c0127c30 <__get_free_pages+10/20> >> Trace; c0139d73 <__pollwait+33/1040> >> Trace; c025137e >> Trace; c023abdf >> Trace; c0139fcb <__pollwait+28b/1040> >> Trace; c013a43c <__pollwait+6fc/1040> >> Trace; c0106cfb <__up_wakeup+110f/23e4> >> Code; c013f736 >> 00000000 <_EIP>: >> Code; c013f736 <===== >> 0: 8b 46 20 mov 0x20(%esi),%eax <===== >> Code; c013f739 >> 3: 85 c0 test %eax,%eax >> Code; c013f73b >> 5: 0f 45 f8 cmovne %eax,%edi >> Code; c013f73e >> 8: 85 ff test %edi,%edi >> Code; c013f740 >> a: 74 0b je 17 <_EIP+0x17> c013f74d >> >> Code; c013f742 >> c: 8b 47 10 mov 0x10(%edi),%eax >> Code; c013f745 >> f: 85 c0 test %eax,%eax >> Code; c013f747 >> 11: 74 04 je 17 <_EIP+0x17> c013f74d >> >> Code; c013f749 >> 13: 53 push %ebx >> -- >> /** >> * Daryl Herzmann (akrherz@iastate.edu) >> * Program Assistant -- Iowa Environmental Mesonet >> * http://mesonet.agron.iastate.edu >> */ Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Apr 10 11:19:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3AIJM8d015787 for ; Wed, 10 Apr 2002 11:19:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3AIJEJV015782 for linux-xfs-outgoing; Wed, 10 Apr 2002 11:19:14 -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 g3AIIj8d015741 for ; Wed, 10 Apr 2002 11:18:46 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx13)) with ESMTP id 8D3F9C382; Wed, 10 Apr 2002 20:19: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 UAA03684; Wed, 10 Apr 2002 20:19:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 01BEF57306; Wed, 10 Apr 2002 20:18:57 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 5940A25835; Wed, 10 Apr 2002 20:18:56 +0200 (CEST) Message-ID: <3CB4820F.721107D7@ch.sauter-bc.com> Date: Wed, 10 Apr 2002 20:18:55 +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: Daryl Herzmann Cc: linux-xfs@oss.sgi.com Subject: Re: Oops 2.4.18 + RAID5 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I've been running a similar server for almost a year now. It's RH 7.1 + XFS, Promise Ultra100TX2 with 4 Quantum 15G drives, software RAID5. I have a second server, RH 7.2 + XFS, Promise Ultra100TX2 with 4 IBM 60G drives, software RAID5. No problems so far, only 3 of 8 IBM drives dead, but that's another story. Can you try a current RH based kernel with XFS? At least for me it has always worked very well. ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1/kernel_rpms/2.4.9-31-RH/ This is from the small server: [root@xxl pub]# cat /proc/ide/pdc202xx PDC20268 TX2 Chipset. ------------------------------- General Status --------------------------------- Burst Mode : enabled Host Mode : Tri-Stated Bus Clocking : 100 External IO pad select : 10 mA Status Polling Period : 15 Interrupt Check Status Polling Delay : 15 --------------- Primary Channel ---------------- Secondary Channel ------------- enabled enabled 66 Clocking enabled enabled Mode MASTER Mode MASTER --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------ DMA enabled: yes yes yes yes --------------- Cannot Decode HOST --------------- [root@xxl pub]# lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev 04) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA [Apollo VP] (rev 47) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) 00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) 00:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 64) 00:09.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08) 00:0a.0 Unknown mass storage controller: Promise Technology, Inc.: Unknown device 4d68 (rev 01) 00:0b.0 SCSI storage controller: Adaptec AIC-7881U 01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 03) [root@xxl pub]# cat /proc/mdstat Personalities : [raid1] [raid5] read_ahead 1024 sectors md8 : active raid5 hde10[0] hdf7[2] hdg10[1] hdh7[3] 31406976 blocks level 5, 128k chunk, algorithm 0 [4/4] [UUUU] md7 : active raid1 hdf6[0] hdh6[1] 1024000 blocks [2/2] [UU] md5 : active raid1 hdf5[0] hdh5[1] 3072256 blocks [2/2] [UU] md0 : active raid1 hde1[0] hdf1[1] hdg1[2] hdh1[3] 102720 blocks [4/4] [UUUU] md6 : active raid1 hde9[0] hdg9[1] 1024000 blocks [2/2] [UU] md4 : active raid1 hde8[0] hdg8[1] 511936 blocks [2/2] [UU] md3 : active raid1 hde7[0] hdg7[1] 511936 blocks [2/2] [UU] md2 : active raid1 hde6[0] hdg6[1] 1755328 blocks [2/2] [UU] md1 : active raid1 hde5[0] hdg5[1] 292672 blocks [2/2] [UU] unused devices: Daryl Herzmann schrieb: > > Hi, > I have a box that had been running RH 7.1 + XFS for a year without > a single problem. Recently, I put 3 120G Maxtor 4G120J6 drives on the > onboard Promise Controller (pdc202xx) and did software RAID 5. And wow, > have the problems started! I went from running a 2.4.3 something kernel > to a custom compiled 2.4.18 w/ SGI patch dated March 3. Still no luck. > It seems under heavy NFS load, that these problems will start occuring. > > Any thoughts? I have been trying to follow the ongoing NFS + > XFS + RAID 5 discussions, but I am not sure where I should be at > regarding kernel + patches. > > My ksymoops is below. > > Thanks! Daryl > > Other info that may be helpful. > > # lspci > 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev > 03) > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] > 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] > (rev 40) > 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) > 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] > (rev 40) > 00:08.0 VGA compatible controller: Trident Microsystems Blade 3D PCI/AGP > (rev 3a) > 00:0c.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] > (rev 30) > 00:0f.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02) > > # free > total used free shared buffers cached > Mem: 900644 897436 3208 0 0 842932 > -/+ buffers/cache: 54504 846140 > Swap: 1028152 0 1028152 > > # cat /proc/ide/pdc202xx > > PDC20265 Chipset. > ------------------------------- General Status > --------------------------------- > Burst Mode : enabled > Host Mode : Normal > Bus Clocking : 33 PCI Internal > IO pad select : 10 mA > Status Polling Period : 0 > Interrupt Check Status Polling Delay : 2 > --------------- Primary Channel ---------------- Secondary Channel > ------------- > enabled enabled > 66 Clocking enabled enabled > Mode MASTER Mode MASTER > FIFO Empty ???????????? > --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 > ------ > DMA enabled: no yes yes yes > DMA Mode: NOTSET UDMA 4 UDMA 4 UDMA 4 > PIO Mode: NOTSET PIO ? PIO ? PIO ? > > Here is my ksymoops from this morning's crash. > > >>EIP; c013f736 <===== > Trace; c013d70c > Trace; c0126e78 > Trace; c013da00 > Trace; c0127037 > Trace; c012708c > Trace; c0127141 > Trace; c01271b6 > Trace; c0127311 > Trace; c0127270 > Trace; c0105000 > Trace; c0105536 > Trace; c0127270 > Code; c013f736 > 00000000 <_EIP>: > Code; c013f736 <===== > 0: 8b 46 20 mov 0x20(%esi),%eax <===== > Code; c013f739 > 3: 85 c0 test %eax,%eax > Code; c013f73b > 5: 0f 45 f8 cmovne %eax,%edi > Code; c013f73e > 8: 85 ff test %edi,%edi > Code; c013f740 > a: 74 0b je 17 <_EIP+0x17> c013f74d > > Code; c013f742 > c: 8b 47 10 mov 0x10(%edi),%eax > Code; c013f745 > f: 85 c0 test %eax,%eax > Code; c013f747 > 11: 74 04 je 17 <_EIP+0x17> c013f74d > > Code; c013f749 > 13: 53 push %ebx > > and then the next immediate oops > > >>EIP; c013f736 <===== > Trace; c013d70c > Trace; c0126e78 > Trace; c013da00 > Trace; c0127037 > Trace; c012708c > Trace; c0127951 <_alloc_pages+71/1c0> > Trace; c0127bbb <__alloc_pages+11b/180> > Trace; c0127c30 <__get_free_pages+10/20> > Trace; c0139d73 <__pollwait+33/1040> > Trace; c025137e > Trace; c023abdf > Trace; c0139fcb <__pollwait+28b/1040> > Trace; c013a43c <__pollwait+6fc/1040> > Trace; c0106cfb <__up_wakeup+110f/23e4> > Code; c013f736 > 00000000 <_EIP>: > Code; c013f736 <===== > 0: 8b 46 20 mov 0x20(%esi),%eax <===== > Code; c013f739 > 3: 85 c0 test %eax,%eax > Code; c013f73b > 5: 0f 45 f8 cmovne %eax,%edi > Code; c013f73e > 8: 85 ff test %edi,%edi > Code; c013f740 > a: 74 0b je 17 <_EIP+0x17> c013f74d > > Code; c013f742 > c: 8b 47 10 mov 0x10(%edi),%eax > Code; c013f745 > f: 85 c0 test %eax,%eax > Code; c013f747 > 11: 74 04 je 17 <_EIP+0x17> c013f74d > > Code; c013f749 > 13: 53 push %ebx > > -- > /** > * Daryl Herzmann (akrherz@iastate.edu) > * Program Assistant -- Iowa Environmental Mesonet > * http://mesonet.agron.iastate.edu > */ From owner-linux-xfs@oss.sgi.com Wed Apr 10 22:27:32 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3B5RW8d005659 for ; Wed, 10 Apr 2002 22:27:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3B5RWVZ005658 for linux-xfs-outgoing; Wed, 10 Apr 2002 22:27:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.blazebox.homeip.net (postfix@pool-141-155-137-69.ny5030.east.verizon.net [141.155.137.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3B5RO8d005628 for ; Wed, 10 Apr 2002 22:27:25 -0700 Received: from blaze.homeip.net (blaze.homeip.net [192.168.0.2]) by mail.blazebox.homeip.net (Postfix) with ESMTP id 6E74D22998; Thu, 11 Apr 2002 01:27:31 -0400 (EDT) Subject: Re: Slackware From: Paul Blazejowski To: Keith Owens Cc: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bw1ArtD2isFuVdnCc243" Organization: BlazeBox.HomeIp.Net X-Mailer: Ximian Evolution 1.1.0.99 (Preview Release) Date: 11 Apr 2002 01:27:56 -0400 Message-Id: <1018502876.1079.8.camel@blaze> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-bw1ArtD2isFuVdnCc243 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-04-09 at 20:39, Keith Owens wrote:=20 > I have been told that this is a symptom of installing a mixture of > libbfd and libiberty and getting out of sync.=20=20 >=20 > http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D101773461204829&w=3D2 In my case it was libiberty missing htab functions.New binutils package from gnu's site fixed that problem and ksymoops compiled just fine. --=-bw1ArtD2isFuVdnCc243 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 iEYEABECAAYFAjy1HtwACgkQOkMJCMfleaK33ACePKcQHoO+uPo3aJBjYUuLNLGP 8IoAoOH9ZO4UtspBfd9AuovwWJlcth57 =XzZE -----END PGP SIGNATURE----- --=-bw1ArtD2isFuVdnCc243-- From owner-linux-xfs@oss.sgi.com Thu Apr 11 09:17:59 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3BGHw8d031342 for ; Thu, 11 Apr 2002 09:17:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3BGHwDs031341 for linux-xfs-outgoing; Thu, 11 Apr 2002 09:17:58 -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 g3BGHp8d031312 for ; Thu, 11 Apr 2002 09:17:51 -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 g3BGILH07552; Thu, 11 Apr 2002 17:18: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 g3BGHwg09391; Thu, 11 Apr 2002 17:17:59 +0100 (BST) Message-ID: <3CB5B736.3F588C69@soton.ac.uk> Date: Thu, 11 Apr 2002 17:17:58 +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 CC: linux-xfs@oss.sgi.com, idh@soton.ac.uk Subject: Re: TAKE - fix a bug in memory freeing References: <200203201906.g2KJ69q10974@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MailScanner: Believed to be clean Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 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? Many thanks for all your help. Ian Hardy Steve Lord wrote: > > Only happens under high memory pressure, Ian, I think this was > your original oops. > > Date: Wed Mar 20 11:06:42 PST 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:114531a > linux/fs/xfs_support/kmem.c - 1.22 > - Fix the case where we used vmalloc to allocate memory under pressure, > we need to free it that way -- /////////////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 Apr 11 17:13:43 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C0Dh8d015319 for ; Thu, 11 Apr 2002 17:13:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C0DhlW015318 for linux-xfs-outgoing; Thu, 11 Apr 2002 17:13:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from intranet.chipwrights.com ([216.75.129.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3C0Da8d015291 for ; Thu, 11 Apr 2002 17:13:36 -0700 Received: from chipwrights.com (ctaylor.chipwrights.com [192.168.42.120]) by intranet.chipwrights.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DPGW9686; Thu, 11 Apr 2002 20:18:03 -0400 Message-ID: <3CB626D1.398F9598@chipwrights.com> Date: Thu, 11 Apr 2002 20:14:09 -0400 From: Clem Taylor X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.12 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2.4.18-xfs 1TB stability problems. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm using 2.4.18-xfs on a dual 1.2GHz Athlon with 1gig of RAM. The machine has a 3ware 7850 with 8 160G drives (RAID5) with an XFS file system (1.0TB). It also has a SCSI software raid root volume and a IDE scratch disk both with ext3. The XFS filesystem is ~40% full with an average file size of ~4-5G The 1TB array is a recent addition to a previously stable system. The RAID volume seemed fine in my initial burn in and stress testing, but now that I have live data on the array I've been having stability problems. In the last <2 months I've had 3 crashes... The first crash was a strange OOM type problem after the box had been up for a few weeks. It started with a series of 'eth0: memory shortage' on a box that was mostly doing NFS, followed by several 'Unable to handle kernel NULL pointer dereference at virtual address 00000030' in kswapd, then klogd, shortly after that it oppsed and wedged. In the last two weeks I've had it die twice, both times within a minute of starting to mv ~800M from an SGI O2 to the linux box via NFS3. The O2 reported NFS timeout errors, the linux box would respond to pings and some things that didn't depend on diskio continued to work. dmesg and df would hang and couldn't be interrupted. In both cases I was forced to reset. I'm not sure if the problems I'm seeing have anything to do with XFS, but my 2 most recent crashes occurred shortly after starting to move data to the XFS volume on an otherwise idle system. Any ideas / debugging tips? Many thanks, Clem From owner-linux-xfs@oss.sgi.com Thu Apr 11 17:49:36 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C0na8d016211 for ; Thu, 11 Apr 2002 17:49:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C0na7W016210 for linux-xfs-outgoing; Thu, 11 Apr 2002 17:49:36 -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 g3C0nP8d016180 for ; Thu, 11 Apr 2002 17:49:27 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16vpG1-000176-00; Fri, 12 Apr 2002 02:49:41 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 16vpFw-0003MA-00; Fri, 12 Apr 2002 02:49:36 +0200 Message-ID: <3CB62F20.910749CD@it.up.ac.za> Date: Fri, 12 Apr 2002 02:49:36 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Clem Taylor CC: linux-xfs@oss.sgi.com Subject: Re: 2.4.18-xfs 1TB stability problems. References: <3CB626D1.398F9598@chipwrights.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16vpFw-0003MA-00*KIdxWVdPSqk* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There are a few issues with the linux kernel (Nothing to do with XFS). You can look at this URL to see what Andrea Arcangeli has to say. http://lwn.net/2002/0411/a/vm-33-reason.php3 get a stock 2.4.18 from a kernel mirror (I use ftp.is.co.za). ftp://ftp.is.co.za/linux/kernel/pub/linux/kernel/v2.4/linux-2.4.18.tar.gz apply ftp://ftp.is.co.za/linux/kernel/pub/linux/kernel/v2.4/testing/patch-2.4.19-pre6.bz2 and then ftp://ftp.is.co.za/linux/kernel/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre6aa1.bz2 The Andrea Arcangeli kernels has XFS and his latest vm tweaks. I do not know what version of XFS he uses. It is worth a try. Paul Clem Taylor wrote: > I'm using 2.4.18-xfs on a dual 1.2GHz Athlon with 1gig of RAM. The machine > has a 3ware 7850 with 8 160G drives (RAID5) with an XFS file system > (1.0TB). It also has a SCSI software raid root volume and a IDE scratch > disk both with ext3. The XFS filesystem is ~40% full with an average file > size of ~4-5G > > The 1TB array is a recent addition to a previously stable system. The RAID > volume seemed fine in my initial burn in and stress testing, but now that I > have live data on the array I've been having stability problems. In the > last <2 months I've had 3 crashes... > > The first crash was a strange OOM type problem after the box had been up > for a few weeks. It started with a series of 'eth0: memory shortage' on a > box that was mostly doing NFS, followed by several 'Unable to handle kernel > NULL pointer dereference at virtual address 00000030' in kswapd, then > klogd, shortly after that it oppsed and wedged. > > In the last two weeks I've had it die twice, both times within a minute of > starting to mv ~800M from an SGI O2 to the linux box via NFS3. The O2 > reported NFS timeout errors, the linux box would respond to pings and some > things that didn't depend on diskio continued to work. dmesg and df would > hang and couldn't be interrupted. In both cases I was forced to reset. > > I'm not sure if the problems I'm seeing have anything to do with XFS, but > my 2 most recent crashes occurred shortly after starting to move data to > the XFS volume on an otherwise idle system. > > Any ideas / debugging tips? > > Many thanks, > Clem From owner-linux-xfs@oss.sgi.com Thu Apr 11 18:13:54 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C1Ds8d016974 for ; Thu, 11 Apr 2002 18:13:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C1DsHL016973 for linux-xfs-outgoing; Thu, 11 Apr 2002 18:13:54 -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 g3C1Dm8d016944 for ; Thu, 11 Apr 2002 18:13:49 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 16vpdf-0001Qu-00; Fri, 12 Apr 2002 03:14:07 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=it.up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 16vpda-0006Mf-00; Fri, 12 Apr 2002 03:14:02 +0200 Message-ID: <3CB634DA.D9D82C1B@it.up.ac.za> Date: Fri, 12 Apr 2002 03:14:02 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Clem Taylor , linux-xfs@oss.sgi.com Subject: Re: 2.4.18-xfs 1TB stability problems. References: <3CB626D1.398F9598@chipwrights.com> <3CB62F20.910749CD@it.up.ac.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *16vpda-0006Mf-00*OvM6F1Denjs* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Paul Schutte wrote: > > In the last two weeks I've had it die twice, both times within a minute of > > starting to mv ~800M from an SGI O2 to the linux box via NFS3. The O2 > > reported NFS timeout errors, the linux box would respond to pings and some > > things that didn't depend on diskio continued to work. dmesg and df would > > hang and couldn't be interrupted. In both cases I was forced to reset. > > I would run xfs_repair on the XFS partition if I were you (Just to be sure) Paul From owner-linux-xfs@oss.sgi.com Thu Apr 11 18:29:49 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C1Tn8d017650 for ; Thu, 11 Apr 2002 18:29:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C1TnBX017649 for linux-xfs-outgoing; Thu, 11 Apr 2002 18:29:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta5-rme.xtra.co.nz (mta5-rme.xtra.co.nz [210.86.15.138]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3C1Tg8d017618 for ; Thu, 11 Apr 2002 18:29:43 -0700 Received: from localhost.localdomain ([210.86.52.110]) by mta5-rme.xtra.co.nz with ESMTP id <20020412013011.FAHC15116.mta5-rme.xtra.co.nz@localhost.localdomain>; Fri, 12 Apr 2002 13:30:11 +1200 Subject: Re: 2.4.18-xfs 1TB stability problems. From: mdew To: Paul Schutte Cc: Clem Taylor , linux-xfs@oss.sgi.com In-Reply-To: <3CB62F20.910749CD@it.up.ac.za> References: <3CB626D1.398F9598@chipwrights.com> <3CB62F20.910749CD@it.up.ac.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 12 Apr 2002 13:30:18 +1200 Message-Id: <1018575019.19251.25.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-12 at 12:49, Paul Schutte wrote: > There are a few issues with the linux kernel (Nothing to do with XFS). > You can look at this URL to see what Andrea Arcangeli has to say. > > http://lwn.net/2002/0411/a/vm-33-reason.php3 > > get a stock 2.4.18 from a kernel mirror (I use ftp.is.co.za). > > ftp://ftp.is.co.za/linux/kernel/pub/linux/kernel/v2.4/linux-2.4.18.tar.gz > > apply > ftp://ftp.is.co.za/linux/kernel/pub/linux/kernel/v2.4/testing/patch-2.4.19-pre6.bz2 > > and then > > ftp://ftp.is.co.za/linux/kernel/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre6aa1.bz2 > > The Andrea Arcangeli kernels has XFS and his latest vm tweaks. > I do not know what version of XFS he uses. > It is worth a try. I found pre6 had broken USB drivers...well for my USB mouse anyway, So im waiting on improvements on pre7 .. but -AA's patches are great, havent had a problem with them. -- ph33r! Linux mdew 2.4.18-xfs #1 Sun Mar 31 15:53:58 NZST 2002 i686 unknown From owner-linux-xfs@oss.sgi.com Fri Apr 12 00:32:16 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C7WG8d029566 for ; Fri, 12 Apr 2002 00:32:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C7WGXr029565 for linux-xfs-outgoing; Fri, 12 Apr 2002 00:32:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.synopex.de (tealc.synopex.de [212.126.196.232]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3C7WB8d029534 for ; Fri, 12 Apr 2002 00:32:12 -0700 Received: from pfeiffer by mail.synopex.de with local (Exim 3.12 #1 (Debian)) id 16vvXs-0006Rk-00 for ; Fri, 12 Apr 2002 09:32:32 +0200 Date: Fri, 12 Apr 2002 09:32:32 +0200 To: linux-xfs@oss.sgi.com Subject: System crash by use xfs Message-ID: <20020412093232.B24739@synopex.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i From: Stephan Pfeiffer Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk dear xfs-users, i used kernel2.4.17-xfs. only one partition on the system is used with xfs. once a process or anything writes to this xfs-partiion my system goes completly down. i have recompile my kernel with gcc2.91.66 how is written here http://oss.sgi.com/projects/xfs/faq.html#hangprocess but it not helps. can anybody help me, please? -- STEPHAN PFEIFFER ICQ: 39844459 (Home) 39064604 (Work) http://www.synopex.de/ mailto:info@synopex.de *** Linux is like a wigwam... *** no windows, no gates and apache inside! From owner-linux-xfs@oss.sgi.com Fri Apr 12 00:46:52 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C7kq8d030126 for ; Fri, 12 Apr 2002 00:46:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C7kqfb030125 for linux-xfs-outgoing; Fri, 12 Apr 2002 00:46: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 g3C7kk8d030097 for ; Fri, 12 Apr 2002 00:46: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 g3C7lKR5082065; Fri, 12 Apr 2002 09:47:20 +0200 (CEST) Message-Id: <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Apr 2002 09:47:37 +0200 To: Stephan Pfeiffer , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: System crash by use xfs In-Reply-To: <20020412093232.B24739@synopex.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:32 12-4-2002 +0200, Stephan Pfeiffer wrote: >dear xfs-users, > >i used kernel2.4.17-xfs. only one partition on the system is used with xfs. >once a process or anything writes to this xfs-partiion my system goes >completly down. i have recompile my kernel with gcc2.91.66 how is written >here http://oss.sgi.com/projects/xfs/faq.html#hangprocess but it not helps. > >can anybody help me, please? What error do you see in the logs (like /var/log/messages) or in dmesg output? Can you cut and paste the output of the error in the mail perhaps? Are you using something like md or lvm on your system? Can you try checking out the latest CVS and see if the problem still exists. Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Apr 12 01:33:12 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C8XC8d001500 for ; Fri, 12 Apr 2002 01:33:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C8XCah001499 for linux-xfs-outgoing; Fri, 12 Apr 2002 01:33:12 -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 g3C8X28d001471 for ; Fri, 12 Apr 2002 01:33:03 -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 g3C8XbXu072434; Fri, 12 Apr 2002 10:33:37 +0200 (CEST) Message-Id: <4.3.2.7.2.20020412101700.02e10008@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Apr 2002 10:33:54 +0200 To: Stephan Pfeiffer From: Seth Mos Subject: Re: System crash by use xfs Cc: Linux XFS List In-Reply-To: <20020412101308.A24994@synopex.de> References: <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <20020412093232.B24739@synopex.de> <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 10:13 12-4-2002 +0200, you wrote: >hi CC'ing the list. >On Fri, Apr 12, 2002 at 09:47:37AM +0200, Seth Mos wrote: > > At 09:32 12-4-2002 +0200, Stephan Pfeiffer wrote: > > >dear xfs-users, > > > > > >i used kernel2.4.17-xfs. only one partition on the system is used with > xfs. > > >once a process or anything writes to this xfs-partiion my system goes > > >completly down. i have recompile my kernel with gcc2.91.66 how is written > > >here http://oss.sgi.com/projects/xfs/faq.html#hangprocess but it not > helps. > > > > > >can anybody help me, please? > > > > What error do you see in the logs (like /var/log/messages) or in dmesg > output? >messages had no info about this. No errors >soo much, sorry! i can't see any problem here. > > > > > Can you cut and paste the output of the error in the mail perhaps? > > Are you using something like md or lvm on your system? >no > > > > > Can you try checking out the latest CVS and see if the problem still > exists. >i am not really a linux-profi and don't know about cvs. i used >suse-linux7.3. help this info? I didn't knew XFS was included in SuSE 7.3, maybe SuSE has a updated kernel with XFS which gives less problems. Since there are no error messages it makes debugging the thing slightly harder. Does anyone from SuSE know if you ever shipped a kernel with XFS support? You can get the instructions here: http://oss.sgi.com/projects/xfs/cvs_download.html Although that does mean you need to compile your own kernel. Are you familiar with compiling your own kernel? Cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Apr 12 01:44:18 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3C8iH8d002005 for ; Fri, 12 Apr 2002 01:44:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3C8iH18002004 for linux-xfs-outgoing; Fri, 12 Apr 2002 01:44:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.synopex.de (tealc.synopex.de [212.126.196.232]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3C8iB8d001974 for ; Fri, 12 Apr 2002 01:44:12 -0700 Received: from pfeiffer by mail.synopex.de with local (Exim 3.12 #1 (Debian)) id 16vwfb-0006cL-00; Fri, 12 Apr 2002 10:44:35 +0200 Date: Fri, 12 Apr 2002 10:44:35 +0200 To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: System crash by use xfs Message-ID: <20020412104435.A25354@synopex.de> References: <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <20020412093232.B24739@synopex.de> <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <20020412101308.A24994@synopex.de> <4.3.2.7.2.20020412101700.02e10008@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.20020412101700.02e10008@pop.xs4all.nl>; from knuffie@xs4all.nl on Fri, Apr 12, 2002 at 10:33:54AM +0200 From: Stephan Pfeiffer Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [..] > I didn't knew XFS was included in SuSE 7.3, maybe SuSE has a updated kernel > with XFS which gives less problems. Since there are no error messages it > makes debugging the thing slightly harder. > > Does anyone from SuSE know if you ever shipped a kernel with XFS support? > > You can get the instructions here: > http://oss.sgi.com/projects/xfs/cvs_download.html > > Although that does mean you need to compile your own kernel. Are you > familiar with compiling your own kernel? yes. i use suse7.3 but i compile my own kernel 2.4.17 with xfs and acl patch. the kernel and the rest of system works :) -- STEPHAN PFEIFFER ICQ: 39844459 (Home) 39064604 (Work) http://www.synopex.de/ mailto:info@synopex.de *** Linux is like a wigwam... *** no windows, no gates and apache inside! From owner-linux-xfs@oss.sgi.com Fri Apr 12 05:24:17 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CCOH8d009619 for ; Fri, 12 Apr 2002 05:24:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CCOHwC009618 for linux-xfs-outgoing; Fri, 12 Apr 2002 05:24:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (IDENT:5lGiVky0aNIqtXR5zEinYOBV2xR4AOYL@firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CCOC8d009588 for ; Fri, 12 Apr 2002 05:24:13 -0700 Received: from conet.cz (CoNetWin [192.168.1.110]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g3CCOlm06893 for ; Fri, 12 Apr 2002 14:24:47 +0200 Message-ID: <3CB6D233.4030404@conet.cz> Date: Fri, 12 Apr 2002 14:25:23 +0200 From: =?ISO-8859-2?Q?Libor_Van=ECk?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: 2 questions Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'd like to ask 2 small yes/no questions about XFS: - does XFS support fs resising? - is there any way how to have physicaly more (Linux) machines which would act like one big XFS (probably all driven by one "master" machine which would handle I/O requests)? (I think it's clear what I would like to do ;-)) Thanks, Libor From owner-linux-xfs@oss.sgi.com Fri Apr 12 06:55:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CDtu8d001360 for ; Fri, 12 Apr 2002 06:55:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CDttqK001359 for linux-xfs-outgoing; Fri, 12 Apr 2002 06:55:55 -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 g3CDtn8d001330 for ; Fri, 12 Apr 2002 06:55:50 -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 g3CDuNlh017540; Fri, 12 Apr 2002 15:56:23 +0200 (CEST) Message-Id: <4.3.2.7.2.20020412155435.038711c8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 12 Apr 2002 15:56:36 +0200 To: =?ISO-8859-2?Q?Libor_Van=ECk?= , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: 2 questions In-Reply-To: <3CB6D233.4030404@conet.cz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 14:25 12-4-2002 +0200, =?ISO-8859-2?Q?Libor_Van=ECk?= wrote: >Hi, >I'd like to ask 2 small yes/no questions about XFS: >- does XFS support fs resising? Only larger, shrinking is not supported. >- is there any way how to have physicaly more (Linux) machines which would >act like one big XFS (probably all driven by one "master" machine which >would handle I/O requests)? There are some other filesystem block layers that can do this but I don't know if any of them actually work with XFS. I see some trivial test reports but I can't remember if any of them was succesful or not. >(I think it's clear what I would like to do ;-)) Yup cheers -- Seth Every program has two purposes one for which it was written and another for which it wasn't I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Apr 12 07:00:27 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CE0R8d001648 for ; Fri, 12 Apr 2002 07:00:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CE0RqV001647 for linux-xfs-outgoing; Fri, 12 Apr 2002 07:00:27 -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 g3CE0L8d001613 for ; Fri, 12 Apr 2002 07:00:22 -0700 Message-Id: <200204121400.g3CE0L8d001613@oss.sgi.com> Received: from there ([144.135.24.81]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw Feb 26 2002 03:44:21) with SMTP id GUGK9F00.316; Sat, 13 Apr 2002 00:00:51 +1000 Received: from CPE-144-137-137-105.qld.bigpond.net.au ([144.137.137.105]) by bwmam05.mailsvc.email.bigpond.com(MailRouter V3.0j 44/403578); 13 Apr 2002 00:00:51 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Libor Van?k , linux-xfs@oss.sgi.com Subject: Re: 2 questions Date: Sat, 13 Apr 2002 00:00:47 +1000 X-Mailer: KMail [version 1.3.1] References: <3CB6D233.4030404@conet.cz> In-Reply-To: <3CB6D233.4030404@conet.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 12 Apr 2002 22:25, Libor Van?k wrote: > Hi, > I'd like to ask 2 small yes/no questions about XFS: > - does XFS support fs resising? Yes XFS supports online fs enlarging - but shrinking has not been immplemented. http://oss.sgi.com/projects/xfs/faq.html#usexfslvm http://oss.sgi.com/projects/xfs/faq.html#resizexfspartition > - is there any way how to have physicaly more (Linux) machines which > would act like one big XFS (probably all driven by one "master" machine > which would handle I/O requests)? I'm unsure what you are after here. SGI AFAIK has a commercial clusterXFS product - I believe much in the same idea as OpenGFS. Maybe some others on the mailing list can give some more information. > > (I think it's clear what I would like to do ;-)) > > Thanks, > Libor -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Fri Apr 12 07:04:44 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CE4i8d001920 for ; Fri, 12 Apr 2002 07:04:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CE4imN001919 for linux-xfs-outgoing; Fri, 12 Apr 2002 07:04:44 -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 g3CE4a8d001886 for ; Fri, 12 Apr 2002 07:04:36 -0700 Received: from lizard.webland.de (www.sinitec.de [194.122.76.165]) by mx.de.kpnqwest.net (Postfix (mx10)) with ESMTP id 445CA6364; Fri, 12 Apr 2002 16:05: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 QAA10917; Fri, 12 Apr 2002 16:05:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5F1D657306; Fri, 12 Apr 2002 16:04:51 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 2460A25835; Fri, 12 Apr 2002 16:04:49 +0200 (CEST) Message-ID: <3CB6E981.8C29617F@ch.sauter-bc.com> Date: Fri, 12 Apr 2002 16:04:49 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Seth Mos Cc: Libor =?iso-8859-1?Q?Van=ECk?= , linux-xfs@oss.sgi.com Subject: Re: 2 questions References: <4.3.2.7.2.20020412155435.038711c8@pop.xs4all.nl> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos schrieb: > > At 14:25 12-4-2002 +0200, =?ISO-8859-2?Q?Libor_Van=ECk?= wrote: > >Hi, > >I'd like to ask 2 small yes/no questions about XFS: > >- does XFS support fs resising? > > Only larger, shrinking is not supported. > > >- is there any way how to have physicaly more (Linux) machines which would > >act like one big XFS (probably all driven by one "master" machine which > >would handle I/O requests)? > > There are some other filesystem block layers that can do this but I don't > know if any of them actually work with XFS. I see some trivial test reports > but I can't remember if any of them was succesful or not. You could use network block devices on several physikal machines and build one big RAID0/1/5 volume with it on the master server. Then put XFS or LVM/XFS on top of it. I tried this once and it worked quite well and fast. If been told you can get better performance than with NFS. -Simon > > >(I think it's clear what I would like to do ;-)) > > Yup > > cheers > > -- > Seth > Every program has two purposes one for which > it was written and another for which it wasn't > I use the last kind. From owner-linux-xfs@oss.sgi.com Fri Apr 12 07:54:51 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CEsp8d004037 for ; Fri, 12 Apr 2002 07:54:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CEspWJ004036 for linux-xfs-outgoing; Fri, 12 Apr 2002 07:54:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hoju-ext.nks.net (hoju-ext.nks.net [216.139.204.180]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CEsX8d003460 for ; Fri, 12 Apr 2002 07:54:40 -0700 Received: from two.nks.net (two.nks.net [192.168.1.22]) by hoju-ext.nks.net (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id KAA13428 for ; Fri, 12 Apr 2002 10:55:00 -0400 Subject: Re: System crash by use xfs From: Derek Glidden To: Linux XFS List In-Reply-To: <4.3.2.7.2.20020412101700.02e10008@pop.xs4all.nl> References: <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <20020412093232.B24739@synopex.de> <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <4.3.2.7.2.20020412101700.02e10008@pop.xs4all.nl> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 12 Apr 2002 10:54:56 -0400 Message-Id: <1018623301.11236.1.camel@two.nks.net> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-12 at 04:33, Seth Mos wrote: > I didn't knew XFS was included in SuSE 7.3, maybe SuSE has a updated kernel > with XFS which gives less problems. Since there are no error messages it > makes debugging the thing slightly harder. > > Does anyone from SuSE know if you ever shipped a kernel with XFS support? A couple months ago at an expo I was told by a SuSE rep that 7.3 would specifically not have XFS because they didn't feel at the time it was ready. I was told it was going to include ReiserFS as usual, and add Ext3 and JFS. It'd probably be nice to hear from an actual SuSE person though. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- #!/usr/bin/perl -w $_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map {$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110; $t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z) [$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join "",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d= unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d >>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q* 8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]} print+x"C*",@a}';s/x/pack+/g;eval usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \ | extract_mpeg2 | mpeg2dec - http://www.cs.cmu.edu/~dst/DeCSS/Gallery/ http://www.eff.org/ http://www.anti-dmca.org/ From owner-linux-xfs@oss.sgi.com Fri Apr 12 08:51:26 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CFpQ8d006801 for ; Fri, 12 Apr 2002 08:51:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CFpPY4006800 for linux-xfs-outgoing; Fri, 12 Apr 2002 08:51:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from picklock.adams.family (dialin-145-254-148-025.arcor-ip.net [145.254.148.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CFpG8d006768 for ; Fri, 12 Apr 2002 08:51:17 -0700 Received: from loewe-komp.de (localhost [127.0.0.1]) by picklock.adams.family (8.11.6/8.11.6/SuSE Linux 0.5) with ESMTP id g3CFjXt03750; Fri, 12 Apr 2002 17:45:33 +0200 Message-ID: <3CB7011D.C43C0D87@loewe-komp.de> Date: Fri, 12 Apr 2002 17:45:33 +0200 From: Peter =?iso-8859-1?Q?W=E4chtler?= Organization: B16 X-Mailer: Mozilla 4.76 [de] (X11; U; Linux 2.4.17-xfs i686) X-Accept-Language: de, en MIME-Version: 1.0 To: Derek Glidden CC: Linux XFS List Subject: Re: System crash by use xfs References: <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <1018623301.11236.1.camel@two.nks.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Derek Glidden wrote: > > On Fri, 2002-04-12 at 04:33, Seth Mos wrote: > > > I didn't knew XFS was included in SuSE 7.3, maybe SuSE has a updated kernel > > with XFS which gives less problems. Since there are no error messages it > > makes debugging the thing slightly harder. > > > > Does anyone from SuSE know if you ever shipped a kernel with XFS support? > > A couple months ago at an expo I was told by a SuSE rep that 7.3 would > specifically not have XFS because they didn't feel at the time it was > ready. I was told it was going to include ReiserFS as usual, and add > Ext3 and JFS. > > It'd probably be nice to hear from an actual SuSE person though. > I am only a SuSE beta-tester. There never was xfs support in the kernel of 7.3 - just the userspace utilities were shipped. Since Andi Kleen is posting here - perhaps in 8.0? But there was no support in the betas I have checked. And: after some obscure bugs (NFS related) our fileserver box has an uptime +70 days again - so XFS is doing again fine for me. Never had trouble with data - online growing filesystem is a nice to have... From owner-linux-xfs@oss.sgi.com Fri Apr 12 08:51:45 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CFpj8d006847 for ; Fri, 12 Apr 2002 08:51:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CFpjS9006846 for linux-xfs-outgoing; Fri, 12 Apr 2002 08:51:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailnet.consensys.com ([209.47.40.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CFpf8d006811 for ; Fri, 12 Apr 2002 08:51:41 -0700 Received: from Francis ([209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g3CAibx25799 for ; Fri, 12 Apr 2002 10:44:37 GMT Message-ID: <001001c1e23a$0a5dbb20$8d02a8c0@consensys.com> From: "Francis Qu" To: "Linux XFS" Subject: dm_handle_to_path causes system crash Date: Fri, 12 Apr 2002 11:52:24 -0400 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 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Linux-2.4.18-xfs dmapi: 2.0.1 dm_handle_to_path -> getcwd --> sys_cwd --> __d_path ---> crash Thanks, Francis [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Apr 12 09:01:53 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CG1r8d007428 for ; Fri, 12 Apr 2002 09:01:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CG1r4p007427 for linux-xfs-outgoing; Fri, 12 Apr 2002 09:01:53 -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 g3CG1n8d007396 for ; Fri, 12 Apr 2002 09:01:49 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 8DA611E5A9; Fri, 12 Apr 2002 18:02:17 +0200 (MEST) Date: Fri, 12 Apr 2002 18:02:17 +0200 From: Andi Kleen To: Peter W?chtler Cc: Derek Glidden , Linux XFS List Subject: Re: System crash by use xfs Message-ID: <20020412180217.A25467@wotan.suse.de> References: <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <1018623301.11236.1.camel@two.nks.net> <3CB7011D.C43C0D87@loewe-komp.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB7011D.C43C0D87@loewe-komp.de> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Apr 12, 2002 at 05:45:33PM +0200, Peter W?chtler wrote: > I am only a SuSE beta-tester. There never was xfs support in > the kernel of 7.3 - just the userspace utilities were shipped. Shipping (outdated) xfs user space utilities in 7.3 was a bug, they weren't supposed to be on the CD. They were only used for internal testing. > > Since Andi Kleen is posting here - perhaps in 8.0? But there was > no support in the betas I have checked. SuSE 8.0 has full XFS support. -Andi From owner-linux-xfs@oss.sgi.com Fri Apr 12 09:05:37 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CG5a8d008334 for ; Fri, 12 Apr 2002 09:05:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CG5aek008333 for linux-xfs-outgoing; Fri, 12 Apr 2002 09:05:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CG5Q8d008305 for ; Fri, 12 Apr 2002 09:05:26 -0700 Received: from atlrel9.hp.com (atlrel9.hp.com [156.153.255.214]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3CG62QR066834 for ; Fri, 12 Apr 2002 11:06:03 -0500 (CDT) Received: from xatlrelay1.atl.hp.com (xatlrelay1.atl.hp.com [15.45.89.190]) by atlrel9.hp.com (Postfix) with ESMTP id EA09D80552B; Fri, 12 Apr 2002 12:05:46 -0400 (EDT) Received: from xatlbh4.atl.hp.com (xatlbh4.atl.hp.com [15.45.89.189]) by xatlrelay1.atl.hp.com (Postfix) with ESMTP id B990F114; Fri, 12 Apr 2002 12:05:46 -0400 (EDT) Received: by xatlbh4.atl.hp.com with Internet Mail Service (5.5.2653.19) id <2V447Z5Q>; Fri, 12 Apr 2002 12:05:46 -0400 Message-ID: From: "HABBINGA,ERIK (HP-Loveland,ex1)" To: "'linux-xfs@oss.sgi.com'" , "'linux-xfs@thebarn.com'" Subject: FW: oops in xfs_iget related to bhv_lookup Date: Fri, 12 Apr 2002 12:05:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk NOTE: this might be a repost. I didn't see it hit the XFS mailing list in the 18 hours since I sent it yesterday... We're seeing an oops in xfs_iget due to bhv_lookup returning NULL: Apr 11 09:43:46 olie kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000152 Apr 11 09:43:46 olie kernel: printing eip: Apr 11 09:43:46 olie kernel: c01b8842 Apr 11 09:43:46 olie kernel: *pde = 3682f001 Apr 11 09:43:46 olie kernel: *pte = 00000000 Apr 11 09:43:46 olie kernel: Oops: 0000 Apr 11 09:43:46 olie kernel: CPU: 0 Apr 11 09:43:46 olie kernel: EIP: 0010:[xfs_iget+254/328] Not tainted Apr 11 09:43:46 olie kernel: EFLAGS: 00010246 Apr 11 09:43:46 olie kernel: eax: 00000000 ebx: ffffffe8 ecx: c032b2cc edx: c032e940 Apr 11 09:43:46 olie kernel: esi: f6299284 edi: f5f65400 ebp: 00000000 esp: f3531dec Apr 11 09:43:46 olie kernel: ds: 0018 es: 0018 ss: 0018 Apr 11 09:43:46 olie kernel: Process nfsd (pid: 18020, stackpage=f3531000) Apr 11 09:43:46 olie kernel: Stack: 00000000 f6368d4c 00000000 00000008 c01cd98c f5f65400 00000000 00400080 Apr 11 09:43:46 olie kernel: 00000000 00000000 f3531e7c 00000000 00000000 f6368d64 f6368d4c 00000008 Apr 11 09:43:46 olie kernel: f69818e0 00000000 00000007 00000288 00000008 c01d1f87 00000000 f6368d64 Apr 11 09:43:46 olie kernel: Call Trace: [xfs_dir_lookup_int+292/656] [xfs_lookup+143/252] [linvfs_lookup+101/184] [lookup_hash+173/252] [lookup_one_len+87/104] Apr 11 09:43:46 olie kernel: [nfsd_lookup+717/1016] [nfsd3_proc_lookup+212/224] [nfsd_dispatch+207/412] [svc_process+653/1240] [nfsd+589/984] [kernel_thread+40/56] Apr 11 09:43:46 olie kernel: Apr 11 09:43:46 olie kernel: Code: 66 83 bb 6a 01 00 00 00 75 10 80 a3 50 01 00 00 f7 53 e8 77 ...and here's the code from xfs_iget: bdp = vn_bhv_lookup(VN_BHV_HEAD(vp), &xfs_vnodeops); ip = XFS_BHVTOI(bdp); if (lock_flags != 0) { xfs_ilock(ip, lock_flags); } newnode = (ip->i_d.di_mode == 0); vn_bhv_lookup is allowed to return NULL, which it does this in this case: 0xc01b8825 : lea 0x14(%esi),%eax 0xc01b8828 : push %eax 0xc01b8829 : call 0xc01dc208 0xc01b882e : lea 0xffffffe8(%eax),%ebx 0xc01b8831 : add $0x8,%esp 0xc01b8834 : test %ebp,%ebp 0xc01b8836 : je 0xc01b8842 0xc01b8838 : push %ebp 0xc01b8839 : push %ebx 0xc01b883a : call 0xc01b8cf0 0xc01b883f : add $0x8,%esp 0xc01b8842 : cmpw $0x0,0x16a(%ebx) EAX has the return value of bhv_lookup at xfs_iget+234. EBX is set to 0xffffffe8 at xfs_iget+254, which is what it was set to because EAX = 0 at xfs_iget+234. Other code within XFS tests the return value of bhv_lookup for NULL and does appropriate error handling. Should xfs_iget also be testing this value for NULL? Other functions that might be ignoring the bhv_lookup error code include xfs_dm_mount, xfs_get_inode, xfs_unmount, and xfs_create. The current test case that reproduces this oops is rather involved, and we're trying to narrow it down as much as possible. Erik From owner-linux-xfs@oss.sgi.com Fri Apr 12 09:34:41 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CGYf8d010064 for ; Fri, 12 Apr 2002 09:34:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CGYfcM010063 for linux-xfs-outgoing; Fri, 12 Apr 2002 09:34:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (IDENT:I3YWxd+RxHj7B1C0VRHMUUWceSoA7wwm@firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CGYY8d010027 for ; Fri, 12 Apr 2002 09:34:35 -0700 Received: from conet.cz (CoNetWin [192.168.1.110]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g3CGZ9m12848; Fri, 12 Apr 2002 18:35:09 +0200 Message-ID: <3CB70CD1.3000103@conet.cz> Date: Fri, 12 Apr 2002 18:35:29 +0200 From: =?ISO-8859-2?Q?Libor_Van=ECk?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Simon Matter CC: linux-xfs@oss.sgi.com Subject: Re: 2 questions References: <4.3.2.7.2.20020412155435.038711c8@pop.xs4all.nl> <3CB6E981.8C29617F@ch.sauter-bc.com> Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > >>>- is there any way how to have physicaly more (Linux) machines which would >>>act like one big XFS (probably all driven by one "master" machine which >>>would handle I/O requests)? >>> >>There are some other filesystem block layers that can do this but I don't >>know if any of them actually work with XFS. I see some trivial test reports >>but I can't remember if any of them was succesful or not. >> > >You could use network block devices on several physikal machines and >build one big RAID0/1/5 volume with it on the master server. Then put >XFS or LVM/XFS on top of it. I tried this once and it worked quite well >and fast. If been told you can get better performance than with NFS. > Please - can you send me some more information about network block devices? I absolutely doesn't know what it is and how to use it ;) Thanks, Libor [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Apr 12 09:56:44 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CGui8d011724 for ; Fri, 12 Apr 2002 09:56:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CGuiTk011723 for linux-xfs-outgoing; Fri, 12 Apr 2002 09:56:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta03bw.bigpond.com (mta03bw.bigpond.com [139.134.6.86]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CGud8d011662 for ; Fri, 12 Apr 2002 09:56:40 -0700 Message-Id: <200204121656.g3CGud8d011662@oss.sgi.com> Received: from there ([144.135.24.78]) by mta03bw.bigpond.com (Netscape Messaging Server 4.15 mta03bw Feb 26 2002 03:44:21) with SMTP id GUGSF900.EL4; Sat, 13 Apr 2002 02:57:09 +1000 Received: from CPE-144-137-137-105.qld.bigpond.net.au ([144.137.137.105]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0j 35/383464); 13 Apr 2002 02:57:09 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Libor Van?k , Simon Matter Subject: Re: 2 questions Date: Sat, 13 Apr 2002 02:57:04 +1000 X-Mailer: KMail [version 1.3.1] Cc: linux-xfs@oss.sgi.com References: <4.3.2.7.2.20020412155435.038711c8@pop.xs4all.nl> <3CB6E981.8C29617F@ch.sauter-bc.com> <3CB70CD1.3000103@conet.cz> In-Reply-To: <3CB70CD1.3000103@conet.cz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 13 Apr 2002 02:35, Libor Van?k wrote: > > Please - can you send me some more information about network block > devices? I absolutely doesn't know what it is and how to use it ;) Network block devices are a way to mount a raw disk volume across a network. Think of it as RAID1 but over a network. They are very useful as a HA solution. There are a couple of them for Linux - the standard kernel has shipped with NBD for a long time. (I've never used NBD though). Probabily the best thing is to point you towards the DRBD pages: http://www.complang.tuwien.ac.at/reisner/drbd/ -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Fri Apr 12 10:37:32 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CHbW8d014658 for ; Fri, 12 Apr 2002 10:37:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CHbVem014657 for linux-xfs-outgoing; Fri, 12 Apr 2002 10:37: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 g3CHbQ8d014613 for ; Fri, 12 Apr 2002 10:37:26 -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 g3CHY63u010568 for ; Fri, 12 Apr 2002 13:34:07 -0400 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id g3CHc2e26991 for linux-xfs@oss.sgi.com; Fri, 12 Apr 2002 13:38:02 -0400 (EDT) Date: Fri, 12 Apr 2002 13:38:02 -0400 From: Thor Lancelot Simon To: linux-xfs@oss.sgi.com Subject: XFS installer and driver/update disks Message-ID: <20020412133802.A26968@pla-muek.reefedge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a new system with an Adaptec I2O RAID controller. I'd really like to use XFS on this system, but I'm having a terrible time getting it installed. The RedHat 7.2 distribution doesn't ship with the Adaptec/DPT I2O driver. Adaptec has a driver disk, but of course the kernel versions differ between standard RedHat 7.2 and SGI 7.2+XFS, so the driver doesn't match what anaconda looks for and doesn't work if loaded by hand (doesn't load, actually; missing symbols). I tried downloading the Adaptec driver sources and the XFS-patched RedHat kernel sources but building a driver disk that actually works appears to be beyond my abilities; adaptec's driver sources are distributed as a patch against 2.4.6, so I have no idea how the 2.7-10 redhat kernel modules were built. Later kernel versions have the dpti driver included in the Linus sources, but not what RedHat uses on their install disks. There's also an "updates" disk distributed with the RedHat 7.2 driver disk; it includes a new "packages.py" but with no real knowledge of Python I can't really see the difference, nor tell if it will work right with the SGI anaconda. What's the right thing to do here? If anyone cares to look at the RedHat/Adaptec solution for stock RedHat 7.2, it's at http://people.redhat.com/tcallawa/dpt/; driver source tarball is down at the bottom of the page. I tried a stock RedHat install but ext3 leaves much to be desired. I really want XFS on this box, but how? Thor From owner-linux-xfs@oss.sgi.com Fri Apr 12 11:26:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CIQc8d018633 for ; Fri, 12 Apr 2002 11:26:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CIQcWo018632 for linux-xfs-outgoing; Fri, 12 Apr 2002 11:26:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.starkmedia.com (mail.starkmedia.com [63.237.54.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CIQU8d018591 for ; Fri, 12 Apr 2002 11:26:30 -0700 Received: from members.evolt.org (gateway3.starkmedia.com [63.237.54.129] (may be forged)) by mail.starkmedia.com (8.10.1/8.10.1) with ESMTP id g3CIRFl30539; Fri, 12 Apr 2002 13:27:15 -0500 Message-ID: <3CB726ED.1010809@members.evolt.org> Date: Fri, 12 Apr 2002 13:26:53 -0500 From: "Daniel J. Cody" User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020403 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thor Lancelot Simon CC: linux-xfs@oss.sgi.com Subject: Re: XFS installer and driver/update disks References: <20020412133802.A26968@pla-muek.reefedge.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Thor - I had almost the exact same issue last year. I wrote up the expierence on my weblog, and maybe that will help you out: http://members.evolt.org/djc/stdio/index.cfm/daddy/show/mommy/94 another trick I pulled was to install RH to an IDE disk, download the latest kernel/patches/driver, recompile, and then you'll be able to use the controller and XFS. I found the 2.4.14 kernel to work really nice with both the card and XFS, so nice, its been up since then. Good luck, feel free to shoot me a line if you need someone to bounce ideas off :) .djc. Thor Lancelot Simon wrote: > I have a new system with an Adaptec I2O RAID controller. I'd > really like to use XFS on this system, but I'm having a terrible > time getting it installed. > > The RedHat 7.2 distribution doesn't ship with the Adaptec/DPT I2O > driver. Adaptec has a driver disk, but of course the kernel versions > differ between standard RedHat 7.2 and SGI 7.2+XFS, so the driver > doesn't match what anaconda looks for and doesn't work if loaded by > hand (doesn't load, actually; missing symbols). I tried downloading > the Adaptec driver sources and the XFS-patched RedHat kernel sources > but building a driver disk that actually works appears to be beyond > my abilities; adaptec's driver sources are distributed as a patch > against 2.4.6, so I have no idea how the 2.7-10 redhat kernel modules > were built. Later kernel versions have the dpti driver included in > the Linus sources, but not what RedHat uses on their install disks. > > There's also an "updates" disk distributed with the RedHat 7.2 driver > disk; it includes a new "packages.py" but with no real knowledge of > Python I can't really see the difference, nor tell if it will work right > with the SGI anaconda. > > What's the right thing to do here? If anyone cares to look at the > RedHat/Adaptec solution for stock RedHat 7.2, it's at > http://people.redhat.com/tcallawa/dpt/; driver source tarball is down > at the bottom of the page. > > I tried a stock RedHat install but ext3 leaves much to be desired. I > really want XFS on this box, but how? > > Thor From owner-linux-xfs@oss.sgi.com Fri Apr 12 11:47:48 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CIlm8d019981 for ; Fri, 12 Apr 2002 11:47:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CIlmHl019980 for linux-xfs-outgoing; Fri, 12 Apr 2002 11:47:48 -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 g3CIlf8d019946 for ; Fri, 12 Apr 2002 11:47:42 -0700 Received: from lizard.webland.de (www.sinitec.de [194.122.76.165]) by mx.de.kpnqwest.net (Postfix (mx13)) with ESMTP id CD75FC45D; Fri, 12 Apr 2002 20:48:12 +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 UAA00626; Fri, 12 Apr 2002 20:48:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 33B3457306; Fri, 12 Apr 2002 20:47:48 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id D5EBD25835; Fri, 12 Apr 2002 20:47:46 +0200 (CEST) Message-ID: <3CB72BD2.DAA3FF86@ch.sauter-bc.com> Date: Fri, 12 Apr 2002 20:47:46 +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: Andi Kleen Cc: Peter W?chtler , Derek Glidden , Linux XFS List Subject: Re: System crash by use xfs References: <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <1018623301.11236.1.camel@two.nks.net> <3CB7011D.C43C0D87@loewe-komp.de> <20020412180217.A25467@wotan.suse.de> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Andi Kleen schrieb: > > On Fri, Apr 12, 2002 at 05:45:33PM +0200, Peter W?chtler wrote: > > I am only a SuSE beta-tester. There never was xfs support in > > the kernel of 7.3 - just the userspace utilities were shipped. > > Shipping (outdated) xfs user space utilities in 7.3 was a bug, they weren't > supposed to be on the CD. They were only used for internal testing. > > > > > Since Andi Kleen is posting here - perhaps in 8.0? But there was > > no support in the betas I have checked. > > SuSE 8.0 has full XFS support. Interesting. Some time ago I found this link http://www.urz.uni-heidelberg.de/Linux/suse80-ank.shtml and this http://www.linuxshop.nu/ The mailing which I received today from SuSE says 8.0 contains 3 journaling filesystems: ReiserFS, JFS and Ext3. > > -Andi From owner-linux-xfs@oss.sgi.com Fri Apr 12 11:52:02 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CIq28d020405 for ; Fri, 12 Apr 2002 11:52:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CIq2VU020404 for linux-xfs-outgoing; Fri, 12 Apr 2002 11:52:02 -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 g3CIpw8d020369 for ; Fri, 12 Apr 2002 11:51:59 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 423B51E666; Fri, 12 Apr 2002 20:52:31 +0200 (MEST) Date: Fri, 12 Apr 2002 20:52:30 +0200 From: Andi Kleen To: Simon Matter Cc: Andi Kleen , Peter W?chtler , Derek Glidden , Linux XFS List Subject: Re: System crash by use xfs Message-ID: <20020412205230.A31768@wotan.suse.de> References: <4.3.2.7.2.20020412094508.02ca3920@pop.xs4all.nl> <1018623301.11236.1.camel@two.nks.net> <3CB7011D.C43C0D87@loewe-komp.de> <20020412180217.A25467@wotan.suse.de> <3CB72BD2.DAA3FF86@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CB72BD2.DAA3FF86@ch.sauter-bc.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Interesting. Some time ago I found this link > http://www.urz.uni-heidelberg.de/Linux/suse80-ank.shtml and this > http://www.linuxshop.nu/ > The mailing which I received today from SuSE says 8.0 contains 3 > journaling filesystems: ReiserFS, JFS and Ext3. XFS is included too. It is the famoue SuSE stealth marketing (always more features than advertised). It is noted in the full release notes. -Andi From owner-linux-xfs@oss.sgi.com Fri Apr 12 12:24:49 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CJOn8d022051 for ; Fri, 12 Apr 2002 12:24:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CJOnPG022050 for linux-xfs-outgoing; Fri, 12 Apr 2002 12:24:49 -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 g3CJOU8d022010 for ; Fri, 12 Apr 2002 12:24:31 -0700 Received: from lizard.webland.de (www.sinitec.de [194.122.76.165]) by mx.de.kpnqwest.net (Postfix (mx14)) with ESMTP id 5CAFAC226; Fri, 12 Apr 2002 20:54: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 UAA01051; Fri, 12 Apr 2002 20:54:05 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 6B6D757306; Fri, 12 Apr 2002 20:53:07 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 0E73625835; Fri, 12 Apr 2002 20:53:06 +0200 (CEST) Message-ID: <3CB72D12.11BF637D@ch.sauter-bc.com> Date: Fri, 12 Apr 2002 20:53:06 +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: Thor Lancelot Simon Cc: linux-xfs@oss.sgi.com Subject: Re: XFS installer and driver/update disks References: <20020412133802.A26968@pla-muek.reefedge.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thor Lancelot Simon schrieb: > > I have a new system with an Adaptec I2O RAID controller. I'd > really like to use XFS on this system, but I'm having a terrible > time getting it installed. > > The RedHat 7.2 distribution doesn't ship with the Adaptec/DPT I2O > driver. Adaptec has a driver disk, but of course the kernel versions > differ between standard RedHat 7.2 and SGI 7.2+XFS, so the driver > doesn't match what anaconda looks for and doesn't work if loaded by > hand (doesn't load, actually; missing symbols). I tried downloading > the Adaptec driver sources and the XFS-patched RedHat kernel sources > but building a driver disk that actually works appears to be beyond > my abilities; adaptec's driver sources are distributed as a patch > against 2.4.6, so I have no idea how the 2.7-10 redhat kernel modules > were built. Later kernel versions have the dpti driver included in > the Linus sources, but not what RedHat uses on their install disks. > > There's also an "updates" disk distributed with the RedHat 7.2 driver > disk; it includes a new "packages.py" but with no real knowledge of > Python I can't really see the difference, nor tell if it will work right > with the SGI anaconda. You have exactly the same problem I had with two Servers. I solved it by installing Linux Mandrake. The real problem is that RedHat does not include XFS in their kernel. They ship it with 1001 patches applied but no XFS. It's a real pain. I have then tried Skipjack-beta1 in the hope, they included XFS. Nothing. I decided to call this a bug and posted it on bugzilla. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62072 I'm asking list members not to flame on bugzilla. I guess it won't help. -Simon > > What's the right thing to do here? If anyone cares to look at the > RedHat/Adaptec solution for stock RedHat 7.2, it's at > http://people.redhat.com/tcallawa/dpt/; driver source tarball is down > at the bottom of the page. > > I tried a stock RedHat install but ext3 leaves much to be desired. I > really want XFS on this box, but how? > > Thor From owner-linux-xfs@oss.sgi.com Fri Apr 12 14:45:35 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CLjZ8d026258 for ; Fri, 12 Apr 2002 14:45:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CLjZHP026257 for linux-xfs-outgoing; Fri, 12 Apr 2002 14:45:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailhub-1.iastate.edu (mailhub-1.iastate.edu [129.186.140.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CLj38d026205 for ; Fri, 12 Apr 2002 14:45:04 -0700 Received: from mailout-1.iastate.edu (mailout-1.iastate.edu [129.186.140.1]) by mailhub-1.iastate.edu (8.9.3/8.9.3) with SMTP id QAA09510; Fri, 12 Apr 2002 16:45:38 -0500 Received: from akrherz.agron.iastate.edu(129.186.26.51) by mailout-1.iastate.edu via csmap id 1104; Fri, 12 Apr 2002 16:45:22 -0500 (CDT) Date: Fri, 12 Apr 2002 16:45:40 -0500 (CDT) From: Daryl Herzmann X-X-Sender: akrherz@akrherz.agron.iastate.edu To: Simon Matter cc: linux-xfs@oss.sgi.com Subject: Re: Oops 2.4.18 + RAID5, now 2.4.9-31SGI_XFS_1.1_PR4 In-Reply-To: <3CB4820F.721107D7@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Thanks to those that responded to my orginal email. I installed the 2.4.9-31SGI_XFS_1.1_PR4 RPM as suggested below and my machine just locked and I had to hard reset it. Again, it was under heavy NFS load. It was also suggested to me to get a 3ware controller, so I may try that. I would be more inclined to move the data off and then reformat ext3 once and see what happens. This all makes me very nervous, since I now have a TB fileserver in RAID 5 running XFS that has been stable thus far, but it has not been subjected to NFS load (it will be soon) :( I would send along a ksymopps, but nothing was sent to syslog. I did have a oops on the screen, but I could not scroll up or anything to get it all. My 2.4.18 crashes did not kill the system as bad as this one did. Daryl On Wed, 10 Apr 2002, Simon Matter wrote: >I've been running a similar server for almost a year now. >It's RH 7.1 + XFS, Promise Ultra100TX2 with 4 Quantum 15G drives, >software RAID5. I have a second server, RH 7.2 + XFS, Promise >Ultra100TX2 with 4 IBM 60G drives, software RAID5. > >No problems so far, only 3 of 8 IBM drives dead, but that's another >story. >Can you try a current RH based kernel with XFS? At least for me it has >always worked very well. > >ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1/kernel_rpms/2.4.9-31-RH/ > >This is from the small server: > >[root@xxl pub]# cat /proc/ide/pdc202xx > > PDC20268 TX2 Chipset. >------------------------------- General Status >--------------------------------- >Burst Mode : enabled >Host Mode : Tri-Stated >Bus Clocking : 100 External >IO pad select : 10 mA >Status Polling Period : 15 >Interrupt Check Status Polling Delay : 15 >--------------- Primary Channel ---------------- Secondary Channel >------------- > enabled enabled >66 Clocking enabled enabled > Mode MASTER Mode MASTER >--------------- drive0 --------- drive1 -------- drive0 ---------- >drive1 ------ >DMA enabled: yes yes yes yes >--------------- Cannot Decode HOST --------------- > >[root@xxl pub]# lspci >00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev >04) >00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo >MVP3/Pro133x AGP] >00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA >[Apollo VP] (rev 47) >00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) >00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) >00:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] >(rev 64) >00:09.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] >(rev 08) >00:0a.0 Unknown mass storage controller: Promise Technology, Inc.: >Unknown device 4d68 (rev 01) >00:0b.0 SCSI storage controller: Adaptec AIC-7881U >01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 03) > >[root@xxl pub]# cat /proc/mdstat >Personalities : [raid1] [raid5] >read_ahead 1024 sectors >md8 : active raid5 hde10[0] hdf7[2] hdg10[1] hdh7[3] > 31406976 blocks level 5, 128k chunk, algorithm 0 [4/4] [UUUU] > >md7 : active raid1 hdf6[0] hdh6[1] > 1024000 blocks [2/2] [UU] > >md5 : active raid1 hdf5[0] hdh5[1] > 3072256 blocks [2/2] [UU] > >md0 : active raid1 hde1[0] hdf1[1] hdg1[2] hdh1[3] > 102720 blocks [4/4] [UUUU] > >md6 : active raid1 hde9[0] hdg9[1] > 1024000 blocks [2/2] [UU] > >md4 : active raid1 hde8[0] hdg8[1] > 511936 blocks [2/2] [UU] > >md3 : active raid1 hde7[0] hdg7[1] > 511936 blocks [2/2] [UU] > >md2 : active raid1 hde6[0] hdg6[1] > 1755328 blocks [2/2] [UU] > >md1 : active raid1 hde5[0] hdg5[1] > 292672 blocks [2/2] [UU] > >unused devices: > > > >Daryl Herzmann schrieb: >> >> Hi, >> I have a box that had been running RH 7.1 + XFS for a year without >> a single problem. Recently, I put 3 120G Maxtor 4G120J6 drives on the >> onboard Promise Controller (pdc202xx) and did software RAID 5. And wow, >> have the problems started! I went from running a 2.4.3 something kernel >> to a custom compiled 2.4.18 w/ SGI patch dated March 3. Still no luck. >> It seems under heavy NFS load, that these problems will start occuring. >> >> Any thoughts? I have been trying to follow the ongoing NFS + >> XFS + RAID 5 discussions, but I am not sure where I should be at >> regarding kernel + patches. >> >> My ksymoops is below. >> >> Thanks! Daryl >> >> Other info that may be helpful. >> >> # lspci >> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev >> 03) >> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] >> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] >> (rev 40) >> 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) >> 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] >> (rev 40) >> 00:08.0 VGA compatible controller: Trident Microsystems Blade 3D PCI/AGP >> (rev 3a) >> 00:0c.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] >> (rev 30) >> 00:0f.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02) >> >> # free >> total used free shared buffers cached >> Mem: 900644 897436 3208 0 0 842932 >> -/+ buffers/cache: 54504 846140 >> Swap: 1028152 0 1028152 >> >> # cat /proc/ide/pdc202xx >> >> PDC20265 Chipset. >> ------------------------------- General Status >> --------------------------------- >> Burst Mode : enabled >> Host Mode : Normal >> Bus Clocking : 33 PCI Internal >> IO pad select : 10 mA >> Status Polling Period : 0 >> Interrupt Check Status Polling Delay : 2 >> --------------- Primary Channel ---------------- Secondary Channel >> ------------- >> enabled enabled >> 66 Clocking enabled enabled >> Mode MASTER Mode MASTER >> FIFO Empty ???????????? >> --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 >> ------ >> DMA enabled: no yes yes yes >> DMA Mode: NOTSET UDMA 4 UDMA 4 UDMA 4 >> PIO Mode: NOTSET PIO ? PIO ? PIO ? >> >> Here is my ksymoops from this morning's crash. >> >> >>EIP; c013f736 <===== >> Trace; c013d70c >> Trace; c0126e78 >> Trace; c013da00 >> Trace; c0127037 >> Trace; c012708c >> Trace; c0127141 >> Trace; c01271b6 >> Trace; c0127311 >> Trace; c0127270 >> Trace; c0105000 >> Trace; c0105536 >> Trace; c0127270 >> Code; c013f736 >> 00000000 <_EIP>: >> Code; c013f736 <===== >> 0: 8b 46 20 mov 0x20(%esi),%eax <===== >> Code; c013f739 >> 3: 85 c0 test %eax,%eax >> Code; c013f73b >> 5: 0f 45 f8 cmovne %eax,%edi >> Code; c013f73e >> 8: 85 ff test %edi,%edi >> Code; c013f740 >> a: 74 0b je 17 <_EIP+0x17> c013f74d >> >> Code; c013f742 >> c: 8b 47 10 mov 0x10(%edi),%eax >> Code; c013f745 >> f: 85 c0 test %eax,%eax >> Code; c013f747 >> 11: 74 04 je 17 <_EIP+0x17> c013f74d >> >> Code; c013f749 >> 13: 53 push %ebx >> >> and then the next immediate oops >> >> >>EIP; c013f736 <===== >> Trace; c013d70c >> Trace; c0126e78 >> Trace; c013da00 >> Trace; c0127037 >> Trace; c012708c >> Trace; c0127951 <_alloc_pages+71/1c0> >> Trace; c0127bbb <__alloc_pages+11b/180> >> Trace; c0127c30 <__get_free_pages+10/20> >> Trace; c0139d73 <__pollwait+33/1040> >> Trace; c025137e >> Trace; c023abdf >> Trace; c0139fcb <__pollwait+28b/1040> >> Trace; c013a43c <__pollwait+6fc/1040> >> Trace; c0106cfb <__up_wakeup+110f/23e4> >> Code; c013f736 >> 00000000 <_EIP>: >> Code; c013f736 <===== >> 0: 8b 46 20 mov 0x20(%esi),%eax <===== >> Code; c013f739 >> 3: 85 c0 test %eax,%eax >> Code; c013f73b >> 5: 0f 45 f8 cmovne %eax,%edi >> Code; c013f73e >> 8: 85 ff test %edi,%edi >> Code; c013f740 >> a: 74 0b je 17 <_EIP+0x17> c013f74d >> >> Code; c013f742 >> c: 8b 47 10 mov 0x10(%edi),%eax >> Code; c013f745 >> f: 85 c0 test %eax,%eax >> Code; c013f747 >> 11: 74 04 je 17 <_EIP+0x17> c013f74d >> >> Code; c013f749 >> 13: 53 push %ebx >> >> -- >> /** >> * Daryl Herzmann (akrherz@iastate.edu) >> * Program Assistant -- Iowa Environmental Mesonet >> * http://mesonet.agron.iastate.edu >> */ > > > -- /** * Daryl Herzmann (akrherz@iastate.edu) * Program Assistant -- Iowa Environmental Mesonet * http://mesonet.agron.iastate.edu */ From owner-linux-xfs@oss.sgi.com Fri Apr 12 14:52:01 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3CLq18d026683 for ; Fri, 12 Apr 2002 14:52:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3CLq1S9026682 for linux-xfs-outgoing; Fri, 12 Apr 2002 14:52:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from thor.hol.gr (thor.hol.gr [194.30.192.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3CLpu8d026651 for ; Fri, 12 Apr 2002 14:51:57 -0700 Message-Id: <200204122151.g3CLpu8d026651@oss.sgi.com> Received: (qmail 10028 invoked from network); 12 Apr 2002 21:50:16 -0000 Received: from mercury.hol.gr (194.30.192.30) by thor.hol.gr with SMTP; 12 Apr 2002 21:50:16 -0000 Received: (qmail 5536 invoked from network); 12 Apr 2002 21:51:02 -0000 Received: from unknown (HELO healthy.gr) (195.97.0.145) by mercury.hol.gr with SMTP; 12 Apr 2002 21:51:02 -0000 From: "owners@healthy.gr" To: Subject: Property owners looking for investors or buyers Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Date: Sat, 13 Apr 2002 00:52:52 +0300 Reply-To: "owners@healthy.gr" Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is not a spam. We are not real estate agents. We are owners of some properties and wish to find investors and buyers. Case A A huge (3,500,000 sq.m) piece of land in GREECE with 400 m private sandy beach. www.healthy.gr/kriavrisi/ Case B A 70,000 sq.m of precious land in the most touristic and attractive part of GREECE, with many buildings, pool, open theater, horse paddocks etc. www.healthy.gr/portoheli/ From owner-linux-xfs@oss.sgi.com Fri Apr 12 18:18:05 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3D1I58d031911 for ; Fri, 12 Apr 2002 18:18:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3D1I582031910 for linux-xfs-outgoing; Fri, 12 Apr 2002 18:18:05 -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 g3D1I08d031883 for ; Fri, 12 Apr 2002 18:18:01 -0700 Received: (qmail 2916 invoked from network); 13 Apr 2002 01:18:38 -0000 Received: from ocs3.intra.ocs.com.au (192.168.255.3) by mail.ocs.com.au with SMTP; 13 Apr 2002 01:18:38 -0000 Received: by ocs3.intra.ocs.com.au (Postfix, from userid 16331) id 201D23000BA; Sat, 13 Apr 2002 11:18:36 +1000 (EST) Received: from ocs3.intra.ocs.com.au (localhost [127.0.0.1]) by ocs3.intra.ocs.com.au (Postfix) with ESMTP id D3D7294 for ; Sat, 13 Apr 2002 11:18:36 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: linux-xfs@oss.sgi.com Subject: Re: Oops 2.4.18 + RAID5, now 2.4.9-31SGI_XFS_1.1_PR4 In-reply-to: Your message of "Fri, 12 Apr 2002 16:45:40 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 13 Apr 2002 11:18:31 +1000 Message-ID: <22289.1018660711@ocs3.intra.ocs.com.au> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 12 Apr 2002 16:45:40 -0500 (CDT), Daryl Herzmann wrote: > I would send along a ksymopps, but nothing was sent to syslog. I >did have a oops on the screen, but I could not scroll up or anything to >get it all. linux/Documentation/oops-tracing.txt. "Where is the_oops.txt?" From owner-linux-xfs@oss.sgi.com Sat Apr 13 06:28:07 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3DDS78d019433 for ; Sat, 13 Apr 2002 06:28:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3DDS75X019432 for linux-xfs-outgoing; Sat, 13 Apr 2002 06:28:07 -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 g3DDRq8d019400 for ; Sat, 13 Apr 2002 06:27:53 -0700 Received: from lizard.webland.de (www.sinitec.de [194.122.76.165]) by mx.de.kpnqwest.net (Postfix (mx12)) with ESMTP id 62D5DC2CB; Sat, 13 Apr 2002 14:57: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 OAA29023; Sat, 13 Apr 2002 14:57:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 0245757306; Sat, 13 Apr 2002 14:56:12 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id E477C25835; Sat, 13 Apr 2002 14:56:08 +0200 (CEST) Message-ID: <3CB82AE8.B48C5411@ch.sauter-bc.com> Date: Sat, 13 Apr 2002 14:56:08 +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: Thor Lancelot Simon , linux-xfs@oss.sgi.com Subject: Re: XFS installer and driver/update disks References: <20020412133802.A26968@pla-muek.reefedge.com> <3CB72D12.11BF637D@ch.sauter-bc.com> <20020412150118.A27171@pla-muek.reefedge.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thor Lancelot Simon schrieb: > > On Fri, Apr 12, 2002 at 08:53:06PM +0200, Simon Matter wrote: > > > > You have exactly the same problem I had with two Servers. I solved it by > > installing Linux Mandrake. > > Does Mandrake include XFS? > > Thor Mandrake includes ext3, JFX, ReiserFS and XFS, Software RAID and LVM, everything with the graphical installer. It's really very nice work. -Simon From owner-linux-xfs@oss.sgi.com Sat Apr 13 07:34:52 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3DEYq8d020898 for ; Sat, 13 Apr 2002 07:34:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3DEYq10020897 for linux-xfs-outgoing; Sat, 13 Apr 2002 07:34:52 -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 g3DEY98d020856 for ; Sat, 13 Apr 2002 07:34:10 -0700 Received: from lizard.webland.de (www.sinitec.de [194.122.76.165]) by mx.de.kpnqwest.net (Postfix (mx05)) with ESMTP id C4CD862FE; Sat, 13 Apr 2002 16:11: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 QAA02816; Sat, 13 Apr 2002 16:11:05 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id AC6D957306; Sat, 13 Apr 2002 16:10:12 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 5B79E25835; Sat, 13 Apr 2002 16:10:11 +0200 (CEST) Message-ID: <3CB83C43.4EEB25F2@ch.sauter-bc.com> Date: Sat, 13 Apr 2002 16:10:11 +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: Daryl Herzmann Cc: linux-xfs@oss.sgi.com Subject: Re: Oops 2.4.18 + RAID5, now 2.4.9-31SGI_XFS_1.1_PR4 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Daryl Herzmann schrieb: > > Hi! > Thanks to those that responded to my orginal email. I installed > the 2.4.9-31SGI_XFS_1.1_PR4 RPM as suggested below and my machine just > locked and I had to hard reset it. Again, it was under heavy NFS load. Is it only NFS which lets the machine lock up? If it is hardware related in any way, it smells like a problem between disk and network controller. Shared IRQ handling comes to mind. Sometimes even moving PCI cards to different slots can help here. It shouldn't happen anyway. > It was also suggested to me to get a 3ware controller, so I may try that. > I would be more inclined to move the data off and then reformat ext3 once > and see what happens. This all makes me very nervous, since I now have a > TB fileserver in RAID 5 running XFS that has been stable thus far, but it > has not been subjected to NFS load (it will be soon) :( > > I would send along a ksymopps, but nothing was sent to syslog. I > did have a oops on the screen, but I could not scroll up or anything to > get it all. My 2.4.18 crashes did not kill the system as bad as this one > did. > > Daryl > > On Wed, 10 Apr 2002, Simon Matter wrote: > > >I've been running a similar server for almost a year now. > >It's RH 7.1 + XFS, Promise Ultra100TX2 with 4 Quantum 15G drives, > >software RAID5. I have a second server, RH 7.2 + XFS, Promise > >Ultra100TX2 with 4 IBM 60G drives, software RAID5. > > > >No problems so far, only 3 of 8 IBM drives dead, but that's another > >story. > >Can you try a current RH based kernel with XFS? At least for me it has > >always worked very well. > > > >ftp://oss.sgi.com/projects/xfs/download/testing/xfs-1.1/kernel_rpms/2.4.9-31-RH/ > > > >This is from the small server: > > > >[root@xxl pub]# cat /proc/ide/pdc202xx > > > > PDC20268 TX2 Chipset. > >------------------------------- General Status > >--------------------------------- > >Burst Mode : enabled > >Host Mode : Tri-Stated > >Bus Clocking : 100 External > >IO pad select : 10 mA > >Status Polling Period : 15 > >Interrupt Check Status Polling Delay : 15 > >--------------- Primary Channel ---------------- Secondary Channel > >------------- > > enabled enabled > >66 Clocking enabled enabled > > Mode MASTER Mode MASTER > >--------------- drive0 --------- drive1 -------- drive0 ---------- > >drive1 ------ > >DMA enabled: yes yes yes yes > >--------------- Cannot Decode HOST --------------- > > > >[root@xxl pub]# lspci > >00:00.0 Host bridge: VIA Technologies, Inc. VT82C598 [Apollo MVP3] (rev > >04) > >00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo > >MVP3/Pro133x AGP] > >00:07.0 ISA bridge: VIA Technologies, Inc. VT82C586/A/B PCI-to-ISA > >[Apollo VP] (rev 47) > >00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) > >00:07.3 Host bridge: VIA Technologies, Inc. VT82C586B ACPI (rev 10) > >00:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] > >(rev 64) > >00:09.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] > >(rev 08) > >00:0a.0 Unknown mass storage controller: Promise Technology, Inc.: > >Unknown device 4d68 (rev 01) > >00:0b.0 SCSI storage controller: Adaptec AIC-7881U > >01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 03) > > > >[root@xxl pub]# cat /proc/mdstat > >Personalities : [raid1] [raid5] > >read_ahead 1024 sectors > >md8 : active raid5 hde10[0] hdf7[2] hdg10[1] hdh7[3] > > 31406976 blocks level 5, 128k chunk, algorithm 0 [4/4] [UUUU] > > > >md7 : active raid1 hdf6[0] hdh6[1] > > 1024000 blocks [2/2] [UU] > > > >md5 : active raid1 hdf5[0] hdh5[1] > > 3072256 blocks [2/2] [UU] > > > >md0 : active raid1 hde1[0] hdf1[1] hdg1[2] hdh1[3] > > 102720 blocks [4/4] [UUUU] > > > >md6 : active raid1 hde9[0] hdg9[1] > > 1024000 blocks [2/2] [UU] > > > >md4 : active raid1 hde8[0] hdg8[1] > > 511936 blocks [2/2] [UU] > > > >md3 : active raid1 hde7[0] hdg7[1] > > 511936 blocks [2/2] [UU] > > > >md2 : active raid1 hde6[0] hdg6[1] > > 1755328 blocks [2/2] [UU] > > > >md1 : active raid1 hde5[0] hdg5[1] > > 292672 blocks [2/2] [UU] > > > >unused devices: > > > > > > > >Daryl Herzmann schrieb: > >> > >> Hi, > >> I have a box that had been running RH 7.1 + XFS for a year without > >> a single problem. Recently, I put 3 120G Maxtor 4G120J6 drives on the > >> onboard Promise Controller (pdc202xx) and did software RAID 5. And wow, > >> have the problems started! I went from running a 2.4.3 something kernel > >> to a custom compiled 2.4.18 w/ SGI patch dated March 3. Still no luck. > >> It seems under heavy NFS load, that these problems will start occuring. > >> > >> Any thoughts? I have been trying to follow the ongoing NFS + > >> XFS + RAID 5 discussions, but I am not sure where I should be at > >> regarding kernel + patches. > >> > >> My ksymoops is below. > >> > >> Thanks! Daryl > >> > >> Other info that may be helpful. > >> > >> # lspci > >> 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev > >> 03) > >> 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] > >> 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] > >> (rev 40) > >> 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 06) > >> 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] > >> (rev 40) > >> 00:08.0 VGA compatible controller: Trident Microsystems Blade 3D PCI/AGP > >> (rev 3a) > >> 00:0c.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] > >> (rev 30) > >> 00:0f.0 RAID bus controller: Promise Technology, Inc. 20265 (rev 02) > >> > >> # free > >> total used free shared buffers cached > >> Mem: 900644 897436 3208 0 0 842932 > >> -/+ buffers/cache: 54504 846140 > >> Swap: 1028152 0 1028152 > >> > >> # cat /proc/ide/pdc202xx > >> > >> PDC20265 Chipset. > >> ------------------------------- General Status > >> --------------------------------- > >> Burst Mode : enabled > >> Host Mode : Normal > >> Bus Clocking : 33 PCI Internal > >> IO pad select : 10 mA > >> Status Polling Period : 0 > >> Interrupt Check Status Polling Delay : 2 > >> --------------- Primary Channel ---------------- Secondary Channel > >> ------------- > >> enabled enabled > >> 66 Clocking enabled enabled > >> Mode MASTER Mode MASTER > >> FIFO Empty ???????????? > >> --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 > >> ------ > >> DMA enabled: no yes yes yes > >> DMA Mode: NOTSET UDMA 4 UDMA 4 UDMA 4 > >> PIO Mode: NOTSET PIO ? PIO ? PIO ? > >> > >> Here is my ksymoops from this morning's crash. > >> > >> >>EIP; c013f736 <===== > >> Trace; c013d70c > >> Trace; c0126e78 > >> Trace; c013da00 > >> Trace; c0127037 > >> Trace; c012708c > >> Trace; c0127141 > >> Trace; c01271b6 > >> Trace; c0127311 > >> Trace; c0127270 > >> Trace; c0105000 > >> Trace; c0105536 > >> Trace; c0127270 > >> Code; c013f736 > >> 00000000 <_EIP>: > >> Code; c013f736 <===== > >> 0: 8b 46 20 mov 0x20(%esi),%eax <===== > >> Code; c013f739 > >> 3: 85 c0 test %eax,%eax > >> Code; c013f73b > >> 5: 0f 45 f8 cmovne %eax,%edi > >> Code; c013f73e > >> 8: 85 ff test %edi,%edi > >> Code; c013f740 > >> a: 74 0b je 17 <_EIP+0x17> c013f74d > >> > >> Code; c013f742 > >> c: 8b 47 10 mov 0x10(%edi),%eax > >> Code; c013f745 > >> f: 85 c0 test %eax,%eax > >> Code; c013f747 > >> 11: 74 04 je 17 <_EIP+0x17> c013f74d > >> > >> Code; c013f749 > >> 13: 53 push %ebx > >> > >> and then the next immediate oops > >> > >> >>EIP; c013f736 <===== > >> Trace; c013d70c > >> Trace; c0126e78 > >> Trace; c013da00 > >> Trace; c0127037 > >> Trace; c012708c > >> Trace; c0127951 <_alloc_pages+71/1c0> > >> Trace; c0127bbb <__alloc_pages+11b/180> > >> Trace; c0127c30 <__get_free_pages+10/20> > >> Trace; c0139d73 <__pollwait+33/1040> > >> Trace; c025137e > >> Trace; c023abdf > >> Trace; c0139fcb <__pollwait+28b/1040> > >> Trace; c013a43c <__pollwait+6fc/1040> > >> Trace; c0106cfb <__up_wakeup+110f/23e4> > >> Code; c013f736 > >> 00000000 <_EIP>: > >> Code; c013f736 <===== > >> 0: 8b 46 20 mov 0x20(%esi),%eax <===== > >> Code; c013f739 > >> 3: 85 c0 test %eax,%eax > >> Code; c013f73b > >> 5: 0f 45 f8 cmovne %eax,%edi > >> Code; c013f73e > >> 8: 85 ff test %edi,%edi > >> Code; c013f740 > >> a: 74 0b je 17 <_EIP+0x17> c013f74d > >> > >> Code; c013f742 > >> c: 8b 47 10 mov 0x10(%edi),%eax > >> Code; c013f745 > >> f: 85 c0 test %eax,%eax > >> Code; c013f747 > >> 11: 74 04 je 17 <_EIP+0x17> c013f74d > >> > >> Code; c013f749 > >> 13: 53 push %ebx > >> > >> -- > >> /** > >> * Daryl Herzmann (akrherz@iastate.edu) > >> * Program Assistant -- Iowa Environmental Mesonet > >> * http://mesonet.agron.iastate.edu > >> */ > > > > > > > > -- > /** > * Daryl Herzmann (akrherz@iastate.edu) > * Program Assistant -- Iowa Environmental Mesonet > * http://mesonet.agron.iastate.edu > */ From owner-linux-xfs@oss.sgi.com Sun Apr 14 10:20:30 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3EHKU8d007625 for ; Sun, 14 Apr 2002 10:20:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3EHKUQU007624 for linux-xfs-outgoing; Sun, 14 Apr 2002 10:20:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from pooh.lsc.hu (IDENT:postfix@pooh.lsc.hu [195.56.172.131]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3EHKA8d007587 for ; Sun, 14 Apr 2002 10:20:11 -0700 Received: by pooh.lsc.hu (Postfix, from userid 547) id D559FE0B01; Sun, 14 Apr 2002 19:31:56 +0200 (CEST) Date: Sun, 14 Apr 2002 19:31:56 +0200 From: GCS To: linux-xfs@oss.sgi.com Subject: XFS, preemption and lock break freezes the box Message-ID: <20020414193156.A10856@lsc.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Anyone using the combo in subject? It locks the box if I would like to write on loop mounted filesystems, regardless of it's type. It happens with ext2 as well as XFS, but not if I do not include XFS in the kernel or I disable the lock break patch. The call trace is __wait_on_buffer, fsync_dev and sync_dev. I also know that with a vanilla kernel I get a lot of lock_break: buffer.c:938: count was 0 not 1 messages. If I include XFS, then it changes to lock_break: buffer.c:919: count was 2 not 551 lock_break: exit.c:252: count was 2 not 1 A big patch for testing is available at http://prdownloads.sourceforge.net/lkpc/lkpc-2.4.18-5beta7.patch.bz2 Thanks for any spot, GCS -- BorsodChem Joint-Stock Company Linux Support Center University of Miskolc Software engineer Programmer System administrator +36-48-511211/27-90 +36-20-4441745 From owner-linux-xfs@oss.sgi.com Sun Apr 14 19:26:11 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3F2QB8d024990 for ; Sun, 14 Apr 2002 19:26:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3F2QARA024989 for linux-xfs-outgoing; Sun, 14 Apr 2002 19:26:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3F2Q38d024959 for ; Sun, 14 Apr 2002 19:26:04 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3F2QnQR088047 for ; Sun, 14 Apr 2002 21:26:50 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3F2Qf6G010699; Sun, 14 Apr 2002 19:26:43 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3F2Qdp43126404; Sun, 14 Apr 2002 19:26:39 -0700 (PDT) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA24355; Mon, 15 Apr 2002 12:26:30 +1000 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA85950; Mon, 15 Apr 2002 12:25:07 +1000 (EST) Date: Mon, 15 Apr 2002 12:25:07 +1000 (EST) From: Timothy Shimmin Message-Id: <200204150225.MAA85950@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, linux-xfs@thebarn.com, tridge@samba.org, sandeen@sgi.com, nathans@sgi.com Subject: TAKE - xfs_acl.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan S., merge to 2.5 , thanks :) Andrew T., if you want, please try your program with a larger inode and with this xfs change, and see if it speeds things up. Eric S., I think this should be good for XFS 1.1 . And there will be another TAKE shortly for an error code change for ACL/EAs from E2BIG to ERANGE to be consistent with Andreas' convention (and doc'ed in our man page and used in the user tools). This will be a kernel and cmd change. Need to check all repercussions first. --Tim Date: Sun Apr 14 18:48:42 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:116374a linux/fs/xfs/xfs_acl.c - 1.15 - Set the length of the EA for the ACL to be the effective length of the ACL (count + ACEs actually used) instead of the length of the whole array. In practice, this will mean smaller EAs for ACLs and may allow them to fit in the inode if it is big enough. These small ACL/EAs on XFS were tested on IRIX by copying the FS to IRIX and worked fine. From owner-linux-xfs@oss.sgi.com Mon Apr 15 08:45:27 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FFjR8d029887 for ; Mon, 15 Apr 2002 08:45:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FFjQbY029886 for linux-xfs-outgoing; Mon, 15 Apr 2002 08:45:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ftp-smtp.fotokem.com ([65.161.242.161]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FFjN8d029841 for ; Mon, 15 Apr 2002 08:45:23 -0700 Received: from navieg.internal.fotokem.com ([139.64.105.65]) by ftp-smtp.fotokem.com (Post.Office MTA v3.5.3 release 223 ID# 0-61736U1000L100S0V35) with SMTP id com for ; Mon, 15 Apr 2002 08:46:08 -0700 Received: (from pchapman [139.64.104.66]) by navieg.internal.fotokem.com (NAVIEG 2.1 bld 63) with SMTP id M2002041508460722258 for ; Mon, 15 Apr 2002 08:46:07 -0700 Reply-To: From: pchapman@fotokem.com (Paul Chapman) To: Subject: Broken Link Date: Mon, 15 Apr 2002 08:46:06 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The link to the ISO images on this page seems to be broken: http://oss.sgi.com/projects/xfs/102_installer.html Paul Chapman From owner-linux-xfs@oss.sgi.com Mon Apr 15 08:55:43 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FFth8d031174 for ; Mon, 15 Apr 2002 08:55:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FFthAA031173 for linux-xfs-outgoing; Mon, 15 Apr 2002 08:55: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FFtc8d031141 for ; Mon, 15 Apr 2002 08:55: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 KAA72193; Mon, 15 Apr 2002 10:56:23 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA65278; Mon, 15 Apr 2002 10:56:23 -0500 (CDT) Subject: Re: Broken Link From: Eric Sandeen To: pchapman@fotokem.com Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Apr 2002 10:56:23 -0500 Message-Id: <1018886183.30016.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-04-15 at 10:46, Paul Chapman wrote: > The link to the ISO images on this page seems to be broken: > > http://oss.sgi.com/projects/xfs/102_installer.html it should be ftp://oss.sgi.com/projects/xfs/download/Release-1.0.2/installer/i386/RH7.2-SGI-XFS-1.0.2a.iso Thanks for pointign it out; I'll fix it in a minute. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Apr 15 09:35:20 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FGZK8d000623 for ; Mon, 15 Apr 2002 09:35:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FGZKtA000622 for linux-xfs-outgoing; Mon, 15 Apr 2002 09:35:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf14bis.bellsouth.net (mail114.mail.bellsouth.net [205.152.58.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FGZA8d000584 for ; Mon, 15 Apr 2002 09:35:11 -0700 Received: from taz ([65.81.168.173]) by imf14bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020415163720.LGBE20778.imf14bis.bellsouth.net@taz>; Mon, 15 Apr 2002 12:37:20 -0400 Date: Mon, 15 Apr 2002 12:34:00 -0400 From: Greg Freemyer Subject: re[2]: XFS installer and driver/update disks To: Simon Matter cc: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020415163720.LGBE20778.imf14bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3FGZB8d000590 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> The real problem is that RedHat does not include XFS in their kernel. >> They ship it with 1001 patches applied but no XFS. It's a real pain. I >> have then tried Skipjack-beta1 in the hope, they included XFS. Nothing. >> I decided to call this a bug and posted it on bugzilla. >> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62072 >> I'm asking list members not to flame on bugzilla. I guess it won't help. >> -Simon I just posted the below comment to Simon's report, and got the below surprising reply. If the reply is in error, I suggest someone with a better knowledge of this than I should post a follow on comment. ========= The reply was: == sorry but 2.4 doesn't have the ACL interface yet and in 2.5 it's still somewhat immature (eg not set in stone) == My comment was: === >From what I understand the ACL kernel API was standardized in the 2.4.18 kernel. The team at http://acl.bestbits.at/ that support ext2/ext3 patches for ACLs and the XFS support team have merged their user tools for working with ACLs. The JFS team has stated that adding ACL support is a top priority now that there is a standard API in the kernel. I imagine they too will use the above userland tools. End-user code such as Samba 2.2.3a support this interface. In other words, I would say the ACLs in Linux have gone from experimental to standardized. As a user, I want to use this new standard Linux feature. I would like to see official Redhat support of ACLs. I don't really care if it is: XFS ext2/ext3 with the http://acl.bestbits.at/ extensions A possible future JFS. One nice thing about XFS is that it does come with xfsdump and xfsrestore. For the acl.bestbits solution, there is enhanced version of tar: star. === Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Mon Apr 15 10:02:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FH2J8d002013 for ; Mon, 15 Apr 2002 10:02:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FH2JYF002011 for linux-xfs-outgoing; Mon, 15 Apr 2002 10:02:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from phoenix.infradead.org (imladris.infradead.org [194.205.184.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FH278d001975 for ; Mon, 15 Apr 2002 10:02:13 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 16x9sJ-0007G7-00; Mon, 15 Apr 2002 18:02:43 +0100 Date: Mon, 15 Apr 2002 18:02:43 +0100 From: Christoph Hellwig To: Greg Freemyer Cc: Simon Matter , linux-xfs@oss.sgi.com Subject: Re: re[2]: XFS installer and driver/update disks Message-ID: <20020415180243.A27219@infradead.org> References: <20020415163720.LGBE20778.imf14bis.bellsouth.net@taz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020415163720.LGBE20778.imf14bis.bellsouth.net@taz>; from freemyer@NorcrossGroup.com on Mon, Apr 15, 2002 at 12:34:00PM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Apr 15, 2002 at 12:34:00PM -0400, Greg Freemyer wrote: > The team at http://acl.bestbits.at/ that support ext2/ext3 patches for ACLs and > the XFS support team have merged their user tools for working with ACLs. > > The JFS team has stated that adding ACL support is a top priority now that there > is a standard API in the kernel. I imagine they too will use the above userland > tools. Yes, with me one of the JFS/Linux core-team members is working on EA/ACL support, but for now this is targeted at 2.5 only - 2.4 code should be almost the same but without the EA interface set in stone it doesn't make sense to work on it yet. > End-user code such as Samba 2.2.3a support this interface. Is the new (attr2/acl2) interface really compatible to samba 2.2.3a? > In other words, I would say the ACLs in Linux have gone from experimental to > standardized. No. 2.5 has a EA interface that still is changing (i.e. locking changes in XFS CVS or the recent discussion on !IFREG && !IFDIR EAs) and NO standadized ACL interface in mainline at yet. Any distributor that ships ACL support now has the risk of having to support obsolete ACL interfaces or binary incompatible changes from the last version (like Mandrake 8.1 -> 8.2 with the incompatible EA change). Christoph From owner-linux-xfs@oss.sgi.com Mon Apr 15 11:12:57 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FICv8d006039 for ; Mon, 15 Apr 2002 11:12:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FICvLb006038 for linux-xfs-outgoing; Mon, 15 Apr 2002 11:12: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FICm8d005983 for ; Mon, 15 Apr 2002 11:12:51 -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 NAA71051; Mon, 15 Apr 2002 13:13:33 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA73930; Mon, 15 Apr 2002 13:13:32 -0500 (CDT) Subject: Re: re[2]: XFS installer and driver/update disks From: Eric Sandeen To: Greg Freemyer Cc: Simon Matter , linux-xfs@oss.sgi.com In-Reply-To: <20020415163720.LGBE20778.imf14bis.bellsouth.net@taz> References: <20020415163720.LGBE20778.imf14bis.bellsouth.net@taz> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 15 Apr 2002 13:13:32 -0500 Message-Id: <1018894412.30606.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-04-15 at 11:34, Greg Freemyer wrote: > I just posted the below comment to Simon's report, and got the below surprising reply. > > If the reply is in error, I suggest someone with a better knowledge of this than I should post a follow on comment. > > ========= > The reply was: > > == > sorry but 2.4 doesn't have the ACL interface yet and in 2.5 it's still somewhat > immature (eg not set in stone) While the syscalls have been reserved in 2.5 (and will probably be added to 2.4 Real Soon Now), I think there is still some wiggle room in the actual API. Perhaps Nathan can chime in when he gets to work, as this is his baby... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Apr 15 11:31:50 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FIVo8d007396 for ; Mon, 15 Apr 2002 11:31:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FIVonn007395 for linux-xfs-outgoing; Mon, 15 Apr 2002 11:31:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from relay1.faa.gov (relay1.faa.gov [204.108.10.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FIVl8d007367 for ; Mon, 15 Apr 2002 11:31:47 -0700 Received: from awpnexgenhub.faa.gov (awp-rthub.faa.gov [172.24.3.6]) by relay1.faa.gov (Switch-2.0.6/Switch-2.0.6) with ESMTP id g3FIVoc00349 for ; Mon, 15 Apr 2002 14:31:50 -0400 (EDT) Subject: SMP Kernel PCMCIA Support To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Ray.Miller@faa.gov Date: Mon, 15 Apr 2002 11:33:41 -0700 X-MIMETrack: Serialize by Router on AWPRTHUB/AWP/H/FAA(Release 5.0.8 |June 18, 2001) at 04/15/2002 11:32:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Will be testing RH72 Linux utilizing the XFS filesystem shortly. Does your precompiled xfs-enabled SMP kernel support PCMCIA? We have smp servers that utilize PCMCIA devices. If not, what is the --define statement to enable pcmcia support in the i386 src.rpm? BTW, where can I locate all the --define parameters for src.rpm kernels? Thanks in advance. Ray From owner-linux-xfs@oss.sgi.com Mon Apr 15 11:42:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FIgM8d008373 for ; Mon, 15 Apr 2002 11:42:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FIgLRb008372 for linux-xfs-outgoing; Mon, 15 Apr 2002 11:42:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf08bis.bellsouth.net (mail008.mail.bellsouth.net [205.152.58.28]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FIgC8d008324 for ; Mon, 15 Apr 2002 11:42:12 -0700 Received: from taz ([65.81.168.173]) by imf08bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020415184422.LYTI22287.imf08bis.bellsouth.net@taz>; Mon, 15 Apr 2002 14:44:22 -0400 Date: Mon, 15 Apr 2002 14:41:14 -0400 From: Greg Freemyer Subject: re[4]: XFS installer and driver/update disks To: Eric Sandeen cc: Simon Matter , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020415184422.LYTI22287.imf08bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3FIgD8d008335 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric / Nathan, I guess I'm just totally confused, and I thought I was following this subject fairly closely. I understood the below to be true (but apparently I'm wrong): ====== The 2.5 kernel had syscalls added to it to support EAs in general. These syscalls were back ported to the 2.4 kernel and released as a standard part of 2.4.18. These new EA syscalls are being used by the user tools to implement ACLs. Shortly after the release of 2.4.18, a new set of XFS kernel patches were released that allowed the new syscalls to be compatible with XFS. This did not impact on the on-disk format. The xfs acl user tools for manipulating ACLs became broken at this point. i.e. the old kernel entry points that the xfs acl user tools depended on were no longer provided by the XFS patches. The acl.bestbits user tools were upgraded to support these new syscalls. Therefore these tools work with XFS on a 2.4.18 kernel. Due to the fact that XFS and acl.bestbits now share a common kernel API for ACL support, the previous xfs-user tools for manipulating ACLs have been retired, and the upgraded acl.bestbit tools are now used instead. The libacl.so library from acl.bestbits has also been upgraded to use the new syscalls. Therefore, programs like Samba 2.2.3a that use the libacl.so package to access ACLs automatically support the new syscalls by simply upgrading the libacl.so library to a current version. ==== If someone could please clarify the above, I would appreciate it. In particular statements that the 2.4.18 kernel does not have ACL support yet seems totally contradictory to the above. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com >> On Mon, 2002-04-15 at 11:34, Greg Freemyer wrote: >> > I just posted the below comment to Simon's report, and got the below >> surprising reply. >> > >> > If the reply is in error, I suggest someone with a better knowledge of >> this than I should post a follow on comment. >> > >> > ========= >> > The reply was: >> > >> > == >> > sorry but 2.4 doesn't have the ACL interface yet and in 2.5 it's still >> somewhat >> > immature (eg not set in stone) >> While the syscalls have been reserved in 2.5 (and will probably be added >> to 2.4 Real Soon Now), I think there is still some wiggle room in the >> actual API. Perhaps Nathan can chime in when he gets to work, as this >> is his baby... >> -Eric >> -- >> Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs >> sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Apr 15 12:26:47 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FJQk8d011191 for ; Mon, 15 Apr 2002 12:26:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FJQkpq011190 for linux-xfs-outgoing; Mon, 15 Apr 2002 12:26:46 -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.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FJQc8d011138 for ; Mon, 15 Apr 2002 12:26:38 -0700 Received: (qmail 32395 invoked by uid 500); 15 Apr 2002 19:27:05 -0000 Subject: Re: SMP Kernel PCMCIA Support From: Austin Gonyou To: Ray.Miller@faa.gov Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oqQHIIdL+2qWfEWGKRnD" X-Mailer: Ximian Evolution 1.0.3.99 Date: 15 Apr 2002 14:27:05 -0500 Message-Id: <1018898825.32291.10.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-oqQHIIdL+2qWfEWGKRnD Content-Type: text/plain Content-Transfer-Encoding: quoted-printable quickest way is to probably get the src.rpm and install it then look in /usr/src/redhat/SPECS. (That's -ivh, not --rebuild) :)=20 On Mon, 2002-04-15 at 13:33, Ray.Miller@faa.gov wrote: > Will be testing RH72 Linux utilizing the XFS filesystem shortly. >=20 > Does your precompiled xfs-enabled SMP kernel support PCMCIA? We have smp > servers that utilize PCMCIA devices. >=20 > If not, what is the --define statement to enable pcmcia support in the > i386 > src.rpm? >=20 > BTW, where can I locate all the --define parameters for src.rpm kernels? >=20 > Thanks in advance. >=20 > Ray --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-oqQHIIdL+2qWfEWGKRnD 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 iD8DBQA8uymJ94g6ZVmFMoIRAuYjAJ4kuKVktT69j55y22f+qNn1FSS64wCgsAEd jYEz+D/eTimdV87tD3rPAfU= =1mvi -----END PGP SIGNATURE----- --=-oqQHIIdL+2qWfEWGKRnD-- From owner-linux-xfs@oss.sgi.com Mon Apr 15 13:06:45 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FK6j8d013768 for ; Mon, 15 Apr 2002 13:06:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FK6iIK013767 for linux-xfs-outgoing; Mon, 15 Apr 2002 13:06: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FK6e8d013732 for ; Mon, 15 Apr 2002 13:06:40 -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 PAA71921 for ; Mon, 15 Apr 2002 15:07:26 -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 PAA02588 for ; Mon, 15 Apr 2002 15:07:25 -0500 (CDT) Received: (from roehrich@localhost) by clink.americas.sgi.com (SGI-8.9.3/8.9.3/erikj-IRIX) id PAA13052 for linux-xfs@oss.sgi.com; Mon, 15 Apr 2002 15:07:25 -0500 (CDT) Date: Mon, 15 Apr 2002 15:07:25 -0500 (CDT) From: Dean Roehrich Message-Id: <200204152007.PAA13052@clink.americas.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - enhance some dmapi tests Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Mon Apr 15 13:07:13 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:116421a src/suite1/cmd/print_event.c - 1.4 - add ability to call dm_set_disp on a newly mounted filesystem src/suite1/cmd/set_eventlist.c - 1.5 - fixup usage message src/common/cmd/set_return_on_destroy.c - 1.6 - let the user specify a token From owner-linux-xfs@oss.sgi.com Mon Apr 15 16:32:02 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FNW28d024206 for ; Mon, 15 Apr 2002 16:32:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FNW27Z024205 for linux-xfs-outgoing; Mon, 15 Apr 2002 16:32:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mrfloppy.digitaloffense.net (mrfloppy.digitaloffense.net [63.164.121.200]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FNVu8d024168 for ; Mon, 15 Apr 2002 16:31:56 -0700 Received: (qmail 2320 invoked by alias); 15 Apr 2002 23:32:38 -0000 Received: from unknown (HELO sliver) (127.0.0.1) by localhost with SMTP; 15 Apr 2002 23:32:38 -0000 Content-Type: text/plain; charset="iso-8859-1" From: H D Moore To: agent99@sgi.com, linux-xfs@oss.sgi.com, bugtraq@securityfocus.com Subject: Re: IRIX XFS filesystem denial of service attack Date: Mon, 15 Apr 2002 18:32:38 -0500 X-Mailer: KMail [version 1.4] References: <10204151449.ZM268355@einstein.csd.sgi.com> In-Reply-To: <10204151449.ZM268355@einstein.csd.sgi.com> X-DigitalOffense: TRUE MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204151832.38497.sflist@digitaloffense.net> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Does this vulnerability affect the Linux XFS port? The XFS page has no information about this or whether there is a fix available: http://oss.sgi.com/projects/xfs/ -HD On Monday 15 April 2002 04:49 pm, SGI Security Coordinator wrote: > > SGI Security Advisory > > Title: IRIX XFS filesystem denial of service attack > Number: 20020402-01-P > Date: April 15, 2002 > Reference: CAN-2002-0042 > ----------------------- > --- Issue Specifics --- > ----------------------- > > It has been reported that there is a vulnerability in IRIX's XFS > filesystem. Under some circumstances, a user can create a file that would > hang any application that would try to access it. This has the potential > to be used to create a Denial of Service attack. From owner-linux-xfs@oss.sgi.com Mon Apr 15 16:41:34 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3FNfY8d024839 for ; Mon, 15 Apr 2002 16:41:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3FNfYIm024838 for linux-xfs-outgoing; Mon, 15 Apr 2002 16:41:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.staff.site.ntu.edu.au (mail.staff.site.ntu.edu.au [138.80.69.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3FNfN8d024804 for ; Mon, 15 Apr 2002 16:41:24 -0700 Subject: xfsdump-2.0.0-0 extended attributes query. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Date: Tue, 16 Apr 2002 09:12:12 +0930 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: xfsdump-2.0.0-0 extended attributes query. Thread-Index: AcHk1ypBprSgdYR9Tk24epE68MUXGw== From: "Jean-Claude Nou" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3FNfP8d024806 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I am testing the XFS file system and utilities (ver 2.0.0-0 with the 2.4.18-SGI_XFS_1.1_PR2 kernel) in the hope of including them in a roll out. I have made a backup and successfully restored, however the ACL's weren't restored. I am curious - are they meant to? I assume this is what is meant by extended attributes in the xfsdump man page. I couldn't find any other doco that specifically discusses this. The commands that were issued are: xfsdump -L session1 -M xfsbackupTEST -l 0 -o -f /dev/nst0 /mnt/xfs xfsrestore -f /dev/nst0 -i /mnt/xfs/restored_files/ BTW - previous backup/restore attempts resulted in (which didn't happen in version 2.0.0-0 so I guess you guys have been busy): xfsrestore: drive_scsitape.c:1504: do_next_mark: Assertion `rechdrp->first_mark_offset - rechdrp->file_offset <= ( off64_t )( contextp->dc_recsz )' failed. The file system is XFS. This is an example of the results from getfacl: [root@test4 win98]# getfacl * # file: Windows 98.png # owner: root # group: root user::rw- group::r-- other::r-- # file: Windows 98.vmx # owner: root # group: root user::rw- group::r-- other::r-- # file: nvram # owner: root # group: root user::rw- group::r-- other::r-- # file: vmware-core # owner: root # group: root user::rw- group::r-- other::r-- # file: vmware.log # owner: root # group: root user::rwx group::rwx #effective:rw- group:smbusers:rwx #effective:rw- mask::rw- other::--- # file: win98.vmdk # owner: root # group: root user::rwx group::rwx #effective:rw- group:smbusers:rwx #effective:rw- mask::rw- other::--- Looking forward to your reply. TIA Jean-Claude Nou SITE InfoTech Faculty Of SITE Northern Territory University From owner-linux-xfs@oss.sgi.com Mon Apr 15 19:03:42 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G23g8d032289 for ; Mon, 15 Apr 2002 19:03:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G23gEO032288 for linux-xfs-outgoing; Mon, 15 Apr 2002 19:03:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from appsales.net ([65.168.244.19]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G23A8d032226 for ; Mon, 15 Apr 2002 19:03:11 -0700 Message-Id: <200204160203.g3G23A8d032226@oss.sgi.com> Received: (qmail 21755 invoked from network); 15 Apr 2002 22:54:08 -0000 Received: from unknown (HELO appsales.net) (65.168.244.13) by 0 with SMTP; 15 Apr 2002 22:54:08 -0000 From: sendout@appsales.net To: Manufacturers@oss.sgi.com Subject: Manuf. Production/Control Software $1,495! Reply-To: info@appsales.net Date: 15 Apr 2002 16:04:28 -0700 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (JMSP031102)Job Master, a complete, user friendly Windows based software package, can manage and control your operation from sales quote to shipment. For one week only, Job Master, normally $2,495.00, is on sale for a total price of $1,495.00. In order for you to receive this $1,000.00 savings we must have your order by April 24th. (To be removed from our list, Please click on or send an email to: remove@appsales.net. Please put REMOVE as the subject. Our remove system is automated If you do not click on or send an email to:remove@appsales.net and have REMOVE as your subject you will be overlooked for removal by the system) Job Master is designed specifically for small to medium sized manufacturers, and costs many thousands of dollars less than any other even remotely comparable software package. Following is a list of features. If you have any questions, and would like to discuss the package further, or if you would like to obtain our Web site address for a total walk through of the program, please call me directly at (661) 254-9926, or email me at info@linkitsoftware.com By way of background, we are a software company, which for some years has specialized in the development of custom software, primarily for small to medium sized manufacturers. Job Master is a distillation of over a million and a half dollars of software we have developed to control and manage the production of our manufacturing clients. Job Master contains the following features: 1. QUOTATION MODULE. In this module, quotes are developed, modified, and produced for sending to your client. A history is kept of all quotes for future reference, or modification for other clients. All quotations and revisions are "auto numbered," including versions. The quotes section allows for the entry of parts/processes, and costing of each, including materials, labor, markup, and taxes. Inventory status can be accessed from this section for reference. 2. SALES ORDER. Once a quotation is accepted, the final quotation information can be transformed into a Sales Order for your client's signature on a "point and click" basis. The Sales Order can be modified and re issued if necessary. A history if kept of all Sales Orders for future reference, or modification for other clients. All sales orders and revisions are "auto numbered," including versions. Inventory status can be accessed from this section for reference. 3. CUSTOMER LETTERS can be created from the Quotation and Sales Order sections. 4. SHOP TRAVELER/WORK ORDER. Once a Sales Order is accepted, the sales order information can be transformed into a shop traveler/work order on a "point and click" basis. Each item on the Sales Order becomes a shop traveler/work order, with each step of production of the item then listed on the traveler/work order. Each such traveler/work order is tied back into the Sales Order. The shop traveler/work order allows for the entry of line items, and notes on each line item. The shop traveler/work order contains a "notes" section. The Shop traveler/work order allows for the storing or attachment of drawings to the traveler/work order. The shop traveler/work order also contains a "drop down," from which standard processes can be selected for inclusion on the shop traveler/work order. The shop traveler/work order numbers progress in order of production sequence, and re numbers them if new steps are added. The shop traveler/work order allows for change orders or revisions, and numbers changes in sequence of the original shop traveler/work order number; i.e., 100, 100-1, 100-2, etc. All shop traveler/work orders and related revisions are retained in memory for future reference. The shop traveler/work order is bar coded for tracking of production step by step, and production of ongoing client status reports. Bar coding includes the ability for an employee to "swipe" their own ID bar code for recording in the system as to who upgraded what step. The shop traveler/work order function also allows for manual update of production status. The shop traveler/work order allows for quality control sign off, and the final production of certifications, either from a "canned" list, or hand typed in on a case by case basis. 5. INVENTORY. The application includes an inventory section, which allows operations to check materials inventory in and out. The inventory section allows for the comparison of inventory received against a P.O., and produces an "overage/underage" report of inventory received as compared against the P.O. The inventory section allows for the setting of minimum (re-order now!) and maximum inventory amounts, and produces reports showing what inventory needs to be ordered, as well as inventory that is at or above the maximum set to have in house. The inventory section also tracks "partially shipped" orders, which are tied in to the shipping function. This section shows how much completed product under a particular order has been actually shipped to a client, and how much remains to be shipped. The balance is adjusted as shipments are made. 6. REQUEST FOR PURCHASE. The application allows operators to produce a Request For Purchase for accounting for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item. 7. REQUEST FOR BID. The application allows operators to produce a Request For Bid for accounting to send to Vendors for any inventory items, which need to be ordered. Inventory items have a drop down of approved vendors for each item to which Requests For Bid can be sent. 8. INVOICE. The application produces an invoice/invoice detail for all completed items ready to be billed/shipped to clients. 9. PRODUCTION OUTPUT STATUS. The application produces a date range selectable report on how much product, and the value of the product, which was completed during a selected date range. The application also produces a report on how many orders, and the value of those orders, which remain to be completed during a selected date range. 10. The application produces SHIPPING DOCUMENTS as per selected shippers, and produces a PACKING SLIP. 11. The application has a "FIND" FUNCTION in selected sections, allowing for searches by customer name, work order number, etc. 12. The application has "AUTO FILL;" i.e., when an operator starts to type in a name, number, etc. all related information auto fills after the first few letters or numbers are typed in. Job Master is currently being sold in the marketplace for $2,495.00 per package. However, if we receive your order by April 24th, your total price will be $1,495.00 Again, if you have any questions at all, or would like to place your order, please call me on my direct line, (661) 254-9926. Thank you! Mario Chavez Link It Software Corp. --------------------------------------------------------------------------- --------------- (To be removed from our list, Please click on or send an email to: remove@appsales.net. Please put REMOVE as the subject. Our remove system is automated If you do not click on or send an email to:remove@appsales.net and have REMOVE as your subject you will be overlooked for removal by the system) --------------------------------------------------------------------------- ---------------- From owner-linux-xfs@oss.sgi.com Mon Apr 15 21:43:36 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G4ha8d006534 for ; Mon, 15 Apr 2002 21:43:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G4haZd006533 for linux-xfs-outgoing; Mon, 15 Apr 2002 21:43:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G4hU8d006504 for ; Mon, 15 Apr 2002 21:43:31 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3G4iLQR000284 for ; Mon, 15 Apr 2002 23:44:22 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3G4iK6G000463 for ; Mon, 15 Apr 2002 21:44:21 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3G4iJp43932964 for <@relay.sgi.com:linux-xfs@thebarn.com>; Mon, 15 Apr 2002 21:44:19 -0700 (PDT) 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 OAA04023 for ; Tue, 16 Apr 2002 14:44:17 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA46447 for linux-xfs@thebarn.com; Tue, 16 Apr 2002 14:44:16 +1000 (AEST) Date: Tue, 16 Apr 2002 14:44:16 +1000 From: Nathan Scott To: linux-xfs@thebarn.com Subject: TAKE - acl 2.0.9 Message-ID: <20020416144416.O43073@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [I still seem to be having some issues sending mail via oss.sgi.com, so I'm resending a few recent mails through Russells mirror]. -- Nathan Date: Mon Apr 15 16:27:57 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:116440a acl/VERSION - 1.26 acl/doc/CHANGES - 1.30 acl/debian/changelog - 1.21 acl/libacl/libobj.h - 1.3 acl/libacl/__libobj.c - 1.2 - bump to version 2.0.9 - small fix for a 64-bit-platform-only issue with padding of the "obj_prefix" structure. From owner-linux-xfs@oss.sgi.com Mon Apr 15 22:23:41 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G5Nf8d007980 for ; Mon, 15 Apr 2002 22:23:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G5NfXe007979 for linux-xfs-outgoing; Mon, 15 Apr 2002 22:23:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (user-0ccsnsf.cable.mindspring.com [24.206.95.143]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G5NY8d007950 for ; Mon, 15 Apr 2002 22:23:35 -0700 Received: (from ctooley@localhost) by localhost.localdomain (8.11.6/8.11.6) id g3G5MdC17723; Tue, 16 Apr 2002 00:22:39 -0500 X-Authentication-Warning: localhost.localdomain: ctooley set sender to ctooley@amoa.org using -f Subject: Re: SMP Kernel PCMCIA Support From: Chris Tooley To: Ray.Miller@faa.gov 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 Date: 16 Apr 2002 00:22:37 -0500 Message-Id: <1018934557.17319.14.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The kernels work great with pcmcia. I use them on my laptop just fine. They use kernel pcmcia though and not the pcmcia-cs package. Chris Tooley On Mon, 2002-04-15 at 13:33, Ray.Miller@faa.gov wrote: > Will be testing RH72 Linux utilizing the XFS filesystem shortly. > > Does your precompiled xfs-enabled SMP kernel support PCMCIA? We have smp > servers that utilize PCMCIA devices. > > If not, what is the --define statement to enable pcmcia support in the i386 > src.rpm? > > BTW, where can I locate all the --define parameters for src.rpm kernels? > > Thanks in advance. > > Ray > From owner-linux-xfs@oss.sgi.com Mon Apr 15 22:31:23 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G5VN8d008352 for ; Mon, 15 Apr 2002 22:31:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G5VNdk008351 for linux-xfs-outgoing; Mon, 15 Apr 2002 22:31:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G5V78d008321 for ; Mon, 15 Apr 2002 22:31:08 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3G5VxQR000632 for ; Tue, 16 Apr 2002 00:31:59 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3G6VwBA003118 for ; Mon, 15 Apr 2002 23:31:58 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3G5Vvp44239639 for <@relay.sgi.com:linux-xfs@thebarn.com>; Mon, 15 Apr 2002 22:31:57 -0700 (PDT) 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 PAA04410 for ; Tue, 16 Apr 2002 15:31:55 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id PAA26986 for linux-xfs@thebarn.com; Tue, 16 Apr 2002 15:31:54 +1000 (AEST) Date: Tue, 16 Apr 2002 15:31:54 +1000 From: Nathan Scott To: linux-xfs@thebarn.com Subject: [RESEND] Re: re[4]: XFS installer and driver/update disks Message-ID: <20020416153154.A46619@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [Resending this via Russell's list, due to oss.sgi.com<->melbourne mail handling issues at the moment.] ----- Forwarded message from Nathan Scott ----- Date: Tue, 16 Apr 2002 10:28:12 +1000 To: Greg Freemyer Cc: Eric Sandeen , Simon Matter , linux-xfs@oss.sgi.com User-Agent: Mutt/1.2.5i From: Nathan Scott Subject: Re: re[4]: XFS installer and driver/update disks On Mon, Apr 15, 2002 at 02:41:14PM -0400, Greg Freemyer wrote: > Eric / Nathan, > > I guess I'm just totally confused, and I thought I was following this subject fairly closely. OK, here's some answers. I'll try to stick to the facts... I really don't want to get involved in the politics here. > I understood the below to be true (but apparently I'm wrong): > > ====== > The 2.5 kernel had syscalls added to it to support EAs in general. Yup. In addition, a VFS interface was also added (ie. there are multiple definitions of "interface" in this discussion, so beware). > These syscalls were back ported to the 2.4 kernel and released as a standard part of 2.4.18. The second part of this statement is incorrect - it has an "off-by-two" error. Marcelo has agreed to include the complete EA patch (that is in 2.5 already, since 2.5.3) in 2.4.20-preX. In 2.4.18 Marcelo took a patch to mark the extended attributes system calls as reserved, and it was 2.4.18 that we switched the XFS CVS tree over to the new interfaces. > These new EA syscalls are being used by the user tools to implement ACLs. > > Shortly after the release of 2.4.18, a new set of XFS kernel patches were released that allowed the new syscalls to be compatible with XFS. This did not impact on the on-disk format. The xfs acl user tools for manipulating ACLs became broken at this point. i.e. the old kernel entry points that the xfs acl user tools depended on were no longer provided by the XFS patches. Yes, this is correct. > The acl.bestbits user tools were upgraded to support these new syscalls. Therefore these tools work with XFS on a 2.4.18 kernel. Yep. > Due to the fact that XFS and acl.bestbits now share a common kernel API for ACL support, the previous xfs-user tools for manipulating ACLs have been retired, and the upgraded acl.bestbit tools are now used instead. Yes, this is now a shared project - both groups are involved in the ongoing development of acl/attr packages in a cooperative manor. eg. the ACL web site is still a much better source of ACL-specific info and those folks host the web site, the mailing list, etc. They asked if we would continue to maintain the CVS tree for the user tools, and we do; plus many changes have been made to both of our patch sets to make them work better together. > The libacl.so library from acl.bestbits has also been upgraded to use the new syscalls. > > Therefore, programs like Samba 2.2.3a that use the libacl.so package to access ACLs automatically support the new syscalls by simply upgrading the libacl.so library to a current version. Yes, Samba uses the libacl API and has no knowledge of system calls or even ACL data structures (which are intentionally hidden below the libacl API, and an opaque acl handle is passed around above the API). This libacl implements the (withdrawn draft) POSIX 1003.1e ACL interfaces which several UNIX variants also implement. > ==== > If someone could please clarify the above, I would appreciate it. > > In particular statements that the 2.4.18 kernel does not have ACL support yet seems totally contradictory to the above. It would technically be true to say no official kernel has any ACL support yet. Such a statement is deliberately misleading, however, and the changes needed to add ACL support to the kernel above and beyond what is already there are trivial. For Christoph: One approach that you and the IBM guys might want to investigate is to implement the code behind the xattr VFS interfaces (and only conditionally compile that file), and then tell people to get the bestbits patches to enable that EA/ACL support (this would allow you guys to get the the 2.4 JFS support in there too, without needing to make any changes to the kernel outside of JFS, which seems to be the JFS mantra). Just a thought, maybe it helps maybe not, I dunno. The VFS locking changes we have in 2.5 are at the request of the ext2/ext3 camp, and have been sent on to Linus (this is part of the wider VFS BKL changes in 2.5, so is inappropriate for 2.4). For the guys following that Redhat bug: I guess one could also point out that its hypocritical to claim that these EA/ACL interfaces can't be used because the ABI _might_ change (which is extremely unlikely - neither the XFS nor the ext2/3 projects have any plans to change the EA format for ACLs; the format also has a version field which can be used to support backward compatibility _if_ that should ever become necessary; and userspace uses the libacl API which hides this anyway!), while most of the distributors, including Redhat, use a quotactl(2) interface with an ABI which _does_ differ to that in the standard kernels from Linus/Marcelo. cheers. -- Nathan ----- End forwarded message ----- -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 15 23:19:57 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G6Ju8d010506 for ; Mon, 15 Apr 2002 23:19:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G6JuBL010505 for linux-xfs-outgoing; Mon, 15 Apr 2002 23:19:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from acid.compass.com.ph (IDENT:+SQJd/GZTLjE2IJgkc86OnG0kFa+sQ9I@acid.compass.com.ph [216.252.144.37]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G6Jo8d010474 for ; Mon, 15 Apr 2002 23:19:52 -0700 Received: by acid.compass.com.ph (Postfix, from userid 500) id C43F0119A414; Tue, 16 Apr 2002 14:20:35 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by acid.compass.com.ph (Postfix) with ESMTP id 8D0BF328FEF0 for ; Tue, 16 Apr 2002 14:20:35 +0800 (PHT) Date: Tue, 16 Apr 2002 14:20:35 +0800 (PHT) From: "Mark M. Barrios" To: linux-xfs@oss.sgi.com Subject: CVS kernel tree question Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, i just finished migrating my RH72 desktop box from ext3 to XFS and the results are great. i just have this problem with the kernel source i pulled from CVS, seems i can only compile a kernel once and after that the kernel src becomes unusable with errors when i do a make bzImage. i tried to do a make clean and a mrproper but it still doesnt work so i have to unpack an untouched linux-xfs src i have backed up. is it a problem with just my box? and do you know how often new code is commited to CVS? Thanks, Mark M. Barrios From owner-linux-xfs@oss.sgi.com Mon Apr 15 23:30:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G6Uc8d011031 for ; Mon, 15 Apr 2002 23:30:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G6Ucxw011030 for linux-xfs-outgoing; Mon, 15 Apr 2002 23:30:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G6UX8d011001 for ; Mon, 15 Apr 2002 23:30:34 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3G6VOQR001069 for ; Tue, 16 Apr 2002 01:31:25 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3G6VO6G003531 for ; Mon, 15 Apr 2002 23:31:24 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3G6VNp42642093 for <@relay.sgi.com:linux-xfs@thebarn.com>; Mon, 15 Apr 2002 23:31:23 -0700 (PDT) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA05062; Tue, 16 Apr 2002 16:31:19 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA57903; Tue, 16 Apr 2002 16:31:19 +1000 (EST) Date: Tue, 16 Apr 2002 16:31:19 +1000 (EST) From: Nathan Scott Message-Id: <200204160631.QAA57903@snort.melbourne.sgi.com> To: linux-xfs@thebarn.com Cc: sandeen@sgi.com Subject: TAKE - ATTR macro encodings Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This fixes that xfsdump/xfsrestore issue reported to the list earlier today/yesterday. cheers. Date: Mon Apr 15 23:28: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:116450a linux/fs/xfs/xfs_attr.h - 1.18 - The ATTR_* values were incorrect, ultimately causing xfsdump to do the wrong thing when manipulating attributes in the root namespace, like ACLs. This change brings these back into line with the original IRIX/XFS values (for those that have counterparts in IRIX). From owner-linux-xfs@oss.sgi.com Mon Apr 15 23:37:52 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G6bq8d011496 for ; Mon, 15 Apr 2002 23:37:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G6bqig011495 for linux-xfs-outgoing; Mon, 15 Apr 2002 23:37:52 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G6bj8d011467 for ; Mon, 15 Apr 2002 23:37:46 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3G6cbQR001102 for ; Tue, 16 Apr 2002 01:38:38 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3G6cT6G003695; Mon, 15 Apr 2002 23:38:29 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3G6cSp43395682; Mon, 15 Apr 2002 23:38:28 -0700 (PDT) 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 QAA05096; Tue, 16 Apr 2002 16:38:25 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA31359; Tue, 16 Apr 2002 16:38:24 +1000 (AEST) Date: Tue, 16 Apr 2002 16:38:24 +1000 From: Nathan Scott To: Jean-Claude Nou Cc: linux-xfs@thebarn.com Subject: Re: xfsdump-2.0.0-0 extended attributes query. Message-ID: <20020416163824.B26032@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 jean-claude.nou@ntu.edu.au on Tue, Apr 16, 2002 at 09:12:12AM +0930 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello Jean-Claude, On Tue, Apr 16, 2002 at 09:12:12AM +0930, Jean-Claude Nou wrote: > Hi, > > I am testing the XFS file system and utilities (ver 2.0.0-0 with the 2.4.18-SGI_XFS_1.1_PR2 kernel) in the hope of including them in a roll out. I have made a backup and successfully restored, however the ACL's weren't restored. I am curious - are they meant to? I assume this is what is meant by extended attributes in the xfsdump man page. I couldn't find any other doco that specifically discusses this. Yes, you're correct -- ACLs are implemented using extended attributes in XFS, and yes they are meant to be restored. This turned out to be an XFS kernel bug... > The commands that were issued are: > > xfsdump -L session1 -M xfsbackupTEST -l 0 -o -f /dev/nst0 /mnt/xfs > xfsrestore -f /dev/nst0 -i /mnt/xfs/restored_files/ > > BTW - previous backup/restore attempts resulted in (which didn't happen in version 2.0.0-0 so I guess you guys have been busy): (yes, Tim tells me this issue was fixed a little while ago) > > Looking forward to your reply. > I have just checked in a kernel change which will fix this problem - it should show up in the XFS CVS tree kernel shortly. Thanks for reporting the problem. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 15 23:42:01 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G6g18d011857 for ; Mon, 15 Apr 2002 23:42:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G6g1FY011856 for linux-xfs-outgoing; Mon, 15 Apr 2002 23:42:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G6fu8d011826 for ; Mon, 15 Apr 2002 23:41:57 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3G6gmQR001124 for ; Tue, 16 Apr 2002 01:42:49 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3G7gbBA005189; Tue, 16 Apr 2002 00:42:37 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3G6gap42817866; Mon, 15 Apr 2002 23:42:36 -0700 (PDT) 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 QAA05131; Tue, 16 Apr 2002 16:42:31 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA35827; Tue, 16 Apr 2002 16:42:30 +1000 (AEST) Date: Tue, 16 Apr 2002 16:42:30 +1000 From: Nathan Scott To: "Mark M. Barrios" Cc: linux-xfs@thebarn.com Subject: Re: CVS kernel tree question Message-ID: <20020416164230.C26032@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 sleep@acid.compass.com.ph on Tue, Apr 16, 2002 at 02:20:35PM +0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 16, 2002 at 02:20:35PM +0800, Mark M. Barrios wrote: > hi, > > i just finished migrating my RH72 desktop box from ext3 to XFS and > the results are great. i just have this problem with the kernel source > i pulled from CVS, seems i can only compile a kernel once and after that > the kernel src becomes unusable with errors when i do a make bzImage. i > tried to do a make clean and a mrproper but it still doesnt work so i have > to unpack an untouched linux-xfs src i have backed up. is it a problem > with just my box? Maybe... I don't have this problem - could you send us the exact error message from the failed build? > and do you know how often new code is commited to CVS? Very often. It slows down a bit while Steve's away on holiday though. ;-) cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 16 01:38:49 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G8cn8d016377 for ; Tue, 16 Apr 2002 01:38:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G8cnGX016376 for linux-xfs-outgoing; Tue, 16 Apr 2002 01:38:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G8bJ8d016285 for ; Tue, 16 Apr 2002 01:37:19 -0700 Received: from acid.compass.com.ph (IDENT:zsJ9UQ6OdRM01R8iPeClJ6FhwRAQZOzC@acid.compass.com.ph [216.252.144.37]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3G8c3QR002052 for ; Tue, 16 Apr 2002 03:38:05 -0500 (CDT) Received: by acid.compass.com.ph (Postfix, from userid 500) id B9D07116A2CA; Tue, 16 Apr 2002 16:37:49 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by acid.compass.com.ph (Postfix) with ESMTP id 9BDA5338381F; Tue, 16 Apr 2002 16:37:49 +0800 (PHT) Date: Tue, 16 Apr 2002 16:37:49 +0800 (PHT) From: "Mark M. Barrios" To: Nathan Scott Cc: linux-xfs@thebarn.com Subject: Re: CVS kernel tree question In-Reply-To: <20020416164230.C26032@wobbly.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-52943472-2013051498-1018946269=:4326" 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. ---52943472-2013051498-1018946269=:4326 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 16 Apr 2002, Nathan Scott wrote: > On Tue, Apr 16, 2002 at 02:20:35PM +0800, Mark M. Barrios wrote: > > hi, > > > > i just finished migrating my RH72 desktop box from ext3 to XFS and > > the results are great. i just have this problem with the kernel source > > i pulled from CVS, seems i can only compile a kernel once and after that > > the kernel src becomes unusable with errors when i do a make bzImage. i > > tried to do a make clean and a mrproper but it still doesnt work so i have > > to unpack an untouched linux-xfs src i have backed up. is it a problem > > with just my box? > > Maybe... I don't have this problem - could you send us the > exact error message from the failed build? > > > and do you know how often new code is commited to CVS? > > Very often. It slows down a bit while Steve's away on holiday > though. ;-) > > cheers. > > Here it is, I've also attached my .config. I just updated my sources from CVS today and tried to build it twice, seems the problem went away? but Im not sure. Thanks for the help and quick response anyway :) --- Mark M. Barrios ---52943472-2013051498-1018946269=:4326 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="error.log" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename="error.log" Z2NjIC1EX19LRVJORUxfXyAtSS91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGlu dXgvaW5jbHVkZSAgLVdhbGwgLVdzdHJpY3QtcHJvdG90eXBlcyAtV25vLXRy aWdyYXBocyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLWZuby1jb21tb24g LWZvbWl0LWZyYW1lLXBvaW50ZXIgLXBpcGUgLW1wcmVmZXJyZWQtc3RhY2st Ym91bmRhcnk9MiAtbWFyY2g9aTY4NiAgIC1ES0JVSUxEX0JBU0VOQU1FPW1h aW4gLWMgLW8gaW5pdC9tYWluLm8gaW5pdC9tYWluLmMNCkluIGZpbGUgaW5j bHVkZWQgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1 ZGUvYXNtL3NlbWFwaG9yZS5oOjM5LA0KICAgICAgICAgICAgICAgICBmcm9t IC91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9m cy5oOjIxMywNCiAgICAgICAgICAgICAgICAgZnJvbSAvdXNyL3NyYy9saW51 eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvY2FwYWJpbGl0eS5oOjE3 LA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3Ivc3JjL2xpbnV4LTIuNC14 ZnMvbGludXgvaW5jbHVkZS9saW51eC9iaW5mbXRzLmg6NSwNCiAgICAgICAg ICAgICAgICAgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2lu Y2x1ZGUvbGludXgvc2NoZWQuaDo5LA0KICAgICAgICAgICAgICAgICBmcm9t IC91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9t bS5oOjQsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGludXgt Mi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3NsYWIuaDoxNCwNCiAgICAg ICAgICAgICAgICAgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4 L2luY2x1ZGUvbGludXgvcHJvY19mcy5oOjUsDQogICAgICAgICAgICAgICAg IGZyb20gaW5pdC9tYWluLmM6MTU6DQovdXNyL3NyYy9saW51eC0yLjQteGZz L2xpbnV4L2luY2x1ZGUvYXNtL3N5c3RlbS5oOjEzOiBwYXJzZSBlcnJvciBi ZWZvcmUgYCgnDQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gL3Vzci9zcmMvbGlu dXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3J3c2VtLmg6MjcsDQog ICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGludXgtMi40LXhmcy9s aW51eC9pbmNsdWRlL2FzbS9zZW1hcGhvcmUuaDo0MiwNCiAgICAgICAgICAg ICAgICAgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1 ZGUvbGludXgvZnMuaDoyMTMsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vz ci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L2NhcGFi aWxpdHkuaDoxNywNCiAgICAgICAgICAgICAgICAgZnJvbSAvdXNyL3NyYy9s aW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvYmluZm10cy5oOjUs DQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGludXgtMi40LXhm cy9saW51eC9pbmNsdWRlL2xpbnV4L3NjaGVkLmg6OSwNCiAgICAgICAgICAg ICAgICAgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1 ZGUvbGludXgvbW0uaDo0LA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3Iv c3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9zbGFiLmg6 MTQsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGludXgtMi40 LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3Byb2NfZnMuaDo1LA0KICAgICAg ICAgICAgICAgICBmcm9tIGluaXQvbWFpbi5jOjE1Og0KL3Vzci9zcmMvbGlu dXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2FzbS9yd3NlbS5oOjQ3OiBwYXJz ZSBlcnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xp bnV4L2luY2x1ZGUvYXNtL3J3c2VtLmg6NDg6IHBhcnNlIGVycm9yIGJlZm9y ZSBgKCcNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9h c20vcndzZW0uaDo0OTogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KSW4gZmls ZSBpbmNsdWRlZCBmcm9tIC91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgv aW5jbHVkZS9saW51eC9qZmZzMl9mc19zYi5oOjgsDQogICAgICAgICAgICAg ICAgIGZyb20gL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRl L2xpbnV4L2ZzLmg6NzMwLA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3Iv c3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9jYXBhYmls aXR5Lmg6MTcsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGlu dXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L2JpbmZtdHMuaDo1LA0K ICAgICAgICAgICAgICAgICBmcm9tIC91c3Ivc3JjL2xpbnV4LTIuNC14ZnMv bGludXgvaW5jbHVkZS9saW51eC9zY2hlZC5oOjksDQogICAgICAgICAgICAg ICAgIGZyb20gL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRl L2xpbnV4L21tLmg6NCwNCiAgICAgICAgICAgICAgICAgZnJvbSAvdXNyL3Ny Yy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvc2xhYi5oOjE0 LA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3Ivc3JjL2xpbnV4LTIuNC14 ZnMvbGludXgvaW5jbHVkZS9saW51eC9wcm9jX2ZzLmg6NSwNCiAgICAgICAg ICAgICAgICAgZnJvbSBpbml0L21haW4uYzoxNToNCi91c3Ivc3JjL2xpbnV4 LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9jb21wbGV0aW9uLmg6MzA6 IHBhcnNlIGVycm9yIGJlZm9yZSBgKCcNCi91c3Ivc3JjL2xpbnV4LTIuNC14 ZnMvbGludXgvaW5jbHVkZS9saW51eC9jb21wbGV0aW9uLmg6MzE6IHBhcnNl IGVycm9yIGJlZm9yZSBgKCcNCkluIGZpbGUgaW5jbHVkZWQgZnJvbSAvdXNy L3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvY2FwYWJp bGl0eS5oOjE3LA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3Ivc3JjL2xp bnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9iaW5mbXRzLmg6NSwN CiAgICAgICAgICAgICAgICAgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZz L2xpbnV4L2luY2x1ZGUvbGludXgvc2NoZWQuaDo5LA0KICAgICAgICAgICAg ICAgICBmcm9tIC91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVk ZS9saW51eC9tbS5oOjQsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9z cmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3NsYWIuaDox NCwNCiAgICAgICAgICAgICAgICAgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQt eGZzL2xpbnV4L2luY2x1ZGUvbGludXgvcHJvY19mcy5oOjUsDQogICAgICAg ICAgICAgICAgIGZyb20gaW5pdC9tYWluLmM6MTU6DQovdXNyL3NyYy9saW51 eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvZnMuaDogSW4gZnVuY3Rp b24gYHB1dF9iaCc6DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2lu Y2x1ZGUvbGludXgvZnMuaDoxMTYzOiB3YXJuaW5nOiBpbXBsaWNpdCBkZWNs YXJhdGlvbiBvZiBmdW5jdGlvbiBgYmFycmllcicNCi91c3Ivc3JjL2xpbnV4 LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9mcy5oOiBBdCB0b3AgbGV2 ZWw6DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGlu dXgvZnMuaDoxMTkxOiBwYXJzZSBlcnJvciBiZWZvcmUgYCgnDQovdXNyL3Ny Yy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvZnMuaDoxMTky OiBwYXJzZSBlcnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQt eGZzL2xpbnV4L2luY2x1ZGUvbGludXgvZnMuaDoxMTkzOiBwYXJzZSBlcnJv ciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2lu Y2x1ZGUvbGludXgvZnMuaDoxMTk0OiBwYXJzZSBlcnJvciBiZWZvcmUgYCgn DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgv ZnMuaDogSW4gZnVuY3Rpb24gYG1hcmtfYnVmZmVyX2RpcnR5X2lub2RlJzoN Ci91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9m cy5oOjEyMjQ6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1 bmN0aW9uIGBtYXJrX2J1ZmZlcl9kaXJ0eScNCi91c3Ivc3JjL2xpbnV4LTIu NC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9mcy5oOiBBdCB0b3AgbGV2ZWw6 DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgv ZnMuaDoxMzQ1OiBwYXJzZSBlcnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9s aW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvZnMuaDoxMzQ2OiBw YXJzZSBlcnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZz L2xpbnV4L2luY2x1ZGUvbGludXgvZnMuaDoxMzQ3OiBwYXJzZSBlcnJvciBi ZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1 ZGUvbGludXgvZnMuaDoxMzQ4OiBwYXJzZSBlcnJvciBiZWZvcmUgYCgnDQpJ biBmaWxlIGluY2x1ZGVkIGZyb20gL3Vzci9zcmMvbGludXgtMi40LXhmcy9s aW51eC9pbmNsdWRlL2xpbnV4L21tLmg6NCwNCiAgICAgICAgICAgICAgICAg ZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGlu dXgvc2xhYi5oOjE0LA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3Ivc3Jj L2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9wcm9jX2ZzLmg6 NSwNCiAgICAgICAgICAgICAgICAgZnJvbSBpbml0L21haW4uYzoxNToNCi91 c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9zY2hl ZC5oOjE1NTogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KSW4gZmlsZSBpbmNs dWRlZCBmcm9tIC91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVk ZS9saW51eC9tbS5oOjQsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9z cmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3NsYWIuaDox NCwNCiAgICAgICAgICAgICAgICAgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQt eGZzL2xpbnV4L2luY2x1ZGUvbGludXgvcHJvY19mcy5oOjUsDQogICAgICAg ICAgICAgICAgIGZyb20gaW5pdC9tYWluLmM6MTU6DQovdXNyL3NyYy9saW51 eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvc2NoZWQuaDo1ODY6IHBh cnNlIGVycm9yIGJlZm9yZSBgKCcNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMv bGludXgvaW5jbHVkZS9saW51eC9zY2hlZC5oOjU4NzogcGFyc2UgZXJyb3Ig YmVmb3JlIGAoJw0KL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNs dWRlL2xpbnV4L3NjaGVkLmg6NTg4OiBwYXJzZSBlcnJvciBiZWZvcmUgYCgn DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgv c2NoZWQuaDo1ODk6IHBhcnNlIGVycm9yIGJlZm9yZSBgKCcNCi91c3Ivc3Jj L2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9zY2hlZC5oOjU5 MTogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KL3Vzci9zcmMvbGludXgtMi40 LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3NjaGVkLmg6NTkyOiBwYXJzZSBl cnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4 L2luY2x1ZGUvbGludXgvc2NoZWQuaDo1OTQ6IHBhcnNlIGVycm9yIGJlZm9y ZSBgKCcNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9s aW51eC9zY2hlZC5oOjc1NjogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KL3Vz ci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3NjaGVk Lmg6IEluIGZ1bmN0aW9uIGBtbWRyb3AnOg0KL3Vzci9zcmMvbGludXgtMi40 LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3NjaGVkLmg6NzYwOiB3YXJuaW5n OiBpbXBsaWNpdCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbiBgX19tbWRyb3An DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgv c2NoZWQuaDogQXQgdG9wIGxldmVsOg0KL3Vzci9zcmMvbGludXgtMi40LXhm cy9saW51eC9pbmNsdWRlL2xpbnV4L3NjaGVkLmg6NzkzOiBwYXJzZSBlcnJv ciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2lu Y2x1ZGUvbGludXgvc2NoZWQuaDo3OTQ6IHBhcnNlIGVycm9yIGJlZm9yZSBg KCcNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51 eC9zY2hlZC5oOjc5NTogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KSW4gZmls ZSBpbmNsdWRlZCBmcm9tIC91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgv aW5jbHVkZS9saW51eC9tbS5oOjEzLA0KICAgICAgICAgICAgICAgICBmcm9t IC91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9z bGFiLmg6MTQsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGlu dXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3Byb2NfZnMuaDo1LA0K ICAgICAgICAgICAgICAgICBmcm9tIGluaXQvbWFpbi5jOjE1Og0KL3Vzci9z cmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3N3YXAuaDox MDQ6IHBhcnNlIGVycm9yIGJlZm9yZSBgKCcNCi91c3Ivc3JjL2xpbnV4LTIu NC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9zd2FwLmg6MTA1OiBwYXJzZSBl cnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4 L2luY2x1ZGUvbGludXgvc3dhcC5oOjEwNjogcGFyc2UgZXJyb3IgYmVmb3Jl IGAoJw0KL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xp bnV4L3N3YXAuaDoxMDg6IHBhcnNlIGVycm9yIGJlZm9yZSBgKCcNCi91c3Iv c3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9zd2FwLmg6 MTE0OiBwYXJzZSBlcnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0y LjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvc3dhcC5oOjE2MTogcGFyc2Ug ZXJyb3IgYmVmb3JlIGAoJw0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC91c3Iv c3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9zbGFiLmg6 MTQsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGludXgtMi40 LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L3Byb2NfZnMuaDo1LA0KICAgICAg ICAgICAgICAgICBmcm9tIGluaXQvbWFpbi5jOjE1Og0KL3Vzci9zcmMvbGlu dXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L21tLmg6MzA2OiBwYXJz ZSBlcnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xp bnV4L2luY2x1ZGUvbGludXgvbW0uaDozNTg6IHBhcnNlIGVycm9yIGJlZm9y ZSBgKCcNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9s aW51eC9tbS5oOjM1OTogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KL3Vzci9z cmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L21tLmg6IElu IGZ1bmN0aW9uIGBhbGxvY19wYWdlcyc6DQovdXNyL3NyYy9saW51eC0yLjQt eGZzL2xpbnV4L2luY2x1ZGUvbGludXgvbW0uaDozNjk6IHdhcm5pbmc6IGlt cGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0aW9uIGBfYWxsb2NfcGFnZXMn DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgv bW0uaDozNjk6IHdhcm5pbmc6IHJldHVybiBtYWtlcyBwb2ludGVyIGZyb20g aW50ZWdlciB3aXRob3V0IGEgY2FzdA0KL3Vzci9zcmMvbGludXgtMi40LXhm cy9saW51eC9pbmNsdWRlL2xpbnV4L21tLmg6IEF0IHRvcCBsZXZlbDoNCi91 c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9tbS5o OjM3NDogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KL3Vzci9zcmMvbGludXgt Mi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L21tLmg6Mzc1OiBwYXJzZSBl cnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4 L2luY2x1ZGUvbGludXgvbW0uaDozOTE6IHBhcnNlIGVycm9yIGJlZm9yZSBg KCcNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51 eC9tbS5oOjM5MjogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KL3Vzci9zcmMv bGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L21tLmg6NDE2OiBw YXJzZSBlcnJvciBiZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZz L2xpbnV4L2luY2x1ZGUvbGludXgvbW0uaDo0MTc6IHBhcnNlIGVycm9yIGJl Zm9yZSBgKCcNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVk ZS9saW51eC9tbS5oOiBJbiBmdW5jdGlvbiBgcG1kX2FsbG9jJzoNCi91c3Iv c3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9tbS5oOjQz OTogd2FybmluZzogaW1wbGljaXQgZGVjbGFyYXRpb24gb2YgZnVuY3Rpb24g YF9fcG1kX2FsbG9jJw0KL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9p bmNsdWRlL2xpbnV4L21tLmg6NDM5OiB3YXJuaW5nOiByZXR1cm4gbWFrZXMg cG9pbnRlciBmcm9tIGludGVnZXIgd2l0aG91dCBhIGNhc3QNCkluIGZpbGUg aW5jbHVkZWQgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2lu Y2x1ZGUvbGludXgvcHJvY19mcy5oOjUsDQogICAgICAgICAgICAgICAgIGZy b20gaW5pdC9tYWluLmM6MTU6DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xp bnV4L2luY2x1ZGUvbGludXgvc2xhYi5oOiBBdCB0b3AgbGV2ZWw6DQovdXNy L3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvc2xhYi5o OjY1OiBwYXJzZSBlcnJvciBiZWZvcmUgYCgnDQpJbiBmaWxlIGluY2x1ZGVk IGZyb20gL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2xp bnV4L2hpZ2htZW0uaDo1LA0KICAgICAgICAgICAgICAgICBmcm9tIC91c3Iv c3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9wYWdlbWFw Lmg6MTYsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGludXgt Mi40LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L2xvY2tzLmg6OCwNCiAgICAg ICAgICAgICAgICAgZnJvbSAvdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4 L2luY2x1ZGUvbGludXgvZGV2ZnNfZnNfa2VybmVsLmg6NiwNCiAgICAgICAg ICAgICAgICAgZnJvbSBpbml0L21haW4uYzoxNjoNCi91c3Ivc3JjL2xpbnV4 LTIuNC14ZnMvbGludXgvaW5jbHVkZS9hc20vcGdhbGxvYy5oOiBJbiBmdW5j dGlvbiBgZ2V0X3BnZF9zbG93JzoNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMv bGludXgvaW5jbHVkZS9hc20vcGdhbGxvYy5oOjYxOiB3YXJuaW5nOiBpbXBs aWNpdCBkZWNsYXJhdGlvbiBvZiBmdW5jdGlvbiBgX19nZXRfZnJlZV9wYWdl cycNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9hc20v cGdhbGxvYy5oOiBJbiBmdW5jdGlvbiBgZnJlZV9wZ2Rfc2xvdyc6DQovdXNy L3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvYXNtL3BnYWxsb2Mu aDoxMDM6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0 aW9uIGBmcmVlX3BhZ2VzJw0KSW4gZmlsZSBpbmNsdWRlZCBmcm9tIC91c3Iv c3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9saW51eC9sb2Nrcy5o OjgsDQogICAgICAgICAgICAgICAgIGZyb20gL3Vzci9zcmMvbGludXgtMi40 LXhmcy9saW51eC9pbmNsdWRlL2xpbnV4L2RldmZzX2ZzX2tlcm5lbC5oOjYs DQogICAgICAgICAgICAgICAgIGZyb20gaW5pdC9tYWluLmM6MTY6DQovdXNy L3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvcGFnZW1h cC5oOiBBdCB0b3AgbGV2ZWw6DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xp bnV4L2luY2x1ZGUvbGludXgvcGFnZW1hcC5oOjgyOiBwYXJzZSBlcnJvciBi ZWZvcmUgYCgnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1 ZGUvbGludXgvcGFnZW1hcC5oOjgzOiBwYXJzZSBlcnJvciBiZWZvcmUgYCgn DQpJbiBmaWxlIGluY2x1ZGVkIGZyb20gL3Vzci9zcmMvbGludXgtMi40LXhm cy9saW51eC9pbmNsdWRlL2xpbnV4L2RldmZzX2ZzX2tlcm5lbC5oOjYsDQog ICAgICAgICAgICAgICAgIGZyb20gaW5pdC9tYWluLmM6MTY6DQovdXNyL3Ny Yy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvbGludXgvbG9ja3MuaDoy OTogcGFyc2UgZXJyb3IgYmVmb3JlIGAoJw0KSW4gZmlsZSBpbmNsdWRlZCBm cm9tIGluaXQvbWFpbi5jOjMyOg0KL3Vzci9zcmMvbGludXgtMi40LXhmcy9s aW51eC9pbmNsdWRlL2FzbS9idWdzLmg6IEluIGZ1bmN0aW9uIGBjaGVja19m cHUnOg0KL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2Fz bS9idWdzLmg6NzE6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9m IGZ1bmN0aW9uIGBwcmludGsnDQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xp bnV4L2luY2x1ZGUvYXNtL2J1Z3MuaDo3MTogYEtFUk5fRU1FUkcnIHVuZGVj bGFyZWQgKGZpcnN0IHVzZSBpbiB0aGlzIGZ1bmN0aW9uKQ0KL3Vzci9zcmMv bGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2FzbS9idWdzLmg6NzE6IChF YWNoIHVuZGVjbGFyZWQgaWRlbnRpZmllciBpcyByZXBvcnRlZCBvbmx5IG9u Y2UNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9hc20v YnVncy5oOjcxOiBmb3IgZWFjaCBmdW5jdGlvbiBpdCBhcHBlYXJzIGluLikN Ci91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVkZS9hc20vYnVn cy5oOjcxOiBwYXJzZSBlcnJvciBiZWZvcmUgc3RyaW5nIGNvbnN0YW50DQov dXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvYXNtL2J1Z3Mu aDo3MjogcGFyc2UgZXJyb3IgYmVmb3JlIHN0cmluZyBjb25zdGFudA0KL3Vz ci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRlL2FzbS9idWdzLmg6 ODc6IGBLRVJOX0lORk8nIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSBpbiB0aGlz IGZ1bmN0aW9uKQ0KL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNs dWRlL2FzbS9idWdzLmg6ODc6IHBhcnNlIGVycm9yIGJlZm9yZSBzdHJpbmcg Y29uc3RhbnQNCi91c3Ivc3JjL2xpbnV4LTIuNC14ZnMvbGludXgvaW5jbHVk ZS9hc20vYnVncy5oOjkyOiBwYXJzZSBlcnJvciBiZWZvcmUgc3RyaW5nIGNv bnN0YW50DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUv YXNtL2J1Z3MuaDogSW4gZnVuY3Rpb24gYGNoZWNrX2hsdCc6DQovdXNyL3Ny Yy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvYXNtL2J1Z3MuaDoxMTU6 IGBLRVJOX0lORk8nIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSBpbiB0aGlzIGZ1 bmN0aW9uKQ0KL3Vzci9zcmMvbGludXgtMi40LXhmcy9saW51eC9pbmNsdWRl L2FzbS9idWdzLmg6MTE1OiBwYXJzZSBlcnJvciBiZWZvcmUgc3RyaW5nIGNv bnN0YW50DQovdXNyL3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUv YXNtL2J1Z3MuaDogSW4gZnVuY3Rpb24gYGNoZWNrX2NvbmZpZyc6DQovdXNy L3NyYy9saW51eC0yLjQteGZzL2xpbnV4L2luY2x1ZGUvYXNtL2J1Z3MuaDox NzA6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0aW9u IGBwYW5pYycNCmluaXQvbWFpbi5jOiBJbiBmdW5jdGlvbiBgcHJvZmlsZV9z ZXR1cCc6DQppbml0L21haW4uYzoxNDM6IHdhcm5pbmc6IGltcGxpY2l0IGRl Y2xhcmF0aW9uIG9mIGZ1bmN0aW9uIGBnZXRfb3B0aW9uJw0KaW5pdC9tYWlu LmM6IEluIGZ1bmN0aW9uIGBuYW1lX3RvX2tkZXZfdCc6DQppbml0L21haW4u YzoyOTY6IHdhcm5pbmc6IGltcGxpY2l0IGRlY2xhcmF0aW9uIG9mIGZ1bmN0 aW9uIGBzaW1wbGVfc3RydG91bCcNCmluaXQvbWFpbi5jOiBJbiBmdW5jdGlv biBgZGVidWdfa2VybmVsJzoNCmluaXQvbWFpbi5jOjQwNDogYGNvbnNvbGVf bG9nbGV2ZWwnIHVuZGVjbGFyZWQgKGZpcnN0IHVzZSBpbiB0aGlzIGZ1bmN0 aW9uKQ0KaW5pdC9tYWluLmM6IEluIGZ1bmN0aW9uIGBxdWlldF9rZXJuZWwn Og0KaW5pdC9tYWluLmM6NDEyOiBgY29uc29sZV9sb2dsZXZlbCcgdW5kZWNs YXJlZCAoZmlyc3QgdXNlIGluIHRoaXMgZnVuY3Rpb24pDQptYWtlOiAqKiog W2luaXQvbWFpbi5vXSBFcnJvciAxDQo= ---52943472-2013051498-1018946269=:4326 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=config Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=config Iw0KIyBBdXRvbWF0aWNhbGx5IGdlbmVyYXRlZCBieSBtYWtlIG1lbnVjb25m aWc6IGRvbid0IGVkaXQNCiMNCkNPTkZJR19YODY9eQ0KQ09ORklHX0lTQT15 DQojIENPTkZJR19TQlVTIGlzIG5vdCBzZXQNCkNPTkZJR19VSUQxNj15DQoN CiMNCiMgQ29kZSBtYXR1cml0eSBsZXZlbCBvcHRpb25zDQojDQpDT05GSUdf RVhQRVJJTUVOVEFMPXkNCg0KIw0KIyBMb2FkYWJsZSBtb2R1bGUgc3VwcG9y dA0KIw0KQ09ORklHX01PRFVMRVM9eQ0KQ09ORklHX01PRFZFUlNJT05TPXkN CkNPTkZJR19LTU9EPXkNCg0KIw0KIyBQcm9jZXNzb3IgdHlwZSBhbmQgZmVh dHVyZXMNCiMNCiMgQ09ORklHX00zODYgaXMgbm90IHNldA0KIyBDT05GSUdf TTQ4NiBpcyBub3Qgc2V0DQojIENPTkZJR19NNTg2IGlzIG5vdCBzZXQNCiMg Q09ORklHX001ODZUU0MgaXMgbm90IHNldA0KIyBDT05GSUdfTTU4Nk1NWCBp cyBub3Qgc2V0DQojIENPTkZJR19NNjg2IGlzIG5vdCBzZXQNCkNPTkZJR19N UEVOVElVTUlJST15DQojIENPTkZJR19NUEVOVElVTTQgaXMgbm90IHNldA0K IyBDT05GSUdfTUs2IGlzIG5vdCBzZXQNCiMgQ09ORklHX01LNyBpcyBub3Qg c2V0DQojIENPTkZJR19NRUxBTiBpcyBub3Qgc2V0DQojIENPTkZJR19NQ1JV U09FIGlzIG5vdCBzZXQNCiMgQ09ORklHX01XSU5DSElQQzYgaXMgbm90IHNl dA0KIyBDT05GSUdfTVdJTkNISVAyIGlzIG5vdCBzZXQNCiMgQ09ORklHX01X SU5DSElQM0QgaXMgbm90IHNldA0KIyBDT05GSUdfTUNZUklYSUlJIGlzIG5v dCBzZXQNCkNPTkZJR19YODZfV1BfV09SS1NfT0s9eQ0KQ09ORklHX1g4Nl9J TlZMUEc9eQ0KQ09ORklHX1g4Nl9DTVBYQ0hHPXkNCkNPTkZJR19YODZfWEFE RD15DQpDT05GSUdfWDg2X0JTV0FQPXkNCkNPTkZJR19YODZfUE9QQURfT0s9 eQ0KIyBDT05GSUdfUldTRU1fR0VORVJJQ19TUElOTE9DSyBpcyBub3Qgc2V0 DQpDT05GSUdfUldTRU1fWENIR0FERF9BTEdPUklUSE09eQ0KQ09ORklHX1g4 Nl9MMV9DQUNIRV9TSElGVD01DQpDT05GSUdfWDg2X1RTQz15DQpDT05GSUdf WDg2X0dPT0RfQVBJQz15DQpDT05GSUdfWDg2X1BHRT15DQpDT05GSUdfWDg2 X1VTRV9QUFJPX0NIRUNLU1VNPXkNCiMgQ09ORklHX1RPU0hJQkEgaXMgbm90 IHNldA0KIyBDT05GSUdfSThLIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JQ1JP Q09ERSBpcyBub3Qgc2V0DQojIENPTkZJR19YODZfTVNSIGlzIG5vdCBzZXQN CiMgQ09ORklHX1g4Nl9DUFVJRCBpcyBub3Qgc2V0DQpDT05GSUdfTk9ISUdI TUVNPXkNCiMgQ09ORklHX0hJR0hNRU00RyBpcyBub3Qgc2V0DQojIENPTkZJ R19ISUdITUVNNjRHIGlzIG5vdCBzZXQNCiMgQ09ORklHX01BVEhfRU1VTEFU SU9OIGlzIG5vdCBzZXQNCkNPTkZJR19NVFJSPXkNCiMgQ09ORklHX1NNUCBp cyBub3Qgc2V0DQpDT05GSUdfWDg2X1VQX0FQSUM9eQ0KQ09ORklHX1g4Nl9V UF9JT0FQSUM9eQ0KQ09ORklHX1g4Nl9MT0NBTF9BUElDPXkNCkNPTkZJR19Y ODZfSU9fQVBJQz15DQoNCiMNCiMgR2VuZXJhbCBzZXR1cA0KIw0KQ09ORklH X05FVD15DQpDT05GSUdfUENJPXkNCiMgQ09ORklHX1BDSV9HT0JJT1MgaXMg bm90IHNldA0KIyBDT05GSUdfUENJX0dPRElSRUNUIGlzIG5vdCBzZXQNCkNP TkZJR19QQ0lfR09BTlk9eQ0KQ09ORklHX1BDSV9CSU9TPXkNCkNPTkZJR19Q Q0lfRElSRUNUPXkNCkNPTkZJR19QQ0lfTkFNRVM9eQ0KIyBDT05GSUdfRUlT QSBpcyBub3Qgc2V0DQojIENPTkZJR19NQ0EgaXMgbm90IHNldA0KIyBDT05G SUdfSE9UUExVRyBpcyBub3Qgc2V0DQojIENPTkZJR19QQ01DSUEgaXMgbm90 IHNldA0KIyBDT05GSUdfSE9UUExVR19QQ0kgaXMgbm90IHNldA0KQ09ORklH X1NZU1ZJUEM9eQ0KQ09ORklHX0JTRF9QUk9DRVNTX0FDQ1Q9eQ0KQ09ORklH X1NZU0NUTD15DQpDT05GSUdfS0NPUkVfRUxGPXkNCiMgQ09ORklHX0tDT1JF X0FPVVQgaXMgbm90IHNldA0KQ09ORklHX0JJTkZNVF9BT1VUPXkNCkNPTkZJ R19CSU5GTVRfRUxGPXkNCkNPTkZJR19CSU5GTVRfTUlTQz15DQojIENPTkZJ R19QTSBpcyBub3Qgc2V0DQojIENPTkZJR19BQ1BJIGlzIG5vdCBzZXQNCiMg Q09ORklHX0FQTSBpcyBub3Qgc2V0DQoNCiMNCiMgTWVtb3J5IFRlY2hub2xv Z3kgRGV2aWNlcyAoTVREKQ0KIw0KIyBDT05GSUdfTVREIGlzIG5vdCBzZXQN Cg0KIw0KIyBQYXJhbGxlbCBwb3J0IHN1cHBvcnQNCiMNCkNPTkZJR19QQVJQ T1JUPW0NCkNPTkZJR19QQVJQT1JUX1BDPW0NCkNPTkZJR19QQVJQT1JUX1BD X0NNTDE9bQ0KIyBDT05GSUdfUEFSUE9SVF9TRVJJQUwgaXMgbm90IHNldA0K IyBDT05GSUdfUEFSUE9SVF9QQ19GSUZPIGlzIG5vdCBzZXQNCiMgQ09ORklH X1BBUlBPUlRfUENfU1VQRVJJTyBpcyBub3Qgc2V0DQojIENPTkZJR19QQVJQ T1JUX0FNSUdBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BBUlBPUlRfTUZDMyBp cyBub3Qgc2V0DQojIENPTkZJR19QQVJQT1JUX0FUQVJJIGlzIG5vdCBzZXQN CiMgQ09ORklHX1BBUlBPUlRfR1NDIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BB UlBPUlRfU1VOQlBQIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BBUlBPUlRfT1RI RVIgaXMgbm90IHNldA0KIyBDT05GSUdfUEFSUE9SVF8xMjg0IGlzIG5vdCBz ZXQNCg0KIw0KIyBQbHVnIGFuZCBQbGF5IGNvbmZpZ3VyYXRpb24NCiMNCkNP TkZJR19QTlA9eQ0KQ09ORklHX0lTQVBOUD1tDQoNCiMNCiMgQmxvY2sgZGV2 aWNlcw0KIw0KQ09ORklHX0JMS19ERVZfRkQ9bQ0KIyBDT05GSUdfQkxLX0RF Vl9YRCBpcyBub3Qgc2V0DQojIENPTkZJR19QQVJJREUgaXMgbm90IHNldA0K IyBDT05GSUdfQkxLX0NQUV9EQSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf Q1BRX0NJU1NfREEgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9EQUM5 NjAgaXMgbm90IHNldA0KQ09ORklHX0JMS19ERVZfTE9PUD1tDQojIENPTkZJ R19CTEtfREVWX05CRCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1JB TSBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0lOSVRSRCBpcyBub3Qg c2V0DQoNCiMNCiMgTXVsdGktZGV2aWNlIHN1cHBvcnQgKFJBSUQgYW5kIExW TSkNCiMNCiMgQ09ORklHX01EIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19E RVZfTUQgaXMgbm90IHNldA0KIyBDT05GSUdfTURfTElORUFSIGlzIG5vdCBz ZXQNCiMgQ09ORklHX01EX1JBSUQwIGlzIG5vdCBzZXQNCiMgQ09ORklHX01E X1JBSUQxIGlzIG5vdCBzZXQNCiMgQ09ORklHX01EX1JBSUQ1IGlzIG5vdCBz ZXQNCiMgQ09ORklHX01EX01VTFRJUEFUSCBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX0xWTSBpcyBub3Qgc2V0DQoNCiMNCiMgTmV0d29ya2luZyBv cHRpb25zDQojDQpDT05GSUdfUEFDS0VUPXkNCkNPTkZJR19QQUNLRVRfTU1B UD15DQojIENPTkZJR19ORVRMSU5LX0RFViBpcyBub3Qgc2V0DQpDT05GSUdf TkVURklMVEVSPXkNCiMgQ09ORklHX05FVEZJTFRFUl9ERUJVRyBpcyBub3Qg c2V0DQpDT05GSUdfRklMVEVSPXkNCkNPTkZJR19VTklYPXkNCkNPTkZJR19J TkVUPXkNCiMgQ09ORklHX0lQX01VTFRJQ0FTVCBpcyBub3Qgc2V0DQpDT05G SUdfSVBfQURWQU5DRURfUk9VVEVSPXkNCkNPTkZJR19JUF9NVUxUSVBMRV9U QUJMRVM9eQ0KQ09ORklHX0lQX1JPVVRFX0ZXTUFSSz15DQpDT05GSUdfSVBf Uk9VVEVfTkFUPXkNCiMgQ09ORklHX0lQX1JPVVRFX01VTFRJUEFUSCBpcyBu b3Qgc2V0DQpDT05GSUdfSVBfUk9VVEVfVE9TPXkNCkNPTkZJR19JUF9ST1VU RV9WRVJCT1NFPXkNCiMgQ09ORklHX0lQX1JPVVRFX0xBUkdFX1RBQkxFUyBp cyBub3Qgc2V0DQojIENPTkZJR19JUF9QTlAgaXMgbm90IHNldA0KIyBDT05G SUdfTkVUX0lQSVAgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0lQR1JFIGlz IG5vdCBzZXQNCiMgQ09ORklHX0FSUEQgaXMgbm90IHNldA0KIyBDT05GSUdf SU5FVF9FQ04gaXMgbm90IHNldA0KQ09ORklHX1NZTl9DT09LSUVTPXkNCg0K Iw0KIyAgIElQOiBOZXRmaWx0ZXIgQ29uZmlndXJhdGlvbg0KIw0KQ09ORklH X0lQX05GX0NPTk5UUkFDSz1tDQpDT05GSUdfSVBfTkZfRlRQPW0NCkNPTkZJ R19JUF9ORl9JUkM9bQ0KQ09ORklHX0lQX05GX1FVRVVFPW0NCkNPTkZJR19J UF9ORl9JUFRBQkxFUz1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfTElNSVQ9bQ0K Q09ORklHX0lQX05GX01BVENIX01BQz1tDQpDT05GSUdfSVBfTkZfTUFUQ0hf TUFSSz1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfTVVMVElQT1JUPW0NCkNPTkZJ R19JUF9ORl9NQVRDSF9UT1M9bQ0KQ09ORklHX0lQX05GX01BVENIX0FIX0VT UD1tDQpDT05GSUdfSVBfTkZfTUFUQ0hfTEVOR1RIPW0NCkNPTkZJR19JUF9O Rl9NQVRDSF9UVEw9bQ0KQ09ORklHX0lQX05GX01BVENIX1RDUE1TUz1tDQpD T05GSUdfSVBfTkZfTUFUQ0hfU1RBVEU9bQ0KQ09ORklHX0lQX05GX01BVENI X1VOQ0xFQU49bQ0KQ09ORklHX0lQX05GX01BVENIX09XTkVSPW0NCkNPTkZJ R19JUF9ORl9GSUxURVI9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9SRUpFQ1Q9 bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9NSVJST1I9bQ0KQ09ORklHX0lQX05G X05BVD1tDQpDT05GSUdfSVBfTkZfTkFUX05FRURFRD15DQpDT05GSUdfSVBf TkZfVEFSR0VUX01BU1FVRVJBREU9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9S RURJUkVDVD1tDQpDT05GSUdfSVBfTkZfTkFUX1NOTVBfQkFTSUM9bQ0KQ09O RklHX0lQX05GX05BVF9JUkM9bQ0KQ09ORklHX0lQX05GX05BVF9GVFA9bQ0K Q09ORklHX0lQX05GX01BTkdMRT1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX1RP Uz1tDQpDT05GSUdfSVBfTkZfVEFSR0VUX01BUks9bQ0KQ09ORklHX0lQX05G X1RBUkdFVF9MT0c9bQ0KQ09ORklHX0lQX05GX1RBUkdFVF9UQ1BNU1M9bQ0K IyBDT05GSUdfSVBfTkZfQ09NUEFUX0lQQ0hBSU5TIGlzIG5vdCBzZXQNCiMg Q09ORklHX0lQX05GX0NPTVBBVF9JUEZXQURNIGlzIG5vdCBzZXQNCiMgQ09O RklHX0lQVjYgaXMgbm90IHNldA0KIyBDT05GSUdfS0hUVFBEIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0FUTSBpcyBub3Qgc2V0DQojIENPTkZJR19WTEFOXzgw MjFRIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lQWCBpcyBub3Qgc2V0DQojIENP TkZJR19BVEFMSyBpcyBub3Qgc2V0DQojIENPTkZJR19ERUNORVQgaXMgbm90 IHNldA0KIyBDT05GSUdfQlJJREdFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1gy NSBpcyBub3Qgc2V0DQojIENPTkZJR19MQVBCIGlzIG5vdCBzZXQNCiMgQ09O RklHX0xMQyBpcyBub3Qgc2V0DQojIENPTkZJR19ORVRfRElWRVJUIGlzIG5v dCBzZXQNCiMgQ09ORklHX0VDT05FVCBpcyBub3Qgc2V0DQojIENPTkZJR19X QU5fUk9VVEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX05FVF9GQVNUUk9VVEUg aXMgbm90IHNldA0KIyBDT05GSUdfTkVUX0hXX0ZMT1dDT05UUk9MIGlzIG5v dCBzZXQNCg0KIw0KIyBRb1MgYW5kL29yIGZhaXIgcXVldWVpbmcNCiMNCiMg Q09ORklHX05FVF9TQ0hFRCBpcyBub3Qgc2V0DQoNCiMNCiMgVGVsZXBob255 IFN1cHBvcnQNCiMNCiMgQ09ORklHX1BIT05FIGlzIG5vdCBzZXQNCiMgQ09O RklHX1BIT05FX0lYSiBpcyBub3Qgc2V0DQojIENPTkZJR19QSE9ORV9JWEpf UENNQ0lBIGlzIG5vdCBzZXQNCg0KIw0KIyBBVEEvSURFL01GTS9STEwgc3Vw cG9ydA0KIw0KQ09ORklHX0lERT15DQoNCiMNCiMgSURFLCBBVEEgYW5kIEFU QVBJIEJsb2NrIGRldmljZXMNCiMNCkNPTkZJR19CTEtfREVWX0lERT15DQoj IENPTkZJR19CTEtfREVWX0hEX0lERSBpcyBub3Qgc2V0DQojIENPTkZJR19C TEtfREVWX0hEIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERURJU0s9 eQ0KIyBDT05GSUdfSURFRElTS19NVUxUSV9NT0RFIGlzIG5vdCBzZXQNCiMg Q09ORklHX0JMS19ERVZfSURFRElTS19WRU5ET1IgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9JREVESVNLX0ZVSklUU1UgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9JREVESVNLX0lCTSBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX0lERURJU0tfTUFYVE9SIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfSURFRElTS19RVUFOVFVNIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfSURFRElTS19TRUFHQVRFIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfSURFRElTS19XRCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtf REVWX0NPTU1FUklBTCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX1RJ Vk8gaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVDUyBpcyBub3Qg c2V0DQpDT05GSUdfQkxLX0RFVl9JREVDRD1tDQojIENPTkZJR19CTEtfREVW X0lERVRBUEUgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVGTE9Q UFkgaXMgbm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9JREVTQ1NJIGlzIG5v dCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ01ENjQwIGlzIG5vdCBzZXQNCiMg Q09ORklHX0JMS19ERVZfQ01ENjQwX0VOSEFOQ0VEIGlzIG5vdCBzZXQNCiMg Q09ORklHX0JMS19ERVZfSVNBUE5QIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19ERVZfUloxMDAwIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERVBD ST15DQojIENPTkZJR19JREVQQ0lfU0hBUkVfSVJRIGlzIG5vdCBzZXQNCkNP TkZJR19CTEtfREVWX0lERURNQV9QQ0k9eQ0KQ09ORklHX0JMS19ERVZfQURN QT15DQojIENPTkZJR19CTEtfREVWX09GRkJPQVJEIGlzIG5vdCBzZXQNCkNP TkZJR19JREVETUFfUENJX0FVVE89eQ0KQ09ORklHX0JMS19ERVZfSURFRE1B PXkNCiMgQ09ORklHX0lERURNQV9QQ0lfV0lQIGlzIG5vdCBzZXQNCiMgQ09O RklHX0lERURNQV9ORVdfRFJJVkVfTElTVElOR1MgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9BRUM2MlhYIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FF QzYyWFhfVFVOSU5HIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQUxJ MTVYMyBpcyBub3Qgc2V0DQojIENPTkZJR19XRENfQUxJMTVYMyBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX0FNRDc0WFggaXMgbm90IHNldA0KIyBD T05GSUdfQU1ENzRYWF9PVkVSUklERSBpcyBub3Qgc2V0DQojIENPTkZJR19C TEtfREVWX0NNRDY0WCBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVWX0NZ ODJDNjkzIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfQ1M1NTMwIGlz IG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZfSFBUMzRYIGlzIG5vdCBzZXQN CiMgQ09ORklHX0hQVDM0WF9BVVRPRE1BIGlzIG5vdCBzZXQNCiMgQ09ORklH X0JMS19ERVZfSFBUMzY2IGlzIG5vdCBzZXQNCiMgQ09ORklHX0JMS19ERVZf UElJWCBpcyBub3Qgc2V0DQojIENPTkZJR19QSUlYX1RVTklORyBpcyBub3Qg c2V0DQojIENPTkZJR19CTEtfREVWX05TODc0MTUgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9PUFRJNjIxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JM S19ERVZfUERDMjAyWFggaXMgbm90IHNldA0KIyBDT05GSUdfUERDMjAyWFhf QlVSU1QgaXMgbm90IHNldA0KIyBDT05GSUdfUERDMjAyWFhfRk9SQ0UgaXMg bm90IHNldA0KIyBDT05GSUdfQkxLX0RFVl9TVldLUyBpcyBub3Qgc2V0DQoj IENPTkZJR19CTEtfREVWX1NJUzU1MTMgaXMgbm90IHNldA0KIyBDT05GSUdf QkxLX0RFVl9TTEM5MEU2NiBpcyBub3Qgc2V0DQojIENPTkZJR19CTEtfREVW X1RSTTI5MCBpcyBub3Qgc2V0DQpDT05GSUdfQkxLX0RFVl9WSUE4MkNYWFg9 eQ0KIyBDT05GSUdfSURFX0NISVBTRVRTIGlzIG5vdCBzZXQNCkNPTkZJR19J REVETUFfQVVUTz15DQpDT05GSUdfSURFRE1BX0lWQj15DQojIENPTkZJR19E TUFfTk9OUENJIGlzIG5vdCBzZXQNCkNPTkZJR19CTEtfREVWX0lERV9NT0RF Uz15DQojIENPTkZJR19CTEtfREVWX0FUQVJBSUQgaXMgbm90IHNldA0KIyBD T05GSUdfQkxLX0RFVl9BVEFSQUlEX1BEQyBpcyBub3Qgc2V0DQojIENPTkZJ R19CTEtfREVWX0FUQVJBSURfSFBUIGlzIG5vdCBzZXQNCg0KIw0KIyBTQ1NJ IHN1cHBvcnQNCiMNCiMgQ09ORklHX1NDU0kgaXMgbm90IHNldA0KDQojDQoj IEZ1c2lvbiBNUFQgZGV2aWNlIHN1cHBvcnQNCiMNCiMgQ09ORklHX0ZVU0lP TiBpcyBub3Qgc2V0DQojIENPTkZJR19GVVNJT05fQk9PVCBpcyBub3Qgc2V0 DQojIENPTkZJR19GVVNJT05fSVNFTlNFIGlzIG5vdCBzZXQNCiMgQ09ORklH X0ZVU0lPTl9DVEwgaXMgbm90IHNldA0KIyBDT05GSUdfRlVTSU9OX0xBTiBp cyBub3Qgc2V0DQoNCiMNCiMgSUVFRSAxMzk0IChGaXJlV2lyZSkgc3VwcG9y dCAoRVhQRVJJTUVOVEFMKQ0KIw0KIyBDT05GSUdfSUVFRTEzOTQgaXMgbm90 IHNldA0KDQojDQojIEkyTyBkZXZpY2Ugc3VwcG9ydA0KIw0KIyBDT05GSUdf STJPIGlzIG5vdCBzZXQNCiMgQ09ORklHX0kyT19QQ0kgaXMgbm90IHNldA0K IyBDT05GSUdfSTJPX0JMT0NLIGlzIG5vdCBzZXQNCiMgQ09ORklHX0kyT19M QU4gaXMgbm90IHNldA0KIyBDT05GSUdfSTJPX1NDU0kgaXMgbm90IHNldA0K IyBDT05GSUdfSTJPX1BST0MgaXMgbm90IHNldA0KDQojDQojIE5ldHdvcmsg ZGV2aWNlIHN1cHBvcnQNCiMNCkNPTkZJR19ORVRERVZJQ0VTPXkNCg0KIw0K IyBBUkNuZXQgZGV2aWNlcw0KIw0KIyBDT05GSUdfQVJDTkVUIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0RVTU1ZIGlzIG5vdCBzZXQNCiMgQ09ORklHX0JPTkRJ TkcgaXMgbm90IHNldA0KIyBDT05GSUdfRVFVQUxJWkVSIGlzIG5vdCBzZXQN CiMgQ09ORklHX1RVTiBpcyBub3Qgc2V0DQojIENPTkZJR19FVEhFUlRBUCBp cyBub3Qgc2V0DQojIENPTkZJR19ORVRfU0IxMDAwIGlzIG5vdCBzZXQNCg0K Iw0KIyBFdGhlcm5ldCAoMTAgb3IgMTAwTWJpdCkNCiMNCkNPTkZJR19ORVRf RVRIRVJORVQ9eQ0KIyBDT05GSUdfU1VOTEFOQ0UgaXMgbm90IHNldA0KIyBD T05GSUdfSEFQUFlNRUFMIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NVTkJNQUMg aXMgbm90IHNldA0KIyBDT05GSUdfU1VOUUUgaXMgbm90IHNldA0KIyBDT05G SUdfU1VOR0VNIGlzIG5vdCBzZXQNCkNPTkZJR19ORVRfVkVORE9SXzNDT009 eQ0KIyBDT05GSUdfRUwxIGlzIG5vdCBzZXQNCiMgQ09ORklHX0VMMiBpcyBu b3Qgc2V0DQojIENPTkZJR19FTFBMVVMgaXMgbm90IHNldA0KIyBDT05GSUdf RUwxNiBpcyBub3Qgc2V0DQojIENPTkZJR19FTDMgaXMgbm90IHNldA0KIyBD T05GSUdfM0M1MTUgaXMgbm90IHNldA0KIyBDT05GSUdfRUxNQyBpcyBub3Qg c2V0DQojIENPTkZJR19FTE1DX0lJIGlzIG5vdCBzZXQNCkNPTkZJR19WT1JU RVg9bQ0KIyBDT05GSUdfTEFOQ0UgaXMgbm90IHNldA0KIyBDT05GSUdfTkVU X1ZFTkRPUl9TTUMgaXMgbm90IHNldA0KIyBDT05GSUdfTkVUX1ZFTkRPUl9S QUNBTCBpcyBub3Qgc2V0DQojIENPTkZJR19BVDE3MDAgaXMgbm90IHNldA0K IyBDT05GSUdfREVQQ0EgaXMgbm90IHNldA0KIyBDT05GSUdfSFAxMDAgaXMg bm90IHNldA0KIyBDT05GSUdfTkVUX0lTQSBpcyBub3Qgc2V0DQpDT05GSUdf TkVUX1BDST15DQojIENPTkZJR19QQ05FVDMyIGlzIG5vdCBzZXQNCiMgQ09O RklHX0FEQVBURUNfU1RBUkZJUkUgaXMgbm90IHNldA0KIyBDT05GSUdfQUMz MjAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FQUklDT1QgaXMgbm90IHNldA0K IyBDT05GSUdfQ1M4OXgwIGlzIG5vdCBzZXQNCkNPTkZJR19UVUxJUD1tDQoj IENPTkZJR19UVUxJUF9NV0kgaXMgbm90IHNldA0KIyBDT05GSUdfVFVMSVBf TU1JTyBpcyBub3Qgc2V0DQojIENPTkZJR19ERTRYNSBpcyBub3Qgc2V0DQoj IENPTkZJR19ER1JTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RNOTEwMiBpcyBu b3Qgc2V0DQojIENPTkZJR19FRVBSTzEwMCBpcyBub3Qgc2V0DQojIENPTkZJ R19MTkUzOTAgaXMgbm90IHNldA0KIyBDT05GSUdfRkVBTE5YIGlzIG5vdCBz ZXQNCiMgQ09ORklHX05BVFNFTUkgaXMgbm90IHNldA0KIyBDT05GSUdfTkUy S19QQ0kgaXMgbm90IHNldA0KIyBDT05GSUdfTkUzMjEwIGlzIG5vdCBzZXQN CiMgQ09ORklHX0VTMzIxMCBpcyBub3Qgc2V0DQojIENPTkZJR184MTM5Q1Ag aXMgbm90IHNldA0KIyBDT05GSUdfODEzOVRPTyBpcyBub3Qgc2V0DQojIENP TkZJR184MTM5VE9PX1BJTyBpcyBub3Qgc2V0DQojIENPTkZJR184MTM5VE9P X1RVTkVfVFdJU1RFUiBpcyBub3Qgc2V0DQojIENPTkZJR184MTM5VE9PXzgx MjkgaXMgbm90IHNldA0KIyBDT05GSUdfODEzOV9ORVdfUlhfUkVTRVQgaXMg bm90IHNldA0KIyBDT05GSUdfU0lTOTAwIGlzIG5vdCBzZXQNCiMgQ09ORklH X0VQSUMxMDAgaXMgbm90IHNldA0KIyBDT05GSUdfU1VOREFOQ0UgaXMgbm90 IHNldA0KIyBDT05GSUdfVExBTiBpcyBub3Qgc2V0DQojIENPTkZJR19WSUFf UkhJTkUgaXMgbm90IHNldA0KIyBDT05GSUdfVklBX1JISU5FX01NSU8gaXMg bm90IHNldA0KIyBDT05GSUdfV0lOQk9ORF84NDAgaXMgbm90IHNldA0KIyBD T05GSUdfTkVUX1BPQ0tFVCBpcyBub3Qgc2V0DQoNCiMNCiMgRXRoZXJuZXQg KDEwMDAgTWJpdCkNCiMNCiMgQ09ORklHX0FDRU5JQyBpcyBub3Qgc2V0DQoj IENPTkZJR19ETDJLIGlzIG5vdCBzZXQNCiMgQ09ORklHX01ZUklfU0JVUyBp cyBub3Qgc2V0DQojIENPTkZJR19OUzgzODIwIGlzIG5vdCBzZXQNCiMgQ09O RklHX0hBTUFDSEkgaXMgbm90IHNldA0KIyBDT05GSUdfWUVMTE9XRklOIGlz IG5vdCBzZXQNCiMgQ09ORklHX1NLOThMSU4gaXMgbm90IHNldA0KIyBDT05G SUdfRkRESSBpcyBub3Qgc2V0DQojIENPTkZJR19ISVBQSSBpcyBub3Qgc2V0 DQojIENPTkZJR19QTElQIGlzIG5vdCBzZXQNCkNPTkZJR19QUFA9bQ0KQ09O RklHX1BQUF9NVUxUSUxJTks9eQ0KIyBDT05GSUdfUFBQX0ZJTFRFUiBpcyBu b3Qgc2V0DQpDT05GSUdfUFBQX0FTWU5DPW0NCkNPTkZJR19QUFBfU1lOQ19U VFk9bQ0KQ09ORklHX1BQUF9ERUZMQVRFPW0NCkNPTkZJR19QUFBfQlNEQ09N UD1tDQojIENPTkZJR19QUFBPRSBpcyBub3Qgc2V0DQojIENPTkZJR19TTElQ IGlzIG5vdCBzZXQNCg0KIw0KIyBXaXJlbGVzcyBMQU4gKG5vbi1oYW1yYWRp bykNCiMNCiMgQ09ORklHX05FVF9SQURJTyBpcyBub3Qgc2V0DQoNCiMNCiMg VG9rZW4gUmluZyBkZXZpY2VzDQojDQojIENPTkZJR19UUiBpcyBub3Qgc2V0 DQojIENPTkZJR19ORVRfRkMgaXMgbm90IHNldA0KIyBDT05GSUdfUkNQQ0kg aXMgbm90IHNldA0KIyBDT05GSUdfU0hBUEVSIGlzIG5vdCBzZXQNCg0KIw0K IyBXYW4gaW50ZXJmYWNlcw0KIw0KIyBDT05GSUdfV0FOIGlzIG5vdCBzZXQN Cg0KIw0KIyBBbWF0ZXVyIFJhZGlvIHN1cHBvcnQNCiMNCiMgQ09ORklHX0hB TVJBRElPIGlzIG5vdCBzZXQNCg0KIw0KIyBJckRBIChpbmZyYXJlZCkgc3Vw cG9ydA0KIw0KIyBDT05GSUdfSVJEQSBpcyBub3Qgc2V0DQoNCiMNCiMgSVNE TiBzdWJzeXN0ZW0NCiMNCiMgQ09ORklHX0lTRE4gaXMgbm90IHNldA0KDQoj DQojIE9sZCBDRC1ST00gZHJpdmVycyAobm90IFNDU0ksIG5vdCBJREUpDQoj DQojIENPTkZJR19DRF9OT19JREVTQ1NJIGlzIG5vdCBzZXQNCg0KIw0KIyBJ bnB1dCBjb3JlIHN1cHBvcnQNCiMNCiMgQ09ORklHX0lOUFVUIGlzIG5vdCBz ZXQNCiMgQ09ORklHX0lOUFVUX0tFWUJERVYgaXMgbm90IHNldA0KIyBDT05G SUdfSU5QVVRfTU9VU0VERVYgaXMgbm90IHNldA0KIyBDT05GSUdfSU5QVVRf Sk9ZREVWIGlzIG5vdCBzZXQNCiMgQ09ORklHX0lOUFVUX0VWREVWIGlzIG5v dCBzZXQNCg0KIw0KIyBDaGFyYWN0ZXIgZGV2aWNlcw0KIw0KQ09ORklHX1ZU PXkNCkNPTkZJR19WVF9DT05TT0xFPXkNCkNPTkZJR19TRVJJQUw9eQ0KIyBD T05GSUdfU0VSSUFMX0NPTlNPTEUgaXMgbm90IHNldA0KIyBDT05GSUdfU0VS SUFMX0VYVEVOREVEIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NFUklBTF9OT05T VEFOREFSRCBpcyBub3Qgc2V0DQpDT05GSUdfVU5JWDk4X1BUWVM9eQ0KQ09O RklHX1VOSVg5OF9QVFlfQ09VTlQ9MjU2DQpDT05GSUdfUFJJTlRFUj1tDQoj IENPTkZJR19MUF9DT05TT0xFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1BQREVW IGlzIG5vdCBzZXQNCg0KIw0KIyBJMkMgc3VwcG9ydA0KIw0KIyBDT05GSUdf STJDIGlzIG5vdCBzZXQNCg0KIw0KIyBNaWNlDQojDQojIENPTkZJR19CVVNN T1VTRSBpcyBub3Qgc2V0DQpDT05GSUdfTU9VU0U9bQ0KQ09ORklHX1BTTU9V U0U9eQ0KIyBDT05GSUdfODJDNzEwX01PVVNFIGlzIG5vdCBzZXQNCiMgQ09O RklHX1BDMTEwX1BBRCBpcyBub3Qgc2V0DQoNCiMNCiMgSm95c3RpY2tzDQoj DQojIENPTkZJR19JTlBVVF9HQU1FUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJ R19RSUMwMl9UQVBFIGlzIG5vdCBzZXQNCg0KIw0KIyBXYXRjaGRvZyBDYXJk cw0KIw0KIyBDT05GSUdfV0FUQ0hET0cgaXMgbm90IHNldA0KIyBDT05GSUdf SU5URUxfUk5HIGlzIG5vdCBzZXQNCiMgQ09ORklHX05WUkFNIGlzIG5vdCBz ZXQNCkNPTkZJR19SVEM9eQ0KIyBDT05GSUdfRFRMSyBpcyBub3Qgc2V0DQoj IENPTkZJR19SMzk2NCBpcyBub3Qgc2V0DQojIENPTkZJR19BUFBMSUNPTSBp cyBub3Qgc2V0DQojIENPTkZJR19TT05ZUEkgaXMgbm90IHNldA0KDQojDQoj IEZ0YXBlLCB0aGUgZmxvcHB5IHRhcGUgZGV2aWNlIGRyaXZlcg0KIw0KIyBD T05GSUdfRlRBUEUgaXMgbm90IHNldA0KQ09ORklHX0FHUD1tDQojIENPTkZJ R19BR1BfSU5URUwgaXMgbm90IHNldA0KIyBDT05GSUdfQUdQX0k4MTAgaXMg bm90IHNldA0KQ09ORklHX0FHUF9WSUE9eQ0KIyBDT05GSUdfQUdQX0FNRCBp cyBub3Qgc2V0DQojIENPTkZJR19BR1BfU0lTIGlzIG5vdCBzZXQNCiMgQ09O RklHX0FHUF9BTEkgaXMgbm90IHNldA0KIyBDT05GSUdfQUdQX1NXT1JLUyBp cyBub3Qgc2V0DQojIENPTkZJR19EUk0gaXMgbm90IHNldA0KIyBDT05GSUdf TVdBVkUgaXMgbm90IHNldA0KDQojDQojIE11bHRpbWVkaWEgZGV2aWNlcw0K Iw0KIyBDT05GSUdfVklERU9fREVWIGlzIG5vdCBzZXQNCg0KIw0KIyBGaWxl IHN5c3RlbXMNCiMNCkNPTkZJR19GU19QT1NJWF9BQ0w9eQ0KQ09ORklHX1FV T1RBPXkNCiMgQ09ORklHX1FGTVRfVjEgaXMgbm90IHNldA0KIyBDT05GSUdf UUZNVF9WMiBpcyBub3Qgc2V0DQojIENPTkZJR19RSUZBQ0VfQ09NUEFUIGlz IG5vdCBzZXQNCiMgQ09ORklHX0FVVE9GU19GUyBpcyBub3Qgc2V0DQojIENP TkZJR19BVVRPRlM0X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFSVNFUkZT X0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1JFSVNFUkZTX0NIRUNLIGlzIG5v dCBzZXQNCiMgQ09ORklHX1JFSVNFUkZTX1BST0NfSU5GTyBpcyBub3Qgc2V0 DQojIENPTkZJR19BREZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FERlNf RlNfUlcgaXMgbm90IHNldA0KIyBDT05GSUdfQUZGU19GUyBpcyBub3Qgc2V0 DQojIENPTkZJR19IRlNfRlMgaXMgbm90IHNldA0KIyBDT05GSUdfQkZTX0ZT IGlzIG5vdCBzZXQNCkNPTkZJR19FWFQzX0ZTPXkNCkNPTkZJR19KQkQ9eQ0K IyBDT05GSUdfSkJEX0RFQlVHIGlzIG5vdCBzZXQNCkNPTkZJR19GQVRfRlM9 bQ0KQ09ORklHX01TRE9TX0ZTPW0NCiMgQ09ORklHX1VNU0RPU19GUyBpcyBu b3Qgc2V0DQpDT05GSUdfVkZBVF9GUz1tDQojIENPTkZJR19FRlNfRlMgaXMg bm90IHNldA0KIyBDT05GSUdfSkZGU19GUyBpcyBub3Qgc2V0DQojIENPTkZJ R19KRkZTMl9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19DUkFNRlMgaXMgbm90 IHNldA0KQ09ORklHX1RNUEZTPXkNCiMgQ09ORklHX1JBTUZTIGlzIG5vdCBz ZXQNCkNPTkZJR19JU085NjYwX0ZTPW0NCkNPTkZJR19KT0xJRVQ9eQ0KIyBD T05GSUdfWklTT0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX01JTklYX0ZTIGlz IG5vdCBzZXQNCiMgQ09ORklHX1ZYRlNfRlMgaXMgbm90IHNldA0KQ09ORklH X05URlNfRlM9bQ0KIyBDT05GSUdfTlRGU19SVyBpcyBub3Qgc2V0DQojIENP TkZJR19IUEZTX0ZTIGlzIG5vdCBzZXQNCkNPTkZJR19QUk9DX0ZTPXkNCiMg Q09ORklHX0RFVkZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFVkZTX01P VU5UIGlzIG5vdCBzZXQNCiMgQ09ORklHX0RFVkZTX0RFQlVHIGlzIG5vdCBz ZXQNCkNPTkZJR19ERVZQVFNfRlM9eQ0KIyBDT05GSUdfUU5YNEZTX0ZTIGlz IG5vdCBzZXQNCiMgQ09ORklHX1FOWDRGU19SVyBpcyBub3Qgc2V0DQojIENP TkZJR19ST01GU19GUyBpcyBub3Qgc2V0DQpDT05GSUdfRVhUMl9GUz15DQoj IENPTkZJR19TWVNWX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VERl9GUyBp cyBub3Qgc2V0DQojIENPTkZJR19VREZfUlcgaXMgbm90IHNldA0KIyBDT05G SUdfVUZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VGU19GU19XUklURSBp cyBub3Qgc2V0DQpDT05GSUdfWEZTX0ZTPXkNCkNPTkZJR19YRlNfUlQ9eQ0K Q09ORklHX1hGU19RVU9UQT15DQpDT05GSUdfWEZTX0RNQVBJPXkNCkNPTkZJ R19IQVZFX1hGU19ETUFQST15DQoNCiMNCiMgTmV0d29yayBGaWxlIFN5c3Rl bXMNCiMNCiMgQ09ORklHX0NPREFfRlMgaXMgbm90IHNldA0KIyBDT05GSUdf SU5URVJNRVpaT19GUyBpcyBub3Qgc2V0DQpDT05GSUdfTkZTX0ZTPW0NCkNP TkZJR19ORlNfVjM9eQ0KIyBDT05GSUdfUk9PVF9ORlMgaXMgbm90IHNldA0K Q09ORklHX05GU0Q9bQ0KQ09ORklHX05GU0RfVjM9eQ0KQ09ORklHX1NVTlJQ Qz1tDQpDT05GSUdfTE9DS0Q9bQ0KQ09ORklHX0xPQ0tEX1Y0PXkNCkNPTkZJ R19TTUJfRlM9bQ0KIyBDT05GSUdfU01CX05MU19ERUZBVUxUIGlzIG5vdCBz ZXQNCiMgQ09ORklHX05DUF9GUyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BG U19QQUNLRVRfU0lHTklORyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19J T0NUTF9MT0NLSU5HIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX1NUUk9O RyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19ORlNfTlMgaXMgbm90IHNl dA0KIyBDT05GSUdfTkNQRlNfT1MyX05TIGlzIG5vdCBzZXQNCiMgQ09ORklH X05DUEZTX1NNQUxMRE9TIGlzIG5vdCBzZXQNCiMgQ09ORklHX05DUEZTX05M UyBpcyBub3Qgc2V0DQojIENPTkZJR19OQ1BGU19FWFRSQVMgaXMgbm90IHNl dA0KIyBDT05GSUdfWklTT0ZTX0ZTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1pM SUJfRlNfSU5GTEFURSBpcyBub3Qgc2V0DQoNCiMNCiMgUGFydGl0aW9uIFR5 cGVzDQojDQpDT05GSUdfUEFSVElUSU9OX0FEVkFOQ0VEPXkNCiMgQ09ORklH X0FDT1JOX1BBUlRJVElPTiBpcyBub3Qgc2V0DQojIENPTkZJR19PU0ZfUEFS VElUSU9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX0FNSUdBX1BBUlRJVElPTiBp cyBub3Qgc2V0DQojIENPTkZJR19BVEFSSV9QQVJUSVRJT04gaXMgbm90IHNl dA0KIyBDT05GSUdfTUFDX1BBUlRJVElPTiBpcyBub3Qgc2V0DQpDT05GSUdf TVNET1NfUEFSVElUSU9OPXkNCiMgQ09ORklHX0JTRF9ESVNLTEFCRUwgaXMg bm90IHNldA0KIyBDT05GSUdfTUlOSVhfU1VCUEFSVElUSU9OIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1NPTEFSSVNfWDg2X1BBUlRJVElPTiBpcyBub3Qgc2V0 DQojIENPTkZJR19VTklYV0FSRV9ESVNLTEFCRUwgaXMgbm90IHNldA0KIyBD T05GSUdfTERNX1BBUlRJVElPTiBpcyBub3Qgc2V0DQojIENPTkZJR19TR0lf UEFSVElUSU9OIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VMVFJJWF9QQVJUSVRJ T04gaXMgbm90IHNldA0KIyBDT05GSUdfU1VOX1BBUlRJVElPTiBpcyBub3Qg c2V0DQpDT05GSUdfU01CX05MUz15DQpDT05GSUdfTkxTPXkNCg0KIw0KIyBO YXRpdmUgTGFuZ3VhZ2UgU3VwcG9ydA0KIw0KQ09ORklHX05MU19ERUZBVUxU PSJpc284ODU5LTEiDQojIENPTkZJR19OTFNfQ09ERVBBR0VfNDM3IGlzIG5v dCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV83MzcgaXMgbm90IHNldA0K IyBDT05GSUdfTkxTX0NPREVQQUdFXzc3NSBpcyBub3Qgc2V0DQojIENPTkZJ R19OTFNfQ09ERVBBR0VfODUwIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19D T0RFUEFHRV84NTIgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdF Xzg1NSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODU3IGlz IG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjAgaXMgbm90IHNl dA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2MSBpcyBub3Qgc2V0DQojIENP TkZJR19OTFNfQ09ERVBBR0VfODYyIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M U19DT0RFUEFHRV84NjMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NPREVQ QUdFXzg2NCBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0VfODY1 IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NjYgaXMgbm90 IHNldA0KIyBDT05GSUdfTkxTX0NPREVQQUdFXzg2OSBpcyBub3Qgc2V0DQoj IENPTkZJR19OTFNfQ09ERVBBR0VfOTM2IGlzIG5vdCBzZXQNCiMgQ09ORklH X05MU19DT0RFUEFHRV85NTAgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0NP REVQQUdFXzkzMiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfQ09ERVBBR0Vf OTQ5IGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19DT0RFUEFHRV84NzQgaXMg bm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfOCBpcyBub3Qgc2V0DQoj IENPTkZJR19OTFNfQ09ERVBBR0VfMTI1MCBpcyBub3Qgc2V0DQojIENPTkZJ R19OTFNfQ09ERVBBR0VfMTI1MSBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNf SVNPODg1OV8xIGlzIG5vdCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzIg aXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlfMyBpcyBub3Qgc2V0 DQojIENPTkZJR19OTFNfSVNPODg1OV80IGlzIG5vdCBzZXQNCiMgQ09ORklH X05MU19JU084ODU5XzUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4 NTlfNiBpcyBub3Qgc2V0DQojIENPTkZJR19OTFNfSVNPODg1OV83IGlzIG5v dCBzZXQNCiMgQ09ORklHX05MU19JU084ODU5XzkgaXMgbm90IHNldA0KIyBD T05GSUdfTkxTX0lTTzg4NTlfMTMgaXMgbm90IHNldA0KIyBDT05GSUdfTkxT X0lTTzg4NTlfMTQgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0lTTzg4NTlf MTUgaXMgbm90IHNldA0KIyBDT05GSUdfTkxTX0tPSThfUiBpcyBub3Qgc2V0 DQojIENPTkZJR19OTFNfS09JOF9VIGlzIG5vdCBzZXQNCiMgQ09ORklHX05M U19VVEY4IGlzIG5vdCBzZXQNCg0KIw0KIyBDb25zb2xlIGRyaXZlcnMNCiMN CkNPTkZJR19WR0FfQ09OU09MRT15DQpDT05GSUdfVklERU9fU0VMRUNUPXkN CiMgQ09ORklHX01EQV9DT05TT0xFIGlzIG5vdCBzZXQNCg0KIw0KIyBGcmFt ZS1idWZmZXIgc3VwcG9ydA0KIw0KQ09ORklHX0ZCPXkNCkNPTkZJR19EVU1N WV9DT05TT0xFPXkNCiMgQ09ORklHX0ZCX1JJVkEgaXMgbm90IHNldA0KIyBD T05GSUdfRkJfQ0xHRU4gaXMgbm90IHNldA0KIyBDT05GSUdfRkJfUE0yIGlz IG5vdCBzZXQNCiMgQ09ORklHX0ZCX0NZQkVSMjAwMCBpcyBub3Qgc2V0DQpD T05GSUdfRkJfVkVTQT15DQojIENPTkZJR19GQl9WR0ExNiBpcyBub3Qgc2V0 DQojIENPTkZJR19GQl9IR0EgaXMgbm90IHNldA0KQ09ORklHX1ZJREVPX1NF TEVDVD15DQojIENPTkZJR19GQl9NQVRST1ggaXMgbm90IHNldA0KIyBDT05G SUdfRkJfQVRZIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZCX1JBREVPTiBpcyBu b3Qgc2V0DQojIENPTkZJR19GQl9BVFkxMjggaXMgbm90IHNldA0KIyBDT05G SUdfRkJfU0lTIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZCXzNERlggaXMgbm90 IHNldA0KIyBDT05GSUdfRkJfVk9PRE9PMSBpcyBub3Qgc2V0DQojIENPTkZJ R19GQl9UUklERU5UIGlzIG5vdCBzZXQNCiMgQ09ORklHX0ZCX1ZJUlRVQUwg aXMgbm90IHNldA0KIyBDT05GSUdfRkJDT05fQURWQU5DRUQgaXMgbm90IHNl dA0KQ09ORklHX0ZCQ09OX0NGQjg9eQ0KQ09ORklHX0ZCQ09OX0NGQjE2PXkN CkNPTkZJR19GQkNPTl9DRkIyND15DQpDT05GSUdfRkJDT05fQ0ZCMzI9eQ0K IyBDT05GSUdfRkJDT05fRk9OVFdJRFRIOF9PTkxZIGlzIG5vdCBzZXQNCiMg Q09ORklHX0ZCQ09OX0ZPTlRTIGlzIG5vdCBzZXQNCkNPTkZJR19GT05UXzh4 OD15DQpDT05GSUdfRk9OVF84eDE2PXkNCg0KIw0KIyBTb3VuZA0KIw0KQ09O RklHX1NPVU5EPW0NCiMgQ09ORklHX1NPVU5EX0JUODc4IGlzIG5vdCBzZXQN CiMgQ09ORklHX1NPVU5EX0NNUENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NP VU5EX0VNVTEwSzEgaXMgbm90IHNldA0KIyBDT05GSUdfTUlESV9FTVUxMEsx IGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX0ZVU0lPTiBpcyBub3Qgc2V0 DQojIENPTkZJR19TT1VORF9DUzQyODEgaXMgbm90IHNldA0KIyBDT05GSUdf U09VTkRfRVMxMzcwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX0VTMTM3 MSBpcyBub3Qgc2V0DQojIENPTkZJR19TT1VORF9FU1NTT0xPMSBpcyBub3Qg c2V0DQojIENPTkZJR19TT1VORF9NQUVTVFJPIGlzIG5vdCBzZXQNCkNPTkZJ R19TT1VORF9NQUVTVFJPMz1tDQojIENPTkZJR19TT1VORF9JQ0ggaXMgbm90 IHNldA0KIyBDT05GSUdfU09VTkRfUk1FOTZYWCBpcyBub3Qgc2V0DQojIENP TkZJR19TT1VORF9TT05JQ1ZJQkVTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NP VU5EX1RSSURFTlQgaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfTVNORENM QVMgaXMgbm90IHNldA0KIyBDT05GSUdfU09VTkRfTVNORFBJTiBpcyBub3Qg c2V0DQojIENPTkZJR19TT1VORF9WSUE4MkNYWFggaXMgbm90IHNldA0KIyBD T05GSUdfTUlESV9WSUE4MkNYWFggaXMgbm90IHNldA0KIyBDT05GSUdfU09V TkRfT1NTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1NPVU5EX1RWTUlYRVIgaXMg bm90IHNldA0KDQojDQojIFVTQiBzdXBwb3J0DQojDQojIENPTkZJR19VU0Ig aXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1VIQ0kgaXMgbm90IHNldA0KIyBD T05GSUdfVVNCX1VIQ0lfQUxUIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9P SENJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9BVURJTyBpcyBub3Qgc2V0 DQojIENPTkZJR19VU0JfQkxVRVRPT1RIIGlzIG5vdCBzZXQNCiMgQ09ORklH X1VTQl9TVE9SQUdFIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdF X0RFQlVHIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TVE9SQUdFX0RBVEFG QUIgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfRlJFRUNPTSBp cyBub3Qgc2V0DQojIENPTkZJR19VU0JfU1RPUkFHRV9JU0QyMDAgaXMgbm90 IHNldA0KIyBDT05GSUdfVVNCX1NUT1JBR0VfRFBDTSBpcyBub3Qgc2V0DQoj IENPTkZJR19VU0JfU1RPUkFHRV9IUDgyMDBlIGlzIG5vdCBzZXQNCiMgQ09O RklHX1VTQl9TVE9SQUdFX1NERFIwOSBpcyBub3Qgc2V0DQojIENPTkZJR19V U0JfU1RPUkFHRV9KVU1QU0hPVCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0Jf QUNNIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9QUklOVEVSIGlzIG5vdCBz ZXQNCiMgQ09ORklHX1VTQl9EQzJYWCBpcyBub3Qgc2V0DQojIENPTkZJR19V U0JfTURDODAwIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TQ0FOTkVSIGlz IG5vdCBzZXQNCiMgQ09ORklHX1VTQl9NSUNST1RFSyBpcyBub3Qgc2V0DQoj IENPTkZJR19VU0JfSFBVU0JTQ1NJIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VT Ql9QRUdBU1VTIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9LQVdFVEggaXMg bm90IHNldA0KIyBDT05GSUdfVVNCX0NBVEMgaXMgbm90IHNldA0KIyBDT05G SUdfVVNCX0NEQ0VUSEVSIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9VU0JO RVQgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1VTUzcyMCBpcyBub3Qgc2V0 DQoNCiMNCiMgVVNCIFNlcmlhbCBDb252ZXJ0ZXIgc3VwcG9ydA0KIw0KIyBD T05GSUdfVVNCX1NFUklBTCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VS SUFMX0dFTkVSSUMgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9C RUxLSU4gaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9XSElURUhF QVQgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9ESUdJX0FDQ0VM RVBPUlQgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9FTVBFRyBp cyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0ZURElfU0lPIGlzIG5v dCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfVklTT1IgaXMgbm90IHNldA0K IyBDT05GSUdfVVNCX1NFUklBTF9JUEFRIGlzIG5vdCBzZXQNCiMgQ09ORklH X1VTQl9TRVJJQUxfSVIgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklB TF9FREdFUE9SVCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tF WVNQQU5fUERBIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9TRVJJQUxfS0VZ U1BBTiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQQU5f VVNBMjggaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9LRVlTUEFO X1VTQTI4WCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tFWVNQ QU5fVVNBMjhYQSBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFMX0tF WVNQQU5fVVNBMjhYQiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VSSUFM X0tFWVNQQU5fVVNBMTkgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklB TF9LRVlTUEFOX1VTQTE4WCBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VS SUFMX0tFWVNQQU5fVVNBMTlXIGlzIG5vdCBzZXQNCiMgQ09ORklHX1VTQl9T RVJJQUxfS0VZU1BBTl9VU0E0OVcgaXMgbm90IHNldA0KIyBDT05GSUdfVVNC X1NFUklBTF9NQ1RfVTIzMiBpcyBub3Qgc2V0DQojIENPTkZJR19VU0JfU0VS SUFMX0tMU0kgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9QTDIz MDMgaXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9DWUJFUkpBQ0sg aXMgbm90IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9YSVJDT00gaXMgbm90 IHNldA0KIyBDT05GSUdfVVNCX1NFUklBTF9PTU5JTkVUIGlzIG5vdCBzZXQN CiMgQ09ORklHX1VTQl9SSU81MDAgaXMgbm90IHNldA0KDQojDQojIEJsdWV0 b290aCBzdXBwb3J0DQojDQojIENPTkZJR19CTFVFWiBpcyBub3Qgc2V0DQoN CiMNCiMgS2VybmVsIGhhY2tpbmcNCiMNCiMgQ09ORklHX0RFQlVHX0tFUk5F TCBpcyBub3Qgc2V0DQo= ---52943472-2013051498-1018946269=:4326-- From owner-linux-xfs@oss.sgi.com Tue Apr 16 02:20:50 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3G9Ko8d021882 for ; Tue, 16 Apr 2002 02:20:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3G9KnCn021881 for linux-xfs-outgoing; Tue, 16 Apr 2002 02:20:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3G9Kj8d021851 for ; Tue, 16 Apr 2002 02:20:45 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3G9LbQR002303 for ; Tue, 16 Apr 2002 04:21:37 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3G9LQ6G009375; Tue, 16 Apr 2002 02:21:26 -0700 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with ESMTP id g3G9LPp37716586; Tue, 16 Apr 2002 02:21:25 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 05CCC3001E3; Tue, 16 Apr 2002 19:21:23 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 74D6B94; Tue, 16 Apr 2002 19:21:23 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: "Mark M. Barrios" Cc: linux-xfs@thebarn.com Subject: Re: CVS kernel tree question In-reply-to: Your message of "Tue, 16 Apr 2002 16:37:49 +0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 16 Apr 2002 19:21:17 +1000 Message-ID: <15196.1018948877@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 16 Apr 2002 16:37:49 +0800 (PHT), "Mark M. Barrios" wrote: >/usr/src/linux-2.4-xfs/linux/include/asm/system.h:13: parse error before `(' >/usr/src/linux-2.4-xfs/linux/include/asm/rwsem.h:47: parse error before `(' >/usr/src/linux-2.4-xfs/linux/include/asm/rwsem.h:48: parse error before `(' >/usr/src/linux-2.4-xfs/linux/include/asm/rwsem.h:49: parse error before `(' FASTCALL is undefined. include/linux/linkage.h not included or empty. >/usr/src/linux-2.4-xfs/linux/include/linux/fs.h:1163: warning: implicit declaration of function `barrier' >/usr/src/linux-2.4-xfs/linux/include/asm/bugs.h:71: warning: implicit declaration of function `printk' >/usr/src/linux-2.4-xfs/linux/include/asm/bugs.h:71: `KERN_EMERG' undeclared (first use in this function) include/linux/kernel.h not included or empty. Either your include files have been deleted or they are truncated. What do include/linux/{linkage,kernel}.h look like when the error occurs? From owner-linux-xfs@oss.sgi.com Tue Apr 16 03:26:10 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GAQA8d030228 for ; Tue, 16 Apr 2002 03:26:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GAQA2V030227 for linux-xfs-outgoing; Tue, 16 Apr 2002 03:26:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GAPt8d030194 for ; Tue, 16 Apr 2002 03:25:56 -0700 Received: from acid.compass.com.ph (IDENT:WCzSDvQw4Pjg7gddKkMn5qMdkNwJQJpm@acid.compass.com.ph [216.252.144.37]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3GAQjQR002839 for ; Tue, 16 Apr 2002 05:26:47 -0500 (CDT) Received: by acid.compass.com.ph (Postfix, from userid 500) id 612111167E66; Tue, 16 Apr 2002 18:26:43 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by acid.compass.com.ph (Postfix) with ESMTP id ECAC93191C0D; Tue, 16 Apr 2002 18:26:42 +0800 (PHT) Date: Tue, 16 Apr 2002 18:26:42 +0800 (PHT) From: "Mark M. Barrios" To: Keith Owens Cc: linux-xfs@thebarn.com Subject: Re: CVS kernel tree question In-Reply-To: <15196.1018948877@kao2.melbourne.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 16 Apr 2002, Keith Owens wrote: > On Tue, 16 Apr 2002 16:37:49 +0800 (PHT), > "Mark M. Barrios" wrote: > > >/usr/src/linux-2.4-xfs/linux/include/asm/system.h:13: parse error before `(' > >/usr/src/linux-2.4-xfs/linux/include/asm/rwsem.h:47: parse error before `(' > >/usr/src/linux-2.4-xfs/linux/include/asm/rwsem.h:48: parse error before `(' > >/usr/src/linux-2.4-xfs/linux/include/asm/rwsem.h:49: parse error before `(' > > FASTCALL is undefined. include/linux/linkage.h not included or empty. > > >/usr/src/linux-2.4-xfs/linux/include/linux/fs.h:1163: warning: implicit declaration of function `barrier' > >/usr/src/linux-2.4-xfs/linux/include/asm/bugs.h:71: warning: implicit declaration of function `printk' > >/usr/src/linux-2.4-xfs/linux/include/asm/bugs.h:71: `KERN_EMERG' undeclared (first use in this function) > > include/linux/kernel.h not included or empty. > > Either your include files have been deleted or they are truncated. > What do include/linux/{linkage,kernel}.h look like when the error > occurs? > Oops, youre right I got the wrong kernel.h include linkage.h looks right but kernel.h looks like this: --- /* This file is automatically generated at boot time. */ #ifndef __BOOT_KERNEL_H_ #define __BOOT_KERNEL_H_ /* Kernel type i686 */ #ifndef __MODULE_KERNEL_i686 #define __MODULE_KERNEL_i686 1 #endif #ifndef __BOOT_KERNEL_ENTERPRISE #define __BOOT_KERNEL_ENTERPRISE 0 #endif #ifndef __BOOT_KERNEL_SMP #define __BOOT_KERNEL_SMP 0 #endif #ifndef __BOOT_KERNEL_UP #define __BOOT_KERNEL_UP 1 #endif #endif --- my mistake... I must have I made a wrong link from /boot/kernel.h to /usr/src/linux when I was cleaning up after migrating /boot I'm not sure if anyone reported this yet, but I found that XFS DMAPI doesn't want to be built as a module, built in has no problems. Here's the error: --- make[1]: Entering directory `/usr/src/linux-2.4-xfs.b/linux' ld -m elf_i386 -T /usr/src/linux-2.4-xfs.b/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o init/version.o --start-group arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o drivers/char/char.o drivers/block/block.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o drivers/ide/idedriver.o drivers/cdrom/driver.o drivers/pci/driver.o drivers/video/video.o net/network.o /usr/src/linux-2.4-xfs.b/linux/arch/i386/lib/lib.a /usr/src/linux-2.4-xfs.b/linux/lib/lib.a /usr/src/linux-2.4-xfs.b/linux/arch/i386/lib/lib.a --end-group -o vmlinuxfs/fs.o: In function `xfs_dm_send_data_event': fs/fs.o(.text+0x279a2): undefined reference to `dm_send_data_event' fs/fs.o: In function `xfs_dm_send_create_event': fs/fs.o(.text+0x27a56): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_dm_bulkstat_one': fs/fs.o(.text+0x27e8a): undefined reference to `dm_vp_to_handle' fs/fs.o: In function `xfs_dm_mount': fs/fs.o(.text+0x2aa8b): undefined reference to `dm_send_mount_event' fs/fs.o(.text+0x2aa9f): undefined reference to `dm_hookup_vfsmount' fs/fs.o: In function `xfs_rename': fs/fs.o(.text+0x7764d): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x7803e): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_unmount': fs/fs.o(.text+0x7d7a4): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x7d883): undefined reference to `dm_send_unmount_event' fs/fs.o: In function `xfs_setattr': fs/fs.o(.text+0x7f9a5): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_inactive': fs/fs.o(.text+0x808ae): undefined reference to `dm_send_destroy_event' fs/fs.o: In function `xfs_create': fs/fs.o(.text+0x817d0): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_remove': fs/fs.o(.text+0x81e10): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x822d4): undefined reference to `dm_send_namesp_event' fs/fs.o: In function `xfs_link': fs/fs.o(.text+0x8241d): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x827d6): undefined reference to `dm_send_namesp_event' fs/fs.o(.text+0x82dd9): more undefined references to `dm_send_namesp_event' follow make[1]: *** [kallsyms] Error 1 make[1]: Leaving directory `/usr/src/linux-2.4-xfs.b/linux' make: *** [vmlinux] Error 2 --- Thanks for the help Mark M. Barrios From owner-linux-xfs@oss.sgi.com Tue Apr 16 05:41:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GCfb8d003300 for ; Tue, 16 Apr 2002 05:41:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GCfbV5003299 for linux-xfs-outgoing; Tue, 16 Apr 2002 05:41:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GCfX8d003270 for ; Tue, 16 Apr 2002 05:41:33 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3GCgPQR003718 for ; Tue, 16 Apr 2002 07:42:26 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3GCgP6G014222 for ; Tue, 16 Apr 2002 05:42:25 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3GCgOp44400992 for <@relay.sgi.com:linux-xfs@thebarn.com>; Tue, 16 Apr 2002 05:42:24 -0700 (PDT) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id WAA07205 for ; Tue, 16 Apr 2002 22:42:21 +1000 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id WAA72296 for linux-xfs@thebarn.com; Tue, 16 Apr 2002 22:42:21 +1000 (EST) Date: Tue, 16 Apr 2002 22:42:21 +1000 (EST) From: Timothy Shimmin Message-Id: <200204161242.WAA72296@snort.melbourne.sgi.com> To: linux-xfs@thebarn.com Subject: TAKE - 2 - ATTR macro encodings Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Last TAKE was wrong for the kernel ATTR macros - only change 1 bit. Oops. --Tim Date: Tue Apr 16 05:40:09 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:116452a linux/fs/xfs/xfs_attr.h - 1.19 - Ensure ATTR_* values only change 1 bit. From owner-linux-xfs@oss.sgi.com Tue Apr 16 08:05:39 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GF5c8d017974 for ; Tue, 16 Apr 2002 08:05:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GF5cEC017973 for linux-xfs-outgoing; Tue, 16 Apr 2002 08:05:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GF5X8d017947 for ; Tue, 16 Apr 2002 08:05:33 -0700 Received: from imf26bis.bellsouth.net (mail126.mail.bellsouth.net [205.152.58.86]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3GF6LQR004748 for ; Tue, 16 Apr 2002 10:06:22 -0500 (CDT) X-Authentication-Warning: lips.thebarn.com: Host mail126.mail.bellsouth.net [205.152.58.86] claimed to be imf26bis.bellsouth.net Received: from taz ([65.81.168.173]) by imf26bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020416150615.OEOS28104.imf26bis.bellsouth.net@taz>; Tue, 16 Apr 2002 11:06:15 -0400 Date: Tue, 16 Apr 2002 11:04:06 -0400 From: Greg Freemyer Subject: re: [RESEND] Re: re[4]: XFS installer and driver/update disks To: Nathan Scott , Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020416150615.OEOS28104.imf26bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3GF5Y8d017948 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nathan, Thanks for the education. I gather from the below that the XFS 2.4.18 kernel patch includes the complete EA patch, and that as of 2.4.20 it is hoped that you will no longer have to include this patch because it will be in the base kernel. >> > These syscalls were back ported to the 2.4 kernel and released as a >> standard part of 2.4.18. >> The second part of this statement is incorrect - it has an "off-by-two" >> error. Marcelo has agreed to include the complete EA patch (that is in >> 2.5 already, since 2.5.3) in 2.4.20-preX. >> In 2.4.18 Marcelo took a patch to mark the extended attributes system >> calls as reserved, and it was 2.4.18 that we switched the XFS CVS tree >> over to the new interfaces. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Tue Apr 16 08:07:02 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GF6v8d018146 for ; Tue, 16 Apr 2002 08:06:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GF6uM3018145 for linux-xfs-outgoing; Tue, 16 Apr 2002 08:06: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GF6o8d018115 for ; Tue, 16 Apr 2002 08:06:50 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA88549; Tue, 16 Apr 2002 10:07:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA79691; Tue, 16 Apr 2002 10:07:37 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3GF5RG24610; Tue, 16 Apr 2002 10:05:27 -0500 Subject: Re: 2 questions From: Steve Lord To: Simon Matter Cc: Seth Mos , Libor =?ISO-8859-1?Q?Van=ECk?= , linux-xfs@oss.sgi.com In-Reply-To: <3CB6E981.8C29617F@ch.sauter-bc.com> References: <4.3.2.7.2.20020412155435.038711c8@pop.xs4all.nl> <3CB6E981.8C29617F@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 16 Apr 2002 10:05:27 -0500 Message-Id: <1018969527.24543.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-12 at 09:04, Simon Matter wrote: > Seth Mos schrieb: > > > > At 14:25 12-4-2002 +0200, =?ISO-8859-2?Q?Libor_Van=ECk?= wrote: > > >Hi, > > >I'd like to ask 2 small yes/no questions about XFS: > > >- does XFS support fs resising? > > > > Only larger, shrinking is not supported. > > > > >- is there any way how to have physicaly more (Linux) machines which would > > >act like one big XFS (probably all driven by one "master" machine which > > >would handle I/O requests)? > > > > There are some other filesystem block layers that can do this but I don't > > know if any of them actually work with XFS. I see some trivial test reports > > but I can't remember if any of them was succesful or not. > > You could use network block devices on several physikal machines and > build one big RAID0/1/5 volume with it on the master server. Then put > XFS or LVM/XFS on top of it. I tried this once and it worked quite well > and fast. If been told you can get better performance than with NFS. > > -Simon > If you mount one xfs filesystem from several hosts like this then you are heading for data corruption very quickly. There is no way to manage cache coherency between the machines in this setup, and all the machines can end up modifying metadata independently. The only way to do this now is NFS. CXFS will allow this configuration when it is available for Linux. However CXFS is still a ways off, and will not be open sourced. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Tue Apr 16 11:27:04 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GIR48d002409 for ; Tue, 16 Apr 2002 11:27:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GIR4bV002408 for linux-xfs-outgoing; Tue, 16 Apr 2002 11:27:04 -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-d514e11a.dsl.mediaWays.net [213.20.225.26]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GIQL8d002346 for ; Tue, 16 Apr 2002 11:26:22 -0700 Received: from apollo.berdmann.de ([192.168.1.2]) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16xXfb-0005Lt-00 for linux-xfs@oss.sgi.com; Tue, 16 Apr 2002 20:27:11 +0200 Received: from be by apollo.berdmann.de with local (Exim 3.22 #1) id 16xXfa-0007sA-00 for linux-xfs@oss.sgi.com; Tue, 16 Apr 2002 20:27:10 +0200 X-Sieve: cmu-sieve 2.0 Received: from james.berdmann.de ([192.168.1.1]) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16xH8w-0003dL-00 for be@berdmann.de; Tue, 16 Apr 2002 02:48:22 +0200 Received: from moutng0.kundenserver.de ([212.227.126.170] helo=moutng0.schlund.de) by james.berdmann.de with esmtp (Exim 3.22 #1) id 16xH8v-0001DP-00 for be@berdmann.de; Tue, 16 Apr 2002 02:48:21 +0200 Received: from [212.227.126.149] (helo=mxng06.kundenserver.de) by moutng0.schlund.de with esmtp (Exim 3.22 #2) id 16xH8r-0006Z6-00 for be@berdmann.dyndns.org; Tue, 16 Apr 2002 02:48:17 +0200 Received: from [66.38.151.27] (helo=outgoing.securityfocus.com) by mxng06.kundenserver.de with esmtp (Exim 3.22 #2) id 16xH8o-00063X-00 for be@berdmann.de; Tue, 16 Apr 2002 02:48:14 +0200 Received: from lists.securityfocus.com (lists.securityfocus.com [66.38.151.19]) by outgoing.securityfocus.com (Postfix) with QMQP id 87299A30E8; Mon, 15 Apr 2002 15:54:00 -0600 (MDT) Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm List-Id: List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list bugtraq@securityfocus.com Delivered-To: moderator for bugtraq@securityfocus.com Received: (qmail 6527 invoked from network); 15 Apr 2002 21:47:17 -0000 Date: Mon, 15 Apr 2002 14:49:34 -0700 (PDT) From: SGI Security Coordinator Message-Id: <10204151449.ZM268355@einstein.csd.sgi.com> Reply-To: agent99@sgi.com X-Mailer: Z-Mail-SGI (3.2S.3 08feb96 MediaMail) To: agent99@sgi.com Subject: IRIX XFS filesystem denial of service attack Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- _____________________________________________________________________________ SGI Security Advisory Title: IRIX XFS filesystem denial of service attack Number: 20020402-01-P Date: April 15, 2002 Reference: CAN-2002-0042 ______________________________________________________________________________ - ----------------------- - --- Issue Specifics --- - ----------------------- It has been reported that there is a vulnerability in IRIX's XFS filesystem. Under some circumstances, a user can create a file that would hang any application that would try to access it. This has the potential to be used to create a Denial of Service attack. SGI has investigated the issue and recommends the following steps for neutralizing the exposure. It is HIGHLY RECOMMENDED that these measures be implemented on ALL vulnerable SGI systems. This issue has been corrected in IRIX 6.5.12 and later versions. - -------------- - --- Impact --- - -------------- The XFS filesystem is the default filesystem in IRIX 6.5, therefore all IRIX 6.5 systems are potentially vulnerable to this problem. This vulnerability may be not exploited by a remote user, a local account is required. This vulnerability can lead to a Denial of Service. SGI assigned the following CVE to this vulnerability: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0042 - ---------------- - --- Solution --- - ---------------- SGI has released patches to address this problem. Our recommendation is to upgrade to IRIX 6.5.12 or later. OS Version Vulnerable? Patch # Other Actions ---------- ----------- ------- ------------- IRIX 3.x unknown Note 1 IRIX 4.x unknown Note 1 IRIX 5.x unknown Note 1 IRIX 6.0.x unknown Note 1 IRIX 6.1 unknown Note 1 IRIX 6.2 unknown Note 1 IRIX 6.3 unknown Note 1 IRIX 6.4 unknown Note 1 IRIX 6.5 yes Notes 2 & 3 IRIX 6.5.1 yes Notes 2 & 3 IRIX 6.5.2 yes Notes 2 & 3 IRIX 6.5.3 yes Notes 2 & 3 IRIX 6.5.4 yes Notes 2 & 3 IRIX 6.5.5 yes Notes 2 & 3 IRIX 6.5.6 yes Notes 2 & 3 IRIX 6.5.7 yes Notes 2 & 3 IRIX 6.5.8 yes Notes 2 & 3 IRIX 6.5.9 yes Notes 2 & 3 IRIX 6.5.10m yes 4286 IRIX 6.5.10f yes 4253 IRIX 6.5.11m yes Notes 2 & 3 IRIX 6.5.11f yes 4254 IRIX 6.5.12 no IRIX 6.5.13 no IRIX 6.5.14 no IRIX 6.5.15 no NOTES 1) This version of the IRIX operating has been retired. Upgrade to an actively supported IRIX operating system. See http://support.sgi.com/irix/news/index.html#policy for more information. 2) If you have not received an IRIX 6.5.X CD for IRIX 6.5, contact your SGI Support Provider or URL: http://support.sgi.com/irix/swupdates/ 3) Upgrade to IRIX 6.5.12 or later ##### Patch File Checksums #### The actual patch will be a tar file containing the following files: Filename: README.patch.4286 Algorithm #1 (sum -r): 28330 8 README.patch.4286 Algorithm #2 (sum): 39948 8 README.patch.4286 MD5 checksum: DD88F4A17F3BAFEA470C17CFB68F693A Filename: patchSG0004286 Algorithm #1 (sum -r): 42009 2 patchSG0004286 Algorithm #2 (sum): 42193 2 patchSG0004286 MD5 checksum: 01F9634E6DCD8893C0D743B267C1D959 Filename: patchSG0004286.eoe_sw Algorithm #1 (sum -r): 25043 13360 patchSG0004286.eoe_sw Algorithm #2 (sum): 45889 13360 patchSG0004286.eoe_sw MD5 checksum: 0770194058C390E5DA0EE1D402CB47AC Filename: patchSG0004286.idb Algorithm #1 (sum -r): 29719 7 patchSG0004286.idb Algorithm #2 (sum): 17684 7 patchSG0004286.idb MD5 checksum: FE5CFE59138343ED743E4658D878FD42 Filename: README.patch.4253 Algorithm #1 (sum -r): 53492 29 README.patch.4253 Algorithm #2 (sum): 10868 29 README.patch.4253 MD5 checksum: 117515A96FDCC06DA6D360069BF14198 Filename: patchSG0004253 Algorithm #1 (sum -r): 54098 19 patchSG0004253 Algorithm #2 (sum): 7810 19 patchSG0004253 MD5 checksum: FDE0FBDAF74600BB5D6C98B4B36A518B Filename: patchSG0004253.cluster_admin_sw Algorithm #1 (sum -r): 53890 1264 patchSG0004253.cluster_admin_sw Algorithm #2 (sum): 41015 1264 patchSG0004253.cluster_admin_sw MD5 checksum: ADB036F14DD3BB0CABFF56DFA49D64A5 Filename: patchSG0004253.cluster_control_sw Algorithm #1 (sum -r): 57927 2911 patchSG0004253.cluster_control_sw Algorithm #2 (sum): 46116 2911 patchSG0004253.cluster_control_sw MD5 checksum: 195444B1050AB985125A280B790E6D6C Filename: patchSG0004253.cluster_services_sw Algorithm #1 (sum -r): 14277 1808 patchSG0004253.cluster_services_sw Algorithm #2 (sum): 60017 1808 patchSG0004253.cluster_services_sw MD5 checksum: 365929CFBBF50B179FC7B5CBF8BBCDED Filename: patchSG0004253.cxfs_sw Algorithm #1 (sum -r): 40423 7581 patchSG0004253.cxfs_sw Algorithm #2 (sum): 62074 7581 patchSG0004253.cxfs_sw MD5 checksum: 1DF5877BB29275C77B6BF5C9C1469F2F Filename: patchSG0004253.eoe_sw Algorithm #1 (sum -r): 03986 4440 patchSG0004253.eoe_sw Algorithm #2 (sum): 7047 4440 patchSG0004253.eoe_sw MD5 checksum: 31C4B8300741D3C904B50661C9B0402A Filename: patchSG0004253.idb Algorithm #1 (sum -r): 44464 18 patchSG0004253.idb Algorithm #2 (sum): 39382 18 patchSG0004253.idb MD5 checksum: 38BF992242C629E2DEE08F9E3A126F8B Filename: patchSG0004253.sysadm_base_sw Algorithm #1 (sum -r): 20162 1680 patchSG0004253.sysadm_base_sw Algorithm #2 (sum): 4626 1680 patchSG0004253.sysadm_base_sw MD5 checksum: 0B184577E1954633CCBBE59D901060FE Filename: patchSG0004253.sysadm_cxfs_sw Algorithm #1 (sum -r): 26183 1569 patchSG0004253.sysadm_cxfs_sw Algorithm #2 (sum): 43899 1569 patchSG0004253.sysadm_cxfs_sw MD5 checksum: CB64A03F7815E5EE06816B75DD58DA2E Filename: README.patch.4254 Algorithm #1 (sum -r): 08556 23 README.patch.4254 Algorithm #2 (sum): 54378 23 README.patch.4254 MD5 checksum: E7DDAC48F0D0463A609176CF781331EB Filename: patchSG0004254 Algorithm #1 (sum -r): 59698 18 patchSG0004254 Algorithm #2 (sum): 2027 18 patchSG0004254 MD5 checksum: A01A811C11139A47BF4D05930CABDF4D Filename: patchSG0004254.cluster_admin_sw Algorithm #1 (sum -r): 60527 1582 patchSG0004254.cluster_admin_sw Algorithm #2 (sum): 18153 1582 patchSG0004254.cluster_admin_sw MD5 checksum: 75EEDC2B94FFBABBA765075DCADE45A8 Filename: patchSG0004254.cluster_control_sw Algorithm #1 (sum -r): 04205 3498 patchSG0004254.cluster_control_sw Algorithm #2 (sum): 57434 3498 patchSG0004254.cluster_control_sw MD5 checksum: 775EAF2E955DACBB42AB641F02A46220 Filename: patchSG0004254.cluster_services_sw Algorithm #1 (sum -r): 08341 2218 patchSG0004254.cluster_services_sw Algorithm #2 (sum): 11236 2218 patchSG0004254.cluster_services_sw MD5 checksum: D83BEBEF84553EF40370D6F0D3086FBB Filename: patchSG0004254.cxfs_sw Algorithm #1 (sum -r): 16484 7548 patchSG0004254.cxfs_sw Algorithm #2 (sum): 65351 7548 patchSG0004254.cxfs_sw MD5 checksum: B9C9FE0FFA3C1D5DD2923ED5F8DE8407 Filename: patchSG0004254.eoe_sw Algorithm #1 (sum -r): 08488 4083 patchSG0004254.eoe_sw Algorithm #2 (sum): 35652 4083 patchSG0004254.eoe_sw MD5 checksum: 058FF0663BD376F7FA8EB52862A3CFDF Filename: patchSG0004254.idb Algorithm #1 (sum -r): 23445 23 patchSG0004254.idb Algorithm #2 (sum): 20069 23 patchSG0004254.idb MD5 checksum: 66CA44FB96445595D0F276C641DEED83 Filename: patchSG0004254.sysadm_base_sw Algorithm #1 (sum -r): 52860 1703 patchSG0004254.sysadm_base_sw Algorithm #2 (sum): 29501 1703 patchSG0004254.sysadm_base_sw MD5 checksum: FAE8ABB6798022398A0ACD24C45CF8A3 Filename: patchSG0004254.sysadm_cxfs_sw Algorithm #1 (sum -r): 02510 1664 patchSG0004254.sysadm_cxfs_sw Algorithm #2 (sum): 456 1664 patchSG0004254.sysadm_cxfs_sw MD5 checksum: 615D790FDD1E1D9712542B208F443688 - ------------------ - --- References --- - ------------------ SGI Security Advisories can be found at: http://www.sgi.com/support/security/ and ftp://patches.sgi.com/support/free/security/advisories/ SGI Security Patches can be found at: http://www.sgi.com/support/security/ and ftp://patches.sgi.com/support/free/security/patches/ SGI patches for IRIX can be found at the following patch servers: http://support.sgi.com/irix/ and ftp://patches.sgi.com/ SGI freeware updates for IRIX can be found at: http://freeware.sgi.com/ SGI fixes for SGI open sourced code can be found on: http://oss.sgi.com/projects/ SGI patches and RPMs for Linux can be found at: http://support.sgi.com/linux/ or http://oss.sgi.com/projects/sgilinux-combined/download/security-fixes/ SGI patches for Windows NT or 2000 can be found at: http://support.sgi.com/nt/ IRIX 5.2-6.4 Recommended/Required Patch Sets can be found at: http://support.sgi.com/irix/ and ftp://patches.sgi.com/support/patchset/ IRIX 6.5 Maintenance Release Streams can be found at: http://support.sgi.com/colls/patches/tools/relstream/index.html IRIX 6.5 Software Update CDs can be obtained from: http://support.sgi.com/irix/swupdates/ The primary SGI anonymous FTP site for security advisories and patches is patches.sgi.com (216.32.174.211). Security advisories and patches are located under the URL ftp://patches.sgi.com/support/free/security/ For security and patch management reasons, ftp.sgi.com (mirrors patches.sgi.com security FTP repository) lags behind and does not do a real-time update. - ------------------------ - --- Acknowledgments ---- - ------------------------ SGI wishes to thank Marc Olzheim, Sven Berkvens and the users of the Internet Community at large for their assistance in this matter. - ----------------------------------------- - --- SGI Security Information/Contacts --- - ----------------------------------------- If there are questions about this document, email can be sent to security-info@sgi.com. ------oOo------ SGI provides security information and patches for use by the entire SGI community. This information is freely available to any person needing the information and is available via anonymous FTP and the Web. The primary SGI anonymous FTP site for security advisories and patches is patches.sgi.com (216.32.174.211). Security advisories and patches are located under the URL ftp://patches.sgi.com/support/free/security/ The SGI Security Headquarters Web page is accessible at the URL: http://www.sgi.com/support/security/ For issues with the patches on the FTP sites, email can be sent to security-info@sgi.com. For assistance obtaining or working with security patches, please contact your SGI support provider. ------oOo------ SGI provides a free security mailing list service called wiretap and encourages interested parties to self-subscribe to receive (via email) all SGI Security Advisories when they are released. Subscribing to the mailing list can be done via the Web (http://www.sgi.com/support/security/wiretap.html) or by sending email to SGI as outlined below. % mail wiretap-request@sgi.com subscribe wiretap end ^d In the example above, is the email address that you wish the mailing list information sent to. The word end must be on a separate line to indicate the end of the body of the message. The control-d (^d) is used to indicate to the mail program that you are finished composing the mail message. ------oOo------ SGI provides a comprehensive customer World Wide Web site. This site is located at http://www.sgi.com/support/security/ . ------oOo------ If there are general security questions on SGI systems, email can be sent to security-info@sgi.com. For reporting *NEW* SGI security issues, email can be sent to security-alert@sgi.com or contact your SGI support provider. A support contract is not required for submitting a security report. ______________________________________________________________________________ This information is provided freely to all interested parties and may be redistributed provided that it is not altered in any way, SGI is appropriately credited and the document retains and includes its valid PGP signature. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQCVAwUBPLtKSrQ4cFApAP75AQG0YQQAq53XfwauXFyvfZaF4uFIDbNCW1UrSqXf WXgon2MLa6/ClJ+kXgFun3A/O7T432MKX7T3i5Czb87ZeaXDSVULqM/eo/yCDd18 seKLlVGMEsrkB9iO59MMSkBkCj8q8XaXIh0e8oD4s/5bhy/GPBerBdgbwlTSG8zY NzEO00tieFY= =f67G -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Apr 16 11:57:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GIvJ8d005045 for ; Tue, 16 Apr 2002 11:57:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GIvJe7005044 for linux-xfs-outgoing; Tue, 16 Apr 2002 11:57:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from icicle.winternet.com (icicle.winternet.com [198.174.169.13]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GIvB8d005006 for ; Tue, 16 Apr 2002 11:57:12 -0700 Received: from tundra.winternet.com (dufresne@tundra.winternet.com [198.174.169.11]) by icicle.winternet.com (8.12.1/8.12.1/sci) with ESMTP id g3GItgNF026226; Tue, 16 Apr 2002 13:57:01 -0500 (CDT) SMTP "HELO" (ESMTP) greeting from tundra.winternet.com But _really_ from :: dufresne@tundra.winternet.com [198.174.169.11] SMTP "MAIL From:" = dufresne@winternet.com (Ron DuFresne) SMTP "RCPT To:" = We have no RCPT Date: Tue, 16 Apr 2002 13:55:35 -0500 (CDT) From: Ron DuFresne To: H D Moore cc: agent99@sgi.com, , Subject: Re: IRIX XFS filesystem denial of service attack In-Reply-To: <200204151832.38497.sflist@digitaloffense.net> Message-ID: X-Admonition: The Good thing about potential is X-Admonition2: as long as you do nothing X-Admonition3: you'll always have it. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Wouldn't ulimit and or rlimits help mitigate this issue on linux systems? Thanks, Ron DuFresne On Mon, 15 Apr 2002, H D Moore wrote: > Does this vulnerability affect the Linux XFS port? The XFS page has no > information about this or whether there is a fix available: > > http://oss.sgi.com/projects/xfs/ > > -HD > > On Monday 15 April 2002 04:49 pm, SGI Security Coordinator wrote: > > > > SGI Security Advisory > > > > Title: IRIX XFS filesystem denial of service attack > > Number: 20020402-01-P > > Date: April 15, 2002 > > Reference: CAN-2002-0042 > > ----------------------- > > --- Issue Specifics --- > > ----------------------- > > > > It has been reported that there is a vulnerability in IRIX's XFS > > filesystem. Under some circumstances, a user can create a file that would > > hang any application that would try to access it. This has the potential > > to be used to create a Denial of Service attack. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. From owner-linux-xfs@oss.sgi.com Tue Apr 16 14:23:24 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GLNO8d017570 for ; Tue, 16 Apr 2002 14:23:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GLNOLf017569 for linux-xfs-outgoing; Tue, 16 Apr 2002 14:23:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.hallcomp.com (hallcomp.com [208.140.194.52]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GLNK8d017543 for ; Tue, 16 Apr 2002 14:23:20 -0700 Received: from phobos.hallcomp.com [207.0.147.36] by mail.hallcomp.com with ESMTP (SMTPD32-5.05) id A8B5DB00AE; Tue, 16 Apr 2002 17:33:41 -0400 Subject: Re: IRIX XFS filesystem denial of service attack From: Timothy Wood To: H D Moore Cc: agent99@sgi.com, linux-xfs@oss.sgi.com, bugtraq@securityfocus.com In-Reply-To: <200204151832.38497.sflist@digitaloffense.net> References: <10204151449.ZM268355@einstein.csd.sgi.com> <200204151832.38497.sflist@digitaloffense.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 16 Apr 2002 16:28:31 -0400 Message-Id: <1018988911.1980.2.camel@phobos> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-04-15 at 19:32, H D Moore wrote: > Does this vulnerability affect the Linux XFS port? The XFS page has no > information about this or whether there is a fix available: > > http://oss.sgi.com/projects/xfs/ > I'd doubt it since it says IRIX XFS filesystem instead of just XFS filesystem. From owner-linux-xfs@oss.sgi.com Tue Apr 16 14:39:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GLdH8d018370 for ; Tue, 16 Apr 2002 14:39:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GLdHJm018369 for linux-xfs-outgoing; Tue, 16 Apr 2002 14:39: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GLdB8d018338 for ; Tue, 16 Apr 2002 14:39:12 -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 QAA95534; Tue, 16 Apr 2002 16:40:01 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA72334; Tue, 16 Apr 2002 16:40:00 -0500 (CDT) Subject: Re: IRIX XFS filesystem denial of service attack From: Eric Sandeen To: H D Moore Cc: agent99@sgi.com, linux-xfs@oss.sgi.com, bugtraq@securityfocus.com In-Reply-To: <200204151832.38497.sflist@digitaloffense.net> References: <10204151449.ZM268355@einstein.csd.sgi.com> <200204151832.38497.sflist@digitaloffense.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 16 Apr 2002 16:40:00 -0500 Message-Id: <1018993200.8789.377.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi HD - I don't believe that Linux is affected. I've been told that the Linux I/O path was written specifically to avoid this problem, and I have run some test cases from our original bug report, and did not see the described behavior. I'll look a bit more and reply when I know for sure. -Eric On Mon, 2002-04-15 at 18:32, H D Moore wrote: > Does this vulnerability affect the Linux XFS port? The XFS page has no > information about this or whether there is a fix available: -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Tue Apr 16 14:53:53 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3GLrr8d019200 for ; Tue, 16 Apr 2002 14:53:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3GLrrxF019199 for linux-xfs-outgoing; Tue, 16 Apr 2002 14:53:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3GLrl8d019166 for ; Tue, 16 Apr 2002 14:53:47 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.33 #1) id 16xauP-0005WV-00 for linux-xfs@oss.sgi.com; Tue, 16 Apr 2002 23:54:41 +0200 Received: from [192.168.11.12] (helo=pc2) by s.automatix.de with esmtp (Exim 3.15 #1) id 16xatR-0002SC-00 for linux-xfs@oss.sgi.com; Tue, 16 Apr 2002 23:53:41 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: linux-xfs@oss.sgi.com Subject: Pointer SuSE 8.0 contains XFS Filesystem Date: Tue, 16 Apr 2002 23:53:41 +0200 X-Mailer: KMail [version 1.4.5] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204162353.41917.juergen.sauer@automatix.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Moin, this is a short pointer to the SuSE 8.0. this Distribution contains XFS directly, it is possible to install XFS Rootfs Systems direct out of the Box. Upgrading - Rescue etc. is also easy possible. mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjy8nWUACgkQW7UKI9EqarEtpgCgvwtdK0pmws/bnwpzr5X60BOo bzkAoMdfJLuCq4NZBCwCbGu9+fhK1nlW =u/FG -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Tue Apr 16 17:54:29 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H0sT8d026437 for ; Tue, 16 Apr 2002 17:54:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H0sTX3026436 for linux-xfs-outgoing; Tue, 16 Apr 2002 17:54:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3H0sO8d026405 for ; Tue, 16 Apr 2002 17:54:24 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3H0tIQR010621 for ; Tue, 16 Apr 2002 19:55:19 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3H1sjBA022652; Tue, 16 Apr 2002 18:54:45 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3H0shp44601224; Tue, 16 Apr 2002 17:54:44 -0700 (PDT) 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 KAA12098; Wed, 17 Apr 2002 10:54:35 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA28440; Wed, 17 Apr 2002 10:54:35 +1000 (AEST) Date: Wed, 17 Apr 2002 10:54:34 +1000 From: Nathan Scott To: Greg Freemyer Cc: linux-xfs@thebarn.com Subject: Re: [RESEND] Re: re[4]: XFS installer and driver/update disks Message-ID: <20020417105434.G26032@wobbly.melbourne.sgi.com> References: <20020416150615.OEOS28104.imf26bis.bellsouth.net@taz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020416150615.OEOS28104.imf26bis.bellsouth.net@taz>; from freemyer@NorcrossGroup.com on Tue, Apr 16, 2002 at 11:04:06AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi Greg, On Tue, Apr 16, 2002 at 11:04:06AM -0400, Greg Freemyer wrote: > Nathan, > > Thanks for the education. > > I gather from the below that the XFS 2.4.18 kernel patch includes the complete EA patch, and that as of 2.4.20 it is hoped that you will no longer have to include this patch because it will be in the base kernel. > That is correct, yes. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 16 23:49:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H6nt8d005248 for ; Tue, 16 Apr 2002 23:49:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H6ntgG005247 for linux-xfs-outgoing; Tue, 16 Apr 2002 23:49:55 -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 g3H6nn8d005214 for ; Tue, 16 Apr 2002 23:49:49 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 4B9B227E73; Wed, 17 Apr 2002 16:50:35 +1000 (EST) Date: Wed, 17 Apr 2002 16:50:35 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: quota on xfs Message-ID: <20020417065035.GA16162@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I've noticed something strange with quotas on xfs (kernel 2.4.18, Debian Woody, latest XFS patch). As root, quota works fine. ie: newserver:/usr/share/doc/quota# quota ian Disk quotas for user ian (uid 1000): Filesystem blocks quota limit grace files quota limit grace /dev/hda8 0 20480 51200 1 10000 15000 /dev/hdc5 28 204800 225280 11 50000 55000 However, as a user, I get: ian@newserver:~$ quota Disk quotas for user ian (uid 1000): none This happens even if I specify xfs to the quota command. I'm not sure if this should be directed to the linux-quota folks, but I thought I would ask in here first. 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 Tue Apr 16 23:55:32 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H6tW8d005612 for ; Tue, 16 Apr 2002 23:55:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H6tWrS005611 for linux-xfs-outgoing; Tue, 16 Apr 2002 23:55:32 -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 g3H6tK8d005574 for ; Tue, 16 Apr 2002 23:55:20 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx12)) with ESMTP id 534C1C5D4; Wed, 17 Apr 2002 08:56:11 +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 IAA10906; Wed, 17 Apr 2002 08:56:11 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 5BEE057306; Wed, 17 Apr 2002 08:55:49 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 8899225835; Wed, 17 Apr 2002 08:55:48 +0200 (CEST) Message-ID: <3CBD1C74.893FA6CB@ch.sauter-bc.com> Date: Wed, 17 Apr 2002 08:55:48 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Steve Lord Cc: Seth Mos , "Libor =?iso-8859-1?Q?Van=ECk?=" , linux-xfs@oss.sgi.com Subject: Re: 2 questions References: <4.3.2.7.2.20020412155435.038711c8@pop.xs4all.nl> <3CB6E981.8C29617F@ch.sauter-bc.com> <1018969527.24543.8.camel@jen.americas.sgi.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord schrieb: > > On Fri, 2002-04-12 at 09:04, Simon Matter wrote: > > Seth Mos schrieb: > > > > > > At 14:25 12-4-2002 +0200, =?ISO-8859-2?Q?Libor_Van=ECk?= wrote: > > > >Hi, > > > >I'd like to ask 2 small yes/no questions about XFS: > > > >- does XFS support fs resising? > > > > > > Only larger, shrinking is not supported. > > > > > > >- is there any way how to have physicaly more (Linux) machines which would > > > >act like one big XFS (probably all driven by one "master" machine which > > > >would handle I/O requests)? > > > > > > There are some other filesystem block layers that can do this but I don't > > > know if any of them actually work with XFS. I see some trivial test reports > > > but I can't remember if any of them was succesful or not. > > > > You could use network block devices on several physikal machines and > > build one big RAID0/1/5 volume with it on the master server. Then put > > XFS or LVM/XFS on top of it. I tried this once and it worked quite well > > and fast. If been told you can get better performance than with NFS. > > > > -Simon > > > > If you mount one xfs filesystem from several hosts like this then you > are heading for data corruption very quickly. There is no way to manage > cache coherency between the machines in this setup, and all the machines > can end up modifying metadata independently. This is what I meant: +----------+ +----------+ +----------+ | Server0 | | Server1 | | Server2 | | | | | | | | | | | | | | /nbd0 | | /nbd1 | | /nbd2 | | ^ | | ^ | | ^ | +-----|----+ +-----|----+ +-----|----+ | | | | | | | | | | \-------\ | | | | | | | | | | | +-------------------|--+ | | | Big Iron | | | | | | | | | | | | | | | | | | \----------->/dev/nbd0 | | | | /dev/nbd1 <-/ | | | /dev/nbd2 <-----------/ | | | /dev/md0:RAID5 { | | /dev/nbd0 | | /dev/nbd1 | | /dev/nbd2 } | | | | | | XFS on /dev/md0 | | | +----------------------+ Is _this_ dangerous or did you get me wrong? IIRC it has worked perfect and I didn't see any corruption. -Simon > > The only way to do this now is NFS. CXFS will allow this configuration > when it is available for Linux. However CXFS is still a ways off, and > will not be open sourced. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Apr 17 00:01:24 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H71O8d006042 for ; Wed, 17 Apr 2002 00:01:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H71OIf006041 for linux-xfs-outgoing; Wed, 17 Apr 2002 00:01:24 -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 g3H71I8d005997 for ; Wed, 17 Apr 2002 00:01:18 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx12)) with ESMTP id 104CEC49B; Wed, 17 Apr 2002 09:02:10 +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 JAA11313; Wed, 17 Apr 2002 09:02:09 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id A6B9457306; Wed, 17 Apr 2002 09:02:00 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 8608D25835; Wed, 17 Apr 2002 09:02:00 +0200 (CEST) Message-ID: <3CBD1DE8.382EEF4F@ch.sauter-bc.com> Date: Wed, 17 Apr 2002 09:02:00 +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, en MIME-Version: 1.0 To: Juergen Sauer Cc: linux-xfs@oss.sgi.com Subject: Re: Pointer SuSE 8.0 contains XFS Filesystem References: <200204162353.41917.juergen.sauer@automatix.de> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=iso-8859-1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Juergen, IIRC you are using SAPDB. Do you run it on XFS? If so, how does it perform and can you recommend XFS for SAPDB? -Simon Juergen Sauer schrieb: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Moin, > > this is a short pointer to the SuSE 8.0. > > this Distribution contains XFS directly, it is possible to install XFS > Rootfs Systems direct out of the Box. > Upgrading - Rescue etc. is also easy possible. > > mfG > Jojo > > - -- > Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** > ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** > http://www.automatix.de to Mail me: remove: -not-for-spawm- ** > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (GNU/Linux) > Comment: For info see http://www.gnupg.org > > iEYEARECAAYFAjy8nWUACgkQW7UKI9EqarEtpgCgvwtdK0pmws/bnwpzr5X60BOo > bzkAoMdfJLuCq4NZBCwCbGu9+fhK1nlW > =u/FG > -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Apr 17 00:27:07 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H7R78d007269 for ; Wed, 17 Apr 2002 00:27:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H7R7Yj007268 for linux-xfs-outgoing; Wed, 17 Apr 2002 00:27:07 -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 g3H7Qu8d007228 for ; Wed, 17 Apr 2002 00:26:57 -0700 Received: from erbenson.alaska.net (20-pm21.nwc.alaska.net [209.112.143.20]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3H7RqQ27055 for ; Tue, 16 Apr 2002 23:27:52 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 9961A3977 for ; Tue, 16 Apr 2002 23:27:50 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 3F8DA10285; Tue, 16 Apr 2002 23:27:50 -0800 (AKDT) Date: Tue, 16 Apr 2002 23:27:50 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: quota on xfs Message-ID: <20020416232750.F20630@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020417065035.GA16162@ids.org.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8JPrznbw0YAQ/KXy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020417065035.GA16162@ids.org.au>; from ian@ids.org.au on Wed, Apr 17, 2002 at 04:50:35PM +1000 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --8JPrznbw0YAQ/KXy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2002 at 04:50:35PM +1000, Ian Cumming wrote: > Hi, >=20 > I've noticed something strange with quotas on xfs (kernel 2.4.18, Debian = Woody, > latest XFS patch). >=20 > As root, quota works fine. ie: >=20 > newserver:/usr/share/doc/quota# quota ian > Disk quotas for user ian (uid 1000): > Filesystem blocks quota limit grace files quota limit grace > /dev/hda8 0 20480 51200 1 10000 15000 > /dev/hdc5 28 204800 225280 11 50000 55000 >=20 >=20 > However, as a user, I get: >=20 > ian@newserver:~$ quota > Disk quotas for user ian (uid 1000): none >=20 >=20 > This happens even if I specify xfs to the quota command. >=20 > I'm not sure if this should be directed to the linux-quota folks, but I > thought I would ask in here first. i found this earlier, search the archives for `quota permissions' basically the quota syscalls are returning -EPERM for non-root, this is a bug in the 2.4.18 split XFS patches, the following patch will fix it: $ diff -Naur quota.c.orig quota.c --- quota.c.orig Mon Mar 25 12:19:57 2002 +++ quota.c Mon Mar 25 12:20:55 2002 @@ -47,6 +47,7 @@ (type =3D=3D GRPQUOTA && !in_egroup_p(id))) && !capable(CAP_SYS_ADMIN)) goto error; + break; default: if (!capable(CAP_SYS_ADMIN)) this is already merged in the XFS cvs tree. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --8JPrznbw0YAQ/KXy 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 iEYEARECAAYFAjy9I/YACgkQJKx7GixEevxsOACeOwErU8/gMV6tlygA4aUi1MmL h8EAni8aYbm986TVPJwtM6PDqOJesVHy =KHgI -----END PGP SIGNATURE----- --8JPrznbw0YAQ/KXy-- From owner-linux-xfs@oss.sgi.com Wed Apr 17 01:09:25 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H89P8d009419 for ; Wed, 17 Apr 2002 01:09:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H89P9c009418 for linux-xfs-outgoing; Wed, 17 Apr 2002 01:09:25 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.automatix.de (mail@www.automatix.de [212.4.161.35]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3H89H8d009392 for ; Wed, 17 Apr 2002 01:09:18 -0700 Received: from uucp by mail.automatix.de with local-bsmtp (Exim 3.33 #1) id 16xkW5-0004Mf-00 for linux-xfs@oss.sgi.com; Wed, 17 Apr 2002 10:10:13 +0200 Received: from [192.168.11.1] (helo=server) by s.automatix.de with esmtp (Exim 3.15 #1) id 16xkUv-000404-00; Wed, 17 Apr 2002 10:09:01 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Juergen Sauer Organization: AutomatiX GmbH To: Simon Matter Subject: Re: Pointer SuSE 8.0 contains XFS Filesystem Date: Wed, 17 Apr 2002 10:09:01 +0200 X-Mailer: KMail [version 1.4.5] Cc: linux-xfs@oss.sgi.com References: <200204162353.41917.juergen.sauer@automatix.de> <3CBD1DE8.382EEF4F@ch.sauter-bc.com> In-Reply-To: <3CBD1DE8.382EEF4F@ch.sauter-bc.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204171009.01362.juergen.sauer@automatix.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 17. April 2002 09:02 schrieb Simon Matter: > Hi Juergen, > IIRC you are using SAPDB. Do you run it on XFS? If so, how does it > perform and can you recommend XFS for SAPDB? Yes, runns fine. [ SapDB is not Adabas D, Adabas D fails] Hi Simon, To my expieriences and tests, it was not possible to me to crash down a SapDB (7.3.00.21) Installation on my notebook by powerdowns during heavyly SQL-Load. But keep in your mind, if you have a hardware-caching Controller in a Server you need urgent a UPS or you may loose data, which resides at writing time in the writebackbuffers of the controllers. A powerloss here may be fatal. This was the only way for me to get XFS + SapDB struggling. [Also it is not a good idea to hit the reset button during mounting a XFS-(Root) Partition and Log-replaying ...] IMHO it is also a good idea to setup a productive, most perfomant RDBMS using RAW devices, in this cases it does not effect the VFS layer of the OS. mfG Jojo - -- Jürgen Sauer - AutomatiX GmbH, +49-4209-4699, jojo@automatix.de ** ** Das Linux Systemhaus - Service - Support - Server - Lösungen ** http://www.automatix.de to Mail me: remove: -not-for-spawm- ** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjy9LZ0ACgkQW7UKI9EqarGnrQCgxWUYu/VQypemeGEMHOkDclGY PmAAn3l9U/4RHAkoiZT8cqBR3FhGvQca =Y8t+ -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Wed Apr 17 02:00:21 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H90L8d011944 for ; Wed, 17 Apr 2002 02:00:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H90LJX011943 for linux-xfs-outgoing; Wed, 17 Apr 2002 02:00:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3H9058d011884 for ; Wed, 17 Apr 2002 02:00:05 -0700 Received: from warp9.koschikode.com (pD95174A3.dip.t-dialin.net [217.81.116.163]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id 481E5F4FC for ; Wed, 17 Apr 2002 11:00:44 +0200 (CEST) Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id 39415A9 for ; Wed, 17 Apr 2002 11:00:34 +0200 (CEST) Message-ID: <3CBD39B1.5090802@koschikode.com> Date: Wed, 17 Apr 2002 11:00:33 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020407 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: quota on xfs References: <20020417065035.GA16162@ids.org.au> <20020416232750.F20630@plato.local.lan> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson wrote: > basically the quota syscalls are returning -EPERM for non-root, this > is a bug in the 2.4.18 split XFS patches, the following patch will > fix it: > > $ diff -Naur quota.c.orig quota.c > --- quota.c.orig Mon Mar 25 12:19:57 2002 > +++ quota.c Mon Mar 25 12:20:55 2002 [patch snipped] > this is already merged in the XFS cvs tree. Uhm, what XFS cvs tree are you talking about? I cannot find this in the current 2.4.18 tree. A kernel checked out on 8th April still exhibits this behaviour and I just updated and linux/fs/quota.c wasn't modified... What am I overlooking? Juri From owner-linux-xfs@oss.sgi.com Wed Apr 17 02:27:33 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H9RX8d013183 for ; Wed, 17 Apr 2002 02:27:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H9RXLb013182 for linux-xfs-outgoing; Wed, 17 Apr 2002 02:27:33 -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 g3H9RO8d013144 for ; Wed, 17 Apr 2002 02:27:25 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 16xlh1-00042t-00; Wed, 17 Apr 2002 11:25:35 +0200 From: "Ralf G. R. Bergs" To: "jeremy@goop.org" Cc: "Linux XFS Mailing List" , "Adam Heath" Date: Wed, 17 Apr 2002 11:25:35 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2475) For Windows 2000 (5.0.2195;2) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Possible bug in autofs 3.9.99 WRT to XFS (DID work in 3.1.4!) Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [CC to the Debian maintainer and the XFS mailing list] Hi there, I think I may have found a bug in autofs 3.9.99. I'm using the Debian "testing" version 4.0.0pre10-0 of the autofs package, running under kernel 2.4.18. I have my home filesystem mounted to /export/home (local xfs). Furthermore I have mounted a (local xfs) filesystem into /export/home/foobar/bighd. Using the automounter I mount /export/home/* to /home: # /etc/auto.home foobar MyServer:/export/home/& This is the auto.home map on the machine where /export/home is physically located. Now when I access /home/foobar the directory /export/home/foobar is bound to /home/foobar: /export/home/foobar on /home/foobar type none (rw,bind) HOWEVER /home/foobar/bighd is EMPTY, while /export/home/foobar/bighd is POPULATED. I know there's an issue with the kernel NFS daemon re. this "multiplexing" (is this the right term?), but curiously this has worked before with autofs 3.1.4 (debian version "3.1.4-9"), and I know I haven't changed my setup (read "configuration") apart from upgrading the machine from "stable" to "testing" (and thusly upgrading autofs from 3.1.4 to 3.9.99,) and from upgrading the kernel from 2.4.17 to 2.4.18. Any idea what's going on here? Could the problem be XFS related? 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 Wed Apr 17 02:31:44 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3H9Vi8d013469 for ; Wed, 17 Apr 2002 02:31:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3H9VixU013468 for linux-xfs-outgoing; Wed, 17 Apr 2002 02:31:44 -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 g3H9VZ8d013430 for ; Wed, 17 Apr 2002 02:31:35 -0700 Received: from erbenson.alaska.net (20-pm21.nwc.alaska.net [209.112.143.20]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3H9WVw35513 for ; Wed, 17 Apr 2002 01:32:31 -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 8EB0B3977 for ; Wed, 17 Apr 2002 01:32:30 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 7C48E10285; Wed, 17 Apr 2002 01:32:30 -0800 (AKDT) Date: Wed, 17 Apr 2002 01:32:30 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: quota on xfs Message-ID: <20020417013230.H20630@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020417065035.GA16162@ids.org.au> <20020416232750.F20630@plato.local.lan> <3CBD39B1.5090802@koschikode.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QwZB9vYiNIzNXIj" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CBD39B1.5090802@koschikode.com>; from juri@koschikode.com on Wed, Apr 17, 2002 at 11:00:33AM +0200 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --+QwZB9vYiNIzNXIj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2002 at 11:00:33AM +0200, Juri Haberland wrote: > Ethan Benson wrote: >=20 > > basically the quota syscalls are returning -EPERM for non-root, this > > is a bug in the 2.4.18 split XFS patches, the following patch will > > fix it: > >=20 > > $ diff -Naur quota.c.orig quota.c > > --- quota.c.orig Mon Mar 25 12:19:57 2002 > > +++ quota.c Mon Mar 25 12:20:55 2002 >=20 > [patch snipped] >=20 > > this is already merged in the XFS cvs tree. >=20 > Uhm, what XFS cvs tree are you talking about? I cannot find this in the= =20 the 2.4 SGI linux-xfs tree, i know of only one mentioned on thier page... > current 2.4.18 tree. A kernel checked out on 8th April still exhibits=20 > this behaviour and I just updated and linux/fs/quota.c wasn't modified... >=20 > What am I overlooking? I am pretty sure i saw a TAKE message from Nathan shortly after i reported the problem where he merged the patch he sent me (which is is what i posted above). you would have to ask him about that. if you apply the patch i gave you it will fix the problem though. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --+QwZB9vYiNIzNXIj 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 iEYEARECAAYFAjy9QS4ACgkQJKx7GixEevz3fQCfcG9KSIrHctSm2Gi8sJBdj90V yfsAnApLtIRnkzPGI/h0pRSbmfcnuz7A =sq3M -----END PGP SIGNATURE----- --+QwZB9vYiNIzNXIj-- From owner-linux-xfs@oss.sgi.com Wed Apr 17 03:04:38 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HA4c8d015080 for ; Wed, 17 Apr 2002 03:04:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HA4cQb015079 for linux-xfs-outgoing; Wed, 17 Apr 2002 03:04:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HA4K8d015031 for ; Wed, 17 Apr 2002 03:04:21 -0700 Received: from warp9.koschikode.com (pD95174A3.dip.t-dialin.net [217.81.116.163]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id B8254F4FC; Wed, 17 Apr 2002 12:05:14 +0200 (CEST) Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id 4EF47A9; Wed, 17 Apr 2002 12:05:03 +0200 (CEST) Message-ID: <3CBD48CE.8040301@koschikode.com> Date: Wed, 17 Apr 2002 12:05:02 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020407 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Cc: Nathan Scott Subject: Re: quota on xfs References: <20020417065035.GA16162@ids.org.au> <20020416232750.F20630@plato.local.lan> <3CBD39B1.5090802@koschikode.com> <20020417013230.H20630@plato.local.lan> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson wrote: > On Wed, Apr 17, 2002 at 11:00:33AM +0200, Juri Haberland wrote: >> Ethan Benson wrote: >> >> > basically the quota syscalls are returning -EPERM for non-root, this >> > is a bug in the 2.4.18 split XFS patches, the following patch will >> > fix it: >> > >> > $ diff -Naur quota.c.orig quota.c >> > --- quota.c.orig Mon Mar 25 12:19:57 2002 >> > +++ quota.c Mon Mar 25 12:20:55 2002 >> >> [patch snipped] >> >> > this is already merged in the XFS cvs tree. >> >> Uhm, what XFS cvs tree are you talking about? I cannot find this in the > > the 2.4 SGI linux-xfs tree, i know of only one mentioned on thier page... Could have been the 2.5-tree ;) >> current 2.4.18 tree. A kernel checked out on 8th April still exhibits >> this behaviour and I just updated and linux/fs/quota.c wasn't modified... >> >> What am I overlooking? > > I am pretty sure i saw a TAKE message from Nathan shortly after i > reported the problem where he merged the patch he sent me (which is is > what i posted above). you would have to ask him about that. if you > apply the patch i gave you it will fix the problem though. Patch won't apply because linux/fs/quota.c is different. I found the TAKE message - the fix is applied to cmd/xfsmisc/2.4.18-pre3-ac2-quotactl.patch... So it seems to me that a 2.4.18 kernel checked out directly from CVS still has this problem. Nathan? Juri From owner-linux-xfs@oss.sgi.com Wed Apr 17 04:46:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HBkM8d019822 for ; Wed, 17 Apr 2002 04:46:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HBkMI1019821 for linux-xfs-outgoing; Wed, 17 Apr 2002 04:46:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rrzs2.rz.uni-regensburg.de (rrzs2.rz.uni-regensburg.de [132.199.1.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HBkA8d019785 for ; Wed, 17 Apr 2002 04:46:12 -0700 Received: from pc9391 (guc28561@pc9391.physik.uni-regensburg.de [132.199.98.219]) by rrzs2.rz.uni-regensburg.de (8.9.3/8.9.3-URRZ-Sol-2.7-01) with ESMTP id NAA18494 for ; Wed, 17 Apr 2002 13:47:07 +0200 (MET DST) Date: Wed, 17 Apr 2002 13:47:04 +0200 From: Christian Guggenberger To: linux-xfs@oss.sgi.com Subject: Re: Oops 2.4.18 + RAID5 - me too Message-ID: <20020417134704.A12027@pc9391.uni-regensburg.de> Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Balsa 1.2.3 Lines: 74 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi there! We've been experiencing similiar Problems like Daryl has. Seems to be nfs related. Ok, lets tell about our hardware. Dual PIII@800MHz(Coppermine) on a MSI-6321 Board. # /sbin/lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT82C693A/694x [Apollo PRO133x] (rev c4) 00:01.0 PCI bridge: VIA Technologies, Inc. VT82C598/694x [Apollo MVP3/Pro133x AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 20) 00:0c.0 Unknown mass storage controller: Promise Technology, Inc. 20265 (rev 02) 00:0f.0 Ethernet controller: 3Com Corporation 3c905C-TX [Fast Etherlink] (rev 74) 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c) # free total used free shared buffers cached Mem: 1029976 507836 522140 0 624 272712 -/+ buffers/cache: 234500 795476 Swap: 2000084 3392 1996692 #dmesg ----cut---- hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(66) hdc: 195371568 sectors (100030 MB) w/2048KiB Cache, CHS=193821/16/63, UDMA(66) hdd: 195371568 sectors (100030 MB) w/2048KiB Cache, CHS=193821/16/63, UDMA(66) hde: 195371568 sectors (100030 MB) w/2048KiB Cache, CHS=193821/16/63, UDMA(100) hdf: 195371568 sectors (100030 MB) w/2048KiB Cache, CHS=193821/16/63, UDMA(100) hdg: 195371568 sectors (100030 MB) w/2048KiB Cache, CHS=193821/16/63, UDMA(100) hdh: 195371568 sectors (100030 MB) w/2048KiB Cache, CHS=193821/16/63, UDMA(100) ----cut---- (Software)-Raid5 consists of 6 Western Digital 100G hardiscs (WDC WD1000BB-00CCB0), 2 of them connected as hdc,hdd on onboard Via Controller, the rest connected to onboard Promise PDC20265. System is Debian-Testing(last update: early February). Raid5 is exported to about 150 clients (Linux and Sun Solaris). What's our Problem? This machine had been running stable for about 100days with kernel-2.4.14 and xfs-1.0.2, but then crashed and wouldn't boot anymore.(At this time, the Raid was about 70% full). Kernel locked while trying to initialize the Promise controller.We then switched to 2.4.18 and xfs(dated March 3), but still no luck. After installing a new Bios Version including a new Promise-Bios these problems were gone, but those nfs-related began!! Even under normal nfs load this machine crashed. Now i switched back to 2.4.14 + xfs-1.0.2 and my problems seem to have gone.... btw.: I didn't try xfs-1.1PR4 What could be wrong with linux-2.4.18-xfs, any ideas ?? Thx Christian From owner-linux-xfs@oss.sgi.com Wed Apr 17 05:59:11 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HCxB8d023094 for ; Wed, 17 Apr 2002 05:59:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HCxBQj023093 for linux-xfs-outgoing; Wed, 17 Apr 2002 05:59:11 -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 g3HCwx8d023055 for ; Wed, 17 Apr 2002 05:59:00 -0700 Received: from erbenson.alaska.net (20-pm21.nwc.alaska.net [209.112.143.20]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3HCxqC26408 for ; Wed, 17 Apr 2002 04:59:56 -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 7F27B3977 for ; Wed, 17 Apr 2002 04:59:50 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id DD3E410285; Wed, 17 Apr 2002 04:59:50 -0800 (AKDT) Date: Wed, 17 Apr 2002 04:59:50 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: possible race in remount read-only Message-ID: <20020417045950.I20630@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="poJSiGMzRSvrLGLs" 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. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --poJSiGMzRSvrLGLs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I use debian and have apt configured to remount /usr read-write prior to installing packages and then remount it read-only again after its done, however today the /usr partition ended up deadlocked and the box had to be reset. i was still able to gather some information about what was going on, what ps revealed is that a process started in the background by one of the debian package postinst scripts (update-menus) had issued a=20 rm command at the very same time as the=20 mount -o remount,ro /usr was run, both were stuck in a D state.=20=20 files already opened/cached from /usr could still be accessed, but attempting to access anything uncatched (say ls /usr) would result in that process going into a D state, as you would expect the box deteriorated into a more and more crippled state fairly quickly. also after having to reset the box a couple files were completly replaced with nulls, this is not really unexpected in most of the cases i found (files open read/write probably being updated when i had to finally reset (i tried a clean shutdown first). however /etc/inetd.conf was also completly replaced with nulls, which i find quite odd since 1) i don't have inetd even running, and 2) it has not been touched or should have even been accessed in the machines entire uptime.=20 also one shared library from the xlibs package (libXm or so) was missing, however this was not one of the packages being upgraded. one the next boot i don't think /usr required any recovery, xfs_repair and xfs_check report no problems. my own verification tests show no other corruption there. also there were no log entries or kernel messages, and no filesystem shutdown.=20=20 /usr /var / and /home are all separate partitions. kernel is 2.4.18 with the split patches, on the powerpc arch. i doubt i could reproduce this again if i tried. from my observation of the rm and mount processes simultaniously deadlocked it smells to me like a very tight race condition in the kernel somewhere. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --poJSiGMzRSvrLGLs 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 iEYEARECAAYFAjy9ccYACgkQJKx7GixEevyuPwCgnVzhNmYlt2kdut2JrHruCoCA SdcAn2KpKIz0mqSbj55EBtq6f+rUdF+l =StIk -----END PGP SIGNATURE----- --poJSiGMzRSvrLGLs-- From owner-linux-xfs@oss.sgi.com Wed Apr 17 06:39:18 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HDdI8d025074 for ; Wed, 17 Apr 2002 06:39:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HDdITJ025073 for linux-xfs-outgoing; Wed, 17 Apr 2002 06:39:18 -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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HDd98d025035 for ; Wed, 17 Apr 2002 06:39:10 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA99882; Wed, 17 Apr 2002 08:40: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 IAA75600; Wed, 17 Apr 2002 08:40:02 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3HDbh922734; Wed, 17 Apr 2002 08:37:43 -0500 Subject: Re: 2 questions From: Steve Lord To: Simon Matter Cc: Seth Mos , Libor =?ISO-8859-1?Q?Van=ECk?= , linux-xfs@oss.sgi.com In-Reply-To: <3CBD1C74.893FA6CB@ch.sauter-bc.com> References: <4.3.2.7.2.20020412155435.038711c8@pop.xs4all.nl> <3CB6E981.8C29617F@ch.sauter-bc.com> <1018969527.24543.8.camel@jen.americas.sgi.com> <3CBD1C74.893FA6CB@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 17 Apr 2002 08:37:42 -0500 Message-Id: <1019050662.24543.44.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-04-17 at 01:55, Simon Matter wrote: > > This is what I meant: > > +----------+ +----------+ +----------+ > | Server0 | | Server1 | | Server2 | > | | | | | | > | | | | | | > | /nbd0 | | /nbd1 | | /nbd2 | > | ^ | | ^ | | ^ | > +-----|----+ +-----|----+ +-----|----+ > | | | > | | | > | | | > | \-------\ | > | | | > | | | > | | | > | +-------------------|--+ | > | | Big Iron | | | > | | | | | > | | | | | > | | | | | > \----------->/dev/nbd0 | | | > | /dev/nbd1 <-/ | | > | /dev/nbd2 <-----------/ > | | > | /dev/md0:RAID5 { | > | /dev/nbd0 | > | /dev/nbd1 | > | /dev/nbd2 } | > | | > | | > | XFS on /dev/md0 | > | | > +----------------------+ > > Is _this_ dangerous or did you get me wrong? IIRC it has worked perfect > and I didn't see any corruption. > > -Simon > That should work just fine, I was interpreting things differently, mounts on all the nodes, not just on one node. I was wading through 12 days of email backlog at the time. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Apr 17 07:37:46 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HEbk8d027552 for ; Wed, 17 Apr 2002 07:37:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HEbkA8027551 for linux-xfs-outgoing; Wed, 17 Apr 2002 07:37:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.beyond.ca ([139.142.153.220]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HEbf8d027523 for ; Wed, 17 Apr 2002 07:37:42 -0700 Received: from x by beyond.ca with SMTP (MDaemon.v3.5.3.R) for ; Wed, 17 Apr 2002 08:39:39 -0600 Message-ID: <000701c1e61d$af2370a0$c774e80c@x> From: "x" To: Subject: bsdgroups? Date: Wed, 17 Apr 2002 07:39:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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-Return-Path: x@srtek.net X-MDaemon-Deliver-To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In the future, do you plan to support 'bsdgroups' ? grpid or bsdgroups / nogrpid or sysvgroups These options define what group id a newly created file gets. When grpid is set, it takes the group id of the directory in which it is created; other­ wise (the default) it takes the fsgid of the cur­ rent process, unless the directory has the setgid bit set, in which case it takes the gid from the parent directory, and also gets the setgid bit set if it is a directory itself. Thanks -Garrett From owner-linux-xfs@oss.sgi.com Wed Apr 17 07:46:55 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HEkt8d028129 for ; Wed, 17 Apr 2002 07:46:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HEktT7028128 for linux-xfs-outgoing; Wed, 17 Apr 2002 07:46:55 -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 g3HEko8d028094 for ; Wed, 17 Apr 2002 07:46:51 -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 g3HElmKB095646 for ; Wed, 17 Apr 2002 10:47:48 -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 g3HEllR250828 for ; Wed, 17 Apr 2002 08:47:47 -0600 Subject: DMAPI bug in dm_file_getattr() To: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Wed, 17 Apr 2002 09:47:45 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 04/17/2002 08:47:46 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk 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? 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 Apr 17 08:05:02 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HF528d029118 for ; Wed, 17 Apr 2002 08:05:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HF52Fe029117 for linux-xfs-outgoing; Wed, 17 Apr 2002 08:05:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from esme.webscreen-technology.com (host217-37-4-59.in-addr.btopenworld.com [217.37.4.59]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HF4s8d029078 for ; Wed, 17 Apr 2002 08:04:55 -0700 Received: from host217-37-4-60.in-addr.btopenworld.com ([217.37.4.60] helo=gbdesktop) by esme.webscreen-technology.com with smtp (Exim 3.34 #2) id 16xr0K-0003gT-00 for linux-xfs@oss.sgi.com; Wed, 17 Apr 2002 15:05:52 +0000 From: "Gareth Blades" To: "Xfs" Subject: Upgrading root partion & Grub Date: Wed, 17 Apr 2002 16:05:50 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Here is my current setup:- Redhat 7.2 XFS kernel installed together with all tools including the Grub upgrade RPM. /dev/md0 raid1 comprising of /dev/sda1 and /dev/sdb1 /dev/md1 raid1 comprising of /dev/sda3 and /dev/sdb3 /dev/md1 has already been converted to XFS under /data and works fine. Now I wish to convert the root partition to XFS so that I can use xfsdump to backup both partitions. I have used the instructions on the website to copy the root partition onto a new drive /dev/sdc1 Here is a copy of my current gub.conf:- default=0 timeout=4 splashimage=(hd0,0)/boot/grub/splash.xpm.gz title Red Hat Linux (2.4.9-31SGI_XFS_1.0.2) root (hd0,0) kernel /boot/vmlinuz-2.4.9-31SGI_XFS_1.0.2 ro root=/dev/md0 initrd /boot/initrd-2.4.9-31SGI_XFS_1.0.2.img title Red Hat Linux (2.4.7-10) root (hd0,0) kernel /boot/vmlinuz-2.4.7-10 ro root=/dev/md0 initrd /boot/initrd-2.4.7-10.img The next step is to get the system to boot off the new drive. I would specify root=/dev/sdc1 for the kernel but what would I specify for the 'root (hdx,x)' parameter? If this works and I convert and copy back /dev/sdc1 to /dev/md0 will grub then be able to find the information it needs to boot considering there is no separate /boot partition? Thanks -- Gareth Blades From owner-linux-xfs@oss.sgi.com Wed Apr 17 08:31:12 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HFVC8d030431 for ; Wed, 17 Apr 2002 08:31:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HFVCS7030430 for linux-xfs-outgoing; Wed, 17 Apr 2002 08:31: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HFV78d030398 for ; Wed, 17 Apr 2002 08:31:07 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA07272 for ; Wed, 17 Apr 2002 10:32: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 KAA30206 for ; Wed, 17 Apr 2002 10:32:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3HFTeG00685; Wed, 17 Apr 2002 10:29:40 -0500 Message-Id: <200204171529.g3HFTeG00685@jen.americas.sgi.com> Date: Wed, 17 Apr 2002 10:29:40 -0500 Subject: TAKE - fix bounds checking on kdb stack backtrace command To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A 2.5 only change Date: Wed Apr 17 08:31:10 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:116578a linux/arch/i386/kdb/kdba_bt.c - 1.13 - fix bounds checking on kdb stack backtrace command From owner-linux-xfs@oss.sgi.com Wed Apr 17 09:14:42 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HGEg8d032426 for ; Wed, 17 Apr 2002 09:14:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HGEfKl032424 for linux-xfs-outgoing; Wed, 17 Apr 2002 09:14: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HGEY8d032389 for ; Wed, 17 Apr 2002 09:14:34 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA03198; Wed, 17 Apr 2002 11:15:27 -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 LAA86996; Wed, 17 Apr 2002 11:15:27 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id LAA72405; Wed, 17 Apr 2002 11:15:27 -0500 (CDT) Message-Id: <200204171615.LAA72405@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI bug in dm_file_getattr() Date: Wed, 17 Apr 2002 11:15:26 -0500 From: Dean Roehrich 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? Not fixed. Sounds like a repeat of something Francis reported a few weeks ago (appended), which is sitting on my list of things to do. I guess this is a bigger problem than I had thought. :) Dean >>Subject: DMAPI dm_set_region >>From: "Francis Qu" >>Date: Wed, 20 Mar 2002 18:01:05 EST >>To: >> >>When DMAPI application tries to do dm_set_region on a file which is opened for >>write, both DMAPI application and the user application doing the write operatio >>n are blocked. The DMAPI application won't come back from dm_set_region utill t >>he user cancels the write job. Is it the way DMAPI works? >> >>Thanks. >> >>Francis From owner-linux-xfs@oss.sgi.com Wed Apr 17 09:54:34 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HGsY8d001751 for ; Wed, 17 Apr 2002 09:54:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HGsYHQ001750 for linux-xfs-outgoing; Wed, 17 Apr 2002 09:54:34 -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.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HGsR8d001697 for ; Wed, 17 Apr 2002 09:54:28 -0700 Received: (qmail 28623 invoked by uid 500); 17 Apr 2002 16:54:54 -0000 Subject: [Off Topic] Anyone running Oracle9i on Sun? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-3ZYwYVS9IWJSQjX78CfZ" X-Mailer: Ximian Evolution 1.0.3.99 Date: 17 Apr 2002 11:54:54 -0500 Message-Id: <1019062494.28605.1.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-3ZYwYVS9IWJSQjX78CfZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Please reply off-list. If anyone is running 9i on an E4500 with FC disks, please respond. I've got a few questions about performance, versus 8i.=20 TIA --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-3ZYwYVS9IWJSQjX78CfZ 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 iD4DBQA8vaje94g6ZVmFMoIRAuAjAJjv8vQPQJwruMdOUCey4AaNogc2AJ0ffzh/ EQ5+z8K2SDHj5tMMZAvXtA== =AAcG -----END PGP SIGNATURE----- --=-3ZYwYVS9IWJSQjX78CfZ-- From owner-linux-xfs@oss.sgi.com Wed Apr 17 09:55:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HGtJ8d001833 for ; Wed, 17 Apr 2002 09:55:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HGtJhB001832 for linux-xfs-outgoing; Wed, 17 Apr 2002 09:55:19 -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 g3HGt78d001795 for ; Wed, 17 Apr 2002 09:55:08 -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 g3HGu4KB041814; Wed, 17 Apr 2002 12:56:05 -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 g3HGu2R266878; Wed, 17 Apr 2002 10:56:03 -0600 Subject: Re: DMAPI bug in dm_file_getattr() To: Dean Roehrich Cc: linux-xfs@oss.sgi.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "James A Goodwin" Date: Wed, 17 Apr 2002 11:56:00 -0500 X-MIMETrack: Serialize by Router on D03NM800/03/M/IBM(Release 5.0.9 |November 16, 2001) at 04/17/2002 10:56:03 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Dean, Yeah this is a big problem. Users won't appreciate it when the filesystem hangs every time they append to a file. When you have a fix ready, what software levels (kernel and XFS) will I need to be running on to use it? Also, do you have a time frame for this? Our testing cycle is coming to a close very soon, so we'll take it as soon as you can dish it out. 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 Sent by: Subject: Re: DMAPI bug in dm_file_getattr() owner-linux-xfs@o ss.sgi.com 04/17/2002 11:15 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? Not fixed. Sounds like a repeat of something Francis reported a few weeks ago (appended), which is sitting on my list of things to do. I guess this is a bigger problem than I had thought. :) Dean >>Subject: DMAPI dm_set_region >>From: "Francis Qu" >>Date: Wed, 20 Mar 2002 18:01:05 EST >>To: >> >>When DMAPI application tries to do dm_set_region on a file which is opened for >>write, both DMAPI application and the user application doing the write operatio >>n are blocked. The DMAPI application won't come back from dm_set_region utill t >>he user cancels the write job. Is it the way DMAPI works? >> >>Thanks. >> >>Francis From owner-linux-xfs@oss.sgi.com Wed Apr 17 10:00:02 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HH028d002295 for ; Wed, 17 Apr 2002 10:00:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HH02ho002294 for linux-xfs-outgoing; Wed, 17 Apr 2002 10:00:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from paperboy.websocietyinc.com (paperboy.websocietyinc.com [209.20.64.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HGxw8d002250 for ; Wed, 17 Apr 2002 09:59:58 -0700 Received: (qmail 15257 invoked by uid 100); 17 Apr 2002 17:02:24 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Apr 2002 17:02:24 -0000 Date: Wed, 17 Apr 2002 10:02:24 -0700 (PDT) From: Justin Coffey To: Austin Gonyou cc: linux-xfs@oss.sgi.com Subject: Re: [Off Topic] Anyone running Oracle9i on Sun? In-Reply-To: <1019062494.28605.1.camel@UberGeek> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Actually, could you include me on that? We've got the same senario here (we're running Oracle 8.0.6, though). Our box is 12 proc e4500 10GB of memory off of a T3 fibre array. Thanks! > Please reply off-list. If anyone is running 9i on an E4500 with FC > disks, please respond. I've got a few questions about performance, > versus 8i. > > TIA > -- ------------------------------------------------------------------------ Justin Coffey 858.535.9332 x 2025 Technical Advisor justin@homes.com Homes.com, Inc. http://homes.com ------------------------------------------------------------------------ From owner-linux-xfs@oss.sgi.com Wed Apr 17 11:48:06 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HIm68d008167 for ; Wed, 17 Apr 2002 11:48:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HIm5vp008166 for linux-xfs-outgoing; Wed, 17 Apr 2002 11:48: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HIm18d008135 for ; Wed, 17 Apr 2002 11:48:01 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id NAA08933 for ; Wed, 17 Apr 2002 13:48:55 -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 NAA95933 for ; Wed, 17 Apr 2002 13:48:55 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3HImtG02573; Wed, 17 Apr 2002 13:48:55 -0500 Message-Id: <200204171848.g3HImtG02573@stout.americas.sgi.com> Date: Wed, 17 Apr 2002 13:48:55 -0500 Subject: TAKE - Fix error handling in xfs_log_recover.c Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Apr 17 11:48:15 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:116597a linux/fs/xfs/xfs_log_recover.c - 1.223 - Various points in this file return -ENOMEM on linux, this was not being handled correctly in some spots. Either error returns were not checked, or -ENOMEM treated the same as a return of -1, which is actually a "normal" return from xlog_find_verify_cycle. From owner-linux-xfs@oss.sgi.com Wed Apr 17 12:12:41 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HJCf8d009608 for ; Wed, 17 Apr 2002 12:12:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HJCfgp009607 for linux-xfs-outgoing; Wed, 17 Apr 2002 12:12: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HJCa8d009575 for ; Wed, 17 Apr 2002 12:12:37 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA10040; Wed, 17 Apr 2002 14:13:30 -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 OAA64581; Wed, 17 Apr 2002 14:13:30 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id OAA71312; Wed, 17 Apr 2002 14:13:30 -0500 (CDT) Message-Id: <200204171913.OAA71312@slobber.americas.sgi.com> To: "James A Goodwin" cc: linux-xfs@oss.sgi.com Subject: Re: DMAPI bug in dm_file_getattr() Date: Wed, 17 Apr 2002 14:13:29 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "James A Goodwin" > >Dean, > >Yeah this is a big problem. Users won't appreciate it when the filesystem >hangs every time they append to a file. > >When you have a fix ready, what software levels (kernel and XFS) will I >need to be running on to use it? Also, do you have a time frame for this? >Our testing cycle is coming to a close very soon, so we'll take it as soon >as you can dish it out. I'm not sure about the software levels--at some point I'll just tell you to get the latest XFS stuff via CVS :) Dean From owner-linux-xfs@oss.sgi.com Wed Apr 17 12:33:26 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HJXQ8d014238 for ; Wed, 17 Apr 2002 12:33:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HJXQML014237 for linux-xfs-outgoing; Wed, 17 Apr 2002 12:33: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 g3HJXE8d014197 for ; Wed, 17 Apr 2002 12:33:15 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx08)) with ESMTP id 16C50615A; Wed, 17 Apr 2002 21:34: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 VAA12810; Wed, 17 Apr 2002 21:34:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 71C0157306; Wed, 17 Apr 2002 21:33: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 2B55D25835; Wed, 17 Apr 2002 21:33:24 +0200 (CEST) Message-ID: <3CBDCE04.25817CC6@ch.sauter-bc.com> Date: Wed, 17 Apr 2002 21:33:24 +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: Gareth Blades Cc: Xfs Subject: Re: Upgrading root partion & Grub References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Gareth Blades schrieb: > > Here is my current setup:- > > Redhat 7.2 XFS kernel installed together with all tools including the Grub > upgrade RPM. Hi Gareth, Did you use LILO when you first installed your system? I don't know what happens exactly if you only upgrade GRUB but read below what could be your problem: GRUB has two big problems: The first problem with GRUB is that it does not work well with software raid. anaconda is prepared to correctly install GRUB at install time but later installs with 'grub-install' fail. The 'grub-install' script only supports floppy and IDE/SCSI harddisks, no MD device. The second problem with GRUB is that if you have mirrored disks and the first disk fails, you end up in a non bootable system because the second disk does not contain a valid MBR. LILO handles this correctly, I mean if you tell LILO to install on /dev/md0, it will install an MBR on every disk which is part of /dev/md0. Now, I don't know why RedHat defaults to GRUB. BTW: This problem has nothing to do with XFS. -Simon > > /dev/md0 raid1 comprising of /dev/sda1 and /dev/sdb1 > /dev/md1 raid1 comprising of /dev/sda3 and /dev/sdb3 > > /dev/md1 has already been converted to XFS under /data and works fine. > > Now I wish to convert the root partition to XFS so that I can use xfsdump to > backup both partitions. > > I have used the instructions on the website to copy the root partition onto > a new drive /dev/sdc1 > > Here is a copy of my current gub.conf:- > > default=0 > timeout=4 > splashimage=(hd0,0)/boot/grub/splash.xpm.gz > title Red Hat Linux (2.4.9-31SGI_XFS_1.0.2) > root (hd0,0) > kernel /boot/vmlinuz-2.4.9-31SGI_XFS_1.0.2 ro root=/dev/md0 > initrd /boot/initrd-2.4.9-31SGI_XFS_1.0.2.img > title Red Hat Linux (2.4.7-10) > root (hd0,0) > kernel /boot/vmlinuz-2.4.7-10 ro root=/dev/md0 > initrd /boot/initrd-2.4.7-10.img > > The next step is to get the system to boot off the new drive. I would > specify root=/dev/sdc1 for the kernel but what would I specify for the 'root > (hdx,x)' parameter? > > If this works and I convert and copy back /dev/sdc1 to /dev/md0 will grub > then be able to find the information it needs to boot considering there is > no separate /boot partition? > > Thanks > > -- > Gareth Blades From owner-linux-xfs@oss.sgi.com Wed Apr 17 12:51:57 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HJpv8d015301 for ; Wed, 17 Apr 2002 12:51:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HJpvL6015300 for linux-xfs-outgoing; Wed, 17 Apr 2002 12:51:57 -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 g3HJpr8d015267 for ; Wed, 17 Apr 2002 12:51:54 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id D20F0401A40; Wed, 17 Apr 2002 15:53:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id D0381C0EDEC; Wed, 17 Apr 2002 15:53:03 -0400 (EDT) Date: Wed, 17 Apr 2002 15:53:03 -0400 (EDT) From: Mike Burger To: Simon Matter Cc: Gareth Blades , Xfs Subject: Re: Upgrading root partion & Grub In-Reply-To: <3CBDCE04.25817CC6@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Even my 7.2 install didn't default to Grub...it gave me a choice. On Wed, 17 Apr 2002, Simon Matter wrote: > Now, I don't know why RedHat defaults to GRUB. > > BTW: This problem has nothing to do with XFS. > > -Simon From owner-linux-xfs@oss.sgi.com Wed Apr 17 14:57:44 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HLvh8d022141 for ; Wed, 17 Apr 2002 14:57:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HLvhJB022140 for linux-xfs-outgoing; Wed, 17 Apr 2002 14:57: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HLvI8d022091 for ; Wed, 17 Apr 2002 14:57:19 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA11058 for ; Wed, 17 Apr 2002 16:58: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 QAA27694 for ; Wed, 17 Apr 2002 16:58:12 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3HLwC503495; Wed, 17 Apr 2002 16:58:12 -0500 Message-Id: <200204172158.g3HLwC503495@stout.americas.sgi.com> Date: Wed, 17 Apr 2002 16:58:12 -0500 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk From: Eric Sandeen To: linux-xfs@oss.sgi.com Subject: [Announce] XFS for Linux 1.1 Released Content-Type: text/plain; charset=us-ascii Precedence: bulk SGI is pleased to announce the 1.1 release of XFS for Linux. Major improvements in this release include: * Faster deletes * Significantly reduced "null-file-after-crash" occurrences * New reserved Extended Attribute syscall interface * Restrict inodes to 32 bits on large filesystems More information can be found at http://oss.sgi.com/projects/xfs/1.1_release.html Files are available under ftp://oss.sgi.com/projects/xfs/download/Release-1.1/ This URL contains the following directories: kernel_rpms/linux-2.4.18/ 2.4.18 kernel RPMS based on vanilla 2.4.18 kernels (Linus' tree) with the XFS bits added. kernel_rpms/2.4.9-31/ 2.4.9-31 kernel RPMS based on Red Hat's 7.1/7.2 2.4.9-31 kernel release. Please not that these are NOT Red Hat kernels, and are in no way supported by Red Hat. kernel_patches/ The patches provided are for linux-2.4.18, for both x86 and ia64. See the README file in the patches/ directory for patching instructions. cmd_tars/ cmd_rpms/ Userspace commands are provided both as tarballs and as RPMs. CHANGES since 1.0.2: ==================== Kernel ------ * Removed most synchronous transactions - faster deletes, fewer chances for null files after a crash! * Various error code return fixes * Restrict inodes to 32 bits on large filesystems (override w/ mount option) * Fixed concurrent file and mmapped I/O * Fixed dbench hangs on low memory systems * Fixed recovery of device special inodes * Fixed mount argument parsing * Various pagebuf reorganization, simplification, and cleanup * Fixed parallel direct and buffered I/O * Code merges from IRIX * Pagebuf merged into xfs * Fixed out-of-line extended attribute data * Fixed forced shutdown bug that overwrote superblock :( * Improved memory allocation when not in a transaction * Limit max file size to something Linux can handle * Some realtime device fixes (still not complete) * Cleaned up xfs_freeze path * Report filesystem name on duplicate UUID mount failure * Shrink xfs inode size * Fixed some direct I/O corner cases * Fixed mount with bad log or realtime device options * Make "osyncisdsync" the default on xfs filesystems * Restrict chown to file's owner, or someone w/ the right capability * Upgraded quota to Jan Kara's 32-bit VFS quota * Fixed memory leak in O_DIRECT read path * Use new reserved ea/acl syscall numbers * Fixed some sparc64 compile problems * Make xfs superblock coherent with block layer * Pagebuf use after free fix * Don't allow quota flag changes on read-only device * Make xfs metadata accesses refresh pages, keep them in the cache * Fixed sgid inheritence for root * Corrected utime permissions checking * Reduced xfs log memory usage * Fixed a bug in memory freeing * Delete nfs refcache sbdirty timer on unmount * Make nfs refcache sbdirty timer for each fs, not global * Fix for inode32 mount option on > 1TB filesystems acl --- * Man page updates from Andreas * Test script updates from Andreas * Clean up the --default option handling in setfacl. The old workarounds caused a bug for unusual input. * Changes to the --test output format setfacl generates: ACLs that are not changed are now displayed as `*'. * Fixed a bug in setfacl/sequence.c:seq_delete_cmd() * Minor changes to test scripts * Apply several patches from Andreas, namely: * - man page fixes * - libacl code reformatting * - acl_from_text errno handling * Applied Andreas Gruenbacher's diffs * Fixed up chacl for deletion of access ACL to be in line with Andreas * Incorporated the Debian packaging again * Reworked to use the new official system call API * Sync up with the XFS project, the SGI folk now use this source * Jumped to version 2 to allow XFS users to upgrade (Rationale: the XFS ACL user tools were at version 1.1.X, and packaging tools like rpm, dpkg, etc. must be presented with a greater version number to allow an upgrade to proceed) * Added the chacl command to ease migration for existing XFS users, and for compatibility with IRIX * Added a flag to allow acl_print to produce a single-line ACL, in addition to the multi-line format * Extended attribute documentation has moved into the extended attribute package from SGI ("attr"), this ACL package now deals exclusively with ACLs * acl_from_text sometimes did not set errno when failing * Moved files and simplified #includes in libacl attr ---- * Add MIPS/MIPS64 system call numbers * Fixed build for architectures which don't have syscalls yet * Fixed the syscall number used on Sparc for fremovexattr(2) * Test script updates * Man page updates * A minor change to the test/run script * Added in ARM architecture system call numbers * Updates to the test output from Andreas * Added in S/390 system call numbers from Martin Schwidefsky * Revert IA64 syscall numbering after further mail with David Mosberger (apparently sys_tkill will be moved) See: https://external-lists.valinux.com/archives/linux-ia64/2002-February/002990.html * Incorporated several documentation changes from Andreas, including a script to convert from the aget format of attribute backup file, to the new getfattr format * Fixed IA64 syscall numbering * Initial introduction of the new system call interface * Synced up with the ext2 project, incorporated get/set tools * New man pages for system calls, getfattr(1) and setfattr(1) * Made the attributes.h interface align properly with IRIX DMAPI ----- * The kernel-side of dmapi is now a module, and the device has moved. Change dmapi to use the dmapi device in its new location of /proc/fs/xfs_dmapi. xfsprogs -------- * Fall back to BLKGETSIZE if BLKGETSIZE64 fails * Sync user/kernel headers and shared code * Major release to coincide with switch to new extended attributes system call interfaces * Bumped version of libhandle, added new symbols to use the reworked extended attributes handle ioctl interface * xfs_repair in no-modify mode opens the filesystem device read-only now (fix from Chris Pascoe) * Sync up with recent (minor) changes to shared kernel code * Switch to using the BLKGETSIZE64 ioctl in libxfs, instead of the (previously busted) BLKGETSIZE ioctl * Fixed xfs_repair option parsing for external logs * Added xfs_repair option parsing for realtime device * Fixed xfs_repair version (-V) option - should not require an argument * Added -V option to usage string * Document verbose (-v) and -r options in manpage * Fixed mkfs.xfs buglet in overwriting signatures when run on a regular file * mkfs.xfs overwrites pre-existing filesystem, swap, or md driver signatures. * xfs_repair fix to prevent double insertion into the uncertain_inode AVL trees ("avl_insert: duplicate range") * xfs_repair fix if the log is corrupted and we can't find the head, don't exit - just proceed on with zeroing it * Use snprintf instead of sprintf throughout * Added text dump type to xfs_db (mkp) * Removed use of a temporary file in xfs_db when processing commands on the command line - allows xfs_check to be run on read-only root filesystems * Reenable the use of the BLKBSZSET ioctl, its baaack * Sync recent XFS kernel source changes back into libxfs * Fixed minor debian package version numbering issue * Added documentation for xfs_db(8) label/uuid commands * Automatic inode sizing code in mkfs.xfs has been removed (restricting inodes to 32 bits) - Steve's recent kernel changes mean this is no longer an issue * Fixed bug in mkfs.xfs size cross-check for realtime device xfsdump/restore --------------- * Reworked all code dealing with extended attributes to use the new system calls (requires attr-2.0.0 or greater) * The attrctl-by-handle ioctl is history, replaced by libhandle routines - more like what we have in IRIX (requires xfsprogs-2.0.0 or greater) * Effectively no-op change (cleanup) - switch over to using XFS_IOC_FSGEOMETRY instead of XFS_IOC_GETFSUUID ioctl, so we can deprecate that "special" UUID ioctl in the kernel. * Added -q description to xfsdump/xfsrestore man pages and usage text. * Change failed bulkstat WARNING to a TRACE message to that it doesn't bother people. * Avoid a possible assertion failure for cumulative restores with -B option. * Fixed xfsrestore so that cumulative restores (with -r) will successfully delete removed directories whose files have also been removed. Previously, the files weren't removed until later, which meant that early directory removal failed. SGI bug#844219. * Fixed xfsdump so that if an inode# is reused in the time between building the inode map and pruning the inode map (in phase 3 when some dirs are marked as not changed), that it no longer aborts with an assertion failure. SGI bug#846374. * Added new -B option to xfsrestore to correctly assign ownership and permissions of the dump root directory to the destination directory * Ported back IRIX changes primarily to xfsrestore for improving performance when one has over a million files. * Some extra mlogs (messages) for dump estimates, dir tree diagnostics, type of dump format being used * Various fixes for restore with multiple threads and extended attributes (note: multiple threads not implemented on Linux yet) * Fix xfsdump to endian convert all of the record header fields properly just prior to writing the header out (in particular first_mark_offset). This caused do_next_mark() assertion failures at some sites. * Fixed xfsrestore so that it doesn't delete hardlinks on alternate cumulative restores * Allow xfsdump to exclude files based on whether they have a certain extended attribute set * Don't include /var/lib/xfsdump in the dump * misc ---- * Updated documentation. From owner-linux-xfs@oss.sgi.com Wed Apr 17 15:21:29 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HMLT8d023710 for ; Wed, 17 Apr 2002 15:21:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HMLTVW023709 for linux-xfs-outgoing; Wed, 17 Apr 2002 15:21: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HML68d023658 for ; Wed, 17 Apr 2002 15:21:07 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA50091 for ; Wed, 17 Apr 2002 17:22:01 -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 RAA69295 for ; Wed, 17 Apr 2002 17:22:01 -0500 (CDT) Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3HMM1T03726; Wed, 17 Apr 2002 17:22:01 -0500 Message-Id: <200204172222.g3HMM1T03726@stout.americas.sgi.com> Date: Wed, 17 Apr 2002 17:22:01 -0500 From: Eric Sandeen To: linux-xfs@oss.sgi.com Subject: [Announce] XFS for Linux 1.1 Released Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk SGI is pleased to announce the 1.1 release of XFS for Linux. Major improvements in this release include: * Faster deletes * Significantly reduced "null-file-after-crash" occurrences * New reserved Extended Attribute syscall interface * Restrict inodes to 32 bits on large filesystems More information can be found at http://oss.sgi.com/projects/xfs/1.1_release.html Files are available under ftp://oss.sgi.com/projects/xfs/download/Release-1.1/ This URL contains the following directories: kernel_rpms/linux-2.4.18/ 2.4.18 kernel RPMS based on vanilla 2.4.18 kernels (Linus' tree) with the XFS bits added. kernel_rpms/2.4.9-31/ 2.4.9-31 kernel RPMS based on Red Hat's 7.1/7.2 2.4.9-31 kernel release. Please not that these are NOT Red Hat kernels, and are in no way supported by Red Hat. kernel_patches/ The patches provided are for linux-2.4.18, for both x86 and ia64. See the README file in the patches/ directory for patching instructions. cmd_tars/ cmd_rpms/ Userspace commands are provided both as tarballs and as RPMs. CHANGES since 1.0.2: ==================== Kernel ------ * Removed most synchronous transactions - faster deletes, fewer chances for null files after a crash! * Various error code return fixes * Restrict inodes to 32 bits on large filesystems (override w/ mount option) * Fixed concurrent file and mmapped I/O * Fixed dbench hangs on low memory systems * Fixed recovery of device special inodes * Fixed mount argument parsing * Various pagebuf reorganization, simplification, and cleanup * Fixed parallel direct and buffered I/O * Code merges from IRIX * Pagebuf merged into xfs * Fixed out-of-line extended attribute data * Fixed forced shutdown bug that overwrote superblock :( * Improved memory allocation when not in a transaction * Limit max file size to something Linux can handle * Some realtime device fixes (still not complete) * Cleaned up xfs_freeze path * Report filesystem name on duplicate UUID mount failure * Shrink xfs inode size * Fixed some direct I/O corner cases * Fixed mount with bad log or realtime device options * Make "osyncisdsync" the default on xfs filesystems * Restrict chown to file's owner, or someone w/ the right capability * Upgraded quota to Jan Kara's 32-bit VFS quota * Fixed memory leak in O_DIRECT read path * Use new reserved ea/acl syscall numbers * Fixed some sparc64 compile problems * Make xfs superblock coherent with block layer * Pagebuf use after free fix * Don't allow quota flag changes on read-only device * Make xfs metadata accesses refresh pages, keep them in the cache * Fixed sgid inheritence for root * Corrected utime permissions checking * Reduced xfs log memory usage * Fixed a bug in memory freeing * Delete nfs refcache sbdirty timer on unmount * Make nfs refcache sbdirty timer for each fs, not global * Fix for inode32 mount option on > 1TB filesystems acl --- * Man page updates from Andreas * Test script updates from Andreas * Clean up the --default option handling in setfacl. The old workarounds caused a bug for unusual input. * Changes to the --test output format setfacl generates: ACLs that are not changed are now displayed as `*'. * Fixed a bug in setfacl/sequence.c:seq_delete_cmd() * Minor changes to test scripts * Apply several patches from Andreas, namely: * - man page fixes * - libacl code reformatting * - acl_from_text errno handling * Applied Andreas Gruenbacher's diffs * Fixed up chacl for deletion of access ACL to be in line with Andreas * Incorporated the Debian packaging again * Reworked to use the new official system call API * Sync up with the XFS project, the SGI folk now use this source * Jumped to version 2 to allow XFS users to upgrade (Rationale: the XFS ACL user tools were at version 1.1.X, and packaging tools like rpm, dpkg, etc. must be presented with a greater version number to allow an upgrade to proceed) * Added the chacl command to ease migration for existing XFS users, and for compatibility with IRIX * Added a flag to allow acl_print to produce a single-line ACL, in addition to the multi-line format * Extended attribute documentation has moved into the extended attribute package from SGI ("attr"), this ACL package now deals exclusively with ACLs * acl_from_text sometimes did not set errno when failing * Moved files and simplified #includes in libacl attr ---- * Add MIPS/MIPS64 system call numbers * Fixed build for architectures which don't have syscalls yet * Fixed the syscall number used on Sparc for fremovexattr(2) * Test script updates * Man page updates * A minor change to the test/run script * Added in ARM architecture system call numbers * Updates to the test output from Andreas * Added in S/390 system call numbers from Martin Schwidefsky * Revert IA64 syscall numbering after further mail with David Mosberger (apparently sys_tkill will be moved) See: https://external-lists.valinux.com/archives/linux-ia64/2002-February/002990.html * Incorporated several documentation changes from Andreas, including a script to convert from the aget format of attribute backup file, to the new getfattr format * Fixed IA64 syscall numbering * Initial introduction of the new system call interface * Synced up with the ext2 project, incorporated get/set tools * New man pages for system calls, getfattr(1) and setfattr(1) * Made the attributes.h interface align properly with IRIX DMAPI ----- * The kernel-side of dmapi is now a module, and the device has moved. Change dmapi to use the dmapi device in its new location of /proc/fs/xfs_dmapi. xfsprogs -------- * Fall back to BLKGETSIZE if BLKGETSIZE64 fails * Sync user/kernel headers and shared code * Major release to coincide with switch to new extended attributes system call interfaces * Bumped version of libhandle, added new symbols to use the reworked extended attributes handle ioctl interface * xfs_repair in no-modify mode opens the filesystem device read-only now (fix from Chris Pascoe) * Sync up with recent (minor) changes to shared kernel code * Switch to using the BLKGETSIZE64 ioctl in libxfs, instead of the (previously busted) BLKGETSIZE ioctl * Fixed xfs_repair option parsing for external logs * Added xfs_repair option parsing for realtime device * Fixed xfs_repair version (-V) option - should not require an argument * Added -V option to usage string * Document verbose (-v) and -r options in manpage * Fixed mkfs.xfs buglet in overwriting signatures when run on a regular file * mkfs.xfs overwrites pre-existing filesystem, swap, or md driver signatures. * xfs_repair fix to prevent double insertion into the uncertain_inode AVL trees ("avl_insert: duplicate range") * xfs_repair fix if the log is corrupted and we can't find the head, don't exit - just proceed on with zeroing it * Use snprintf instead of sprintf throughout * Added text dump type to xfs_db (mkp) * Removed use of a temporary file in xfs_db when processing commands on the command line - allows xfs_check to be run on read-only root filesystems * Reenable the use of the BLKBSZSET ioctl, its baaack * Sync recent XFS kernel source changes back into libxfs * Fixed minor debian package version numbering issue * Added documentation for xfs_db(8) label/uuid commands * Automatic inode sizing code in mkfs.xfs has been removed (restricting inodes to 32 bits) - Steve's recent kernel changes mean this is no longer an issue * Fixed bug in mkfs.xfs size cross-check for realtime device xfsdump/restore --------------- * Reworked all code dealing with extended attributes to use the new system calls (requires attr-2.0.0 or greater) * The attrctl-by-handle ioctl is history, replaced by libhandle routines - more like what we have in IRIX (requires xfsprogs-2.0.0 or greater) * Effectively no-op change (cleanup) - switch over to using XFS_IOC_FSGEOMETRY instead of XFS_IOC_GETFSUUID ioctl, so we can deprecate that "special" UUID ioctl in the kernel. * Added -q description to xfsdump/xfsrestore man pages and usage text. * Change failed bulkstat WARNING to a TRACE message to that it doesn't bother people. * Avoid a possible assertion failure for cumulative restores with -B option. * Fixed xfsrestore so that cumulative restores (with -r) will successfully delete removed directories whose files have also been removed. Previously, the files weren't removed until later, which meant that early directory removal failed. SGI bug#844219. * Fixed xfsdump so that if an inode# is reused in the time between building the inode map and pruning the inode map (in phase 3 when some dirs are marked as not changed), that it no longer aborts with an assertion failure. SGI bug#846374. * Added new -B option to xfsrestore to correctly assign ownership and permissions of the dump root directory to the destination directory * Ported back IRIX changes primarily to xfsrestore for improving performance when one has over a million files. * Some extra mlogs (messages) for dump estimates, dir tree diagnostics, type of dump format being used * Various fixes for restore with multiple threads and extended attributes (note: multiple threads not implemented on Linux yet) * Fix xfsdump to endian convert all of the record header fields properly just prior to writing the header out (in particular first_mark_offset). This caused do_next_mark() assertion failures at some sites. * Fixed xfsrestore so that it doesn't delete hardlinks on alternate cumulative restores * Allow xfsdump to exclude files based on whether they have a certain extended attribute set * Don't include /var/lib/xfsdump in the dump * misc ---- * Updated documentation. From owner-linux-xfs@oss.sgi.com Wed Apr 17 15:44:23 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HMiN8d025298 for ; Wed, 17 Apr 2002 15:44:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HMiNM4025297 for linux-xfs-outgoing; Wed, 17 Apr 2002 15:44:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from localhost.localdomain (IDENT:K2JtN6O03xFGs/F2hitprQ9yS6U0isOD@firewall.conet.cz [213.175.54.250]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HMiJ8d025271 for ; Wed, 17 Apr 2002 15:44:20 -0700 Received: from conet.cz (CoNetWin [192.168.1.110]) by localhost.localdomain (8.11.6/8.11.6) with ESMTP id g3HMjDm24783; Thu, 18 Apr 2002 00:45:14 +0200 Message-ID: <3CBDFA9E.4050101@conet.cz> Date: Thu, 18 Apr 2002 00:43:42 +0200 From: Libor Vanek User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS for Linux 1.1 Released References: <200204172222.g3HMM1T03726@stout.americas.sgi.com> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Great job! Really thanks! Libor From owner-linux-xfs@oss.sgi.com Wed Apr 17 16:11:41 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HNBf8d026873 for ; Wed, 17 Apr 2002 16:11:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HNBetL026872 for linux-xfs-outgoing; Wed, 17 Apr 2002 16:11:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HNBX8d026826 for ; Wed, 17 Apr 2002 16:11:33 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 16xyZ2-0000Q8-00; Wed, 17 Apr 2002 17:10:12 -0600 Message-ID: <3CBE015A.3070004@emergence.com> Date: Wed, 17 Apr 2002 17:12:26 -0600 From: Michael Best Reply-To: linux-xfs User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: arjanv@redhat.com CC: Greg Freemyer , linux-xfs Subject: Re: XFS installer and driver/update disks References: <20020415163720.LGBE20778.imf14bis.bellsouth.net@taz> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk In http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62072 you wrote: > > Product - Version Component Status Short Summary > > Red Hat Public Beta - skipjack-beta1 kernel CLOSED No XFS filesystem in the kernel > > Additional comment by arjanv@redhat.com 2002-04-17 03:51:34 > > This used to be a sane bug. Now it seems (via xfs ml etc) to be some sort of propaganda campain; I'm not interested in being the target of PR campaigns. Is there anything the XFS user community can do to help speed the adoption of XFS into Skipjack or a future (non 2.5 kernel) Redhat release? The XFS team at SGI is hard at getting XFS into the main kernel, and they do make kernel rpms for Redhat as well as an installer that have been of consistantly good quality. There are many users including myself using the XFS team installer + Redhat 7.1 or 7.2 and after trying Mandrake 8.1 and 8.2 that included XFS support I too was hoping that Redhat would include XFS if not in the main kernel, even if only in an optional kernel. In addition, the official XFS Team 1.1 release has just been announced. -- Michael Best Systems Administrator Emergence By Design, Inc. +1 780 413-6397 Greg Freemyer wrote: > >> The real problem is that RedHat does not include XFS in their kernel. > >> They ship it with 1001 patches applied but no XFS. It's a real pain. I > >> have then tried Skipjack-beta1 in the hope, they included XFS. Nothing. > >> I decided to call this a bug and posted it on bugzilla. > > >> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62072 > > >> I'm asking list members not to flame on bugzilla. I guess it won't help. > > >> -Simon From owner-linux-xfs@oss.sgi.com Wed Apr 17 16:35:17 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HNZH8d028155 for ; Wed, 17 Apr 2002 16:35:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HNZH0n028154 for linux-xfs-outgoing; Wed, 17 Apr 2002 16:35:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HNZB8d028122 for ; Wed, 17 Apr 2002 16:35:12 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3HNaAQR022438 for ; Wed, 17 Apr 2002 18:36:11 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3I0ZvBA019837; Wed, 17 Apr 2002 17:35:57 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3HNZtp43218386; Wed, 17 Apr 2002 16:35:55 -0700 (PDT) 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 JAA21633; Thu, 18 Apr 2002 09:35:48 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA51025; Thu, 18 Apr 2002 09:35:45 +1000 (AEST) Date: Thu, 18 Apr 2002 09:35:45 +1000 From: Nathan Scott To: Ethan Benson , Juri Haberland Cc: linux-xfs@thebarn.com Subject: Re: quota on xfs Message-ID: <20020418093544.C33861@wobbly.melbourne.sgi.com> References: <20020417065035.GA16162@ids.org.au> <20020416232750.F20630@plato.local.lan> <3CBD39B1.5090802@koschikode.com> <20020417013230.H20630@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: <20020417013230.H20630@plato.local.lan>; from erbenson@alaska.net on Wed, Apr 17, 2002 at 01:32:30AM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 17, 2002 at 01:32:30AM -0800, Ethan Benson wrote: > On Wed, Apr 17, 2002 at 11:00:33AM +0200, Juri Haberland wrote: > > > > What am I overlooking? > > I am pretty sure i saw a TAKE message from Nathan shortly after i > reported the problem where he merged the patch he sent me (which is is > what i posted above). you would have to ask him about that. if you > apply the patch i gave you it will fix the problem though. > That patch is for the 2.4.18 split patches. We now have another implementation of quota from Jan in CVS (so the patch wont apply there), sounds like it is busted in a similar way - I will have a quick look. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Apr 17 16:40:59 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HNex8d028571 for ; Wed, 17 Apr 2002 16:40:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HNewmO028570 for linux-xfs-outgoing; Wed, 17 Apr 2002 16:40:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.dada.it (mail2.dada.it [195.110.96.69]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HNej8d028532 for ; Wed, 17 Apr 2002 16:40:54 -0700 Received: (qmail 31941 invoked from network); 17 Apr 2002 23:41:33 -0000 Received: from unknown (HELO tribe) (195.110.114.109) by mail.dada.it with SMTP; 17 Apr 2002 23:41:33 -0000 Message-ID: <004701c1e669$afdaef40$2101a8c0@dada.it> Reply-To: "PiercingTribe" From: "PiercingTribe" To: Subject: trouble with xfs partition Date: Thu, 18 Apr 2002 01:43:32 +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 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello, im running big trouble with my xfs partition... all worked correctly for months... today, after a reboot (the server was locked and i hard-rebooted) it is no longer able to mount xfs partition (it locks everyting if i try, bot at boot or manually)... i entered the system without mounting the xfs partition, and i tried various tools (xfs_repair, and so)... nothing worked, the various check shows that the data is still on the disk, but xfs_repair keep making all the same operation (some lost+found reconnecting) but after it it still hang when mounting... anyone got some advice to save at least the data on the disk? im using kernel 2.4.14-xfs thanks lorenzo tribe@piercingtribe.it From owner-linux-xfs@oss.sgi.com Wed Apr 17 16:53:46 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HNrk8d029366 for ; Wed, 17 Apr 2002 16:53:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HNrkxn029365 for linux-xfs-outgoing; Wed, 17 Apr 2002 16:53:46 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HNrf8d029336 for ; Wed, 17 Apr 2002 16:53:42 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3HNseQR022581 for ; Wed, 17 Apr 2002 18:54:41 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3I0seBA020553 for ; Wed, 17 Apr 2002 17:54:40 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3HNscp42141179 for <@relay.sgi.com:linux-xfs@thebarn.com>; Wed, 17 Apr 2002 16:54:39 -0700 (PDT) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA21773 for ; Thu, 18 Apr 2002 09:54:35 +1000 Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA62857 for linux-xfs@thebarn.com; Thu, 18 Apr 2002 09:54:35 +1000 (EST) Date: Thu, 18 Apr 2002 09:54:35 +1000 (EST) From: Nathan Scott Message-Id: <200204172354.JAA62857@snort.melbourne.sgi.com> To: linux-xfs@thebarn.com Subject: TAKE - quota Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Wed Apr 17 16: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:116647a linux/fs/quota.c - 1.11 - Q_XGETQSTAT must be accessible to all, not just root. From owner-linux-xfs@oss.sgi.com Wed Apr 17 16:57:52 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3HNvq8d029705 for ; Wed, 17 Apr 2002 16:57:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3HNvq2w029704 for linux-xfs-outgoing; Wed, 17 Apr 2002 16:57:52 -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-d514e116.dsl.mediaWays.net [213.20.225.22]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3HNvn8d029674 for ; Wed, 17 Apr 2002 16:57:49 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16xzJz-0005PT-00; Thu, 18 Apr 2002 01:58:43 +0200 Message-ID: <3CBE0C33.DA76B9F5@berdmann.de> Date: Thu, 18 Apr 2002 01:58:43 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13SGI_XFS_1.0.2 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Eric Sandeen CC: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS for Linux 1.1 Released References: <200204172222.g3HMM1T03726@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > SGI is pleased to announce the 1.1 release of XFS for Linux. Well done! Thanks. From owner-linux-xfs@oss.sgi.com Wed Apr 17 17:36:09 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I0a98d031687 for ; Wed, 17 Apr 2002 17:36:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I0a9KM031686 for linux-xfs-outgoing; Wed, 17 Apr 2002 17:36:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I0a68d031654 for ; Wed, 17 Apr 2002 17:36:06 -0700 Received: from relative.emergence.com ([209.5.172.43] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 16xzss-0000SB-00 for linux-xfs@oss.sgi.com; Wed, 17 Apr 2002 18:34:46 -0600 Message-ID: <3CBE152D.8000001@emergence.com> Date: Wed, 17 Apr 2002 18:37:01 -0600 From: Michael Best User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs Subject: Re: [Announce] XFS for Linux 1.1 Released References: <200204172222.g3HMM1T03726@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has there been any work on either a 7.2 or Skipjack Redhat Installer ISO? -Mike Eric Sandeen wrote: > SGI is pleased to announce the 1.1 release of XFS for Linux. From owner-linux-xfs@oss.sgi.com Wed Apr 17 17:51:29 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I0pS8d032649 for ; Wed, 17 Apr 2002 17:51:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I0pSxb032648 for linux-xfs-outgoing; Wed, 17 Apr 2002 17:51:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I0pJ8d032621 for ; Wed, 17 Apr 2002 17:51:19 -0700 Received: from zok.sgi.com (zok.sgi.com [204.94.215.101]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3I0qIQR023115 for ; Wed, 17 Apr 2002 19:52:19 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by zok.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3I1qHBA022380 for ; Wed, 17 Apr 2002 18:52:17 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3I0qFp41315504 for <@relay.sgi.com:linux-xfs@thebarn.com>; Wed, 17 Apr 2002 17:52:15 -0700 (PDT) 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 KAA22217 for ; Thu, 18 Apr 2002 10:52:12 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA32273 for linux-xfs@thebarn.com; Thu, 18 Apr 2002 10:52:11 +1000 (AEST) Date: Thu, 18 Apr 2002 10:52:11 +1000 From: Nathan Scott To: linux-xfs@thebarn.com Subject: [RESEND] TAKE - userspace Message-ID: <20020418105211.A50643@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk [Just bounced, resending, initially sent last Friday] This is only really important in xfsprogs, where we really need to be able to override DEBUG when building libxfs. This issue was causing libxfs to be incorrectly built which can be disastrous in xfs_repair - as Eric found out. The other packages were also doing it wrong, but it's harmless for them. >From past experience its been a good idea to bump the version numbers just before a new XFS release anyway to ensure everyone gets the latest bits installed. note: xfsprogs-2.0.2 is ill-advised due to this repair issue - you should upgrade if you were using that one (2.0.2 has only been out for about a week though). cheers. Date: Fri Apr 12 17:11:02 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:116356a cmd/acl/VERSION - 1.25 cmd/acl/doc/CHANGES - 1.29 cmd/acl/include/builddefs.in - 1.19 cmd/acl/debian/changelog - 1.20 cmd/acl/include/buildmacros - 1.2 cmd/attr/VERSION - 1.18 cmd/attr/doc/CHANGES - 1.21 cmd/attr/include/builddefs.in - 1.16 cmd/attr/debian/changelog - 1.19 cmd/attr/include/buildmacros - 1.2 cmd/xfsprogs/VERSION - 1.44 cmd/xfsprogs/doc/CHANGES - 1.59 cmd/xfsprogs/include/builddefs.in - 1.21 cmd/xfsprogs/debian/changelog - 1.42 cmd/xfsprogs/include/buildmacros - 1.2 cmd/xfsdump/VERSION - 1.29 cmd/xfsdump/doc/CHANGES - 1.36 cmd/xfsdump/include/builddefs.in - 1.14 cmd/xfsdump/debian/changelog - 1.19 cmd/xfsdump/include/buildmacros - 1.2 cmd/dmapi/VERSION - 1.11 cmd/dmapi/doc/CHANGES - 1.10 cmd/dmapi/include/builddefs.in - 1.15 cmd/dmapi/debian/changelog - 1.11 cmd/dmapi/include/buildmacros - 1.2 - bump version number, build updates to fix a macro propogation issue which was recently introduced. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Apr 17 19:46:57 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I2kv8d007990 for ; Wed, 17 Apr 2002 19:46:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I2kvir007989 for linux-xfs-outgoing; Wed, 17 Apr 2002 19:46:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I2kp8d007963 for ; Wed, 17 Apr 2002 19:46:52 -0700 Received: from rj.sgi.com (rj.SGI.COM [204.94.215.100]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3I2loQR024351 for ; Wed, 17 Apr 2002 21:47:51 -0500 (CDT) Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by rj.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3I2lo6G024454 for ; Wed, 17 Apr 2002 19:47:50 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with SMTP id g3I2lmp40495990 for <@relay.sgi.com:linux-xfs@thebarn.com>; Wed, 17 Apr 2002 19:47:49 -0700 (PDT) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA23103 for ; Thu, 18 Apr 2002 12:47:46 +1000 Received: (from tes@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA33862 for linux-xfs@thebarn.com; Thu, 18 Apr 2002 12:47:45 +1000 (EST) Date: Thu, 18 Apr 2002 12:47:45 +1000 (EST) From: Timothy Shimmin Message-Id: <200204180247.MAA33862@snort.melbourne.sgi.com> To: linux-xfs@thebarn.com Subject: TAKE - xfstests/063 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Make sure we test the root namespace EAs in the dump as well as the user ones. --Tim Date: Wed Apr 17 19:45:46 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/diskb/build4/tes/slinx-xfs The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:116674a cmd/xfstests/common.dump - 1.34 - Also test for dumping of xfsroot EA names as well as user names. cmd/xfstests/063.out - 1.3 - Update for root EA names. From owner-linux-xfs@oss.sgi.com Wed Apr 17 21:38:27 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I4cR8d013666 for ; Wed, 17 Apr 2002 21:38:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I4cRUX013665 for linux-xfs-outgoing; Wed, 17 Apr 2002 21: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I4cM8d013632 for ; Wed, 17 Apr 2002 21:38:22 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA16278 for ; Wed, 17 Apr 2002 23:39: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 XAA42564 for ; Wed, 17 Apr 2002 23:39:17 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3I4dHN04140; Wed, 17 Apr 2002 23:39:17 -0500 Message-Id: <200204180439.g3I4dHN04140@stout.americas.sgi.com> Date: Wed, 17 Apr 2002 23:39:17 -0500 Subject: TAKE - Fix my last fix Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Got carried away with the cut and paste... Thanks Nathan! -Eric Date: Wed Apr 17 21:38:30 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:116695a linux/fs/xfs/xfs_log_recover.c - 1.224 - Cut and paste error - s/last_blk/new_blk From owner-linux-xfs@oss.sgi.com Wed Apr 17 23:03:18 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I63H8d018924 for ; Wed, 17 Apr 2002 23:03:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I63HTX018923 for linux-xfs-outgoing; Wed, 17 Apr 2002 23:03: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 g3I63B8d018893 for ; Wed, 17 Apr 2002 23:03:12 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx10)) with ESMTP id F1BDC6259; Thu, 18 Apr 2002 08:04: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 IAA19250; Thu, 18 Apr 2002 08:04:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id DCE5357306; Thu, 18 Apr 2002 08:03:21 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id A882D25835; Thu, 18 Apr 2002 08:03:21 +0200 (CEST) Message-ID: <3CBE61A9.3794F9F6@ch.sauter-bc.com> Date: Thu, 18 Apr 2002 08:03:21 +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, en MIME-Version: 1.0 To: PiercingTribe Cc: linux-xfs@oss.sgi.com Subject: Re: trouble with xfs partition References: <004701c1e669$afdaef40$2101a8c0@dada.it> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk PiercingTribe schrieb: > > hello, > im running big trouble with my xfs partition... all worked correctly for > months... today, after a reboot (the server was locked and i hard-rebooted) > it is no longer able to mount xfs partition (it locks everyting if i try, > bot at boot or manually)... i entered the system without mounting the xfs > partition, and i tried various tools (xfs_repair, and so)... nothing worked, > the various check shows that the data is still on the disk, but xfs_repair > keep making all the same operation (some lost+found reconnecting) but after > it it still hang when mounting... anyone got some advice to save at least > the data on the disk? im using kernel 2.4.14-xfs Lorenzo, Did you always use the same kernel? xfs tools have changed and maybe you have the wrong version? -Simon > > thanks > lorenzo tribe@piercingtribe.it From owner-linux-xfs@oss.sgi.com Wed Apr 17 23:24:39 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I6Od8d020076 for ; Wed, 17 Apr 2002 23:24:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I6OdtD020075 for linux-xfs-outgoing; Wed, 17 Apr 2002 23:24:39 -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 g3I6OO8d020030 for ; Wed, 17 Apr 2002 23:24:24 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx10)) with ESMTP id EA6F1612D; Thu, 18 Apr 2002 07:56: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 HAA18760; Thu, 18 Apr 2002 07:56:08 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 7A93B57306; Thu, 18 Apr 2002 07:55:20 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 425E025835; Thu, 18 Apr 2002 07:55:19 +0200 (CEST) Message-ID: <3CBE5FC6.44567009@ch.sauter-bc.com> Date: Thu, 18 Apr 2002 07:55: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, en MIME-Version: 1.0 To: Mike Burger Cc: Gareth Blades , Xfs Subject: Re: Upgrading root partion & Grub References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger schrieb: > > Even my 7.2 install didn't default to Grub...it gave me a choice. If you just hit 'OK', you'll end up using GRUB, that's what I call 'default' here. The problem is that the default selection results in a dangerous configuration on systems with software RAID. BTW: Choice is always good, that's what I want for filesystems. -Simon > > On Wed, 17 Apr 2002, Simon Matter wrote: > > > Now, I don't know why RedHat defaults to GRUB. > > > > BTW: This problem has nothing to do with XFS. > > > > -Simon From owner-linux-xfs@oss.sgi.com Wed Apr 17 23:52:32 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I6qW8d021710 for ; Wed, 17 Apr 2002 23:52:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I6qWrw021709 for linux-xfs-outgoing; Wed, 17 Apr 2002 23:52:32 -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-d514e12f.dsl.mediaWays.net [213.20.225.47]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I6qT8d021680 for ; Wed, 17 Apr 2002 23:52:30 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16y5nJ-0001BU-00; Thu, 18 Apr 2002 08:53:25 +0200 Message-ID: <3CBE6D65.2F001CCD@berdmann.de> Date: Thu, 18 Apr 2002 08:53:25 +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: Michael Best CC: linux-xfs Subject: Re: [Announce] XFS for Linux 1.1 Released References: <200204172222.g3HMM1T03726@stout.americas.sgi.com> <3CBE152D.8000001@emergence.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Has there been any work on either a 7.2 or Skipjack Redhat Installer ISO? SGI XFS Release 1.0.2 has an installer ISO for RH 7.2 From owner-linux-xfs@oss.sgi.com Thu Apr 18 00:55:33 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I7tX8d025271 for ; Thu, 18 Apr 2002 00:55:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I7tX9U025270 for linux-xfs-outgoing; Thu, 18 Apr 2002 00:55:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cc.kuleuven.ac.be (mail.cc.kuleuven.ac.be [134.58.10.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3I7tS8d025227 for ; Thu, 18 Apr 2002 00:55:29 -0700 Received: from pclab.cc.kuleuven.ac.be (pc-10-33-6-229.cc.kuleuven.ac.be [10.33.6.229]) by mail.cc.kuleuven.ac.be (8.9.3/8.9.0) with ESMTP id JAA104000 for ; Thu, 18 Apr 2002 09:56:24 +0200 Message-Id: <5.1.0.14.2.20020418095347.00a89ec0@pb429905.kuleuven.be> X-Sender: pb429905@pb429905.kuleuven.be X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 18 Apr 2002 09:56:20 +0200 To: linux-xfs@oss.sgi.com From: werner maes Subject: Re: [Announce] XFS for Linux 1.1 Released Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Has there been any work on either a 7.2 or Skipjack Redhat Installer ISO? >SGI XFS Release 1.0.2 has an installer ISO for RH 7.2 Yes, That's right. But I'm also wondering wether SGI will provide an Redhat Installer ISO with XFS 1.1 for the upcoming RedHat 7.3. Would make things easier. Werner From owner-linux-xfs@oss.sgi.com Thu Apr 18 02:46:51 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3I9kk8d003554 for ; Thu, 18 Apr 2002 02:46:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3I9kkj4003553 for linux-xfs-outgoing; Thu, 18 Apr 2002 02:46:46 -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 g3I9ke8d003519 for ; Thu, 18 Apr 2002 02:46:41 -0700 Received: (qmail 29404 invoked by uid 1000); 18 Apr 2002 09:55:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Apr 2002 09:55:53 -0000 Date: Thu, 18 Apr 2002 12:55:53 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Eric Sandeen cc: Subject: Re: [Announce] XFS for Linux 1.1 Released In-Reply-To: <200204172222.g3HMM1T03726@stout.americas.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 17 Apr 2002, Eric Sandeen wrote: > SGI is pleased to announce the 1.1 release of XFS for Linux. > Hi Great work guys. The first think to be noticed after upgrading from 1.0.2 to 1.1 is that kupdated doesnt show all the time in D state as before , only from time to time. ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Thu Apr 18 03:39:19 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IAdE8d006391 for ; Thu, 18 Apr 2002 03:39:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IAdEHA006390 for linux-xfs-outgoing; Thu, 18 Apr 2002 03:39:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from china.sercomm.com ([61.177.58.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IAcn8d006343 for ; Thu, 18 Apr 2002 03:39:09 -0700 Received: by china.sercomm.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 48256B9F.003AB171 ; Thu, 18 Apr 2002 18:41:05 +0800 X-Lotus-FromDomain: CHINA From: ken@sernet.com.cn To: linux-xfs@oss.sgi.com Message-ID: <48256B9F.003AB082.00@china.sercomm.com> Date: Thu, 18 Apr 2002 18:41:01 +0800 Subject: help! Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk dear XFS: I have a XFS partion ,size above 60G. It will print out a message" out of memory" and application dump(xfs_repair),as repairing. I have a questio: If XFS support large partion(>60G)?. rgds ken From owner-linux-xfs@oss.sgi.com Thu Apr 18 03:58:40 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IAwe8d007425 for ; Thu, 18 Apr 2002 03:58:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IAwemX007424 for linux-xfs-outgoing; Thu, 18 Apr 2002 03:58:40 -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 g3IAwa8d007397 for ; Thu, 18 Apr 2002 03:58:36 -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 g3IAxQUd053347; Thu, 18 Apr 2002 12:59:31 +0200 (CEST) Message-Id: <4.3.2.7.2.20020418125845.03e1d928@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Apr 2002 12:59:29 +0200 To: ken@sernet.com.cn, linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: help! In-Reply-To: <48256B9F.003AB082.00@china.sercomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 18:41 18-4-2002 +0800, ken@sernet.com.cn wrote: >dear XFS: > I have a XFS partion ,size above 60G. >It will print out a message" out of memory" and application >dump(xfs_repair),as >repairing. >I have a questio: If XFS support large partion(>60G)?. > rgds You need a newer version of xfs_repair. Good luck! -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Apr 18 07:41:30 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IEfU8d001818 for ; Thu, 18 Apr 2002 07:41:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IEfU0s001817 for linux-xfs-outgoing; Thu, 18 Apr 2002 07:41:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail45.fg.online.no (mail45-s.fg.online.no [148.122.161.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IEfN8d001777 for ; Thu, 18 Apr 2002 07:41:24 -0700 Received: from suspiria (ti300710a080-1361.bb.online.no [80.212.133.81]) by mail45.fg.online.no (8.9.3/8.9.3) with SMTP id QAA23755 for ; Thu, 18 Apr 2002 16:42:20 +0200 (MET DST) From: =?us-ascii?Q?Kristian_Sorensen?= To: Subject: RE: [Announce] XFS for Linux 1.1 Released Date: Thu, 18 Apr 2002 16:42:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <5.1.0.14.2.20020418095347.00a89ec0@pb429905.kuleuven.be> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Congratulations and thanks for the 1.1 release, just show a little patience and the installer will be available some time AFTER the OFFICIAL release of Skipjack. Just wait and see :-) Kristian -----Original Message----- From: owner-linux-xfs@oss.sgi.com [mailto:owner-linux-xfs@oss.sgi.com]On Behalf Of werner maes Sent: 18. april 2002 09:56 To: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS for Linux 1.1 Released >> Has there been any work on either a 7.2 or Skipjack Redhat Installer ISO? >SGI XFS Release 1.0.2 has an installer ISO for RH 7.2 Yes, That's right. But I'm also wondering wether SGI will provide an Redhat Installer ISO with XFS 1.1 for the upcoming RedHat 7.3. Would make things easier. Werner From owner-linux-xfs@oss.sgi.com Thu Apr 18 07:47:46 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IElk8d002893 for ; Thu, 18 Apr 2002 07:47:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IElkuT002892 for linux-xfs-outgoing; Thu, 18 Apr 2002 07:47: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IElg8d002266 for ; Thu, 18 Apr 2002 07:47:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id JAA23592; Thu, 18 Apr 2002 09:48: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 JAA36795; Thu, 18 Apr 2002 09:48:36 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3IEk2Q10314; Thu, 18 Apr 2002 09:46:02 -0500 Subject: RE: [Announce] XFS for Linux 1.1 Released From: Steve Lord To: Kristian Sorensen Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Apr 2002 09:46:02 -0500 Message-Id: <1019141162.10294.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-18 at 09:42, Kristian Sorensen wrote: > Congratulations and thanks for the 1.1 release, just show a little patience > and the installer will be available some time AFTER the OFFICIAL release of > Skipjack. Just wait and see :-) The skipjack installer has xfs support in it already. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Apr 18 07:55:07 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IEt78d003438 for ; Thu, 18 Apr 2002 07:55:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IEt7WG003435 for linux-xfs-outgoing; Thu, 18 Apr 2002 07:55:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IEt38d003394 for ; Thu, 18 Apr 2002 07:55:03 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 16yDIA-0000WZ-00 for linux-xfs@oss.sgi.com; Thu, 18 Apr 2002 08:53:46 -0600 Message-ID: <3CBEDE4B.7060100@emergence.com> Date: Thu, 18 Apr 2002 08:55:07 -0600 From: Michael Best User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en, pdf MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS for Linux 1.1 Released References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk It's not that I needed said installer per se, it was just that I was curious to hear if one was being worked on, if there were any issues to resolve etc. I was thinking of just diving into the iso images and wholesale replacing the kernel packages, and giving some attention to the anaconda installer, but I have no idea about the filesystem support part of it in the partition part of the installer. -Mike Kristian Sorensen wrote: > Congratulations and thanks for the 1.1 release, just show a little patience > and the installer will be available some time AFTER the OFFICIAL release of > Skipjack. Just wait and see :-) > > Kristian From owner-linux-xfs@oss.sgi.com Thu Apr 18 08:21:31 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IFLV8d014650 for ; Thu, 18 Apr 2002 08:21:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IFLVqD014649 for linux-xfs-outgoing; Thu, 18 Apr 2002 08:21:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from pellig.fpm.wisc.edu (pellig.fpm.wisc.edu [128.104.65.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IFLP8d013209 for ; Thu, 18 Apr 2002 08:21:25 -0700 Received: by pellig.fpm.wisc.edu with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Apr 2002 10:22:19 -0500 Message-ID: <85DD09F31993D41190D700508BDC7BE701B1EA6A@pellig.fpm.wisc.edu> From: ANTIGEN_PELLIG To: "'agent99@sgi.com'" , "'linux-xfs@oss.sgi.com'" , "'bugtraq@securityfocus.com'" Subject: Antigen forwarded attachment Date: Thu, 18 Apr 2002 10:22:16 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The body from the message "Re: IRIX XFS filesystem denial of service attack", originally quarantined by Antigen has been forwarded to you by H D Moore (sflist@digitaloffense.net). This message body may have been re-scanned by Antigen and handled according to the appropriate scan job's settings. begin 600 Body of Message M1&]E"!81E,@ M<&]R=#\@5&AE(%A&4R!P86=E(&AA"!A=F%I;&%B;&4Z#0H- M"FAT='`Z+R]O2!!9'9I0T*/@T*/B`@("`@("`@(%1I M=&QE.B`@("`@($E225@@6$93(&9I;&5S>7-T96T@9&5N:6%L(&]F('-E2!I;B!)4DE8)W,@ M6$93#0H^(&9I;&5S>7-T96TN(%5N9&5R('-O;64@8VER8W5M; Thu, 18 Apr 2002 08:23:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IFNwGo016326 for linux-xfs-outgoing; Thu, 18 Apr 2002 08:23:58 -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 g3IFNr8d016295 for ; Thu, 18 Apr 2002 08:23:53 -0700 Received: from pellig.fpm.wisc.edu (pellig.fpm.wisc.edu [128.104.65.25]) 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 IAA07301 for ; Thu, 18 Apr 2002 08:23:32 -0700 (PDT) mail_from (ANTIGEN_PELLIG@fpm.wisc.edu) Received: by pellig.fpm.wisc.edu with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Apr 2002 10:22:27 -0500 Message-ID: <85DD09F31993D41190D700508BDC7BE701B1EA81@pellig.fpm.wisc.edu> From: ANTIGEN_PELLIG To: "'sflist@digitaloffense.net'" , "'agent99@sgi.com'" , "'linux-xfs@oss.sgi.com'" , "'bugtraq@securityfocus.com'" Subject: Antigen forwarded attachment Date: Thu, 18 Apr 2002 10:22:24 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The body from the message "Re: IRIX XFS filesystem denial of service attack", originally quarantined by Antigen has been forwarded to you by Eric Sandeen (sandeen@sgi.com). This message body may have been re-scanned by Antigen and handled according to the appropriate scan job's settings. begin 600 Body of Message M:&D@2$0@+2`-"@T*22!D;VXG="!B96QI979E('1H870@3&EN=7@@:7,@869F M96-T960N("!))W9E(&)E96X@=&]L9"!T:&%T('1H92!,:6YU>`T*22]/('!A M=&@@=V%S('=R:71T96X@"!81E,@ M<&]R=#\@5&AE(%A&4R!P86=E(&AA; Thu, 18 Apr 2002 08:27:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IFRCUw016732 for linux-xfs-outgoing; Thu, 18 Apr 2002 08:27: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IFR88d016700 for ; Thu, 18 Apr 2002 08:27: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 KAA22672; Thu, 18 Apr 2002 10:28: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 KAA84137; Thu, 18 Apr 2002 10:28:06 -0500 (CDT) Subject: RE: [Announce] XFS for Linux 1.1 Released From: Eric Sandeen To: Steve Lord Cc: Kristian Sorensen , linux-xfs@oss.sgi.com In-Reply-To: <1019141162.10294.0.camel@jen.americas.sgi.com> References: <1019141162.10294.0.camel@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Apr 2002 10:28:06 -0500 Message-Id: <1019143686.4704.0.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-18 at 09:46, Steve Lord wrote: > The skipjack installer has xfs support in it already. True, but the skipjack kernel doesn't. Which still presents a problem. :) -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Apr 18 08:28:33 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IFSX8d022406 for ; Thu, 18 Apr 2002 08:28:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IFSXdD022405 for linux-xfs-outgoing; Thu, 18 Apr 2002 08:28:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IFSS8d022363 for ; Thu, 18 Apr 2002 08:28:28 -0700 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Thu, 18 Apr 2002 09:28:20 -0600 Message-ID: <3CBEE618.B220A393@echostar.com> Date: Thu, 18 Apr 2002 09:28:24 -0600 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS List Subject: IDE write cache and journaling file systems Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We've got a bit of an issue. From conversations on this list over the last few months, it appears as if enabling the write cache on an IDE drive is a "bad thing" when using a journaling file system such as XFS. But, when talking to drive manufacturers, we are told that if the write cache is disabled, the life of the drive is substantially reduced. This puts us in a bit of a hard place. We have little choice but to turn the write cache on. In our application, (consumer set top box) we cannot always cleanly shut down the system. The consumer rightly expects to just unplug the box when he wants/needs to. I'm not terribly concerned about losing a bit of data in such a case. I'm worried about file system corruption that would turn the box into an expensive door stop. My own testing so far has not shown any catastrophic failures, but if we have a million boxes in the field, issues could start showing up. The drive manufactures have recommended inserting IDE cache flushes at critical sections of the code. I'm hesitant to muck with XFS internals, and adding flushes in our user-space code would not cover all cases. This has to be a common problem. Does anyone have any strategies or words of wisdom? Jim Buzbee, Echostar Technologies From owner-linux-xfs@oss.sgi.com Thu Apr 18 08:29:05 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IFT58d022488 for ; Thu, 18 Apr 2002 08:29:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IFT5A2022487 for linux-xfs-outgoing; Thu, 18 Apr 2002 08:29: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IFT18d022436 for ; Thu, 18 Apr 2002 08:29:01 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA24437; Thu, 18 Apr 2002 10:29:58 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA34037; Thu, 18 Apr 2002 10:29:58 -0500 (CDT) Subject: Re: [Announce] XFS for Linux 1.1 Released From: Eric Sandeen To: Michael Best Cc: linux-xfs@oss.sgi.com In-Reply-To: <3CBEDE4B.7060100@emergence.com> References: <3CBEDE4B.7060100@emergence.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Apr 2002 10:29:58 -0500 Message-Id: <1019143798.4722.3.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-18 at 09:55, Michael Best wrote: > It's not that I needed said installer per se, it was just that I was > curious to hear if one was being worked on, if there were any issues to > resolve etc. > > I was thinking of just diving into the iso images and wholesale replacing > the kernel packages, and giving some attention to the anaconda installer, > but I have no idea about the filesystem support part of it in the partition > part of the installer. Ah, ok. As Steve says, most of the XFS support is already in the installer; the ISO just needs updated kernel and xfs userspace RPMs. If you'd like to give this a shot, I'd be more than happy to answer any questions that come up in the process... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Apr 18 08:46:36 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IFka8d029202 for ; Thu, 18 Apr 2002 08:46:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IFkZAY029201 for linux-xfs-outgoing; Thu, 18 Apr 2002 08:46: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IFkS8d029172 for ; Thu, 18 Apr 2002 08:46:28 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id KAA23826; Thu, 18 Apr 2002 10:47:26 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA16811; Thu, 18 Apr 2002 10:47:26 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3IFiqd11380; Thu, 18 Apr 2002 10:44:52 -0500 Subject: Re: IDE write cache and journaling file systems From: Steve Lord To: Jim Buzbee , ak@suse.de Cc: XFS List In-Reply-To: <3CBEE618.B220A393@echostar.com> References: <3CBEE618.B220A393@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Apr 2002 10:44:52 -0500 Message-Id: <1019144692.10200.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-18 at 10:28, Jim Buzbee wrote: > > We've got a bit of an issue. From conversations on this list over the > last few months, it appears as if enabling the write cache on an IDE > drive is a "bad thing" when using a journaling file system such as XFS. > But, when talking to drive manufacturers, we are told that if the write > cache is disabled, the life of the drive is substantially reduced. This > puts us in a bit of a hard place. We have little choice but to turn the > write cache on. > > In our application, (consumer set top box) we cannot always cleanly shut > down the system. The consumer rightly expects to just unplug the box > when he wants/needs to. I'm not terribly concerned about losing a bit > of data in such a case. I'm worried about file system corruption that > would turn the box into an expensive door stop. My own testing so far > has not shown any catastrophic failures, but if we have a million boxes > in the field, issues could start showing up. > > The drive manufactures have recommended inserting IDE cache flushes at > critical sections of the code. I'm hesitant to muck with XFS internals, > and adding flushes in our user-space code would not cover all cases. > > This has to be a common problem. Does anyone have any strategies or > words of wisdom? > > Jim Buzbee, > Echostar Technologies Andi Kleen was experimenting with the ide cache flushing code in the Suse kernel and adding some flushing calls to XFS. We talked about the right place to add them, I am not sure if he has tried it yet. The simplistic approach is to isolate log writes from other writes and ensure they can never share the cache. This is not the optimal approach, but should allow filesystem consistency to be maintained while keeping the cache on. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Apr 18 08:52:30 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IFqU8d029468 for ; Thu, 18 Apr 2002 08:52:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IFqUHd029467 for linux-xfs-outgoing; Thu, 18 Apr 2002 08:52:30 -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 g3IFqP8d029440 for ; Thu, 18 Apr 2002 08:52:25 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 01A551E54E; Thu, 18 Apr 2002 17:53:23 +0200 (MEST) Date: Thu, 18 Apr 2002 17:53:14 +0200 From: Andi Kleen To: Steve Lord Cc: Jim Buzbee , ak@suse.de, XFS List Subject: Re: IDE write cache and journaling file systems Message-ID: <20020418175314.A21976@wotan.suse.de> References: <3CBEE618.B220A393@echostar.com> <1019144692.10200.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1019144692.10200.8.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Andi Kleen was experimenting with the ide cache flushing code in the > Suse kernel and adding some flushing calls to XFS. We talked about > the right place to add them, I am not sure if he has tried it yet. I've tried it and also got it to work in an experimental state, but decided to rewrite it to use barriers instead. I didn't yet get around to do this rewrite. The reason for the rewrite is that just doing the flush slows it down a lot. It requires considerable infrastructure not in the standard kernel. > The simplistic approach is to isolate log writes from other writes > and ensure they can never share the cache. This is not the optimal > approach, but should allow filesystem consistency to be maintained > while keeping the cache on. I've just defined a new flag for page buf writes and taught the pagebuf layer how to set queue barriers for that new flag. -Andi From owner-linux-xfs@oss.sgi.com Thu Apr 18 09:03:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IG3M8d029951 for ; Thu, 18 Apr 2002 09:03:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IG3MaS029950 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:03:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IG3G8d029918 for ; Thu, 18 Apr 2002 09:03:17 -0700 Received: from burns.home.kernel.dk ([192.168.0.2] ident=mail) by virtualhost.dk with esmtp (Exim 3.34 #1) id 16yEOC-0007x6-00; Thu, 18 Apr 2002 18:04:04 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 3.35 #1) id 16yENs-0002LI-00; Thu, 18 Apr 2002 18:03:44 +0200 Date: Thu, 18 Apr 2002 18:03:44 +0200 From: Jens Axboe To: Andi Kleen Cc: Steve Lord , Jim Buzbee , XFS List Subject: Re: IDE write cache and journaling file systems Message-ID: <20020418160344.GM2492@suse.de> References: <3CBEE618.B220A393@echostar.com> <1019144692.10200.8.camel@jen.americas.sgi.com> <20020418175314.A21976@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020418175314.A21976@wotan.suse.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 18 2002, Andi Kleen wrote: > > > > Andi Kleen was experimenting with the ide cache flushing code in the > > Suse kernel and adding some flushing calls to XFS. We talked about > > the right place to add them, I am not sure if he has tried it yet. > > I've tried it and also got it to work in an experimental state, but decided > to rewrite it to use barriers instead. I didn't yet get around to do this > rewrite. The reason for the rewrite is that just doing the flush slows > it down a lot. Using barriers is surely the right approach, and lets the kernel use flushes or tag barriers as provided by the hardware. > It requires considerable infrastructure not in the standard kernel. ? Both the SuSE kernel has the infrastructure, and the 2.5 kernels so as well. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Apr 18 09:05:45 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IG5j8d030152 for ; Thu, 18 Apr 2002 09:05:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IG5jD4030151 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:05: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IG5d8d030120 for ; Thu, 18 Apr 2002 09:05:39 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA27533; Thu, 18 Apr 2002 11:06:37 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA14804; Thu, 18 Apr 2002 11:06:37 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3IG43l11459; Thu, 18 Apr 2002 11:04:03 -0500 Subject: Re: IDE write cache and journaling file systems From: Steve Lord To: Jens Axboe Cc: Andi Kleen , Jim Buzbee , XFS List In-Reply-To: <20020418160344.GM2492@suse.de> References: <3CBEE618.B220A393@echostar.com> <1019144692.10200.8.camel@jen.americas.sgi.com> <20020418175314.A21976@wotan.suse.de> <20020418160344.GM2492@suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Apr 2002 11:04:03 -0500 Message-Id: <1019145843.10294.10.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-18 at 11:03, Jens Axboe wrote: > On Thu, Apr 18 2002, Andi Kleen wrote: > > > > > > Andi Kleen was experimenting with the ide cache flushing code in the > > > Suse kernel and adding some flushing calls to XFS. We talked about > > > the right place to add them, I am not sure if he has tried it yet. > > > > I've tried it and also got it to work in an experimental state, but decided > > to rewrite it to use barriers instead. I didn't yet get around to do this > > rewrite. The reason for the rewrite is that just doing the flush slows > > it down a lot. > > Using barriers is surely the right approach, and lets the kernel use > flushes or tag barriers as provided by the hardware. > > > It requires considerable infrastructure not in the standard kernel. > > ? Both the SuSE kernel has the infrastructure, and the 2.5 kernels so as > well. Unless I am mistaken, Jim is tied down to a fairly old 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 Apr 18 09:06:17 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IG6H8d030280 for ; Thu, 18 Apr 2002 09:06:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IG6Hi6030278 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:06: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 g3IG6D8d030235 for ; Thu, 18 Apr 2002 09:06:14 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id AA7221E54E; Thu, 18 Apr 2002 18:07:11 +0200 (MEST) Date: Thu, 18 Apr 2002 18:07:06 +0200 From: Andi Kleen To: Jens Axboe Cc: Andi Kleen , Steve Lord , Jim Buzbee , XFS List Subject: Re: IDE write cache and journaling file systems Message-ID: <20020418180706.A28301@wotan.suse.de> References: <3CBEE618.B220A393@echostar.com> <1019144692.10200.8.camel@jen.americas.sgi.com> <20020418175314.A21976@wotan.suse.de> <20020418160344.GM2492@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020418160344.GM2492@suse.de> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > It requires considerable infrastructure not in the standard kernel. > > ? Both the SuSE kernel has the infrastructure, and the 2.5 kernels so as > well. I was thinking of the SuSE kernel. Wasn't aware that the queue flushing has been merged into 2.5 yet. My work was on 2.4-SuSE, but could be probably ported to 2.5 (but I'm waiting a few releases first before I let 2.5 near my IDE disks again...) -Andi From owner-linux-xfs@oss.sgi.com Thu Apr 18 09:10:17 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IGAH8d030599 for ; Thu, 18 Apr 2002 09:10:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IGAHZf030598 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:10:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IGAC8d030560 for ; Thu, 18 Apr 2002 09:10:13 -0700 Received: from burns.home.kernel.dk ([192.168.0.2] ident=mail) by virtualhost.dk with esmtp (Exim 3.34 #1) id 16yEUP-00083L-00; Thu, 18 Apr 2002 18:10:29 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 3.35 #1) id 16yEUG-0002Mz-00; Thu, 18 Apr 2002 18:10:20 +0200 Date: Thu, 18 Apr 2002 18:10:20 +0200 From: Jens Axboe To: Andi Kleen Cc: Steve Lord , Jim Buzbee , XFS List Subject: Re: IDE write cache and journaling file systems Message-ID: <20020418161020.GO2492@suse.de> References: <3CBEE618.B220A393@echostar.com> <1019144692.10200.8.camel@jen.americas.sgi.com> <20020418175314.A21976@wotan.suse.de> <20020418160344.GM2492@suse.de> <20020418180706.A28301@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020418180706.A28301@wotan.suse.de> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 18 2002, Andi Kleen wrote: > > > It requires considerable infrastructure not in the standard kernel. > > > > ? Both the SuSE kernel has the infrastructure, and the 2.5 kernels so as > > well. > > I was thinking of the SuSE kernel. Wasn't aware that the queue flushing > has been merged into 2.5 yet. My work was on 2.4-SuSE, but could be > probably ported to 2.5 (but I'm waiting a few releases first before > I let 2.5 near my IDE disks again...) I don't think the backend has been merged in 2.5 yet, at least I didn't send it in so far. The frontend is there though, so writing the support is trivial :-) I'll get the 2.5 bits in now. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Apr 18 09:10:07 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IGA78d030556 for ; Thu, 18 Apr 2002 09:10:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IGA7IU030555 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:10:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from virtualhost.dk (ns.virtualhost.dk [195.184.98.160]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IGA18d030527 for ; Thu, 18 Apr 2002 09:10:01 -0700 Received: from burns.home.kernel.dk ([192.168.0.2] ident=mail) by virtualhost.dk with esmtp (Exim 3.34 #1) id 16yEUj-00083o-00; Thu, 18 Apr 2002 18:10:49 +0200 Received: from axboe by burns.home.kernel.dk with local (Exim 3.35 #1) id 16yETG-0002Mv-00; Thu, 18 Apr 2002 18:09:18 +0200 Date: Thu, 18 Apr 2002 18:09:18 +0200 From: Jens Axboe To: Steve Lord Cc: Andi Kleen , Jim Buzbee , XFS List Subject: Re: IDE write cache and journaling file systems Message-ID: <20020418160918.GN2492@suse.de> References: <3CBEE618.B220A393@echostar.com> <1019144692.10200.8.camel@jen.americas.sgi.com> <20020418175314.A21976@wotan.suse.de> <20020418160344.GM2492@suse.de> <1019145843.10294.10.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1019145843.10294.10.camel@jen.americas.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 18 2002, Steve Lord wrote: > On Thu, 2002-04-18 at 11:03, Jens Axboe wrote: > > On Thu, Apr 18 2002, Andi Kleen wrote: > > > > > > > > Andi Kleen was experimenting with the ide cache flushing code in the > > > > Suse kernel and adding some flushing calls to XFS. We talked about > > > > the right place to add them, I am not sure if he has tried it yet. > > > > > > I've tried it and also got it to work in an experimental state, but decided > > > to rewrite it to use barriers instead. I didn't yet get around to do this > > > rewrite. The reason for the rewrite is that just doing the flush slows > > > it down a lot. > > > > Using barriers is surely the right approach, and lets the kernel use > > flushes or tag barriers as provided by the hardware. > > > > > It requires considerable infrastructure not in the standard kernel. > > > > ? Both the SuSE kernel has the infrastructure, and the 2.5 kernels so as > > well. > > Unless I am mistaken, Jim is tied down to a fairly old kernel. Not too much of a problem, the barrier infrastructure + ide flush support really isn't that much code, didn't even take long to write. That just leaves the XFS parts, which I don't know anything about. -- Jens Axboe From owner-linux-xfs@oss.sgi.com Thu Apr 18 09:17:32 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IGHW8d031204 for ; Thu, 18 Apr 2002 09:17:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IGHWNI031203 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:17:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IGHS8d031177 for ; Thu, 18 Apr 2002 09:17:28 -0700 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Thu, 18 Apr 2002 10:17:27 -0600 Message-ID: <3CBEF19B.9CFD9D99@echostar.com> Date: Thu, 18 Apr 2002 10:17:31 -0600 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: XFS List Subject: Re: IDE write cache and journaling file systems References: <3CBEE618.B220A393@echostar.com> <1019144692.10200.8.camel@jen.americas.sgi.com> <20020418175314.A21976@wotan.suse.de> <20020418160344.GM2492@suse.de> <1019145843.10294.10.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > > ? Both the SuSE kernel has the infrastructure, and the 2.5 kernels so as > > well. > > Unless I am mistaken, Jim is tied down to a fairly old kernel. Yep, we're on 2.4.8 with the current box under development. Jim > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Apr 18 09:35:17 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IGZH8d032062 for ; Thu, 18 Apr 2002 09:35:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IGZHCn032061 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:35:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from relay.dera.gov.uk (relay.dera.gov.uk [192.5.29.49]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IGZB8d032035 for ; Thu, 18 Apr 2002 09:35:12 -0700 Received: (qmail 21435 invoked from network); 18 Apr 2002 17:36:13 +0100 Received: from butterfly.mod.uk (HELO warlock.dstl.gov.uk) (192.5.29.10) by relay.dera.gov.uk with SMTP; 18 Apr 2002 17:36:13 +0100 Subject: Re: IDE write cache and journaling file systems From: Tony Gale To: linux-xfs@oss.sgi.com In-Reply-To: <3CBEF19B.9CFD9D99@dstl.gov.uk> References: <3CBEE618.B220A393@dstl.gov.uk> <1019144692.10200.8.camel@jen.americas.sgi.com> <20020418175314.A21976@wotan.suse.de> <20020418160344.GM2492@suse.de> <1019145843.10294.10.camel@jen.americas.sgi.com> <3CBEF19B.9CFD9D99@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3.99 Date: 18 Apr 2002 17:36:11 +0100 Message-Id: <1019147772.13561.9.camel@syntax.dstl.gov.uk> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-18 at 17:17, Jim Buzbee wrote: > Steve Lord wrote: > > > > ? Both the SuSE kernel has the infrastructure, and the 2.5 kernels so as > > > well. > > > > Unless I am mistaken, Jim is tied down to a fairly old kernel. > > Yep, we're on 2.4.8 with the current box under development. > > Jim > Have you thought about using ext3 in data=journal mode instead? Also make sure your disk honours the ATA write cache flush command, and that it doesn't throw away the cache contents on reboot/suspend. -tony From owner-linux-xfs@oss.sgi.com Thu Apr 18 09:39:09 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IGd98d032238 for ; Thu, 18 Apr 2002 09:39:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IGd97K032237 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:39:09 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from server.tevox.de (ghost.liquidsteel.net [62.8.161.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IGd38d032211 for ; Thu, 18 Apr 2002 09:39:05 -0700 Received: (qmail 32588 invoked by uid 64014); 18 Apr 2002 16:40:04 -0000 Received: from cd@kalkatraz.de by server with qmail-scanner-1.01 ( Clean. Processed in 0.170404 secs); 18 Apr 2002 16:40:04 -0000 Received: from scully.tevox.de (200.0.0.14) by mail.tevox.de with DES-CBC3-SHA encrypted SMTP; 18 Apr 2002 16:40:04 -0000 Date: Thu, 18 Apr 2002 18:40:03 +0200 From: Lars Weitze To: linux-xfs@oss.sgi.com Subject: Can't get samba 2.2.3a to compile with ACL support Message-Id: <20020418184003.4490436e.cd@kalkatraz.de> Organization: http://www.liquidsteel.net X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: "Add'HrsHhg}pA?6>_fl]8[PNFwpJTSTW?I_:}%1O}rQof)E5W:qQbr1i>J?[?W:9"~?}]; ,?}|UTr8Ww=d%HY}-ap:|nv&; Thu, 18 Apr 2002 09:46:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IGkX4e032533 for linux-xfs-outgoing; Thu, 18 Apr 2002 09:46:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IGkQ8d032496 for ; Thu, 18 Apr 2002 09:46:26 -0700 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Thu, 18 Apr 2002 10:46:17 -0600 Message-ID: <3CBEF85E.1E412605@echostar.com> Date: Thu, 18 Apr 2002 10:46:22 -0600 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: IDE write cache and journaling file systems References: <3CBEE618.B220A393@dstl.gov.uk> <1019144692.10200.8.camel@jen.americas.sgi.com> <20020418175314.A21976@wotan.suse.de> <20020418160344.GM2492@suse.de> <1019145843.10294.10.camel@jen.americas.sgi.com> <3CBEF19B.9CFD9D99@echostar.com> <1019147772.13561.9.camel@syntax.dstl.gov.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Tony Gale wrote: > > On Thu, 2002-04-18 at 17:17, Jim Buzbee wrote: > > Steve Lord wrote: > > > > > > ? Both the SuSE kernel has the infrastructure, and the 2.5 kernels so as > > > > well. > > > > > > Unless I am mistaken, Jim is tied down to a fairly old kernel. > > > > Yep, we're on 2.4.8 with the current box under development. > > > > Jim > > > > Have you thought about using ext3 in data=journal mode instead? One feature we require that only XFS provides (as far as I know) is the ability to punch holes in files. We continually record video to a file and when the file gets too large, we just chop off the front and keep writing. > > Also make sure your disk honours the ATA write cache flush command, and > that it doesn't throw away the cache contents on reboot/suspend. That's an interesting thought. The box can be reset (by the user pulling the smart card) without losing power. So I guess in that case, the IDE buffer would still get flushed. Jim > > -tony From owner-linux-xfs@oss.sgi.com Thu Apr 18 10:06:07 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IH668d000777 for ; Thu, 18 Apr 2002 10:06:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IH66VX000776 for linux-xfs-outgoing; Thu, 18 Apr 2002 10:06:06 -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 g3IH608d000739 for ; Thu, 18 Apr 2002 10:06:01 -0700 Received: from auto-nb1.xs4all.nl (qn-212-58-167-74.quicknet.nl [212.58.167.74]) by smtpzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g3IH6v1J095901; Thu, 18 Apr 2002 19:06:57 +0200 (CEST) Message-Id: <4.3.2.7.2.20020418190239.03b5cc20@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 18 Apr 2002 19:07:00 +0200 To: Jim Buzbee , XFS List From: Seth Mos Subject: Re: IDE write cache and journaling file systems In-Reply-To: <3CBEE618.B220A393@echostar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 09:28 18-4-2002 -0600, Jim Buzbee wrote: >We've got a bit of an issue. From conversations on this list over the >last few months, it appears as if enabling the write cache on an IDE >drive is a "bad thing" when using a journaling file system such as XFS. >But, when talking to drive manufacturers, we are told that if the write >cache is disabled, the life of the drive is substantially reduced. This >puts us in a bit of a hard place. We have little choice but to turn the >write cache on. If that was so a lot of disks would be failing these days. It's all nice and dandy but if your power supply goes, your filesystem integrity will go with it. I have never had write cache on any of my disks enabled and I have so far lost just 4 disks of the 12 over the last 6 years. 2 of which were from a _really_ bad seagate series drive. So far all the maxtor drives I have are still alive. I also have 1 out of 3 IBM deskstar disks which is beginning to fail after 1,5 years. Repeatingley switching disks on and off is not really good for the disk either. Workaround: Don't use the disk. ;) Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Apr 18 10:08:12 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IH8C8d000942 for ; Thu, 18 Apr 2002 10:08:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IH8CwV000941 for linux-xfs-outgoing; Thu, 18 Apr 2002 10:08:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from server.tevox.de (ghost.liquidsteel.net [62.8.161.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IH5Q8d000694 for ; Thu, 18 Apr 2002 10:05:27 -0700 Received: (qmail 473 invoked by uid 64014); 18 Apr 2002 17:06:27 -0000 Received: from cd@kalkatraz.de by server with qmail-scanner-1.01 ( Clean. Processed in 0.386877 secs); 18 Apr 2002 17:06:27 -0000 Received: from scully.tevox.de (200.0.0.14) by mail.tevox.de with DES-CBC3-SHA encrypted SMTP; 18 Apr 2002 17:06:27 -0000 Date: Thu, 18 Apr 2002 19:06:27 +0200 From: Lars Weitze To: samba@lists.samba.org Cc: linux-xfs@oss.sgi.com Subject: Can't get samba 2.2.3a to compile with ACL support (with logs) Message-Id: <20020418190627.6a4dc65c.cd@kalkatraz.de> Organization: http://www.liquidsteel.net X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: "Add'HrsHhg}pA?6>_fl]8[PNFwpJTSTW?I_:}%1O}rQof)E5W:qQbr1i>J?[?W:9"~?}]; ,?}|UTr8Ww=d%HY}-ap:|nv&; Thu, 18 Apr 2002 10:58:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IHwIII005353 for linux-xfs-outgoing; Thu, 18 Apr 2002 10:58:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fep02-mail.bloor.is.net.cable.rogers.com (fep02-mail.bloor.is.net.cable.rogers.com [66.185.86.72]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IHwD8d005326 for ; Thu, 18 Apr 2002 10:58:13 -0700 Received: from cr598116-a ([24.112.74.120]) by fep02-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with ESMTP id <20020418175906.VCSZ322766.fep02-mail.bloor.is.net.cable.rogers.com@cr598116-a> for ; Thu, 18 Apr 2002 13:59:06 -0400 From: Gerald Henriksen To: linux-xfs@oss.sgi.com Subject: Re: [Announce] XFS for Linux 1.1 Released Date: Thu, 18 Apr 2002 13:59:13 -0400 Message-ID: References: <5.1.0.14.2.20020418095347.00a89ec0@pb429905.kuleuven.be> In-Reply-To: X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep02-mail.bloor.is.net.cable.rogers.com from [24.112.74.120] using ID at Thu, 18 Apr 2002 13:59:06 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3IHwE8d005328 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 18 Apr 2002 16:42:14 +0200, you wrote: >Congratulations and thanks for the 1.1 release, just show a little patience >and the installer will be available some time AFTER the OFFICIAL release of >Skipjack. Just wait and see :-) But Skipjack has been officially released, Skipjack being a beta release. Red Hat has not yet (and will not until the official announcement) indicated what the version number or name of the next non-beta release will be. From owner-linux-xfs@oss.sgi.com Thu Apr 18 11:33:49 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IIXn8d006847 for ; Thu, 18 Apr 2002 11:33:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IIXnM4006846 for linux-xfs-outgoing; Thu, 18 Apr 2002 11:33:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mcp.ucsd.edu (mcp.ucsd.edu [132.239.236.121]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IIXk8d006816 for ; Thu, 18 Apr 2002 11:33:46 -0700 Received: from localhost (drew@localhost) by mcp.ucsd.edu (8.11.6/8.11.6) with ESMTP id g3IIXN117990 for ; Thu, 18 Apr 2002 11:33:26 -0700 X-Authentication-Warning: mcp.ucsd.edu: drew owned process doing -bs Date: Thu, 18 Apr 2002 11:33:23 -0700 (PDT) From: Drew Schaffner X-X-Sender: drew@mcp.ucsd.edu To: linux-xfs@oss.sgi.com Subject: RH Installer ISO for 1.1? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there going to be an RH 7.2 ISO image for 1.1 like there was for release 1.0.2? -- Drew Schaffner Department of Bioengineering University of California San Diego perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' From owner-linux-xfs@oss.sgi.com Thu Apr 18 11:33:15 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IIXF8d006768 for ; Thu, 18 Apr 2002 11:33:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IIXFsS006766 for linux-xfs-outgoing; Thu, 18 Apr 2002 11:33:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IIX68d006732 for ; Thu, 18 Apr 2002 11:33:06 -0700 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Thu, 18 Apr 2002 12:32:41 -0600 Message-ID: <3CBF114D.DF79A098@echostar.com> Date: Thu, 18 Apr 2002 12:32:45 -0600 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Seth Mos CC: XFS List Subject: Re: IDE write cache and journaling file systems References: <4.3.2.7.2.20020418190239.03b5cc20@pop.xs4all.nl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Seth Mos wrote: > > At 09:28 18-4-2002 -0600, Jim Buzbee wrote: > > >We've got a bit of an issue. From conversations on this list over the > >last few months, it appears as if enabling the write cache on an IDE > >drive is a "bad thing" when using a journaling file system such as XFS. > >But, when talking to drive manufacturers, we are told that if the write > >cache is disabled, the life of the drive is substantially reduced. This > >puts us in a bit of a hard place. We have little choice but to turn the > >write cache on. > > If that was so a lot of disks would be failing these days. It's all nice > and dandy but if your power supply goes, your filesystem integrity will go > with it. Anyone know what are the Linux distributions are doing by default? Now that they are including journaling filesystems as an option, I wonder if they turn write caching off on IDE drives. Jim > > I have never had write cache on any of my disks enabled and I have so far > lost just 4 disks of the 12 over the last 6 years. 2 of which were from a > _really_ bad seagate series drive. > > So far all the maxtor drives I have are still alive. > I also have 1 out of 3 IBM deskstar disks which is beginning to fail after > 1,5 years. > > Repeatingley switching disks on and off is not really good for the disk either. > Workaround: Don't use the disk. > > ;) > > Cheers > > -- > Seth > It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Apr 18 11:51:25 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IIpP8d007612 for ; Thu, 18 Apr 2002 11:51:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IIpPbE007611 for linux-xfs-outgoing; Thu, 18 Apr 2002 11:51: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IIpK8d007579 for ; Thu, 18 Apr 2002 11:51:20 -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 NAA31456; Thu, 18 Apr 2002 13:52:18 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA39953; Thu, 18 Apr 2002 13:52:18 -0500 (CDT) Subject: Re: RH Installer ISO for 1.1? From: Eric Sandeen To: Drew Schaffner Cc: linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 18 Apr 2002 13:52:18 -0500 Message-Id: <1019155938.4704.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-18 at 13:33, Drew Schaffner wrote: > Is there going to be an RH 7.2 ISO image for 1.1 like there was for > release 1.0.2? No, for the same reason that Red Hat doesn't release a new installer for every kernel upgrade. Think of XFS 1.1 as an upgrade/update for the 7.2/1.0.2 installer. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Thu Apr 18 11:58:17 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IIwH8d007918 for ; Thu, 18 Apr 2002 11:58:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IIwHtX007917 for linux-xfs-outgoing; Thu, 18 Apr 2002 11:58: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 g3IIwD8d007871 for ; Thu, 18 Apr 2002 11:58:14 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 265631E5A5; Thu, 18 Apr 2002 20:59:12 +0200 (MEST) Date: Thu, 18 Apr 2002 20:59:12 +0200 From: Andi Kleen To: Jim Buzbee Cc: Seth Mos , XFS List Subject: Re: IDE write cache and journaling file systems Message-ID: <20020418205911.A13869@wotan.suse.de> References: <4.3.2.7.2.20020418190239.03b5cc20@pop.xs4all.nl> <3CBF114D.DF79A098@echostar.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CBF114D.DF79A098@echostar.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Anyone know what are the Linux distributions are doing by default? Now > that they are including journaling filesystems as an option, I wonder if > they turn write caching off on IDE drives. They don't. Only the BSDs turn it off by default, but everybody then just turns it on again. SuSe 8.0 also flushes caches explicitely for ext3 and reiserfs. -Andi From owner-linux-xfs@oss.sgi.com Thu Apr 18 13:50:14 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IKoE8d011152 for ; Thu, 18 Apr 2002 13:50:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IKoEws011151 for linux-xfs-outgoing; Thu, 18 Apr 2002 13:50:14 -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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IKo88d011125 for ; Thu, 18 Apr 2002 13:50:08 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA34938 for ; Thu, 18 Apr 2002 15:51:07 -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 PAA71759 for ; Thu, 18 Apr 2002 15:51:07 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3IKp7F13448; Thu, 18 Apr 2002 15:51:07 -0500 Message-Id: <200204182051.g3IKp7F13448@stout.americas.sgi.com> Date: Thu, 18 Apr 2002 15:51:07 -0500 Subject: TAKE - Fix up ENOSPC behavior Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Apr 18 13:45:37 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea If you make a 50M filesystem and copy a kernel tree to it, you'll see that after you run out of space on the copy, 15M-20M of space magically re-appears after a sync. This is because the worst-case space requirement for metadata is reserved for delayed writes, and when these are finally flushed, much of that space is reclaimed. (Thanks, Steve!) There is a loop in xfs_bmap that tries to deal with ENOSPC, which tries progressively harder to shake loose some space. The last thing it tries is VFS_SYNC, but this wasn't syncing the data buffers. Changing this to fsync_no_super does the trick. The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:116769a linux/fs/xfs/linux/xfs_lrw.c - 1.132 - In the ENOSPC loop in xfs_bmap, sync the data buffers, so that the worst-case reserved metadata space for delayed writes will be freed, and we can truly fill the filesystem. From owner-linux-xfs@oss.sgi.com Thu Apr 18 13:57:50 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IKvo8d011387 for ; Thu, 18 Apr 2002 13:57:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IKvnhk011386 for linux-xfs-outgoing; Thu, 18 Apr 2002 13:57: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IKvh8d011358 for ; Thu, 18 Apr 2002 13:57:43 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA81991 for ; Thu, 18 Apr 2002 15:58:42 -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 PAA68937 for ; Thu, 18 Apr 2002 15:58:42 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3IKwgp13570; Thu, 18 Apr 2002 15:58:42 -0500 Message-Id: <200204182058.g3IKwgp13570@stout.americas.sgi.com> Date: Thu, 18 Apr 2002 15:58:42 -0500 Subject: TAKE - Remove extra access check in lookup path Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Chris Pascoe was seeing stale file handles on his NFS clients, and traced it down to directories on which the client had no execute permissions. Long story short, NFS was trying to reconstruct a path up to / by doing a lookup on ".." in such a directory, and failing - this returned EBADHANDLE because there was an extra access check in xfs_lookup if we had to unlock the directory - since perms on this directory may have changed while it was unlocked. NFS always expects to be able to lookup ".." and didn't deal well with this extra check when it failed. In general, access checks have already happened above this point, and re-checking shouldn't be necessary. ...and that was the short story... Date: Thu Apr 18 13:53:35 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:116778a linux/fs/xfs/xfs_vnodeops.c - 1.523 - Remove extra access check in lookup path From owner-linux-xfs@oss.sgi.com Thu Apr 18 15:16:23 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3IMGN8d013124 for ; Thu, 18 Apr 2002 15:16:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3IMGN4O013123 for linux-xfs-outgoing; Thu, 18 Apr 2002 15:16:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imo-d06.mx.aol.com (imo-d06.mx.aol.com [205.188.157.38]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3IMGJ8d013097 for ; Thu, 18 Apr 2002 15:16:20 -0700 Received: from NetBja@netscape.net by imo-d06.mx.aol.com (mail_out_v32.5.) id 4.19.38ea41e (22680) for ; Thu, 18 Apr 2002 18:17:16 -0400 (EDT) Received: from netscape.net (m174.net195-132-4.noos.fr [195.132.4.174]) by air-in04.mx.aol.com (v84.14) with ESMTP id MAILININ41-0418181716; Thu, 18 Apr 2002 18:17:16 -0400 Message-ID: <3CBF45E9.1080909@netscape.net> Date: Fri, 19 Apr 2002 00:17:13 +0200 From: "Linux User's Team" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: fr-fr, en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Maybe... Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: Unknown (No Version) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi team, In a few words, thank you very much for this GREAT Linux file system. Maybe Linus accept soon the XFS patch in the 2.4.2x kernel... Regards, Bernard (from France) From owner-linux-xfs@oss.sgi.com Thu Apr 18 16:38:34 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3INcP8d015130 for ; Thu, 18 Apr 2002 16:38:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3INcP3X015129 for linux-xfs-outgoing; Thu, 18 Apr 2002 16:38: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]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3INcJ8d015096 for ; Thu, 18 Apr 2002 16:38:19 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id QAA795598 for ; Thu, 18 Apr 2002 16:39:20 -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 JAA01443; Fri, 19 Apr 2002 09:38:01 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA53647; Fri, 19 Apr 2002 09:37:59 +1000 (AEST) Date: Fri, 19 Apr 2002 09:37:57 +1000 From: Nathan Scott To: Lars Weitze Cc: samba@lists.samba.org, linux-xfs@oss.sgi.com Subject: Re: Can't get samba 2.2.3a to compile with ACL support (with logs) Message-ID: <20020419093757.B22886@wobbly.melbourne.sgi.com> References: <20020418190627.6a4dc65c.cd@kalkatraz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020418190627.6a4dc65c.cd@kalkatraz.de>; from cd@kalkatraz.de on Thu, Apr 18, 2002 at 07:06:27PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, On Thu, Apr 18, 2002 at 07:06:27PM +0200, Lars Weitze wrote: > I've compiled everything: the whole acl package, the attr package the > xfs-progs etc. from the SGI CVS. I've installed all the devel packages. > > But Samba 2.2.3a configure tells me that it can't find ACL support. > > The line in the logs reads: > configure:12853: gcc -o conftest -O -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE conftest.c -lacl -lcups > /usr/lib/libacl.so: undefined reference to `fgetxattr' > /usr/lib/libacl.so: undefined reference to `removexattr' > /usr/lib/libacl.so: undefined reference to `setxattr' > /usr/lib/libacl.so: undefined reference to `fsetxattr' > /usr/lib/libacl.so: undefined reference to `getxattr' > The fix is to add "-lattr" to that link line above... this should be added into Samba's configure checks somewhere I guess (libacl.so now makes use of the syscalls defined in libattr.so). cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 18 17:27:27 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J0RR8d016017 for ; Thu, 18 Apr 2002 17:27:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J0RRvf016015 for linux-xfs-outgoing; Thu, 18 Apr 2002 17:27:27 -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 g3J0RM8d015989 for ; Thu, 18 Apr 2002 17:27:22 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id RAA779770 for ; Thu, 18 Apr 2002 17:28:23 -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 KAA94517; Fri, 19 Apr 2002 10:27:05 +1000 (EST) Date: Fri, 19 Apr 2002 10:27:05 +1000 (EST) From: Nathan Scott Message-Id: <200204190027.KAA94517@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Cc: hch@infradead.org, ag@bestbits.at Subject: TAKE - xattr Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Apr 18 17:25:34 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:116833a cmd/xfsmisc/2.4-xattr.patch - 1.3 - update locks held in VFS before making xattr calls, after discussion with Christoph and Andreas about their needs for jfs/ext2/ext3. 2.4 only, and syncs us up a bit more with Andreas' patches. Modid: 2.4.x-xfs:slinx:116833b linux/Documentation/filesystems/Locking - 1.6 linux/fs/xattr.c - 1.5 - update locks held in VFS before making xattr calls, after discussion with Christoph and Andreas about their needs for jfs/ext2/ext3. 2.4 only, and syncs us up a bit more with Andreas' patches. From owner-linux-xfs@oss.sgi.com Thu Apr 18 17:35:53 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J0Zr8d016226 for ; Thu, 18 Apr 2002 17:35:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J0Zrnu016225 for linux-xfs-outgoing; Thu, 18 Apr 2002 17:35:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from plato.arts.usyd.edu.au (plato.arts.usyd.edu.au [129.78.16.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J0Zm8d016199 for ; Thu, 18 Apr 2002 17:35:49 -0700 Received: from localhost (plato.arts.usyd.edu.au [129.78.16.1]) by plato.arts.usyd.edu.au (8.9.3/8.9.3) with ESMTP id KAA16436 for ; Fri, 19 Apr 2002 10:36:52 +1000 (EST) Received: from whitestar.arts.usyd.edu.au ( [whitestar.arts.usyd.edu.au]) as user matthew@localhost by admin.arts.usyd.edu.au with HTTP; Fri, 19 Apr 2002 10:36:52 +1000 Message-ID: <1019176612.3cbf66a453076@admin.arts.usyd.edu.au> Date: Fri, 19 Apr 2002 10:36:52 +1000 From: matthew@arts.usyd.edu.au To: linux-xfs@oss.sgi.com Subject: Can't build kernal with DMAPI as a module in 2.4 CVS MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.1 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not sure why you would want to - but I accidently selected DMAPI m instead of n and the resulting kernel would not link due to what appeared to be missing DMAPI function calls. I guess some one should get into kbuild and remove the option to build it as a module ? ------------------------------------------------- This mail sent through IMP at ArtsIT: http://admin.arts.usyd.edu.au/horde/imp/ From owner-linux-xfs@oss.sgi.com Thu Apr 18 18:14:59 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J1Ex8d016849 for ; Thu, 18 Apr 2002 18:14:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J1ExdN016848 for linux-xfs-outgoing; Thu, 18 Apr 2002 18:14:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from huachuca.tellurian.com.au (huachuca.tellurian.com.au [203.20.69.212]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J1Et8d016821 for ; Thu, 18 Apr 2002 18:14:55 -0700 Received: (qmail 2290 invoked from network); 19 Apr 2002 10:35:10 +0930 Received: from gauntlet.tellurian.com.au (HELO rebel.net.au) (203.20.69.209) by huachuca.tellurian.com.au with SMTP; 19 Apr 2002 10:35:10 +0930 Message-ID: <3CBF72C5.7080100@rebel.net.au> Date: Fri, 19 Apr 2002 10:58:37 +0930 From: David Lloyd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS -- Version 1.1 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, I can say that it certainly feels different although I had to install about 5 other RPM's to get it to behave itself. I wonder how it behaves itself under mongo.pl (i.e. namesys/reiserfs tool to do benchmarks) DSL -- On this day, this day of wrath All shall dissolve in flames As attested by David and the Sybil... (...translation of the third part of the Requiem Mass) From owner-linux-xfs@oss.sgi.com Thu Apr 18 19:02:58 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J22w8d017687 for ; Thu, 18 Apr 2002 19:02:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J22wUf017686 for linux-xfs-outgoing; Thu, 18 Apr 2002 19:02:58 -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 g3J22p8d017659 for ; Thu, 18 Apr 2002 19:02:51 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA888076 for ; Thu, 18 Apr 2002 19:03:56 -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.11.4/8.11.4/nodin-1.0) with ESMTP id g3J22sB136524; Thu, 18 Apr 2002 19:02:54 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 2900C3000BA; Fri, 19 Apr 2002 12:02:47 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id D649094; Fri, 19 Apr 2002 12:02:47 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: matthew@arts.usyd.edu.au Cc: linux-xfs@oss.sgi.com, roehrich@sgi.com Subject: Re: Can't build kernal with DMAPI as a module in 2.4 CVS In-reply-to: Your message of "Fri, 19 Apr 2002 10:36:52 +1000." <1019176612.3cbf66a453076@admin.arts.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Apr 2002 12:02:42 +1000 Message-ID: <8429.1019181762@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 19 Apr 2002 10:36:52 +1000, matthew@arts.usyd.edu.au wrote: > Not sure why you would want to - but I accidently selected DMAPI m instead of n >and the resulting kernel would not link due to what appeared to be missing DMAPI >function calls. > > I guess some one should get into kbuild and remove the option to build it as a >module ? Dean, as currently coded XFS has unconditional calls to DMAPI. This means that when XFS is built in then DMAPI cannot be a module. The patch below enforces this rule but I am not going to check it in until you decide if the code is correct or not. If XFS built in with DMAPI in a module is desirable then forget this patch, the DMAPI code has to be changed to use a register function and XFS to make conditional calls to DMAPI via the registered data. =========================================================================== Index: linux/fs/Config.in =========================================================================== --- /usr/tmp/TmpDir.27777-0/linux/fs/Config.in_1.77 Fri Apr 19 11:58:11 2002 +++ linux/fs/Config.in Fri Apr 19 11:50:22 2002 @@ -100,8 +100,16 @@ dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS if [ "$CONFIG_XFS_FS" != "n" ]; then + # Current DMAPI code has calls from XFS to DMAPI. This requires that + # DMAPI be built in if selected and XFS is built in. Valid combinations + # XFS=n, DMAPI=n + # XFS=y, DMAPI=[yn] + # XFS=m, DMAPI=[mn] dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS if [ "$CONFIG_XFS_DMAPI" != "n" ]; then + if [ "$CONFIG_XFS_FS" = "y" ]; then + define_tristate CONFIG_XFS_DMAPI y + fi define_bool CONFIG_HAVE_XFS_DMAPI y fi fi From owner-linux-xfs@oss.sgi.com Thu Apr 18 20:12:02 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J3C28d018631 for ; Thu, 18 Apr 2002 20:12:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J3C2rX018630 for linux-xfs-outgoing; Thu, 18 Apr 2002 20:12: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J3Br8d018602 for ; Thu, 18 Apr 2002 20:11:53 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id WAA34386; Thu, 18 Apr 2002 22:12:48 -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 WAA80697; Thu, 18 Apr 2002 22:12:48 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id WAA04315; Thu, 18 Apr 2002 22:12:47 -0500 (CDT) Message-Id: <200204190312.WAA04315@slobber.americas.sgi.com> To: Keith Owens cc: matthew@arts.usyd.edu.au, linux-xfs@oss.sgi.com Subject: Re: Can't build kernal with DMAPI as a module in 2.4 CVS Date: Thu, 18 Apr 2002 22:12:47 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Keith Owens >On Fri, 19 Apr 2002 10:36:52 +1000, >matthew@arts.usyd.edu.au wrote: >> Not sure why you would want to - but I accidently selected DMAPI m instead o >f n >>and the resulting kernel would not link due to what appeared to be missing DM >API >>function calls. >> >> I guess some one should get into kbuild and remove the option to build it as > a >>module ? > >Dean, as currently coded XFS has unconditional calls to DMAPI. This >means that when XFS is built in then DMAPI cannot be a module. The >patch below enforces this rule but I am not going to check it in until >you decide if the code is correct or not. > >If XFS built in with DMAPI in a module is desirable then forget this >patch, the DMAPI code has to be changed to use a register function and >XFS to make conditional calls to DMAPI via the registered data. The idea was that if XFS was built-in, then DMAPI must be built-in; and if XFS is a module, then DMAPI must be a module. I thought I had code in fs/Config.in to enforce this, but I've just been through its history back to the last time I touched it and I can't find a mod which does it any better than what you see today. I believe your change will limit DMAPI to [yn] if XFS is 'y', but does it really limit DMAPI to [mn] if XFS is 'm'? (I don't have convenient access to a build machine tonight.) Dean >=========================================================================== >Index: linux/fs/Config.in >=========================================================================== > >--- /usr/tmp/TmpDir.27777-0/linux/fs/Config.in_1.77 Fri Apr 19 11:58:11 200 >2 >+++ linux/fs/Config.in Fri Apr 19 11:50:22 2002 >@@ -100,8 +100,16 @@ > dep_mbool ' Enable XFS Realtime support' CONFIG_XFS_RT $CONFIG_XFS_FS > dep_mbool ' Enable XFS Quota' CONFIG_XFS_QUOTA $CONFIG_XFS_FS > if [ "$CONFIG_XFS_FS" != "n" ]; then >+ # Current DMAPI code has calls from XFS to DMAPI. This requires that >+ # DMAPI be built in if selected and XFS is built in. Valid combinations >+ # XFS=n, DMAPI=n >+ # XFS=y, DMAPI=[yn] >+ # XFS=m, DMAPI=[mn] > dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS > if [ "$CONFIG_XFS_DMAPI" != "n" ]; then >+ if [ "$CONFIG_XFS_FS" = "y" ]; then >+ define_tristate CONFIG_XFS_DMAPI y >+ fi > define_bool CONFIG_HAVE_XFS_DMAPI y > fi > fi > From owner-linux-xfs@oss.sgi.com Thu Apr 18 21:12:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J4Cu8d019250 for ; Thu, 18 Apr 2002 21:12:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J4CuM0019249 for linux-xfs-outgoing; Thu, 18 Apr 2002 21:12:56 -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 g3J4Co8d019223 for ; Thu, 18 Apr 2002 21:12:51 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA882683 for ; Thu, 18 Apr 2002 21:13:55 -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.11.4/8.11.4/nodin-1.0) with ESMTP id g3J4CrB159040; Thu, 18 Apr 2002 21:12:53 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 8F91E3000BA; Fri, 19 Apr 2002 14:12:48 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 7870694; Fri, 19 Apr 2002 14:12:48 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dean Roehrich Cc: matthew@arts.usyd.edu.au, linux-xfs@oss.sgi.com Subject: Re: Can't build kernal with DMAPI as a module in 2.4 CVS In-reply-to: Your message of "Thu, 18 Apr 2002 22:12:47 EST." <200204190312.WAA04315@slobber.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Apr 2002 14:12:43 +1000 Message-ID: <9251.1019189563@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 18 Apr 2002 22:12:47 -0500, Dean Roehrich wrote: >I believe your change will limit DMAPI to [yn] if XFS is 'y', but does it >really limit DMAPI to [mn] if XFS is 'm'? (I don't have convenient access to >a build machine tonight.) >> if [ "$CONFIG_XFS_FS" != "n" ]; then >>+ # Current DMAPI code has calls from XFS to DMAPI. This requires that >>+ # DMAPI be built in if selected and XFS is built in. Valid combinations >>+ # XFS=n, DMAPI=n >>+ # XFS=y, DMAPI=[yn] >>+ # XFS=m, DMAPI=[mn] >> dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS >> if [ "$CONFIG_XFS_DMAPI" != "n" ]; then >>+ if [ "$CONFIG_XFS_FS" = "y" ]; then >>+ define_tristate CONFIG_XFS_DMAPI y >>+ fi >> define_bool CONFIG_HAVE_XFS_DMAPI y >> fi dep_tristate enforces CONFIG_XFS_FS=m -> CONFIG_XFS_DMAPI=[mn] From owner-linux-xfs@oss.sgi.com Thu Apr 18 21:17:17 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J4HH8d019430 for ; Thu, 18 Apr 2002 21:17:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J4HHxB019429 for linux-xfs-outgoing; Thu, 18 Apr 2002 21:17: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J4HC8d019402 for ; Thu, 18 Apr 2002 21:17:12 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id XAA35149; Thu, 18 Apr 2002 23:18: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 XAA40863; Thu, 18 Apr 2002 23:18: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 XAA76645; Thu, 18 Apr 2002 23:18:09 -0500 (CDT) Message-Id: <200204190418.XAA76645@slobber.americas.sgi.com> To: Keith Owens cc: matthew@arts.usyd.edu.au, linux-xfs@oss.sgi.com Subject: Re: Can't build kernal with DMAPI as a module in 2.4 CVS Date: Thu, 18 Apr 2002 23:18:08 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: Keith Owens >On Thu, 18 Apr 2002 22:12:47 -0500, >Dean Roehrich wrote: >>I believe your change will limit DMAPI to [yn] if XFS is 'y', but does it >>really limit DMAPI to [mn] if XFS is 'm'? (I don't have convenient access to >>a build machine tonight.) >>> if [ "$CONFIG_XFS_FS" != "n" ]; then >>>+ # Current DMAPI code has calls from XFS to DMAPI. This requires that >>>+ # DMAPI be built in if selected and XFS is built in. Valid combination >s >>>+ # XFS=n, DMAPI=n >>>+ # XFS=y, DMAPI=[yn] >>>+ # XFS=m, DMAPI=[mn] >>> dep_tristate ' Enable XFS DMAPI' CONFIG_XFS_DMAPI $CONFIG_XFS_FS >>> if [ "$CONFIG_XFS_DMAPI" != "n" ]; then >>>+ if [ "$CONFIG_XFS_FS" = "y" ]; then >>>+ define_tristate CONFIG_XFS_DMAPI y >>>+ fi >>> define_bool CONFIG_HAVE_XFS_DMAPI y >>> fi > >dep_tristate enforces CONFIG_XFS_FS=m -> CONFIG_XFS_DMAPI=[mn] Ah, but apparently it doesn't enforce the other way. XFS=y -> DMAPI=[yn]. Why would that be? Dean From owner-linux-xfs@oss.sgi.com Thu Apr 18 21:26:06 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J4Q68d019668 for ; Thu, 18 Apr 2002 21:26:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J4Q6Cv019667 for linux-xfs-outgoing; Thu, 18 Apr 2002 21:26:06 -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 g3J4Q18d019641 for ; Thu, 18 Apr 2002 21:26:01 -0700 Received: from nodin.corp.sgi.com (fddi-nodin.corp.sgi.com [198.29.75.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA824140 for ; Thu, 18 Apr 2002 21:27:07 -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.11.4/8.11.4/nodin-1.0) with ESMTP id g3J4Q5B163325; Thu, 18 Apr 2002 21:26:05 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 9321E3000BA; Fri, 19 Apr 2002 14:26:04 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 79F8794; Fri, 19 Apr 2002 14:26:04 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Dean Roehrich Cc: matthew@arts.usyd.edu.au, linux-xfs@oss.sgi.com Subject: Re: Can't build kernal with DMAPI as a module in 2.4 CVS In-reply-to: Your message of "Thu, 18 Apr 2002 23:18:08 EST." <200204190418.XAA76645@slobber.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Apr 2002 14:25:59 +1000 Message-ID: <9445.1019190359@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 18 Apr 2002 23:18:08 -0500, Dean Roehrich wrote: >>dep_tristate enforces CONFIG_XFS_FS=m -> CONFIG_XFS_DMAPI=[mn] > >Ah, but apparently it doesn't enforce the other way. XFS=y -> DMAPI=[yn]. >Why would that be? Designed that way. The kernel config assumes a hierarchy of code, with the base code being selected first and options later, with the optional code calling the base, not the other way around. Then the base code can be built in and the optional code can be a module, so BASE=y with OPTIONAL=m is assumed to be valid. XFS/DMAPI is awkward because the base XFS code calls the optional DMAPI code directly, breaking the assumptions of dep_tristate. If you want the optional code to be a module when the base code is built in then direct function calls from base to optional are out. Instead the base code has to call the optional code via a function pointer and check if that pointer is filled in before using it. From owner-linux-xfs@oss.sgi.com Thu Apr 18 23:31:22 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J6VM8d020994 for ; Thu, 18 Apr 2002 23:31:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J6VM8P020993 for linux-xfs-outgoing; Thu, 18 Apr 2002 23:31:22 -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 g3J6VD8d020966 for ; Thu, 18 Apr 2002 23:31:14 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx01)) with ESMTP id DA00662A0; Fri, 19 Apr 2002 08:32: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 IAA08191; Fri, 19 Apr 2002 08:32:08 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 6D73257306; Fri, 19 Apr 2002 08:31:48 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id AFACD25835; Fri, 19 Apr 2002 08:31:47 +0200 (CEST) Message-ID: <3CBFB9D3.831D2C98@ch.sauter-bc.com> Date: Fri, 19 Apr 2002 08:31:47 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Jim Buzbee Cc: XFS List Subject: Re: IDE write cache and journaling file systems References: <3CBEE618.B220A393@echostar.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jim Buzbee schrieb: > > We've got a bit of an issue. From conversations on this list over the > last few months, it appears as if enabling the write cache on an IDE > drive is a "bad thing" when using a journaling file system such as XFS. > But, when talking to drive manufacturers, we are told that if the write > cache is disabled, the life of the drive is substantially reduced. This > puts us in a bit of a hard place. We have little choice but to turn the > write cache on. Jim, It's obvious that lifetime is reduced with write caching off. Just listen to the drive and compare between w/cache on / off. What helps here is that Linux uses memory for caching effectively. Some weeks ago I brought an issue to this list. I got zero filled files after _clean_ reboots and I thought it was the write cache of the IDE drives not flushing correctly. In fact I got bitten by the 'remount readonly bug' and it had nothing to do with the write chache being turned on. > > In our application, (consumer set top box) we cannot always cleanly shut > down the system. The consumer rightly expects to just unplug the box > when he wants/needs to. I'm not terribly concerned about losing a bit > of data in such a case. I'm worried about file system corruption that > would turn the box into an expensive door stop. My own testing so far > has not shown any catastrophic failures, but if we have a million boxes > in the field, issues could start showing up. > > The drive manufactures have recommended inserting IDE cache flushes at > critical sections of the code. I'm hesitant to muck with XFS internals, > and adding flushes in our user-space code would not cover all cases. Cache flushing does only work if the drive honours the flushing request correctly. What I recommend is trying to use drives which: - really flush cache when requested to do so. - flush cache on power failure. The latter is quite important because comsumers will just pull power to turn it off. I don't know whether this feature is available with IDE drives but I think it should be possible. -Simon > > This has to be a common problem. Does anyone have any strategies or > words of wisdom? > > Jim Buzbee, > Echostar Technologies From owner-linux-xfs@oss.sgi.com Fri Apr 19 01:55:32 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J8tW8d029121 for ; Fri, 19 Apr 2002 01:55:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J8tWPL029120 for linux-xfs-outgoing; Fri, 19 Apr 2002 01:55:32 -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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J8qj8d029067 for ; Fri, 19 Apr 2002 01:52:45 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id DAA40949 for ; Fri, 19 Apr 2002 03:53:46 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id DAA20318 for ; Fri, 19 Apr 2002 03:53:46 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3J8p5616941; Fri, 19 Apr 2002 03:51:05 -0500 Message-Id: <200204190851.g3J8p5616941@jen.americas.sgi.com> Date: Fri, 19 Apr 2002 03:51:05 -0500 Subject: TAKE - merge up to 2.5.8 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Not 100% happy with this, but it appears to function correctly. Date: Fri Apr 19 01:45:09 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:116847a linux/include/asm-ppc64/tlbflush.h - 1.1 linux/include/asm-ppc64/cacheflush.h - 1.1 linux/Documentation/BK-usage/bksend - 1.1 linux/Documentation/BK-usage/bz64wrap - 1.1 linux/lib/radix-tree.c - 1.1 linux/drivers/ieee1394/eth1394.c - 1.1 linux/Documentation/BK-usage/unbz64wrap - 1.1 linux/include/asm-ppc/tlbflush.h - 1.1 linux/drivers/net/tc35815.c - 1.1 linux/include/asm-ppc/percpu.h - 1.1 linux/include/asm-ppc/cacheflush.h - 1.1 linux/drivers/net/sun3_82586.h - 1.1 linux/drivers/net/sun3_82586.c - 1.1 linux/drivers/net/sb1250-mac.c - 1.1 linux/drivers/ide/ide-tcq.c - 1.1 linux/drivers/usb/README - 1.1 linux/drivers/usb/image/Makefile - 1.1 linux/drivers/net/e1000/e1000_hw.h - 1.1 linux/include/asm-i386/tlbflush.h - 1.1 linux/drivers/usb/class/Config.help - 1.1 linux/drivers/usb/class/Config.in - 1.1 linux/Documentation/networking/ppp_generic.txt - 1.1 linux/drivers/usb/class/Makefile - 1.1 linux/drivers/usb/class/Makefile.lib - 1.1 linux/drivers/usb/image/microtek.c - 1.1 linux/drivers/usb/class/audio.c - 1.1 linux/drivers/usb/class/audio.h - 1.1 linux/include/asm-i386/percpu.h - 1.1 linux/Documentation/usb/silverlink.txt - 1.1 linux/drivers/usb/class/bluetty.c - 1.1 linux/drivers/usb/input/Config.help - 1.1 linux/drivers/usb/class/cdc-acm.c - 1.1 linux/Documentation/watchdog-api.txt - 1.1 linux/include/asm-i386/irq_vectors.h - 1.1 linux/drivers/usb/class/printer.c - 1.1 linux/drivers/usb/core/Config.in - 1.1 linux/drivers/usb/core/Makefile - 1.1 linux/include/asm-i386/cacheflush.h - 1.1 linux/drivers/usb/core/devices.c - 1.1 linux/drivers/usb/core/devio.c - 1.1 linux/drivers/usb/core/drivers.c - 1.1 linux/include/asm-generic/percpu.h - 1.1 linux/drivers/usb/core/hcd.c - 1.1 linux/drivers/usb/core/hcd.h - 1.1 linux/drivers/usb/core/hub.c - 1.1 linux/drivers/usb/core/hub.h - 1.1 linux/drivers/usb/core/inode.c - 1.1 linux/drivers/usb/core/usb-debug.c - 1.1 linux/include/asm-arm/arch-pxa/vmalloc.h - 1.1 linux/include/asm-arm/arch-pxa/uncompress.h - 1.1 linux/include/asm-arm/arch-pxa/timex.h - 1.1 linux/include/asm-arm/arch-pxa/time.h - 1.1 linux/include/asm-arm/arch-pxa/system.h - 1.1 linux/include/asm-arm/arch-pxa/serial.h - 1.1 linux/include/asm-arm/arch-pxa/pxa-regs.h - 1.1 linux/include/asm-arm/arch-pxa/param.h - 1.1 linux/include/asm-arm/arch-pxa/memory.h - 1.1 linux/include/asm-arm/arch-pxa/lubbock.h - 1.1 linux/include/asm-arm/arch-pxa/keyboard.h - 1.1 linux/drivers/usb/input/hid-core.c - 1.1 linux/include/asm-arm/arch-pxa/irqs.h - 1.1 linux/include/asm-arm/arch-pxa/irq.h - 1.1 linux/include/asm-arm/arch-pxa/io.h - 1.1 linux/include/asm-arm/arch-pxa/idp.h - 1.1 linux/drivers/usb/media/dabusb.h - 1.1 linux/include/asm-arm/arch-pxa/ide.h - 1.1 linux/include/asm-arm/arch-pxa/hardware.h - 1.1 linux/include/asm-arm/arch-pxa/dma.h - 1.1 linux/drivers/usb/core/usb.c - 1.1 linux/include/asm-alpha/tlbflush.h - 1.1 linux/include/asm-alpha/cacheflush.h - 1.1 linux/include/linux/ticable.h - 1.1 linux/drivers/usb/host/Config.help - 1.1 linux/drivers/usb/host/Config.in - 1.1 linux/drivers/usb/host/Makefile - 1.1 linux/drivers/usb/media/konicawc.c - 1.1 linux/drivers/usb/host/ehci-dbg.c - 1.1 linux/drivers/usb/media/pwc-ioctl.h - 1.1 linux/arch/arm/mach-pxa/Makefile - 1.1 linux/arch/arm/mach-pxa/dma.c - 1.1 linux/arch/arm/mach-pxa/generic.c - 1.1 linux/arch/arm/mach-pxa/generic.h - 1.1 linux/arch/arm/mach-pxa/idp.c - 1.1 linux/arch/arm/mach-pxa/irq.c - 1.1 linux/arch/arm/mach-pxa/leds-idp.c - 1.1 linux/arch/arm/mach-pxa/leds-lubbock.c - 1.1 linux/arch/arm/mach-pxa/leds.c - 1.1 linux/arch/arm/mach-pxa/leds.h - 1.1 linux/arch/arm/mach-pxa/lubbock.c - 1.1 linux/drivers/usb/media/pwc-misc.c - 1.1 linux/drivers/usb/host/ehci-hcd.c - 1.1 linux/drivers/usb/host/ehci-hub.c - 1.1 linux/drivers/usb/host/ehci-mem.c - 1.1 linux/drivers/usb/host/ehci-q.c - 1.1 linux/drivers/usb/host/ehci-sched.c - 1.1 linux/drivers/usb/host/ehci.h - 1.1 linux/drivers/usb/host/ohci-dbg.c - 1.1 linux/drivers/usb/host/ohci-hcd.c - 1.1 linux/drivers/usb/host/ohci-hub.c - 1.1 linux/drivers/usb/host/ohci-mem.c - 1.1 linux/fs/partitions/efi.h - 1.1 linux/fs/partitions/efi.c - 1.1 linux/drivers/usb/host/ohci-q.c - 1.1 linux/drivers/usb/host/ohci.h - 1.1 linux/drivers/usb/media/pwc_kiara.h - 1.1 linux/drivers/usb/host/uhci-debug.h - 1.1 linux/drivers/usb/media/stv680.c - 1.1 linux/drivers/base/sys.c - 1.1 linux/drivers/base/power.c - 1.1 linux/drivers/base/base.h - 1.1 linux/drivers/usb/media/stv680.h - 1.1 linux/drivers/usb/media/usbvideo.c - 1.1 linux/drivers/usb/host/uhci.c - 1.1 linux/drivers/usb/host/uhci.h - 1.1 linux/drivers/usb/host/usb-ohci.c - 1.1 linux/drivers/usb/host/usb-ohci.h - 1.1 linux/drivers/usb/host/usb-uhci-debug.h - 1.1 linux/drivers/usb/host/usb-uhci.c - 1.1 linux/drivers/usb/host/usb-uhci.h - 1.1 linux/drivers/net/e1000/e1000_hw.c - 1.1 linux/drivers/usb/image/Config.help - 1.1 linux/drivers/usb/image/Config.in - 1.1 linux/drivers/ieee1394/cmp.h - 1.1 linux/drivers/usb/image/dc2xx.c - 1.1 linux/drivers/usb/image/hpusbscsi.c - 1.1 linux/drivers/usb/image/hpusbscsi.h - 1.1 linux/arch/i386/kernel/bootflag.c - 1.1 linux/drivers/usb/image/mdc800.c - 1.1 linux/drivers/ieee1394/cmp.c - 1.1 linux/drivers/usb/image/microtek.h - 1.1 linux/drivers/usb/image/scanner.c - 1.1 linux/drivers/usb/image/scanner.h - 1.1 linux/drivers/ieee1394/amdtp.h - 1.1 linux/drivers/usb/input/Config.in - 1.1 linux/drivers/usb/input/Makefile - 1.1 linux/drivers/ieee1394/amdtp.c - 1.1 linux/drivers/usb/input/hid-debug.h - 1.1 linux/drivers/usb/input/hid-input.c - 1.1 linux/fs/nls/nls_cp1250.c - 1.1 linux/drivers/usb/input/hid.h - 1.1 linux/drivers/usb/input/hiddev.c - 1.1 linux/drivers/usb/input/usbkbd.c - 1.1 linux/drivers/usb/input/usbmouse.c - 1.1 linux/drivers/usb/input/wacom.c - 1.1 linux/drivers/usb/media/Config.help - 1.1 linux/drivers/usb/media/Config.in - 1.1 linux/drivers/usb/media/Makefile - 1.1 linux/drivers/usb/media/dabfirmware.h - 1.1 linux/drivers/usb/media/dabusb.c - 1.1 linux/drivers/ieee1394/eth1394.h - 1.1 linux/drivers/usb/media/dsbr100.c - 1.1 linux/drivers/usb/media/ibmcam.c - 1.1 linux/include/linux/radix-tree.h - 1.1 linux/drivers/usb/media/ov511.c - 1.1 linux/drivers/usb/media/ov511.h - 1.1 linux/drivers/usb/media/pwc-ctrl.c - 1.1 linux/drivers/usb/media/pwc-if.c - 1.1 linux/drivers/video/clps711xfb.c - 1.1 linux/drivers/video/anakinfb.c - 1.1 linux/drivers/usb/media/pwc-uncompress.c - 1.1 linux/drivers/usb/media/pwc-uncompress.h - 1.1 linux/drivers/usb/media/pwc.h - 1.1 linux/kernel/platform.c - 1.1 linux/drivers/net/e100/e100_test.c - 1.1 linux/drivers/usb/storage/Config.in - 1.1 linux/drivers/usb/storage/Config.help - 1.1 linux/drivers/usb/media/pwc_nala.h - 1.1 linux/fs/minix/minix.h - 1.1 linux/drivers/usb/media/pwc_timon.h - 1.1 linux/drivers/usb/serial/safe_serial.c - 1.1 linux/drivers/usb/media/se401.c - 1.1 linux/drivers/usb/media/se401.h - 1.1 linux/drivers/usb/net/usbnet.c - 1.1 linux/drivers/usb/net/rtl8150.c - 1.1 linux/drivers/usb/media/ultracam.c - 1.1 linux/drivers/usb/net/pegasus.h - 1.1 linux/drivers/usb/media/usbvideo.h - 1.1 linux/drivers/usb/net/pegasus.c - 1.1 linux/drivers/usb/media/vicam.c - 1.1 linux/drivers/usb/media/vicam.h - 1.1 linux/drivers/usb/media/vicamurbs.h - 1.1 linux/drivers/usb/net/kawethfw.h - 1.1 linux/drivers/usb/net/kaweth.c - 1.1 linux/drivers/usb/net/cdc-ether.h - 1.1 linux/drivers/usb/net/cdc-ether.c - 1.1 linux/drivers/usb/net/catc.c - 1.1 linux/drivers/usb/net/Makefile - 1.1 linux/drivers/usb/net/Config.in - 1.1 linux/mm/readahead.c - 1.1 linux/drivers/usb/misc/Config.help - 1.1 linux/include/linux/platform.h - 1.1 linux/include/linux/percpu.h - 1.1 linux/mm/pdflush.c - 1.1 linux/drivers/usb/net/Config.help - 1.1 linux/drivers/usb/misc/uss720.c - 1.1 linux/drivers/usb/misc/Makefile - 1.1 linux/drivers/usb/misc/auerswald.c - 1.1 linux/drivers/usb/misc/emi26.c - 1.1 linux/drivers/usb/misc/emi26_fw.h - 1.1 linux/drivers/usb/misc/rio500.c - 1.1 linux/arch/ppc64/kernel/nvram.c - 1.1 linux/arch/ppc64/kernel/pSeries_htab.c - 1.1 linux/drivers/usb/misc/rio500_usb.h - 1.1 linux/drivers/usb/misc/tiglusb.c - 1.1 linux/drivers/usb/misc/tiglusb.h - 1.1 linux/net/x25/af_x25.c - 1.26 linux/net/sunrpc/xprt.c - 1.25 linux/net/sunrpc/stats.c - 1.9 linux/net/sched/sch_sfq.c - 1.6 linux/net/sched/sch_prio.c - 1.7 linux/net/rose/af_rose.c - 1.24 linux/net/packet/af_packet.c - 1.32 linux/net/netsyms.c - 1.45 linux/net/netrom/af_netrom.c - 1.23 linux/net/netlink/netlink_dev.c - 1.15 linux/net/lapb/lapb_iface.c - 1.10 linux/net/irda/qos.c - 1.15 linux/net/irda/irsysctl.c - 1.9 linux/net/irda/irlmp_frame.c - 1.10 linux/net/irda/irlmp_event.c - 1.15 linux/net/irda/irlmp.c - 1.17 linux/net/irda/irlap_event.c - 1.21 linux/net/irda/irlan/irlan_client.c - 1.11 linux/net/irda/af_irda.c - 1.35 linux/net/ipv6/udp.c - 1.26 linux/net/ipv6/tcp_ipv6.c - 1.35 linux/net/ipv6/sit.c - 1.19 linux/net/ipv6/ndisc.c - 1.21 linux/net/ipv6/addrconf.c - 1.23 linux/net/ipv4/udp.c - 1.31 linux/net/ipv4/tcp_output.c - 1.30 linux/net/ipv4/tcp_ipv4.c - 1.44 linux/net/ipv4/tcp_input.c - 1.37 linux/net/ipv4/tcp.c - 1.39 linux/net/ipv4/sysctl_net_ipv4.c - 1.14 linux/net/ipv4/route.c - 1.31 linux/net/ipv4/ipip.c - 1.21 linux/net/ipv4/ip_input.c - 1.16 linux/net/ipv4/ip_gre.c - 1.19 linux/net/ipv4/icmp.c - 1.28 linux/net/ipv4/fib_semantics.c - 1.8 linux/net/ipv4/fib_frontend.c - 1.12 linux/net/ipv4/devinet.c - 1.15 linux/net/ipv4/arp.c - 1.22 linux/net/ipv4/af_inet.c - 1.34 linux/net/core/sock.c - 1.25 linux/net/core/skbuff.c - 1.24 linux/net/core/neighbour.c - 1.14 linux/net/ax25/af_ax25.c - 1.25 linux/mm/vmscan.c - 1.97 linux/mm/vmalloc.c - 1.36 linux/mm/swapfile.c - 1.54 linux/mm/swap_state.c - 1.37 linux/mm/page_alloc.c - 1.76 linux/mm/mremap.c - 1.29 linux/mm/mprotect.c - 1.25 linux/mm/mmap.c - 1.48 linux/mm/memory.c - 1.79 linux/mm/filemap.c - 1.116 linux/mm/Makefile - 1.14 linux/lib/string.c - 1.14 linux/lib/Makefile - 1.11 linux/kernel/time.c - 1.9 linux/kernel/sysctl.c - 1.50 linux/kernel/sys.c - 1.30 linux/kernel/sched.c - 1.65 linux/kernel/module.c - 1.27 linux/kernel/ksyms.c - 1.141 linux/kernel/fork.c - 1.53 linux/kernel/exit.c - 1.43 linux/kernel/acct.c - 1.18 linux/kernel/Makefile - 1.29 linux/ipc/shm.c - 1.54 linux/ipc/sem.c - 1.16 linux/init/main.c - 1.77 linux/include/net/tcp.h - 1.30 linux/include/net/sock.h - 1.31 linux/include/net/pkt_sched.h - 1.9 linux/include/net/ndisc.h - 1.7 linux/include/net/irda/irlmp.h - 1.11 linux/include/net/irda/irlan_client.h - 1.4 linux/include/net/irda/discovery.h - 1.6 linux/include/linux/videodev.h - 1.22 linux/include/linux/sysctl.h - 1.47 linux/include/linux/swap.h - 1.55 linux/include/linux/sunrpc/svc.h - 1.7 linux/include/linux/string.h - 1.10 linux/include/linux/smp.h - 1.12 linux/include/linux/smb_fs.h - 1.19 linux/include/linux/skbuff.h - 1.24 linux/include/linux/securebits.h - 1.3 linux/include/linux/sched.h - 1.65 linux/include/linux/rtnetlink.h - 1.13 linux/include/linux/quota.h - 1.13 linux/include/linux/proc_fs.h - 1.34 linux/include/linux/pagemap.h - 1.41 linux/include/linux/nfsd/syscall.h - 1.8 linux/include/linux/nfsd/const.h - 1.5 linux/include/linux/netdevice.h - 1.34 linux/include/linux/nbd.h - 1.12 linux/include/linux/mm.h - 1.85 linux/include/linux/minix_fs_sb.h - 1.3 linux/include/linux/minix_fs_i.h - 1.4 linux/include/linux/minix_fs.h - 1.13 linux/include/linux/inetdevice.h - 1.7 linux/include/linux/hfs_sysdep.h - 1.9 linux/include/linux/hdreg.h - 1.18 linux/include/linux/fs.h - 1.166 linux/include/linux/blkdev.h - 1.54 linux/include/asm-sparc64/unistd.h - 1.20 linux/include/asm-sparc64/sbus.h - 1.7 linux/include/asm-sparc64/processor.h - 1.24 linux/include/asm-sparc64/pgtable.h - 1.34 linux/include/asm-sparc/unistd.h - 1.18 linux/include/asm-sparc/sbus.h - 1.8 linux/include/asm-sparc/pgtable.h - 1.25 linux/include/asm-sparc/elf.h - 1.5 linux/include/asm-ppc/unistd.h - 1.20 linux/include/asm-ppc/pgtable.h - 1.33 linux/include/asm-ppc/bitops.h - 1.13 linux/include/asm-mips/unistd.h - 1.12 linux/include/asm-mips/spinlock.h - 1.8 linux/include/asm-m68k/unistd.h - 1.13 linux/include/asm-m68k/string.h - 1.6 linux/include/asm-i386/unistd.h - 1.24 linux/include/asm-i386/timex.h - 1.5 linux/include/asm-i386/string.h - 1.12 linux/include/asm-i386/string-486.h - 1.8 linux/include/asm-i386/processor.h - 1.35 linux/include/asm-i386/pgtable.h - 1.31 linux/include/asm-i386/msr.h - 1.11 linux/include/asm-i386/mmu_context.h - 1.18 linux/include/asm-i386/irq.h - 1.6 linux/include/asm-i386/io.h - 1.26 linux/include/asm-i386/checksum.h - 1.7 linux/include/asm-i386/bugs.h - 1.15 linux/include/asm-i386/bitops.h - 1.12 linux/include/asm-arm/unistd.h - 1.20 linux/include/asm-arm/system.h - 1.18 linux/include/asm-arm/siginfo.h - 1.8 linux/include/asm-arm/mman.h - 1.4 linux/include/asm-arm/leds.h - 1.5 linux/include/asm-arm/irq.h - 1.4 linux/include/asm-alpha/unistd.h - 1.18 linux/fs/vfat/namei.c - 1.30 linux/fs/umsdos/inode.c - 1.25 linux/fs/ufs/super.c - 1.28 linux/fs/super.c - 1.83 linux/fs/smbfs/proc.c - 1.19 linux/fs/smbfs/inode.c - 1.33 linux/fs/romfs/inode.c - 1.34 linux/fs/read_write.c - 1.20 linux/fs/qnx4/TODO - 1.4 linux/fs/qnx4/BUGS - 1.4 linux/fs/proc/inode.c - 1.21 linux/fs/proc/generic.c - 1.29 linux/fs/proc/array.c - 1.41 linux/fs/open.c - 1.36 linux/fs/ntfs/support.h - 1.7 linux/fs/ntfs/fs.c - 1.42 linux/fs/ntfs/Makefile - 1.15 linux/fs/nls/nls_koi8-r.c - 1.7 linux/fs/nls/nls_iso8859-9.c - 1.7 linux/fs/nls/nls_iso8859-8.c - 1.8 linux/fs/nls/nls_iso8859-7.c - 1.7 linux/fs/nls/nls_iso8859-6.c - 1.7 linux/fs/nls/nls_iso8859-5.c - 1.7 linux/fs/nls/nls_iso8859-4.c - 1.7 linux/fs/nls/nls_iso8859-3.c - 1.7 linux/fs/nls/nls_iso8859-2.c - 1.7 linux/fs/nls/nls_iso8859-15.c - 1.7 linux/fs/nls/nls_iso8859-1.c - 1.7 linux/fs/nls/nls_cp874.c - 1.8 linux/fs/nls/nls_cp869.c - 1.8 linux/fs/nls/nls_cp866.c - 1.8 linux/fs/nls/nls_cp865.c - 1.8 linux/fs/nls/nls_cp864.c - 1.8 linux/fs/nls/nls_cp863.c - 1.8 linux/fs/nls/nls_cp862.c - 1.8 linux/fs/nls/nls_cp861.c - 1.8 linux/fs/nls/nls_cp860.c - 1.8 linux/fs/nls/nls_cp857.c - 1.8 linux/fs/nls/nls_cp855.c - 1.8 linux/fs/nls/nls_cp852.c - 1.8 linux/fs/nls/nls_cp850.c - 1.8 linux/fs/nls/nls_cp775.c - 1.8 linux/fs/nls/nls_cp737.c - 1.8 linux/fs/nls/nls_cp437.c - 1.8 linux/fs/nls/nls_base.c - 1.10 linux/fs/nls/Config.in - 1.11 linux/fs/nfsd/vfs.c - 1.49 linux/fs/nfsd/stats.c - 1.9 linux/fs/nfsd/nfsxdr.c - 1.15 linux/fs/nfsd/nfssvc.c - 1.21 linux/fs/nfsd/nfsproc.c - 1.23 linux/fs/nfsd/nfsfh.c - 1.39 linux/fs/nfsd/nfsctl.c - 1.30 linux/fs/nfsd/nfs3xdr.c - 1.26 linux/fs/nfsd/nfs3proc.c - 1.14 linux/fs/nfsd/lockd.c - 1.9 linux/fs/nfsd/export.c - 1.33 linux/fs/nfs/proc.c - 1.13 linux/fs/nfs/nfsroot.c - 1.13 linux/fs/nfs/nfs3xdr.c - 1.9 linux/fs/nfs/nfs2xdr.c - 1.12 linux/fs/nfs/mount_clnt.c - 1.6 linux/fs/nfs/inode.c - 1.41 linux/fs/ncpfs/inode.c - 1.30 linux/fs/namei.c - 1.51 linux/fs/msdos/namei.c - 1.30 linux/fs/minix/namei.c - 1.19 linux/fs/minix/inode.c - 1.33 linux/fs/minix/file.c - 1.14 linux/fs/minix/dir.c - 1.11 linux/fs/minix/bitmap.c - 1.16 linux/fs/lockd/xdr.c - 1.13 linux/fs/lockd/svc.c - 1.17 linux/fs/lockd/mon.c - 1.10 linux/fs/isofs/inode.c - 1.36 linux/fs/inode.c - 1.72 linux/fs/hfs/super.c - 1.17 linux/fs/hfs/inode.c - 1.17 linux/fs/hfs/file_hdr.c - 1.15 linux/fs/hfs/file_cap.c - 1.14 linux/fs/hfs/file.c - 1.18 linux/fs/filesystems.c - 1.23 linux/fs/file_table.c - 1.19 linux/fs/fat/inode.c - 1.41 linux/fs/ext2/super.c - 1.29 linux/fs/ext2/inode.c - 1.45 linux/fs/ext2/ialloc.c - 1.25 linux/fs/dquot.c - 1.54 linux/fs/devpts/inode.c - 1.16 linux/fs/coda/inode.c - 1.23 linux/fs/buffer.c - 1.117 linux/fs/block_dev.c - 1.45 linux/fs/binfmt_script.c - 1.14 linux/fs/binfmt_misc.c - 1.22 linux/fs/binfmt_em86.c - 1.13 linux/fs/binfmt_elf.c - 1.41 linux/fs/binfmt_aout.c - 1.26 linux/fs/autofs/inode.c - 1.13 linux/fs/attr.c - 1.15 linux/fs/affs/super.c - 1.23 linux/fs/affs/inode.c - 1.20 linux/fs/adfs/super.c - 1.20 linux/fs/adfs/inode.c - 1.23 linux/fs/Makefile - 1.53 linux/fs/Config.in - 1.83 linux/drivers/video/fbmem.c - 1.46 linux/drivers/video/atafb.c - 1.14 linux/drivers/video/amifb.c - 1.22 linux/drivers/video/Makefile - 1.36 linux/drivers/video/Config.in - 1.34 linux/drivers/usb/usb.c - 1.73 linux/drivers/usb/usb-debug.c - 1.16 linux/drivers/usb/uhci.h - 1.29 linux/drivers/usb/uhci.c - 1.62 linux/drivers/usb/hub.h - 1.19 linux/drivers/usb/hub.c - 1.46 linux/drivers/usb/audio.c - 1.42 linux/drivers/usb/Makefile - 1.50 linux/drivers/usb/Config.in - 1.56 linux/drivers/scsi/u14-34f.c - 1.22 linux/drivers/scsi/tmscsim.c - 1.16 linux/drivers/scsi/sd.c - 1.58 linux/drivers/scsi/scsi.c - 1.53 linux/drivers/scsi/ppa.c - 1.15 linux/drivers/scsi/ide-scsi.c - 1.31 linux/drivers/scsi/fdomain.c - 1.20 linux/drivers/scsi/eata.c - 1.24 linux/drivers/scsi/a2091.c - 1.14 linux/drivers/scsi/NCR53C9x.c - 1.13 linux/drivers/scsi/53c7xx.c - 1.15 linux/drivers/scsi/53c7,8xx.c - 1.19 linux/drivers/sbus/sbus.c - 1.16 linux/drivers/sbus/audio/cs4231.c - 1.13 linux/drivers/sbus/audio/amd7930.c - 1.11 linux/drivers/pci/pci.c - 1.58 linux/drivers/net/wd.c - 1.17 linux/drivers/net/sunhme.h - 1.13 linux/drivers/net/sunhme.c - 1.36 linux/drivers/net/strip.c - 1.18 linux/drivers/net/sonic.c - 1.8 linux/drivers/net/smc-ultra32.c - 1.15 linux/drivers/net/smc-ultra.c - 1.21 linux/drivers/net/smc-mca.c - 1.15 linux/drivers/net/sgiseeq.c - 1.13 linux/drivers/net/rrunner.c - 1.19 linux/drivers/net/ppp_deflate.c - 1.9 linux/drivers/net/pcnet32.c - 1.34 linux/drivers/net/ne3210.c - 1.16 linux/drivers/net/lne390.c - 1.17 linux/drivers/net/lance.c - 1.24 linux/drivers/net/irda/w83977af_ir.c - 1.23 linux/drivers/net/irda/irtty.c - 1.26 linux/drivers/net/hydra.c - 1.15 linux/drivers/net/hp-plus.c - 1.17 linux/drivers/net/hamradio/soundmodem/smdma.h - 1.3 linux/drivers/net/hamradio/soundmodem/sm_wss.c - 1.8 linux/drivers/net/hamradio/soundmodem/sm_sbc.c - 1.7 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/scc.c - 1.25 linux/drivers/net/hamradio/mkiss.c - 1.15 linux/drivers/net/hamradio/hdlcdrv.c - 1.16 linux/drivers/net/hamradio/dmascc.c - 1.11 linux/drivers/net/hamradio/bpqether.c - 1.20 linux/drivers/net/hamradio/baycom_ser_hdx.c - 1.15 linux/drivers/net/hamradio/baycom_ser_fdx.c - 1.15 linux/drivers/net/hamradio/baycom_par.c - 1.15 linux/drivers/net/hamradio/baycom_epp.c - 1.20 linux/drivers/net/hamradio/6pack.c - 1.14 linux/drivers/net/es3210.c - 1.17 linux/drivers/net/epic100.c - 1.29 linux/drivers/net/eepro100.c - 1.43 linux/drivers/net/e2100.c - 1.17 linux/drivers/net/de620.c - 1.14 linux/drivers/net/daynaport.c - 1.11 linux/drivers/net/atp.c - 1.18 linux/drivers/net/at1700.c - 1.18 linux/drivers/net/ariadne2.c - 1.12 linux/drivers/net/ariadne.c - 1.14 linux/drivers/net/acenic.h - 1.20 linux/drivers/net/acenic.c - 1.39 linux/drivers/net/ac3200.c - 1.19 linux/drivers/net/a2065.c - 1.16 linux/drivers/net/Space.c - 1.33 linux/drivers/net/Makefile - 1.56 linux/drivers/net/Config.in - 1.60 linux/drivers/net/8390.h - 1.10 linux/drivers/net/7990.c - 1.7 linux/drivers/net/3c59x.c - 1.34 linux/drivers/net/3c505.c - 1.26 linux/drivers/net/3c503.c - 1.22 linux/drivers/macintosh/adb.c - 1.14 linux/drivers/fc4/socal.c - 1.12 linux/drivers/fc4/soc.c - 1.12 linux/drivers/char/wdt.c - 1.15 linux/drivers/char/tty_ioctl.c - 1.6 linux/drivers/char/tty_io.c - 1.42 linux/drivers/char/tpqic02.c - 1.19 linux/drivers/char/synclink.c - 1.24 linux/drivers/char/stallion.c - 1.20 linux/drivers/char/softdog.c - 1.15 linux/drivers/char/rocket.c - 1.16 linux/drivers/char/random.c - 1.26 linux/drivers/char/n_tty.c - 1.14 linux/drivers/char/mem.c - 1.45 linux/drivers/char/esp.c - 1.17 linux/drivers/char/cyclades.c - 1.22 linux/drivers/char/acquirewdt.c - 1.16 linux/drivers/cdrom/cdrom.c - 1.41 linux/drivers/block/rd.c - 1.48 linux/drivers/block/nbd.c - 1.35 linux/drivers/block/loop.c - 1.54 linux/drivers/block/ll_rw_blk.c - 1.97 linux/drivers/block/genhd.c - 1.25 linux/drivers/acorn/scsi/eesox.c - 1.13 linux/arch/sparc64/solaris/timod.c - 1.20 linux/arch/sparc64/solaris/misc.c - 1.23 linux/arch/sparc64/prom/misc.c - 1.10 linux/arch/sparc64/prom/bootstr.c - 1.4 linux/arch/sparc64/mm/init.c - 1.41 linux/arch/sparc64/math-emu/math.c - 1.8 linux/arch/sparc64/kernel/trampoline.S - 1.12 linux/arch/sparc64/kernel/time.c - 1.19 linux/arch/sparc64/kernel/sys_sunos32.c - 1.37 linux/arch/sparc64/kernel/sys_sparc.c - 1.24 linux/arch/sparc64/kernel/sparc64_ksyms.c - 1.42 linux/arch/sparc64/kernel/smp.c - 1.41 linux/arch/sparc64/kernel/signal32.c - 1.23 linux/arch/sparc64/kernel/signal.c - 1.21 linux/arch/sparc64/kernel/ptrace.c - 1.17 linux/arch/sparc64/kernel/process.c - 1.34 linux/arch/sparc64/kernel/irq.c - 1.23 linux/arch/sparc64/kernel/ioctl32.c - 1.53 linux/arch/sparc64/kernel/head.S - 1.17 linux/arch/sparc64/kernel/ebus.c - 1.16 linux/arch/sparc64/defconfig - 1.65 linux/arch/sparc/mm/tsunami.S - 1.9 linux/arch/sparc/mm/sun4c.c - 1.31 linux/arch/sparc/mm/srmmu.c - 1.30 linux/arch/sparc/mm/iommu.c - 1.12 linux/arch/sparc/kernel/traps.c - 1.9 linux/arch/sparc/kernel/time.c - 1.16 linux/arch/sparc/kernel/sun4d_smp.c - 1.20 linux/arch/sparc/kernel/sparc_ksyms.c - 1.26 linux/arch/sparc/kernel/signal.c - 1.23 linux/arch/sparc/kernel/setup.c - 1.21 linux/arch/sparc/kernel/ptrace.c - 1.13 linux/arch/sparc/kernel/process.c - 1.26 linux/arch/sparc/kernel/pcic.c - 1.18 linux/arch/sparc/kernel/irq.c - 1.20 linux/arch/sparc/kernel/ioport.c - 1.20 linux/arch/ppc/kernel/smp.c - 1.36 linux/arch/ppc/kernel/signal.c - 1.16 linux/arch/ppc/kernel/ppc_ksyms.c - 1.41 linux/arch/ppc/kernel/misc.S - 1.38 linux/arch/ppc/kernel/idle.c - 1.23 linux/arch/ppc/config.in - 1.48 linux/arch/mips/sni/pci.c - 1.10 linux/arch/mips/kernel/signal.c - 1.16 linux/arch/mips/kernel/mips_ksyms.c - 1.12 linux/arch/m68k/kernel/m68k_ksyms.c - 1.11 linux/arch/m68k/atari/config.c - 1.7 linux/arch/i386/mm/ioremap.c - 1.12 linux/arch/i386/mm/init.c - 1.35 linux/arch/i386/kernel/vm86.c - 1.14 linux/arch/i386/kernel/traps.c - 1.52 linux/arch/i386/kernel/smp.c - 1.43 linux/arch/i386/kernel/signal.c - 1.25 linux/arch/i386/kernel/setup.c - 1.72 linux/arch/i386/kernel/ptrace.c - 1.22 linux/arch/i386/kernel/mtrr.c - 1.35 linux/arch/i386/kernel/io_apic.c - 1.35 linux/arch/i386/kernel/i386_ksyms.c - 1.47 linux/arch/i386/kernel/entry.S - 1.53 linux/arch/i386/kernel/Makefile - 1.27 linux/arch/i386/defconfig - 1.105 linux/arch/i386/config.in - 1.77 linux/arch/arm/mm/proc-sa110.S - 1.26 linux/arch/arm/mm/proc-arm6,7.S - 1.22 linux/arch/arm/mm/mm-armv.c - 1.26 linux/arch/arm/mm/init.c - 1.27 linux/arch/arm/mm/fault-armv.c - 1.24 linux/arch/arm/kernel/traps.c - 1.26 linux/arch/arm/kernel/signal.c - 1.22 linux/arch/arm/kernel/ptrace.c - 1.17 linux/arch/arm/kernel/irq.c - 1.17 linux/arch/arm/kernel/entry-armv.S - 1.27 linux/arch/arm/kernel/ecard.c - 1.19 linux/arch/arm/kernel/armksyms.c - 1.25 linux/arch/arm/config.in - 1.38 linux/arch/arm/boot/compressed/head.S - 1.16 linux/arch/alpha/mm/fault.c - 1.17 linux/arch/alpha/kernel/sys_takara.c - 1.9 linux/arch/alpha/kernel/sys_sx164.c - 1.11 linux/arch/alpha/kernel/sys_sio.c - 1.14 linux/arch/alpha/kernel/sys_sable.c - 1.9 linux/arch/alpha/kernel/sys_rx164.c - 1.9 linux/arch/alpha/kernel/sys_ruffian.c - 1.13 linux/arch/alpha/kernel/sys_rawhide.c - 1.13 linux/arch/alpha/kernel/sys_noritake.c - 1.10 linux/arch/alpha/kernel/sys_mikasa.c - 1.11 linux/arch/alpha/kernel/sys_miata.c - 1.13 linux/arch/alpha/kernel/sys_jensen.c - 1.11 linux/arch/alpha/kernel/sys_eb64p.c - 1.9 linux/arch/alpha/kernel/sys_dp264.c - 1.18 linux/arch/alpha/kernel/sys_cabriolet.c - 1.14 linux/arch/alpha/kernel/sys_alcor.c - 1.10 linux/arch/alpha/kernel/setup.c - 1.28 linux/arch/alpha/kernel/alpha_ksyms.c - 1.32 linux/Rules.make - 1.17 linux/Makefile - 1.193 linux/MAINTAINERS - 1.102 linux/Documentation/networking/vortex.txt - 1.11 linux/Documentation/networking/ip-sysctl.txt - 1.11 linux/Documentation/Changes - 1.48 linux/Documentation/00-INDEX - 1.12 linux/CREDITS - 1.77 linux/include/linux/ide.h - 1.45 linux/fs/hpfs/super.c - 1.16 linux/fs/hpfs/namei.c - 1.15 linux/fs/hpfs/inode.c - 1.17 linux/drivers/video/cyber2000fb.h - 1.13 linux/drivers/video/cyber2000fb.c - 1.29 linux/drivers/usb/printer.c - 1.45 linux/drivers/usb/acm.c - 1.47 linux/drivers/sbus/char/aurora.c - 1.19 linux/drivers/isdn/eicon/eicon_mod.c - 1.16 linux/drivers/block/blkpg.c - 1.19 linux/Documentation/kernel-parameters.txt - 1.16 linux/drivers/tc/zs.c - 1.8 linux/drivers/net/arlan.c - 1.22 linux/fs/iobuf.c - 1.22 linux/drivers/parport/parport_mfc3.c - 1.9 linux/drivers/char/raw.c - 1.22 linux/include/linux/iobuf.h - 1.16 linux/include/asm-i386/apic.h - 1.16 linux/drivers/net/ppp_generic.c - 1.26 linux/drivers/net/ppp_async.c - 1.15 linux/drivers/net/hamradio/yam.c - 1.18 linux/include/asm-arm/proc-armv/domain.h - 1.3 linux/drivers/usb/uss720.c - 1.23 linux/net/khttpd/sockets.c - 1.5 linux/include/asm-i386/hw_irq.h - 1.26 linux/fs/partitions/msdos.c - 1.20 linux/fs/partitions/check.c - 1.38 linux/fs/partitions/Makefile - 1.8 linux/fs/partitions/Config.in - 1.16 linux/drivers/scsi/sun3x_esp.c - 1.7 linux/drivers/isdn/avmb1/kcapi.c - 1.17 linux/arch/i386/kernel/i8259.c - 1.27 linux/fs/nls/nls_iso8859-14.c - 1.6 linux/drivers/net/sb1000.c - 1.16 linux/drivers/char/ip2/i2lib.c - 1.7 linux/drivers/atm/eni.c - 1.15 linux/net/atm/resources.c - 1.8 linux/arch/ppc/kernel/semaphore.c - 1.7 linux/arch/arm/kernel/bios32.c - 1.26 linux/drivers/block/DAC960.c - 1.45 linux/arch/sparc64/kernel/semaphore.c - 1.9 linux/arch/sparc64/kernel/power.c - 1.8 linux/arch/sparc64/kernel/pci_sabre.c - 1.30 linux/arch/sparc64/kernel/pci_psycho.c - 1.28 linux/arch/sparc64/kernel/pci_common.c - 1.18 linux/arch/sparc64/kernel/pci.c - 1.26 linux/arch/sh/kernel/sh_ksyms.c - 1.11 linux/arch/ppc/math-emu/op-4.h - 1.3 linux/include/asm-arm/cpu-single.h - 1.11 linux/include/asm-arm/cpu-multi32.h - 1.11 linux/drivers/char/applicom.c - 1.12 linux/net/irda/ircomm/ircomm_tty_ioctl.c - 1.8 linux/net/irda/ircomm/ircomm_tty_attach.c - 1.9 linux/net/irda/ircomm/ircomm_tty.c - 1.17 linux/include/net/irda/ircomm_tty.h - 1.8 linux/include/asm-sh/unistd.h - 1.13 linux/drivers/pcmcia/Config.in - 1.12 linux/include/linux/udf_fs.h - 1.14 linux/fs/udf/super.c - 1.29 linux/include/linux/spinlock.h - 1.16 linux/drivers/sbus/char/uctrl.c - 1.13 linux/drivers/net/pcmcia/pcnet_cs.c - 1.18 linux/include/linux/acpi.h - 1.24 linux/drivers/net/wan/cosa.c - 1.24 linux/drivers/net/tokenring/olympic.c - 1.19 linux/arch/i386/kernel/smpboot.c - 1.36 linux/arch/i386/kernel/pci-pc.c - 1.36 linux/include/linux/pci_ids.h - 1.63 linux/drivers/net/wan/sdla_ppp.c - 1.17 linux/drivers/usb/audio.h - 1.3 linux/mm/highmem.c - 1.38 linux/include/linux/highmem.h - 1.20 linux/include/asm-i386/highmem.h - 1.11 linux/include/asm-arm/proc-armv/cache.h - 1.14 linux/include/asm-arm/arch-sa1100/keyboard.h - 1.9 linux/drivers/net/ppp_synctty.c - 1.11 linux/fs/proc/proc_misc.c - 1.32 linux/drivers/usb/dc2xx.c - 1.25 linux/drivers/pci/pci.ids - 1.45 linux/include/asm-ppc/pgalloc.h - 1.9 linux/include/asm-i386/pgalloc.h - 1.18 linux/include/asm-arm/pgalloc.h - 1.10 linux/include/asm-arm/arch-cl7500/system.h - 1.12 linux/include/asm-alpha/pgalloc.h - 1.14 linux/arch/alpha/kernel/sys_nautilus.c - 1.8 linux/arch/alpha/kernel/sys_eiger.c - 1.7 linux/arch/alpha/kernel/core_irongate.c - 1.9 linux/drivers/net/aironet4500.h - 1.10 linux/drivers/char/agp/agpgart_be.c - 1.34 linux/drivers/usb/uhci-debug.h - 1.10 linux/drivers/i2c/i2c-dev.c - 1.16 linux/drivers/i2c/i2c-algo-bit.c - 1.11 linux/drivers/usb/dabusb.h - 1.8 linux/drivers/usb/dabusb.c - 1.19 linux/arch/sparc/mm/swift.S - 1.7 linux/arch/i386/kernel/acpi.c - 1.24 linux/include/asm-sparc64/pgalloc.h - 1.19 linux/fs/cramfs/inode.c - 1.28 linux/drivers/usb/scanner.c - 1.32 linux/drivers/usb/usbmouse.c - 1.19 linux/drivers/usb/usbkbd.c - 1.25 linux/drivers/usb/ov511.h - 1.16 linux/drivers/usb/ov511.c - 1.36 linux/drivers/usb/hid.h - 1.19 linux/drivers/usb/hid-debug.h - 1.8 linux/drivers/net/arcnet/rfc1201.c - 1.5 linux/drivers/net/arcnet/rfc1051.c - 1.3 linux/drivers/net/arcnet/com90xx.c - 1.9 linux/drivers/net/arcnet/com90io.c - 1.10 linux/drivers/net/arcnet/com20020.c - 1.5 linux/drivers/net/arcnet/com20020-pci.c - 1.12 linux/drivers/net/arcnet/com20020-isa.c - 1.8 linux/drivers/net/arcnet/arcnet.c - 1.12 linux/drivers/net/arcnet/arc-rimi.c - 1.7 linux/drivers/net/arcnet/arc-rawmode.c - 1.3 linux/Documentation/usb/proc_usb_info.txt - 1.4 linux/drivers/net/tokenring/smctr.c - 1.15 linux/drivers/usb/devices.c - 1.17 linux/drivers/usb/devio.c - 1.29 linux/drivers/usb/drivers.c - 1.9 linux/drivers/usb/inode.c - 1.26 linux/drivers/ieee1394/raw1394.c - 1.17 linux/drivers/ieee1394/pcilynx.c - 1.19 linux/drivers/ieee1394/ieee1394_core.c - 1.18 linux/drivers/ieee1394/ohci1394.h - 1.14 linux/drivers/ieee1394/ohci1394.c - 1.21 linux/drivers/ieee1394/ieee1394_types.h - 1.12 linux/drivers/ieee1394/ieee1394_transactions.h - 1.4 linux/drivers/ieee1394/ieee1394_transactions.c - 1.10 linux/arch/arm/lib/findbit.S - 1.6 linux/arch/arm/lib/memchr.S - 1.4 linux/arch/i386/kernel/apic.c - 1.28 linux/drivers/ieee1394/hosts.h - 1.9 linux/drivers/ieee1394/hosts.c - 1.11 linux/arch/i386/kernel/mpparse.c - 1.17 linux/drivers/ieee1394/Config.in - 1.7 linux/drivers/char/mxser.c - 1.15 linux/drivers/ieee1394/Makefile - 1.11 linux/include/asm-i386/apicdef.h - 1.8 linux/drivers/usb/dabfirmware.h - 1.2 linux/drivers/scsi/3w-xxxx.h - 1.10 linux/drivers/scsi/3w-xxxx.c - 1.18 linux/drivers/char/mixcomwd.c - 1.10 linux/arch/i386/kernel/pci-dma.c - 1.4 linux/Documentation/DMA-mapping.txt - 1.14 linux/drivers/usb/usb-uhci.h - 1.12 linux/drivers/usb/usb-uhci.c - 1.42 linux/drivers/usb/usb-ohci.h - 1.17 linux/drivers/usb/usb-ohci.c - 1.39 linux/drivers/usb/scanner.h - 1.22 linux/drivers/usb/ibmcam.c - 1.17 linux/fs/autofs4/inode.c - 1.13 linux/drivers/usb/usb-uhci-debug.h - 1.8 linux/drivers/net/irda/nsc-ircc.c - 1.21 linux/drivers/char/vme_scc.c - 1.9 linux/arch/ia64/kernel/mca.c - 1.10 linux/drivers/scsi/qla1280.h - 1.4 linux/fs/adfs/dir_f.c - 1.7 linux/fs/adfs/dir_fplus.c - 1.6 linux/drivers/scsi/qla1280.c - 1.15 linux/drivers/scsi/ql1280_fw.h - 1.2 linux/drivers/scsi/ql12160_fw.h - 1.2 linux/include/asm-ia64/efi.h - 1.8 linux/include/linux/raid/md_k.h - 1.19 linux/include/asm-ia64/sal.h - 1.10 linux/include/linux/raid/md.h - 1.10 linux/include/asm-ia64/unistd.h - 1.18 linux/arch/m68k/mac/baboon.c - 1.4 linux/arch/i386/kernel/microcode.c - 1.13 linux/Documentation/filesystems/devfs/README - 1.14 linux/Documentation/filesystems/devfs/ChangeLog - 1.20 linux/include/linux/devfs_fs_kernel.h - 1.11 linux/fs/devfs/util.c - 1.12 linux/fs/devfs/base.c - 1.37 linux/drivers/net/skfp/skfddi.c - 1.12 linux/fs/lockd/xdr4.c - 1.8 linux/drivers/net/ioc3-eth.c - 1.18 linux/drivers/char/wdt977.c - 1.8 linux/drivers/char/nwflash.c - 1.11 linux/drivers/char/ds1620.c - 1.6 linux/include/asm-mips64/unistd.h - 1.9 linux/include/asm-mips64/spinlock.h - 1.4 linux/arch/mips64/kernel/mips64_ksyms.c - 1.8 linux/drivers/usb/wacom.c - 1.19 linux/drivers/usb/rio500_usb.h - 1.2 linux/drivers/usb/rio500.c - 1.16 linux/drivers/usb/pegasus.c - 1.31 linux/net/econet/af_econet.c - 1.11 linux/include/linux/usb.h - 1.33 linux/drivers/usb/serial/usb-serial.h - 1.19 linux/drivers/usb/serial/Makefile - 1.18 linux/drivers/ide/via82cxxx.c - 1.25 linux/drivers/ide/umc8672.c - 1.5 linux/drivers/ide/trm290.c - 1.5 linux/drivers/ide/sl82c105.c - 1.9 linux/drivers/ide/sis5513.c - 1.17 linux/drivers/ide/rz1000.c - 1.6 linux/drivers/ide/piix.c - 1.20 linux/drivers/ide/pdc4030.c - 1.13 linux/drivers/ide/pdc202xx.c - 1.17 linux/drivers/ide/opti621.c - 1.9 linux/drivers/ide/ns87415.c - 1.6 linux/drivers/ide/macide.c - 1.4 linux/drivers/ide/ide.c - 1.49 linux/drivers/ide/ide-tape.c - 1.23 linux/drivers/ide/ide-proc.c - 1.16 linux/drivers/ide/ide-probe.c - 1.28 linux/drivers/ide/ide-pnp.c - 1.7 linux/drivers/ide/ide-pmac.c - 1.10 linux/drivers/ide/ide-pci.c - 1.25 linux/drivers/ide/ide-geometry.c - 1.12 linux/drivers/ide/ide-floppy.c - 1.20 linux/drivers/ide/ide-features.c - 1.11 linux/drivers/ide/ide-dma.c - 1.24 linux/drivers/ide/ide-disk.c - 1.31 linux/drivers/ide/ide-cd.c - 1.31 linux/drivers/ide/icside.c - 1.13 linux/drivers/ide/ht6560b.c - 1.7 linux/drivers/ide/hpt366.c - 1.16 linux/drivers/ide/hpt34x.c - 1.9 linux/drivers/ide/gayle.c - 1.6 linux/drivers/ide/dtc2278.c - 1.6 linux/drivers/ide/cy82c693.c - 1.9 linux/drivers/ide/cs5530.c - 1.8 linux/drivers/ide/cmd64x.c - 1.12 linux/drivers/ide/cmd640.c - 1.8 linux/drivers/ide/buddha.c - 1.9 linux/drivers/ide/alim15x3.c - 1.14 linux/drivers/ide/ali14xx.c - 1.8 linux/drivers/ide/Makefile - 1.19 linux/drivers/ide/Config.in - 1.21 linux/drivers/block/elevator.c - 1.16 linux/Documentation/DocBook/Makefile - 1.26 linux/drivers/usb/dsbr100.c - 1.15 linux/drivers/net/wan/comx-hw-mixcom.c - 1.9 linux/drivers/net/wan/comx-hw-locomx.c - 1.7 linux/Documentation/DocBook/kernel-api.tmpl - 1.16 linux/net/ipv4/netfilter/ip_queue.c - 1.14 linux/net/ipv4/netfilter/ip_nat_standalone.c - 1.17 linux/net/ipv4/netfilter/ip_nat_rule.c - 1.7 linux/net/ipv4/netfilter/ip_nat_proto_unknown.c - 1.2 linux/net/ipv4/netfilter/ip_nat_proto_tcp.c - 1.4 linux/net/ipv4/netfilter/ip_nat_ftp.c - 1.9 linux/net/ipv4/netfilter/ip_nat_core.c - 1.11 linux/net/ipv4/netfilter/ip_fw_compat_redir.c - 1.6 linux/net/ipv4/netfilter/ip_fw_compat_masq.c - 1.8 linux/net/ipv4/netfilter/ip_conntrack_standalone.c - 1.14 linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c - 1.7 linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c - 1.8 linux/net/ipv4/netfilter/ip_conntrack_proto_icmp.c - 1.5 linux/net/ipv4/netfilter/ip_conntrack_proto_generic.c - 1.5 linux/net/ipv4/netfilter/ip_conntrack_ftp.c - 1.9 linux/net/ipv4/netfilter/ip_conntrack_core.c - 1.13 linux/net/ipv4/netfilter/Makefile - 1.13 linux/net/ipv4/netfilter/Config.in - 1.10 linux/include/linux/netfilter_ipv4/ip_nat_rule.h - 1.2 linux/include/linux/netfilter_ipv4/ip_nat_helper.h - 1.4 linux/include/linux/netfilter_ipv4/ip_conntrack_protocol.h - 1.4 linux/include/linux/netfilter_ipv4/ip_conntrack_helper.h - 1.3 linux/include/linux/netfilter_ipv4/ip_conntrack_ftp.h - 1.4 linux/include/linux/netfilter_ipv4/ip_conntrack_core.h - 1.5 linux/include/linux/netfilter_ipv4/ip_conntrack.h - 1.11 linux/drivers/isdn/avmb1/capifs.c - 1.17 linux/drivers/usb/mdc800.c - 1.19 linux/drivers/char/wdt_pci.c - 1.11 linux/arch/i386/kernel/pci-irq.c - 1.21 linux/include/linux/usbdevice_fs.h - 1.8 linux/drivers/video/sa1100fb.c - 1.12 linux/fs/nfs/nfs3proc.c - 1.10 linux/drivers/usb/serial/keyspan_pda.c - 1.24 linux/drivers/usb/serial/ftdi_sio.c - 1.34 linux/drivers/usb/serial/usbserial.c - 1.33 linux/drivers/usb/serial/whiteheat.c - 1.24 linux/drivers/usb/serial/visor.h - 1.10 linux/drivers/usb/serial/visor.c - 1.33 linux/drivers/ide/aec62xx.c - 1.7 linux/drivers/usb/serial/omninet.c - 1.23 linux/include/linux/if_pppox.h - 1.7 linux/drivers/usb/serial/digi_acceleport.c - 1.25 linux/drivers/net/pppoe.c - 1.20 linux/include/asm-s390/unistd.h - 1.9 linux/drivers/s390/block/dasd.c - 1.22 linux/include/asm-s390/pgtable.h - 1.12 linux/arch/s390/kernel/s390_ksyms.c - 1.7 linux/arch/i386/kernel/cpuid.c - 1.9 linux/fs/xfs/linux/xfs_super.c - 1.173 linux/fs/xfs/linux/xfs_iops.c - 1.133 linux/kdb/modules/kdbm_vm.c - 1.20 linux/kdb/modules/kdbm_pg.c - 1.55 linux/Documentation/DocBook/via-audio.tmpl - 1.6 linux/Documentation/filesystems/Locking - 1.10 linux/drivers/char/i810_rng.c - 1.8 linux/drivers/char/drm/i810_dma.c - 1.12 linux/drivers/usb/storage/transport.h - 1.8 linux/drivers/char/sbc60xxwdt.c - 1.13 linux/drivers/usb/storage/Makefile - 1.7 linux/arch/alpha/kernel/sys_titan.c - 1.5 linux/arch/alpha/kernel/sys_wildfire.c - 1.4 linux/drivers/usb/serial/keyspan.c - 1.25 linux/drivers/acpi/tables/tbxface.c - 1.9 linux/drivers/acpi/tables/tbutils.c - 1.9 linux/drivers/acpi/tables/tbinstal.c - 1.9 linux/drivers/acpi/tables/tbget.c - 1.9 linux/drivers/usb/microtek.h - 1.4 linux/drivers/usb/microtek.c - 1.18 linux/drivers/acpi/parser/psxface.c - 1.9 linux/drivers/acpi/parser/psutils.c - 1.9 linux/drivers/acpi/parser/psparse.c - 1.10 linux/drivers/acpi/parser/psopcode.c - 1.9 linux/drivers/acpi/namespace/nsxfname.c - 1.9 linux/drivers/acpi/namespace/nsutils.c - 1.9 linux/drivers/acpi/namespace/nssearch.c - 1.10 linux/drivers/acpi/namespace/nsobject.c - 1.9 linux/drivers/usb/bluetooth.c - 1.24 linux/fs/jffs/inode-v23.c - 1.23 linux/drivers/acpi/namespace/nseval.c - 1.10 linux/drivers/acpi/namespace/nsalloc.c - 1.9 linux/drivers/acpi/namespace/nsaccess.c - 1.10 linux/arch/arm/mm/proc-arm720.S - 1.12 linux/drivers/acpi/include/amlcode.h - 1.9 linux/drivers/acpi/include/actypes.h - 1.11 linux/drivers/acpi/include/actables.h - 1.9 linux/drivers/acpi/include/acpixf.h - 1.10 linux/drivers/acpi/include/acpiosxf.h - 1.9 linux/drivers/acpi/include/acobject.h - 1.9 linux/drivers/acpi/include/acexcep.h - 1.8 linux/drivers/acpi/hardware/hwregs.c - 1.10 linux/drivers/acpi/hardware/hwgpe.c - 1.9 linux/drivers/acpi/events/evxface.c - 1.9 linux/drivers/acpi/events/evmisc.c - 1.9 linux/drivers/acpi/events/evevent.c - 1.11 linux/drivers/acpi/dispatcher/dswload.c - 1.9 linux/drivers/acpi/dispatcher/dswexec.c - 1.9 linux/drivers/acpi/dispatcher/dsutils.c - 1.9 linux/drivers/acpi/dispatcher/dsopcode.c - 1.10 linux/drivers/acpi/dispatcher/dsobject.c - 1.10 linux/drivers/acpi/dispatcher/dsmthdat.c - 1.8 linux/drivers/acpi/dispatcher/dsmethod.c - 1.9 linux/arch/ia64/kernel/ia64_ksyms.c - 1.10 linux/drivers/acpi/Makefile - 1.12 linux/drivers/ieee1394/video1394.c - 1.19 linux/drivers/mtd/ftl.c - 1.14 linux/drivers/mtd/mtdblock.c - 1.14 linux/fs/nls/nls_big5.c - 1.4 linux/fs/nls/nls_cp932.c - 1.4 linux/fs/nls/nls_cp936.c - 1.3 linux/fs/nls/nls_cp949.c - 1.3 linux/fs/nls/nls_cp950.c - 1.3 linux/fs/nls/nls_euc-jp.c - 1.5 linux/fs/nls/nls_euc-kr.c - 1.4 linux/fs/nls/nls_gb2312.c - 1.4 linux/include/linux/mtd/compatmac.h - 1.2 linux/fs/nls/nls_sjis.c - 1.4 linux/fs/nls/nls_utf8.c - 1.3 linux/net/ipv4/tcp_minisocks.c - 1.13 linux/include/asm-arm/mach/pci.h - 1.7 linux/drivers/media/video/videodev.c - 1.13 linux/drivers/media/video/saa5249.c - 1.9 linux/drivers/media/video/pms.c - 1.8 linux/drivers/media/video/cpia.c - 1.14 linux/drivers/media/video/c-qcam.c - 1.10 linux/drivers/media/video/bw-qcam.c - 1.10 linux/drivers/media/video/bttv-driver.c - 1.20 linux/drivers/media/radio/radio-zoltrix.c - 1.8 linux/drivers/media/radio/radio-typhoon.c - 1.9 linux/drivers/media/radio/radio-trust.c - 1.9 linux/drivers/media/radio/radio-terratec.c - 1.9 linux/drivers/media/radio/radio-sf16fmi.c - 1.11 linux/drivers/media/radio/radio-rtrack2.c - 1.9 linux/drivers/media/radio/radio-gemtek.c - 1.9 linux/drivers/media/radio/radio-cadet.c - 1.8 linux/drivers/media/radio/radio-aztech.c - 1.9 linux/drivers/media/radio/radio-aimslab.c - 1.9 linux/drivers/char/i810-tco.c - 1.9 linux/arch/arm/tools/mach-types - 1.14 linux/arch/arm/mach-footbridge/arch.c - 1.5 linux/Documentation/SubmittingDrivers - 1.6 linux/arch/arm/mach-sa1100/leds.c - 1.7 linux/arch/arm/mm/proc-arm920.S - 1.9 linux/arch/arm/mm/proc-syms.c - 1.3 linux/arch/i386/kernel/bluesmoke.c - 1.17 linux/drivers/acpi/include/acconfig.h - 1.10 linux/drivers/acpi/include/acdebug.h - 1.9 linux/drivers/acpi/include/acdispat.h - 1.8 linux/drivers/acpi/include/acevents.h - 1.9 linux/drivers/acpi/include/acglobal.h - 1.8 linux/drivers/acpi/include/acinterp.h - 1.9 linux/drivers/acpi/include/aclocal.h - 1.10 linux/drivers/acpi/namespace/nsdump.c - 1.6 linux/drivers/block/cciss.c - 1.33 linux/drivers/md/lvm-snap.c - 1.15 linux/drivers/md/md.c - 1.42 linux/drivers/media/radio/radio-maestro.c - 1.7 linux/drivers/scsi/cpqfcTSinit.c - 1.15 linux/drivers/scsi/cpqfcTSstructs.h - 1.7 linux/fs/minix/itree_common.c - 1.8 linux/fs/minix/itree_v1.c - 1.5 linux/fs/minix/itree_v2.c - 1.5 linux/include/asm-ppc/highmem.h - 1.8 linux/drivers/usb/pegasus.h - 1.12 linux/drivers/usb/serial/belkin_sa.c - 1.18 linux/net/irda/irnet/irnet_irda.h - 1.4 linux/net/irda/irnet/irnet_irda.c - 1.10 linux/net/irda/irnet/irnet.h - 1.9 linux/include/linux/ethtool.h - 1.10 linux/include/asm-parisc/unistd.h - 1.3 linux/drivers/usb/serial/mct_u232.c - 1.18 linux/include/asm-parisc/pgalloc.h - 1.5 linux/drivers/usb/serial/empeg.c - 1.22 linux/drivers/usb/serial/Config.in - 1.13 linux/arch/i386/kernel/dmi_scan.c - 1.16 linux/arch/parisc/kernel/parisc_ksyms.c - 1.2 linux/drivers/acpi/tables/tbxfroot.c - 1.7 linux/drivers/acpi/namespace/nsinit.c - 1.9 linux/mm/shmem.c - 1.35 linux/fs/reiserfs/stree.c - 1.21 linux/fs/reiserfs/super.c - 1.22 linux/fs/reiserfs/tail_conversion.c - 1.14 linux/fs/reiserfs/prints.c - 1.13 linux/drivers/acpi/hardware/hwsleep.c - 1.7 linux/drivers/acpi/hardware/hwtimer.c - 1.7 linux/fs/reiserfs/namei.c - 1.22 linux/arch/sparc64/kernel/pci_schizo.c - 1.15 linux/fs/reiserfs/journal.c - 1.25 linux/fs/reiserfs/item_ops.c - 1.7 linux/fs/reiserfs/inode.c - 1.29 linux/fs/reiserfs/ibalance.c - 1.8 linux/fs/reiserfs/fix_node.c - 1.19 linux/fs/reiserfs/file.c - 1.10 linux/fs/reiserfs/do_balan.c - 1.10 linux/fs/reiserfs/dir.c - 1.12 linux/include/linux/reiserfs_fs.h - 1.21 linux/include/linux/reiserfs_fs_sb.h - 1.11 linux/fs/reiserfs/Makefile - 1.6 linux/include/asm-s390x/pgtable.h - 1.8 linux/arch/s390x/kernel/s390_ksyms.c - 1.5 linux/arch/cris/drivers/ethernet.c - 1.9 linux/arch/cris/drivers/ide.c - 1.10 linux/arch/cris/kernel/ksyms.c - 1.5 linux/drivers/s390/char/tapeblock.c - 1.8 linux/drivers/s390/block/xpram.c - 1.13 linux/include/asm-cris/unistd.h - 1.7 linux/include/asm-s390x/unistd.h - 1.6 linux/include/asm-arm/mach/irq.h - 1.4 linux/Documentation/i810_rng.txt - 1.3 linux/drivers/usb/serial/io_edgeport.c - 1.24 linux/drivers/scsi/aic7xxx_old.c - 1.17 linux/drivers/scsi/aic7xxx/aic7xxx_linux.c - 1.14 linux/drivers/net/wan/hd6457x.c - 1.3 linux/drivers/net/wan/dscc4.c - 1.8 linux/drivers/net/sungem.h - 1.7 linux/drivers/net/sungem.c - 1.16 linux/drivers/media/radio/radio-maxiradio.c - 1.6 linux/drivers/char/machzwd.c - 1.7 linux/drivers/char/advantechwdt.c - 1.6 linux/drivers/net/gt96100eth.h - 1.3 linux/drivers/net/gt96100eth.c - 1.4 linux/fs/nls/nls_cp1251.c - 1.4 linux/fs/nls/nls_cp1255.c - 1.5 linux/fs/nls/nls_iso8859-13.c - 1.4 linux/fs/nls/nls_koi8-u.c - 1.4 linux/fs/nls/nls_tis-620.c - 1.3 linux/include/asm-i386/rwsem.h - 1.3 linux/net/ipv4/netfilter/ip_nat_helper.c - 1.4 linux/arch/cris/drivers/gpio.c - 1.7 linux/arch/ia64/kernel/efivars.c - 1.6 linux/include/linux/compiler.h - 1.5 linux/fs/nls/nls_koi8-ru.c - 1.3 linux/drivers/media/video/w9966.c - 1.4 linux/drivers/net/irda/irda-usb.c - 1.15 linux/fs/char_dev.c - 1.4 linux/drivers/usb/pwc_timon.h - 1.2 linux/drivers/usb/pwc_nala.h - 1.2 linux/drivers/usb/pwc_kiara.h - 1.2 linux/drivers/usb/pwc.h - 1.10 linux/drivers/usb/pwc-uncompress.h - 1.3 linux/drivers/usb/pwc-uncompress.c - 1.3 linux/drivers/usb/pwc-misc.c - 1.4 linux/drivers/usb/pwc-ioctl.h - 1.5 linux/drivers/usb/pwc-if.c - 1.15 linux/drivers/usb/pwc-ctrl.c - 1.9 linux/drivers/mtd/nftlcore.c - 1.13 linux/drivers/mtd/nand/nand_ecc.c - 1.3 linux/drivers/mtd/mtdblock_ro.c - 1.7 linux/drivers/mtd/chips/sharp.c - 1.3 linux/drivers/media/radio/miropcm20-radio.c - 1.5 linux/drivers/acpi/executer/exstore.c - 1.5 linux/drivers/acpi/utilities/utglobal.c - 1.5 linux/drivers/acpi/utilities/uteval.c - 1.5 linux/drivers/acpi/utilities/utdelete.c - 1.5 linux/drivers/acpi/utilities/utdebug.c - 1.5 linux/drivers/acpi/utilities/utcopy.c - 1.5 linux/drivers/acpi/include/acstruct.h - 1.5 linux/drivers/usb/catc.c - 1.11 linux/drivers/acpi/include/platform/acenv.h - 1.5 linux/drivers/acpi/include/platform/acgcc.h - 1.7 linux/drivers/acpi/include/platform/aclinux.h - 1.4 linux/drivers/acpi/debugger/dbdisply.c - 1.5 linux/drivers/acpi/debugger/dbfileio.c - 1.5 linux/drivers/acpi/debugger/dbutils.c - 1.5 linux/drivers/acpi/executer/exstorob.c - 1.4 linux/drivers/acpi/executer/exstoren.c - 1.4 linux/drivers/acpi/executer/exconfig.c - 1.5 linux/drivers/acpi/executer/exconvrt.c - 1.5 linux/drivers/acpi/executer/exdump.c - 1.5 linux/drivers/acpi/executer/exfield.c - 1.4 linux/drivers/acpi/executer/exfldio.c - 1.5 linux/drivers/acpi/executer/exprep.c - 1.5 linux/drivers/acpi/executer/exregion.c - 1.5 linux/drivers/acpi/executer/exresnte.c - 1.6 linux/drivers/acpi/executer/exresolv.c - 1.5 linux/drivers/acpi/executer/exresop.c - 1.5 linux/drivers/usb/se401.c - 1.12 linux/drivers/usb/se401.h - 1.4 linux/Documentation/usb/se401.txt - 1.2 linux/drivers/usb/serial/cyberjack.c - 1.12 linux/drivers/usb/serial/pl2303.c - 1.13 linux/arch/mips/kernel/smp.c - 1.6 linux/arch/mips64/math-emu/cp1emu.c - 1.4 linux/Documentation/sonypi.txt - 1.6 linux/Documentation/video4linux/Zoran - 1.2 linux/Documentation/video4linux/w9966.txt - 1.2 linux/drivers/char/sonypi.h - 1.6 linux/drivers/media/video/meye.c - 1.9 linux/drivers/net/au1000_eth.c - 1.6 linux/drivers/net/au1000_eth.h - 1.2 linux/include/linux/sonypi.h - 1.4 linux/drivers/char/sonypi.c - 1.6 linux/drivers/net/dl2k.h - 1.7 linux/Documentation/networking/dl2k.txt - 1.6 linux/drivers/net/dl2k.c - 1.11 linux/drivers/ieee1394/sbp2.c - 1.7 linux/drivers/ieee1394/sbp2.h - 1.6 linux/drivers/ieee1394/nodemgr.c - 1.9 linux/drivers/ieee1394/nodemgr.h - 1.6 linux/drivers/video/aty/atyfb_base.c - 1.9 linux/drivers/media/radio/radio-gemtek-pci.c - 1.5 linux/drivers/s390/block/dasd_int.h - 1.5 linux/drivers/usb/CDCEther.c - 1.9 linux/drivers/usb/CDCEther.h - 1.4 linux/drivers/usb/kaweth.c - 1.14 linux/drivers/usb/kawethfw.h - 1.2 linux/drivers/video/sa1100fb.h - 1.3 linux/drivers/ide/serverworks.c - 1.8 linux/drivers/ide/it8172.c - 1.5 linux/drivers/ide/amd74xx.c - 1.8 linux/arch/arm/mach-sa1100/sa1111.h - 1.4 linux/arch/arm/mach-sa1100/sa1111.c - 1.5 linux/arch/arm/kernel/entry-header.S - 1.5 linux/arch/arm/mach-sa1100/leds.h - 1.5 linux/include/asm-arm/mach/serial_sa1100.h - 1.3 linux/arch/arm/mach-sa1100/generic.h - 1.3 linux/arch/arm/mach-sa1100/generic.c - 1.4 linux/drivers/usb/usbnet.c - 1.13 linux/arch/ppc/mm/mmu_decl.h - 1.5 linux/arch/ppc/mm/pgtable.c - 1.5 linux/arch/ppc/mm/tlb.c - 1.4 linux/drivers/usb/usbvideo.h - 1.9 linux/drivers/usb/usbvideo.c - 1.11 linux/drivers/ide/qd65xx.c - 1.6 linux/drivers/net/ns83820.c - 1.11 linux/drivers/usb/hid-core.c - 1.12 linux/drivers/usb/hid-input.c - 1.4 linux/drivers/usb/hiddev.c - 1.7 linux/Documentation/usb/hiddev.txt - 1.2 linux/include/linux/hiddev.h - 1.3 linux/fs/jffs2/file.c - 1.7 linux/fs/jffs2/super.c - 1.11 linux/scripts/mkspec - 1.2 linux/lib/rbtree.c - 1.2 linux/arch/i386/kernel/nmi.c - 1.5 linux/include/asm-generic/tlb.h - 1.3 linux/drivers/mtd/devices/blkmtd.c - 1.8 linux/drivers/usb/ultracam.c - 1.3 linux/drivers/usb/hpusbscsi.h - 1.5 linux/drivers/usb/hpusbscsi.c - 1.8 linux/drivers/net/wireless/orinoco_plx.c - 1.3 linux/drivers/usb/serial/ir-usb.c - 1.13 linux/fs/quota.c - 1.11 linux/drivers/i2c/i2c-proc.c - 1.2 linux/drivers/char/ib700wdt.c - 1.3 linux/arch/arm/mach-sa1100/h3600.c - 1.7 linux/arch/arm/lib/udivdi3.c - 1.2 linux/drivers/char/shwdt.c - 1.5 linux/drivers/char/eurotechwdt.c - 1.3 linux/drivers/net/irda/sa1100_ir.c - 1.3 linux/drivers/pcmcia/i82092.c - 1.4 linux/fs/isofs/compress.c - 1.7 linux/drivers/acpi/executer/exoparg2.c - 1.3 linux/drivers/acpi/executer/exoparg1.c - 1.3 linux/net/ipv4/netfilter/ip_nat_snmp_basic.c - 1.3 linux/net/ipv4/netfilter/ip_nat_irc.c - 1.3 linux/net/ipv4/netfilter/ip_conntrack_irc.c - 1.4 linux/include/linux/netfilter_ipv4/ip_conntrack_irc.h - 1.2 linux/fs/jbd/journal.c - 1.8 linux/arch/arm/mm/proc-arm1020.S - 1.5 linux/arch/arm/mm/proc-arm926.S - 1.5 linux/net/atm/pppoatm.c - 1.2 linux/fs/ext3/ialloc.c - 1.9 linux/fs/ext3/inode.c - 1.8 linux/fs/ext3/super.c - 1.13 linux/drivers/hotplug/Makefile - 1.3 linux/include/linux/seq_file.h - 1.3 linux/fs/intermezzo/super.c - 1.5 linux/fs/intermezzo/vfs.c - 1.7 linux/include/linux/ext3_fs_sb.h - 1.2 linux/fs/jbd/transaction.c - 1.6 linux/fs/reiserfs/procfs.c - 1.6 linux/drivers/hotplug/Config.in - 1.3 linux/fs/ext3/balloc.c - 1.4 linux/fs/intermezzo/dir.c - 1.4 linux/drivers/isdn/hisax/hisax_fcpcipnp.c - 1.5 linux/fs/bio.c - 1.12 linux/include/linux/device.h - 1.7 linux/drivers/isdn/hisax/hisax_isac.c - 1.3 linux/init/do_mounts.c - 1.10 linux/mm/mempool.c - 1.5 linux/drivers/usb/hcd/ehci-mem.c - 1.4 linux/drivers/usb/hcd.c - 1.11 linux/drivers/usb/hcd.h - 1.4 linux/drivers/usb/hcd/Config.in - 1.4 linux/drivers/usb/hcd/Makefile - 1.4 linux/drivers/usb/hcd/ehci-dbg.c - 1.2 linux/drivers/usb/hcd/ehci-hcd.c - 1.8 linux/drivers/usb/hcd/ehci-hub.c - 1.6 linux/drivers/usb/hcd/ehci-q.c - 1.8 linux/drivers/usb/hcd/ehci-sched.c - 1.7 linux/drivers/usb/hcd/ehci.h - 1.3 linux/drivers/usb/serial/ipaq.c - 1.6 linux/drivers/usb/serial/kl5kusb105.c - 1.6 linux/drivers/usb/stv680.h - 1.3 linux/drivers/usb/stv680.c - 1.8 linux/drivers/usb/vicam.c - 1.9 linux/drivers/usb/vicam.h - 1.4 linux/drivers/usb/vicamurbs.h - 1.2 linux/arch/arm/mm/proc-xscale.S - 1.5 linux/arch/arm/mm/proc-arm922.S - 1.4 linux/arch/arm/mach-arc/dma.c - 1.3 linux/arch/arm/mach-iop310/iq80310-time.c - 1.4 linux/drivers/usb/auerswald.c - 1.8 linux/arch/arm/kernel/debug.S - 1.3 linux/fs/xfs/pagebuf/page_buf_io.c - 1.24 linux/fs/xfs/pagebuf/page_buf.c - 1.17 linux/drivers/block/cciss_scsi.c - 1.4 linux/drivers/usb/Makefile.lib - 1.2 linux/drivers/ide/ide-taskfile.c - 1.8 linux/drivers/ide/pdcadma.c - 1.4 linux/drivers/ieee1394/dv1394-private.h - 1.2 linux/drivers/ieee1394/dv1394.c - 1.4 linux/fs/ext2/ext2.h - 1.5 linux/drivers/usb/hcd/ohci.h - 1.3 linux/drivers/usb/hcd/ohci-q.c - 1.5 linux/drivers/usb/hcd/ohci-mem.c - 1.3 linux/drivers/net/wireless/wavelan_cs.c - 1.4 linux/drivers/usb/hcd/ohci-hub.c - 1.3 linux/drivers/usb/hcd/ohci-hcd.c - 1.5 linux/drivers/usb/hcd/ohci-dbg.c - 1.3 linux/net/ipv6/netfilter/ip6_queue.c - 1.2 linux/net/ipv4/netfilter/ipt_ULOG.c - 1.2 linux/arch/arm/Config.help - 1.7 linux/arch/i386/Config.help - 1.7 linux/net/ipv4/netfilter/Config.help - 1.2 linux/fs/partitions/Config.help - 1.2 linux/arch/ppc/Config.help - 1.6 linux/fs/nls/Config.help - 1.2 linux/fs/Config.help - 1.8 linux/drivers/usb/serial/Config.help - 1.3 linux/drivers/usb/hcd/Config.help - 1.4 linux/drivers/usb/Config.help - 1.6 linux/drivers/ide/Config.help - 1.8 linux/drivers/ieee1394/Config.help - 1.2 linux/drivers/base/core.c - 1.7 linux/drivers/base/Makefile - 1.2 linux/drivers/pnp/pnpbios_core.c - 1.4 linux/drivers/pnp/pnpbios_proc.c - 1.2 linux/include/linux/pnpbios.h - 1.3 linux/include/asm-i386/thread_info.h - 1.3 linux/Documentation/filesystems/porting - 1.5 linux/arch/ppc/4xx_io/stb_kb.c - 1.2 linux/arch/ppc/iSeries/iSeries_irq.c - 1.2 linux/sound/oss/pss.c - 1.2 linux/sound/oss/pas2.h - 1.2 linux/sound/oss/opl3.h - 1.2 linux/sound/oss/mpu401.h - 1.2 linux/sound/oss/mad16.c - 1.2 linux/sound/oss/gus.h - 1.2 linux/arch/ppc/kernel/prom_init.c - 1.3 linux/arch/ppc/platforms/chrp_setup.c - 1.2 linux/arch/ppc/platforms/pmac_pic.c - 1.2 linux/arch/ppc/platforms/pmac_smp.c - 1.2 linux/sound/oss/cs4232.h - 1.2 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.3 linux/sound/oss/ad1848.h - 1.2 linux/sound/oss/ac97_codec.c - 1.2 linux/sound/core/rtctimer.c - 1.7 linux/drivers/usb/konicawc.c - 1.3 linux/include/asm-ppc/thread_info.h - 1.4 linux/include/asm-x86_64/unistd.h - 1.2 linux/include/asm-ppc64/time.h - 1.2 linux/include/asm-ppc64/floppy.h - 1.2 linux/arch/ppc64/mm/init.c - 1.2 linux/include/asm-ppc64/abs_addr.h - 1.2 linux/include/asm-ppc64/Paca.h - 1.2 linux/arch/ppc64/Makefile - 1.2 linux/arch/ppc64/config.in - 1.3 linux/arch/ppc64/defconfig - 1.2 linux/arch/ppc64/kernel/ItLpQueue.c - 1.2 linux/arch/ppc64/kernel/LparData.c - 1.2 linux/arch/ppc64/kernel/Makefile - 1.2 linux/arch/ppc64/kernel/align.c - 1.2 linux/arch/ppc64/kernel/chrp_setup.c - 1.2 linux/arch/ppc64/kernel/entry.S - 1.3 linux/arch/ppc64/kernel/head.S - 1.2 linux/arch/ppc64/kernel/htab.c - 1.2 linux/arch/ppc64/kernel/iSeries_irq.c - 1.2 linux/arch/ppc64/kernel/iSeries_pci.c - 1.2 linux/arch/ppc64/kernel/iSeries_setup.c - 1.2 linux/arch/ppc64/kernel/iSeries_setup.h - 1.2 linux/arch/ppc64/kernel/idle.c - 1.2 linux/arch/ppc64/kernel/ioctl32.c - 1.3 linux/arch/ppc64/kernel/lmb.c - 1.2 linux/arch/ppc64/kernel/misc.S - 1.2 linux/arch/ppc64/kernel/mk_defs.c - 1.2 linux/arch/ppc64/kernel/pSeries_lpar.c - 1.2 linux/arch/ppc64/kernel/pSeries_pci.c - 1.2 linux/arch/ppc64/kernel/pacaData.c - 1.2 linux/arch/ppc64/kernel/pci.c - 1.2 linux/arch/ppc64/kernel/pci.h - 1.2 linux/arch/ppc64/kernel/pci_dma.c - 1.2 linux/arch/ppc64/kernel/pmac_nvram.c - 1.2 linux/arch/ppc64/kernel/ppc_ksyms.c - 1.2 linux/arch/ppc64/kernel/process.c - 1.2 linux/arch/ppc64/kernel/prom.c - 1.2 linux/arch/ppc64/kernel/rtasd.c - 1.2 linux/arch/ppc64/kernel/semaphore.c - 1.2 linux/arch/ppc64/kernel/setup.c - 1.2 linux/arch/ppc64/kernel/signal.c - 1.2 linux/arch/ppc64/kernel/signal32.c - 1.2 linux/arch/ppc64/kernel/smp.c - 1.3 linux/arch/ppc64/kernel/stab.c - 1.2 linux/arch/ppc64/kernel/sys_ppc32.c - 1.3 linux/arch/ppc64/kernel/time.c - 1.2 linux/arch/ppc64/kernel/udbg.c - 1.2 linux/arch/ppc64/kernel/xics.c - 1.2 linux/arch/ppc64/lib/checksum.S - 1.2 linux/arch/ppc64/lib/string.S - 1.2 linux/arch/ppc64/vmlinux.lds - 1.2 linux/arch/ppc64/xmon/start.c - 1.2 linux/arch/ppc64/xmon/xmon.c - 1.2 linux/include/asm-ppc64/linux_logo.h - 1.2 linux/include/asm-ppc64/lmb.h - 1.2 linux/include/asm-ppc64/machdep.h - 1.2 linux/include/asm-ppc64/hw_irq.h - 1.2 linux/include/asm-ppc64/mman.h - 1.2 linux/include/asm-ppc64/mmu.h - 1.2 linux/include/asm-ppc64/mmu_context.h - 1.2 linux/include/asm-ppc64/iSeries/HvCallPci.h - 1.2 linux/include/asm-ppc64/unistd.h - 1.2 linux/include/asm-ppc64/thread_info.h - 1.2 linux/include/asm-ppc64/system.h - 1.2 linux/include/asm-ppc64/spinlock.h - 1.2 linux/include/asm-ppc64/siginfo.h - 1.2 linux/include/asm-ppc64/rtas.h - 1.2 linux/include/asm-ppc64/processor.h - 1.2 linux/include/asm-ppc64/ppcdebug.h - 1.2 linux/include/asm-ppc64/pgtable.h - 1.2 linux/include/asm-ppc64/pgalloc.h - 1.2 linux/include/asm-ppc64/page.h - 1.2 linux/include/asm-ppc64/nvram.h - 1.2 linux/drivers/net/e1000/e1000_phy.h - 1.2 linux/drivers/net/e1000/e1000_main.c - 1.5 linux/drivers/net/e1000/LICENSE - 1.2 linux/drivers/net/e1000/Makefile - 1.2 linux/drivers/net/e1000/e1000_osdep.h - 1.2 linux/drivers/net/e1000/e1000.h - 1.3 linux/drivers/net/e1000/e1000_ethtool.c - 1.2 linux/drivers/net/e1000/e1000_mac.c - 1.2 linux/drivers/net/e1000/e1000_mac.h - 1.2 linux/drivers/net/e1000/e1000_phy.c - 1.2 linux/drivers/net/e1000/e1000_param.c - 1.2 linux/drivers/net/e1000/e1000_proc.c - 1.2 linux/fs/jfs/jfs_metapage.h - 1.2 linux/fs/jfs/jfs_logmgr.h - 1.2 linux/fs/jfs/jfs_lock.h - 1.2 linux/fs/jfs/jfs_inode.h - 1.2 linux/drivers/hotplug/ibmphp_core.c - 1.2 linux/fs/jfs/endian24.h - 1.2 linux/fs/jfs/file.c - 1.2 linux/fs/jfs/inode.c - 1.2 linux/fs/jfs/jfs_btree.h - 1.2 linux/fs/jfs/jfs_debug.c - 1.2 linux/fs/jfs/jfs_debug.h - 1.2 linux/fs/jfs/jfs_defragfs.h - 1.2 linux/fs/jfs/jfs_dinode.h - 1.2 linux/fs/jfs/jfs_dmap.c - 1.2 linux/fs/jfs/jfs_dmap.h - 1.2 linux/fs/jfs/jfs_dtree.c - 1.3 linux/fs/jfs/jfs_dtree.h - 1.3 linux/fs/jfs/jfs_extendfs.h - 1.2 linux/fs/jfs/jfs_inode.c - 1.2 linux/fs/jfs/jfs_extent.c - 1.2 linux/fs/jfs/jfs_incore.h - 1.2 linux/fs/jfs/jfs_imap.h - 1.2 linux/fs/jfs/jfs_imap.c - 1.2 linux/fs/jfs/jfs_extent.h - 1.2 linux/fs/jfs/jfs_filsys.h - 1.2 linux/fs/jfs/namei.c - 1.2 linux/fs/jfs/jfs_xtree.h - 1.2 linux/fs/jfs/jfs_xtree.c - 1.2 linux/fs/jfs/jfs_logmgr.c - 1.2 linux/fs/jfs/super.c - 1.3 linux/fs/jfs/symlink.c - 1.2 linux/fs/jfs/jfs_uniupr.c - 1.2 linux/arch/arm/mm/tlb-v4wb.S - 1.2 linux/fs/jfs/jfs_mount.c - 1.2 linux/fs/jfs/jfs_superblock.h - 1.2 linux/fs/jfs/jfs_txnmgr.c - 1.2 linux/fs/jfs/jfs_txnmgr.h - 1.2 linux/fs/jfs/jfs_types.h - 1.2 linux/arch/arm/mach-sa1100/badge4.c - 1.2 linux/fs/jfs/jfs_umount.c - 1.2 linux/arch/arm/mm/proc-macros.S - 1.2 linux/arch/arm/mm/tlb-v4.S - 1.2 linux/arch/arm/mm/tlb-v3.S - 1.2 linux/fs/jfs/jfs_unicode.c - 1.2 linux/fs/jfs/jfs_unicode.h - 1.2 linux/fs/jfs/jfs_metapage.c - 1.2 linux/drivers/net/tg3.h - 1.3 linux/drivers/net/tg3.c - 1.3 linux/drivers/net/e100/Makefile - 1.2 linux/drivers/net/e100/e100.h - 1.3 linux/drivers/net/e100/e100_config.c - 1.3 linux/drivers/net/e100/e100_config.h - 1.3 linux/drivers/net/e100/e100_main.c - 1.3 linux/Documentation/sound/oss/AudioExcelDSP16 - 1.2 linux/mm/mincore.c - 1.2 linux/mm/msync.c - 1.2 linux/fs/nfsctl.c - 1.2 linux/Documentation/BK-usage/cset-to-linus - 1.2 linux/Documentation/BK-usage/csets-to-patches - 1.2 linux/include/asm-i386/acpi.h - 1.2 linux/Documentation/video4linux/bttv/README.freeze - 1.2 linux/drivers/acpi/acpi_ac.c - 1.2 linux/drivers/acpi/acpi_battery.c - 1.2 linux/drivers/acpi/acpi_bus.c - 1.3 linux/drivers/acpi/acpi_bus.h - 1.2 linux/drivers/acpi/acpi_button.c - 1.2 linux/arch/i386/kernel/acpi_wakeup.S - 1.2 linux/drivers/acpi/acpi_pci_root.c - 1.2 linux/drivers/acpi/acpi_drivers.h - 1.2 linux/drivers/acpi/acpi_ec.c - 1.2 linux/drivers/acpi/acpi_osl.c - 1.2 linux/drivers/media/video/bttv-vbi.c - 1.2 linux/drivers/acpi/acpi_processor.c - 1.2 linux/drivers/acpi/acpi_pci_link.c - 1.2 linux/drivers/acpi/acpi_system.c - 1.2 linux/drivers/net/wan/comx-hw-munich.c - 1.2 linux/drivers/acpi/acpi_tables.c - 1.2 linux/drivers/acpi/acpi_thermal.c - 1.2 linux/drivers/usb/emi26_fw.h - 1.2 linux/drivers/usb/emi26.c - 1.2 From owner-linux-xfs@oss.sgi.com Fri Apr 19 02:06:54 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J96s8d029441 for ; Fri, 19 Apr 2002 02:06:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J96s2B029440 for linux-xfs-outgoing; Fri, 19 Apr 2002 02:06:54 -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 g3J96k8d029410 for ; Fri, 19 Apr 2002 02:06:46 -0700 Received: from erbenson.alaska.net (211-pm16.nwc.alaska.net [209.112.141.211]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3J97pC33481; Fri, 19 Apr 2002 01:07:51 -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 5E7B0393A; Fri, 19 Apr 2002 01:07:49 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 0153110285; Fri, 19 Apr 2002 01:07:48 -0800 (AKDT) Date: Fri, 19 Apr 2002 01:07:48 -0800 From: Ethan Benson To: Stephen Lord Cc: linux-xfs@oss.sgi.com Subject: Re: mtime permission Message-ID: <20020419010748.K20630@plato.local.lan> Mail-Followup-To: Stephen Lord , linux-xfs@oss.sgi.com References: <20020405235829.G1524@plato.local.lan> <3CBFD6AB.4050901@sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYjDATHXTWnytHRU" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CBFD6AB.4050901@sgi.com>; from lord@sgi.com on Fri, Apr 19, 2002 at 03:34:51AM -0500 X-OS: Debian GNU Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --zYjDATHXTWnytHRU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 19, 2002 at 03:34:51AM -0500, Stephen Lord wrote: > I tried this without hitting the problem here: >=20 > burst{lord}: ls -l /tmp/xxx /xfs/xxx > -rw-rw-rw- 1 root root 0 Apr 19 02:59 /tmp/xxx (ext3) > -rw-rw-rw- 1 root root 0 Apr 19 02:57 /xfs/xxx (xfs) >=20 > burst{lord}: touch -r /etc/passwd /tmp/xxx > touch: setting times of `/tmp/xxx': Operation not permitted > burst{lord}: touch -r /etc/passwd /xfs/xxx > touch: setting times of `/xfs/xxx': Operation not permitted >=20 > Which kernel version were you using? 2.4.18 with the split patches. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --zYjDATHXTWnytHRU 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 iEYEARECAAYFAjy/3mQACgkQJKx7GixEevxuSgCfTtcTFK1DIl6DDVeqyfbIUmYD JQYAn2ffg4jW2I5KOJE3Aw1UaFN1gWLA =Ahsl -----END PGP SIGNATURE----- --zYjDATHXTWnytHRU-- From owner-linux-xfs@oss.sgi.com Fri Apr 19 02:11:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J9Bu8d029672 for ; Fri, 19 Apr 2002 02:11:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J9BuBR029671 for linux-xfs-outgoing; Fri, 19 Apr 2002 02:11: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3J9Bo8d029645 for ; Fri, 19 Apr 2002 02:11:50 -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 EAA39877; Fri, 19 Apr 2002 04:12:51 -0500 (CDT) Received: from sgi.com (n1XZPlcp3yTLnYkHIaRdTMRLzPqjWz+S@cf-vpn-sw-corp-64-24.corp.sgi.com [134.15.64.24]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id EAA75089; Fri, 19 Apr 2002 04:12:50 -0500 (CDT) Message-ID: <3CBFE025.9040105@sgi.com> Date: Fri, 19 Apr 2002 04:15:17 -0500 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: mtime permission References: <20020405235829.G1524@plato.local.lan> <3CBFD6AB.4050901@sgi.com> <20020419010748.K20630@plato.local.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson wrote: >On Fri, Apr 19, 2002 at 03:34:51AM -0500, Stephen Lord wrote: > >>I tried this without hitting the problem here: >> >>burst{lord}: ls -l /tmp/xxx /xfs/xxx >>-rw-rw-rw- 1 root root 0 Apr 19 02:59 /tmp/xxx (ext3) >>-rw-rw-rw- 1 root root 0 Apr 19 02:57 /xfs/xxx (xfs) >> >>burst{lord}: touch -r /etc/passwd /tmp/xxx >>touch: setting times of `/tmp/xxx': Operation not permitted >>burst{lord}: touch -r /etc/passwd /xfs/xxx >>touch: setting times of `/xfs/xxx': Operation not permitted >> >>Which kernel version were you using? >> > >2.4.18 with the split patches. > Hmm, can you try current cvs, it appears to be working there. Unfortunately the split patches are getting a little long in the tooth. Steve From owner-linux-xfs@oss.sgi.com Fri Apr 19 02:34:56 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3J9Yu8d030078 for ; Fri, 19 Apr 2002 02:34:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3J9YuUD030077 for linux-xfs-outgoing; Fri, 19 Apr 2002 02:34:56 -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 g3J9Yn8d030048 for ; Fri, 19 Apr 2002 02:34:49 -0700 Received: from erbenson.alaska.net (211-pm16.nwc.alaska.net [209.112.141.211]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3J9ZtQ79200 for ; Fri, 19 Apr 2002 01:35:55 -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 A0DEC393A for ; Fri, 19 Apr 2002 01:35:53 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 8D09110285; Fri, 19 Apr 2002 01:35:53 -0800 (AKDT) Date: Fri, 19 Apr 2002 01:35:53 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: mtime permission Message-ID: <20020419013553.L20630@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020405235829.G1524@plato.local.lan> <3CBFD6AB.4050901@sgi.com> <20020419010748.K20630@plato.local.lan> <3CBFE025.9040105@sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/ZYM6PqDyfNytx60" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CBFE025.9040105@sgi.com>; from lord@sgi.com on Fri, Apr 19, 2002 at 04:15:17AM -0500 X-OS: Debian GNU Mail-Copies-To: nobody X-No-CC: I subscribe to this list; do not CC me on replies. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --/ZYM6PqDyfNytx60 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 19, 2002 at 04:15:17AM -0500, Stephen Lord wrote: > >2.4.18 with the split patches. > > > Hmm, can you try current cvs, it appears to be working there. Unfortunate= ly > the split patches are getting a little long in the tooth. its really quite a lot of trouble to do that, i prefer not to replace kernels unless there is a pretty good reason, or its an actual upgrade. ill however keep this on my list of things to check when i upgrade to 2.4.19+split patches. (2.4.19 probably isn't too far off at this point). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --/ZYM6PqDyfNytx60 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 iEYEARECAAYFAjy/5PkACgkQJKx7GixEevxXxgCeJl2uZazYJDWv9AMQR5Z2oduP YEIAn3VoE5zDAAmlwooVoCjtiH3jTmis =bxGl -----END PGP SIGNATURE----- --/ZYM6PqDyfNytx60-- From owner-linux-xfs@oss.sgi.com Fri Apr 19 05:12:03 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JCC38d001609 for ; Fri, 19 Apr 2002 05:12:03 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JCC3gX001608 for linux-xfs-outgoing; Fri, 19 Apr 2002 05:12:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lips.thebarn.com (lips.borg.umn.edu [160.94.232.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JCBs8d001581 for ; Fri, 19 Apr 2002 05:11:55 -0700 Received: from scream.digitalelves.com (scream.digitalelves.com [209.98.159.31]) by lips.thebarn.com (8.12.3/8.12.0) with ESMTP id g3JC4MSV040547 for ; Fri, 19 Apr 2002 07:13:00 -0500 (CDT) Received: from tolkor.sgi.com (tolkor.sgi.com [192.48.180.13]) by scream.digitalelves.com (8.12.2/8.11.0) with ESMTP id g3J8X7pb027817 for ; Fri, 19 Apr 2002 03:33:07 -0500 (CDT) Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by tolkor.sgi.com (8.12.2/8.12.2/linux-outbound_gateway-1.2) with ESMTP id g3J8WQkw010916; Fri, 19 Apr 2002 03:32:27 -0500 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 DAA38574; Fri, 19 Apr 2002 03:32:26 -0500 (CDT) Received: from sgi.com (E37Gry2I1YpJX5mK8rMWQGxDt3Ni/lXe@cf-vpn-sw-corp-64-24.corp.sgi.com [134.15.64.24]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id DAA92131; Fri, 19 Apr 2002 03:32:24 -0500 (CDT) Message-ID: <3CBFD6AB.4050901@sgi.com> Date: Fri, 19 Apr 2002 03:34:51 -0500 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: Ethan Benson CC: linux-xfs@thebarn.com Subject: Re: mtime permission References: <20020405235829.G1524@plato.local.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ethan Benson wrote: >after more thought regarding xattrs, i looked at the sementecs >regarding users changing traditional attributes on world writable >files they don't own, in this case mtime and noticed a bug in XFS. > >on ext2 filesystems if i attempt to set the mtime of a file i don't >own (but do have write permission to) to anything but the current time >i get -EPERM, but on XFS im allowed to do whatever i want: > >eb@dogbert ~$ mount | grep -w / >/dev/hda3 on / type xfs (rw) >eb@dogbert ~$ mount | grep /mnt >/dev/hda4 on /mnt type ext2 (rw) > >eb@dogbert ~$ ls -l /dev/null /mnt/null >crw-rw-rw- 1 root root 1, 3 Jun 28 2001 /dev/null >crw-rw-rw- 1 root root 1, 3 Apr 5 23:47 /mnt/null > >eb@dogbert ~$ touch -r /etc/passwd /mnt/null >touch: setting times of `/mnt/null': Operation not permitted >eb@dogbert ~$ touch -r /etc/passwd /dev/null > >eb@dogbert ~$ ls -l /etc/passwd /dev/null >crw-rw-rw- 1 root root 1, 3 Feb 16 06:00 /dev/null >-rw-r--r-- 1 root root 1408 Feb 16 06:00 /etc/passwd >eb@dogbert ~$ ls -l /dev/null /mnt/null >crw-rw-rw- 1 root root 1, 3 Feb 16 06:00 /dev/null >crw-rw-rw- 1 root root 1, 3 Apr 5 23:47 /mnt/null >eb@dogbert ~$ > >the same is true for setting time in the future, also the same applies >to normal files as opposed to regular files. > I tried this without hitting the problem here: burst{lord}: ls -l /tmp/xxx /xfs/xxx -rw-rw-rw- 1 root root 0 Apr 19 02:59 /tmp/xxx (ext3) -rw-rw-rw- 1 root root 0 Apr 19 02:57 /xfs/xxx (xfs) burst{lord}: touch -r /etc/passwd /tmp/xxx touch: setting times of `/tmp/xxx': Operation not permitted burst{lord}: touch -r /etc/passwd /xfs/xxx touch: setting times of `/xfs/xxx': Operation not permitted Which kernel version were you using? Steve From owner-linux-xfs@oss.sgi.com Fri Apr 19 06:15:15 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JDFF8d002526 for ; Fri, 19 Apr 2002 06:15:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JDFFQE002525 for linux-xfs-outgoing; Fri, 19 Apr 2002 06:15:15 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail015.syd.optusnet.com.au (mail015.syd.optusnet.com.au [210.49.20.173]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JDFA8d002499 for ; Fri, 19 Apr 2002 06:15:11 -0700 Received: from localhost.localdomain (c17835.eburwd2.vic.optusnet.com.au [210.49.188.189]) by mail015.syd.optusnet.com.au (8.11.1/8.11.1) with ESMTP id g3JDGC019582 for ; Fri, 19 Apr 2002 23:16:12 +1000 Subject: XFS 1.1 on PowerPC From: Menaka Lashitha Bandara To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 19 Apr 2002 23:16:10 +1000 Message-Id: <1019222170.3390.8.camel@revolution> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Great Work guys! I've always been a quiet listner on this mailing list, but I must admit, real nice work with XFS 1.1. I've patched it against Benh's PowerPC kernel varient (2.4.18-benh), and it works like a charm... on my iBook, running Debian Sid with XFS from root up! \LaShI From owner-linux-xfs@oss.sgi.com Fri Apr 19 07:47:50 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JElo8d005176 for ; Fri, 19 Apr 2002 07:47:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JEloMt005175 for linux-xfs-outgoing; Fri, 19 Apr 2002 07:47:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from riv-vwsmtpout1.echostar.com (wks-253.echostar.com [204.76.128.253]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JElg8d005149 for ; Fri, 19 Apr 2002 07:47:43 -0700 Received: from 10.79.98.101 by riv-vwsmtpout1.echostar.com (InterScan E-Mail VirusWall NT); Fri, 19 Apr 2002 08:47:13 -0600 Message-ID: <3CC02DFB.ACEA0E6A@echostar.com> Date: Fri, 19 Apr 2002 08:47:23 -0600 From: Jim Buzbee X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.4.3 i686) X-Accept-Language: en MIME-Version: 1.0 To: Simon Matter CC: XFS List Subject: Re: IDE write cache and journaling file systems References: <3CBEE618.B220A393@echostar.com> <3CBFB9D3.831D2C98@ch.sauter-bc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Simon Matter wrote: ... > Jim, > > It's obvious that lifetime is reduced with write caching off. Just > listen to the drive and compare between w/cache on / off. What helps > here is that Linux uses memory for caching effectively. > > Some weeks ago I brought an issue to this list. I got zero filled files > after _clean_ reboots and I thought it was the write cache of the IDE > drives not flushing correctly. In fact I got bitten by the 'remount > readonly bug' and it had nothing to do with the write chache being > turned on. I think I missed some of the "remount readonly" discussion. Can someone summarize what the problem is and the correct way we should be doing a controlled shutdown/reboot with XFS? ... > > Cache flushing does only work if the drive honours the flushing request > correctly. What I recommend is trying to use drives which: > - really flush cache when requested to do so. > - flush cache on power failure. The drive we are currently using does its best. It has a "power failure" mode where the cache is flushed. I believe they re-order requests to get as much data on the platter as possible in this mode. We're trying to determine how how much time they have after the power is cut. Jim Buzbee, Echostar Technologies > > The latter is quite important because comsumers will just pull power to > turn it off. I don't know whether this feature is available with IDE > drives but I think it should be possible. > > -Simon > > > > > This has to be a common problem. Does anyone have any strategies or > > words of wisdom? > > > > Jim Buzbee, > > Echostar Technologies From owner-linux-xfs@oss.sgi.com Fri Apr 19 08:13:18 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JFDH8d005699 for ; Fri, 19 Apr 2002 08:13:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JFDHmU005698 for linux-xfs-outgoing; Fri, 19 Apr 2002 08:13: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 g3JFD68d005669 for ; Fri, 19 Apr 2002 08:13:07 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mx08)) with ESMTP id 5E7CF6165; Fri, 19 Apr 2002 17:14: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 RAA23573; Fri, 19 Apr 2002 17:14:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id C895D57306; Fri, 19 Apr 2002 17:13: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 C439925835; Fri, 19 Apr 2002 17:13:17 +0200 (CEST) Message-ID: <3CC0340D.FEB1EA53@ch.sauter-bc.com> Date: Fri, 19 Apr 2002 17:13:17 +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, en MIME-Version: 1.0 To: Jim Buzbee Cc: XFS List Subject: Re: IDE write cache and journaling file systems References: <3CBEE618.B220A393@echostar.com> <3CBFB9D3.831D2C98@ch.sauter-bc.com> <3CC02DFB.ACEA0E6A@echostar.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jim Buzbee schrieb: > > Simon Matter wrote: > > ... > > > Jim, > > > > It's obvious that lifetime is reduced with write caching off. Just > > listen to the drive and compare between w/cache on / off. What helps > > here is that Linux uses memory for caching effectively. > > > > Some weeks ago I brought an issue to this list. I got zero filled files > > after _clean_ reboots and I thought it was the write cache of the IDE > > drives not flushing correctly. In fact I got bitten by the 'remount > > readonly bug' and it had nothing to do with the write chache being > > turned on. > > I think I missed some of the "remount readonly" discussion. Can someone > summarize what the problem is and the correct way we should be doing a > controlled shutdown/reboot with XFS? The problem was that I changed some xinetd services via ntsysv (RH specific) and immediately rebooted. Something like this: ntsysv ; shutdown -r now Shutdown was okay and / got remounted ro. After reboot, all the files in /etc/xinetd.d that were touched by ntsysv before shutdown were now filled with zero. In the end it came out that it was a bug of this kernel which is fixed now. You may want to check this: http://oss.sgi.com/projects/xfs/mail_archive/200203/msg00634.html -Simon > > ... > > > > > Cache flushing does only work if the drive honours the flushing request > > correctly. What I recommend is trying to use drives which: > > - really flush cache when requested to do so. > > - flush cache on power failure. > > The drive we are currently using does its best. It has a "power > failure" mode where the cache is flushed. I believe they re-order > requests to get as much data on the platter as possible in this mode. > We're trying to determine how how much time they have after the power is > cut. > > Jim Buzbee, > Echostar Technologies > > > > > The latter is quite important because comsumers will just pull power to > > turn it off. I don't know whether this feature is available with IDE > > drives but I think it should be possible. > > > > -Simon > > > > > > > > This has to be a common problem. Does anyone have any strategies or > > > words of wisdom? > > > > > > Jim Buzbee, > > > Echostar Technologies From owner-linux-xfs@oss.sgi.com Fri Apr 19 08:15:29 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JFFT8d005843 for ; Fri, 19 Apr 2002 08:15:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JFFTrM005842 for linux-xfs-outgoing; Fri, 19 Apr 2002 08:15:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from wiley (66-2-81-26.customer.algx.net [66.2.81.26]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JFFO8d005777 for ; Fri, 19 Apr 2002 08:15:25 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by wiley (8.11.6/8.11.6) with ESMTP id g3JFGJW02150; Fri, 19 Apr 2002 11:16:20 -0400 Subject: Re: IDE write cache and journaling file systems From: Danny Cox To: Jim Buzbee Cc: XFS Mailing List In-Reply-To: <3CC02DFB.ACEA0E6A@echostar.com> References: <3CBEE618.B220A393@echostar.com> <3CBFB9D3.831D2C98@ch.sauter-bc.com> <3CC02DFB.ACEA0E6A@echostar.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 19 Apr 2002 11:16:19 -0400 Message-Id: <1019229380.1145.41.camel@wiley> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jim, On Fri, 2002-04-19 at 10:47, Jim Buzbee wrote: > The drive we are currently using does its best. It has a "power > failure" mode where the cache is flushed. I believe they re-order > requests to get as much data on the platter as possible in this mode. > We're trying to determine how how much time they have after the power is > cut. Sorry, I can't resist: how about a pair of really large electrolytics? ;-) Okay, I'll go back under my "lurker" rock, now. -- 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 Fri Apr 19 08:35:06 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JFZ68d006226 for ; Fri, 19 Apr 2002 08:35:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JFZ6nQ006225 for linux-xfs-outgoing; Fri, 19 Apr 2002 08:35:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from acid.compass.com.ph (IDENT:+nGGrbXFn//5hnjt8W8kC1NVWLBvqOew@acid.compass.com.ph [216.252.144.37]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JFYt8d006194 for ; Fri, 19 Apr 2002 08:34:58 -0700 Received: by acid.compass.com.ph (Postfix, from userid 500) id 18F1B1166C2C; Fri, 19 Apr 2002 23:35:55 +0800 (PHT) Received: from localhost (localhost [127.0.0.1]) by acid.compass.com.ph (Postfix) with ESMTP id 136AD324D634; Fri, 19 Apr 2002 23:35:55 +0800 (PHT) Date: Fri, 19 Apr 2002 23:35:55 +0800 (PHT) From: "Mark M. Barrios" To: Simon Matter Cc: Jim Buzbee , XFS List Subject: Re: IDE write cache and journaling file systems In-Reply-To: <3CBFB9D3.831D2C98@ch.sauter-bc.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 19 Apr 2002, Simon Matter wrote: > Jim, > > It's obvious that lifetime is reduced with write caching off. Just > listen to the drive and compare between w/cache on / off. What helps > here is that Linux uses memory for caching effectively. > > Some weeks ago I brought an issue to this list. I got zero filled files > after _clean_ reboots and I thought it was the write cache of the IDE > drives not flushing correctly. In fact I got bitten by the 'remount > readonly bug' and it had nothing to do with the write chache being > turned on. about a week after migrating my RH 7.2 desktop box to XFS, I started loosing setting in GNOME 1.4 and I also lost all of my bookmarks in mozilla 0.9.9, I did test XFS with a simulated powerfailure just to see if everything works and it went well. today I had a real powerfailure and after the box was back up again I lost all of the settings in GNOME, everything went back to its default settings, I cant say if the config files were corupted or had 0 sizes. is this because these applications are not compatible with XFS? or because of my hardware? or is this a needed feature/bug fix not yet in XFS code? is there a work around to this? please share or its back to ext3 for me. im running kernel linux-2.4.18-xfs-20020418 from CVS and the tools from that tree also. Thanks, Mark M. Barrios From owner-linux-xfs@oss.sgi.com Fri Apr 19 09:23:07 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JGN78d006988 for ; Fri, 19 Apr 2002 09:23:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JGN75e006987 for linux-xfs-outgoing; Fri, 19 Apr 2002 09:23:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf05bis.bellsouth.net (mail305.mail.bellsouth.net [205.152.58.165]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JGN18d006961 for ; Fri, 19 Apr 2002 09:23:02 -0700 Received: from taz ([65.81.169.140]) by imf05bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> for ; Fri, 19 Apr 2002 12:25:29 -0400 Date: Fri, 19 Apr 2002 12:22:00 -0400 From: Greg Freemyer Subject: OT: ISO images for Suse To: Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3JGN28d006962 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Guys, Since SuSE 8.0 is going to have XFS in it, I decided to go see if the ISO images could be downloaded. 8.0 is not released until next week, so there is nothing for it, so I went looking at 7.3 ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/suse/i386/7.3 I don't see any CD images. Does anyone know if they make them available for download or not. If so, where. PS: I have ordered a set from the online store, but they say it will be the end of the month before they ship, and I would like to start getting experience with SuSE 8.0 next week if I can. Greg Freemyer Internet Engineer Deployment and Integration Specialist The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Fri Apr 19 10:04:04 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JH448d007571 for ; Fri, 19 Apr 2002 10:04:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JH44vi007570 for linux-xfs-outgoing; Fri, 19 Apr 2002 10:04:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JH418d007537 for ; Fri, 19 Apr 2002 10:04:01 -0700 Received: from d-ri1-007.globalnet.hr (HELO default) (dgojtan@213.149.34.141 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Apr 2002 17:05:07 -0000 Message-ID: <3185813-22002451917549850@default> X-Priority: 3 Reply-To: X-MSMail-Priority: Normal From: "Dzon" To: "linux-xfs@oss.sgi.com" Subject: Dobar posao Date: Fri, 19 Apr 2002 19:05:49 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Postovani Ako zelite zaraditi posjetite http://www.workenjoy.50megs.com i vasom prijavom koja vas na nista neobvezuje zatrazite dodatne informacije. Odluka je samo vasa. Zahvaljujemo se na razumjevanju. Srdacan pozdrav Dzon gojtan Ovu poruku ste primili samo jednom i ukoliko vas ona nezanima ispricavamo se sto smo vam oduzeli malo vaseg dragocjenog vremena i nadalje necete primati informacije o istoj. [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Apr 19 11:03:15 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JI3F8d008339 for ; Fri, 19 Apr 2002 11:03:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JI3E4c008338 for linux-xfs-outgoing; Fri, 19 Apr 2002 11:03:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.merlinsoftech.com (www.merlinsoftech.com [66.38.133.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JI378d008309 for ; Fri, 19 Apr 2002 11:03:08 -0700 Received: from merlinsoftech.com (anmar.merlinsoftech.com [192.168.1.47]) by mail.merlinsoftech.com (8.11.6/8.11.6) with ESMTP id g3JI43q29300; Fri, 19 Apr 2002 11:04:08 -0700 Message-ID: <3CC05C1D.2080504@merlinsoftech.com> Date: Fri, 19 Apr 2002 11:04:13 -0700 From: Anmar Oueja Reply-To: anmar@merlinsoftech.com Organization: Merlin Technologies Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020412 Debian/0.9.9-6 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lars Weitze CC: samba@lists.samba.org, linux-xfs@oss.sgi.com Subject: Re: Can't get samba 2.2.3a to compile with ACL support (with logs) References: <20020418190627.6a4dc65c.cd@kalkatraz.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk We had the same problem. It seems that the new XFS has moved some functions from the lacl to lattr. Try and replace the lacl with lattr and that shoudl solve the issue hopefully. Thanks and good luck Anmar Lars Weitze wrote: > Hi, > > I've compiled everything: the whole acl package, the attr package the > xfs-progs etc. from the SGI CVS. I've installed all the devel packages. > > But Samba 2.2.3a configure tells me that it can't find ACL support. > > The line in the logs reads: > configure:12853: gcc -o conftest -O -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE conftest.c -lacl -lcups > /usr/lib/libacl.so: undefined reference to `fgetxattr' > /usr/lib/libacl.so: undefined reference to `removexattr' > /usr/lib/libacl.so: undefined reference to `setxattr' > /usr/lib/libacl.so: undefined reference to `fsetxattr' > /usr/lib/libacl.so: undefined reference to `getxattr' > > > Logfile is attached. > > Regards > Lars Weitze -- Anmar Oueja B.A.Sc. Engineering Manager Merlin Technologies Inc. T: (604) 320-7227 F: (604) 320-7277 www.merlinsoftech.com From owner-linux-xfs@oss.sgi.com Fri Apr 19 12:48:58 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JJmv8d012860 for ; Fri, 19 Apr 2002 12:48:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JJmv5H012859 for linux-xfs-outgoing; Fri, 19 Apr 2002 12:48: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JJmo8d012820 for ; Fri, 19 Apr 2002 12:48:51 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA49856 for ; Fri, 19 Apr 2002 14:49:54 -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 OAA93041 for ; Fri, 19 Apr 2002 14:49:53 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3JJnrL17213; Fri, 19 Apr 2002 14:49:53 -0500 Message-Id: <200204191949.g3JJnrL17213@stout.americas.sgi.com> Date: Fri, 19 Apr 2002 14:49:53 -0500 Subject: TAKE - Change default sgid bit inheritance behavior Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On other Linux filesystems, if you chmod g+s a directory, any directory created under that parent directory will also have the sgid bit set. XFS behaved differently, and only set the bit on subdirectories if the creating process was in the group ID of the parent directory. This changes the default behavior on Linux to be like that of other Linux filesystems; the previous "Irix" behavior can be set with a new "irixsgid" mount option. Date: Fri Apr 19 11:22:52 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:116903a linux/fs/xfs/xfs_vfsops.c - 1.341 - set mount struct flag for irixsgid linux/fs/xfs/xfs_clnt.h - 1.27 - add mount option flag for irixsgid linux/fs/xfs/xfs_mount.h - 1.139 - add mount struct flag for irixsgid linux/fs/xfs/xfs_inode.c - 1.335 - Do not clear the SGID bit on subdirs created by processes not in the parent dir's group, unless the irixsgid mount option is used linux/fs/xfs/linux/xfs_super.c - 1.165 - add irixsgid mount opton to mimic irix sgid bit inheritance linux/Documentation/filesystems/xfs.txt - 1.9 - Document irixsgid mount option From owner-linux-xfs@oss.sgi.com Fri Apr 19 13:10:27 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JKAR8d015593 for ; Fri, 19 Apr 2002 13:10:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JKARsD015592 for linux-xfs-outgoing; Fri, 19 Apr 2002 13: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JKAK8d015555 for ; Fri, 19 Apr 2002 13:10:20 -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 PAA49195; Fri, 19 Apr 2002 15:11:22 -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 PAA15443; Fri, 19 Apr 2002 15:11:20 -0500 (CDT) Subject: Fwd: Problem with 2.4.18 kernel + XFS From: Eric Sandeen To: linux-xfs@oss.sgi.com Cc: garski@poczta.onet.pl Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Apr 2002 15:11:20 -0500 Message-Id: <1019247082.16379.274.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (Marcin, the sig at the bottom of your email bounced off of the over-zealous email filters on oss.sgi.com....) It looks like something did not sync out data after your installed the newer RPMs. Were you running the 2.4.9-13 kernel at the time you upgraded the userspace RPMS? -Eric > Hi, > > I've patch 2.4.18 kernel by xfs-2.4.18-all-i386 (probably from Mar 3), > then compile patched > kernel and install it. > I read in the README-KERNELVERSION that xfs userspace tools >= 2.0.0 are > needed with kernels >= 2.4.18, so before restarting system I've upgraded > xfs rpm (rpm -Fvh) xfsprogs-2.0.0-0.i386.rpm and other. Reboot. > Lilo starts properly decompress kernel then init starts, after ASFAIR > "Setting hostname" (when system "Checking root filesystem") I get the > message like this: > > Your system appears to have shut down uncleanly > Press Y within 4 seconds to force file system integrity check...y > Checking root filesystem > fsck.xfs: Exec format error > > > *** An error occurred during the file system check. > *** Dropping you to a shell; the system will reboot > *** when you leave the shell. > Give root password for maintenance > (or type Control-D for normal startup): > > I didn't press any key, but strange thing is that system have shut down > cleanly but init didn't "think" so :). > I type root passwd and when editing fsck.xfs in MC (Midnight Commander) > I've only see many "..........." (dots) in this file, the other fsck ie. > fsck.ext2 is good ".ELF" in header and rest of file. After rpm -qa |grep > xfsprogs I did't get "xfsprogs-2.0.0-0" but "xfsprogs-1.3.13-0". > Of course system didn't start, after reboot I get the same message. > The same thing happen after reinstall OS and compiling kernel. > My system is RH 7.2 installed from ISO SGI-XFS Installer (1.0.2). > -- > Best Regards > Marcin Garski From owner-linux-xfs@oss.sgi.com Fri Apr 19 13:17:32 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JKHW8d015852 for ; Fri, 19 Apr 2002 13:17:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JKHWSh015851 for linux-xfs-outgoing; Fri, 19 Apr 2002 13:17:32 -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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JKHR8d015824 for ; Fri, 19 Apr 2002 13:17: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 PAA99015; Fri, 19 Apr 2002 15:18: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 PAA09643; Fri, 19 Apr 2002 15:18:30 -0500 (CDT) Subject: Re: IDE write cache and journaling file systems From: Eric Sandeen To: "Mark M. Barrios" Cc: Simon Matter , Jim Buzbee , XFS List In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Apr 2002 15:18:29 -0500 Message-Id: <1019247510.16444.283.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-19 at 10:35, Mark M. Barrios wrote: > today I had a real powerfailure and after the box was back up again I lost > all of the settings in GNOME, everything went back to its default > settings, I cant say if the config files were corupted or had 0 sizes. > > is this because these applications are not compatible with XFS? or > because of my hardware? or is this a needed feature/bug fix not yet in XFS > code? Well, it should not be a compatibility issue... gnome seems to be particularly susceptible to this, it seems that our sync behavior may not be quite right. On the other hand, with a metadata journaling filesystem, there is no guarantee against data loss when the system crashes or is switched off. We do need to be sure that we deal with it as gracefully as possible though, and I'll see if I can get a reproducible case going. -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Apr 19 14:23:06 2002 Received: from oss.sgi.com (localhost.localdomain [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3JLN68d020743 for ; Fri, 19 Apr 2002 14:23:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3JLN69t020742 for linux-xfs-outgoing; Fri, 19 Apr 2002 14:23: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3JLN08d020713 for ; Fri, 19 Apr 2002 14:23:01 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA49260; Fri, 19 Apr 2002 16:24: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 QAA20026; Fri, 19 Apr 2002 16:24:03 -0500 (CDT) Subject: Re: Problem with 2.4.18 kernel + XFS From: Eric Sandeen To: Marcin Garski Cc: linux-xfs@oss.sgi.com In-Reply-To: <010601c1e7ed$c01ee480$0200a8c0@g> References: <1019247082.16379.274.camel@stout.americas.sgi.com> <010601c1e7ed$c01ee480$0200a8c0@g> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 19 Apr 2002 16:24:03 -0500 Message-Id: <1019251443.16819.308.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-19 at 17:00, Marcin Garski wrote: > > It looks like something did not sync out data after your installed > > the newer RPMs. Were you running the 2.4.9-13 kernel at the time you > > upgraded the userspace RPMS? > > Yes I have running 2.4.9-13 kernel, first time I've do "#reboot", second > just push reset botom :) after upgraded RPMS. The result was the same > "Exec format error". Hm, the 2.4.9-13 kernel had a fix in it for a previous bug in remount, readonly that sometimes caused problems on shutdown, so I'm not sure what happened the first time. However, hitting reset is a very, very bad idea, especially right after you install a bunch of system software... -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Fri Apr 19 17:04: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 g3K04Dqf002046 for ; Fri, 19 Apr 2002 17:04:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3K04DOv002045 for linux-xfs-outgoing; Fri, 19 Apr 2002 17:04: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 g3K047qf002019 for ; Fri, 19 Apr 2002 17:04:08 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via SMTP id RAA87662 for ; Fri, 19 Apr 2002 17:04:14 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA09699; Sat, 20 Apr 2002 10:02:49 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA54513; Sat, 20 Apr 2002 10:02:48 +1000 (AEST) Date: Sat, 20 Apr 2002 10:02:48 +1000 From: Nathan Scott To: Anmar Oueja Cc: Lars Weitze , samba@lists.samba.org, linux-xfs@oss.sgi.com Subject: Re: Can't get samba 2.2.3a to compile with ACL support (with logs) Message-ID: <20020420100247.H22886@wobbly.melbourne.sgi.com> References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC05C1D.2080504@merlinsoftech.com>; from anmar@merlinsoftech.com on Fri, Apr 19, 2002 at 11:04:13AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hello, On Fri, Apr 19, 2002 at 11:04:13AM -0700, Anmar Oueja wrote: > > We had the same problem. It seems that the new XFS has moved some > functions from the lacl to lattr. XFS now uses the ACL userspace code maintained primarily by the good folk at acl.bestbits.at, so XFS has not moved any functions anywhere (the XFS-specific libacl implementation has in fact ceased to exist). These issues we're seeing here are fallout from the switch to the new "official" system call interfaces for extended attributes, and some library reorganisations that happened at that time. > Try and replace the lacl with lattr > and that shoudl solve the issue hopefully. You'll need to use both -lacl and -lattr. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Apr 19 17:56: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 g3K0upqf002680 for ; Fri, 19 Apr 2002 17:56:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3K0upAB002679 for linux-xfs-outgoing; Fri, 19 Apr 2002 17:56:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from cpw.math.columbia.edu (root@cpw.math.columbia.edu [128.59.209.25]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3K0ulqf002650 for ; Fri, 19 Apr 2002 17:56:47 -0700 Received: from cpw.math.columbia.edu (atici@localhost [127.0.0.1]) by cpw.math.columbia.edu (8.12.2/8.12.2) with ESMTP id g3K0v5da001841 for ; Fri, 19 Apr 2002 20:57:05 -0400 Received: from localhost (atici@localhost) by cpw.math.columbia.edu (8.12.2/8.12.2/Submit) with ESMTP id g3K0v5mW001838 for ; Fri, 19 Apr 2002 20:57:05 -0400 Date: Fri, 19 Apr 2002 20:57:05 -0400 (EDT) From: Alp ATICI To: linux-xfs@oss.sgi.com Subject: XFS in mainstream kernel Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I know this issue has been discussed before but I'd be glad to hear if there's anything new about XFS being incorporated into 2.5 or even in 2.4 series. Now that JFS has already made it into 2.5 and XFS has reached v1.1 I think it's about time. Thanks, Alp From owner-linux-xfs@oss.sgi.com Fri Apr 19 18:20: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 g3K1KYqf003200 for ; Fri, 19 Apr 2002 18:20:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3K1KYQ7003199 for linux-xfs-outgoing; Fri, 19 Apr 2002 18:20:34 -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 g3K1KUqf003173 for ; Fri, 19 Apr 2002 18:20:30 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 67BBD401A40; Fri, 19 Apr 2002 21:21:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 65D17C0EDEE; Fri, 19 Apr 2002 21:21:02 -0400 (EDT) Date: Fri, 19 Apr 2002 21:21:02 -0400 (EDT) From: Mike Burger To: Alp ATICI Cc: linux-xfs@oss.sgi.com Subject: Re: XFS in mainstream kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, if you'd be so kind as to tell Linus that, I'm sure it would go a little farther towards getting it there. Linus doesn't read this list, I think, and he's the one making the decisions. On Fri, 19 Apr 2002, Alp ATICI wrote: > Hi, > I know this issue has been discussed before but I'd be glad to hear > if there's anything new about XFS being incorporated into 2.5 > or even in 2.4 series. Now that JFS has already made it into > 2.5 and XFS has reached v1.1 I think it's about time. > Thanks, > Alp > From owner-linux-xfs@oss.sgi.com Fri Apr 19 19:37: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 g3K2buqf004091 for ; Fri, 19 Apr 2002 19:37:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3K2buVW004090 for linux-xfs-outgoing; Fri, 19 Apr 2002 19:37:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from newmail.emergence.com (newmail.emergence.com [209.5.172.115]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3K2bpqf004063 for ; Fri, 19 Apr 2002 19:37:51 -0700 Received: from h24-86-77-34.ed.shawcable.net ([24.86.77.34] helo=emergence.com) by newmail.emergence.com with esmtp (TLSv1:RC4-MD5:128) (Exim 3.34 #1) id 16ykjB-0001CE-00 for linux-xfs@oss.sgi.com; Fri, 19 Apr 2002 20:35:53 -0600 Message-ID: <3CC0D46E.2050800@emergence.com> Date: Fri, 19 Apr 2002 20:37:34 -0600 From: Michael Best User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9) Gecko/20020311 X-Accept-Language: en, pdf MIME-Version: 1.0 To: linux-xfs Subject: Re: XFS in mainstream kernel References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger wrote: > Well, if you'd be so kind as to tell Linus that, I'm sure it would go a > little farther towards getting it there. > > Linus doesn't read this list, I think, and he's the one making the > decisions. This post on this list mentions that Andrea Arcangeli is including XFS in his patch tree for testing purposes. http://marc.theaimsgroup.com/?l=linux-xfs&m=101857274727754&w=2 ie his latest kernel pre release: ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre6aa1/ Perhaps working with him and other kernel developers to get it included by Linus would be more productive. I'm sure the fact that is is being included by every major distro besides Redhat isn't being lost on anyone and that it is making acceptable progress. Getting Redhat to package it into Skipjack would be a real coup but it doesn't look promising. -Mike From owner-linux-xfs@oss.sgi.com Sat Apr 20 08:36: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 g3KFaUqf013348 for ; Sat, 20 Apr 2002 08:36:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3KFaTrT013347 for linux-xfs-outgoing; Sat, 20 Apr 2002 08:36:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fep04-mail.bloor.is.net.cable.rogers.com (fep04-mail.bloor.is.net.cable.rogers.com [66.185.86.74]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3KFaPqf013320 for ; Sat, 20 Apr 2002 08:36:26 -0700 Received: from cr598116-a ([24.112.74.120]) by fep04-mail.bloor.is.net.cable.rogers.com (InterMail vM.5.01.04.13 201-253-122-122-113-20020313) with ESMTP id <20020420153643.SCZE4552.fep04-mail.bloor.is.net.cable.rogers.com@cr598116-a> for ; Sat, 20 Apr 2002 11:36:43 -0400 From: Gerald Henriksen To: linux-xfs@oss.sgi.com Subject: Re: XFS in mainstream kernel Date: Sat, 20 Apr 2002 11:36:52 -0400 Message-ID: References: <3CC0D46E.2050800@emergence.com> In-Reply-To: <3CC0D46E.2050800@emergence.com> X-Mailer: Forte Agent 1.91/32.564 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Authentication-Info: Submitted using SMTP AUTH LOGIN at fep04-mail.bloor.is.net.cable.rogers.com from [24.112.74.120] using ID at Sat, 20 Apr 2002 11:36:43 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3KFaQqf013322 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 19 Apr 2002 20:37:34 -0600, you wrote: >Getting Redhat to package it into Skipjack would be a real coup but it >doesn't look promising. Red Hat won't introduce new features in the middle of a beta release (Skipjack is the beta for their next release). If people want XFS to be included in Red Hat then they should wait until after the next official release and then start working on Red Hat to add XFS to rawhide followed by the beta for the following release (which based on past behaviour should be in the Oct-Dec timeframe). From owner-linux-xfs@oss.sgi.com Sat Apr 20 09:10: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 g3KGASqf013941 for ; Sat, 20 Apr 2002 09:10:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3KGAS1R013940 for linux-xfs-outgoing; Sat, 20 Apr 2002 09:10:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from out-gate.propack-data.de (out-gate.propack-data.de [194.120.230.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3KGAKqf013913 for ; Sat, 20 Apr 2002 09:10:21 -0700 Received: from pegasus.propack-data.de (pddeka-s0008.ka.propack-data.de [10.2.1.23]) by out-gate.propack-data.de (Postfix) with ESMTP id 310271D807 for ; Sat, 20 Apr 2002 18:10:37 +0200 (CEST) Subject: Re: OT: ISO images for Suse To: X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Michael Wahlbrink" Date: Sat, 20 Apr 2002 18:10:36 +0200 X-MIMETrack: Serialize by Router on Pegasus/KA/Propack Data GmbH(Release 5.0.8 |June 18, 2001) at 20.04.2002 18:10:37 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 g3KGALqf013914 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 19.04.2002 18:22:00 Greg Freemyer wrote: >Guys, > >Since SuSE 8.0 is going to have XFS in it, I decided to go see if the >ISO images could be downloaded. > >8.0 is not released until next week, so there is nothing for it, so I >went looking at 7.3 > >ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/suse/i386/7.3 > >I don't see any CD images. > >Does anyone know if they make them available for download or not. > >If so, where. AFAIK SuSE does not release any ISO images for free download on their FTP : -( You have to buy it.......... But I don't like the new SuSE..... > >PS: I have ordered a set from the online store, but they say it will be >the end of the month before they ship, and I would like to start >getting experience with SuSE 8.0 next week if I can. > >Greg Freemyer >Internet Engineer >Deployment and Integration Specialist >The Norcross Group >www.NorcrossGroup.com Micha -- Michael Wahlbrink IT Services Propack Data GmbH Karlsruhe miw@propack-data.com +49 721/9650-851 From owner-linux-xfs@oss.sgi.com Sat Apr 20 10:22: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 g3KHMTqf014860 for ; Sat, 20 Apr 2002 10:22:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3KHMT0v014859 for linux-xfs-outgoing; Sat, 20 Apr 2002 10:22: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3KHMNqf014832 for ; Sat, 20 Apr 2002 10:22:23 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id MAA62659; Sat, 20 Apr 2002 12:21: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 MAA88162; Sat, 20 Apr 2002 12:21:23 -0500 (CDT) Date: Sat, 20 Apr 2002 12:21:23 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Alvaro Figueroa cc: XFS to linux port mailing list Subject: Re: opps on xfs on a linear raid on a sparc64 box In-Reply-To: <1016587272.19159.2.camel@lucy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Alvaro - Sorry for the slow reply on this one! There was a bug in _pagebuf_page_io that would cause memory corruption with RAID if you had a page size > 4k; almost certainly what this oops is, and it should be fixed now in both CVS and the XFS 1.1 kernels. -Eric On 19 Mar 2002, Alvaro Figueroa wrote: > > Today, I'd tried to use xfs on a linear raid, and it oops'ses. > > I've just tried it with a raid5, and the same thing happen. > > (BTW, I did forgot to mention (sorry) that the same raid formated with > ext2, even with the same kernel, works perfectly) > > Here is the oops for the raid5 test. > >>I7; 004fcc50 <_pagebuf_page_io+230/2e0> > Trace; 004fcc50 <_pagebuf_page_io+230/2e0> From owner-linux-xfs@oss.sgi.com Sat Apr 20 15:18: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 g3KMIAqf020739 for ; Sat, 20 Apr 2002 15:18:10 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3KMIAv8020738 for linux-xfs-outgoing; Sat, 20 Apr 2002 15:18:10 -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-d514e105.dsl.mediaWays.net [213.20.225.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3KMI6qf020711 for ; Sat, 20 Apr 2002 15:18:07 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16z3BY-0002JA-00; Sun, 21 Apr 2002 00:18:24 +0200 Message-ID: <3CC1E930.3887B3AB@berdmann.de> Date: Sun, 21 Apr 2002 00:18:24 +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: Greg Freemyer CC: linux-xfs@oss.sgi.com Subject: Re: OT: ISO images for Suse References: <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Since SuSE 8.0 is going to have XFS in it, I decided to go see if the ISO images could be downloaded. SuSE is a commercial distro. They don't offer ISO images for free download. From owner-linux-xfs@oss.sgi.com Sat Apr 20 15:29: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 g3KMTkqf021084 for ; Sat, 20 Apr 2002 15:29:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3KMTkBu021083 for linux-xfs-outgoing; Sat, 20 Apr 2002 15:29:46 -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-d514e105.dsl.mediaWays.net [213.20.225.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3KMTdqf021053 for ; Sat, 20 Apr 2002 15:29:40 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 16z3Mj-0002PX-00; Sun, 21 Apr 2002 00:29:57 +0200 Message-ID: <3CC1EBBA.D7122F0C@berdmann.de> Date: Sun, 21 Apr 2002 00:29:14 +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: Rupa Schomaker CC: linux-xfs@oss.sgi.com Subject: Re: Fragmentation (was: XFS NFS server Oops) References: <1016578034.28166.25.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I've got a filesystem with 28 .iso images, the frags -f command shows: > > # xfs_db -r /dev/shaktivg/xxx > xfs_db: frag -f > actual 355, ideal 29, fragmentation factor 91.83% # for dev in `df|grep /dev/vg2|awk '{print $1};'`; do > echo -n $dev ": " > /usr/sbin/xfs_db -c "frag -f" -r $dev > done /dev/vg2/home : actual 56720, ideal 55427, fragmentation factor 2.28% /dev/vg2/tmp : actual 5016, ideal 5004, fragmentation factor 0.24% /dev/vg2/usr : actual 111119, ideal 111110, fragmentation factor 0.01% /dev/vg2/var : actual 10353, ideal 8147, fragmentation factor 21.31% /dev/vg2/exim : actual 11, ideal 11, fragmentation factor 0.00% /dev/vg2/news : actual 416937, ideal 400006, fragmentation factor 4.06% /dev/vg2/squid : actual 99132, ideal 99088, fragmentation factor 0.04% /dev/vg2/opt : actual 48, ideal 48, fragmentation factor 0.00% /dev/vg2/tftp : actual 25916, ideal 25855, fragmentation factor 0.24% /dev/vg2/dumps : actual 17, ideal 5, fragmentation factor 70.59% /dev/vg2/stor : actual 17952, ideal 17949, fragmentation factor 0.02% /dev/vg2/heise : actual 151162, ideal 151162, fragmentation factor 0.00% /dev/vg2/mp3 : actual 1162, ideal 1162, fragmentation factor 0.00% /dev/vg2/rawhide : actual 2672, ideal 2244, fragmentation factor 16.02% /dev/vg2/redhat : actual 1862, ideal 1700, fragmentation factor 8.70% /dev/vg2/rhlcd : actual 47260, ideal 47259, fragmentation factor 0.00% /dev/vg2/scratch : actual 1369, ideal 1305, fragmentation factor 4.67% /dev/vg2/sw : actual 2668, ideal 2554, fragmentation factor 4.27% /dev/vg2/hp710 : actual 5041, ideal 5041, fragmentation factor 0.00% /dev/vg2/hp710loc : actual 17390, ideal 17361, fragmentation factor 0.17% /dev/vg2/imap : actual 296624, ideal 295712, fragmentation factor 0.31% From owner-linux-xfs@oss.sgi.com Sat Apr 20 18:34: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 g3L1YMqf024527 for ; Sat, 20 Apr 2002 18:34:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3L1YMpw024526 for linux-xfs-outgoing; Sat, 20 Apr 2002 18:34: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3L1YFqf024497 for ; Sat, 20 Apr 2002 18:34: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 UAA66936; Sat, 20 Apr 2002 20:34: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 UAA83363; Sat, 20 Apr 2002 20:34:34 -0500 (CDT) Date: Sat, 20 Apr 2002 20:34:34 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Marcin Garski cc: linux-xfs@oss.sgi.com Subject: Re: Problem with 2.4.18 kernel + XFS In-Reply-To: <014f01c1e8a6$0e7b6eb0$0200a8c0@g> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Marcin - On Sat, 20 Apr 2002, Marcin Garski wrote: > when I shutdown system so the only way to didn't do that was just hit > reset. Yesterday I've upgraded linux box to release 1.1 (userspace progs > and kenrel, all from rpms) and everything runs fine, but the problem is > that i don't want to alway use rpm kernel, but just compile it by > myself. compiling it by yourself should be fine; read the FAQ on recommended compilers. > BTW. > 1. What patch do You suggest for 2.4.18 kernel, the one from relase 1.1 > (xfs-1.1-2.4.18-all.patch.bz2) or xfs-2.4.18-all-i386.bz2 ? Release 1.1, absolutely. > 2. Maybe havening 2.4.9-13 kernel I'll upgrade xfsprogs, reboot and > compile 2.4.18 kernel? (I don't known what happen if the old kernel will > be having new xfsprogs?)? The 2.4.9-13 kernel is pretty old now, I wouldn't bother with any testing on it at this point. > 3. ASFAIR After I've done RH 7.2 instalation from ISO 1.0.2 Installer, > while doing reboot (first time only, next everything was fine) I've saw > that mount have problem unmounting one of the file system. The umount > problem replay after reinstall, but once more only at first reboot. Not sure what to tell you on this one, I assume it said that the filesystem was busy? -Eric -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sat Apr 20 19:23: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 g3L2Nvqf025501 for ; Sat, 20 Apr 2002 19:23:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3L2NvM0025500 for linux-xfs-outgoing; Sat, 20 Apr 2002 19:23: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3L2Nmqf025468 for ; Sat, 20 Apr 2002 19:23:48 -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 VAA66077; Sat, 20 Apr 2002 21:24:07 -0500 (CDT) Received: from sgi.com (lNx2vpigWMwvO4n1hVrIfDsmsvFbOVBz@cf-vpn-sw-corp-64-20.corp.sgi.com [134.15.64.20]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id VAA19534; Sat, 20 Apr 2002 21:24:06 -0500 (CDT) Message-ID: <3CC2235A.5070104@sgi.com> Date: Sat, 20 Apr 2002 21:26:34 -0500 From: Stephen Lord User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: "Bernhard R. Erdmann" CC: Rupa Schomaker , linux-xfs@oss.sgi.com Subject: Re: Fragmentation (was: XFS NFS server Oops) References: <1016578034.28166.25.camel@jen.americas.sgi.com> <3CC1EBBA.D7122F0C@berdmann.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Bernhard R. Erdmann wrote: >>I've got a filesystem with 28 .iso images, the frags -f command shows: >> >># xfs_db -r /dev/shaktivg/xxx >>xfs_db: frag -f >>actual 355, ideal 29, fragmentation factor 91.83% >> Try running xfs_bmap on those iso images, just give it file names as its parameter. It will report how large the individual chunks of the files are. Assuming say 200Mb in each image, 355 fragments is about 16 Mbytes in each extent. It all depends on how they were written (one after the other or in parallel), and how full the filesystem is, and what state it was in before you wrote them. If you write a few hundred Mbytes into a filesystem which only has small scattered chunks of free space you are going to get a fragmented file, there is no way out of that. Steve >> > ># for dev in `df|grep /dev/vg2|awk '{print $1};'`; do > >>echo -n $dev ": " >>/usr/sbin/xfs_db -c "frag -f" -r $dev >>done >> >/dev/vg2/home : actual 56720, ideal 55427, fragmentation factor 2.28% >/dev/vg2/tmp : actual 5016, ideal 5004, fragmentation factor 0.24% >/dev/vg2/usr : actual 111119, ideal 111110, fragmentation factor 0.01% >/dev/vg2/var : actual 10353, ideal 8147, fragmentation factor 21.31% >/dev/vg2/exim : actual 11, ideal 11, fragmentation factor 0.00% >/dev/vg2/news : actual 416937, ideal 400006, fragmentation factor 4.06% >/dev/vg2/squid : actual 99132, ideal 99088, fragmentation factor 0.04% >/dev/vg2/opt : actual 48, ideal 48, fragmentation factor 0.00% >/dev/vg2/tftp : actual 25916, ideal 25855, fragmentation factor 0.24% >/dev/vg2/dumps : actual 17, ideal 5, fragmentation factor 70.59% >/dev/vg2/stor : actual 17952, ideal 17949, fragmentation factor 0.02% >/dev/vg2/heise : actual 151162, ideal 151162, fragmentation factor 0.00% >/dev/vg2/mp3 : actual 1162, ideal 1162, fragmentation factor 0.00% >/dev/vg2/rawhide : actual 2672, ideal 2244, fragmentation factor 16.02% >/dev/vg2/redhat : actual 1862, ideal 1700, fragmentation factor 8.70% >/dev/vg2/rhlcd : actual 47260, ideal 47259, fragmentation factor 0.00% >/dev/vg2/scratch : actual 1369, ideal 1305, fragmentation factor 4.67% >/dev/vg2/sw : actual 2668, ideal 2554, fragmentation factor 4.27% >/dev/vg2/hp710 : actual 5041, ideal 5041, fragmentation factor 0.00% >/dev/vg2/hp710loc : actual 17390, ideal 17361, fragmentation factor >0.17% >/dev/vg2/imap : actual 296624, ideal 295712, fragmentation factor 0.31% > From owner-linux-xfs@oss.sgi.com Sun Apr 21 00: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 g3L7R7qf031000 for ; Sun, 21 Apr 2002 00:27:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3L7R7fI030999 for linux-xfs-outgoing; Sun, 21 Apr 2002 00:27:07 -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 g3L7R0qf030969 for ; Sun, 21 Apr 2002 00:27:01 -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 g3L7Mv3u013111 for ; Sun, 21 Apr 2002 03:22:57 -0400 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id g3L7RPt18027 for linux-xfs@oss.sgi.com; Sun, 21 Apr 2002 03:27:25 -0400 (EDT) Date: Sun, 21 Apr 2002 03:27:24 -0400 From: Thor Lancelot Simon To: linux-xfs@oss.sgi.com Subject: 2.4.18 + XFS 1.1 on multiprocessor: bizzare hard hang on Samba writes. Message-ID: <20020421032724.A18019@pla-muek.reefedge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I have a rather interesting old box, a 6 x PPro ALR beast with two primary PCI buses and a truly immense number of disk bays. At the moment it's got Linux 2.4.18 with XFS 1.1 on it; the disks are four IDE disks in a software RAID and five IBM SCSI disks on an Adaptec 3210S I2O RAID controller. The only other thing of note in the machine is a Netgear GA-620 (Tigon-II) ethernet adapter. I have, unfortunately, discovered that though I can't provoke the problem any other way, if I copy many large files onto the box using Samba, I get an almost instant hard hang. No network I/O, no keyboard input; I can't even drop to the debugger. I figured the problem was with the software RAID (even though I'm using an external log on a partition of the Adaptec's "disk") but copying onto the Adaptec RAID volume, as it turns out, has the same issue. So, I assume the likely culprit is a locking botch somewhere in the acenic or dpti drivers or in XFS. I assume everyone in the world would know if acenic or dpti were broken (they have many more users that XFS, I've got to guess) so I tend to blame XFS... I note that Linux spinlocks seem to use cli/sti to disable all interrupts so a locking botch does seem like a likely cause of a total, irrecoverable hang. That leaves me with little or no idea how to debug this, but I'd be glad to give it a shot if someone could make suggestions. I work at a router vendor that ships a Linux-based product so I can handle the kernel debugger fairly well; I just don't know where to start with this kind of problem, since we ship only uniprocessor machines and locking issues aren't exactly common. :-) I'd be perfectly willing to arrange login or serial console access to the box for anyone from SGI who cared to look at this; or just let me know what you want me to look at and I'll be glad to report back. Thor From owner-linux-xfs@oss.sgi.com Sun Apr 21 02:05: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 g3L95Wqf032741 for ; Sun, 21 Apr 2002 02:05:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3L95WYw032740 for linux-xfs-outgoing; Sun, 21 Apr 2002 02:05:32 -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 g3L95Rqf032701 for ; Sun, 21 Apr 2002 02:05:28 -0700 Received: by ids.org.au (Postfix, from userid 1001) id D76EE27EBF; Sun, 21 Apr 2002 19:09:15 +1000 (EST) Date: Sun, 21 Apr 2002 19:09:15 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: re: quota patch Message-ID: <20020421090915.GA2108@ids.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm currently running kernel 2.4.18 + xfs patch set obtained from the "latest" folder in the development pages on oss.sgi.com With regards to the quota fix submitted to CVS, should I update from CVS, download 1.1, or just try to patch the quota.c file? I'm running a "production" server, so the userland quota functionality would be desirable - which way is the best to get the quota stuff (and ACLs) in a functionable state? (cvs or 1.1) rgds, 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 Apr 21 04:31: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 g3LBV6qf008702 for ; Sun, 21 Apr 2002 04:31:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3LBV6M4008701 for linux-xfs-outgoing; Sun, 21 Apr 2002 04:31:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zamok.crans.org (zamok.crans.org [138.231.136.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3LBV2qf008675 for ; Sun, 21 Apr 2002 04:31:02 -0700 Received: from lucas.loria (localhost.crans.org [127.0.0.1]) by zamok.crans.org (Postfix) with ESMTP id BBEC9214 for ; Sun, 21 Apr 2002 13:31:27 +0200 (CEST) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id 2F2CBA53B for ; Sun, 21 Apr 2002 13:31:26 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id A9284104D2A; Sun, 21 Apr 2002 13:31:25 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: XFS and postfix X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat Organization: Kabale Inc Date: Sun, 21 Apr 2002 13:31:25 +0200 Message-ID: Lines: 11 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I encounter the problem described in this thread with XFS and kernel 2.4.16 : Is this problem fixed ? -- BOFH excuse #28: CPU radiator broken From owner-linux-xfs@oss.sgi.com Sun Apr 21 05:42: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 g3LCgwqf009965 for ; Sun, 21 Apr 2002 05:42:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3LCgwu1009964 for linux-xfs-outgoing; Sun, 21 Apr 2002 05:42:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zamok.crans.org (zamok.crans.org [138.231.136.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3LCgpqf009938 for ; Sun, 21 Apr 2002 05:42:52 -0700 Received: from lucas.loria (localhost.crans.org [127.0.0.1]) by zamok.crans.org (Postfix) with ESMTP id CBA0B2E5; Sun, 21 Apr 2002 14:43:17 +0200 (CEST) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id 51AB3A53B; Sun, 21 Apr 2002 14:43:12 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id 1F71B104D2A; Sun, 21 Apr 2002 14:43:10 +0200 (CEST) To: linux-xfs@oss.sgi.com Subject: Re: XFS and postfix References: X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat In-Reply-To: (Vincent Bernat's message of "Sun, 21 Apr 2002 13:31:25 +0200") Organization: Kabale Inc Date: Sun, 21 Apr 2002 14:43:10 +0200 Message-ID: Lines: 35 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OoO Peu avant le début de l'après-midi du dimanche 21 avril 2002, vers 13:31, Vincent Bernat disait: > I encounter the problem described in this thread with XFS and kernel > 2.4.16 : > > Is this problem fixed ? Well, I have tried with a 2.4.18 and the problem is the same. I have searched where the SIG_XFSZ signal is triggered and it is in xfs_file.c. I think the error is here. The "err" variable is set to a negative value and if it is non null, the opposite is returned. I think that we must return the positive value : return(err ? err : count); instead of return(err ? -err : count); But I suppose that the sign flipping was here for something. The only function that uses err (besides simple constant assignations) is the macro VOP_WRITE which I suppose finally calls xfs_write. xfs_write is said to return positive error value. So I suppose, that the above change is correct and the sign flipping must occur only after the call to xfs_write. Am I missing something ? -- /* * Hash table gook.. */ 2.4.0-test2 /usr/src/linux/fs/buffer.c From owner-linux-xfs@oss.sgi.com Sun Apr 21 05:53: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 g3LCrOqf010289 for ; Sun, 21 Apr 2002 05:53:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3LCrOrS010288 for linux-xfs-outgoing; Sun, 21 Apr 2002 05:53:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sto-vo-kor.koschikode.com (sto-vo-kor.koschikode.com [213.61.61.142]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3LCrAqf010251 for ; Sun, 21 Apr 2002 05:53:10 -0700 Received: from warp9.koschikode.com (pD9EB1F9B.dip.t-dialin.net [217.235.31.155]) by sto-vo-kor.koschikode.com (Postfix) with ESMTP id E5A62F501; Sun, 21 Apr 2002 14:53:17 +0200 (CEST) Received: from localhost (localhost.koschikode.com [127.0.0.1]) by warp9.koschikode.com (Postfix) with SMTP id 1FA70B8; Sun, 21 Apr 2002 14:53:05 +0200 (CEST) Received: from koschikode.com (pktomo.koschikode.com [192.168.200.10]) by warp9.koschikode.com (Postfix) with ESMTP id 29B03A9; Sun, 21 Apr 2002 14:53:04 +0200 (CEST) Message-ID: <3CC2B62F.3020303@koschikode.com> Date: Sun, 21 Apr 2002 14:53:03 +0200 From: Juri Haberland User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vincent Bernat Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and postfix References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Vincent Bernat wrote: > Hello, > > I encounter the problem described in this thread with XFS and kernel > 2.4.16 : > > > > Is this problem fixed ? Well, as I reported in http://marc.theaimsgroup.com/?l=postfix-users&m=101804736803968&w=2 the problem did not occure on a system with a kernel checked out on March 16 (actually the dates I reported had a off-by-one error ;). On the system in question I updated the kernel via CVS on April 8th and the problem has gone. Juri From owner-linux-xfs@oss.sgi.com Sun Apr 21 06:26: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 g3LDQIqf011052 for ; Sun, 21 Apr 2002 06:26:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3LDQIJM011051 for linux-xfs-outgoing; Sun, 21 Apr 2002 06:26:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zamok.crans.org (zamok.crans.org [138.231.136.6]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3LDQ3qf011024 for ; Sun, 21 Apr 2002 06:26:04 -0700 Received: from lucas.loria (localhost.crans.org [127.0.0.1]) by zamok.crans.org (Postfix) with ESMTP id 8A25A2E5; Sun, 21 Apr 2002 14:58:37 +0200 (CEST) Received: from neo.loria (neo.loria [10.0.0.3]) by lucas.loria (Postfix) with ESMTP id E019EA53B; Sun, 21 Apr 2002 14:58:32 +0200 (CEST) Received: by neo.loria (Postfix, from userid 500) id 251D1104D2A; Sun, 21 Apr 2002 14:58:32 +0200 (CEST) To: Juri Haberland Cc: linux-xfs@oss.sgi.com Subject: Re: XFS and postfix References: <3CC2B62F.3020303@koschikode.com> X-PGP-KeyID: 0xF22A794E X-PGP-Fingerprint: 5854 AF2B 65B2 0E96 2161 E32B 285B D7A1 F22A 794E From: Vincent Bernat In-Reply-To: <3CC2B62F.3020303@koschikode.com> (Juri Haberland's message of "Sun, 21 Apr 2002 14:53:03 +0200") Organization: Kabale Inc Date: Sun, 21 Apr 2002 14:58:31 +0200 Message-ID: Lines: 16 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) XEmacs/21.4 (Common Lisp, i686-pc-linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OoO En ce début d'après-midi nuageux du dimanche 21 avril 2002, vers 14:53, Juri Haberland disait: > Well, as I reported in > http://marc.theaimsgroup.com/?l=postfix-users&m=101804736803968&w=2 the > problem did not occure on a system with a kernel checked out on March 16 > (actually the dates I reported had a off-by-one error ;). On the system > in question I updated the kernel via CVS on April 8th and the problem has > gone. I browsed the web CVS and there are changes in xfs_file.c and it is the sign flipping problem, plus something else (maybe unrelated). Thanks for your help. -- BOFH excuse #360: Your parity check is overdrawn and you're out of cache. From owner-linux-xfs@oss.sgi.com Sun Apr 21 07:55: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 g3LEtiqf012568 for ; Sun, 21 Apr 2002 07:55:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3LEtiml012567 for linux-xfs-outgoing; Sun, 21 Apr 2002 07:55: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3LEtdqf012533 for ; Sun, 21 Apr 2002 07:55: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 JAA73129; Sun, 21 Apr 2002 09:56:00 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA77970; Sun, 21 Apr 2002 09:56:00 -0500 (CDT) Date: Sun, 21 Apr 2002 09:56:00 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ian Cumming cc: linux-xfs@oss.sgi.com Subject: re: quota patch In-Reply-To: <20020421090915.GA2108@ids.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ian - If the patch you obtained has "1.1" in the name, then you don't need the latest quota patch that Nathan checked in; quota in 1.1 is a bit different from what's currently in CVS, and as far as I know, quota functionality is fine. If you're running a production machine, I would use the 1.1 release. -Eric On Sun, 21 Apr 2002, Ian Cumming wrote: > Hi, > > I'm currently running kernel 2.4.18 + xfs patch set obtained from the > "latest" folder in the development pages on oss.sgi.com > > With regards to the quota fix submitted to CVS, should I update from > CVS, download 1.1, or just try to patch the quota.c file? > > I'm running a "production" server, so the userland quota functionality > would be desirable - which way is the best to get the quota stuff (and > ACLs) in a functionable state? (cvs or 1.1) -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Apr 21 09:18: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 g3LGIoqf014017 for ; Sun, 21 Apr 2002 09:18:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3LGIoiJ014016 for linux-xfs-outgoing; Sun, 21 Apr 2002 09:18: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3LGIgqf013989 for ; Sun, 21 Apr 2002 09:18:43 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA75641; Sun, 21 Apr 2002 11:19:04 -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 LAA77503; Sun, 21 Apr 2002 11:19:04 -0500 (CDT) Date: Sun, 21 Apr 2002 11:19:04 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Vincent Bernat cc: linux-xfs@oss.sgi.com Subject: Re: XFS and postfix In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Vincent - Yes, this was fixed about 5 weeks ago in CVS. The tricky part is that XFS uses positive error values internally, while Linux expects negative errors. (Linux often uses a single variable for returns, returning negative errors and positive results, i.e. either -EPERM or (+)bytes_written). XFS doesn't usually overload return values like this. In any case, when we transition from the internals of XFS out ot linux (i.e. the linvfs_* functions) we need to keep careful track of error signs. So, VOP_WRITE (which is essentially xfs_write) returns positive errors, but other constant assignments in linvfs_write set err to be negative. The out: target had always been flipping the sign of the error, but this was only correct for errors from VOP_WRITE. The change was made to explicitly sign-flip the VOP_WRITE error return, and otherwise return errors as they are. -Eric On Sun, 21 Apr 2002, Vincent Bernat wrote: > Well, I have tried with a 2.4.18 and the problem is the same. > I have searched where the SIG_XFSZ signal is triggered and it is in > xfs_file.c. I think the error is here. The "err" variable is set to a > negative value and if it is non null, the opposite is returned. I > think that we must return the positive value : > > return(err ? err : count); > > instead of > > return(err ? -err : count); > > But I suppose that the sign flipping was here for something. The only > function that uses err (besides simple constant assignations) is the > macro VOP_WRITE which I suppose finally calls xfs_write. xfs_write is > said to return positive error value. So I suppose, that the above > change is correct and the sign flipping must occur only after the call > to xfs_write. > > Am I missing something ? -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Sun Apr 21 22:23: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 g3M5Nrqf023589 for ; Sun, 21 Apr 2002 22:23:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3M5NquE023588 for linux-xfs-outgoing; Sun, 21 Apr 2002 22:23: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 g3M5Nlqf023558 for ; Sun, 21 Apr 2002 22:23:47 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id WAA583781 for ; Sun, 21 Apr 2002 22:24:15 -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 PAA82373; Mon, 22 Apr 2002 15:22:58 +1000 (EST) Date: Mon, 22 Apr 2002 15:22:58 +1000 (EST) From: Nathan Scott Message-Id: <200204220522.PAA82373@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: TAKE - acl/attr updates Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric/Nate - could you guys cross-check for us that the IA64 structure packing problem is still fixed in libacl? Thanks. Date: Sun Apr 21 22:19:17 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:116999a cmd/acl/VERSION - 1.27 cmd/acl/doc/CHANGES - 1.31 cmd/acl/debian/changelog - 1.22 cmd/acl/libacl/Makefile - 1.13 cmd/acl/libacl/libobj.h - 1.4 cmd/acl/libacl/libacl.h - 1.4 - updates from Andreas -libacl build change, 64 bit struct packing fix rework. cmd/attr/VERSION - 1.19 cmd/attr/doc/CHANGES - 1.22 cmd/attr/man/Makefile - 1.5 cmd/attr/debian/changelog - 1.20 cmd/attr/test/attr.test - 1.4 cmd/attr/man/man2/listxattr.2 - 1.4 - updates from Andreas -man page update, additional test cases. From owner-linux-xfs@oss.sgi.com Mon Apr 22 02:24: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 g3M9Ocqf026030 for ; Mon, 22 Apr 2002 02:24:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3M9OcBh026029 for linux-xfs-outgoing; Mon, 22 Apr 2002 02:24:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3M9OUqf026000 for ; Mon, 22 Apr 2002 02:24:31 -0700 Received: from pyewacket.nic.uklinux.net (host213-122-88-96.in-addr.btopenworld.com [213.122.88.96]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3M9OqA07587 for ; Mon, 22 Apr 2002 10:24:53 +0100 Envelope-To: Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.34 #1) id 16zZsu-0000eL-00 for linux-xfs@oss.sgi.com; Mon, 22 Apr 2002 10:13:20 +0100 Subject: Re: IDE write cache and journaling file systems From: Nic Doye To: linux-xfs@oss.sgi.com In-Reply-To: <1019247510.16444.283.camel@stout.americas.sgi.com> References: <1019247510.16444.283.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 22 Apr 2002 10:13:20 +0100 Message-Id: <1019466800.2160.19.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-19 at 21:18, Eric Sandeen wrote: > On Fri, 2002-04-19 at 10:35, Mark M. Barrios wrote: > > > today I had a real powerfailure and after the box was back up again I lost > > all of the settings in GNOME, everything went back to its default > > settings, I cant say if the config files were corupted or had 0 sizes. > > > > is this because these applications are not compatible with XFS? or > > because of my hardware? or is this a needed feature/bug fix not yet in XFS > > code? > > Well, it should not be a compatibility issue... gnome seems to be > particularly susceptible to this, it seems that our sync behavior may > not be quite right. > > On the other hand, with a metadata journaling filesystem, there is no > guarantee against data loss when the system crashes or is switched off. > We do need to be sure that we deal with it as gracefully as possible > though, and I'll see if I can get a reproducible case going. FWIW, my laptop loses all my gnome settings when I do a Desktop->Logout->Shutdown via the menu panel every time. This behaviour only started when I did a reinstall (to put an MS OS on it too) and then lazilly set it up to have 2 XFS partitions (/boot + a massive /) whereas previously it had my usual 8ish XFS partitions. So my theory is that: 1) it's something to do with "it being a laptop" (slow disk/odd controller) 2) gnome keeps files open for writing which are unnecessary 3) having a (stupidly) big partition (takes longer to sync?) Any theories gratefully received. Any testing you want done... nic From owner-linux-xfs@oss.sgi.com Mon Apr 22 02:38: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 g3M9cUqf026242 for ; Mon, 22 Apr 2002 02:38:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3M9cUNp026241 for linux-xfs-outgoing; Mon, 22 Apr 2002 02:38:30 -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 g3M9cMqf026214 for ; Mon, 22 Apr 2002 02:38:22 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 6B083C211; Mon, 22 Apr 2002 11:38:46 +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 LAA03496; Mon, 22 Apr 2002 11:38:45 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 7EE7457306; Mon, 22 Apr 2002 11:36:47 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 41E8A25835; Mon, 22 Apr 2002 11:36:47 +0200 (CEST) Message-ID: <3CC3D9AF.C5574193@ch.sauter-bc.com> Date: Mon, 22 Apr 2002 11:36:47 +0200 From: Simon Matter Organization: Sauter AG, Basel X-Mailer: Mozilla 4.77 [de] (X11; U; Linux 2.2.19-6.2.16 i686) X-Accept-Language: de-CH, en MIME-Version: 1.0 To: Nic Doye Cc: linux-xfs@oss.sgi.com Subject: Re: IDE write cache and journaling file systems References: <1019247510.16444.283.camel@stout.americas.sgi.com> <1019466800.2160.19.camel@pyewacket> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nic Doye schrieb: > > On Fri, 2002-04-19 at 21:18, Eric Sandeen wrote: > > On Fri, 2002-04-19 at 10:35, Mark M. Barrios wrote: > > > > > today I had a real powerfailure and after the box was back up again I lost > > > all of the settings in GNOME, everything went back to its default > > > settings, I cant say if the config files were corupted or had 0 sizes. > > > > > > is this because these applications are not compatible with XFS? or > > > because of my hardware? or is this a needed feature/bug fix not yet in XFS > > > code? > > > > Well, it should not be a compatibility issue... gnome seems to be > > particularly susceptible to this, it seems that our sync behavior may > > not be quite right. > > > > On the other hand, with a metadata journaling filesystem, there is no > > guarantee against data loss when the system crashes or is switched off. > > We do need to be sure that we deal with it as gracefully as possible > > though, and I'll see if I can get a reproducible case going. > > FWIW, my laptop loses all my gnome settings when I do a > Desktop->Logout->Shutdown via the menu panel every time. > > This behaviour only started when I did a reinstall (to put an MS OS on > it too) and then lazilly set it up to have 2 XFS partitions (/boot + a > massive /) whereas previously it had my usual 8ish XFS partitions.$ You did not tell us which kernel you're on. Anyway, if it's the "remount readonly bug" I could explain it like this: Before you had /home on a separate partition and this one was unmounted on reboot and therefore all data was cleanly written to the disk. Now your /home is on the / partition and therefore on reboot your /home is remounted readonly and this could leave to data loss if your kernel is affected by this bug. Just put a 'sleep 40' in the halt script before root gets remounted readonly and try it. -Simon > > So my theory is that: > 1) it's something to do with "it being a laptop" (slow disk/odd > controller) > 2) gnome keeps files open for writing which are unnecessary > 3) having a (stupidly) big partition (takes longer to sync?) > > Any theories gratefully received. Any testing you want done... > > nic From owner-linux-xfs@oss.sgi.com Mon Apr 22 03:24: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 g3MAOVqf026773 for ; Mon, 22 Apr 2002 03:24:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MAOV1V026772 for linux-xfs-outgoing; Mon, 22 Apr 2002 03:24:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MAOOqf026743 for ; Mon, 22 Apr 2002 03:24:25 -0700 Received: from pyewacket.nic.uklinux.net (host213-122-88-96.in-addr.btopenworld.com [213.122.88.96]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3MAOlB14868 for ; Mon, 22 Apr 2002 11:24:47 +0100 Envelope-To: Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.34 #1) id 16zan1-0000fL-00 for linux-xfs@oss.sgi.com; Mon, 22 Apr 2002 11:11:19 +0100 Subject: Re: IDE write cache and journaling file systems From: Nic Doye To: linux-xfs@oss.sgi.com In-Reply-To: <3CC3D9AF.C5574193@ch.sauter-bc.com> References: <1019247510.16444.283.camel@stout.americas.sgi.com> <1019466800.2160.19.camel@pyewacket> <3CC3D9AF.C5574193@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 22 Apr 2002 11:11:19 +0100 Message-Id: <1019470279.2156.35.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-04-22 at 10:36, Simon Matter wrote: > You did not tell us which kernel you're on. Sorry. I think many variables changed at once (hence never reporting it). Personally, I view it as my own stupid fault. Factors that changed: 1) went from sane disk layout to dumb disk layout 2) went from RH 7.1 to RH 7.2 3) went from 2.4.3 to 2.4.9-21 (and onto 31) (Both of these 2.4.9's are your excellent contrib kernels which I also use on my real machines) > Anyway, if it's the "remount readonly bug" I could explain it like this: > Before you had /home on a separate partition and this one was unmounted > on reboot and therefore all data was cleanly written to the disk. > Now your /home is on the / partition and therefore on reboot your /home > is remounted readonly and this could leave to data loss if your kernel > is affected by this bug. Just put a 'sleep 40' in the halt script before > root gets remounted readonly and try it. This sounds perfectly feasible. I'll do some tests to see. nic From owner-linux-xfs@oss.sgi.com Mon Apr 22 04:13: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 g3MBD2qf027892 for ; Mon, 22 Apr 2002 04:13:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MBD2BY027891 for linux-xfs-outgoing; Mon, 22 Apr 2002 04:13:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MBCuqf027864 for ; Mon, 22 Apr 2002 04:12:57 -0700 Received: from pyewacket.nic.uklinux.net (host213-122-88-96.in-addr.btopenworld.com [213.122.88.96]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3MBDKa20456 for ; Mon, 22 Apr 2002 12:13:20 +0100 Envelope-To: Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.34 #1) id 16zbEa-0000fn-00 for linux-xfs@oss.sgi.com; Mon, 22 Apr 2002 11:39:48 +0100 Subject: Re: IDE write cache and journaling file systems From: Nic Doye To: XFS In-Reply-To: <1019470279.2156.35.camel@pyewacket> References: <1019247510.16444.283.camel@stout.americas.sgi.com> <1019466800.2160.19.camel@pyewacket> <3CC3D9AF.C5574193@ch.sauter-bc.com> <1019470279.2156.35.camel@pyewacket> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 22 Apr 2002 11:39:48 +0100 Message-Id: <1019471988.2156.43.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-04-22 at 11:11, Nic Doye wrote: > On Mon, 2002-04-22 at 10:36, Simon Matter wrote: > > Anyway, if it's the "remount readonly bug" I could explain it like this: > > Before you had /home on a separate partition and this one was unmounted > > on reboot and therefore all data was cleanly written to the disk. > > Now your /home is on the / partition and therefore on reboot your /home > > is remounted readonly and this could leave to data loss if your kernel > > is affected by this bug. Just put a 'sleep 40' in the halt script before > > root gets remounted readonly and try it. > > This sounds perfectly feasible. I'll do some tests to see. First test. Everything disappears from the panels, as per flaming usual. As far as I'm concerned this is my fault for having set the machine up so badly. I'd rather the Linux XFS team concentrated on all the real issues (so everyone can have XFS on their servers) than waste their time thinking about my laptop. nic From owner-linux-xfs@oss.sgi.com Mon Apr 22 04:20: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 g3MBKnqf028117 for ; Mon, 22 Apr 2002 04:20:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MBKnfc028116 for linux-xfs-outgoing; Mon, 22 Apr 2002 04:20:49 -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 g3MBKhqf028090 for ; Mon, 22 Apr 2002 04:20:43 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 4BE12C210; Mon, 22 Apr 2002 13:21: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 NAA12620; Mon, 22 Apr 2002 13:21:07 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 6BA3257306; Mon, 22 Apr 2002 13:20:36 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id A178A25835; Mon, 22 Apr 2002 13:20:35 +0200 (CEST) Message-ID: <3CC3F203.9F41E98E@ch.sauter-bc.com> Date: Mon, 22 Apr 2002 13:20:35 +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, en MIME-Version: 1.0 To: Nic Doye Cc: linux-xfs@oss.sgi.com Subject: Re: IDE write cache and journaling file systems References: <1019247510.16444.283.camel@stout.americas.sgi.com> <1019466800.2160.19.camel@pyewacket> <3CC3D9AF.C5574193@ch.sauter-bc.com> <1019470279.2156.35.camel@pyewacket> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Nic Doye schrieb: > > On Mon, 2002-04-22 at 10:36, Simon Matter wrote: > > > You did not tell us which kernel you're on. > > Sorry. I think many variables changed at once (hence never reporting > it). Personally, I view it as my own stupid fault. > > Factors that changed: > 1) went from sane disk layout to dumb disk layout > 2) went from RH 7.1 to RH 7.2 > 3) went from 2.4.3 to 2.4.9-21 (and onto 31) (Both of these 2.4.9's are > your excellent contrib kernels which I also use on my real machines) You should ugrade to the 1.1 release of 2.4.9-31. The 'remount readonly' is fixed there. Please let us know if this helps. -Simon > > > Anyway, if it's the "remount readonly bug" I could explain it like this: > > Before you had /home on a separate partition and this one was unmounted > > on reboot and therefore all data was cleanly written to the disk. > > Now your /home is on the / partition and therefore on reboot your /home > > is remounted readonly and this could leave to data loss if your kernel > > is affected by this bug. Just put a 'sleep 40' in the halt script before > > root gets remounted readonly and try it. > > This sounds perfectly feasible. I'll do some tests to see. > > nic From owner-linux-xfs@oss.sgi.com Mon Apr 22 05:45: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 g3MCjvqf029060 for ; Mon, 22 Apr 2002 05:45:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MCjvdE029059 for linux-xfs-outgoing; Mon, 22 Apr 2002 05:45:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from server.tevox.de (ghost.liquidsteel.net [62.8.161.162]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MCjqqf029031 for ; Mon, 22 Apr 2002 05:45:53 -0700 Received: (qmail 11812 invoked by uid 64014); 22 Apr 2002 12:46:20 -0000 Received: from cd@kalkatraz.de by server with qmail-scanner-1.01 ( Clean. Processed in 0.17181 secs); 22 Apr 2002 12:46:20 -0000 Received: from scully.tevox.de (200.0.0.14) by mail.tevox.de with DES-CBC3-SHA encrypted SMTP; 22 Apr 2002 12:46:20 -0000 Date: Mon, 22 Apr 2002 14:46:19 +0200 From: Lars Weitze To: samba@lists.samba.org Cc: linux-xfs@oss.sgi.com Subject: ACLs and security=server not working Message-Id: <20020422144619.49a0b59d.cd@kalkatraz.de> Organization: http://www.liquidsteel.net X-Mailer: Sylpheed version 0.7.4 (GTK+ 1.2.10; i686-pc-linux-gnu) X-Face: "Add'HrsHhg}pA?6>_fl]8[PNFwpJTSTW?I_:}%1O}rQof)E5W:qQbr1i>J?[?W:9"~?}]; ,?}|UTr8Ww=d%HY}-ap:|nv&; Mon, 22 Apr 2002 06:17:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MDHCT5030175 for linux-xfs-outgoing; Mon, 22 Apr 2002 06:17: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MDH6qf030146 for ; Mon, 22 Apr 2002 06:17:06 -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 IAA83235; Mon, 22 Apr 2002 08:17:32 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA11730; Mon, 22 Apr 2002 08:17:31 -0500 (CDT) Date: Mon, 22 Apr 2002 08:17:31 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Nic Doye cc: linux-xfs@oss.sgi.com Subject: Re: IDE write cache and journaling file systems In-Reply-To: <1019466800.2160.19.camel@pyewacket> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nic - The other thought is that it may have something to do with /home being on the / filesystem in this case, since / is the last filesystem to be unmounted, and goes through the remount,ro trick on shutdown. Any chance you have a spare partition to move /home to, or maybe make a small user homedir in /boot, to see if it exhibits the same problem? -Eric On 22 Apr 2002, Nic Doye wrote: > FWIW, my laptop loses all my gnome settings when I do a > Desktop->Logout->Shutdown via the menu panel every time. > > This behaviour only started when I did a reinstall (to put an MS OS on > it too) and then lazilly set it up to have 2 XFS partitions (/boot + a > massive /) whereas previously it had my usual 8ish XFS partitions. > > So my theory is that: > 1) it's something to do with "it being a laptop" (slow disk/odd > controller) > 2) gnome keeps files open for writing which are unnecessary > 3) having a (stupidly) big partition (takes longer to sync?) -- Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs sandeen@sgi.com SGI, Inc. From owner-linux-xfs@oss.sgi.com Mon Apr 22 08:47: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 g3MFlLqf032115 for ; Mon, 22 Apr 2002 08:47:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MFlLtx032114 for linux-xfs-outgoing; Mon, 22 Apr 2002 08:47:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from s1.uklinux.net (mail.uklinux.net [80.84.72.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MFlBqf032085 for ; Mon, 22 Apr 2002 08:47:15 -0700 Received: from pyewacket.nic.uklinux.net (host213-122-80-203.in-addr.btopenworld.com [213.122.80.203]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3MFlYc28118 for ; Mon, 22 Apr 2002 16:47:35 +0100 Envelope-To: Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.34 #1) id 16zg0f-0000x9-00 for linux-xfs@oss.sgi.com; Mon, 22 Apr 2002 16:45:45 +0100 Subject: [Fixed] Re: IDE write cache and journaling file systems From: Nic Doye To: XFS In-Reply-To: <3CC3F203.9F41E98E@ch.sauter-bc.com> References: <1019247510.16444.283.camel@stout.americas.sgi.com> <1019466800.2160.19.camel@pyewacket> <3CC3D9AF.C5574193@ch.sauter-bc.com> <1019470279.2156.35.camel@pyewacket> <3CC3F203.9F41E98E@ch.sauter-bc.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 22 Apr 2002 16:45:45 +0100 Message-Id: <1019490345.3258.81.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-04-22 at 12:20, Simon Matter wrote: > Nic Doye schrieb: > You should ugrade to the 1.1 release of 2.4.9-31. The 'remount readonly' > is fixed there. Please let us know if this helps. OK, so I switched from 2.4.9-31 contrib to 2.4.9-31 1.1. Reboot. (Clock gains an hour mysteriously[1]). Add applets and launchers. ~12 shutdowns/logins later and it all seems fine. On one occaision all the applets "forgot what they were", but this is different from all launchers and applets disappearing completely. I think the "panel" may have got itself very confused at this point. So Simon was right, and Eric need worry no longer (and thank you both for your help). Needless to say, if it does it again (and it doesn't appear to be just a gnome bug) I'll let you know. Thanks again, nic Footnotes: [1] Sometimes, I'm sure my own computers do odd things just to piss me off. From owner-linux-xfs@oss.sgi.com Mon Apr 22 09: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 g3MGPYqf001953 for ; Mon, 22 Apr 2002 09:25:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MGPY6e001952 for linux-xfs-outgoing; Mon, 22 Apr 2002 09: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MGPTqf001925 for ; Mon, 22 Apr 2002 09:25:30 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA88928 for ; Mon, 22 Apr 2002 11:25: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 LAA44549 for ; Mon, 22 Apr 2002 11:25:55 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3MGMec18705; Mon, 22 Apr 2002 11:22:40 -0500 Message-Id: <200204221622.g3MGMec18705@jen.americas.sgi.com> Date: Mon, 22 Apr 2002 11:22:40 -0500 Subject: TAKE - small realtime I/O path change To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk No effect on the normal kernel, but an incorrect flag was being checked to detect realtime being enabled for a file. Date: Mon Apr 22 09:24:56 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117024a linux/fs/xfs/linux/xfs_iops.c - 1.131 - Use XFS_DIFLAG_REALTIME instead of XFS_IOCORE_RT to detect realtime From owner-linux-xfs@oss.sgi.com Mon Apr 22 09:29: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 g3MGT4qf002141 for ; Mon, 22 Apr 2002 09:29:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MGT3e3002140 for linux-xfs-outgoing; Mon, 22 Apr 2002 09:29:03 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from joines.okstate.edu (joines.bus.okstate.edu [139.78.89.31]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MGSvqf002114 for ; Mon, 22 Apr 2002 09:28:57 -0700 Received: from localhost (localhost [[UNIX: localhost]]) by joines.okstate.edu (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) id g3MGS2e19444; Mon, 22 Apr 2002 11:28:02 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Jason Joines To: XFS Users Subject: Re: OT: ISO images for Suse Date: Mon, 22 Apr 2002 11:28:01 -0500 X-Mailer: KMail [version 1.4] References: <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> In-Reply-To: <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204221128.01746.joines@joines.okstate.edu> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Friday 19 April 2002 11:22, Greg Freemyer wrote: > Guys, > > Since SuSE 8.0 is going to have XFS in it, I decided to go see if the > ISO images could be downloaded. > > 8.0 is not released until next week, so there is nothing for it, so I > went looking at 7.3 > > ftp://ftp-linux.cc.gatech.edu/pub/linux/distributions/suse/suse/i386/ >7.3 > > I don't see any CD images. > > Does anyone know if they make them available for download or not. > > If so, where. > > PS: I have ordered a set from the online store, but they say it will > be the end of the month before they ship, and I would like to start > getting experience with SuSE 8.0 next week if I can. > > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > The Norcross Group > www.NorcrossGroup.com SuSE doesn't provide ISO images but you can download there boot floppy that allows you to install straight from there ftp server or a mirror. Instructions are at http://sdb.suse.de/sdb/en/html/lmuelle_suselinux_internet.html Also, once someone gets the CDs, you are free to make ISOs and redistribute them as long as you don't charge for it. Jason Joines ---------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Apr 22 09:36: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 g3MGajqf002391 for ; Mon, 22 Apr 2002 09:36:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MGajt2002390 for linux-xfs-outgoing; Mon, 22 Apr 2002 09:36: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.163]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MGadqf002340 for ; Mon, 22 Apr 2002 09:36:39 -0700 Received: (qmail 23150 invoked by uid 500); 22 Apr 2002 16:33:29 -0000 Subject: DMP MD device + XFS + FC Howto? From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-oZS1UTEINvM+mWsHitlh" X-Mailer: Ximian Evolution 1.0.3.99 Date: 22 Apr 2002 11:33:29 -0500 Message-Id: <1019493209.23057.5.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-oZS1UTEINvM+mWsHitlh Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Is there a HowTo like document on something like this anywhere? I need some failover options for storage. Say 2 or 4 HBAs? If anyone has info on this, or is doing this, with XFS, I'd like to know where to get this info.=20 TIA. --=20 Austin Gonyou Systems Architect, CCNA Coremetrics, Inc. Phone: 512-698-7250 email: austin@coremetrics.com "It is the part of a good shepherd to shear his flock, not to skin it." Latin Proverb --=-oZS1UTEINvM+mWsHitlh 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 iD8DBQA8xDtZ94g6ZVmFMoIRAnZyAKDVUO7L8CneH1uxUhFotbSVBkUKwwCfbUN9 Md7YISberWnDaJsatWnfVQY= =+phA -----END PGP SIGNATURE----- --=-oZS1UTEINvM+mWsHitlh-- From owner-linux-xfs@oss.sgi.com Mon Apr 22 09: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 g3MGcRqf002480 for ; Mon, 22 Apr 2002 09:38:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MGcR4n002479 for linux-xfs-outgoing; Mon, 22 Apr 2002 09:38:27 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MGcNqf002453 for ; Mon, 22 Apr 2002 09:38:23 -0700 Received: (qmail 10263 invoked by uid 1000); 22 Apr 2002 16:38:08 -0000 To: Jim Buzbee Cc: XFS List Subject: Re: IDE write cache and journaling file systems References: <3CBEE618.B220A393@echostar.com> From: Florian Weimer Date: Mon, 22 Apr 2002 18:38:08 +0200 In-Reply-To: <3CBEE618.B220A393@echostar.com> (Jim Buzbee's message of "Thu, 18 Apr 2002 09:28:24 -0600") Message-ID: <87it6jheof.fsf@CERT.Uni-Stuttgart.DE> Lines: 13 User-Agent: Gnus/5.090005 (Oort Gnus v0.05) Emacs/21.1 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jim Buzbee writes: > In our application, (consumer set top box) we cannot always cleanly shut > down the system. The consumer rightly expects to just unplug the box > when he wants/needs to. BTW, there are a few IBM disks which take the liberty to map out at most one sector if power fails during a write operation. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 From owner-linux-xfs@oss.sgi.com Mon Apr 22 12:03: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 g3MJ32qf007581 for ; Mon, 22 Apr 2002 12:03:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MJ32TN007580 for linux-xfs-outgoing; Mon, 22 Apr 2002 12:03:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from webshield (pc005.butterfield.com.hk [203.85.35.5] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MJ2sqf007548 for ; Mon, 22 Apr 2002 12:02:55 -0700 Received: FROM C0RE BY webshield ; Tue Apr 23 03:00:14 2002 +0800 Message-ID: <4146-220024122185811914@C0RE> X-Priority: 3 To: "sr4" From: "panagrow@yahoo.com" Subject: Free Online Seminar on Developing a Dynamic E-business Strategy! Date: Mon, 22 Apr 2002 11:58:12 -0700 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Space is Limited for the April 25th Seminar. Register Today! Discover how an integrated web solution suite can deliver VARs, Web Agencies, and System Integrators more effective solutions for their customer base while ensuring opportunities for revenue and greater ROI. The seminar will explore how to: Speed Time-to-market and Reduce Development Costs Allocate Resources Better and Increase Revenue Reduce Cost of Ownership and Increase Customer Satisfaction Leverage Reef Alliances with Industry Leaders Win New Business WHAT: Free Online Seminar for VARs, Web Agencies and System Integrators WHEN: Thursday - April 25, 9am to 10am PST WHERE: Your Web Browser (Internet Explorer or Netscape--Your choice!) Click Here to Register [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Apr 22 12:21: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 g3MJLOqf007966 for ; Mon, 22 Apr 2002 12:21:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MJLOhf007965 for linux-xfs-outgoing; Mon, 22 Apr 2002 12:21: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.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MJLJqf007939 for ; Mon, 22 Apr 2002 12:21:19 -0700 Received: from daisy-e185.americas.sgi.com (daisy-e194.americas.sgi.com [128.162.194.214]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA64352 for ; Mon, 22 Apr 2002 14:21:45 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA94395 for ; Mon, 22 Apr 2002 14:21:45 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3MJITL20052; Mon, 22 Apr 2002 14:18:29 -0500 Message-Id: <200204221918.g3MJITL20052@jen.americas.sgi.com> Date: Mon, 22 Apr 2002 14:18:29 -0500 Subject: TAKE - pagebuf fixes To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks to Mike Ovsiannikov for these. One of the code paths which should have called balance_dirty from the xfs write path had a bug which meant it could never get down to balance_dirty. Which means we can dirty too much data and get tied in knots trying to find memory. Date: Mon Apr 22 12:15:37 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-vanilla The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117040a linux/fs/xfs/pagebuf/page_buf_io.c - 1.25 - Fix an error which could lead to less balance_dirty calls than we should make, plus some missing kunmap calls in error paths. From owner-linux-xfs@oss.sgi.com Mon Apr 22 14:10: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 g3MLAIqf020899 for ; Mon, 22 Apr 2002 14:10:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MLAI0J020898 for linux-xfs-outgoing; Mon, 22 Apr 2002 14:10:18 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moria.linuxis.net (moria.linuxis.net [64.71.162.80]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MLA8qf020865 for ; Mon, 22 Apr 2002 14:10:08 -0700 Received: (qmail 10575 invoked by uid 1000); 22 Apr 2002 21:05:14 -0000 Date: Mon, 22 Apr 2002 14:05:14 -0700 To: linux-xfs@oss.sgi.com Subject: oops in 2.4.14-xfs (XFS 1.0.2) Message-ID: <20020422210514.GE28583@flounder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Adam McKenna Mail-Followup-To: linux-xfs@oss.sgi.com X-Delivery-Agent: TMDA/0.51 (Python 2.1.2 on Linux/i686) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk One of our boxes crashed today with this error. Can anyone tell me if this is XFS-related? Thanks, --Adam Unable to handle kernel NULL pointer dereference at virtual address 00000010 c011361f *pde = 298bf001 Oops: 0000 CPU: 0 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010006 eax: 00000010 ebx: e587003c ecx: 00000019 edx: 00000010 esi: e5870000 edi: c0308000 ebp: c0309fc4 esp: c0309f8c ds: 0018 es: 0018 ss: 0018 Process swapper (pid: 0, stackpage=c0309000) Stack: c01053b0 c0308000 c01053b0 00000001 00000010 e5c94000 00000000 0008e000 00000000 f3ba7660 00000001 0000002e 00000000 c0344840 0008e000 c010544e 000fa000 0009b800 c0105000 c0105043 c030a8f1 c029da40 000fa000 000fa000 Call Trace: [] [] [] [] [] Code: 8b 02 0f 18 00 81 fa 20 e6 2e c0 0f 85 76 ff ff ff 83 7d f4 >>EIP; c011361f <===== >>ebx; e587003c >>esi; e5870000 >>edi; c0308000 <__devicestr_104cac53+0/23> >>ebp; c0309fc4 <__devicestr_10b75950+5/19> >>esp; c0309f8c <__devicestr_10b75900+c/20> Trace; c01053b0 Trace; c01053b0 Trace; c010544e Trace; c0105000 <_stext+0/0> Trace; c0105043 Code; c011361f 00000000 <_EIP>: Code; c011361f <===== 0: 8b 02 mov (%edx),%eax <===== Code; c0113621 2: 0f 18 00 prefetchnta (%eax) Code; c0113624 5: 81 fa 20 e6 2e c0 cmp $0xc02ee620,%edx Code; c011362a b: 0f 85 76 ff ff ff jne ffffff87 <_EIP+0xffffff87> c01135a6 Code; c0113630 11: 83 7d f4 00 cmpl $0x0,0xfffffff4(%ebp) -- Adam McKenna | GPG: 17A4 11F7 5E7E C2E7 08AA http://flounder.net/publickey.html | 38B0 05D0 8BF7 2C6D 110A From owner-linux-xfs@oss.sgi.com Mon Apr 22 16:27: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 g3MNRCqf022878 for ; Mon, 22 Apr 2002 16:27:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MNRChe022877 for linux-xfs-outgoing; Mon, 22 Apr 2002 16:27:12 -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 g3MNR8qf022850 for ; Mon, 22 Apr 2002 16:27:08 -0700 Received: from relay1.corp.sgi.com (corp.sgi.com [198.29.75.13]) 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 QAA05388 for ; Mon, 22 Apr 2002 16:27:20 -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 QAA61424 for ; Mon, 22 Apr 2002 16:27:05 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 814C513641F for ; Mon, 22 Apr 2002 16:27:05 -0700 (PDT) Subject: Re: XFS and postfix From: Florin Andrei