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 To: 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: 22 Apr 2002 16:27:05 -0700 Message-Id: <1019518025.12762.79.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2002-04-21 at 09:19, Eric Sandeen wrote: > > Yes, this was fixed about 5 weeks ago in CVS. That means, it's fixed in v1.1, right? -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. From owner-linux-xfs@oss.sgi.com Mon Apr 22 16:35: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 g3MNZ6qf023110 for ; Mon, 22 Apr 2002 16:35:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MNZ6h7023109 for linux-xfs-outgoing; Mon, 22 Apr 2002 16:35: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 g3MNZ2qf023083 for ; Mon, 22 Apr 2002 16:35:02 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id QAA760988 for ; Mon, 22 Apr 2002 16:35:35 -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 QAA66583 for ; Mon, 22 Apr 2002 16:35:04 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 6EB0613641F for ; Mon, 22 Apr 2002 16:35:04 -0700 (PDT) Subject: Re: [Fixed] Re: IDE write cache and journaling file systems From: Florin Andrei To: XFS In-Reply-To: <1019490345.3258.81.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> <3CC3F203.9F41E98E@ch.sauter-bc.com> <1019490345.3258.81.camel@pyewacket> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 22 Apr 2002 16:35:04 -0700 Message-Id: <1019518504.12762.83.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-04-22 at 08:45, Nic Doye wrote: > > 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. Yes. If you trash the filesystem badly, the Gnome Panel becomes very confused. At this point, it's better to logout from Gnome, backup your .gnome directory and other configuration bits in your ~user, erase the said configurations, then start again with a clean slate. It happened to me on Ext2, it was one of the main reasons to switch to journalised FSs on my workstation. -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. From owner-linux-xfs@oss.sgi.com Mon Apr 22 16:44:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MNiUqf023319 for ; Mon, 22 Apr 2002 16:44:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MNiUfH023318 for linux-xfs-outgoing; Mon, 22 Apr 2002 16:44:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MNiOqf023292 for ; Mon, 22 Apr 2002 16:44:25 -0700 Received: (qmail 15748 invoked by uid 0); 22 Apr 2002 23:44:52 -0000 Received: from m223.net81-65-102.noos.fr (HELO mail.gmx.de) (81.65.102.223) by mail.gmx.net (mp014-rz3) with SMTP; 22 Apr 2002 23:44:52 -0000 Message-ID: <200204230143150875.1F48DF92@mail.gmx.de> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 23 Apr 2002 01:43:15 +0200 From: "linux" To: linux-xfs@oss.sgi.com Subject: cmd tars 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 g3MNiQqf023293 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi i've a problem with the last release of xfs i made a ./configure make make install make install-dev make install-lib in each directory [root@bretagne cmd_tars]# ls MD5SUMS acl-2.0.9/ attr-2.0.7/ dmapi-2.0.2/ tar/ xfsdump-2.0.1/ xfsprogs-2.0.3/ [root@bretagne cmd_tars]# chacl chacl: error while loading shared libraries: chacl: undefined symbol: acl_set_compat [root@bretagne cmd_tars]# uname -a Linux bretagne.ath.cx 2.4.18-xfs-1.1 #1 dim avr 21 18:07:38 CEST 2002 i686 unknown what's going wrong ? thanks for your help @++ Nico From owner-linux-xfs@oss.sgi.com Mon Apr 22 16:53:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3MNrHqf024266 for ; Mon, 22 Apr 2002 16:53:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3MNrHAR024265 for linux-xfs-outgoing; Mon, 22 Apr 2002 16:53:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3MNrBqf024239 for ; Mon, 22 Apr 2002 16:53:11 -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 QAA544366 for ; Mon, 22 Apr 2002 16:53:43 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA27811; Tue, 23 Apr 2002 09:52:26 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA69974; Tue, 23 Apr 2002 09:52:26 +1000 (AEST) Date: Tue, 23 Apr 2002 09:52:26 +1000 From: Nathan Scott To: linux Cc: linux-xfs@oss.sgi.com Subject: Re: cmd tars Message-ID: <20020423095225.E63455@wobbly.melbourne.sgi.com> References: <200204230143150875.1F48DF92@mail.gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200204230143150875.1F48DF92@mail.gmx.de>; from dahouet@gmx.net on Tue, Apr 23, 2002 at 01:43:15AM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 23, 2002 at 01:43:15AM +0200, linux wrote: > Hi > > i've a problem with the last release of xfs > > i made a > ./configure > make > make install > make install-dev > make install-lib > in each directory > > [root@bretagne cmd_tars]# ls > MD5SUMS acl-2.0.9/ attr-2.0.7/ dmapi-2.0.2/ tar/ xfsdump-2.0.1/ xfsprogs-2.0.3/ > [root@bretagne cmd_tars]# chacl > chacl: error while loading shared libraries: chacl: undefined symbol: acl_set_compat You probably have an older version of chacl(1) on your path somewhere before the new one... IIRC, this moved from /bin to /usr/bin (or maybe vice-versa) as part of the consolidation effort with the ext2 project's ACL userspace code. You can safely remove the old chacl binary, and just use the new one. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 22 17:33:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3N0Xeqf025907 for ; Mon, 22 Apr 2002 17:33:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3N0XeaS025906 for linux-xfs-outgoing; Mon, 22 Apr 2002 17:33:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3N0XZqf025879 for ; Mon, 22 Apr 2002 17:33:36 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id TAA96196; Mon, 22 Apr 2002 19:34: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 TAA82643; Mon, 22 Apr 2002 19:34:02 -0500 (CDT) Date: Mon, 22 Apr 2002 19:34:02 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Florin Andrei cc: linux-xfs@oss.sgi.com Subject: Re: XFS and postfix In-Reply-To: <1019518025.12762.79.camel@stantz.corp.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 22 Apr 2002, Florin Andrei wrote: > On Sun, 2002-04-21 at 09:19, Eric Sandeen wrote: > > > > Yes, this was fixed about 5 weeks ago in CVS. > > That means, it's fixed in v1.1, right? Yes. -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 22 21:49: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 g3N4n2wJ002558 for ; Mon, 22 Apr 2002 21:49:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3N4n297002557 for linux-xfs-outgoing; Mon, 22 Apr 2002 21:49:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3N4mtwJ002529 for ; Mon, 22 Apr 2002 21:48:55 -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 VAA797944 for ; Mon, 22 Apr 2002 21:49:14 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with ESMTP id g3N4mD21087958 for ; Mon, 22 Apr 2002 21:48:13 -0700 (PDT) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id OAA43349 for linux-xfs@oss.sgi.com; Tue, 23 Apr 2002 14:46:55 +1000 (EST) Date: Tue, 23 Apr 2002 14:46:55 +1000 (EST) From: Nathan Scott Message-Id: <200204230446.OAA43349@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Work-in-progress, shouldn't affect the blksize == pgsize case at all. Date: Mon Apr 15 20:53:52 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:116448a linux/fs/xfs/pagebuf/page_buf_io.c - 1.24 - changes for the file read code path to support filesystem blocksizes smaller than the pagesize. Date: Mon Apr 22 21:40:43 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117115a linux/fs/xfs/pagebuf/page_buf_io.c - 1.26 - several changes to support blocksizes smaller than the pagesize on the write path. needs the delalloc page bit change still before it becomes really useful. linux/fs/xfs/pagebuf/page_buf_internal.h - 1.2 - make a couple of functions/macros available to page_buf.c from page_buf_io.c; looks like (current implementation anyway) we will need these on the metadata path too. From owner-linux-xfs@oss.sgi.com Tue Apr 23 01:28: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 g3N8SCwJ005055 for ; Tue, 23 Apr 2002 01:28:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3N8SC98005054 for linux-xfs-outgoing; Tue, 23 Apr 2002 01:28:12 -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@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3N8S7wJ005028 for ; Tue, 23 Apr 2002 01:28:07 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 5BCF0401A40; Tue, 23 Apr 2002 04:28:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 5A310C0393F for ; Tue, 23 Apr 2002 04:28:38 -0400 (EDT) Date: Tue, 23 Apr 2002 04:28:38 -0400 (EDT) From: Mike Burger To: linux-xfs@oss.sgi.com Subject: /dev/null coming up as chmod 600 at boot? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I noticed something odd once I started using the latest 2.4.9-31 kernel with XFS 1.1, and removed the 2.4.14 XFS 1.0.2 kernel that I had installed (as an additional kernel...I just don't know if there's any correlation between removing it and what's happening). When I boot up, I've found that /dev/null is chmod 600 (rw-------). This, of course, causes all sorts of problems, as a number of background process I run are piped through /dev/null, and aren't necessarily run as root. It also causes me to not properly start up the KDE desktop when I log in. I get a different desktop, from which I have to open an xterm, chmod 666 /dev/null, and then log out and back in, again. I even went so far as to add "/bin/chmod 666 /dev/null" to my /etc/rc.d/rc.local file, but it doesn't seem to have helped. Any ideas on what I can do to remedy this on a more permanent basis? From owner-linux-xfs@oss.sgi.com Tue Apr 23 01:50:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3N8oEwJ005441 for ; Tue, 23 Apr 2002 01:50:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3N8oEVB005440 for linux-xfs-outgoing; Tue, 23 Apr 2002 01:50:14 -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 g3N8o8wJ005413 for ; Tue, 23 Apr 2002 01:50:09 -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 g3N8oOJW008965; Tue, 23 Apr 2002 10:50:25 +0200 (CEST) Message-Id: <4.3.2.7.2.20020423104241.035c73f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Apr 2002 10:51:45 +0200 To: Mike Burger , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: /dev/null coming up as chmod 600 at boot? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 04:28 23-4-2002 -0400, Mike Burger wrote: >I noticed something odd once I started using the latest 2.4.9-31 kernel >with XFS 1.1, and removed the 2.4.14 XFS 1.0.2 kernel that I had installed >(as an additional kernel...I just don't know if there's any correlation >between removing it and what's happening). There might very well be one. >When I boot up, I've found that /dev/null is chmod 600 (rw-------). I have XFS 1.1 here but I didn't install it using the RPM. I built from the kernel-source rpm and installed it from there. The /dev/null on this box still has 666 so I reckon that the file got touched somewhere in the process of upgrading. You should be able to chmod the file and the permission should stick. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Tue Apr 23 02:28:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3N9StwJ005953 for ; Tue, 23 Apr 2002 02:28:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3N9StmH005952 for linux-xfs-outgoing; Tue, 23 Apr 2002 02:28:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3N9SnwJ005925 for ; Tue, 23 Apr 2002 02:28:49 -0700 Received: (qmail 4396 invoked by uid 0); 23 Apr 2002 09:29:00 -0000 Received: from m223.net81-65-102.noos.fr (HELO mail.gmx.de) (81.65.102.223) by mail.gmx.net (mp014-rz3) with SMTP; 23 Apr 2002 09:29:00 -0000 Message-ID: <200204231127210898.215FA219@mail.gmx.de> In-Reply-To: <20020423095225.E63455@wobbly.melbourne.sgi.com> References: <200204230143150875.1F48DF92@mail.gmx.de> <20020423095225.E63455@wobbly.melbourne.sgi.com> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 23 Apr 2002 11:27:21 +0200 From: "linux" To: linux-xfs@oss.sgi.com Subject: Re: cmd tars Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3N9SowJ005926 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Le 23/04/2002 à 09:52 Nathan Scott a écrit : >You probably have an older version of chacl(1) on your path >somewhere before the new one... IIRC, this moved from /bin >to /usr/bin (or maybe vice-versa) as part of the consolidation >effort with the ext2 project's ACL userspace code. > >You can safely remove the old chacl binary, and just use the >new one. exactly, i've deleted the /bin one and it's ok there's nothing more to take attention ? thanks @++ nico From owner-linux-xfs@oss.sgi.com Tue Apr 23 04:19: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 g3NBJUwJ007462 for ; Tue, 23 Apr 2002 04:19:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NBJUTZ007461 for linux-xfs-outgoing; Tue, 23 Apr 2002 04:19:30 -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 g3NBJNwJ007432 for ; Tue, 23 Apr 2002 04:19:24 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by wiley (8.11.6/8.11.6) with ESMTP id g3NBJdE01565 for ; Tue, 23 Apr 2002 07:19:39 -0400 Subject: XFS Shutdown: EINVAL From: Danny Cox To: XFS Mailing List Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 23 Apr 2002 07:19:38 -0400 Message-Id: <1019560779.1143.18.camel@wiley> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mornin'! I currently have XFS installed on four machines. Last night, on the newest, I had completed the XFS/RH 7.2 install (after much gnashing of teeth, see below), and was using rsync to retrieve the copy of /home I had saved before upgrading (rsync -avcP). I tried several times, but XFS continued to shutdown on the first write attempt each time. /var/log/messages reported: xfs_inotobp: xfs_imap() returned an error 22 on ide0 (3,65). This is indeed the location of /home, on /dev/hdb1, and is a WD 400BB (40 GB Caviar). I looked briefly at the code, and xfs_imap() only has one point that could return an error, on an error return from xfs_dilocate(). 22 is EINVAL, which seems to say that xfs_dilocate doesn't like one or more of it's input args. So, that's the low-level insight. What's it mean at the high level? Note: previously, I was having great difficulty with this installation, because I have one of the motherboards (DFI AK75-EC) which can't handle the Athlon specific mmx_clear_page() and mmx_copy_page(). It was oopsing all over the place. I recompiled the kernel for i686 (see the RH 7.2 release notes), and it seemed fine. In 20/20 retrospect, I see that perhaps I should have blown away /home with mkfs.xfs, and started rsync over, as all bets are off. Sorry, it was late, and I wasn't thinking as clearly as I am now . Thoughts? Confirmations? Denials? Opinions? Thanks! -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny From owner-linux-xfs@oss.sgi.com Tue Apr 23 05:00: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 g3NC0owJ008477 for ; Tue, 23 Apr 2002 05:00:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NC0orW008476 for linux-xfs-outgoing; Tue, 23 Apr 2002 05:00: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 g3NC0gwJ008443 for ; Tue, 23 Apr 2002 05:00:43 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id HAA02678; Tue, 23 Apr 2002 07:00:58 -0500 (CDT) Received: from [192.168.1.102] (cf-vpn-sw-corp-64-22.corp.sgi.com [134.15.64.22]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA88268; Tue, 23 Apr 2002 07:00:57 -0500 (CDT) Subject: Re: XFS Shutdown: EINVAL From: Stephen Lord To: Danny Cox Cc: XFS Mailing List In-Reply-To: <1019560779.1143.18.camel@wiley> References: <1019560779.1143.18.camel@wiley> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 23 Apr 2002 06:54:22 -0500 Message-Id: <1019562863.2109.3.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-23 at 06:19, Danny Cox wrote: > Mornin'! > > I currently have XFS installed on four machines. Last night, on the > newest, I had completed the XFS/RH 7.2 install (after much gnashing of > teeth, see below), and was using rsync to retrieve the copy of /home I > had saved before upgrading (rsync -avcP). I tried several times, but > XFS continued to shutdown on the first write attempt each time. > /var/log/messages reported: > > xfs_inotobp: xfs_imap() returned an error 22 on ide0 (3,65). > > This is indeed the location of /home, on /dev/hdb1, and is a WD 400BB > (40 GB Caviar). I looked briefly at the code, and xfs_imap() only has > one point that could return an error, on an error return from > xfs_dilocate(). 22 is EINVAL, which seems to say that xfs_dilocate > doesn't like one or more of it's input args. So, that's the low-level > insight. What's it mean at the high level? I suspect it means a bad inode number in a directory, try running xfs_check on the filesystem, and xfs_repair -n, or xfs_repair if you just want to go ahead and attempt to fix it. The oopses you experienced could be the cause of this. Steve > > Note: previously, I was having great difficulty with this installation, > because I have one of the motherboards (DFI AK75-EC) which can't handle > the Athlon specific mmx_clear_page() and mmx_copy_page(). It was > oopsing all over the place. I recompiled the kernel for i686 (see the > RH 7.2 release notes), and it seemed fine. In 20/20 retrospect, I see > that perhaps I should have blown away /home with mkfs.xfs, and started > rsync over, as all bets are off. Sorry, it was late, and I wasn't > thinking as clearly as I am now . > > Thoughts? Confirmations? Denials? Opinions? > > Thanks! > > -- > kernel, n.: A part of an operating system that preserves the > medieval traditions of sorcery and black art. > > Danny From owner-linux-xfs@oss.sgi.com Tue Apr 23 06:33:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NDX8wJ009589 for ; Tue, 23 Apr 2002 06:33:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NDX8Ka009588 for linux-xfs-outgoing; Tue, 23 Apr 2002 06:33:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NDX2wJ009562 for ; Tue, 23 Apr 2002 06:33:03 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA03227; Tue, 23 Apr 2002 08:33:19 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA85082; Tue, 23 Apr 2002 08:33:18 -0500 (CDT) Date: Tue, 23 Apr 2002 08:33:18 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mike Burger cc: linux-xfs@oss.sgi.com Subject: Re: /dev/null coming up as chmod 600 at boot? 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 Mike - On Tue, 23 Apr 2002, Mike Burger wrote: > I noticed something odd once I started using the latest 2.4.9-31 kernel > with XFS 1.1, and removed the 2.4.14 XFS 1.0.2 kernel that I had installed > (as an additional kernel...I just don't know if there's any correlation > between removing it and what's happening). > > When I boot up, I've found that /dev/null is chmod 600 (rw-------). Any chance you're using devfs? I don't know what /dev/null defaults to, but if you're using devfs, that might explain the permission change not sticking? I have one of the 2.4.9-31-XFS prereleases running on my workstation, and /dev/null permissions are fine. -Eric -- 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 23 06:40: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 g3NDerwJ009779 for ; Tue, 23 Apr 2002 06:40:53 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NDerRD009778 for linux-xfs-outgoing; Tue, 23 Apr 2002 06:40:53 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from burgers.bubbanfriends.org (IDENT:postfix@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NDemwJ009752 for ; Tue, 23 Apr 2002 06:40:48 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 9C795401A40; Tue, 23 Apr 2002 09:41:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 8EFA5C0393F; Tue, 23 Apr 2002 09:41:22 -0400 (EDT) Date: Tue, 23 Apr 2002 09:41:22 -0400 (EDT) From: Mike Burger To: Seth Mos Cc: linux-xfs@oss.sgi.com Subject: Re: /dev/null coming up as chmod 600 at boot? In-Reply-To: <4.3.2.7.2.20020423104241.035c73f8@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 23 Apr 2002, Seth Mos wrote: > At 04:28 23-4-2002 -0400, Mike Burger wrote: > >I noticed something odd once I started using the latest 2.4.9-31 kernel > >with XFS 1.1, and removed the 2.4.14 XFS 1.0.2 kernel that I had installed > >(as an additional kernel...I just don't know if there's any correlation > >between removing it and what's happening). > > There might very well be one. > > >When I boot up, I've found that /dev/null is chmod 600 (rw-------). > > I have XFS 1.1 here but I didn't install it using the RPM. I built from the > kernel-source rpm and installed it from there. > > The /dev/null on this box still has 666 so I reckon that the file got > touched somewhere in the process of upgrading. > > You should be able to chmod the file and the permission should stick. I thought so, too, but I just rebooted, this morning, and the permissions were back to 600. From owner-linux-xfs@oss.sgi.com Tue Apr 23 06:43:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NDhJwJ009946 for ; Tue, 23 Apr 2002 06:43:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NDhI7k009945 for linux-xfs-outgoing; Tue, 23 Apr 2002 06:43:18 -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 g3NDhDwJ009918 for ; Tue, 23 Apr 2002 06:43:14 -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 g3NDh2m07698; Tue, 23 Apr 2002 08:43:02 -0500 Content-Type: text/plain; charset="iso-8859-1" From: Jason Joines To: XFS Users Subject: Re: OT: ISO images for Suse Date: Tue, 23 Apr 2002 08:43:02 -0500 X-Mailer: KMail [version 1.4] References: <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> <200204221128.01746.joines@joines.okstate.edu> <20020423123737.GH9561@fruit.eu.org> In-Reply-To: <20020423123737.GH9561@fruit.eu.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204230843.02042.joines@joines.okstate.edu> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tuesday 23 April 2002 07:37, Wessel Dankers wrote: > On 2002-04-22 11:28:01-0500, Jason Joines wrote: > > Also, once someone gets the CDs, you are free to make ISOs and > > redistribute them as long as you don't charge for it. > > Actually, assuming the GPL here, you only have to supply the source > code for free (and license it for free). Common misconception :) > > Of course, if SuSE licensed it differently, that won't hold. But you > would be allowed to sell at least the GPL bits. My information came from SuSE, not from reading the license. They said it was fine to redistribute ISOs of their distribution as long as you didn't charge for it. If you did, you had to pay them a licensing fee. Jason Joines ------------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Apr 23 06:52: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 g3NDqSwJ010206 for ; Tue, 23 Apr 2002 06:52:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NDqSPc010205 for linux-xfs-outgoing; Tue, 23 Apr 2002 06:52:28 -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@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NDqMwJ010179 for ; Tue, 23 Apr 2002 06:52:22 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id E5AAD401A40; Tue, 23 Apr 2002 09:46:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id CCFB6C0393F; Tue, 23 Apr 2002 09:46:54 -0400 (EDT) Date: Tue, 23 Apr 2002 09:46:54 -0400 (EDT) From: Mike Burger To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: /dev/null coming up as chmod 600 at boot? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 23 Apr 2002, Eric Sandeen wrote: > Hi Mike - > > On Tue, 23 Apr 2002, Mike Burger wrote: > > > I noticed something odd once I started using the latest 2.4.9-31 kernel > > with XFS 1.1, and removed the 2.4.14 XFS 1.0.2 kernel that I had installed > > (as an additional kernel...I just don't know if there's any correlation > > between removing it and what's happening). > > > > When I boot up, I've found that /dev/null is chmod 600 (rw-------). > > Any chance you're using devfs? I don't know what /dev/null defaults to, > but if you're using devfs, that might explain the permission change not > sticking? > > I have one of the 2.4.9-31-XFS prereleases running on my workstation, > and /dev/null permissions are fine. I thought about devfs, too, but rpm -q devfs came up with nothing. On the off chance, just now, I decided to "rpm -qa | grep devfs" and it came up with devfsd-1.3.11-sgi. I'm not showing any processes, though, with "devfs" in the name. I guess I can rpm -e devfsd and see if that helps. I suppose devfsd was installed when I did the RH7.1 + SGI installation. From owner-linux-xfs@oss.sgi.com Tue Apr 23 07:05:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NE5BwJ011639 for ; Tue, 23 Apr 2002 07:05:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NE5BNX011638 for linux-xfs-outgoing; Tue, 23 Apr 2002 07:05:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from camillo.lissone.redix.it (DatapointVim-gw.customer.ALTER.NET [146.188.57.46]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NE56wJ011612 for ; Tue, 23 Apr 2002 07:05:06 -0700 Received: (qmail 1796 invoked from network); 23 Apr 2002 14:07:17 -0000 Received: from localhost (HELO camillo) (roby@127.0.0.1) by localhost with SMTP; 23 Apr 2002 14:07:17 -0000 Date: Tue, 23 Apr 2002 16:07:16 +0200 From: Roberto To: linux-xfs@oss.sgi.com Subject: XFS 1.1 and LVM Message-ID: <20510000.1019570836@camillo> X-Mailer: Mulberry/2.1.2 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, I'm running Slack 8+ kernel 2.4.14 + XFS 1.0.1 + LVM 1.0.1-rc4. Now I want to use XFS 1.1 but I'd like to know what version of LVM is required/suggested. May be LVM 1.0.1rc4 included with kernel 2.4.18 or I can use the current 1.0.3? Anyway XFS+LVM is it stable according to your experience? Bye Roby From owner-linux-xfs@oss.sgi.com Tue Apr 23 07:30: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 g3NEUDwJ019457 for ; Tue, 23 Apr 2002 07:30:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NEUCMs019456 for linux-xfs-outgoing; Tue, 23 Apr 2002 07:30:12 -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 g3NEU6wJ019429 for ; Tue, 23 Apr 2002 07:30:07 -0700 Received: from pyewacket.nic.uklinux.net (host213-122-176-2.in-addr.btopenworld.com [213.122.176.2]) (authenticated) by s1.uklinux.net (8.11.6/8.11.6) with ESMTP id g3NEULd25951; Tue, 23 Apr 2002 15:30:21 +0100 Envelope-To: linux-xfs@oss.sgi.com Received: from nic by pyewacket.nic.uklinux.net with local (Exim 3.34 #1) id 1701IO-0002og-00; Tue, 23 Apr 2002 15:29:28 +0100 Subject: Re: /dev/null coming up as chmod 600 at boot? From: Nic Doye To: Mike Burger Cc: XFS In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.1 (1.0.1-2) Date: 23 Apr 2002 15:29:28 +0100 Message-Id: <1019572168.2185.130.camel@pyewacket> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-23 at 14:46, Mike Burger wrote: > I thought about devfs, too, but rpm -q devfs came up with nothing. > > On the off chance, just now, I decided to "rpm -qa | grep devfs" and it > came up with devfsd-1.3.11-sgi. > > I'm not showing any processes, though, with "devfs" in the name. > > I guess I can rpm -e devfsd and see if that helps. I suppose devfsd was > installed when I did the RH7.1 + SGI installation. pyewacket Red Hat 7.2 athlon $ rpm -q devfsd devfsd-1.3.18-nic_4 pyewacket Red Hat 7.2 athlon $ df /dev Filesystem 1k-blocks Used Available Use% Mounted on devfs 0 0 0 - /dev pyewacket Red Hat 7.2 athlon $ ps -deaf | grep devfs root 14 1 0 09:19 ? 00:00:00 /sbin/devfsd /dev nic 10811 10736 0 15:24 pts/1 00:00:00 grep devfs I suspect if ps isn't showing devfsd as running, I guess you'll be OK, but switching between devfs and non-devfs can be a non-trivial operation. (ie. your machine may not boot correctly). So I'd check by doing running 'mount' (or 'df') just in case. nic From owner-linux-xfs@oss.sgi.com Tue Apr 23 07:31: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 g3NEVSwJ019632 for ; Tue, 23 Apr 2002 07:31:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NEVSqN019631 for linux-xfs-outgoing; Tue, 23 Apr 2002 07:31:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lucy.ulatina.ac.cr (lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NEVDwJ019556 for ; Tue, 23 Apr 2002 07:31:18 -0700 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g3NEOxM00930; Tue, 23 Apr 2002 08:24:59 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: /dev/null coming up as chmod 600 at boot? From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 23 Apr 2002 08:24:58 -0600 Message-Id: <1019571898.801.4.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > I thought so, too, but I just rebooted, this morning, and the permissions > were back to 600. A nasty little chmod hanging arround in the init scripts? -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Tue Apr 23 07:31:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NEVlwJ019694 for ; Tue, 23 Apr 2002 07:31:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NEVloS019693 for linux-xfs-outgoing; Tue, 23 Apr 2002 07:31:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NEVfwJ019659 for ; Tue, 23 Apr 2002 07:31:42 -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 JAA04102; Tue, 23 Apr 2002 09:31: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 JAA97809; Tue, 23 Apr 2002 09:31:58 -0500 (CDT) Date: Tue, 23 Apr 2002 09:31:58 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Roberto cc: linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 and LVM In-Reply-To: <20510000.1019570836@camillo> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk There have been various problems with XFS + LVM, but we've gotten them ironed out as they are discovered. I would suggest using the latest LVM (1.0.3) with XFS; previous versions caused stack overflows when used with XFS. OTOH, if you've had good luck with LVM 1.0.1-rc4 in the past, it would probably be no worse with XFS 1.1. -Eric On Tue, 23 Apr 2002, Roberto wrote: > > Hi, > > I'm running Slack 8+ kernel 2.4.14 + XFS 1.0.1 + LVM 1.0.1-rc4. > > Now I want to use XFS 1.1 but I'd like to know what version of LVM is > required/suggested. > May be LVM 1.0.1rc4 included with kernel 2.4.18 or I can use the current > 1.0.3? > Anyway XFS+LVM is it stable according to your experience? > > Bye Roby > -- 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 23 07:46: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 g3NEkwwJ023491 for ; Tue, 23 Apr 2002 07:46:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NEkwqp023490 for linux-xfs-outgoing; Tue, 23 Apr 2002 07:46:58 -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 g3NEkqwJ023464 for ; Tue, 23 Apr 2002 07:46:52 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 085A627FDE; Wed, 24 Apr 2002 00:47:06 +1000 (EST) Date: Wed, 24 Apr 2002 00:47:06 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: xfsdump query Message-ID: <20020423144706.GA13525@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, just a few queries about xfsdump. 1. does it back up ACL's, or will I need to back them up separately? 2. does it support incremental backups to a file on disk? ie: xfsdump -l 0 -f /mnt/backup/var_dump /var xfsudmp -l 1 -f /mnt/backup/var_dump /var This fails, with: xfsdump: ERROR: media contains valid xfsdump but does not support append Obviously, /mnt/backup is a local hard disk. Is there anyway to get around this, or should I look to the tar command for my needs? 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 Tue Apr 23 07:54:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NEs8wJ026246 for ; Tue, 23 Apr 2002 07:54:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NEs85C026245 for linux-xfs-outgoing; Tue, 23 Apr 2002 07:54:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail-gw.select-tech.si (ned.select-tech.si [193.77.122.2]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NEs3wJ026217 for ; Tue, 23 Apr 2002 07:54:04 -0700 Received: from stsrv.select-tech.si (stsrv.select-tech.si [193.77.112.44]) by mail-gw.select-tech.si (8.11.2/8.11.2) with ESMTP id g3NFnHJ21991 for ; Tue, 23 Apr 2002 17:49:17 +0200 Received: from navi (navi [193.77.112.21]) by stsrv.select-tech.si (8.10.0.Beta10/8.10.0.Beta10) with SMTP id g3NEsRs02797 for ; Tue, 23 Apr 2002 16:54:27 +0200 (MET DST) Date: Tue, 23 Apr 2002 16:54:14 +0200 From: Jure Pecar To: linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 and LVM Message-Id: <20020423165414.202b89e2.pegasus@telemach.net> In-Reply-To: References: <20510000.1019570836@camillo> Organization: Select Technology X-Mailer: Sylpheed version 0.7.0 (GTK+ 1.2.9; i386-redhat-linux) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 23 Apr 2002 09:31:58 -0500 (CDT) "Eric Sandeen" wrote: > There have been various problems with XFS + LVM, but we've gotten > them ironed out as they are discovered. I would suggest using > the latest LVM (1.0.3) with XFS; previous versions caused stack > overflows when used with XFS. > > OTOH, if you've had good luck with LVM 1.0.1-rc4 in the past, it > would probably be no worse with XFS 1.1. > > -Eric Has anyone tried it with IBM's evms? -- Jure Pecar From owner-linux-xfs@oss.sgi.com Tue Apr 23 08:13:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NFDewJ026675 for ; Tue, 23 Apr 2002 08:13:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NFDZm0026674 for linux-xfs-outgoing; Tue, 23 Apr 2002 08:13:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NFDSwJ026648 for ; Tue, 23 Apr 2002 08:13:29 -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 KAA61809; Tue, 23 Apr 2002 10:13:45 -0500 (CDT) Received: from sgi.com (NBh3x0nqN7PSyZjgcPPnVCeHdXjrF2oi@cf-vpn-sw-corp-64-45.corp.sgi.com [134.15.64.45]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA03159; Tue, 23 Apr 2002 10:13:44 -0500 (CDT) Message-ID: <3CC57AC5.4010308@sgi.com> Date: Tue, 23 Apr 2002 10:16:21 -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: Jure Pecar CC: linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 and LVM References: <20510000.1019570836@camillo> <20020423165414.202b89e2.pegasus@telemach.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jure Pecar wrote: >On Tue, 23 Apr 2002 09:31:58 -0500 (CDT) >"Eric Sandeen" wrote: > >>There have been various problems with XFS + LVM, but we've gotten >>them ironed out as they are discovered. I would suggest using >>the latest LVM (1.0.3) with XFS; previous versions caused stack >>overflows when used with XFS. >> >>OTOH, if you've had good luck with LVM 1.0.1-rc4 in the past, it >>would probably be no worse with XFS 1.1. >> >>-Eric >> > > >Has anyone tried it with IBM's evms? > >-- > >Jure Pecar > We had some ioctl problem reports from mkfs which should now be fixed in EVMS 1.0. Someone else reported it was working. I have not tried myself. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 23 08:14: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 g3NFESwJ026746 for ; Tue, 23 Apr 2002 08:14:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NFESjs026745 for linux-xfs-outgoing; Tue, 23 Apr 2002 08:14:28 -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 g3NFELwJ026718 for ; Tue, 23 Apr 2002 08:14:22 -0700 Message-Id: <200204231514.g3NFELwJ026718@oss.sgi.com> Received: from there ([144.135.24.87]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw Feb 26 2002 03:44:21) with SMTP id GV110C00.8YQ; Wed, 24 Apr 2002 01:14:36 +1000 Received: from CPE-144-137-129-242.qld.bigpond.net.au ([144.137.129.242]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V3.0l 62/584808); 24 Apr 2002 01:14:36 Content-Type: text/plain; charset="us-ascii" From: Adrian Head To: Roberto , linux-xfs@oss.sgi.com Subject: Re: XFS 1.1 and LVM Date: Wed, 24 Apr 2002 01:14:32 +1000 X-Mailer: KMail [version 1.3.1] References: <20510000.1019570836@camillo> In-Reply-To: <20510000.1019570836@camillo> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Apr 2002 00:07, Roberto wrote: > I'm running Slack 8+ kernel 2.4.14 + XFS 1.0.1 + LVM 1.0.1-rc4. > > Now I want to use XFS 1.1 but I'd like to know what version of LVM is > required/suggested. > May be LVM 1.0.1rc4 included with kernel 2.4.18 or I can use the current > 1.0.3? > Anyway XFS+LVM is it stable according to your experience? I would recommend lvm-1.0.3 for the moment. There have been heaps of fixes gone into it since lvm-1.0.1rc4. I believe that the 2.4.19 kernel when it is released will contain lvm-1.0.3. The biggest problem with LVM and XFS was with snapshots and co-existing with other filesystems. If you are only running XFS and are not using snapshots then you could be lucky. >From personal experience I have a very stable kernel running XFS CVS & lvm-1.1rc1 as it is one of the first XFS & LVM combinations that have passed all my tests. But as lvm-1.1rc1 is very beta I would strongly not recommend this to anyone for production machines. -- Adrian Head (Public Key available on request.) From owner-linux-xfs@oss.sgi.com Tue Apr 23 09:18:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NGImwJ024795 for ; Tue, 23 Apr 2002 09:18:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NGIm9b024794 for linux-xfs-outgoing; Tue, 23 Apr 2002 09:18:48 -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@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NGIiwJ024768 for ; Tue, 23 Apr 2002 09:18:45 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 01FDB401A40; Tue, 23 Apr 2002 12:19:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id CBCCEC0393F; Tue, 23 Apr 2002 12:19:04 -0400 (EDT) Date: Tue, 23 Apr 2002 12:19:04 -0400 (EDT) From: Mike Burger To: Alvaro Figueroa Cc: XFS to linux port mailing list Subject: Re: /dev/null coming up as chmod 600 at boot? In-Reply-To: <1019571898.801.4.camel@lucy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thought of that, but grep didn't find any chmod in anything. On 23 Apr 2002, Alvaro Figueroa wrote: > > I thought so, too, but I just rebooted, this morning, and the permissions > > were back to 600. > > A nasty little chmod hanging arround in the init scripts? > > From owner-linux-xfs@oss.sgi.com Tue Apr 23 09:21: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 g3NGLdwJ024941 for ; Tue, 23 Apr 2002 09:21:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NGLdtS024939 for linux-xfs-outgoing; Tue, 23 Apr 2002 09:21:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fs1.theiqgroup.com (fs1.theiqgroup.com [216.81.249.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NGLWwJ024910 for ; Tue, 23 Apr 2002 09:21:32 -0700 Received: from theiqgroup.com (funkmotor.theiqgroup.com [216.81.249.31] (may be forged)) by fs1.theiqgroup.com (8.12.2/8.12.2) with ESMTP id g3NGLeft013410; Tue, 23 Apr 2002 11:21:40 -0500 Message-ID: <3CC58A0D.7010100@theiqgroup.com> Date: Tue, 23 Apr 2002 11:21:33 -0500 From: Kelly Corbin Organization: The IQ Group, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Roberto , Linux XFS Subject: Re: XFS 1.1 and LVM References: <20510000.1019570836@camillo> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I use Slack 8, 2.4.16, XFS 1.1, and LVM 1.0.1 on medium-duty production machines with 0 problems. I don't use any of the more esoteric features of either XFS or LVM, but I've had no real problems or crashes. Seems quite stable to me. Kelly Roberto wrote: > > Hi, > > I'm running Slack 8+ kernel 2.4.14 + XFS 1.0.1 + LVM 1.0.1-rc4. > > Now I want to use XFS 1.1 but I'd like to know what version of LVM is > required/suggested. > May be LVM 1.0.1rc4 included with kernel 2.4.18 or I can use the current > 1.0.3? > Anyway XFS+LVM is it stable according to your experience? > > Bye Roby > > -- -------------------------------------------- -- Kelly Corbin -- Systems Administrator -- -- http://www.theiqgroup.com -- The Future of eServices... -- -- The IQ Group, Inc. -- 6740 Antioch Suite 110 -- Merriam, KS 66204 -- (913)-722-6700 x105 -- Fax (913)722-7264 -------------------------------------------- From owner-linux-xfs@oss.sgi.com Tue Apr 23 09:35:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NGZfwJ025317 for ; Tue, 23 Apr 2002 09:35:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NGZeQM025316 for linux-xfs-outgoing; Tue, 23 Apr 2002 09:35:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NGZRwJ025289 for ; Tue, 23 Apr 2002 09:35:28 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g3NGZks02772; Tue, 23 Apr 2002 18:35:46 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15557.36194.760672.792045@slime.wu-wien.ac.at> Date: Tue, 23 Apr 2002 18:35:46 +0200 To: linux-xfs@oss.sgi.com Subject: corrupt xfs filesystem -- xfs_repair dumps core X-Mailer: VM 7.03 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! We have the following problem with a fileserver in one of our departments. Distribution: RedHat-7.1 Kernel: # cat /proc/version Linux version 2.4.3-SGI_XFS_1.0.1 (root@linux-xfs2.americas.sgi.com) \ (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) \ #1 Mon Jul 9 14:27:56 CDT 2001 Now upgraded to: # cat /proc/version Linux version 2.4.9-31SGI_XFS_1.1 (root@permit) \ (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) \ #1 Wed Apr 17 12:21:35 CDT 2002 BTW, the xfs filesystem lives on /dev/sdb (an unpartitioned scsi disk -- i didn't know that this is possible, but my colleage said, that it has worked until now). The problems began with disappearing directories. We tried a xfs_repair (1.2.8), but without luck. Unfortunatly, my colleague hasn't saved the output from that run. Then, we upgraded the xfsprogs to 2.0.3, an now we get a core dump: # /sbin/xfs_repair /dev/sdb Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion `start_blk != 0 || *last_blk != start_blk' failed. Aborted (core dumped) Should this happen? The Kernel Upgrade from 2.4.3-SGI_XFS_1.0.1 to 2.4.9-31SGI_XFS_1.1 made no difference. When we try the -n flag to xfs_repair, we get a more promising output: # /sbin/xfs_repair -n /dev/sdb Phase 1 - find and verify superblock... Phase 2 - using internal log - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan (but don't clear) agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 [...agno 3-1998...] - agno = 1999 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 inode block 8 multiply claimed, state was 4 inode block 9 multiply claimed, state was 4 inode block 10 multiply claimed, state was 4 inode block 11 multiply claimed, state was 4 - agno = 1 - agno = 2 [...agno 3-1998...] - agno = 1999 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. Needless to say, that there very important data on the filesystem, and that we have no backup! Is there any chance, to get the data back? Anybody out there, who can help? Any hints are highly appreciated! (and please let me know, if i should provide other information) Thank You, \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Tue Apr 23 09:40:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NGebwJ027030 for ; Tue, 23 Apr 2002 09:40:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NGebrq027029 for linux-xfs-outgoing; Tue, 23 Apr 2002 09:40:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NGeWwJ027002 for ; Tue, 23 Apr 2002 09:40:33 -0700 Received: from offline.mpc.local ([172.16.20.7] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 3.16 #1) id 1703LQ-0007uH-00; Tue, 23 Apr 2002 17:40:45 +0100 Message-ID: <3CC58E8C.B513B7C9@moving-picture.com> Date: Tue, 23 Apr 2002 17:40:44 +0100 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: Mike Burger CC: linux-xfs@oss.sgi.com Subject: Re: /dev/null coming up as chmod 600 at boot? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mike Burger wrote: > > Thought of that, but grep didn't find any chmod in anything. > > On 23 Apr 2002, Alvaro Figueroa wrote: > > > > I thought so, too, but I just rebooted, this morning, and the permissions > > > were back to 600. > > > > A nasty little chmod hanging arround in the init scripts? > > Anything in /etc/security/console.perms that changes /dev/null ?? James Pearson From owner-linux-xfs@oss.sgi.com Tue Apr 23 09:58:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NGwGwJ028029 for ; Tue, 23 Apr 2002 09:58:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NGwGKo028028 for linux-xfs-outgoing; Tue, 23 Apr 2002 09:58:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from maddux.wayfarer.org (rdu25-14-014.nc.rr.com [24.25.14.14]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NGwBwJ028002 for ; Tue, 23 Apr 2002 09:58:12 -0700 Received: (qmail 1893 invoked by uid 401); 23 Apr 2002 16:58:30 -0000 Received: from localhost (HELO linux-lovelace.internal.opennms.org) (lovelace@127.0.0.1) by localhost with SMTP; 23 Apr 2002 16:58:30 -0000 Subject: Re: /dev/null coming up as chmod 600 at boot? From: Tanner Lovelace To: XFS to linux port mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3-1mdk Date: 23 Apr 2002 12:58:26 -0400 Message-Id: <1019581107.26464.92.camel@linux-lovelace.internal.opennms.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-23 at 12:19, Mike Burger wrote: > Thought of that, but grep didn't find any chmod in anything. If you have any reason to suspect devfs is running, try looking in /lib/dev-state (which is the directory that get's copied to /dev, at least on my Mandrake 8.2 box). Also, you might look at /etc/devfsd.conf or /etc/devfs/..., but I doubt you'll find anything there. Tanner Lovelace -- Tanner Lovelace | lovelace@wayfarer.org | http://wtl.wayfarer.org/ --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-- GPG Fingerprint = A66C 8660 924F 5F8C 71DA BDD0 CE09 4F8E DE76 39D4 GPG Key can be found at http://wtl.wayfarer.org/lovelace.gpg.asc --*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*--*-- This would be a very good time to hang out with the Open Source people, before they get formally reclassified as a national security threat. -- Bruce Sterling From owner-linux-xfs@oss.sgi.com Tue Apr 23 10:01: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 g3NH1wwJ028239 for ; Tue, 23 Apr 2002 10:01:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NH1wCo028238 for linux-xfs-outgoing; Tue, 23 Apr 2002 10:01:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from c000.snv.cp.net (h000.c000.snv.cp.net [209.228.32.64]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NH1pwJ028210 for ; Tue, 23 Apr 2002 10:01:51 -0700 Received: (cpmta 24468 invoked from network); 23 Apr 2002 10:02:08 -0700 Received: from 207.207.51.226 (HELO itspec.amoa.org) by smtp.tooley.com (209.228.32.64) with SMTP; 23 Apr 2002 10:02:08 -0700 X-Sent: 23 Apr 2002 17:02:08 GMT Subject: Re: Can't get samba 2.2.3a to compile with ACL support (with logs) From: Chris Tooley To: Nathan Scott Cc: samba@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: <20020420100247.H22886@wobbly.melbourne.sgi.com> References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 23 Apr 2002 12:02:44 -0500 Message-Id: <1019581365.26898.9.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I did make the switch in configure from -lacl -lattr and faired no better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp kernel. checking if large file support can be enabled... yes checking whether to support ACLs... checking for acl_get_file in -lattr... no checking for ACL support... no checking whether to build winbind... yes checking configure summary configure: error: summary failure. Aborting config error: Bad exit status from /var/tmp/rpm-tmp.71265 (%build) Chris Tooley On Fri, 2002-04-19 at 19:02, Nathan Scott wrote: > 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 Tue Apr 23 10:15:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NHFkwJ028509 for ; Tue, 23 Apr 2002 10:15:46 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NHFkiV028508 for linux-xfs-outgoing; Tue, 23 Apr 2002 10:15:46 -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@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NHFgwJ028482 for ; Tue, 23 Apr 2002 10:15:43 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 751794B7EB5; Tue, 23 Apr 2002 13:16:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 737D2C0393F for ; Tue, 23 Apr 2002 13:16:05 -0400 (EDT) Date: Tue, 23 Apr 2002 13:16:05 -0400 (EDT) From: Mike Burger To: linux-xfs@oss.sgi.com Subject: Fixed? (was Re: /dev/null coming up as chmod 600 at boot?) In-Reply-To: <1019581107.26464.92.camel@linux-lovelace.internal.opennms.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Well, while devfsd wasn't necessarily running, it seems to have been a problem...at least, it was installed. I ran rpm -e devfsd, and rebooted. The permissions came up wrong, so I changed them and rebooted, again. This time, the permissions came up right. Thanks, everyone, for all the suggestions. From owner-linux-xfs@oss.sgi.com Tue Apr 23 11:58: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 g3NIwjwJ030636 for ; Tue, 23 Apr 2002 11:58:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NIwjrx030635 for linux-xfs-outgoing; Tue, 23 Apr 2002 11:58:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from juniper.intra.microsharp.com (asl.microsharp.com [206.190.130.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NIwcwJ030609 for ; Tue, 23 Apr 2002 11:58:39 -0700 Received: from juniper.intra.microsharp.com (karlheg@localhost [127.0.0.1]) by juniper.intra.microsharp.com (8.12.3/8.12.3/Debian -5) with ESMTP id g3NIx11r027778 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Tue, 23 Apr 2002 11:59:01 -0700 Received: (from karlheg@localhost) by juniper.intra.microsharp.com (8.12.3/8.12.3/Debian -5) id g3NIx0MH027776; Tue, 23 Apr 2002 11:59:00 -0700 X-Authentication-Warning: juniper.intra.microsharp.com: karlheg set sender to karlheg@microsharp.com using -f Subject: XFS and EVMS - Limited Success From: "Karl M. Hegbloom" To: linux-xfs@oss.sgi.com In-Reply-To: <3CC57AC5.4010308@sgi.com> References: <20510000.1019570836@camillo> <20020423165414.202b89e2.pegasus@telemach.net> <3CC57AC5.4010308@sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 23 Apr 2002 11:59:00 -0700 Message-Id: <1019588340.27446.23.camel@juniper.intra.microsharp.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-23 at 08:16, Stephen Lord wrote: > We had some ioctl problem reports from mkfs which should now be fixed in > EVMS 1.0. Someone else reported it was working. I have not tried myself. I am using EVMS, and see: root@juniper:~ # mkfs -t xfs /dev/evms/test mkfs.xfs: warning - cannot set blocksize on block device /dev/evms/test: Invalid argument meta-data=/dev/evms/test isize=256 agcount=8, agsize=65536 blks data = bsize=4096 blocks=524287, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=1200 realtime =none extsz=65536 blocks=0, rtextents=0 This is a 2.4.18 kernel (SMP), the evms header says it's version 1.0.0, and the evms tools are version 1.0.0. root@juniper:~ # mkfs.xfs -V mkfs.xfs version 2.0.3 Is that too old a version of mkfs.xfs? It would be a lot easier for me to see what version of XFS the kernel has built into it if you would cause the "dmesg" (printk) output at startup to give a version number. I've given up on finding what version it is after 5 minutes of code grepping, sorry. Ah... dpkg --status kernel-patch-xfs tells me that it's version "1.0.2+20020304-2". So do I need a newer one to make XFS work right with EVMS? As far as EVMS itself goes, I think it's great. I have experienced lockups when working with snapshots that I need to explore and document at some point (if I find some time). From owner-linux-xfs@oss.sgi.com Tue Apr 23 12:12: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 g3NJCYwJ030958 for ; Tue, 23 Apr 2002 12:12:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NJCYDH030957 for linux-xfs-outgoing; Tue, 23 Apr 2002 12:12: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 g3NJCRwJ030928 for ; Tue, 23 Apr 2002 12:12: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 OAA04751; Tue, 23 Apr 2002 14:12:44 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA95065; Tue, 23 Apr 2002 14:12:44 -0500 (CDT) Subject: Re: XFS and EVMS - Limited Success From: Eric Sandeen To: "Karl M. Hegbloom" Cc: linux-xfs@oss.sgi.com In-Reply-To: <1019588340.27446.23.camel@juniper.intra.microsharp.com> References: <20510000.1019570836@camillo> <20020423165414.202b89e2.pegasus@telemach.net> <3CC57AC5.4010308@sgi.com> <1019588340.27446.23.camel@juniper.intra.microsharp.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 23 Apr 2002 14:12:43 -0500 Message-Id: <1019589164.6392.4.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-23 at 13:59, Karl M. Hegbloom wrote: > On Tue, 2002-04-23 at 08:16, Stephen Lord wrote: > > > We had some ioctl problem reports from mkfs which should now be fixed in > > EVMS 1.0. Someone else reported it was working. I have not tried myself. > > I am using EVMS, and see: > > root@juniper:~ > # mkfs -t xfs /dev/evms/test > mkfs.xfs: warning - cannot set blocksize on block device /dev/evms/test: > Invalid argument That's not really a problem. It just means that the BLKSETSZ ioctl is not supported by evms; for now, anyway, xfs can live without it. > It would be a lot easier for me > to see what version of XFS the kernel has built into it if you would > cause the "dmesg" (printk) output at startup to give a version number. Well, there are 2 flavors of XFS - releases, and cvs snapshots (this includes any patch you find on oss.sgi.com that's NOT under a "Release-X" directory.) It would have been a good idea to hard code a release version into the releases, yes. Sorry about that. > I've given up on finding what version it is after 5 minutes of code > grepping, sorry. Ah... dpkg --status kernel-patch-xfs tells me that > it's version "1.0.2+20020304-2". So do I need a newer one to make XFS > work right with EVMS? Sounds like you got it from debian, then - and I guess they got it from release 1.0.2, and maybe tweaked it a bit? I would suggest getting patches + userspace from under the Release-1.1, if you're looking for a set of things that are known to work well together. However, there isn't anything inherently wrong with the combination you have now. -Eric -- 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 23 12:44:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NJiKwJ031545 for ; Tue, 23 Apr 2002 12:44:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NJiKgN031544 for linux-xfs-outgoing; Tue, 23 Apr 2002 12:44:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.trustium.com (adsl-64-165-6-11.dsl.sndg02.pacbell.net [64.165.6.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NJiAwJ031516 for ; Tue, 23 Apr 2002 12:44:10 -0700 Received: by adsl-64-165-6-11.dsl.sndg02.pacbell.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 12:36:48 -0700 Message-ID: <44D5677E9B8478468DE31AE26DF0AFD6077C87@adsl-64-165-6-11.dsl.sndg02.pacbell.net> From: Adam Milazzo To: "'linux-xfs@oss.sgi.com'" Subject: low-level XFS drive recovery Date: Tue, 23 Apr 2002 12:36:40 -0700 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 In a bout of impatient, early-morning foolishness, while trying to quickly "format" /dev/hda1 (mounted under /mnt), I did an 'rm -rf /*' from a chroot'd shell, but didn't realize until I pressed Enter, that I had /dev/hdb1 mounted. However, it was too late, as the second drive was nearly instantly wiped clean, taking with it all my important stuff! So I went to bed. I learned a few lessons, like making better use of 'mount -o ro'. However, the damage was already done and I am trying to restore the data on that drive. I know that the XFS FAQ claims that there's no way to undelete, and that's understandable. However, I might be in luck in this case. The drive was freshly formatted and had a number of large files copied to it from another drive, and no writing/deleting was done after that point (except when it was deleted by rm -rf). Also, no writing has been done since the deletion. My hope is that the files are [still] in contiguous blocks on the disk. My first question is: How likely is it that after writing some (rather large, 100 meg average, but up to 700 meg) files to a freshly formatted XFS partition, that they would be in contiguous blocks? Second: after the rm -rf /* recursed into that drive's mount point and did it's dirty work, is there anything left of the directory structure? Or was that all wiped out? I dumped the first 8 gigs of the drive to a file on another drive, and am writing a program to scan that dump file and attempt to pull out anything that looks like a data file (basically by scanning for valid file headers). However, it's slow work, and is almost useless if the files are not stored in a single contiguous blocks (hence my first question). Also, if there's anything left of the directory structure that I could use to find where files begin and the filename, that would be very helpful. Perhaps it's relatively trivial to restore the entire drive just by rebuilding the directory structure, given the special circumstances of my situation. Or perhaps the entire thing would be extremely difficult because the files are broken up. So, if anybody could provide some information that would be helpful, and/or point me to some good information on the low-level details of the filesystem structure that might be useful in aiding my recovery of the data (or giving me enough information that I can deem it pointless without going through all the work), it would be greatly appreciated. Also, does anybody know of a good hex editor (or sector editor)? I'm looking for the following features (In decreasing order of importance): * Fast searching of text and binary data * Ability to open huge files (>2gb) * A display of the word, dword, and maybe quadword value that begins at the byte under the cursor. * Ability to select a chunk of data and save it to a disk (directly, or in a round-about way) * A built-in calculator? curses-based would be okay, but something for gnome/X would be nice. Thanks a lot in advance! Adam M. From owner-linux-xfs@oss.sgi.com Tue Apr 23 13:20: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 g3NKKCwJ032127 for ; Tue, 23 Apr 2002 13:20:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NKKCFS032126 for linux-xfs-outgoing; Tue, 23 Apr 2002 13:20:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NKK6wJ032099 for ; Tue, 23 Apr 2002 13:20:07 -0700 Received: (qmail 3852 invoked by uid 0); 23 Apr 2002 20:20:23 -0000 Received: from b1f4b.pppool.de (HELO gmx.de) (213.7.31.75) by mail.gmx.net (mp011-rz3) with SMTP; 23 Apr 2002 20:20:23 -0000 Message-ID: <3CC5C1EE.F4B7388B@gmx.de> Date: Tue, 23 Apr 2002 22:19:58 +0200 From: Martin Stricker Organization: http://martin-stricker.de/ http://www.surfo.net/ http://www.masterportal24.com/cgi-bin/YaBB.cgi X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: OT: ISO images for Suse References: <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> <200204221128.01746.joines@joines.okstate.edu> <20020423123737.GH9561@fruit.eu.org> <200204230843.02042.joines@joines.okstate.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jason Joines wrote: > My information came from SuSE, not from reading the license. > They said it was fine to redistribute ISOs of their distribution as > long as you didn't charge for it. If you did, you had to pay them a > licensing fee. That's legally correct. S.u.S.E. uses *lots* of proprietary software on their distribution, amongst them their installer/configuration tools. If you use S.u.SW.E. Linux you'll find out many things are not where there are supposed to be... Red Hat release all their tools under the GPL. Guess which distribution I prefer... Best regards, Martin Stricker -- Homepage: http://www.martin-stricker.de/ Webmaster-Forum: http://www.masterportal24.com/cgi-bin/YaBB.cgi Red Hat Linux 7.2 for low memory: http://www.rule-project.org/rule/ Registered Linux user #210635: http://counter.li.org/ From owner-linux-xfs@oss.sgi.com Tue Apr 23 13:37:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NKbKwJ032696 for ; Tue, 23 Apr 2002 13:37:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NKbKdD032695 for linux-xfs-outgoing; Tue, 23 Apr 2002 13:37:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NKbDwJ032659 for ; Tue, 23 Apr 2002 13:37:13 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA09519; Tue, 23 Apr 2002 15:37:31 -0500 (CDT) Received: from sgi.com (w19yePhGoZUeY0ePGNGBDYwrjxWQQEFu@cf-vpn-sw-corp-64-45.corp.sgi.com [134.15.64.45]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id PAA34777; Tue, 23 Apr 2002 15:37:30 -0500 (CDT) Message-ID: <3CC5C6A5.3070104@sgi.com> Date: Tue, 23 Apr 2002 15:40:05 -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: Martin Stricker CC: linux-xfs@oss.sgi.com Subject: Re: OT: ISO images for Suse References: <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> <200204221128.01746.joines@joines.okstate.edu> <20020423123737.GH9561@fruit.eu.org> <200204230843.02042.joines@joines.okstate.edu> <3CC5C1EE.F4B7388B@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Martin Stricker wrote: >Jason Joines wrote: > >> My information came from SuSE, not from reading the license. >>They said it was fine to redistribute ISOs of their distribution as >>long as you didn't charge for it. If you did, you had to pay them a >>licensing fee. >> > >That's legally correct. S.u.S.E. uses *lots* of proprietary software on >their distribution, amongst them their installer/configuration tools. If >you use S.u.SW.E. Linux you'll find out many things are not where there >are supposed to be... > >Red Hat release all their tools under the GPL. Guess which distribution >I prefer... > >Best regards, >Martin Stricker > Lets limit the discussion to filesystems, not distribution bashing please. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 23 15:28:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NMSswJ002731 for ; Tue, 23 Apr 2002 15:28:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NMSsx6002730 for linux-xfs-outgoing; Tue, 23 Apr 2002 15:28:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NMSlwJ002704 for ; Tue, 23 Apr 2002 15:28:47 -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 PAA906924 for ; Tue, 23 Apr 2002 15:29:09 -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 IAA07015; Wed, 24 Apr 2002 08:27:51 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA73566; Wed, 24 Apr 2002 08:27:49 +1000 (AEST) Date: Wed, 24 Apr 2002 08:27:48 +1000 From: Nathan Scott To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com Subject: Re: corrupt xfs filesystem -- xfs_repair dumps core Message-ID: <20020424082748.L63455@wobbly.melbourne.sgi.com> References: <15557.36194.760672.792045@slime.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15557.36194.760672.792045@slime.wu-wien.ac.at>; from wlang@wu-wien.ac.at on Tue, Apr 23, 2002 at 06:35:46PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 23, 2002 at 06:35:46PM +0200, Willi Langenberger wrote: > Hi! Hi there, > The problems began with disappearing directories. We tried a > xfs_repair (1.2.8), but without luck. Unfortunatly, my colleague > hasn't saved the output from that run. > > Then, we upgraded the xfsprogs to 2.0.3, an now we get a core dump: > > # /sbin/xfs_repair /dev/sdb > Phase 1 - find and verify superblock... > Phase 2 - using internal log > - zero log... > xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion `start_blk != 0 || *last_blk != start_blk' failed. > Aborted (core dumped) > > Should this happen? The Kernel Upgrade from 2.4.3-SGI_XFS_1.0.1 to > 2.4.9-31SGI_XFS_1.1 made no difference. Ah, I see the problem. You have an unclean log and corruption in the log which is causing the code in xfs_repair to get confused when searching for the log head/tail. First try mount, then unmount, and then run xfs_repair. The initial mount/unmount will cause the log to be replayed, if it can be. Failing that, try "xfs_repair -L /dev/sdb" which skips the check for an empty log, zeroes it, then goes ahead with repairing. Failing that (!) we can get libxlog built non-debug so this assertion doesn't get tripped, and see how we go from there. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 23 15:41:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3NMfqwJ003012 for ; Tue, 23 Apr 2002 15:41:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NMfqha003011 for linux-xfs-outgoing; Tue, 23 Apr 2002 15:41: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 g3NMflwJ002985 for ; Tue, 23 Apr 2002 15:41:47 -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 PAA1019799 for ; Tue, 23 Apr 2002 15:42:09 -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 IAA07131; Wed, 24 Apr 2002 08:40:52 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA73607; Wed, 24 Apr 2002 08:40:51 +1000 (AEST) Date: Wed, 24 Apr 2002 08:40:49 +1000 From: Nathan Scott To: Chris Tooley 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: <20020424084049.M63455@wobbly.melbourne.sgi.com> References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> <1019581365.26898.9.camel@itspec.amoa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1019581365.26898.9.camel@itspec.amoa.org>; from ctooley@amoa.org on Tue, Apr 23, 2002 at 12:02:44PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 23, 2002 at 12:02:44PM -0500, Chris Tooley wrote: > I did make the switch in configure from -lacl -lattr and faired no > better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp > kernel. > > checking if large file support can be enabled... yes > checking whether to support ACLs... checking for acl_get_file in > -lattr... no > checking for ACL support... no Your configure changes are incorrect - they're looking in the wrong library for acl_get_file (which is in libacl, not libattr), as I said earlier you need to link with both libraries. It has been pointed out that we can do a better job when building libacl so that it knows it depends on libattr (in fact this was done at one point, but was accidentally dropped from the Makefile). If you build and install the acl code from XFS CVS (have a look though cmd/acl/doc/INSTALL), you should find that Samba gets built correctly with no changes at all now. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 23 16:21: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 g3NNLUwJ003547 for ; Tue, 23 Apr 2002 16:21:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3NNLUOn003546 for linux-xfs-outgoing; Tue, 23 Apr 2002 16:21:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3NNLOwJ003520 for ; Tue, 23 Apr 2002 16:21:25 -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 QAA1086266 for ; Tue, 23 Apr 2002 16:21:29 -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 JAA07480; Wed, 24 Apr 2002 09:20:07 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA73821; Wed, 24 Apr 2002 09:20:06 +1000 (AEST) Date: Wed, 24 Apr 2002 09:20:06 +1000 From: Nathan Scott To: linux Cc: linux-xfs@oss.sgi.com Subject: Re: cmd tars Message-ID: <20020424092005.P63455@wobbly.melbourne.sgi.com> References: <200204230143150875.1F48DF92@mail.gmx.de> <20020423095225.E63455@wobbly.melbourne.sgi.com> <200204231127090170.215F7061@mail.gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200204231127090170.215F7061@mail.gmx.de>; from dahouet@gmx.net on Tue, Apr 23, 2002 at 11:27:09AM +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3NNLPwJ003521 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 23, 2002 at 11:27:09AM +0200, linux wrote: > > > Le 23/04/2002 à 09:52 Nathan Scott a écrit : > > >You probably have an older version of chacl(1) on your path > >somewhere before the new one... IIRC, this moved from /bin > >to /usr/bin (or maybe vice-versa) as part of the consolidation > >effort with the ext2 project's ACL userspace code. > > > >You can safely remove the old chacl binary, and just use the > >new one. > > exactly, i've deleted the /bin one > and it's ok > > there's nothing more to take attention ? Nope, nothing else -- sounds like its sorted out now. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Apr 23 17:29:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3O0TcwJ004191 for ; Tue, 23 Apr 2002 17:29:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3O0Tcam004190 for linux-xfs-outgoing; Tue, 23 Apr 2002 17:29:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rebel.net.au (IDENT:root@rebel.rebel.net.au [203.20.69.66]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3O0TWwJ004163 for ; Tue, 23 Apr 2002 17:29:33 -0700 Received: from rebel.net.au (dialup-2.rebel.net.au [203.20.69.72]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id JAA20729; Wed, 24 Apr 2002 09:32:27 +0930 Message-ID: <3CC6002D.3A555DC5@rebel.net.au> Date: Wed, 24 Apr 2002 10:15:33 +0930 From: David Lloyd X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-SGI_XFS_1.0 i586) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Lord CC: Martin Stricker , linux-xfs@oss.sgi.com Subject: Re: OT: ISO images for Suse References: <20020419162529.ZFRN2390.imf05bis.bellsouth.net@taz> <200204221128.01746.joines@joines.okstate.edu> <20020423123737.GH9561@fruit.eu.org> <200204230843.02042.joines@joines.okstate.edu> <3CC5C1EE.F4B7388B@gmx.de> <3CC5C6A5.3070104@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I would agree with Steve: > Lets limit the discussion to filesystems, not distribution bashing please. ...however "Suse" sounds just like a Phillipino expression having the same meaning as "Bloody Hell!" or stronger. Regardless of what you think of Suse having a reasonably well-known distribution roll XFS into it coldn't possibly be a bad thing, especially since Suse have strongly supported ReiserFS (developed by that wonderfully, charismatic and charming Han Reiser -- oh please) in the past. DSL -- 2337: Chastity means the successful integration of sexuality within the person and thus the inner unity of man in his bodily and spiritual being...[First sentence of item 2337 of the Catechism of the Catholic Church revised in accordance with the official Latin Text] From owner-linux-xfs@oss.sgi.com Tue Apr 23 20:53:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3O3rawJ007940 for ; Tue, 23 Apr 2002 20:53:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3O3raSF007939 for linux-xfs-outgoing; Tue, 23 Apr 2002 20:53:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.trustium.com (adsl-64-165-6-11.dsl.sndg02.pacbell.net [64.165.6.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3O3rLwJ007913 for ; Tue, 23 Apr 2002 20:53:21 -0700 Received: by adsl-64-165-6-11.dsl.sndg02.pacbell.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 20:46:00 -0700 Message-ID: <44D5677E9B8478468DE31AE26DF0AFD6077C92@adsl-64-165-6-11.dsl.sndg02.pacbell.net> From: Adam Milazzo To: "'linux-xfs@oss.sgi.com'" Subject: UPDATE: low-level XFS drive recovery Date: Tue, 23 Apr 2002 20:45:51 -0700 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 After running xfs_repair -n, I get some stuff that looks like this: entry "backup" in directory inode 128 points to free inode 12583040, would junk entry entry "desktop" in directory inode 128 points to free inode 16777344, would junk entry entry "t" in directory inode 128 points to free inode 33554240, would junk entry ...as well as others... These are exactly the three directories I need to recover!! However, from the look of the message, it seems like it's going to "junk" the entry, making it more difficult to recover. I'm thinking that directory inode 128 is the root directory, and the inodes mentioned are the directory inodes of those subdirectories. Is there a way (using xfs_db perhaps?) to get the inodes and/or extents of the files in those directories? Could I use this information to recover my files (note that there is important information regarding the situation in my original post, below)? I'm trying to figure out how to use xfs_db to do this... If anybody would be kind enough to give me a few instructions on this, or point me to some documentation about the format of the directory inodes (whatever I would need to get at the file extents), I would greatly appreciate it. Thanks in advance, Adam M. -----Original Message----- From: Adam Milazzo To: 'linux-xfs@oss.sgi.com' Sent: 4/23/2002 12:36 PM Subject: low-level XFS drive recovery In a bout of impatient, early-morning foolishness, while trying to quickly "format" /dev/hda1 (mounted under /mnt), I did an 'rm -rf /*' from a chroot'd shell, but didn't realize until I pressed Enter, that I had /dev/hdb1 mounted. However, it was too late, as the second drive was nearly instantly wiped clean, taking with it all my important stuff! So I went to bed. I learned a few lessons, like making better use of 'mount -o ro'. However, the damage was already done and I am trying to restore the data on that drive. I know that the XFS FAQ claims that there's no way to undelete, and that's understandable. However, I might be in luck in this case. The drive was freshly formatted and had a number of large files copied to it from another drive, and no writing/deleting was done after that point (except when it was deleted by rm -rf). Also, no writing has been done since the deletion. My hope is that the files are [still] in contiguous blocks on the disk. My first question is: How likely is it that after writing some (rather large, 100 meg average, but up to 700 meg) files to a freshly formatted XFS partition, that they would be in contiguous blocks? Second: after the rm -rf /* recursed into that drive's mount point and did it's dirty work, is there anything left of the directory structure? Or was that all wiped out? I dumped the first 8 gigs of the drive to a file on another drive, and am writing a program to scan that dump file and attempt to pull out anything that looks like a data file (basically by scanning for valid file headers). However, it's slow work, and is almost useless if the files are not stored in a single contiguous blocks (hence my first question). Also, if there's anything left of the directory structure that I could use to find where files begin and the filename, that would be very helpful. Perhaps it's relatively trivial to restore the entire drive just by rebuilding the directory structure, given the special circumstances of my situation. Or perhaps the entire thing would be extremely difficult because the files are broken up. So, if anybody could provide some information that would be helpful, and/or point me to some good information on the low-level details of the filesystem structure that might be useful in aiding my recovery of the data (or giving me enough information that I can deem it pointless without going through all the work), it would be greatly appreciated. Also, does anybody know of a good hex editor (or sector editor)? I'm looking for the following features (In decreasing order of importance): * Fast searching of text and binary data * Ability to open huge files (>2gb) * A display of the word, dword, and maybe quadword value that begins at the byte under the cursor. * Ability to select a chunk of data and save it to a disk (directly, or in a round-about way) * A built-in calculator? curses-based would be okay, but something for gnome/X would be nice. Thanks a lot in advance! Adam M. From owner-linux-xfs@oss.sgi.com Tue Apr 23 21:07:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3O47BwJ008276 for ; Tue, 23 Apr 2002 21:07:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3O47A7c008275 for linux-xfs-outgoing; Tue, 23 Apr 2002 21:07:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.trustium.com (adsl-64-165-6-11.dsl.sndg02.pacbell.net [64.165.6.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3O478wJ008249 for ; Tue, 23 Apr 2002 21:07:08 -0700 Received: by adsl-64-165-6-11.dsl.sndg02.pacbell.net with Internet Mail Service (5.5.2653.19) id ; Tue, 23 Apr 2002 20:59:40 -0700 Message-ID: <44D5677E9B8478468DE31AE26DF0AFD6077C93@adsl-64-165-6-11.dsl.sndg02.pacbell.net> From: Adam Milazzo To: "'linux-xfs@oss.sgi.com'" Subject: problems with xfs_db (seg fault) Date: Tue, 23 Apr 2002 20:59:38 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Whenever I use the 'blockget' command in xfs_db, it quits with a segmentation fault. The drive is not mounted. I have tried setting the inode and the type properly, but it still seg faults. Google isn't turning up anything... is there anything I could try to diagnose this problem? From owner-linux-xfs@oss.sgi.com Tue Apr 23 22:07:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3O57ewJ008815 for ; Tue, 23 Apr 2002 22:07:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3O57djl008814 for linux-xfs-outgoing; Tue, 23 Apr 2002 22:07:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ilanz.monex.li (ilanz.monex.li [164.128.93.104]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3O57UwJ008786 for ; Tue, 23 Apr 2002 22:07:31 -0700 Received: from spalegna.monex.li (spalegna [164.128.93.99]) by ilanz.monex.li (8.11.6/8.11.6) with ESMTP id g3O57mF17637; Wed, 24 Apr 2002 07:07:48 +0200 Received: from relay.monex.li (8.9.3/8.9.3) id IAA26261; Wed, 24 Apr 2002 08:34:57 +0200 Received: from mailpumpe.monex.li by relay.monex.li via smtp; Received: from vorab.monex.li by mailpumpe.monex.li (8.11.6/8.11.6) with ESMTP id g3O57Ti17919; Wed, 24 Apr 2002 07:07:30 +0200 Subject: Re: XFS and EVMS - Limited Success From: Oliver Jehle To: Eric Sandeen Cc: "Karl M. Hegbloom" , linux-xfs@oss.sgi.com In-Reply-To: <1019589164.6392.4.camel@stout.americas.sgi.com> References: <20510000.1019570836@camillo> <20020423165414.202b89e2.pegasus@telemach.net> <3CC57AC5.4010308@sgi.com> <1019588340.27446.23.camel@juniper.intra.microsharp.com> <1019589164.6392.4.camel@stout.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 24 Apr 2002 07:07:13 +0200 Message-Id: <1019624835.933.7.camel@vorab> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk there is a patch for evms implementing the BLKSETSZ64 call... have a look in the evms mailing list... On Tue, 2002-04-23 at 21:12, Eric Sandeen wrote: > On Tue, 2002-04-23 at 13:59, Karl M. Hegbloom wrote: > > On Tue, 2002-04-23 at 08:16, Stephen Lord wrote: > > > > > We had some ioctl problem reports from mkfs which should now be fixed in > > > EVMS 1.0. Someone else reported it was working. I have not tried myself. > > > > I am using EVMS, and see: > > > > root@juniper:~ > > # mkfs -t xfs /dev/evms/test > > mkfs.xfs: warning - cannot set blocksize on block device /dev/evms/test: > > Invalid argument > > That's not really a problem. It just means that the BLKSETSZ ioctl is > not supported by evms; for now, anyway, xfs can live without it. > > > It would be a lot easier for me > > to see what version of XFS the kernel has built into it if you would > > cause the "dmesg" (printk) output at startup to give a version number. > > Well, there are 2 flavors of XFS - releases, and cvs snapshots (this > includes any patch you find on oss.sgi.com that's NOT under a > "Release-X" directory.) It would have been a good idea to hard code a > release version into the releases, yes. Sorry about that. > > > I've given up on finding what version it is after 5 minutes of code > > grepping, sorry. Ah... dpkg --status kernel-patch-xfs tells me that > > it's version "1.0.2+20020304-2". So do I need a newer one to make XFS > > work right with EVMS? > > Sounds like you got it from debian, then - and I guess they got it from > release 1.0.2, and maybe tweaked it a bit? > > I would suggest getting patches + userspace from under the Release-1.1, > if you're looking for a set of things that are known to work well > together. However, there isn't anything inherently wrong with the > combination you have now. > > -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 24 00:08:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3O78fwJ009896 for ; Wed, 24 Apr 2002 00:08:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3O78eM3009895 for linux-xfs-outgoing; Wed, 24 Apr 2002 00:08:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3O78ZwJ009869 for ; Wed, 24 Apr 2002 00:08:36 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g3O78wR04973 for ; Wed, 24 Apr 2002 16:08:58 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g3O78vR00749 for ; Wed, 24 Apr 2002 16:08:57 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g3O78ur19544 for ; Wed, 24 Apr 2002 16:08:57 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA476 for ; Wed, 24 Apr 2002 16:08:55 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Apr 24 16:08:54 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g3O78s611156 for ; Wed, 24 Apr 2002 16:08:55 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id g3O78sO02752 for ; Wed, 24 Apr 2002 16:08:54 +0900 To: linux-xfs@oss.sgi.com Subject: maximum files X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020424160854G.masano@tnes.nec.co.jp> Date: Wed, 24 Apr 2002 16:08:54 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 9 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, What is the maximum number of files per filesystem for XFS? The inode.i_ino field has 32 bits, so I guess the maximum number is 4 giga, is it correct? -- Masano From owner-linux-xfs@oss.sgi.com Wed Apr 24 00:19:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3O7J8wJ010123 for ; Wed, 24 Apr 2002 00:19:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3O7J8EA010122 for linux-xfs-outgoing; Wed, 24 Apr 2002 00:19:08 -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 g3O7J2wJ010096 for ; Wed, 24 Apr 2002 00:19:03 -0700 Received: (qmail 8392 invoked from network); 24 Apr 2002 16:37:42 +0930 Received: from gauntlet.tellurian.com.au (HELO rebel.net.au) (203.20.69.209) by huachuca.tellurian.com.au with SMTP; 24 Apr 2002 16:37:42 +0930 Message-ID: <3CC65F83.5090604@rebel.net.au> Date: Wed, 24 Apr 2002 17:02:19 +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: ASANO Masahiro CC: linux-xfs@oss.sgi.com Subject: Re: maximum files References: <20020424160854G.masano@tnes.nec.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hmmmm.... > What is the maximum number of files per filesystem for XFS? I think you can actually tell XFS how many inodes it can have...which means you could probably have terabytes of sparse files if you really wanted to be silly :-) 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 Wed Apr 24 01:57:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3O8vxwJ012894 for ; Wed, 24 Apr 2002 01:57:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3O8vxDl012893 for linux-xfs-outgoing; Wed, 24 Apr 2002 01:57:59 -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 g3O8v7wJ012828 for ; Wed, 24 Apr 2002 01:57:26 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 170IaW-00010W-00 for linux-xfs@oss.sgi.com; Wed, 24 Apr 2002 10:57:20 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 170IaU-0000U8-00; Wed, 24 Apr 2002 10:57:18 +0200 Message-ID: <3CC67369.935DF3ED@up.ac.za> Date: Wed, 24 Apr 2002 10:57:13 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-h-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Paul Schutte CC: XFS mailing list Subject: Re: XFS slows down on used partions with bonnie++ References: <3C94F14E.7DE5A62D@it.up.ac.za> Content-Type: multipart/mixed; boundary="------------ADF3D20412ED9D13CCDE13A3" X-Scanner: exiscan *170IaU-0000U8-00*1eLBRblw/YU* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This is a multi-part message in MIME format. --------------ADF3D20412ED9D13CCDE13A3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The patch that I include here fixes the problem that I mentioned in my original posting. It should work on all 2.4.x kernels. I don't know how it will behave on IRIX, but linux gets a bit of a performance boost. It seemed faster or the same on all tests that I have run so far. The backup speed of my XFS servers got slower over time and that is why I chased down the problem. The results here are done on a different server than the one I used for my original posting, so you can not compare numeric values between the 2 postings. Here is before and after values done now on the same server now. BEFORE: 1st run: Version 1.02b ------Sequential Create------ --------Random Create-------- kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 10:100000:1000/1000 222 8 170 4 1441 21 199 8 55 1 985 20 kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,222,8,170,4,1441,21,199,8,55,! 0.320u 16.660s 6:00.93 4.7% 0+0k 0+0io 202pf+0w 2nd run: Version 1.02b ------Sequential Create------ --------Random Create-------- kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 10:100000:1000/1000 201 7 99 2 1168 16 204 7 54 1 989 22 kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,201,7,99,2,1168,16,204,7,54,1! 0.400u 16.360s 6:49.92 4.0% 0+0k 0+0io 202pf+0w AFTER: 1st run: Version 1.02b ------Sequential Create------ --------Random Create-------- kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 10:100000:1000/1000 224 8 176 4 1444 21 224 8 57 1 1084 19 kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,224,8,176,4,1444,21,224,8,57,! 0.380u 15.700s 5:44.37 4.6% 0+0k 0+0io 202pf+0w 2nd run: Version 1.02b ------Sequential Create------ --------Random Create-------- kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP 10:100000:1000/1000 214 8 173 4 1367 20 222 8 57 1 1081 23 kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,214,8,173,4,1367,20,222,8,57,! 0.350u 16.110s 5:49.39 4.7% 0+0k 0+0io 202pf+0w >From this we can see that the sequential read speed is wat is should be. As a bonus we get a healthy increase in random create. Paul Paul Schutte wrote: > Hi, > > I have being playing around with bonnie++ from > http://www.coker.com.au/bonnie++/ > > I found an interesting thing. > > When I run bonnie++ on a newly created XFS filesystem I get the > following results: > > mkfs.xfs -f -l size=8192b /dev/sda7 > > meta-data=/dev/sda7 isize=256 agcount=19, agsize=262144 > blks > data = bsize=4096 blocks=4843589, imaxpct=25 > > = sunit=0 swidth=0 blks, unwritten=0 > > naming =version 2 bsize=4096 > log =internal log bsize=4096 blocks=8192 > realtime =none extsz=65536 blocks=0, rtextents=0 > > mount -o logbufs=8 /dev/sda7 /mnt > > cd /mnt > > /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 > > Version 1.02b ------Sequential Create------ --------Random > Create-------- > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > /sec %CP > 10:100000:1000/1000 206 8 154 3 1463 20 192 7 49 1 > 1081 18 > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,206,8,154,3,1463,20,192,7,49,1, > > 1081,18 > 0.300u 15.540s 6:35.00 4.0% 0+0k 0+0io 215pf+0w > > /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 > > Version 1.02b ------Sequential Create------ --------Random > Create-------- > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > /sec %CP > 10:100000:1000/1000 196 7 83 1 1215 23 191 8 49 1 > 1023 20 > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,196,7,83,1,1215,23,191,8,49,1,1 > > 023,20 > 0.370u 16.520s 7:31.92 3.7% 0+0k 0+0io 219pf+0w > > I created the file system. > Run bonnie++ with the parameters as above. > I run bonnie++ immediately for a second time. > If you look at the sequential read field, you will see that it is nearly > half the amount of the first run. > According to this test XFS seems to lose sequential read speed as the > filesystem gets used. > You can umount and even reboot the machine and run bonnie++ again and > still get the slowdown phenomenon, > provided you mount the same filesystem again without mkfs'ing it. > > I repeated this test on several other machines with the same result. > I also did it with other filesystems. > > Here is the result with ext2: > > Version 1.02b ------Sequential Create------ --------Random > Create-------- > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > /sec %CP > 10:100000:1000/1000 142 2 142 2 585 3 150 3 46 0 > 430 2 > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,142,2,142,2,585,3,150,3,46,0,43 > > 0,2 > 0.240u 8.950s 7:56.63 1.9% 0+0k 0+0io 218pf+0w > /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 > Version 1.02b ------Sequential Create------ --------Random > Create-------- > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- > -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > /sec %CP > 10:100000:1000/1000 154 3 143 3 540 2 152 2 47 0 > 449 2 > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,154,3,143,3,540,2,152,2,47,0,44 > > 9,2 > 0.300u 9.080s 7:42.20 2.0% 0+0k 0+0io 220pf+0w > > No slow down. > I can include results for reiserfs and JFS, but will add size to this > message without adding additional info > regarding this issue. > > The machine is a Dell PE2550 > 1G RAM (I used mem=256M kernel param, otherwise everything runs from > cache) > 4x18G 15k RPM seagate cheethas in RAID 10 > 2x1.133GHz P4 CPUs > > Regards > > Paul Schutte --------------ADF3D20412ED9D13CCDE13A3 Content-Type: text/plain; charset=us-ascii; name="patch-2.4.18-ifix" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="patch-2.4.18-ifix" diff -ur linux/fs/xfs/xfs_ialloc.c /data/linux-2.4-xfs-ifix/linux/fs/xfs/xfs_ialloc.c --- linux/fs/xfs/xfs_ialloc.c Sat Jan 12 01:43:26 2002 +++ /data/linux-2.4-xfs-ifix/linux/fs/xfs/xfs_ialloc.c Wed Apr 24 00:36:54 2002 @@ -815,20 +815,35 @@ if ((error = xfs_inobt_lookup_eq(cur, INT_GET(agi->agi_newino, ARCH_CONVERT), 0, 0, &i))) goto error0; + + /* + * It seems not te be a good idea to use the most recently + * allocated block. If we do so, we end up using the inodes + * at the back of the ag first and work our way to the front. + * The data blocks on the other hand tend to be allocated from + * the begining to the end of the ag. The avarage distance between + * an inode and its data in terms of daddr is much longer if we do + * it this way. The avarage distance between the inode and it's data + * tend to be more constant and in general shorter if we allocate + * inodes from the front of the ag to the back. + * + * Paul Schutte + * if (i == 1 && (error = xfs_inobt_get_rec(cur, &rec.ir_startino, &rec.ir_freecount, &rec.ir_free, &j, ARCH_NOCONVERT)) == 0 && j == 1 && rec.ir_freecount > 0) { - /* + * * The last chunk allocated in the group still has * a free inode. - */ + * } /* * None left in the last group, search the whole a.g. - */ + else { + */ if (error) goto error0; if ((error = xfs_inobt_lookup_ge(cur, 0, 0, 0, &i))) @@ -847,7 +862,7 @@ goto error0; XFS_WANT_CORRUPTED_GOTO(i == 1, error0); } - } + /* } Matches the most recently block code above */ } offset = XFS_IALLOC_FIND_FREE(&rec.ir_free); ASSERT(offset >= 0); --------------ADF3D20412ED9D13CCDE13A3-- From owner-linux-xfs@oss.sgi.com Wed Apr 24 04:04: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 g3OB4nwJ018493 for ; Wed, 24 Apr 2002 04:04:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OB4mxZ018492 for linux-xfs-outgoing; Wed, 24 Apr 2002 04:04:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OB4dwJ018461 for ; Wed, 24 Apr 2002 04:04:40 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g3OB53c05642; Wed, 24 Apr 2002 13:05:03 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15558.37214.558780.264419@slime.wu-wien.ac.at> Date: Wed, 24 Apr 2002 13:05:02 +0200 To: linux-xfs@oss.sgi.com Subject: Re: corrupt xfs filesystem -- xfs_repair dumps core In-Reply-To: <20020424082748.L63455@wobbly.melbourne.sgi.com> References: <15557.36194.760672.792045@slime.wu-wien.ac.at> <20020424082748.L63455@wobbly.melbourne.sgi.com> X-Mailer: VM 7.03 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Nathan! According to Nathan Scott: > > Then, we upgraded the xfsprogs to 2.0.3, an now we get a core dump: > > > > # /sbin/xfs_repair /dev/sdb > > Phase 1 - find and verify superblock... > > Phase 2 - using internal log > > - zero log... > > xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion `start_blk != 0 || *last_blk != start_blk' failed. > > Aborted (core dumped) > > [...] > > Ah, I see the problem. You have an unclean log and corruption in > the log which is causing the code in xfs_repair to get confused when > searching for the log head/tail. Thank You *very* much for your answer. > First try mount, then unmount, and then run xfs_repair. The initial > mount/unmount will cause the log to be replayed, if it can be. The mount operation seems to hang. After 6 hours i decided to reboot the box... > Failing that, try "xfs_repair -L /dev/sdb" which skips the check for > an empty log, zeroes it, then goes ahead with repairing. Unfortunatly the '-L' makes no difference: # /sbin/xfs_repair -L /dev/sdb Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion `start_blk != 0 || *last_blk != start_blk' failed. Aborted (core dumped) > Failing that (!) we can get libxlog built non-debug so this assertion > doesn't get tripped, and see how we go from there. Ok, i will see if i can do this... Thanks again, \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Wed Apr 24 05:25:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OCPmwJ020328 for ; Wed, 24 Apr 2002 05:25:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OCPmsu020327 for linux-xfs-outgoing; Wed, 24 Apr 2002 05:25:48 -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 g3OCPAwJ020297 for ; Wed, 24 Apr 2002 05:25:11 -0700 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by wiley (8.11.6/8.11.6) with ESMTP id g3OCPUp01682 for ; Wed, 24 Apr 2002 08:25:31 -0400 Subject: Still Another Oops, and I'm Stumped From: Danny Cox To: XFS Mailing List Content-Type: multipart/mixed; boundary="=-hLfCO8ytrTB3gth63MUA" X-Mailer: Ximian Evolution 1.0.3 Date: 24 Apr 2002 08:25:30 -0400 Message-Id: <1019651131.1144.17.camel@wiley> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-hLfCO8ytrTB3gth63MUA Content-Type: text/plain Content-Transfer-Encoding: 7bit Different machine from yesterday ;-). We have a machine with root mirrored across many (11) drives. We pulled one drive while it was resyncing a drive ("stress test" ;-), rebooted, and shoved it back in. XFS oopsed during mount, attempting to recover the FS. Interpreted oops (actually 3 of 'em) attached. Ideas? I know: "if it hurts, DON'T DO THAT!". Other data: XFS is from a few weeks back (~ 19-Mar), 2.4.18 kernel. MD is version 0.90, included in the kernel. Thanks! -- kernel, n.: A part of an operating system that preserves the medieval traditions of sorcery and black art. Danny --=-hLfCO8ytrTB3gth63MUA Content-Disposition: attachment; filename=oops.interp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; name=oops.interp; charset=ISO-8859-1 ksymoops 2.4.1 on i686 2.4.18-xfs. Options used -V (specified) -K (specified) -L (specified) -O (specified) -m System.map (specified) Unable to handle kernel paging request at virtual address d0000000 c01c7bee=20=20=20=20=20=20 *pde =3D 00000000 Oops: 0002=20=20=20=20=20 CPU: 0=20 EIP: 0010:[] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010206=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 eax: e8fffffd ebx: 00000000 ecx: 00000400 edx: 00000000 esi: 00000400 edi: ce40642c ebp: d0000000 esp: cff3f778 ds: 0018 es: 0018 ss: 0018=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Process mount (pid: 41, stackpage=3Dcff3f000) Stack: 00000000 00001090 00000000 00000000 00000400 ce40642c c01c7dcd ce405400=20 cff80000 c157a7e0 00000000 c157a7e0 0000108e 00000000 c028ff11 cff3f7c0=20 c157a7e0 cff3f8e8 72617453 cff80000 c1535800 c1535800 7265766f 6e6f2079=20 Call Trace: [] [] [] [] [] [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 Code: 89 45 00 81 c5 00 02 00 00 83 c7 04 89 7c 24 14 ff 44 24 10=20 >>EIP; c01c7bee <=3D=3D=3D=3D=3D Trace; c01c7dcd Trace; c01c8226 Trace; c01c82ae Trace; c01c8450 Trace; c01c2192 Trace; c01c9ec7 Trace; c01a63a0 Trace; c0105c69 <__down+a1/ac> Trace; c01c8b21 Trace; c01c8d06 Trace; c01c8d51 Trace; c01e74f1 Trace; c01d18ed Trace; c01d1a6e Trace; c01d1a9b Trace; c01e76e9 Trace; c01284cf <__alloc_pages+3b/17c> Trace; c011f529 Trace; c0128330 <_alloc_pages+18/1c> Trace; c011f5a0 Trace; c011f655 Trace; c01325e6 Trace; c01417e7 Trace; c01329ec Trace; c0142654 Trace; c0142a0e Trace; c0142874 Trace; c0142aac Trace; c0106dfb Code; c01c7bee 00000000 <_EIP>: Code; c01c7bee <=3D=3D=3D=3D=3D 0: 89 45 00 mov %eax,0x0(%ebp) <=3D=3D=3D=3D=3D Code; c01c7bf1 3: 81 c5 00 02 00 00 add $0x200,%ebp Code; c01c7bf7 9: 83 c7 04 add $0x4,%edi Code; c01c7bfa c: 89 7c 24 14 mov %edi,0x14(%esp,1) Code; c01c7bfe 10: ff 44 24 10 incl 0x10(%esp,1) <1>Unable to handle kernel NULL pointer dereference at virtual address 00000004 c0126b2d=20=20=20=20=20=20 *pde =3D 00000000 Oops: 0002=20=20=20=20=20 CPU: 0=20 EIP: 0010:[] Not tainted EFLAGS: 00010046=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 eax: ce5e1000 ebx: 00000001 ecx: cffc0000 edx: 00000000 esi: c1403d50 edi: 00000292 ebp: 00000008 esp: cff3f61c ds: 0018 es: 0018 ss: 0018=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Process mount (pid: 41, stackpage=3Dcff3f000) Stack: cffc03c0 ce5e3440 40146000 00004000 ce470404 c0120a0e c0120a29 c1403d50=20 cffc03c0 ce5e3440 cff3e000 0000000b d0000000 ce5e1e40 c0111c82 ce5e3440=20 ce5e3440 c0115a99 ce5e3440 00000002 00000340 cff3f744 c010732b 0000000b=20 Call Trace: [] [] [] [] [] [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 []=20 Code: 89 42 04 89 10 8b 46 10 89 48 04 89 01 8d 56 10 89 51 04 89=20 >>EIP; c0126b2d <=3D=3D=3D=3D=3D Trace; c0120a0e Trace; c0120a29 Trace; c0111c82 Trace; c0115a99 Trace; c010732b Trace; c0110216 Trace; c010fea4 Trace; c01c7bee Trace; c01c7bee Trace; c0110bef Trace; c0105c69 <__down+a1/ac> Trace; c0106eec Trace; c01c7bee Trace; c01c7dcd Trace; c01c8226 Trace; c01c82ae Trace; c01c8450 Trace; c01c2192 Trace; c01c9ec7 Trace; c01a63a0 Trace; c0105c69 <__down+a1/ac> Trace; c01c8b21 Trace; c01c8d06 Trace; c01c8d51 Trace; c01e74f1 Trace; c01d18ed Trace; c01d1a6e Trace; c01d1a9b Trace; c01e76e9 Trace; c01284cf <__alloc_pages+3b/17c> Trace; c011f529 Trace; c0128330 <_alloc_pages+18/1c> Trace; c011f5a0 Trace; c011f655 Trace; c01325e6 Trace; c01417e7 Trace; c01329ec Trace; c0142654 Trace; c0142a0e Trace; c0142874 Trace; c0142aac Trace; c0106dfb Code; c0126b2d 00000000 <_EIP>: Code; c0126b2d <=3D=3D=3D=3D=3D 0: 89 42 04 mov %eax,0x4(%edx) <=3D=3D=3D=3D=3D Code; c0126b30 3: 89 10 mov %edx,(%eax) Code; c0126b32 5: 8b 46 10 mov 0x10(%esi),%eax Code; c0126b35 8: 89 48 04 mov %ecx,0x4(%eax) Code; c0126b38 b: 89 01 mov %eax,(%ecx) Code; c0126b3a d: 8d 56 10 lea 0x10(%esi),%edx Code; c0126b3d 10: 89 51 04 mov %edx,0x4(%ecx) Code; c0126b40 13: 89 00 mov %eax,(%eax) <1>Unable to handle kernel NULL pointer dereference at virtual address 00000004 c0126b2d=20=20=20=20=20=20 *pde =3D 00000000 Oops: 0002=20=20=20=20=20 CPU: 0=20 EIP: 0010:[] Not tainted EFLAGS: 00010046=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20 eax: c154a020 ebx: 00000001 ecx: cffc4000 edx: 00000000 esi: c1403c00 edi: 00000092 ebp: 00000001 esp: cff3f4dc ds: 0018 es: 0018 ss: 0018=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 Process mount (pid: 41, stackpage=3Dcff3f000) Stack: cff3e000 cff3e000 0000000b 00000008 cff3e000 0000000b c011a38b c1403c00=20 cffc4560 c15b0260 c0115b75 cff3e000 00000002 00000000 cff3f5e8 c010732b=20 0000000b 00000000 c0110216 c027dd5e cff3f5e8 00000002 cff3e000 00000002=20 Call Trace: [] [] [] [] [] [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 [] [] [] [] [] []=20 Code: 89 42 04 89 10 8b 46 10 89 48 04 89 01 8d 56 10 89 51 04 89=20 >>EIP; c0126b2d <=3D=3D=3D=3D=3D Trace; c011a38b Trace; c0115b75 Trace; c010732b Trace; c0110216 Trace; c010fea4 Trace; c0126b2d Trace; c0126b2d Trace; c01fbbc8 Trace; c0127211 Trace; c0106eec Trace; c0126b2d Trace; c0120a0e Trace; c0120a29 Trace; c0111c82 Trace; c0115a99 Trace; c010732b Trace; c0110216 Trace; c010fea4 Trace; c01c7bee Trace; c01c7bee Trace; c0110bef Trace; c0105c69 <__down+a1/ac> Trace; c0106eec Trace; c01c7bee Trace; c01c7dcd Trace; c01c8226 Trace; c01c82ae Trace; c01c8450 Trace; c01c2192 Trace; c01c9ec7 Trace; c01a63a0 Trace; c0105c69 <__down+a1/ac> Trace; c01c8b21 Trace; c01c8d06 Trace; c01c8d51 Trace; c01e74f1 Trace; c01d18ed Trace; c01d1a6e Trace; c01d1a9b Trace; c01e76e9 Trace; c01284cf <__alloc_pages+3b/17c> Trace; c011f529 Trace; c0128330 <_alloc_pages+18/1c> Trace; c011f5a0 Trace; c011f655 Trace; c01325e6 Trace; c01417e7 Trace; c01329ec Trace; c0142654 Trace; c0142a0e Trace; c0142874 Trace; c0142aac Trace; c0106dfb Code; c0126b2d 00000000 <_EIP>: Code; c0126b2d <=3D=3D=3D=3D=3D 0: 89 42 04 mov %eax,0x4(%edx) <=3D=3D=3D=3D=3D Code; c0126b30 3: 89 10 mov %edx,(%eax) Code; c0126b32 5: 8b 46 10 mov 0x10(%esi),%eax Code; c0126b35 8: 89 48 04 mov %ecx,0x4(%eax) Code; c0126b38 b: 89 01 mov %eax,(%ecx) Code; c0126b3a d: 8d 56 10 lea 0x10(%esi),%edx Code; c0126b3d 10: 89 51 04 mov %edx,0x4(%ecx) Code; c0126b40 13: 89 00 mov %eax,(%eax) --=-hLfCO8ytrTB3gth63MUA-- From owner-linux-xfs@oss.sgi.com Wed Apr 24 05:39:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OCdKwJ020577 for ; Wed, 24 Apr 2002 05:39:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OCdKVw020576 for linux-xfs-outgoing; Wed, 24 Apr 2002 05:39:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OCdGwJ020550 for ; Wed, 24 Apr 2002 05:39:16 -0700 Received: from relay1.corp.sgi.com (spindle.corp.sgi.com [198.29.75.13]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id FAA1131313 for ; Wed, 24 Apr 2002 05:39:40 -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 FAA80416 for ; Wed, 24 Apr 2002 05:38:54 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by stantz.corp.sgi.com (Postfix) with ESMTP id 7AF3413641F for ; Wed, 24 Apr 2002 05:38:54 -0700 (PDT) Subject: Re: /dev/null coming up as chmod 600 at boot? From: Florin Andrei To: 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: 24 Apr 2002 05:38:54 -0700 Message-Id: <1019651934.2754.5.camel@stantz.corp.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-23 at 06:46, Mike Burger wrote: > > I guess I can rpm -e devfsd and see if that helps. I suppose devfsd was > installed when I did the RH7.1 + SGI installation. Yeah, that's why it's always better to backup/format/reinstall instead of upgrade. ;-) I have XFS-1.1 on a Red Hat 7.2 here, running a fairly beefy MySQL database, and /dev/null is fine and dandy. [florin@zoul florin]$ ls -l /dev/null crw-rw-rw- 1 root root 1, 3 Aug 30 2001 /dev/null -- Florin Andrei There's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it. From owner-linux-xfs@oss.sgi.com Wed Apr 24 06:04: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 g3OD4CwJ020992 for ; Wed, 24 Apr 2002 06:04:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OD4CN4020991 for linux-xfs-outgoing; Wed, 24 Apr 2002 06:04:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OD44wJ020965 for ; Wed, 24 Apr 2002 06:04:05 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g3OD4TR23391 for ; Wed, 24 Apr 2002 22:04:29 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g3OD4SR23373 for ; Wed, 24 Apr 2002 22:04:28 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g3OD4Sr02013 for ; Wed, 24 Apr 2002 22:04:28 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA468 for ; Wed, 24 Apr 2002 22:04:26 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Wed Apr 24 22:04:25 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g3OD4Q641161; Wed, 24 Apr 2002 22:04:26 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id g3OD4QO24160; Wed, 24 Apr 2002 22:04:26 +0900 To: lloy0076@rebel.net.au, linux-xfs@oss.sgi.com Subject: Re: maximum files In-Reply-To: <3CC65F83.5090604@rebel.net.au> References: <20020424160854G.masano@tnes.nec.co.jp> <3CC65F83.5090604@rebel.net.au> X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020424220426Y.masano@tnes.nec.co.jp> Date: Wed, 24 Apr 2002 22:04:26 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, > > What is the maximum number of files per filesystem for XFS? > 1 > I think you can actually tell XFS how many inodes it can have...which > means you could probably have terabytes of sparse files if you really > wanted to be silly :-) Thank you. I made a sparse file whose length is 2000GB and executed mkfs.xfs on it; the xfs had 500 AGs. I mounted the xfs by loop and made 500 directories on the mount point. But it seems that 256th directory was created on the AG#0. Anyway I could not create inode whose d_ino is >4G. $ ls -ldi d? 131 drwxr-xr-x 2 masano grp 42 Apr 24 20:58 d0 16777344 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d1 33554560 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d2 50331776 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d3 67108992 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d4 83886208 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d5 100663424 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d6 117440640 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d7 134217856 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d8 150995072 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d9 $ ls -ldi d25? 4194828416 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d250 4211081344 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d251 4227858560 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d252 4244635776 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d253 4261412992 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d254 4278190208 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d255 132 drwxr-xr-x 2 masano grp 33 Apr 24 20:58 d256 16777345 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d257 33554561 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d258 50331777 drwxr-xr-x 2 masano grp 6 Apr 24 20:56 d259 -- Masano From owner-linux-xfs@oss.sgi.com Wed Apr 24 06:23: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 g3ODNuwJ021441 for ; Wed, 24 Apr 2002 06:23:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ODNust021440 for linux-xfs-outgoing; Wed, 24 Apr 2002 06:23: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 g3ODNpwJ021414 for ; Wed, 24 Apr 2002 06:23: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 IAA21562; Wed, 24 Apr 2002 08:24:12 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id IAA26017; Wed, 24 Apr 2002 08:24:11 -0500 (CDT) Date: Wed, 24 Apr 2002 08:24:11 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: ASANO Masahiro cc: linux-xfs@oss.sgi.com Subject: Re: maximum files In-Reply-To: <20020424160854G.masano@tnes.nec.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The default in XFS is now to restrict inode numbers to 32 bits; however there is an "ino64" option that allows them to reach 64 bits internally, possibly breaking other applications. (I see that the linux inode number is an unsigned long, so this is probably the limiting factor on a 32 bit box). The Inode numbers in xfs are sparse, though, so I'm not sure how to calculate the actual number of files you can fit on a filesystem. Steve can probably answer this succinctly. -Eric On Wed, 24 Apr 2002, ASANO Masahiro wrote: > What is the maximum number of files per filesystem for XFS? > > The inode.i_ino field has 32 bits, so I guess the maximum number > is 4 giga, is it correct? -- 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 24 06:31: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 g3ODViwJ021656 for ; Wed, 24 Apr 2002 06:31:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ODVibN021655 for linux-xfs-outgoing; Wed, 24 Apr 2002 06:31:44 -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@burgers.bubbanfriends.org [216.140.122.113]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ODVewJ021629 for ; Wed, 24 Apr 2002 06:31:40 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id A0E8F401A40; Wed, 24 Apr 2002 09:32:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 89700C0008D; Wed, 24 Apr 2002 09:32:07 -0400 (EDT) Date: Wed, 24 Apr 2002 09:32:07 -0400 (EDT) From: Mike Burger To: Florin Andrei Cc: linux-xfs@oss.sgi.com Subject: Re: /dev/null coming up as chmod 600 at boot? In-Reply-To: <1019651934.2754.5.camel@stantz.corp.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 24 Apr 2002, Florin Andrei wrote: > On Tue, 2002-04-23 at 06:46, Mike Burger wrote: > > > > I guess I can rpm -e devfsd and see if that helps. I suppose devfsd was > > installed when I did the RH7.1 + SGI installation. > > Yeah, that's why it's always better to backup/format/reinstall instead > of upgrade. ;-) It was a clean install, actually...with the 7.1 ISO set (when that was the current set). The only things I've upgraded are on a package by package basis, including the kernels. > I have XFS-1.1 on a Red Hat 7.2 here, running a fairly beefy MySQL > database, and /dev/null is fine and dandy. > > [florin@zoul florin]$ ls -l /dev/null > crw-rw-rw- 1 root root 1, 3 Aug 30 2001 /dev/null Yup...well, after removing the devfsd package, rebooting, resetting the permissions and rebooting again, it looks like all is well, finally. From owner-linux-xfs@oss.sgi.com Wed Apr 24 07:14: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 g3OEEowJ022423 for ; Wed, 24 Apr 2002 07:14:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OEEoQi022422 for linux-xfs-outgoing; Wed, 24 Apr 2002 07:14:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from slime.wu-wien.ac.at (slime.wu-wien.ac.at [137.208.89.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OEEdwJ022382 for ; Wed, 24 Apr 2002 07:14:40 -0700 Received: (from wlang@localhost) by slime.wu-wien.ac.at (8.11.6/8.11.6) id g3OEF2506203; Wed, 24 Apr 2002 16:15:02 +0200 From: Willi Langenberger MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15558.48614.712385.959334@slime.wu-wien.ac.at> Date: Wed, 24 Apr 2002 16:15:02 +0200 To: linux-xfs@oss.sgi.com Subject: Re: corrupt xfs filesystem -- xfs_repair dumps core In-Reply-To: <15558.37214.558780.264419@slime.wu-wien.ac.at> References: <15557.36194.760672.792045@slime.wu-wien.ac.at> <20020424082748.L63455@wobbly.melbourne.sgi.com> <15558.37214.558780.264419@slime.wu-wien.ac.at> X-Mailer: VM 7.03 under Emacs 20.7.1 Reply-To: Willi.Langenberger@wu-wien.ac.at Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all! According to Willi Langenberger: > According to Nathan Scott: > > > Then, we upgraded the xfsprogs to 2.0.3, an now we get a core dump: > > > > > > # /sbin/xfs_repair /dev/sdb > > > Phase 1 - find and verify superblock... > > > Phase 2 - using internal log > > > - zero log... > > > xfs_repair: xfs_log_recover.c:159: xlog_find_verify_log_record: Assertion `start_blk != 0 || *last_blk != start_blk' failed. > > > Aborted (core dumped) I tried to debug xfs_repair (xfsprogs 2.0.3) to find out what is going on, but i need help... Function xlog_find_zeroed at xfs_log_recover.c: /* * We search for any instances of cycle number 0 that occur before * our current estimate of the head. What we're trying to detect is * 1 ... | 0 | 1 | 0... * ^ binary search ends here */ new_blk = xlog_find_verify_cycle(log, start_blk, (int)num_scan_bblks, 0); if (new_blk != -1) last_blk = new_blk; /* * Potentially backup over partial log record write. We don't need * to search the end of the log because we know it is zero. */ if ((error = xlog_find_verify_log_record(log, start_blk, &last_blk, 0))) goto bp_err; start_blk is zero and xlog_find_verify_cycle returns also zero for new_blk ==> that means, that xlog_find_verify_log_record is called with start_blk=0 and last_blk=0 (last_blk is copied from new_blk). However, this triggers the assertion in xlog_find_verify_log_record: xlog_find_verify_log_record(xlog_t *log, xfs_daddr_t start_blk, xfs_daddr_t *last_blk, int extra_bblks) { xfs_daddr_t i; xfs_buf_t *bp; char *buf = NULL; xlog_rec_header_t *head = NULL; int error = 0; int smallmem = 0; int num_blks = *last_blk - start_blk; ASSERT(start_blk != 0 || *last_blk != start_blk); Can anybody say, what is the right thing to do? Should i ignore the ASSERT? Or should i dive into xlog_find_verify_cycle, to find out, why it returns 0 to new_blk? Or is there a way to completely skip the ``check partially zeroed log'' section in xlog_find_zeroed (i'd happily forget the last changes, if i can access the filesystem again...) As always: any help is highly appreciated! Thanks, \wlang{} -- Willi.Langenberger@wu-wien.ac.at Fax: +43/1/31336/702 Zentrum fuer Informatikdienste, Wirtschaftsuniversitaet Wien, Austria From owner-linux-xfs@oss.sgi.com Wed Apr 24 07:13: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 g3OEDiwJ022333 for ; Wed, 24 Apr 2002 07:13:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OEDiJX022332 for linux-xfs-outgoing; Wed, 24 Apr 2002 07:13:44 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from c000.snv.cp.net (h019.c000.snv.cp.net [209.228.32.83]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OEDXwJ022303 for ; Wed, 24 Apr 2002 07:13:38 -0700 Received: (cpmta 12212 invoked from network); 24 Apr 2002 07:13:53 -0700 Received: from 207.207.51.226 (HELO itspec.amoa.org) by smtp.tooley.com (209.228.32.83) with SMTP; 24 Apr 2002 07:13:53 -0700 X-Sent: 24 Apr 2002 14:13:53 GMT Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) From: Chris Tooley To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020424084049.M63455@wobbly.melbourne.sgi.com> References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> <1019581365.26898.9.camel@itspec.amoa.org> <20020424084049.M63455@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 24 Apr 2002 09:14:33 -0500 Message-Id: <1019657673.29084.7.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anything else been changed in CVS? I'm hoping that nothing is broken because I'm planning on putting the machine into production this weekend. Chris On Tue, 2002-04-23 at 17:40, Nathan Scott wrote: > On Tue, Apr 23, 2002 at 12:02:44PM -0500, Chris Tooley wrote: > > I did make the switch in configure from -lacl -lattr and faired no > > better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp > > kernel. > > > > checking if large file support can be enabled... yes > > checking whether to support ACLs... checking for acl_get_file in > > -lattr... no > > checking for ACL support... no > > Your configure changes are incorrect - they're looking in the wrong > library for acl_get_file (which is in libacl, not libattr), as I > said earlier you need to link with both libraries. > > It has been pointed out that we can do a better job when building > libacl so that it knows it depends on libattr (in fact this was > done at one point, but was accidentally dropped from the Makefile). > If you build and install the acl code from XFS CVS (have a look > though cmd/acl/doc/INSTALL), you should find that Samba gets > built correctly with no changes at all now. > > cheers. > > -- > Nathan > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba From owner-linux-xfs@oss.sgi.com Wed Apr 24 07:36:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OEagwJ022897 for ; Wed, 24 Apr 2002 07:36:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OEagB8022896 for linux-xfs-outgoing; Wed, 24 Apr 2002 07:36:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OEaWwJ022869 for ; Wed, 24 Apr 2002 07:36:33 -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 JAA23053; Wed, 24 Apr 2002 09:36:52 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA80835; Wed, 24 Apr 2002 09:36:51 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3OEXI028435; Wed, 24 Apr 2002 09:33:18 -0500 Subject: Re: maximum files From: Steve Lord To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020424160854G.masano@tnes.nec.co.jp> References: <20020424160854G.masano@tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 24 Apr 2002 09:33:18 -0500 Message-Id: <1019658798.27989.29.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-04-24 at 02:08, ASANO Masahiro wrote: > Hi, > > What is the maximum number of files per filesystem for XFS? > > The inode.i_ino field has 32 bits, so I guess the maximum number > is 4 giga, is it correct? > > -- > Masano Other people have already provided some of the information here. On linux the thoretical limit is indeed 4G of inodes, however, as Eric mentioned, the inode numbers are sparse, so it will probably be less than that. Inode numbers actually contain an encoding of the disk address of the inode. Various factors come into play, but with default mkfs parameters you have the potential to overflow 32 bits with any filesystem larger than 1 Tbyte. Larger inode sizes can push this size up somewhat. In order to deal with the 32 bit limit on Linux, and with issues with 3rd party applications such as Legato Networker on Irix, changes went in recently which adjust the inode placement policy of XFS to restrict inodes to the part of the filesystem which keeps them within 32 bits, unless the inode64 mount option is used. The fix is more complex than that as we need to make data prefer space not suitable for inodes to avoid filesystems which have lots of space but cannot create new files. The other aspect of how many inodes you can have is controlled via mkfs and growfs. Inode space is restricted to a default 20% of the disk space. So for a 1 Tbyte filesystem, the default maximum number of inodes you could have is around 850 million (inodes are 256 bytes by default). Since the largest addressable filesystem on Linux is currently 2 Tbytes, the maximum possible number of inodes with default mkfs options is twice that. Note that 4Gbytes of default inodes takes 1 Tbyte of disk storage for the inodes themselves, so the inode percentage would need to be upped to 50% for this to be theoretically possible. The theoretical maximum for XFS without the limits imposed by the Linux block and vfs layers is probably on the order of 2^6x which is a very very big number and would probably require the output of several major drive vendors for a long time to construct, around 115 million 160G drives by my calculation! 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 24 07:48:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OEmKwJ023135 for ; Wed, 24 Apr 2002 07:48:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OEmJTS023134 for linux-xfs-outgoing; Wed, 24 Apr 2002 07:48:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OElowJ023106 for ; Wed, 24 Apr 2002 07:47: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 JAA23466; Wed, 24 Apr 2002 09:47: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 JAA45251; Wed, 24 Apr 2002 09:47:45 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3OEiBx28458; Wed, 24 Apr 2002 09:44:11 -0500 Subject: Re: XFS slows down on used partions with bonnie++ From: Steve Lord To: Paul Schutte Cc: Paul Schutte , XFS mailing list In-Reply-To: <3CC67369.935DF3ED@up.ac.za> References: <3C94F14E.7DE5A62D@it.up.ac.za> <3CC67369.935DF3ED@up.ac.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 24 Apr 2002 09:44:11 -0500 Message-Id: <1019659451.27989.44.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Very interesting, I will take a look at this some more. One initial comment is that optimizing for bonnie is not necessarily the correct thing to do - not many real world loads create thousands of files and then immediately delete them. Plus, once you are on a raid device, logical and physical closeness on the volume no longer mean very much. Having said that we need to think some more about the underlying allocation policy of inodes vs file data here. I will run a broader set of tests on this and see what the impact is. Steve p.s. congrats on getting further into XFS than most people have! On Wed, 2002-04-24 at 03:57, Paul Schutte wrote: > The patch that I include here fixes the problem that I mentioned in my original > posting. > It should work on all 2.4.x kernels. > > I don't know how it will behave on IRIX, but linux gets a bit of a performance > boost. > It seemed faster or the same on all tests that I have run so far. > > The backup speed of my XFS servers got slower over time and that is why I chased > down > the problem. > > The results here are done on a different server than the one I used for my original > posting, so > you can not compare numeric values between the 2 postings. > > Here is before and after values done now on the same server now. > > BEFORE: > 1st run: > Version 1.02b ------Sequential Create------ --------Random Create-------- > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > 10:100000:1000/1000 222 8 170 4 1441 21 199 8 55 1 985 20 > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,222,8,170,4,1441,21,199,8,55,! > 0.320u 16.660s 6:00.93 4.7% 0+0k 0+0io 202pf+0w > > 2nd run: > Version 1.02b ------Sequential Create------ --------Random Create-------- > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > 10:100000:1000/1000 201 7 99 2 1168 16 204 7 54 1 989 22 > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,201,7,99,2,1168,16,204,7,54,1! > 0.400u 16.360s 6:49.92 4.0% 0+0k 0+0io 202pf+0w > > AFTER: > 1st run: > Version 1.02b ------Sequential Create------ --------Random Create-------- > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > 10:100000:1000/1000 224 8 176 4 1444 21 224 8 57 1 1084 19 > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,224,8,176,4,1444,21,224,8,57,! > 0.380u 15.700s 5:44.37 4.6% 0+0k 0+0io 202pf+0w > > 2nd run: > Version 1.02b ------Sequential Create------ --------Random Create-------- > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete-- > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > 10:100000:1000/1000 214 8 173 4 1367 20 222 8 57 1 1081 23 > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,214,8,173,4,1367,20,222,8,57,! > 0.350u 16.110s 5:49.39 4.7% 0+0k 0+0io 202pf+0w > > >From this we can see that the sequential read speed is wat is should be. > As a bonus we get a healthy increase in random create. > > Paul > > Paul Schutte wrote: > > > Hi, > > > > I have being playing around with bonnie++ from > > http://www.coker.com.au/bonnie++/ > > > > I found an interesting thing. > > > > When I run bonnie++ on a newly created XFS filesystem I get the > > following results: > > > > mkfs.xfs -f -l size=8192b /dev/sda7 > > > > meta-data=/dev/sda7 isize=256 agcount=19, agsize=262144 > > blks > > data = bsize=4096 blocks=4843589, imaxpct=25 > > > > = sunit=0 swidth=0 blks, unwritten=0 > > > > naming =version 2 bsize=4096 > > log =internal log bsize=4096 blocks=8192 > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > mount -o logbufs=8 /dev/sda7 /mnt > > > > cd /mnt > > > > /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 > > > > Version 1.02b ------Sequential Create------ --------Random > > Create-------- > > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- > > -Delete-- > > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > > /sec %CP > > 10:100000:1000/1000 206 8 154 3 1463 20 192 7 49 1 > > 1081 18 > > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,206,8,154,3,1463,20,192,7,49,1, > > > > 1081,18 > > 0.300u 15.540s 6:35.00 4.0% 0+0k 0+0io 215pf+0w > > > > /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 > > > > Version 1.02b ------Sequential Create------ --------Random > > Create-------- > > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- > > -Delete-- > > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > > /sec %CP > > 10:100000:1000/1000 196 7 83 1 1215 23 191 8 49 1 > > 1023 20 > > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,196,7,83,1,1215,23,191,8,49,1,1 > > > > 023,20 > > 0.370u 16.520s 7:31.92 3.7% 0+0k 0+0io 219pf+0w > > > > I created the file system. > > Run bonnie++ with the parameters as above. > > I run bonnie++ immediately for a second time. > > If you look at the sequential read field, you will see that it is nearly > > half the amount of the first run. > > According to this test XFS seems to lose sequential read speed as the > > filesystem gets used. > > You can umount and even reboot the machine and run bonnie++ again and > > still get the slowdown phenomenon, > > provided you mount the same filesystem again without mkfs'ing it. > > > > I repeated this test on several other machines with the same result. > > I also did it with other filesystems. > > > > Here is the result with ext2: > > > > Version 1.02b ------Sequential Create------ --------Random > > Create-------- > > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- > > -Delete-- > > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > > /sec %CP > > 10:100000:1000/1000 142 2 142 2 585 3 150 3 46 0 > > 430 2 > > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,142,2,142,2,585,3,150,3,46,0,43 > > > > 0,2 > > 0.240u 8.950s 7:56.63 1.9% 0+0k 0+0io 218pf+0w > > /mnt#time bonnie++ -u root -s0 -b -n 10:100000:1000:1000 > > Version 1.02b ------Sequential Create------ --------Random > > Create-------- > > kendy2.up.ac.za -Create-- --Read--- -Delete-- -Create-- --Read--- > > -Delete-- > > files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP > > /sec %CP > > 10:100000:1000/1000 154 3 143 3 540 2 152 2 47 0 > > 449 2 > > kendy2.up.ac.za,,,,,,,,,,,,,,10:100000:1000/1000,154,3,143,3,540,2,152,2,47,0,44 > > > > 9,2 > > 0.300u 9.080s 7:42.20 2.0% 0+0k 0+0io 220pf+0w > > > > No slow down. > > I can include results for reiserfs and JFS, but will add size to this > > message without adding additional info > > regarding this issue. > > > > The machine is a Dell PE2550 > > 1G RAM (I used mem=256M kernel param, otherwise everything runs from > > cache) > > 4x18G 15k RPM seagate cheethas in RAID 10 > > 2x1.133GHz P4 CPUs > > > > Regards > > > > Paul Schutte > ---- > > diff -ur linux/fs/xfs/xfs_ialloc.c /data/linux-2.4-xfs-ifix/linux/fs/xfs/xfs_ialloc.c > --- linux/fs/xfs/xfs_ialloc.c Sat Jan 12 01:43:26 2002 > +++ /data/linux-2.4-xfs-ifix/linux/fs/xfs/xfs_ialloc.c Wed Apr 24 00:36:54 2002 > @@ -815,20 +815,35 @@ > if ((error = xfs_inobt_lookup_eq(cur, > INT_GET(agi->agi_newino, ARCH_CONVERT), 0, 0, &i))) > goto error0; > + > + /* > + * It seems not te be a good idea to use the most recently > + * allocated block. If we do so, we end up using the inodes > + * at the back of the ag first and work our way to the front. > + * The data blocks on the other hand tend to be allocated from > + * the begining to the end of the ag. The avarage distance between > + * an inode and its data in terms of daddr is much longer if we do > + * it this way. The avarage distance between the inode and it's data > + * tend to be more constant and in general shorter if we allocate > + * inodes from the front of the ag to the back. > + * > + * Paul Schutte > + * > if (i == 1 && > (error = xfs_inobt_get_rec(cur, &rec.ir_startino, > &rec.ir_freecount, &rec.ir_free, &j, ARCH_NOCONVERT)) == 0 && > j == 1 && > rec.ir_freecount > 0) { > - /* > + * > * The last chunk allocated in the group still has > * a free inode. > - */ > + * > } > /* > * None left in the last group, search the whole a.g. > - */ > + > else { > + */ > if (error) > goto error0; > if ((error = xfs_inobt_lookup_ge(cur, 0, 0, 0, &i))) > @@ -847,7 +862,7 @@ > goto error0; > XFS_WANT_CORRUPTED_GOTO(i == 1, error0); > } > - } > + /* } Matches the most recently block code above */ > } > offset = XFS_IALLOC_FIND_FREE(&rec.ir_free); > ASSERT(offset >= 0); -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Apr 24 08:01:13 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OF1DwJ023500 for ; Wed, 24 Apr 2002 08:01:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OF1DhU023499 for linux-xfs-outgoing; Wed, 24 Apr 2002 08:01:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OF03wJ023452 for ; Wed, 24 Apr 2002 08:00:03 -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 KAA23865 for ; Wed, 24 Apr 2002 10:00:24 -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 KAA10537 for ; Wed, 24 Apr 2002 10:00:24 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3OEuoW28557; Wed, 24 Apr 2002 09:56:50 -0500 Message-Id: <200204241456.g3OEuoW28557@jen.americas.sgi.com> Date: Wed, 24 Apr 2002 09:56:50 -0500 Subject: TAKE - merge up to 2.5.9 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Since 2.5.10 came out I am throwing this over the fence. 2.5.10 will follow shortly. I can hang this xfs and it has not had a lot of testing, I will fix it up later, just playing catch up with Linus right now and avoiding tossing all the merge work I did and starting again. Date: Wed Apr 24 07:52:56 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:117279a linux/arch/x86_64/ia32/fpu32.c - 1.1 linux/include/asm-ia64/percpu.h - 1.1 linux/Documentation/filesystems/Exporting - 1.1 linux/include/asm-ia64/machvec_hpzx1.h - 1.1 linux/drivers/isdn/tpam/Config.help - 1.1 linux/drivers/isdn/icn/Config.in - 1.1 linux/drivers/isdn/icn/Config.help - 1.1 linux/drivers/isdn/i4l/isdn_x25iface.h - 1.1 linux/drivers/isdn/i4l/isdn_x25iface.c - 1.1 linux/drivers/isdn/i4l/isdn_v110.h - 1.1 linux/drivers/isdn/i4l/isdn_v110.c - 1.1 linux/drivers/isdn/i4l/isdn_ttyfax.h - 1.1 linux/drivers/isdn/i4l/isdn_ttyfax.c - 1.1 linux/drivers/isdn/i4l/isdn_tty.h - 1.1 linux/drivers/isdn/i4l/isdn_tty.c - 1.1 linux/drivers/isdn/i4l/isdn_ppp.h - 1.1 linux/drivers/isdn/i4l/isdn_ppp.c - 1.1 linux/drivers/isdn/i4l/isdn_net.h - 1.1 linux/include/asm-ia64/cacheflush.h - 1.1 linux/drivers/isdn/i4l/isdn_net.c - 1.1 linux/drivers/isdn/i4l/isdn_concap.h - 1.1 linux/include/asm-ia64/acpi.h - 1.1 linux/drivers/isdn/avmb1/Config.help - 1.1 linux/drivers/isdn/i4l/isdn_concap.c - 1.1 linux/drivers/isdn/i4l/isdn_common.h - 1.1 linux/fs/exportfs/Makefile - 1.1 linux/drivers/isdn/i4l/isdn_common.c - 1.1 linux/drivers/isdn/i4l/isdn_bsdcomp.c - 1.1 linux/fs/exportfs/expfs.c - 1.1 linux/arch/x86_64/kernel/bootflag.c - 1.1 linux/drivers/isdn/i4l/isdn_audio.h - 1.1 linux/drivers/isdn/i4l/isdn_audio.c - 1.1 linux/drivers/isdn/i4l/Makefile - 1.1 linux/include/asm-x86_64/cacheflush.h - 1.1 linux/include/asm-x86_64/fpu32.h - 1.1 linux/include/asm-x86_64/percpu.h - 1.1 linux/include/asm-arm/tlbflush.h - 1.1 linux/drivers/isdn/i4l/Config.in - 1.1 linux/drivers/isdn/i4l/Config.help - 1.1 linux/drivers/isdn/hysdn/Config.in - 1.1 linux/drivers/isdn/hysdn/Config.help - 1.1 linux/drivers/isdn/hisax/Config.in - 1.1 linux/drivers/isdn/hisax/Config.help - 1.1 linux/drivers/isdn/eicon/Config.in - 1.1 linux/drivers/isdn/eicon/Config.help - 1.1 linux/drivers/isdn/avmb1/Config.in - 1.1 linux/arch/ia64/hp/zx1/hpzx1_misc.c - 1.1 linux/drivers/isdn/act2000/Config.in - 1.1 linux/drivers/isdn/act2000/Config.help - 1.1 linux/include/asm-x86_64/sigcontext32.h - 1.1 linux/include/asm-arm/proc-armv/tlbflush.h - 1.1 linux/arch/x86_64/mm/modutil.c - 1.1 linux/arch/ia64/lib/copy_page_mck.S - 1.1 linux/include/asm-arm/proc-armo/tlbflush.h - 1.1 linux/include/asm-x86_64/tlbflush.h - 1.1 linux/arch/ia64/hp/sim/hpsim_ssc.h - 1.1 linux/arch/ia64/hp/zx1/hpzx1_machvec.c - 1.1 linux/arch/ia64/hp/zx1/Makefile - 1.1 linux/arch/ia64/hp/sim/hpsim_machvec.c - 1.1 linux/arch/ia64/hp/sim/hpsim_console.c - 1.1 linux/drivers/pcmcia/sa1100_trizeps.c - 1.1 linux/arch/ia64/hp/Config.in - 1.1 linux/include/asm-arm/cacheflush.h - 1.1 linux/arch/ia64/hp/sim/simserial.c - 1.1 linux/arch/ia64/hp/sim/simscsi.h - 1.1 linux/arch/ia64/hp/sim/simscsi.c - 1.1 linux/arch/ia64/hp/sim/simeth.c - 1.1 linux/arch/ia64/hp/sim/hpsim_setup.c - 1.1 linux/drivers/isdn/tpam/Config.in - 1.1 linux/arch/ia64/hp/sim/Makefile - 1.1 linux/include/asm-ia64/tlbflush.h - 1.1 linux/arch/ia64/hp/common/Makefile - 1.1 linux/arch/ia64/hp/sim/hpsim_irq.c - 1.1 linux/drivers/isdn/sc/Config.in - 1.1 linux/arch/x86_64/lib/thunk.S - 1.1 linux/drivers/isdn/pcbit/Config.help - 1.1 linux/drivers/isdn/pcbit/Config.in - 1.1 linux/arch/ia64/hp/common/sba_iommu.c - 1.1 linux/drivers/isdn/sc/Config.help - 1.1 linux/scripts/Configure - 1.14 linux/net/irda/ircomm/Makefile - 1.7 linux/mm/vmscan.c - 1.98 linux/mm/vmalloc.c - 1.37 linux/mm/swapfile.c - 1.55 linux/mm/page_alloc.c - 1.77 linux/mm/filemap.c - 1.117 linux/kernel/time.c - 1.10 linux/kernel/sys.c - 1.31 linux/kernel/sched.c - 1.66 linux/kernel/printk.c - 1.19 linux/kernel/ksyms.c - 1.142 linux/kernel/fork.c - 1.54 linux/kernel/exit.c - 1.44 linux/init/main.c - 1.78 linux/include/linux/tqueue.h - 1.10 linux/include/linux/smp.h - 1.13 linux/include/linux/signal.h - 1.6 linux/include/linux/sched.h - 1.66 linux/include/linux/proc_fs.h - 1.35 linux/include/linux/prctl.h - 1.8 linux/include/linux/nls.h - 1.7 linux/include/linux/interrupt.h - 1.18 linux/include/linux/hdreg.h - 1.19 linux/include/linux/fs.h - 1.167 linux/include/linux/fb.h - 1.22 linux/include/linux/dcache.h - 1.23 linux/include/linux/capability.h - 1.12 linux/include/linux/auto_fs.h - 1.7 linux/include/asm-ppc/bitops.h - 1.14 linux/include/asm-i386/pgtable.h - 1.32 linux/include/asm-i386/ioctls.h - 1.6 linux/include/asm-i386/hardirq.h - 1.18 linux/include/asm-i386/errno.h - 1.5 linux/include/asm-i386/bugs.h - 1.16 linux/include/asm-i386/bitops.h - 1.13 linux/include/asm-arm/mmu_context.h - 1.11 linux/include/asm-arm/io.h - 1.20 linux/include/asm-arm/arch-rpc/system.h - 1.14 linux/include/asm-arm/arch-nexuspci/system.h - 1.10 linux/include/asm-arm/arch-ebsa285/system.h - 1.14 linux/include/asm-arm/arch-ebsa110/system.h - 1.12 linux/include/asm-arm/arch-arc/system.h - 1.13 linux/include/asm-alpha/unistd.h - 1.19 linux/include/asm-alpha/siginfo.h - 1.6 linux/include/asm-alpha/mman.h - 1.4 linux/fs/super.c - 1.84 linux/fs/proc/base.c - 1.37 linux/fs/nls/nls_base.c - 1.11 linux/fs/nfsd/nfsfh.c - 1.40 linux/fs/nfsd/nfsctl.c - 1.31 linux/fs/nfsd/export.c - 1.34 linux/fs/fcntl.c - 1.18 linux/fs/fat/inode.c - 1.42 linux/fs/ext2/super.c - 1.30 linux/fs/ext2/namei.c - 1.24 linux/fs/ext2/inode.c - 1.46 linux/fs/exec.c - 1.56 linux/fs/dcache.c - 1.35 linux/fs/binfmt_misc.c - 1.23 linux/fs/Makefile - 1.54 linux/fs/Config.in - 1.84 linux/drivers/scsi/st.c - 1.41 linux/drivers/scsi/scsicam.c - 1.9 linux/drivers/scsi/scsi_debug.h - 1.7 linux/drivers/scsi/scsi_debug.c - 1.18 linux/drivers/scsi/ide-scsi.c - 1.32 linux/drivers/scsi/advansys.c - 1.26 linux/drivers/scsi/Makefile - 1.35 linux/drivers/sbus/char/Makefile - 1.11 linux/drivers/pnp/Makefile - 1.13 linux/drivers/net/eepro100.c - 1.44 linux/drivers/isdn/isdn_x25iface.h - 1.5 linux/drivers/isdn/isdn_x25iface.c - 1.7 linux/drivers/isdn/isdn_v110.h - 1.7 linux/drivers/isdn/isdn_v110.c - 1.10 linux/drivers/isdn/isdn_tty.h - 1.11 linux/drivers/isdn/isdn_tty.c - 1.20 linux/drivers/isdn/isdn_ppp.h - 1.9 linux/drivers/isdn/isdn_ppp.c - 1.23 linux/drivers/isdn/isdn_net.h - 1.11 linux/drivers/isdn/isdn_net.c - 1.28 linux/drivers/isdn/isdn_concap.h - 1.5 linux/drivers/isdn/isdn_concap.c - 1.8 linux/drivers/isdn/isdn_common.h - 1.10 linux/drivers/isdn/isdn_common.c - 1.35 linux/drivers/isdn/isdn_audio.h - 1.6 linux/drivers/isdn/isdn_audio.c - 1.12 linux/drivers/isdn/icn/Makefile - 1.5 linux/drivers/isdn/Makefile - 1.12 linux/drivers/isdn/Config.in - 1.24 linux/drivers/fc4/Makefile - 1.7 linux/drivers/char/tty_io.c - 1.43 linux/drivers/char/synclink.c - 1.25 linux/drivers/char/serial.c - 1.57 linux/drivers/char/rtc.c - 1.27 linux/drivers/char/nvram.c - 1.20 linux/drivers/char/n_hdlc.c - 1.14 linux/drivers/char/msbusmouse.c - 1.8 linux/drivers/char/console.c - 1.28 linux/drivers/char/Makefile - 1.56 linux/drivers/block/nbd.c - 1.36 linux/drivers/block/ll_rw_blk.c - 1.98 linux/drivers/acorn/scsi/acornscsi.c - 1.14 linux/drivers/acorn/scsi/Makefile - 1.8 linux/drivers/acorn/block/Makefile - 1.8 linux/arch/sparc64/solaris/Makefile - 1.5 linux/arch/sparc/config.in - 1.36 linux/arch/ppc/config.in - 1.49 linux/arch/mips/config.in - 1.29 linux/arch/i386/kernel/traps.c - 1.53 linux/arch/i386/kernel/setup.c - 1.73 linux/arch/i386/kernel/process.c - 1.47 linux/arch/i386/kernel/irq.c - 1.41 linux/arch/i386/kernel/io_apic.c - 1.36 linux/arch/i386/defconfig - 1.106 linux/arch/i386/config.in - 1.78 linux/arch/arm/kernel/traps.c - 1.27 linux/arch/arm/kernel/time.c - 1.15 linux/arch/arm/kernel/signal.c - 1.23 linux/arch/arm/kernel/setup.c - 1.28 linux/arch/arm/kernel/process.c - 1.26 linux/arch/arm/kernel/irq.c - 1.18 linux/arch/arm/kernel/entry-common.S - 1.21 linux/arch/arm/kernel/entry-armv.S - 1.28 linux/arch/arm/kernel/dma.c - 1.11 linux/arch/arm/kernel/armksyms.c - 1.26 linux/arch/arm/config.in - 1.39 linux/arch/arm/boot/compressed/head.S - 1.17 linux/arch/arm/boot/compressed/Makefile - 1.22 linux/arch/arm/boot/Makefile - 1.12 linux/arch/alpha/mm/init.c - 1.22 linux/arch/alpha/math-emu/Makefile - 1.6 linux/arch/alpha/kernel/signal.c - 1.14 linux/arch/alpha/kernel/ptrace.c - 1.14 linux/arch/alpha/kernel/process.c - 1.25 linux/arch/alpha/kernel/osf_sys.c - 1.29 linux/arch/alpha/config.in - 1.44 linux/Rules.make - 1.18 linux/Makefile - 1.194 linux/Documentation/ide.txt - 1.8 linux/include/linux/ide.h - 1.46 linux/drivers/video/cyber2000fb.c - 1.30 linux/drivers/isdn/isdn_bsdcomp.c - 1.8 linux/arch/arm/nwfpe/fpmodule.c - 1.11 linux/arch/arm/nwfpe/Makefile - 1.6 linux/drivers/parport/Makefile - 1.9 linux/drivers/char/logibusmouse.c - 1.6 linux/drivers/isdn/isdn_ttyfax.h - 1.4 linux/drivers/isdn/isdn_ttyfax.c - 1.8 linux/drivers/net/sis900.c - 1.32 linux/drivers/atm/Makefile - 1.16 linux/arch/alpha/kernel/semaphore.c - 1.7 linux/net/atm/Makefile - 1.10 linux/arch/arm/kernel/semaphore.c - 1.11 linux/arch/arm/kernel/bios32.c - 1.27 linux/include/asm-arm/cpu-single.h - 1.12 linux/include/asm-arm/cpu-multi32.h - 1.12 linux/include/asm-arm/cpu-multi26.h - 1.5 linux/drivers/scsi/ips.h - 1.12 linux/drivers/scsi/ips.c - 1.25 linux/drivers/pcmcia/Makefile - 1.14 linux/drivers/char/drm/Makefile - 1.13 linux/drivers/net/tokenring/olympic.c - 1.20 linux/arch/i386/kernel/pci-pc.c - 1.37 linux/include/linux/pci_ids.h - 1.64 linux/arch/arm/boot/compressed/head-netwinder.S - 1.5 linux/arch/arm/def-configs/victor - 1.3 linux/arch/arm/boot/compressed/vmlinux.lds.in - 1.5 linux/include/asm-arm/proc-armv/cache.h - 1.15 linux/include/asm-arm/proc-armo/cache.h - 1.9 linux/include/asm-arm/pci.h - 1.19 linux/include/asm-arm/arch-sa1100/system.h - 1.15 linux/include/linux/bfs_fs.h - 1.8 linux/fs/bfs/inode.c - 1.22 linux/fs/bfs/file.c - 1.19 linux/fs/bfs/dir.c - 1.20 linux/fs/bfs/bfs_defs.h - 1.5 linux/drivers/pci/pci.ids - 1.46 linux/include/asm-arm/pgalloc.h - 1.11 linux/include/asm-arm/arch-cl7500/system.h - 1.13 linux/include/asm-alpha/pgalloc.h - 1.15 linux/drivers/char/agp/Makefile - 1.6 linux/Documentation/usb/dc2xx.txt - 1.4 linux/arch/arm/boot/compressed/head-sa1100.S - 1.9 linux/arch/i386/kernel/mpparse.c - 1.18 linux/drivers/ieee1394/Makefile - 1.12 linux/arch/ia64/kernel/head.S - 1.11 linux/arch/ia64/kernel/semaphore.c - 1.8 linux/arch/ia64/kernel/entry.S - 1.24 linux/arch/ia64/kernel/efi.c - 1.13 linux/arch/ia64/kernel/acpi.c - 1.12 linux/arch/ia64/kernel/Makefile - 1.12 linux/arch/ia64/ia32/sys_ia32.c - 1.24 linux/arch/ia64/ia32/binfmt_elf32.c - 1.14 linux/arch/ia64/hp/hpsim_ssc.h - 1.2 linux/arch/ia64/hp/hpsim_setup.c - 1.5 linux/arch/ia64/hp/hpsim_machvec.c - 1.3 linux/arch/ia64/hp/hpsim_irq.c - 1.5 linux/arch/ia64/hp/hpsim_console.c - 1.5 linux/arch/ia64/hp/Makefile - 1.5 linux/arch/ia64/dig/setup.c - 1.8 linux/arch/ia64/vmlinux.lds.S - 1.11 linux/arch/ia64/defconfig - 1.15 linux/arch/ia64/config.in - 1.27 linux/arch/ia64/Makefile - 1.12 linux/arch/ia64/kernel/irq.c - 1.17 linux/arch/ia64/kernel/setup.c - 1.14 linux/arch/ia64/kernel/signal.c - 1.14 linux/arch/ia64/kernel/smp.c - 1.14 linux/arch/ia64/kernel/sys_ia64.c - 1.12 linux/arch/ia64/kernel/traps.c - 1.13 linux/arch/ia64/lib/Makefile - 1.9 linux/arch/ia64/kernel/ivt.S - 1.16 linux/arch/ia64/kernel/pci.c - 1.11 linux/arch/ia64/lib/do_csum.S - 1.6 linux/arch/ia64/kernel/process.c - 1.16 linux/arch/ia64/mm/tlb.c - 1.11 linux/arch/ia64/kernel/mca.c - 1.11 linux/arch/ia64/mm/init.c - 1.15 linux/arch/ia64/mm/fault.c - 1.10 linux/arch/ia64/lib/memset.S - 1.5 linux/include/asm-ia64/ide.h - 1.7 linux/include/asm-ia64/efi.h - 1.9 linux/include/asm-ia64/acpi-ext.h - 1.8 linux/include/asm-ia64/processor.h - 1.18 linux/include/linux/raid/md.h - 1.11 linux/include/asm-ia64/pgtable.h - 1.16 linux/include/asm-ia64/pgalloc.h - 1.11 linux/include/asm-ia64/machvec.h - 1.8 linux/include/asm-ia64/pci.h - 1.13 linux/include/asm-ia64/offsets.h - 1.14 linux/include/asm-ia64/machvec_init.h - 1.4 linux/include/asm-ia64/unistd.h - 1.19 linux/include/asm-ia64/uaccess.h - 1.9 linux/include/asm-ia64/system.h - 1.13 linux/include/asm-ia64/string.h - 1.5 linux/arch/arm/mm/consistent.c - 1.10 linux/arch/i386/kernel/microcode.c - 1.14 linux/Documentation/filesystems/devfs/README - 1.15 linux/Documentation/filesystems/devfs/ChangeLog - 1.21 linux/fs/devfs/util.c - 1.13 linux/drivers/scsi/pcmcia/Makefile - 1.6 linux/drivers/char/wdt977.c - 1.9 linux/arch/mips64/config.in - 1.20 linux/include/linux/usb.h - 1.34 linux/include/asm-ia64/hw_irq.h - 1.7 linux/drivers/ide/via82cxxx.c - 1.26 linux/drivers/ide/rz1000.c - 1.7 linux/drivers/ide/piix.c - 1.21 linux/drivers/ide/pdc4030.c - 1.14 linux/drivers/ide/pdc202xx.c - 1.18 linux/drivers/ide/ide.c - 1.50 linux/drivers/ide/ide-tape.c - 1.24 linux/drivers/ide/ide-proc.c - 1.17 linux/drivers/ide/ide-probe.c - 1.29 linux/drivers/ide/ide-floppy.c - 1.21 linux/drivers/ide/ide-features.c - 1.12 linux/drivers/ide/ide-dma.c - 1.25 linux/drivers/ide/ide-disk.c - 1.32 linux/drivers/ide/ide-cd.h - 1.12 linux/drivers/ide/ide-cd.c - 1.32 linux/drivers/ide/ht6560b.c - 1.8 linux/drivers/ide/dtc2278.c - 1.7 linux/drivers/ide/cmd640.c - 1.9 linux/drivers/ide/Makefile - 1.20 linux/drivers/ide/Config.in - 1.22 linux/net/ipv4/netfilter/Makefile - 1.14 linux/include/asm-arm/arch-shark/system.h - 1.6 linux/include/asm-arm/arch-shark/memory.h - 1.6 linux/drivers/usb/serial/keyspan_pda.c - 1.25 linux/drivers/usb/serial/ftdi_sio.c - 1.35 linux/drivers/usb/serial/usbserial.c - 1.34 linux/arch/ia64/kernel/smpboot.c - 1.9 linux/arch/ia64/kernel/minstate.h - 1.8 linux/drivers/s390/net/Makefile - 1.5 linux/drivers/s390/char/Makefile - 1.6 linux/arch/arm/def-configs/lusl7200 - 1.3 linux/drivers/s390/block/Makefile - 1.6 linux/Documentation/DocBook/kernel-hacking.tmpl - 1.9 linux/include/asm-arm/arch-l7200/system.h - 1.6 linux/fs/xfs/xfs_dmapi.c - 1.53 linux/fs/xfs/linux/xfs_super.c - 1.174 linux/fs/xfs/linux/xfs_ioctl.c - 1.59 linux/drivers/usb/storage/Makefile - 1.8 linux/include/asm-i386/i387.h - 1.7 linux/fs/jffs/Makefile - 1.5 linux/arch/i386/kernel/i387.c - 1.9 linux/arch/ia64/kernel/brl_emu.c - 1.4 linux/arch/ia64/kernel/ia64_ksyms.c - 1.11 linux/arch/ia64/kernel/unwind_i.h - 1.5 linux/drivers/mtd/Makefile - 1.8 linux/drivers/media/video/Makefile - 1.8 linux/drivers/media/radio/Makefile - 1.9 linux/arch/arm/boot/compressed/head-ftvpci.S - 1.3 linux/arch/arm/boot/compressed/head-l7200.S - 1.3 linux/arch/arm/tools/mach-types - 1.15 linux/arch/arm/def-configs/shark - 1.5 linux/arch/arm/mach-sa1100/Makefile - 1.9 linux/arch/arm/mach-shark/pci.c - 1.3 linux/arch/i386/kernel/bluesmoke.c - 1.18 linux/drivers/md/Makefile - 1.8 linux/fs/minix/itree_common.c - 1.9 linux/include/asm-arm/arch-tbox/system.h - 1.3 linux/include/asm-ia64/acpikcfg.h - 1.5 linux/include/asm-ia64/module.h - 1.7 linux/arch/arm/def-configs/sherman - 1.3 linux/arch/ia64/kernel/iosapic.c - 1.6 linux/arch/ia64/lib/swiotlb.c - 1.7 linux/fs/reiserfs/inode.c - 1.30 linux/arch/arm/boot/compressed/head-shark.S - 1.4 linux/arch/cris/config.in - 1.13 linux/arch/cris/drivers/ide.c - 1.11 linux/include/asm-arm/arch-integrator/system.h - 1.3 linux/drivers/net/wan/dscc4.c - 1.9 linux/arch/arm/boot/compressed/head-clps7500.S - 1.2 linux/net/bluetooth/Makefile - 1.2 linux/arch/arm/boot/compressed/head-integrator.S - 1.2 linux/fs/sysv/itree.c - 1.6 linux/drivers/net/dl2k.c - 1.12 linux/drivers/message/fusion/Makefile - 1.3 linux/drivers/ide/it8172.c - 1.6 linux/drivers/ide/amd74xx.c - 1.9 linux/arch/arm/mach-sa1100/sa1111.h - 1.5 linux/arch/arm/mach-sa1100/sa1111.c - 1.6 linux/arch/arm/mach-sa1100/pfs168.c - 1.6 linux/include/asm-arm/arch-anakin/system.h - 1.2 linux/arch/arm/mach-sa1100/neponset.c - 1.7 linux/drivers/ide/qd65xx.c - 1.7 linux/drivers/ide/ide-m8xx.c - 1.3 linux/drivers/pcmcia/sa1100_generic.c - 1.5 linux/drivers/pcmcia/sa1100.h - 1.3 linux/arch/arm/mach-sa1100/graphicsmaster.c - 1.7 linux/arch/arm/mach-sa1100/adsbitsy.c - 1.5 linux/include/asm-arm/arch-epxa10db/system.h - 1.2 linux/drivers/scsi/sym53c8xx_2/Makefile - 1.2 linux/fs/ext3/inode.c - 1.9 linux/include/linux/acpi_serial.h - 1.2 linux/fs/intermezzo/dir.c - 1.5 linux/fs/xfs_dmapi/dmapi_register.c - 1.11 linux/arch/arm/mm/proc-xscale.S - 1.6 linux/arch/arm/mm/minicache.c - 1.4 linux/arch/arm/boot/compressed/head-xscale.S - 1.2 linux/arch/arm/def-configs/iq80310 - 1.4 linux/arch/arm/mach-sa1100/system3.c - 1.5 linux/include/asm-arm/hardware/sa1111.h - 1.2 linux/include/asm-arm/arch-adifcc/system.h - 1.2 linux/include/asm-arm/arch-iop310/system.h - 1.2 linux/arch/arm/mach-clps711x/edb7211-mm.c - 1.3 linux/include/asm-arm/arch-clps711x/system.h - 1.2 linux/drivers/ide/ide-taskfile.c - 1.9 linux/drivers/video/neofb.c - 1.5 linux/arch/arm/Config.help - 1.8 linux/arch/ia64/Config.help - 1.5 linux/drivers/ide/Config.help - 1.9 linux/drivers/isdn/Config.help - 1.4 linux/drivers/pnp/pnpbios_core.c - 1.5 linux/include/linux/thread_info.h - 1.2 linux/Documentation/filesystems/porting - 1.6 linux/arch/x86_64/Config.help - 1.2 linux/arch/x86_64/Makefile - 1.2 linux/arch/x86_64/boot/setup.S - 1.2 linux/arch/x86_64/boot/video.S - 1.2 linux/arch/x86_64/config.in - 1.5 linux/arch/x86_64/defconfig - 1.4 linux/arch/x86_64/ia32/Makefile - 1.2 linux/arch/x86_64/ia32/ia32_binfmt.c - 1.3 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.4 linux/arch/x86_64/ia32/ia32_signal.c - 1.3 linux/arch/x86_64/ia32/ia32entry.S - 1.2 linux/arch/x86_64/ia32/ptrace32.c - 1.2 linux/arch/x86_64/ia32/sys_ia32.c - 1.2 linux/arch/x86_64/kernel/Makefile - 1.2 linux/arch/x86_64/kernel/apic.c - 1.2 linux/arch/x86_64/kernel/bluesmoke.c - 1.2 linux/arch/x86_64/kernel/cpuid.c - 1.2 linux/arch/x86_64/kernel/early_printk.c - 1.2 linux/arch/x86_64/kernel/entry.S - 1.3 linux/arch/x86_64/kernel/head.S - 1.2 linux/arch/x86_64/kernel/head64.c - 1.2 linux/arch/x86_64/kernel/i387.c - 1.2 linux/arch/x86_64/kernel/i8259.c - 1.2 linux/arch/x86_64/kernel/init_task.c - 1.2 linux/arch/x86_64/kernel/io_apic.c - 1.2 linux/arch/x86_64/kernel/irq.c - 1.2 linux/arch/x86_64/kernel/ldt.c - 1.2 linux/arch/x86_64/kernel/mpparse.c - 1.2 linux/arch/x86_64/kernel/mtrr.c - 1.2 linux/arch/x86_64/kernel/pci-dma.c - 1.2 linux/arch/x86_64/kernel/pci-irq.c - 1.2 linux/arch/x86_64/kernel/pci-pc.c - 1.2 linux/arch/x86_64/kernel/pci-x86_64.h - 1.2 linux/arch/x86_64/kernel/process.c - 1.3 linux/arch/x86_64/kernel/ptrace.c - 1.3 linux/arch/x86_64/kernel/semaphore.c - 1.2 linux/arch/x86_64/kernel/setup.c - 1.2 linux/arch/x86_64/kernel/setup64.c - 1.2 linux/arch/x86_64/kernel/signal.c - 1.3 linux/arch/x86_64/kernel/smp.c - 1.2 linux/arch/x86_64/kernel/smpboot.c - 1.3 linux/arch/x86_64/kernel/sys_x86_64.c - 1.2 linux/arch/x86_64/kernel/syscall.c - 1.2 linux/arch/x86_64/kernel/time.c - 1.3 linux/arch/x86_64/kernel/trampoline.S - 1.2 linux/arch/x86_64/kernel/traps.c - 1.2 linux/arch/x86_64/kernel/vsyscall.c - 1.3 linux/arch/x86_64/kernel/x8664_ksyms.c - 1.4 linux/arch/x86_64/lib/Makefile - 1.2 linux/arch/x86_64/lib/mmx.c - 1.2 linux/arch/x86_64/mm/Makefile - 1.2 linux/arch/x86_64/mm/fault.c - 1.3 linux/arch/x86_64/mm/init.c - 1.3 linux/arch/x86_64/mm/ioremap.c - 1.3 linux/arch/x86_64/tools/offset.c - 1.3 linux/arch/x86_64/vmlinux.lds - 1.2 linux/sound/drivers/mpu401/mpu401_uart.c - 1.4 linux/sound/core/seq/seq_queue.h - 1.3 linux/sound/core/seq/seq_queue.c - 1.4 linux/sound/core/seq/seq_midi_event.c - 1.4 linux/sound/core/seq/seq_midi.c - 1.3 linux/sound/core/seq/seq_dummy.c - 1.3 linux/sound/core/memory.c - 1.4 linux/sound/core/device.c - 1.4 linux/include/asm-x86_64/semaphore.h - 1.2 linux/include/asm-x86_64/segment.h - 1.2 linux/include/asm-x86_64/rwsem.h - 1.3 linux/include/asm-x86_64/rwlock.h - 1.2 linux/include/asm-x86_64/ptrace.h - 1.2 linux/include/asm-x86_64/processor.h - 1.2 linux/include/asm-x86_64/pgtable.h - 1.4 linux/include/asm-x86_64/pgalloc.h - 1.3 linux/include/asm-x86_64/pda.h - 1.3 linux/include/asm-x86_64/page.h - 1.3 linux/include/asm-x86_64/msr.h - 1.2 linux/include/asm-x86_64/mpspec.h - 1.2 linux/include/asm-x86_64/module.h - 1.2 linux/include/asm-x86_64/mmu_context.h - 1.3 linux/include/asm-x86_64/mman.h - 1.2 linux/include/asm-x86_64/ldt.h - 1.2 linux/include/asm-x86_64/kdebug.h - 1.2 linux/include/asm-x86_64/ipc.h - 1.2 linux/include/asm-x86_64/io_apic.h - 1.2 linux/include/asm-x86_64/io.h - 1.2 linux/include/asm-x86_64/ia32_unistd.h - 1.2 linux/include/asm-x86_64/ia32.h - 1.2 linux/include/asm-x86_64/i387.h - 1.2 linux/include/asm-x86_64/hw_irq.h - 1.2 linux/include/asm-x86_64/fixmap.h - 1.2 linux/include/asm-x86_64/elf.h - 1.2 linux/include/asm-x86_64/desc.h - 1.2 linux/include/asm-x86_64/current.h - 1.2 linux/include/asm-x86_64/checksum.h - 1.2 linux/include/asm-x86_64/calling.h - 1.2 linux/include/asm-x86_64/bugs.h - 1.2 linux/include/asm-x86_64/bitops.h - 1.3 linux/include/asm-x86_64/apicdef.h - 1.2 linux/include/asm-x86_64/apic.h - 1.2 linux/include/asm-x86_64/system.h - 1.3 linux/include/sound/core.h - 1.5 linux/include/sound/asound.h - 1.4 linux/include/asm-x86_64/sigcontext.h - 1.2 linux/include/asm-x86_64/siginfo.h - 1.2 linux/include/asm-x86_64/smp.h - 1.2 linux/include/asm-x86_64/user32.h - 1.2 linux/include/asm-alpha/thread_info.h - 1.2 linux/include/asm-x86_64/vsyscall.h - 1.2 linux/include/asm-x86_64/user.h - 1.2 linux/include/asm-x86_64/unistd.h - 1.3 linux/include/asm-x86_64/types.h - 1.2 linux/include/asm-x86_64/timex.h - 1.2 linux/include/asm-x86_64/thread_info.h - 1.2 linux/arch/ppc64/config.in - 1.4 linux/include/asm-arm/thread_info.h - 1.2 linux/arch/arm/boot/compressed/head-epxa10db.S - 1.2 linux/arch/arm/mm/abort-ev5ej.S - 1.3 linux/arch/arm/mach-footbridge/isa-irq.c - 1.2 linux/arch/arm/mm/tlb-v4wb.S - 1.3 linux/arch/arm/mach-sa1100/badge4.c - 1.3 linux/arch/arm/mm/tlb-v4.S - 1.3 linux/arch/arm/mm/tlb-v3.S - 1.3 linux/fs/jfs/jfs_metapage.c - 1.3 linux/include/asm-ia64/thread_info.h - 1.2 linux/Documentation/BK-usage/bk-kernel-howto.txt - 1.2 linux/arch/ia64/hp/simscsi.h - 1.2 linux/arch/ia64/hp/simserial.c - 1.2 linux/arch/ia64/hp/simscsi.c - 1.2 linux/arch/ia64/hp/simeth.c - 1.2 linux/lib/radix-tree.c - 1.2 linux/drivers/ide/ide-tcq.c - 1.2 linux/drivers/usb/image/Makefile - 1.2 linux/include/asm-i386/tlbflush.h - 1.2 linux/drivers/usb/class/audio.c - 1.2 linux/drivers/usb/class/cdc-acm.c - 1.2 linux/drivers/usb/core/devio.c - 1.2 linux/drivers/usb/core/hcd.c - 1.2 linux/drivers/usb/core/hcd.h - 1.2 linux/drivers/usb/core/hub.c - 1.2 linux/include/asm-arm/arch-pxa/system.h - 1.2 linux/drivers/usb/core/usb.c - 1.2 linux/drivers/usb/host/ehci-dbg.c - 1.2 linux/drivers/usb/host/ehci-hcd.c - 1.2 linux/drivers/usb/host/ehci-hub.c - 1.2 linux/drivers/usb/host/ehci-mem.c - 1.2 linux/drivers/usb/host/ehci-q.c - 1.2 linux/drivers/usb/host/ehci-sched.c - 1.2 linux/drivers/usb/host/ohci-dbg.c - 1.2 linux/drivers/usb/host/ohci-hcd.c - 1.2 linux/drivers/usb/host/ohci-hub.c - 1.2 linux/drivers/usb/host/uhci.c - 1.2 linux/drivers/usb/host/usb-ohci.c - 1.2 linux/drivers/usb/host/usb-uhci.c - 1.2 linux/drivers/usb/image/Config.help - 1.2 linux/drivers/usb/image/Config.in - 1.2 linux/drivers/usb/image/dc2xx.c - 1.2 linux/drivers/video/anakinfb.c - 1.2 linux/drivers/usb/net/usbnet.c - 1.2 linux/drivers/usb/net/rtl8150.c - 1.2 linux/drivers/usb/net/pegasus.h - 1.2 linux/drivers/usb/net/pegasus.c - 1.2 linux/drivers/usb/net/kaweth.c - 1.2 linux/drivers/usb/net/catc.c - 1.2 linux/drivers/usb/net/Config.in - 1.2 linux/drivers/usb/misc/tiglusb.c - 1.2 From owner-linux-xfs@oss.sgi.com Wed Apr 24 08:03:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OF3EwJ023615 for ; Wed, 24 Apr 2002 08:03:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OF3E2k023614 for linux-xfs-outgoing; Wed, 24 Apr 2002 08:03: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 g3OF2wwJ023571 for ; Wed, 24 Apr 2002 08:02:58 -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 KAA20525; Wed, 24 Apr 2002 10:03:18 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA95067; Wed, 24 Apr 2002 10:03:18 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3OExic28576; Wed, 24 Apr 2002 09:59:44 -0500 Subject: Re: UPDATE: low-level XFS drive recovery From: Steve Lord To: Adam Milazzo Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <44D5677E9B8478468DE31AE26DF0AFD6077C92@adsl-64-165-6-11.dsl.sndg02.pacbell. net> References: <44D5677E9B8478468DE31AE26DF0AFD6077C92@adsl-64-165-6-11.dsl.sndg02.pacbell. net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 24 Apr 2002 09:59:44 -0500 Message-Id: <1019660384.27989.56.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk OK, but on you bullet proof vest and thermally insulated gloves.... Try this for starters: mount -o ro,norecovery It will skip processing the log. You can try copying files out of the filesystem, hopefully it is in good enough state to open directories and copy data out of files. It may crash in the process, or if it finds corruption it may shutdown the filesystem. In that case umount it and mount it again with the same options, and avoid the paths which caused the problems. Get as much data out this way as you can, you cannot make anything worse with this. Next run xfs_repair -L (no -n) those files it said it would trash will probably get put in lost+found by repair, it might actually keep all of your data. Steve On Tue, 2002-04-23 at 22:45, Adam Milazzo wrote: > After running xfs_repair -n, I get some stuff that looks like this: > entry "backup" in directory inode 128 points to free inode 12583040, would > junk entry > entry "desktop" in directory inode 128 points to free inode 16777344, would > junk entry > entry "t" in directory inode 128 points to free inode 33554240, would junk > entry > ...as well as others... > These are exactly the three directories I need to recover!! > > However, from the look of the message, it seems like it's going to "junk" > the entry, > making it more difficult to recover. > > I'm thinking that directory inode 128 is the root directory, and the inodes > mentioned > are the directory inodes of those subdirectories. Is there a way (using > xfs_db > perhaps?) to get the inodes and/or extents of the files in those > directories? > > Could I use this information to recover my files (note that there is > important > information regarding the situation in my original post, below)? > > I'm trying to figure out how to use xfs_db to do this... > > If anybody would be kind enough to give me a few instructions on this, or > point me to > some documentation about the format of the directory inodes (whatever I > would need to > get at the file extents), I would greatly appreciate it. > > Thanks in advance, > Adam M. > > -----Original Message----- > From: Adam Milazzo > To: 'linux-xfs@oss.sgi.com' > Sent: 4/23/2002 12:36 PM > Subject: low-level XFS drive recovery > > In a bout of impatient, early-morning foolishness, while trying to > quickly "format" /dev/hda1 (mounted under /mnt), I did an 'rm -rf /*' > from a chroot'd shell, but didn't realize until I pressed Enter, that I > had /dev/hdb1 mounted. However, it was too late, as the second drive was > nearly instantly wiped clean, taking with it all my important stuff! So > I went to bed. > > I learned a few lessons, like making better use of 'mount -o ro'. > However, the damage was already done and I am trying to restore the data > on that drive. I know that the XFS FAQ claims that there's no way to > undelete, and that's understandable. However, I might be in luck in this > case. The drive was freshly formatted and had a number of large files > copied to it from another drive, and no writing/deleting was done after > that point (except when it was deleted by rm -rf). Also, no writing has > been done since the deletion. My hope is that the files are [still] in > contiguous blocks on the disk. > > My first question is: How likely is it that after writing some (rather > large, 100 meg average, but up to 700 meg) files to a freshly formatted > XFS partition, that they would be in contiguous blocks? > > Second: after the rm -rf /* recursed into that drive's mount point and > did it's dirty work, is there anything left of the directory structure? > Or was that all wiped out? > > I dumped the first 8 gigs of the drive to a file on another drive, and > am writing a program to scan that dump file and attempt to pull out > anything that looks like a data file (basically by scanning for valid > file headers). However, it's slow work, and is almost useless if the > files are not stored in a single contiguous blocks (hence my first > question). Also, if there's anything left of the directory structure > that I could use to find where files begin and the filename, that would > be very helpful. > > Perhaps it's relatively trivial to restore the entire drive just by > rebuilding the directory structure, given the special circumstances of > my situation. Or perhaps the entire thing would be extremely difficult > because the files are broken up. > > So, if anybody could provide some information that would be helpful, > and/or point me to some good information on the low-level details of the > filesystem structure that might be useful in aiding my recovery of the > data (or giving me enough information that I can deem it pointless > without going through all the work), it would be greatly appreciated. > > Also, does anybody know of a good hex editor (or sector editor)? I'm > looking for the following features (In decreasing order of importance): > * Fast searching of text and binary data > * Ability to open huge files (>2gb) > * A display of the word, dword, and maybe quadword value that begins at > the byte under the cursor. > * Ability to select a chunk of data and save it to a disk (directly, or > in a round-about way) > * A built-in calculator? > > curses-based would be okay, but something for gnome/X would be nice. > > Thanks a lot in advance! > Adam M. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Apr 24 08:08: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 g3OF8VwJ023889 for ; Wed, 24 Apr 2002 08:08:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OF8VAZ023888 for linux-xfs-outgoing; Wed, 24 Apr 2002 08:08:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from thor.goeci.com (thor.goeci.com [216.181.40.16]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OF8RwJ023862 for ; Wed, 24 Apr 2002 08:08:27 -0700 Received: by THOR with Internet Mail Service (5.5.2650.21) id ; Wed, 24 Apr 2002 11:08:47 -0400 Message-ID: From: Murthy Kambhampaty To: "'Mike Burger'" , Florin Andrei Cc: linux-xfs@oss.sgi.com Subject: RE: /dev/null coming up as chmod 600 at boot? Date: Wed, 24 Apr 2002 11:08:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wednesday, April 24, 2002 09:32, Mike Burger wrote: > It was a clean install, actually...with the 7.1 ISO set (when > that was the > current set). The only things I've upgraded are on a package > by package > basis, including the kernels. It's amazing how much crud you can avoid installing if you do a select individual packages for installation. (I don't usually go through every branch, looking for packages to select/"deselect", but I certainly do make sure that emacs is out and Vim is in (BTW, that's not a polemic), along with some other stuff I'm interested in/concerned about.) Murthy PS: The above message may contain spelling errors. They may or may not reflect my English language silkls. From owner-linux-xfs@oss.sgi.com Wed Apr 24 08:19:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OFJlwJ024245 for ; Wed, 24 Apr 2002 08:19:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OFJltg024244 for linux-xfs-outgoing; Wed, 24 Apr 2002 08:19:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OFJfwJ024214 for ; Wed, 24 Apr 2002 08:19:41 -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 KAA24192; Wed, 24 Apr 2002 10:20:01 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA32575; Wed, 24 Apr 2002 10:20:01 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3OFGRo31639; Wed, 24 Apr 2002 10:16:27 -0500 Subject: Re: Still Another Oops, and I'm Stumped From: Steve Lord To: Danny Cox Cc: XFS Mailing List In-Reply-To: <1019651131.1144.17.camel@wiley> References: <1019651131.1144.17.camel@wiley> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 24 Apr 2002 10:16:27 -0500 Message-Id: <1019661387.28018.61.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-04-24 at 07:25, Danny Cox wrote: > Different machine from yesterday ;-). > > We have a machine with root mirrored across many (11) drives. We > pulled one drive while it was resyncing a drive ("stress test" ;-), > rebooted, and shoved it back in. XFS oopsed during mount, attempting to > recover the FS. Interpreted oops (actually 3 of 'em) attached. Ideas? > > I know: "if it hurts, DON'T DO THAT!". > > Other data: XFS is from a few weeks back (~ 19-Mar), 2.4.18 kernel. MD > is version 0.90, included in the kernel. > > Thanks! > Try updating the xfs_support directory current with CVS. There was a fix in there recently to avoid freeing things the wrong way. A kdb enabled kernel and a backtrace from that would help some more too. 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 24 08:26: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 g3OFQYwJ025295 for ; Wed, 24 Apr 2002 08:26:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OFQY5G025294 for linux-xfs-outgoing; Wed, 24 Apr 2002 08:26:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from imf13bis.bellsouth.net (mail213.mail.bellsouth.net [205.152.58.153]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OFQTwJ025268 for ; Wed, 24 Apr 2002 08:26:29 -0700 Received: from taz ([65.81.168.225]) by imf13bis.bellsouth.net (InterMail vM.5.01.04.05 201-253-122-122-105-20011231) with SMTP id <20020424152816.QAQG16252.imf13bis.bellsouth.net@taz>; Wed, 24 Apr 2002 11:28:16 -0400 Date: Wed, 24 Apr 2002 11:24:16 -0400 From: Greg Freemyer Subject: re[2]: XFS slows down on used partions with bonnie++ To: Steve Lord , Paul Schutte cc: XFS mailing list Mime-Version: 1.0 Organization: The NorcrossGroup X-Mailer: GoldMine [5.70.11111] Content-Type: Text/plain Message-Id: <20020424152816.QAQG16252.imf13bis.bellsouth.net@taz> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3OFQUwJ025269 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >> Plus, once you are on a raid device, >> logical and physical closeness on the volume no longer mean very much. Don't they? I would have thought: Raid 0: physical distance = logical distance / spindles Raid 1: physical distance = logical distance Raid 1 + 0: physical distance = logical distance / spindles / 2 Raid 5: physical distance = logical distance / (spindles - 1) Certainly caches and elevator seeks can come into play, but it still seems worth considering the physical distance. The only array I know of that would not work basically like the above is Compaq's really high-end EVA system. I'm sure there are others, but I have to believe the vast majority of arrays use a very simple block layout. Greg Freemyer Internet Engineer Deployment and Integration Specialist Compaq ASE - Tru64 Compaq Master ASE - SAN Architect The Norcross Group www.NorcrossGroup.com From owner-linux-xfs@oss.sgi.com Wed Apr 24 09:22:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OGMYwJ026111 for ; Wed, 24 Apr 2002 09:22:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OGMYJf026110 for linux-xfs-outgoing; Wed, 24 Apr 2002 09:22:34 -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 g3OGM4wJ026081 for ; Wed, 24 Apr 2002 09:22:15 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy.up.ac.za with esmtp (Exim 3.15 #1) id 170PRx-0006Lo-00; Wed, 24 Apr 2002 18:16:57 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 170PRw-0004SY-00; Wed, 24 Apr 2002 18:16:56 +0200 Message-ID: <3CC6DA78.2AEAB9EB@up.ac.za> Date: Wed, 24 Apr 2002 18:16:56 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-ifix-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Paul Schutte , XFS mailing list Subject: Re: XFS slows down on used partions with bonnie++ References: <3C94F14E.7DE5A62D@it.up.ac.za> <3CC67369.935DF3ED@up.ac.za> <1019659451.27989.44.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *170PRw-0004SY-00*nOsZfvA/DuI* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > Very interesting, I will take a look at this some more. One initial > comment is that optimizing for bonnie is not necessarily the correct Agreed. Bonnie was just convenient to illustrate the problem that I observed. I saw this the first time after I removed a kernel source tree. It felt a lot slower after that. It was only then that I started paying attention to the bonnie output. > > thing to do - not many real world loads create thousands of files and > then immediately delete them. Plus, once you are on a raid device, > logical and physical closeness on the volume no longer mean very much. > This is another thing that is bothering me. If you create a filesystem with only one AG all the benchmarks, tars, cps and whatever you can dream up is a lot faster. I concluded that the seeks accross to other allocation groups was killing performance. XFS with 1 AG performs similar to jfs and reiserfs on random read/write. (Actually out performs them) XFS with the same amount of AG's as ext2 and ext3 performs similar to ext2/ext3 on random read/write. (Again outperforming them) If you always use XFS with 1 AG (This would be usefull for a desktop - AGs keeps the fragmentation down. It's not that important on a desktop), there's a few problems: 1) You can't create filesystems bigger than 4G (4G should be enough 4 desktop) 2) You can't xfs_repair it. There is only one superblock and xfs_repair won't work if it can't find a backup superblock. Another drawback on having many AGs is that the superblocks in al the AGs needs to be updated ? This makes the disk head seek all over the platter. I found that in real life more AGs tend to be slower, but more fragmentation resistant and thus be faster as time goes by. RAID devices don't seem to make much of a difference to these observations. > > Having said that we need to think some more about the underlying > allocation policy of inodes vs file data here. > Implimenting the core.format =local for regular files would be a nice start ;-) This would REALLY make XFS fly for very small files. Are there any plans to do this ? > > I will run a broader set of tests on this and see what the impact is. > > Steve > > p.s. congrats on getting further into XFS than most people have! > From owner-linux-xfs@oss.sgi.com Wed Apr 24 09:25: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 g3OGPSwJ026290 for ; Wed, 24 Apr 2002 09:25:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OGPSLf026289 for linux-xfs-outgoing; Wed, 24 Apr 2002 09:25:28 -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 g3OGPIwJ026250 for ; Wed, 24 Apr 2002 09:25:18 -0700 Received: (qmail 11251 invoked by uid 500); 24 Apr 2002 16:25:19 -0000 Subject: Re: re[2]: XFS slows down on used partions with bonnie++ From: Austin Gonyou To: Greg Freemyer Cc: Steve Lord , Paul Schutte , XFS mailing list In-Reply-To: <20020424152816.QAQG16252.imf13bis.bellsouth.net@taz> References: <20020424152816.QAQG16252.imf13bis.bellsouth.net@taz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-aUPb5l3ol+BFSP0TjAT9" X-Mailer: Ximian Evolution 1.0.3.99 Date: 24 Apr 2002 11:25:19 -0500 Message-Id: <1019665519.11079.30.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-aUPb5l3ol+BFSP0TjAT9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I think for the puropose of this disucussion we should assume a type of files. (large contiguous, versus smaller un-contiguous) The way the data is access differes on the type of files as well. If you are using hardware RAID, this is true with most raid devices. Even in a SAN, wher you might have several disk trays and say 2 controllers, or a single head-unit with 2 controllers enclosed using either FCAL or FABRIC. Most read-ahead on RAID devices are adaptive by default, unless you're tweaking it. Also, in the case of something like RAID3, you'll have pretty stellar performance if you're using those large contiguous files, versus if you tried to use smaller contiguous or un-contiguous files, your overall performance would dump out. On Wed, 2002-04-24 at 10:24, Greg Freemyer wrote: > >> Plus, once you are on a raid device, > >> logical and physical closeness on the volume no longer mean very > much. >=20 > Don't they? >=20 > I would have thought: >=20 > Raid 0: physical distance =3D logical distance / spindles > Raid 1: physical distance =3D logical distance > Raid 1 + 0: physical distance =3D logical distance / spindles / 2 > Raid 5: physical distance =3D logical distance / (spindles - 1) >=20=20 > Certainly caches and elevator seeks can come into play, but it still > seems worth considering the physical distance. >=20 > The only array I know of that would not work basically like the above is > Compaq's really high-end EVA system. >=20 > I'm sure there are others, but I have to believe the vast majority of > arrays use a very simple block layout. >=20 > Greg Freemyer > Internet Engineer > Deployment and Integration Specialist > Compaq ASE - Tru64 > Compaq Master ASE - SAN Architect > The Norcross Group > www.NorcrossGroup.com >=20 --=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 --=-aUPb5l3ol+BFSP0TjAT9 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 iD8DBQA8xtxv94g6ZVmFMoIRAhFtAKCwkkGH0jN3+j4LP77HLRFkG69iRQCffL36 0Oz+mJomNLhuvbgUkiNvKFk= =y7/z -----END PGP SIGNATURE----- --=-aUPb5l3ol+BFSP0TjAT9-- From owner-linux-xfs@oss.sgi.com Wed Apr 24 09:51:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OGp9wJ026629 for ; Wed, 24 Apr 2002 09:51:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OGp9qN026628 for linux-xfs-outgoing; Wed, 24 Apr 2002 09:51:09 -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 g3OGoqwJ026592 for ; Wed, 24 Apr 2002 09:50:52 -0700 Received: (qmail 11310 invoked by uid 500); 24 Apr 2002 16:50:53 -0000 Subject: Re: XFS slows down on used partions with bonnie++ From: Austin Gonyou To: Paul Schutte Cc: Steve Lord , Paul Schutte , XFS mailing list In-Reply-To: <3CC6DA78.2AEAB9EB@up.ac.za> References: <3CC6DA78.2AEAB9EB@up.ac.za> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Kvu6J7lSKRyweXpR/YLY" X-Mailer: Ximian Evolution 1.0.3.99 Date: 24 Apr 2002 11:50:53 -0500 Message-Id: <1019667053.11079.46.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-Kvu6J7lSKRyweXpR/YLY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2002-04-24 at 11:16, Paul Schutte wrote: > Steve Lord wrote: >=20 > > Very interesting, I will take a look at this some more. One initial > > comment is that optimizing for bonnie is not necessarily the correct >=20 > Agreed. > Bonnie was just convenient to illustrate the problem that I observed. > I saw this the first time after I removed a kernel source tree. > It felt a lot slower after that. > It was only then that I started paying attention to the bonnie output. I saw similar things with IOZone and dbench when using XFS and LVM. The things about that though, is there are some bdflush fixes that I incorporated from the -AA tree that allayed the problem, but only for a short time. Further tweaks were necessary to actually get to a point where the problem was minimized and some sort of balance was reached.=20 This test was done on a Dell 6450, 8GB RAM, and 270GB of Disks. Four RAID0 devices.(sda 3x36, sdb 3x36, sdc 1x36,sde 1x36) >=20 > > > > thing to do - not many real world loads create thousands of files and > > then immediately delete them. Plus, once you are on a raid device, > > logical and physical closeness on the volume no longer mean very much. > > >=20 > This is another thing that is bothering me. > If you create a filesystem with only one AG all the benchmarks, tars, > cps and > whatever you can dream up is a lot faster. >=20 Hrmm....that might be true as well. Though bdflush, in test cases with 2.4.17 and 2.4.18 + XFS, seems to really take a beating. Perhaps it is caused by that in some way? > I concluded that the seeks accross to other allocation groups was > killing performance. > XFS with 1 AG performs similar to jfs and reiserfs on random read/write. > (Actually out performs them) > XFS with the same amount of AG's as ext2 and ext3 performs similar to > ext2/ext3 > on random read/write. > (Again outperforming them) >=20 > If you always use XFS with 1 AG (This would be usefull for a desktop - > AGs keeps the fragmentation down. It's not that important on a > desktop), there's a few problems: >=20 > 1) You can't create filesystems bigger than 4G (4G should be enough 4 > desktop) I disagree..in the realm of 100GB disks, people may want to take 2 or 4 of them, striped, and create large archives of their music, or videos, or perhaps a cheap, technically unimportant file server for low cost. Using something like, MD, LVM, or EVMS to create volumes of say 100GB in size at a time, on a desktop. > 2) You can't xfs_repair it. There is only one superblock and xfs_repair > won't work if it can't find a backup superblock. >=20 Well..enough said on that. What's the point of redundancy in the FS, if you can't repair your SB? > Another drawback on having many AGs is that the > superblocks in al the AGs needs to be updated ? > This makes the disk head seek all over the platter. > I found that in real life more AGs tend to be slower, but more > fragmentation resistant and thus be faster as time goes by. >=20 > RAID devices don't seem to make much of a difference to these > observations. > I disagree slightly, only given that I can increase my speed about 2x by usin LVM or EVMS, and XFS. (throughput numbers collected using IOZone and Dbench) Though repeatability of the same test over and over, without unmounting/remounting seems to decline as time goes on.=20 =20 > > > > Having said that we need to think some more about the underlying > > allocation policy of inodes vs file data here. > > >=20 > Implimenting the core.format =3Dlocal for regular files would be a nice > start ;-) > This would REALLY make XFS fly for very small files. > Are there any plans to do this ? >=20 > > > > I will run a broader set of tests on this and see what the impact is. I would like to see what you use to test and what testing you do. I've got a test bed I could lend with for corroberation of these tests possibly. > > > > Steve > > > > p.s. congrats on getting further into XFS than most people have! > > --=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 --=-Kvu6J7lSKRyweXpR/YLY 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 iD8DBQA8xuJt94g6ZVmFMoIRAuFsAJ9xxXvv+tJ2aeDYm6Mmwrs9rG47vQCfQFeS ysEEsgql8XlcprMRQ1RRnnA= =Qzq0 -----END PGP SIGNATURE----- --=-Kvu6J7lSKRyweXpR/YLY-- From owner-linux-xfs@oss.sgi.com Wed Apr 24 09:59:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OGxGwJ026917 for ; Wed, 24 Apr 2002 09:59:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OGxGUi026916 for linux-xfs-outgoing; Wed, 24 Apr 2002 09:59:16 -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-d514e17b.dsl.mediaWays.net [213.20.225.123]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OGxBwJ026890 for ; Wed, 24 Apr 2002 09:59:12 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 170Q75-0003nJ-00; Wed, 24 Apr 2002 18:59:27 +0200 Message-ID: <3CC6E46F.40CD835E@berdmann.de> Date: Wed, 24 Apr 2002 18:59:27 +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: Ian Cumming CC: linux-xfs@oss.sgi.com Subject: Re: xfsdump query References: <20020423144706.GA13525@ids.org.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > just a few queries about xfsdump. > > 1. does it back up ACL's, or will I need to back them up separately? it does > 2. does it support incremental backups to a file on disk? ie: > > xfsdump -l 0 -f /mnt/backup/var_dump /var > xfsudmp -l 1 -f /mnt/backup/var_dump /var > > This fails, with: > xfsdump: ERROR: media contains valid xfsdump but does not support append dump to different files From owner-linux-xfs@oss.sgi.com Wed Apr 24 10:53:43 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OHrhwJ001758 for ; Wed, 24 Apr 2002 10:53:43 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OHrh50001757 for linux-xfs-outgoing; Wed, 24 Apr 2002 10:53:43 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtp4.9tel.net (smtp.9tel.net [213.203.124.147]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OHrawJ001722 for ; Wed, 24 Apr 2002 10:53:37 -0700 Received: from ifrance.com (242.101-30-212.9massy1-1-ro-as-i1-2.9tel.net [212.30.101.242]) by smtp4.9tel.net (Postfix) with ESMTP id 179825C24A; Wed, 24 Apr 2002 19:21:33 +0200 (CEST) Message-ID: <1869720024324171747979@ifrance.com> X-EM-Version: 5, 0, 0, 21 X-EM-Registration: #01B0530810E603002D00 X-Priority: 3 Reply-To: sondageexpress1@ifrance.com To: "-" From: "SondageExpress" Subject: =?iso-8859-1?Q?Le_dernier_sondage_avant_les_=E9l=E9ctions_pr=E9sidentielles_2002_!?= Date: Wed, 24 Apr 2002 19:17:47 +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 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Apr 24 10:56: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 g3OHunwJ001945 for ; Wed, 24 Apr 2002 10:56:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OHun40001944 for linux-xfs-outgoing; Wed, 24 Apr 2002 10:56:49 -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 g3OHujwJ001916 for ; Wed, 24 Apr 2002 10:56:45 -0700 Received: from Francis (bozo@[209.47.40.10]) by mailnet.consensys.com (8.11.6/8.11.2) with SMTP id g3OCm4832647 for ; Wed, 24 Apr 2002 12:48:05 GMT Message-ID: <000a01c1ebb9$7b140030$8d02a8c0@consensys.com> From: "Francis Qu" To: "Linux XFS" Subject: DMAPI dm_handle_to_path Date: Wed, 24 Apr 2002 13:57:20 -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 Sometimes we want to obtain the path without knowing parent handle. A single file/dir object handle is sufficient in getting it's full path name. Thus makes the arguments parent dir handle unnecessary? I create my own version of handle_to_path by using only object handle. Regards, Francis [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Wed Apr 24 11:31: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 g3OIVnwJ005634 for ; Wed, 24 Apr 2002 11:31:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OIVngF005633 for linux-xfs-outgoing; Wed, 24 Apr 2002 11:31: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 g3OIVNwJ005597 for ; Wed, 24 Apr 2002 11:31:23 -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 NAA24033 for ; Wed, 24 Apr 2002 13:31:44 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA06977 for ; Wed, 24 Apr 2002 13:31:44 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3OIS8h08635; Wed, 24 Apr 2002 13:28:08 -0500 Message-Id: <200204241828.g3OIS8h08635@jen.americas.sgi.com> Date: Wed, 24 Apr 2002 13:28:08 -0500 Subject: TAKE - merge up to 2.5.10 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Lets hope Linus is done for a day or so now! Still to come are a fix for a memory deadlock under load and the new nfs export interface. Steve Date: Wed Apr 24 11:28:07 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-merge.2.5 The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:117310a linux/drivers/isdn/hardware/avm/avm_cs.c - 1.1 linux/drivers/usb/misc/brlvger.c - 1.1 linux/drivers/isdn/hardware/avm/t1pci.c - 1.1 linux/Documentation/usb/brlvger.txt - 1.1 linux/drivers/usb/serial/keyspan_usa19qi_fw.h - 1.1 linux/drivers/isdn/hardware/avm/t1isa.c - 1.1 linux/drivers/isdn/hardware/avm/c4.c - 1.1 linux/drivers/isdn/hardware/avm/b1pcmcia.c - 1.1 linux/include/linux/isdn/capilli.h - 1.1 linux/include/linux/brlvger.h - 1.1 linux/drivers/isdn/hardware/avm/Config.in - 1.1 linux/drivers/isdn/capi/Config.help - 1.1 linux/drivers/usb/serial/keyspan_usa19qw_fw.h - 1.1 linux/drivers/isdn/capi/Config.in - 1.1 linux/drivers/isdn/capi/Makefile - 1.1 linux/drivers/isdn/hardware/avm/b1pci.c - 1.1 linux/drivers/isdn/hardware/avm/b1isa.c - 1.1 linux/drivers/isdn/hardware/avm/b1dma.c - 1.1 linux/include/linux/isdn/capiutil.h - 1.1 linux/include/linux/isdn/capidev.h - 1.1 linux/drivers/isdn/hardware/avm/b1.c - 1.1 linux/drivers/isdn/hardware/avm/avmcard.h - 1.1 linux/include/linux/isdn/capicmd.h - 1.1 linux/drivers/isdn/hardware/avm/Makefile - 1.1 linux/drivers/isdn/capi/capi.c - 1.1 linux/drivers/isdn/hardware/Makefile - 1.1 linux/drivers/isdn/hardware/Config.in - 1.1 linux/drivers/isdn/capi/kcapi.c - 1.1 linux/drivers/isdn/capi/capidrv.c - 1.1 linux/drivers/isdn/capi/capiutil.c - 1.1 linux/drivers/isdn/capi/capifs.h - 1.1 linux/drivers/isdn/capi/capifs.c - 1.1 linux/drivers/isdn/capi/capidrv.h - 1.1 linux/kernel/fork.c - 1.55 linux/ipc/util.c - 1.20 linux/ipc/sem.c - 1.17 linux/init/main.c - 1.79 linux/include/linux/sem.h - 1.8 linux/include/linux/sched.h - 1.67 linux/include/asm-i386/bitops.h - 1.14 linux/fs/ufs/super.c - 1.29 linux/fs/sysv/inode.c - 1.31 linux/fs/qnx4/inode.c - 1.34 linux/fs/nfsd/vfs.c - 1.50 linux/fs/hfs/super.c - 1.18 linux/fs/ext2/super.c - 1.31 linux/fs/buffer.c - 1.118 linux/fs/affs/super.c - 1.24 linux/drivers/usb/Makefile - 1.51 linux/drivers/usb/Config.in - 1.57 linux/drivers/scsi/megaraid.c - 1.33 linux/drivers/net/Makefile - 1.57 linux/drivers/isdn/hisax/hisax.h - 1.28 linux/drivers/isdn/hisax/callc.c - 1.17 linux/drivers/isdn/avmb1/capiutil.h - 1.7 linux/drivers/isdn/avmb1/capiutil.c - 1.11 linux/drivers/isdn/avmb1/capidrv.h - 1.5 linux/drivers/isdn/avmb1/capidrv.c - 1.20 linux/drivers/isdn/avmb1/capidev.h - 1.9 linux/drivers/isdn/avmb1/capicmd.h - 1.6 linux/drivers/isdn/avmb1/capi.c - 1.30 linux/drivers/isdn/avmb1/b1pci.c - 1.19 linux/drivers/isdn/avmb1/Makefile - 1.13 linux/drivers/isdn/Makefile - 1.13 linux/drivers/isdn/Config.in - 1.25 linux/arch/i386/boot/setup.S - 1.26 linux/Makefile - 1.195 linux/MAINTAINERS - 1.103 linux/Documentation/sysrq.txt - 1.12 linux/CREDITS - 1.78 linux/drivers/isdn/eicon/eicon_mod.c - 1.17 linux/drivers/isdn/avmb1/t1isa.c - 1.14 linux/drivers/isdn/avmb1/kcapi.c - 1.18 linux/drivers/isdn/avmb1/capilli.h - 1.3 linux/drivers/isdn/avmb1/b1pcmcia.c - 1.14 linux/drivers/isdn/avmb1/b1isa.c - 1.12 linux/drivers/isdn/avmb1/b1.c - 1.16 linux/drivers/isdn/avmb1/avmcard.h - 1.9 linux/fs/udf/super.c - 1.30 linux/drivers/net/wan/Makefile - 1.16 linux/fs/bfs/inode.c - 1.23 linux/drivers/isdn/avmb1/t1pci.c - 1.18 linux/drivers/pci/pci.ids - 1.47 linux/Documentation/usb/ov511.txt - 1.17 linux/drivers/isdn/avmb1/c4.c - 1.19 linux/drivers/isdn/avmb1/b1dma.c - 1.19 linux/drivers/isdn/hysdn/hysdn_defs.h - 1.8 linux/drivers/net/tulip/Makefile - 1.6 linux/include/linux/usb.h - 1.35 linux/drivers/usb/serial/Makefile - 1.19 linux/drivers/isdn/avmb1/capifs.c - 1.18 linux/drivers/isdn/avmb1/avm_cs.c - 1.7 linux/drivers/isdn/avmb1/capifs.h - 1.4 linux/Documentation/filesystems/Locking - 1.11 linux/drivers/usb/serial/keyspan_usa28x_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa28_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa26msg.h - 1.5 linux/drivers/usb/serial/keyspan_usa19w_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa19_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa18x_fw.h - 1.3 linux/drivers/usb/serial/keyspan.h - 1.10 linux/drivers/usb/serial/keyspan.c - 1.26 linux/fs/jffs/inode-v23.c - 1.24 linux/drivers/usb/serial/keyspan_usa49w_fw.h - 1.3 linux/drivers/usb/serial/keyspan_usa49msg.h - 1.4 linux/drivers/usb/serial/Config.in - 1.14 linux/fs/reiserfs/journal.c - 1.26 linux/include/linux/reiserfs_fs.h - 1.22 linux/drivers/scsi/aic7xxx/Makefile - 1.4 linux/drivers/isdn/tpam/Makefile - 1.2 linux/drivers/usb/usb-skeleton.c - 1.9 linux/drivers/usb/serial/keyspan_usa28xb_fw.h - 1.2 linux/drivers/usb/serial/keyspan_usa28xa_fw.h - 1.2 linux/fs/ext3/super.c - 1.14 linux/sound/synth/emux/Makefile - 1.2 linux/sound/synth/Makefile - 1.3 linux/sound/ppc/Makefile - 1.2 linux/sound/pci/ymfpci/Makefile - 1.2 linux/sound/pci/trident/Makefile - 1.2 linux/sound/pci/rme9652/Makefile - 1.2 linux/sound/pci/nm256/Makefile - 1.2 linux/sound/pci/korg1212/Makefile - 1.2 linux/sound/pci/emu10k1/Makefile - 1.3 linux/sound/pci/cs46xx/Makefile - 1.2 linux/sound/pci/ali5451/Makefile - 1.2 linux/sound/pci/ac97/Makefile - 1.3 linux/sound/pci/Makefile - 1.2 linux/arch/x86_64/config.in - 1.6 linux/arch/x86_64/defconfig - 1.5 linux/arch/x86_64/ia32/ia32_ioctl.c - 1.5 linux/arch/x86_64/kernel/early_printk.c - 1.3 linux/arch/x86_64/kernel/i387.c - 1.3 linux/arch/x86_64/kernel/sys_x86_64.c - 1.3 linux/arch/x86_64/kernel/traps.c - 1.3 linux/arch/x86_64/mm/fault.c - 1.4 linux/sound/oss/Makefile - 1.2 linux/sound/isa/wavefront/Makefile - 1.3 linux/sound/isa/sb/Makefile - 1.3 linux/sound/isa/opti9xx/Makefile - 1.2 linux/sound/isa/gus/Makefile - 1.2 linux/sound/isa/es1688/Makefile - 1.2 linux/sound/isa/cs423x/Makefile - 1.2 linux/sound/isa/ad1848/Makefile - 1.2 linux/sound/isa/ad1816a/Makefile - 1.2 linux/sound/isa/Makefile - 1.2 linux/sound/i2c/Makefile - 1.3 linux/sound/drivers/opl3/Makefile - 1.3 linux/sound/drivers/mpu401/Makefile - 1.3 linux/sound/drivers/Makefile - 1.2 linux/sound/core/seq/oss/Makefile - 1.2 linux/sound/core/seq/instr/Makefile - 1.3 linux/sound/core/seq/Makefile - 1.5 linux/sound/core/oss/Makefile - 1.2 linux/sound/core/Makefile - 1.5 linux/sound/Makefile - 1.4 linux/include/sound/mpu401.h - 1.2 linux/include/asm-x86_64/unistd.h - 1.4 linux/sound/core/ioctl32/Makefile - 1.3 linux/fs/jffs2/fs.c - 1.2 linux/drivers/usb/image/Makefile - 1.3 linux/drivers/usb/class/Config.in - 1.2 linux/drivers/usb/class/Makefile - 1.2 linux/drivers/usb/class/printer.c - 1.2 linux/drivers/usb/core/Makefile - 1.2 linux/drivers/usb/core/drivers.c - 1.2 linux/drivers/usb/core/usb.c - 1.3 linux/drivers/usb/host/Config.in - 1.2 linux/drivers/usb/host/Makefile - 1.2 linux/drivers/usb/host/ehci-hcd.c - 1.3 linux/drivers/usb/host/ehci-q.c - 1.3 linux/drivers/usb/host/ehci-sched.c - 1.3 linux/drivers/usb/media/stv680.c - 1.2 linux/drivers/usb/image/Config.in - 1.3 linux/drivers/usb/image/hpusbscsi.c - 1.2 linux/drivers/usb/image/mdc800.c - 1.2 linux/drivers/usb/image/scanner.c - 1.2 linux/drivers/usb/input/Config.in - 1.2 linux/drivers/usb/input/Makefile - 1.2 linux/drivers/usb/input/hiddev.c - 1.2 linux/drivers/usb/media/Config.in - 1.2 linux/drivers/usb/media/Makefile - 1.2 linux/drivers/usb/media/dabusb.c - 1.2 linux/drivers/usb/media/dsbr100.c - 1.2 linux/drivers/usb/media/ov511.c - 1.2 linux/drivers/usb/media/ov511.h - 1.2 linux/drivers/usb/media/se401.c - 1.2 linux/drivers/usb/net/rtl8150.c - 1.3 linux/drivers/usb/net/pegasus.c - 1.3 linux/drivers/usb/net/Makefile - 1.2 linux/drivers/usb/net/Config.in - 1.3 linux/drivers/usb/misc/Config.help - 1.2 linux/drivers/usb/misc/Makefile - 1.2 linux/drivers/usb/misc/auerswald.c - 1.2 linux/drivers/usb/misc/rio500.c - 1.2 linux/drivers/isdn/i4l/isdn_tty.c - 1.2 linux/drivers/isdn/avmb1/Config.help - 1.2 linux/drivers/isdn/i4l/isdn_common.c - 1.2 linux/drivers/isdn/i4l/Config.in - 1.2 linux/drivers/isdn/avmb1/Config.in - 1.2 From owner-linux-xfs@oss.sgi.com Wed Apr 24 11:34: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 g3OIYSwJ005832 for ; Wed, 24 Apr 2002 11:34:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OIYRIH005831 for linux-xfs-outgoing; Wed, 24 Apr 2002 11:34: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 g3OIYFwJ005805 for ; Wed, 24 Apr 2002 11:34:17 -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 NAA21988; Wed, 24 Apr 2002 13:34: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 NAA69569; Wed, 24 Apr 2002 13:34:36 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3OIV0d08655; Wed, 24 Apr 2002 13:31:00 -0500 Subject: Re: XFS slows down on used partions with bonnie++ From: Steve Lord To: Thor Lancelot Simon Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020424142912.A24837@pla-muek.reefedge.com> References: <3C94F14E.7DE5A62D@it.up.ac.za> <3CC67369.935DF3ED@up.ac.za> <1019659451.27989.44.camel@jen.americas.sgi.com> <20020424142912.A24837@pla-muek.reefedge.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 24 Apr 2002 13:31:00 -0500 Message-Id: <1019673060.27989.232.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-04-24 at 13:29, Thor Lancelot Simon wrote: > On Wed, Apr 24, 2002 at 09:44:11AM -0500, Steve Lord wrote: > > Very interesting, I will take a look at this some more. One initial > > comment is that optimizing for bonnie is not necessarily the correct > > thing to do - not many real world loads create thousands of files and > > then immediately delete them. Plus, once you are on a raid device, > > logical and physical closeness on the volume no longer mean very much. > > > > Having said that we need to think some more about the underlying > > allocation policy of inodes vs file data here. > > There's been some amount of academic research on this with LFS (both the > BSD and Sprite variants), which suffers particularly badly from this > problem because inode rewrites can cause inodes to migrate away from their > related data blocks in the log over time. One interesting result is that > the original Sprite policy, with all inodes stored at the head of the disk, > isn't nearly as bad as you'd think; it keeps the seek time down and the > inodes end up pretty much pinned in the cache anyway. This isn't too far > off "allocate inodes from the front of the allocation group", I think. To > allocate them at opposite ends, as the average percentage of free space in > filesystems with large numbers of inodes grows (as I believe research would > currently show to be the case, due to increasing per-spindle capacity esp. > when compared to per-spindle seek performance) probably is about as bad as > you can get; allocation groups will *not* fill up, so this really does > maximize seek time in the case in which the inode is not in the cache. On > the other hand, if you assume that allocation groups *will* fill up, and > are willing to make the additional assumption that data written last is > most likely to be read (questionable, I think, in general, but true for some > database workloads) then as the group fills up, the data blocks you read > most frequently will turn out to be closest to the inodes you need to get at > them. However, in this case the inode is almost sure to be in cache, no? > > Another interesting take on it is to think about locality of reference > from an LFS-like temporal point of view. If inode blocks were simply > allocated with no constraint other than that they be in the same allocation > group as the first data block of the file, in the absence of fragmentation > inode and data blocks that were written at about the same time would tend > to be in about the same part of the disk -- indeed, since inodes in XFS > are allocated in 64K extents (aren't they?) you could turn the allocation > policy on its head and say "put the data block as close as possible to > the extent with the inode in it". This would produce the effect that in a > filesystem with many small files written at the same time, you'd get > temporal locality of reference on reads, even across multiple files -- which > the LFS work shows to be quite good: data written at the same time generally > is read at the same time. I believe NetApp's WAFL does this, as well: pick > where the metadata goes, then use that to place the data. Of course, there > are pathological cases for this kind of filesystem structure, too, but the > existence of the allocation groups, and the presence of read caching, would > at least reduce them. > > I'm not sure how clear the above was (and maybe anything of sense in it > was already obvious to you) but it seemed like it might be worth pointing > out. > > Thor I am not ignoring this thread, just got a few dozen other things I need to get done. XFS is supposed to put file data near inode data (inodes come in chunks of 2 filesystem blocks, 8K on linux, or 32 inodes by default). We need to study that code path and make sure it is behaving as designed. 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 24 11:42: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 g3OIgYwJ006089 for ; Wed, 24 Apr 2002 11:42:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OIgYjA006088 for linux-xfs-outgoing; Wed, 24 Apr 2002 11:42:34 -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 g3OIgQwJ006062 for ; Wed, 24 Apr 2002 11:42: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 g3OIcB3u005915; Wed, 24 Apr 2002 14:38:11 -0400 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id g3OIgqf24993; Wed, 24 Apr 2002 14:42:52 -0400 (EDT) Date: Wed, 24 Apr 2002 14:42:52 -0400 From: Thor Lancelot Simon To: linux-xfs@oss.sgi.com Cc: Thor Lancelot Simon Subject: Re: XFS slows down on used partions with bonnie++ Message-ID: <20020424144252.B24837@pla-muek.reefedge.com> References: <3C94F14E.7DE5A62D@it.up.ac.za> <3CC67369.935DF3ED@up.ac.za> <1019659451.27989.44.camel@jen.americas.sgi.com> <3CC6DA78.2AEAB9EB@up.ac.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC6DA78.2AEAB9EB@up.ac.za>; from paul@up.ac.za on Wed, Apr 24, 2002 at 06:16:56PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 06:16:56PM +0200, Paul Schutte wrote: > > This is another thing that is bothering me. > If you create a filesystem with only one AG all the benchmarks, tars, cps and > whatever you can dream up is a lot faster. > > I concluded that the seeks accross to other allocation groups was killing > performance. This is probably true only in the uniprocessor, single-spindle case. On a multiprocessor, the existence of largely independent allocation groups should be a big win, allowing much more processor concurrency in the filesystem code. On a filesystem that lives on multiple spindles (even if they're hidden behind a logical disk device of some kind) the inherent ability of the multiple heads to service requests from different areas of the disk at different times is discarded without multiple allocation groups. Of course, you have to understand what you're optimizing your disk subsystem for. The typical naive RAID configuration using mirroring or RAID5 for redundancy and small-stripe striping for "parallelism" actually just boosts single-threaded I/O *throughput*; it actually discards potential parallelism. When you have to seek, you still have to wait for the full seek time of *one of* the disks (though on stripe-sized or larger I/O, you have to seek only 1/N as often, where "N" is the number of disks) because all heads must settle on the same stripe before your I/O request to the stripe can be satisfied. If you're looking for maximum concurrency for small transactions -- for example, precisely the benchmark you describe -- you want to do something like create a plex with your disks (RAID 5 volumes for redundancy, perhaps) laid out in sequence, not striped, and arrange your allocation groups such that there is one per disk, so requests to separate AGs hit separate I/O paths at the lowest level, and the seek penalty is greatly reduced. One of the really nice things about XFS is that it is flexible enough that one *can* optimize it for either the maximum-throughput or maximum-concurrency case, in configurations from single-spindle-uniprocessor to really big servers with gigantic arrays of many disks. In the small case, though, allocating across a small number of AGs should not hurt performance much, so long as the allocation policy batches transactions into the same AG whenever possible. What you really, really *don't* want is a policy like the broken old BSD FFS policy: switch allocation groups any time you create a new file, and make a new allocation choice every time you create a new file. Spreading stuff across the disk is good; not doing it in batches does murder your single-spindle performance. Thor From owner-linux-xfs@oss.sgi.com Wed Apr 24 11:45: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 g3OIjDwJ006237 for ; Wed, 24 Apr 2002 11:45:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OIjDEU006236 for linux-xfs-outgoing; Wed, 24 Apr 2002 11:45:13 -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 g3OIj9wJ006208 for ; Wed, 24 Apr 2002 11:45:09 -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 g3OIes3u006001 for ; Wed, 24 Apr 2002 14:40:54 -0400 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id g3OIjZT25006 for linux-xfs@oss.sgi.com; Wed, 24 Apr 2002 14:45:35 -0400 (EDT) Date: Wed, 24 Apr 2002 14:45:35 -0400 From: Thor Lancelot Simon To: linux-xfs@oss.sgi.com Subject: Re: 2.4.18 + XFS 1.1 on multiprocessor: bizzare hard hang on Samba writes. Message-ID: <20020424144535.A25002@pla-muek.reefedge.com> References: <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 In-Reply-To: <20020421032724.A18019@pla-muek.reefedge.com>; from tls@reefedge.com on Sun, Apr 21, 2002 at 03:27:24AM -0400 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Apr 21, 2002 at 03:27:24AM -0400, Thor Lancelot Simon wrote: > > 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... This appears to actually be some kind of locking botch in the IDE driver; I cannot provoke the problem with the IDE bus totally inactive, and I *can* provoke it even if I switch all filesystems to ext3. I think XFS is off the hook here. Thor From owner-linux-xfs@oss.sgi.com Wed Apr 24 11:53:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OIr8wJ007394 for ; Wed, 24 Apr 2002 11:53:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OIr7Rb007393 for linux-xfs-outgoing; Wed, 24 Apr 2002 11:53:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OIr1wJ007367 for ; Wed, 24 Apr 2002 11:53:03 -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 NAA26338; Wed, 24 Apr 2002 13:53:23 -0500 (CDT) Received: from slobber.americas.sgi.com (slobber.americas.sgi.com [128.162.187.52]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id NAA37593; Wed, 24 Apr 2002 13:53:23 -0500 (CDT) Received: from slobber.americas.sgi.com by slobber.americas.sgi.com (SGI-8.9.3/SGI-client-1.7) via ESMTP id NAA04686; Wed, 24 Apr 2002 13:53:22 -0500 (CDT) Message-Id: <200204241853.NAA04686@slobber.americas.sgi.com> To: "Francis Qu" cc: "Linux XFS" Subject: Re: DMAPI dm_handle_to_path Date: Wed, 24 Apr 2002 13:53:22 -0500 From: Dean Roehrich Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From: "Francis Qu" >Sometimes we want to obtain the path without knowing parent handle. A single f >ile/dir object handle is sufficient in getting it's full path name. Thus makes > the arguments parent dir handle unnecessary? I create my own version of handl >e_to_path by using only object handle. I agree, you should be able to do this without using the parent dir handle. I wrestled with it, but didn't want to throw away the stuff in dm_handl2path.c because I wasn't sure about all the things it claims to fix. Now, here's something to try with your version: you have the handle, so unmount and again mount the filesystem, and now feed that handle to your handle_to_path. What happens? If you get something other than "/" or a crash, I really want to see your code. Dean From owner-linux-xfs@oss.sgi.com Wed Apr 24 12:17:48 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OJHmwJ007895 for ; Wed, 24 Apr 2002 12:17:48 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OJHmoX007894 for linux-xfs-outgoing; Wed, 24 Apr 2002 12:17:48 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.trustium.com (adsl-64-165-6-11.dsl.sndg02.pacbell.net [64.165.6.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OJHIwJ007867 for ; Wed, 24 Apr 2002 12:17:24 -0700 Received: by adsl-64-165-6-11.dsl.sndg02.pacbell.net with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 12:09:59 -0700 Message-ID: <44D5677E9B8478468DE31AE26DF0AFD6077C97@adsl-64-165-6-11.dsl.sndg02.pacbell.net> From: Adam Milazzo To: "'linux-xfs@oss.sgi.com'" Subject: RE: UPDATE: low-level XFS drive recovery Date: Wed, 24 Apr 2002 12:09:58 -0700 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 I will try that, but I'd like to note one thing. The drive actually had everything deleted with [essentially] 'rm -rf /mnt/drive/*'. It's not corrupt (just deleted), and I think mounting it might show that it's just plain empty. I know that there is no undelete capability designed into XFS, but I think that my case might be special enough (more information in my original post, far below) that the data could be recovered. The two options that I can see are to try and recover the directory information, or to do a raw scan of the entire disk and try to find the files based on their headers. One or both of these might be completely infeasible, depending upon how files are stored. Given that you know a lot about the details of XFS (of course), I would appreciate it if you could answer the questions I originally posted. That might help me decide which option to concentrate my efforts upon. To save you from having to scroll down (though there is still relevant information in my original post), I'll reproduce the important bits here: > I know that the XFS FAQ claims that there's no way to > undelete, and that's understandable. However, I might be in luck in this > case. The drive was freshly formatted and had a number of large files > copied to it from another drive, and no writing/deleting of those files was done after > that point (except when it was deleted by rm -rf). Also, no writing has > been done since the deletion. My hope is that the files are [still] in > contiguous blocks on the disk. > > My first question is: How likely is it that after writing some (rather > large, 100 meg average, but up to 700 meg) files to a freshly formatted > XFS partition, that they would be in contiguous blocks? > > Second: after the rm -rf /* recursed into that drive's mount point and > did it's dirty work, is there anything left of the directory structure? > Or was that all wiped out? As additional information, the partition is about 18-19 gigs, IDE, and was created with a recent version of mkfs.xfs with the default options. If the large files are not in contiguous blocks, scanning the disk looking for file headers would be useless because the files are not in one piece anyway. But if the directory information is gone, trying to recover it might be useless. I was hoping the oss.sgi.com/xfs site would have some information about the raw disk structure, but the "Design" link (which points to http://oss.sgi.com/projects/xfs/design_docs/) gives me a "Forbidden" access denied error, and I'm not sure where else to look. Since I can't find any low-level documentation, I've been trying to study the source code for the XFS utilities, but it's slow-going. I know this question doesn't really relate to problems in XFS itself, and the problem was completely my fault, but I would appreciate any information you could give that might be of use. Thanks very much, Adam M. -----Original Message----- From: Steve Lord [mailto:lord@sgi.com] Sent: Wednesday, April 24, 2002 8:00 AM To: Adam Milazzo Cc: 'linux-xfs@oss.sgi.com' Subject: Re: UPDATE: low-level XFS drive recovery OK, but on you bullet proof vest and thermally insulated gloves.... Try this for starters: mount -o ro,norecovery It will skip processing the log. You can try copying files out of the filesystem, hopefully it is in good enough state to open directories and copy data out of files. It may crash in the process, or if it finds corruption it may shutdown the filesystem. In that case umount it and mount it again with the same options, and avoid the paths which caused the problems. Get as much data out this way as you can, you cannot make anything worse with this. Next run xfs_repair -L (no -n) those files it said it would trash will probably get put in lost+found by repair, it might actually keep all of your data. Steve On Tue, 2002-04-23 at 22:45, Adam Milazzo wrote: > After running xfs_repair -n, I get some stuff that looks like this: > entry "backup" in directory inode 128 points to free inode 12583040, would > junk entry > entry "desktop" in directory inode 128 points to free inode 16777344, would > junk entry > entry "t" in directory inode 128 points to free inode 33554240, would junk > entry > ...as well as others... > These are exactly the three directories I need to recover!! > > However, from the look of the message, it seems like it's going to "junk" > the entry, > making it more difficult to recover. > > I'm thinking that directory inode 128 is the root directory, and the inodes > mentioned > are the directory inodes of those subdirectories. Is there a way (using > xfs_db > perhaps?) to get the inodes and/or extents of the files in those > directories? > > Could I use this information to recover my files (note that there is > important > information regarding the situation in my original post, below)? > > I'm trying to figure out how to use xfs_db to do this... > > If anybody would be kind enough to give me a few instructions on this, or > point me to > some documentation about the format of the directory inodes (whatever I > would need to > get at the file extents), I would greatly appreciate it. > > Thanks in advance, > Adam M. > > -----Original Message----- > From: Adam Milazzo > To: 'linux-xfs@oss.sgi.com' > Sent: 4/23/2002 12:36 PM > Subject: low-level XFS drive recovery > > In a bout of impatient, early-morning foolishness, while trying to > quickly "format" /dev/hda1 (mounted under /mnt), I did an 'rm -rf /*' > from a chroot'd shell, but didn't realize until I pressed Enter, that I > had /dev/hdb1 mounted. However, it was too late, as the second drive was > nearly instantly wiped clean, taking with it all my important stuff! So > I went to bed. > > I learned a few lessons, like making better use of 'mount -o ro'. > However, the damage was already done and I am trying to restore the data > on that drive. I know that the XFS FAQ claims that there's no way to > undelete, and that's understandable. However, I might be in luck in this > case. The drive was freshly formatted and had a number of large files > copied to it from another drive, and no writing/deleting was done after > that point (except when it was deleted by rm -rf). Also, no writing has > been done since the deletion. My hope is that the files are [still] in > contiguous blocks on the disk. > > My first question is: How likely is it that after writing some (rather > large, 100 meg average, but up to 700 meg) files to a freshly formatted > XFS partition, that they would be in contiguous blocks? > > Second: after the rm -rf /* recursed into that drive's mount point and > did it's dirty work, is there anything left of the directory structure? > Or was that all wiped out? > > I dumped the first 8 gigs of the drive to a file on another drive, and > am writing a program to scan that dump file and attempt to pull out > anything that looks like a data file (basically by scanning for valid > file headers). However, it's slow work, and is almost useless if the > files are not stored in a single contiguous blocks (hence my first > question). Also, if there's anything left of the directory structure > that I could use to find where files begin and the filename, that would > be very helpful. > > Perhaps it's relatively trivial to restore the entire drive just by > rebuilding the directory structure, given the special circumstances of > my situation. Or perhaps the entire thing would be extremely difficult > because the files are broken up. > > So, if anybody could provide some information that would be helpful, > and/or point me to some good information on the low-level details of the > filesystem structure that might be useful in aiding my recovery of the > data (or giving me enough information that I can deem it pointless > without going through all the work), it would be greatly appreciated. > > Also, does anybody know of a good hex editor (or sector editor)? I'm > looking for the following features (In decreasing order of importance): > * Fast searching of text and binary data > * Ability to open huge files (>2gb) > * A display of the word, dword, and maybe quadword value that begins at > the byte under the cursor. > * Ability to select a chunk of data and save it to a disk (directly, or > in a round-about way) > * A built-in calculator? > > curses-based would be okay, but something for gnome/X would be nice. > > Thanks a lot in advance! > Adam M. -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Wed Apr 24 12:22: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 g3OJMOwJ008173 for ; Wed, 24 Apr 2002 12:22:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OJMO2N008172 for linux-xfs-outgoing; Wed, 24 Apr 2002 12:22: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 g3OJMJwJ008145 for ; Wed, 24 Apr 2002 12:22:19 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA26981; Wed, 24 Apr 2002 14:22:40 -0500 (CDT) Received: from eagdhcp-187-28.americas.sgi.com (eagdhcp-187-28.americas.sgi.com [128.162.187.178]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA13123; Wed, 24 Apr 2002 14:22:40 -0500 (CDT) Subject: Re: DMAPI dm_handle_to_path From: Stephen Lord To: Dean Roehrich Cc: Francis Qu , Linux XFS In-Reply-To: <200204241853.NAA04686@slobber.americas.sgi.com> References: <200204241853.NAA04686@slobber.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 24 Apr 2002 14:15:54 -0500 Message-Id: <1019675754.6608.1.camel@128-162-187-178> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-04-24 at 13:53, Dean Roehrich wrote: > > >From: "Francis Qu" > >Sometimes we want to obtain the path without knowing parent handle. A single f > >ile/dir object handle is sufficient in getting it's full path name. Thus makes > > the arguments parent dir handle unnecessary? I create my own version of handl > >e_to_path by using only object handle. > > I agree, you should be able to do this without using the parent dir handle. I > wrestled with it, but didn't want to throw away the stuff in dm_handl2path.c > because I wasn't sure about all the things it claims to fix. > > Now, here's something to try with your version: you have the handle, so > unmount and again mount the filesystem, and now feed that handle to your > handle_to_path. What happens? If you get something other than "/" or a > crash, I really want to see your code. > > > Dean A heads up for people working in this area. 2.5.9 just revamped how NFS does all of its work in this area, and the old interface between NFS and filesystems is 'going away'. I suspect the handle code will be impacted by this in 2.5 Steve From owner-linux-xfs@oss.sgi.com Wed Apr 24 12:23: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 g3OJNpwJ008280 for ; Wed, 24 Apr 2002 12:23:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OJNpH6008279 for linux-xfs-outgoing; Wed, 24 Apr 2002 12:23:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OJNfwJ008240 for ; Wed, 24 Apr 2002 12:23:41 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA28821; Wed, 24 Apr 2002 14:24:03 -0500 (CDT) Received: from eagdhcp-187-28.americas.sgi.com (eagdhcp-187-28.americas.sgi.com [128.162.187.178]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA14876; Wed, 24 Apr 2002 14:24:03 -0500 (CDT) Subject: RE: UPDATE: low-level XFS drive recovery From: Stephen Lord To: Adam Milazzo Cc: "'linux-xfs@oss.sgi.com'" In-Reply-To: <44D5677E9B8478468DE31AE26DF0AFD6077C97@adsl-64-165-6-11.dsl.sndg02.pacbell. net> References: <44D5677E9B8478468DE31AE26DF0AFD6077C97@adsl-64-165-6-11.dsl.sndg02.pacbell. net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 24 Apr 2002 14:17:16 -0500 Message-Id: <1019675836.6608.3.camel@128-162-187-178> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-04-24 at 14:09, Adam Milazzo wrote: > I will try that, but I'd like to note one thing. The drive actually had > everything deleted with [essentially] 'rm -rf /mnt/drive/*'. It's not > corrupt (just deleted), and I think mounting it might show that it's just > plain empty. I know that there is no undelete capability designed into XFS, > but I think that my case might be special enough (more information in my > original post, far below) that the data could be recovered. The two options > that I can see are to try and recover the directory information, or to do a > raw scan of the entire disk and try to find the files based on their > headers. One or both of these might be completely infeasible, depending upon > how files are stored. Given that you know a lot about the details of XFS (of > course), I would appreciate it if you could answer the questions I > originally posted. That might help me decide which option to concentrate my > efforts upon. To save you from having to scroll down (though there is still > relevant information in my original post), I'll reproduce the important bits > here: > Well, durrrr!! doing too many things at once. Yes, you deleted it all, so none of this will help. Sorry about that. Steve From owner-linux-xfs@oss.sgi.com Wed Apr 24 12:33: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 g3OJXYwJ008537 for ; Wed, 24 Apr 2002 12:33:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OJXXMn008536 for linux-xfs-outgoing; Wed, 24 Apr 2002 12:33:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OJXRwJ008510 for ; Wed, 24 Apr 2002 12:33:28 -0700 Received: from attbi.com ([12.234.8.60]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020424193349.XVDV19669.rwcrmhc54.attbi.com@attbi.com>; Wed, 24 Apr 2002 19:33:49 +0000 Message-ID: <3CC7084B.5020005@attbi.com> Date: Wed, 24 Apr 2002 12:32:27 -0700 From: Curtis Anderson User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Adam Milazzo CC: "'linux-xfs@oss.sgi.com'" Subject: Re: UPDATE: low-level XFS drive recovery References: <44D5677E9B8478468DE31AE26DF0AFD6077C97@adsl-64-165-6-11.dsl.sndg02.pacbell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Adam Milazzo wrote: > I will try that, but I'd like to note one thing. The drive actually had > everything deleted with [essentially] 'rm -rf /mnt/drive/*'. Isn't there still a utility to print out the contents of the transaction log? If the history in the log goes back far enough, then you will see images of all of the inodes as they existed before they were deleted. XFS uses post-image logging so you will not see the extent lists in the log transaction that deletes the file, you will have to look for the change just prior to that. The log will include the extent lists where your blocks were located as well as where the directory entries for the filesystem were located. Looking backward in the log is exactly like looking backward in time (to before the deletions). Note that the log might not go back far enough, the on-disk structures are rather complex, the log records are also complex, etc, etc... Thanks, Curtis -- Curtis Anderson Storage Architect curtisanderson1@attbi.com From owner-linux-xfs@oss.sgi.com Wed Apr 24 12:45:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OJj1wJ008763 for ; Wed, 24 Apr 2002 12:45:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OJj12M008762 for linux-xfs-outgoing; Wed, 24 Apr 2002 12:45:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.trustium.com (adsl-64-165-6-11.dsl.sndg02.pacbell.net [64.165.6.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OJiqwJ008734 for ; Wed, 24 Apr 2002 12:44:52 -0700 Received: by adsl-64-165-6-11.dsl.sndg02.pacbell.net with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Apr 2002 12:37:32 -0700 Message-ID: <44D5677E9B8478468DE31AE26DF0AFD6077C98@adsl-64-165-6-11.dsl.sndg02.pacbell.net> From: Adam Milazzo To: "'linux-xfs@oss.sgi.com'" Subject: RE: UPDATE: low-level XFS drive recovery Date: Wed, 24 Apr 2002 12:37:31 -0700 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 I'm not sure, but what you described sounds useful. I might try to do some research regarding that as well. Using 'xfs_repair -n' printed out some helpful-looking information, and I've had some success recovering small files by scanning the drive and trying to find valid file headers. However, I don't know if large (100mb - 700mb) files are stored in contiguous blocks, like the small files were. If they are, then I can continue recovering files by programmatically searching for file headers. If not, then searching for the headers is pointless, as the file won't be in a single chunk anyway. In that case, I'd need to recover the directory information (if possible) to help me piece everything back together. If that's not possible, then what you described might be the only way to go about it. However, I can't seem to find any detailed documentation regarding low-level details like this! And trying to figure it out through hex editing and the XFS source code is a bit tough. :) Thanks for the suggestion! Adam M. -----Original Message----- From: Curtis Anderson [mailto:curtisanderson1@attbi.com] Sent: Wednesday, April 24, 2002 12:32 PM To: Adam Milazzo Cc: 'linux-xfs@oss.sgi.com' Subject: Re: UPDATE: low-level XFS drive recovery Adam Milazzo wrote: > I will try that, but I'd like to note one thing. The drive actually had > everything deleted with [essentially] 'rm -rf /mnt/drive/*'. Isn't there still a utility to print out the contents of the transaction log? If the history in the log goes back far enough, then you will see images of all of the inodes as they existed before they were deleted. XFS uses post-image logging so you will not see the extent lists in the log transaction that deletes the file, you will have to look for the change just prior to that. The log will include the extent lists where your blocks were located as well as where the directory entries for the filesystem were located. Looking backward in the log is exactly like looking backward in time (to before the deletions). Note that the log might not go back far enough, the on-disk structures are rather complex, the log records are also complex, etc, etc... Thanks, Curtis -- Curtis Anderson Storage Architect curtisanderson1@attbi.com From owner-linux-xfs@oss.sgi.com Wed Apr 24 12:46:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OJk1wJ008849 for ; Wed, 24 Apr 2002 12:46:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OJk0T8008848 for linux-xfs-outgoing; Wed, 24 Apr 2002 12:46:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OJjrwJ008818 for ; Wed, 24 Apr 2002 12:45:54 -0700 Received: from inter.nl.net (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.11.6/linuxconf) with ESMTP id g3OJoxF17925; Wed, 24 Apr 2002 21:50:59 +0200 Message-ID: <3CC70C70.4020707@inter.nl.net> Date: Wed, 24 Apr 2002 21:50:08 +0200 From: Jurgen Kramer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Nathan Scott CC: Chris Tooley , 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> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> <1019581365.26898.9.camel@itspec.amoa.org> <20020424084049.M63455@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am also not very lucky in compiling samba with ACL support: checking if large file support can be enabled... yes checking whether to support ACLs... checking for acl_get_file in -lacl... no checking for ACL support... no checking whether to build winbind... yes Both samba and XFS come from CVS. Greetings, Jurgen Nathan Scott wrote: >On Tue, Apr 23, 2002 at 12:02:44PM -0500, Chris Tooley wrote: > >>I did make the switch in configure from -lacl -lattr and faired no >>better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp >>kernel. >> >>checking if large file support can be enabled... yes >>checking whether to support ACLs... checking for acl_get_file in >>-lattr... no >>checking for ACL support... no >> > >Your configure changes are incorrect - they're looking in the wrong >library for acl_get_file (which is in libacl, not libattr), as I >said earlier you need to link with both libraries. > >It has been pointed out that we can do a better job when building >libacl so that it knows it depends on libattr (in fact this was >done at one point, but was accidentally dropped from the Makefile). >If you build and install the acl code from XFS CVS (have a look >though cmd/acl/doc/INSTALL), you should find that Samba gets >built correctly with no changes at all now. > >cheers. > From owner-linux-xfs@oss.sgi.com Wed Apr 24 12:49: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 g3OJnDwJ009137 for ; Wed, 24 Apr 2002 12:49:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OJnDCd009136 for linux-xfs-outgoing; Wed, 24 Apr 2002 12:49:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.SGI.COM [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OJn6wJ009110 for ; Wed, 24 Apr 2002 12:49:06 -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 OAA13397; Wed, 24 Apr 2002 14:49:28 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.35 #1 (Debian)) id 170Sla-0004TW-00; Wed, 24 Apr 2002 14:49:26 -0500 Date: Wed, 24 Apr 2002 14:49:26 -0500 From: Nathan Straz To: Adam Milazzo Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: UPDATE: low-level XFS drive recovery Message-ID: <20020424194925.GD8662@sgi.com> Mail-Followup-To: Adam Milazzo , "'linux-xfs@oss.sgi.com'" References: <44D5677E9B8478468DE31AE26DF0AFD6077C92@adsl-64-165-6-11.dsl.sndg02.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44D5677E9B8478468DE31AE26DF0AFD6077C92@adsl-64-165-6-11.dsl.sndg02.pacbell.net> User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk A few months back I repartitioned a BSD box before I realized that I lost my backups. The tool that helped me recover most of my data was Python. Why Python? - Interactive scripting language With an interactive scripting language you can write the tools while you use it. I can paste functions in from an editor, try them out, fix the bugs in the editor and repeat. - the struct package Python has a package that takes strings and unpacks them into variables. I've used it to decode everything from superblocks to dentries. - the mmap package mmap your entire disk image read-only and access it like an array. You can then use slices and regex on it to find where structures are. If you want, I can send you my code as a starting point. It's for OpenBSD (4.4BSD UFS), but it should give you some ideas. -- 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 Wed Apr 24 12:54: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 g3OJs7wJ009335 for ; Wed, 24 Apr 2002 12:54:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OJs7Nh009334 for linux-xfs-outgoing; Wed, 24 Apr 2002 12:54:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from gatekeeper.slim (slimnet.xs4all.nl [194.109.194.192]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OJrwwJ009306 for ; Wed, 24 Apr 2002 12:53:59 -0700 Received: from inter.nl.net (paragon.slim [192.168.100.26]) by gatekeeper.slim (8.11.6/linuxconf) with ESMTP id g3OK2sF18093 for ; Wed, 24 Apr 2002 22:02:54 +0200 Message-ID: <3CC70F3B.90601@inter.nl.net> Date: Wed, 24 Apr 2002 22:02:03 +0200 From: Jurgen Kramer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Re: Can't get samba 2.2.3a to compile with ACL support (with logs) Now works! References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> <1019581365.26898.9.camel@itspec.amoa.org> <20020424084049.M63455@wobbly.melbourne.sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ok after upgrading to the very latest CVS version of XFS it works: checking whether to support ACLs... checking for acl_get_file in -lacl... yes checking for ACL support... yes Using posix ACLs checking for acl_get_perm_np... no I thought I was up to date with a 2 day old XFS version from CVS...;-) Cheers, Jurgen Nathan Scott wrote: >On Tue, Apr 23, 2002 at 12:02:44PM -0500, Chris Tooley wrote: > >>I did make the switch in configure from -lacl -lattr and faired no >>better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp >>kernel. >> >>checking if large file support can be enabled... yes >>checking whether to support ACLs... checking for acl_get_file in >>-lattr... no >>checking for ACL support... no >> > >Your configure changes are incorrect - they're looking in the wrong >library for acl_get_file (which is in libacl, not libattr), as I >said earlier you need to link with both libraries. > >It has been pointed out that we can do a better job when building >libacl so that it knows it depends on libattr (in fact this was >done at one point, but was accidentally dropped from the Makefile). >If you build and install the acl code from XFS CVS (have a look >though cmd/acl/doc/INSTALL), you should find that Samba gets >built correctly with no changes at all now. > >cheers. > From owner-linux-xfs@oss.sgi.com Wed Apr 24 13:02:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OK2LwJ009578 for ; Wed, 24 Apr 2002 13:02:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OK2Lh3009577 for linux-xfs-outgoing; Wed, 24 Apr 2002 13:02:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mailman.mnd.com ([208.226.69.17]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OK2EwJ009551 for ; Wed, 24 Apr 2002 13:02:15 -0700 Received: from alpha2.production.mnd.com (IDENT:cjb@alpha2.production.mnd.com [192.168.3.105]) by mailman.mnd.com (8.9.3/8.9.3) with ESMTP id OAA11425 for ; Wed, 24 Apr 2002 14:59:56 -0500 Date: Wed, 24 Apr 2002 14:59:55 -0500 (CDT) From: Chris Bednar X-Sender: cjb@alpha2.production.mnd.com To: "'linux-xfs@oss.sgi.com'" Subject: RE: UPDATE: low-level XFS drive recovery In-Reply-To: <1019675836.6608.3.camel@128-162-187-178> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 24 Apr 2002, Stephen Lord wrote: > On Wed, 2002-04-24 at 14:09, Adam Milazzo wrote: > > I will try that, but I'd like to note one thing. The drive actually had > > everything deleted with [essentially] 'rm -rf /mnt/drive/*'. It's not > > corrupt (just deleted), and I think mounting it might show that it's just > > here: > Well, durrrr!! doing too many things at once. Yes, you deleted it all, > so none of this will help. Sorry about that. It would be interesting to know if there is anything that could (at least in principle) be done in this situation. A while back, we had all the scratch files deleted on a job that had been running on our cluster for 20+ days. They were on ext2 filesystems, and I found the wonderful e2undel which almost did what I needed. It essentially scans the FS for not-in-use inodes with nonzero dtimes, gives you a list of them, and lets you pull them off. I hacked it up to look for files with no refs, but zero dtimes (since the app hadn't quit on most nodes, the files were in limbo) and managed to recover about all of the 160 GB of data. I'm not asking if such a tool exists for XFS, mind you, but sooner or later, given that we have a few TB of XFS in house, I can guess that I'll want to know if the info to do this still exists on the platter, and if I could get it through xfsprogs-devel... ---- Chris J. Bednar Director, Distributed Computing Product Group http://AdvancedDataSolutions.com/ From owner-linux-xfs@oss.sgi.com Wed Apr 24 14:44:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3OLiXwJ021213 for ; Wed, 24 Apr 2002 14:44:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OLiXYI021212 for linux-xfs-outgoing; Wed, 24 Apr 2002 14:44:33 -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 g3OLiOwJ021184 for ; Wed, 24 Apr 2002 14:44:27 -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 HAA00330; Thu, 25 Apr 2002 07:44:36 +1000 (EST) Received: from holly.aitch.ucc.usyd.edu.au ( [holly.aitch.ucc.usyd.edu.au]) as user matthew@localhost by admin.arts.usyd.edu.au with HTTP; Thu, 25 Apr 2002 07:44:35 +1000 Message-ID: <1019684675.3cc72743d9ded@admin.arts.usyd.edu.au> Date: Thu, 25 Apr 2002 07:44:35 +1000 From: Matthew Geier To: Chris Tooley Cc: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> <1019581365.26898.9.camel@itspec.amoa.org> <20020424084049.M63455@wobbly.melbourne.sgi.com> <1019657673.29084.7.camel@itspec.amoa.org> In-Reply-To: <1019657673.29084.7.camel@itspec.amoa.org> 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 Quoting Chris Tooley : > Has anything else been changed in CVS? I'm hoping that nothing is > broken because I'm planning on putting the machine into production this > weekend. > > On Tue, 2002-04-23 at 17:40, Nathan Scott wrote: > > On Tue, Apr 23, 2002 at 12:02:44PM -0500, Chris Tooley wrote: > > > I did make the switch in configure from -lacl -lattr and faired no > > > better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp > > > kernel. I went through configure.in and changed multiple references to -lacl to -lacl -lattr, -lacl was in about 3 places from memory. The compile of samba 2.2.3a then failed on the quota code - some ones messed with the quota interface as well. :-) I made some minor changes and that seems to work as well no. I assume when people stop changing things, that will settle as well :-) -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University ------------------------------------------------- This mail sent through IMP at ArtsIT: http://admin.arts.usyd.edu.au/horde/imp/ From owner-linux-xfs@oss.sgi.com Wed Apr 24 15:14: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 g3OMETwJ022704 for ; Wed, 24 Apr 2002 15:14:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OMESCQ022703 for linux-xfs-outgoing; Wed, 24 Apr 2002 15:14:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3OMEBwJ022675 for ; Wed, 24 Apr 2002 15:14:11 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id RAA29840; Wed, 24 Apr 2002 17:14:33 -0500 (CDT) Received: from eagdhcp-187-28.americas.sgi.com (eagdhcp-187-28.americas.sgi.com [128.162.187.178]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id RAA41278; Wed, 24 Apr 2002 17:14:33 -0500 (CDT) Subject: RE: UPDATE: low-level XFS drive recovery From: Stephen Lord To: Chris Bednar 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: 24 Apr 2002 17:07:21 -0500 Message-Id: <1019686041.6620.71.camel@128-162-187-178> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-04-24 at 14:59, Chris Bednar wrote: > > I'm not asking if such a tool exists for XFS, mind you, but sooner > or later, given that we have a few TB of XFS in house, I can guess that > I'll want to know if the info to do this still exists on the platter, > and if I could get it through xfsprogs-devel... > > > ---- > Chris J. Bednar > Director, Distributed Computing Product Group > http://AdvancedDataSolutions.com/ Getting stuff back in XFS is always problematical, it is so good at cleaning up after itself. With some filesystems, once you get to an inode, getting the data back is not too hard. With XFS, when you delete a file, the extents which were in that file are removed from it and returned to free space, destroying the record in the inode of where the data once was. Curtis (who worked on XFS at one point) has come the closest here, xfs_logprint can dump out the contents of the log, and at least provide a record of what happened most recently. Unfortunately, the options on logprint which format the contents also do similar processing to mount - the find the head and tail of the log, and if is empty (as it will be after a successful unmount), proceed to print nothing: # xfs_logprint -t /dev/hda3 xfs_logprint: data device: 0x303 log device: 0x303 daddr: 4193024 length: 131072 log tail: 88508 head: 88508 state: xfs_db is also a good tool for looking at metadata: xfs_db /dev/xxx xfs_db: inode 132 xfs_db: p core.magic = 0x494e core.mode = 0100664 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 1 core.uid = 858 core.gid = 858 core.atime.sec = Mon Apr 1 07:04:31 2002 core.atime.nsec = 706933000 core.mtime.sec = Mon Apr 1 06:54:42 2002 core.mtime.nsec = 086933000 core.ctime.sec = Mon Apr 1 06:54:42 2002 core.ctime.nsec = 086933000 core.size = 4119297 core.nblocks = 1006 core.extsize = 0 core.nextents = 1 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.gen = 25 next_unlinked = null u.bmx[0] = [startoff,startblock,blockcount,extentflag] 0:[0,1664,1006,0] I can even get to the data: xfs_db: dblock 0 xfs_db: p 000: 534d426d 6b646972 20524551 55455354 20506174 68205c43 4c49454e 54530a53 020: 4d426d6b 64697220 5245504c 59200a53 4d426d6b 64697220 52455155 45535420 040: 50617468 205c4e42 53494d55 4c440a53 4d426d6b 64697220 5245504c 59200a53 060: 4d426d6b 64697220 52455155 45535420 50617468 205c4e42 53494d55 4c445c43 080: 4c49454e 540a534d 426d6b64 69722052 45504c59 200a534d 426d6b64 69722052 But if I delete the inode and go look at it again: xfs_db: inode 132 xfs_db: p core.magic = 0x494e core.mode = 0 core.version = 1 core.format = 2 (extents) core.nlinkv1 = 0 core.uid = 858 core.gid = 858 core.atime.sec = Mon Apr 1 07:04:31 2002 core.atime.nsec = 706933000 core.mtime.sec = Mon Apr 1 06:54:42 2002 core.mtime.nsec = 086933000 core.ctime.sec = Wed Apr 24 16:47:02 2002 core.ctime.nsec = 665733000 core.size = 0 core.nblocks = 0 core.extsize = 0 core.nextents = 0 core.naextents = 0 core.forkoff = 0 core.aformat = 2 (extents) core.dmevmask = 0 core.dmstate = 0 core.newrtbm = 0 core.prealloc = 0 core.realtime = 0 core.gen = 26 next_unlinked = null u = (empty) All the extent info got wiped out in the formated output. I can get raw output: xfs_db: type data xfs_db: p 00: 494e0000 01020000 0000035a 0000035a 00000000 00000000 00000000 00000000 20: 3ca85adf 2a22f108 3ca85892 052e7e08 3cc727d6 27ae4788 00000000 00000000 40: 00000000 00000000 00000000 00000000 00000002 00000000 00000000 0000001a 60: ffffffff 00000000 00000000 00000000 d00003ee 00000000 00000200 00000000 80: 02c00002 00000000 00000600 00000000 05000001 00000000 00000800 00000000 a0: 07000002 00000000 00000c00 00000000 00000000 00000059 00000000 00000000 c0: 01a00001 00000001 00000200 00000000 06400002 00000001 00000600 00000000 e0: 09600001 00000002 00000000 00000000 05200001 00000000 00000000 00000000 The extent information may actually still be there in this case, but it is getting pretty hard to get at. In answer to the original question in this thread, there is a good chance the files are reasonably sequential on the disk, if they were written one at a time, but there is no guarantee of this, and no real simple way of finding out. Sorry I am not being more helpful here. Steve From owner-linux-xfs@oss.sgi.com Wed Apr 24 15:34: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 g3OMYTwJ023155 for ; Wed, 24 Apr 2002 15:34:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3OMYT7q023154 for linux-xfs-outgoing; Wed, 24 Apr 2002 15:34: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 g3OMYLwJ023127 for ; Wed, 24 Apr 2002 15:34:21 -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 RAA29495; Wed, 24 Apr 2002 17:34:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA23439; Wed, 24 Apr 2002 17:34:43 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3OMV8101736; Wed, 24 Apr 2002 17:31:08 -0500 Subject: RE: UPDATE: low-level XFS drive recovery From: Steve Lord To: Stephen Lord Cc: Chris Bednar , "'linux-xfs@oss.sgi.com'" In-Reply-To: <1019686041.6620.71.camel@128-162-187-178> References: <1019686041.6620.71.camel@128-162-187-178> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 24 Apr 2002 17:31:08 -0500 Message-Id: <1019687468.1706.18.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 2002-04-24 at 17:07, Stephen Lord wrote: > > In answer to the original question in this thread, there is a good chance > the files are reasonably sequential on the disk, if they were written one > at a time, but there is no guarantee of this, and no real simple way of > finding out. > > Sorry I am not being more helpful here. > > Steve > So, I did try one more thing: xfs_db -x /dev/xxx this enables a write command Using the commands inode 132 write core.nextents 1 p I was able to get my extent info back again. So presuming you can find an inode number, and then assuming extents fit within the inode, this gives back the extent info for an individual file. I then took the info from the extent and multiplied it by 4096 and set the size to this: write core.size 4120576 and set the blocks used write core.nblocks 1006 a number of other fields need setting, and so far I have been unable to get repair to like the inode, but there is a chance this could be made to work. There also still appear to be endian issues in this part of xfs_db. 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 24 16:52:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ONqFwJ001910 for ; Wed, 24 Apr 2002 16:52:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ONqFEx001909 for linux-xfs-outgoing; Wed, 24 Apr 2002 16:52:15 -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-d514e17b.dsl.mediaWays.net [213.20.225.123]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ONqBwJ001883 for ; Wed, 24 Apr 2002 16:52:12 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 170WYo-0007Yg-00; Thu, 25 Apr 2002 01:52:30 +0200 Message-ID: <3CC7453D.12C7D497@berdmann.de> Date: Thu, 25 Apr 2002 01:52:29 +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: Adam Milazzo CC: "'linux-xfs@oss.sgi.com'" Subject: Re: low-level XFS drive recovery References: <44D5677E9B8478468DE31AE26DF0AFD6077C87@adsl-64-165-6-11.dsl.sndg02.pacbell.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > In a bout of impatient, early-morning foolishness, while trying to quickly > "format" /dev/hda1 (mounted under /mnt), I did an 'rm -rf /*' from a > chroot'd shell, but didn't realize until I pressed Enter, that I had > /dev/hdb1 mounted. However, it was too late, as the second drive was nearly > instantly wiped clean, taking with it all my important stuff! So I went to > bed. Maybe a good backup scheme to tape would help. From owner-linux-xfs@oss.sgi.com Wed Apr 24 17:13:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P0DvwJ002358 for ; Wed, 24 Apr 2002 17:13:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P0DvnA002357 for linux-xfs-outgoing; Wed, 24 Apr 2002 17:13:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from lucy.ulatina.ac.cr (lucy.ulatina.ac.cr [163.178.60.3]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P0DawJ002328 for ; Wed, 24 Apr 2002 17:13:46 -0700 Received: (from fede2@localhost) by lucy.ulatina.ac.cr (8.11.4/8.11.4) id g3P076o03640; Wed, 24 Apr 2002 18:07:06 -0600 X-Authentication-Warning: lucy.ulatina.ac.cr: fede2 set sender to fede2@fuerzag.ulatina.ac.cr using -f Subject: Re: opps on xfs on a linear raid on a sparc64 box From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 24 Apr 2002 18:07:05 -0600 Message-Id: <1019693225.2548.37.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Sorry for the slow reply on this one! Not at all. Thanks for the help actually. > 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. Great. I've just taste it on raid 0,4,5 and linear raid and it works fine. I will still stress test it for a couple of days and let you know. I coulnd test it on raid1 because raid1 fails no matter what filesystem you put on it. As soon as it finish syncing, it gives me an oops. But that is a matter for another mailing list ;). Again, thanks for the help. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Wed Apr 24 20:53:00 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P3qxwJ004560 for ; Wed, 24 Apr 2002 20:52:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P3qx0n004559 for linux-xfs-outgoing; Wed, 24 Apr 2002 20:52:59 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P3qpwJ004533 for ; Wed, 24 Apr 2002 20:52:52 -0700 Received: from umbi.umd.edu ([129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GV3UUB00.E2B for ; Wed, 24 Apr 2002 23:54:11 -0400 Message-ID: <3CC77E02.44593DF5@umbi.umd.edu> Date: Wed, 24 Apr 2002 23:54:42 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: boot thinks / is still ext2 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I figured out a way to "convert" the root fs from ext2 to xfs by booting off the CD. However, when I try to boot off the MBR, the boot process fails apparently because it's still trying to treat "/" as an ext2 filesystem (and hence no init is found). For now I'm booting off a floppy disk, and that works fine. I double-checked /etc/fstab, re-ran LILO, checked in /etc/lilo.conf no luck. I read the man page for rdev but didn't find anything about fs type. I also poked around in /boot running strings and gunzip on various files looking for some reference to ext2. LILO's not having a problem loading the kernel or initrd, so I don't think it's a cylinder boundary problem. I'm using kernel-2.4.18-SGI_XFS_1.1 on Red Hat 7.2. Does anyone have a clue as to what is the problem? In case anybody thinks to ask, this is the procedure I used for the "conversion:" First, you better make a boot floppy in case you can't boot off the MBR (which is the problem that I had). Then: 1) rsync -avx "/." to a directory on another partition eg. /home/r2/. 2) boot of the SGI XFS installer CD with "linux rescue" 3) "skip " the mounting of the root fs 4) mkdir /mnt/tmp and mount the other partition with the "/" files as /mnt/tmp 5) ln -s /mnt/tmp/r2 /mnt/sysimage Now all of the xfsprogs should be in your exec path. mkfs.xfs on the real root partition, mount it, then rsync -avx the files back to the root partition and reboot. -- "Jonathan F. Dill" (dill@umbi.umd.edu) UMBI CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Wed Apr 24 21:04: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 g3P44vwJ004817 for ; Wed, 24 Apr 2002 21:04:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P44vZt004816 for linux-xfs-outgoing; Wed, 24 Apr 2002 21:04:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sunny.pacific.net.au (sunny.pacific.net.au [203.25.148.40]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P44rwJ004789 for ; Wed, 24 Apr 2002 21:04:54 -0700 Received: from wisma.pacific.net.au (wisma.pacific.net.au [210.23.129.72]) by sunny.pacific.net.au with ESMTP id g3P45KXt029999 for ; Thu, 25 Apr 2002 14:05:20 +1000 (EST) Received: from jdc.local (ppp209.dyn224.pacific.net.au [203.100.224.209]) by wisma.pacific.net.au with ESMTP id OAA00049 for ; Thu, 25 Apr 2002 14:05:19 +1000 (EST) Received: from jdc.local (LOCALHOST [127.0.0.1]) by jdc.local (8.12.1/8.12.1/Debian -5) with ESMTP id g3P45HpS004724 for ; Thu, 25 Apr 2002 14:05:17 +1000 Received: (from jason@localhost) by jdc.local (8.12.1/8.12.1/Debian -5) id g3P45FSH004716; Thu, 25 Apr 2002 14:05:15 +1000 From: Jason White MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15559.32891.89807.1812@jdc.local> Date: Thu, 25 Apr 2002 14:05:15 +1000 To: linux-xfs Subject: Re: boot thinks / is still ext2 In-Reply-To: <3CC77E02.44593DF5@umbi.umd.edu> References: <3CC77E02.44593DF5@umbi.umd.edu> X-Mailer: VM 7.01 under Emacs 20.7.2 Reply-To: jasonw@ariel.ucs.unimelb.edu.au Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Are you sure the boot process is loading an XFS-enabled kernel? I would double check this just to be sure. From owner-linux-xfs@oss.sgi.com Wed Apr 24 21:07: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 g3P47CwJ004965 for ; Wed, 24 Apr 2002 21:07:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P47Beh004964 for linux-xfs-outgoing; Wed, 24 Apr 2002 21:07:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from ledzep.americas.sgi.com (eaganfw1.sgi.com [198.149.7.1]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P477wJ004934 for ; Wed, 24 Apr 2002 21:07:07 -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 XAA23812; Wed, 24 Apr 2002 23:07:30 -0500 (CDT) Received: from nstraz by maine.americas.sgi.com with local (Exim 3.35 #1 (Debian)) id 170aXY-0007bb-00; Wed, 24 Apr 2002 23:07:28 -0500 Date: Wed, 24 Apr 2002 23:07:27 -0500 From: Nathan Straz To: Jonathan Dill Cc: linux-xfs@oss.sgi.com Subject: Re: boot thinks / is still ext2 Message-ID: <20020425040727.GC28666@sgi.com> Mail-Followup-To: Jonathan Dill , linux-xfs@oss.sgi.com References: <3CC77E02.44593DF5@umbi.umd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3CC77E02.44593DF5@umbi.umd.edu> User-Agent: Mutt/1.3.28i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 11:54:42PM -0400, Jonathan Dill wrote: > I figured out a way to "convert" the root fs from ext2 to xfs by booting > off the CD. However, when I try to boot off the MBR, the boot process > fails apparently because it's still trying to treat "/" as an ext2 > filesystem (and hence no init is found). For now I'm booting off a > floppy disk, and that works fine. [...] > I'm using kernel-2.4.18-SGI_XFS_1.1 on Red Hat 7.2. Did you forget to remake your initrd? IIRC, in Red Hat's initrd images, it explicitly tells the kernel what type of file system root is. If the root was ext2 when you made it, you won't be able to reboot to an XFS root with that initrd. Remake the initrd (or hack it) and you should be all set. -- 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 Wed Apr 24 21:29:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P4T9wJ005458 for ; Wed, 24 Apr 2002 21:29:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P4T9tJ005457 for linux-xfs-outgoing; Wed, 24 Apr 2002 21:29:09 -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 g3P4T4wJ005431 for ; Wed, 24 Apr 2002 21:29:04 -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 XAA31147; Wed, 24 Apr 2002 23:29:27 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id XAA63943; Wed, 24 Apr 2002 23:29:27 -0500 (CDT) Date: Wed, 24 Apr 2002 23:29:27 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Jonathan Dill cc: linux-xfs@oss.sgi.com Subject: Re: boot thinks / is still ext2 In-Reply-To: <3CC77E02.44593DF5@umbi.umd.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, 24 Apr 2002, Jonathan Dill wrote: > I figured out a way to "convert" the root fs from ext2 to xfs by booting > off the CD. However, when I try to boot off the MBR, the boot process > fails apparently because it's still trying to treat "/" as an ext2 The problem may be an older mkfs.xfs - the latest version (actually for some time now, but not sure about the version on the installer CD) obliterates all traces of ext2 from the device; older ones could leave bits of ext2 superblocks lying around. If the kernel finds an ext2 bit before it finds an xfs bit (and it likely looks for ext2 first) it will probably assume that your root is ext2. I think you can specify the root fs type with the lilo argument "rootfstype=xfs" and that will make it look for xfs first. I've never actually tried it... but give it a shot! :) Nate's suggestion about remaking the initrd is probably a good one as well. -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 24 21:39: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 g3P4dnwJ005708 for ; Wed, 24 Apr 2002 21:39:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P4dnZN005707 for linux-xfs-outgoing; Wed, 24 Apr 2002 21:39:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P4dfwJ005677 for ; Wed, 24 Apr 2002 21:39:43 -0700 Received: from umbi.umd.edu ([129.6.113.182]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GV3X0F00.AXM; Thu, 25 Apr 2002 00:41:03 -0400 Message-ID: <3CC788FE.7BF1F40@umbi.umd.edu> Date: Thu, 25 Apr 2002 00:41:34 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Nathan Straz CC: linux-xfs@oss.sgi.com Subject: Re: boot thinks / is still ext2 References: <3CC77E02.44593DF5@umbi.umd.edu> <20020425040727.GC28666@sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Oops, you got it: [root@azuga /boot]# gunzip -cf initrd-2.4.18-SGI_XFS_1.1.img | strings | fgrep ext2 mount --ro -t ext2 /dev/root /sysroot Thanks a bunch! -- "Jonathan F. Dill" (dill@umbi.umd.edu) UMBI CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Wed Apr 24 23:52: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 g3P6qTwJ007252 for ; Wed, 24 Apr 2002 23:52:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P6qTGZ007251 for linux-xfs-outgoing; Wed, 24 Apr 2002 23:52:29 -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 g3P6q6wJ007220 for ; Wed, 24 Apr 2002 23:52:10 -0700 Received: by ids.org.au (Postfix, from userid 1001) id 7B7A727E7A; Thu, 25 Apr 2002 16:52:26 +1000 (EST) Date: Thu, 25 Apr 2002 16:52:26 +1000 From: Ian Cumming To: linux-xfs@oss.sgi.com Subject: xfsdump script Message-ID: <20020425065226.GA31909@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, Just sending out this simple script for anyone who wants to see an example of using xfsdump to backup a system to a local disk. I couldn't find any examples on the net, so I wrote my own. The script performs incremental backups of my system's filesystems to a local drive. At the start of each week a full (level 0) backup is performed. The xfsdumps are compressed with gzip to improve on space efficiency (in my case, I'm backup up 100Gb onto a 40Gb backup drive). I'm not a shell script guru, but this is what I came up with. Hopefully this might be useful to others looking for examples. rgds, Ian. -- backup.sh -- #!/bin/sh # Simple backup script to backup filesystems with xfsdump to a local disk. # Written by Ian Cumming, 25/04/02 - ian@ids.org.au # Operation: # Incremental backups are performed daily, with full backup performed on the first day of the week. # Dump files are archived with gzip to improve space efficiency. # Compressed dumps may be restored with "gunzip -c xfsdump.gz | xfsrestore -i - /retore/path" # Usage: # ./backup.sh [dump_level] # With no arguments, the script will backup filesystems using incremental dump options (-l) # The dump level is the offset from the first day of the week, ie: Sunday = 0, Monday = 1, etc.. # If dump_level is specified, then this will override the default behaviour. # Example: # An example cron job entry, to run at 4am every day. # 0 4 * * * * /root/scripts/backup.sh # commands WALL="/usr/bin/wall" XFSDUMP="/sbin/xfsdump" MOUNT="/bin/mount" UMOUNT="/bin/umount" DAY="date +%a" # print the day of the week # variables BACKUP_PATH="/mnt/backup" # could be subdir of mount path MOUNT_PATH="/mnt/backup" MEDIA_LABEL="Backup Drive (hdd5)" # it all starts here main() { # Perform pre backup operations pre_backup # Get the level of the backup (can be overriden with argv[1]) if [ "$1" != "" ] ; then echo "Overriding dump level with $1" LEVEL=$1 else LEVEL=`get_dump_level` fi # Perform the backups # These commands could be rolled into a separate function, but I decided against this to improve readability. # backup / $XFSDUMP -l $LEVEL -F -E -L "/" -M "$MEDIA_LABEL" - / | gzip - > "$BACKUP_PATH/root/root_xfsdump$LEVEL.gz" # backup /usr $XFSDUMP -l $LEVEL -F -E -L "/usr" -M "$MEDIA_LABEL" - /usr | gzip - > "$BACKUP_PATH/usr/usr_xfsdump$LEVEL.gz" # backup /var $XFSDUMP -l $LEVEL -F -E -L "/var" -M "$MEDIA_LABEL" - /var | gzip - > "$BACKUP_PATH/var/var_xfsdump$LEVEL.gz" # backup /pub $XFSDUMP -l $LEVEL -F -E -L "/pub" -M "$MEDIA_LABEL" - /pub | gzip - > "$BACKUP_PATH/pub/pub_xfsdump$LEVEL.gz" # backup /home $XFSDUMP -l $LEVEL -F -E -L "/home" -M "$MEDIA_LABEL" - /home | gzip - > "$BACKUP_PATH/home/home_xfsdump$LEVEL.gz" # Perform post backup operations post_backup } # Return the dump level, indexed from Sunday (level 0) get_dump_level() { case `$DAY` in Sun) echo 0;; Mon) echo 1;; Tue) echo 2;; Wed) echo 3;; Thu) echo 4;; Fri) echo 5;; Sat) echo 6;; esac } # commands to perform before the backup occurs pre_backup() { # warn users of backup `echo Daily backups are being performed. You may stay logged in while this occurs. | $WALL` # set the umask umask 027 # mount the backup volume echo "Mounting $MOUNT_PATH" if ! `$MOUNT $MOUNT_PATH`; then echo "Unable to mount $MOUNT_PATH (perhaps its already mounted?)" exit 0 fi } # commands to perform after the backup occurs post_backup() { # notify users that backup is complete `echo Daily backups completed. | $WALL` # unmount the backup volume echo "Unmounting $MOUNT_PATH" if ! `$UMOUNT $MOUNT_PATH`; then echo "Unable to umount $MOUNT_PATH" fi } # do main main $@ -- end backup.sh -- -- 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 Thu Apr 25 00:12:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P7C8wJ007675 for ; Thu, 25 Apr 2002 00:12:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P7C7k7007674 for linux-xfs-outgoing; Thu, 25 Apr 2002 00:12:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.deseretmail.com ([205.208.192.101]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3P7C2wJ007646 for ; Thu, 25 Apr 2002 00:12:03 -0700 Date: Thu, 25 Apr 2002 01:12:34 -0600 Message-Id: <200204250112.AA199491690@mail.deseretmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: "Roland_Kaiser" Reply-To: To: Subject: Linux request. X-Mailer: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, found your eMail- adress while surfing on: http://rpmfind.net/linux/RPM/Vendors.html So far, I never got a hook on unix, but I understand it as fast and reliable and opensource. What else are the advantages of this system? Where can I get info, do you know some other Linux- sites?. My website: http://www.aarontec.de/ Yours, sincerly Roland Kaiser. From owner-linux-xfs@oss.sgi.com Thu Apr 25 00:17: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 g3P7HdwJ007887 for ; Thu, 25 Apr 2002 00:17:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P7Hd06007886 for linux-xfs-outgoing; Thu, 25 Apr 2002 00:17:39 -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 g3P7HUwJ007858 for ; Thu, 25 Apr 2002 00:17:31 -0700 Received: from erbenson.alaska.net (209-pm32.nwc.alaska.net [209.112.158.209]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3P7Hwu65418 for ; Wed, 24 Apr 2002 23:17:58 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 118363938 for ; Wed, 24 Apr 2002 23:17:57 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 77C3210287; Wed, 24 Apr 2002 23:17:57 -0800 (AKDT) Date: Wed, 24 Apr 2002 23:17:57 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: boot thinks / is still ext2 Message-ID: <20020424231757.C21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <3CC77E02.44593DF5@umbi.umd.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/e2eDi0V/xtL+Mc8" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC77E02.44593DF5@umbi.umd.edu>; from dill@umbi.umd.edu on Wed, Apr 24, 2002 at 11:54:42PM -0400 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 --/e2eDi0V/xtL+Mc8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 24, 2002 at 11:54:42PM -0400, Jonathan Dill wrote: > First, you better make a boot floppy in case you can't boot off the MBR > (which is the problem that I had). Then: >=20 > 1) rsync -avx "/." to a directory on another partition eg. /home/r2/. >=20 > 2) boot of the SGI XFS installer CD with "linux rescue" >=20 > 3) "skip > " the mounting of the root fs >=20 > 4) mkdir /mnt/tmp and mount the other partition with the "/" files as > /mnt/tmp >=20 > 5) ln -s /mnt/tmp/r2 /mnt/sysimage >=20 > Now all of the xfsprogs should be in your exec path. mkfs.xfs on the > real root partition, mount it, then rsync -avx the files back to the > root partition and reboot. rsync isn't a very good tool for this, it will not preserve hard links. use: cd /=20 find . -mount -depth | cpio -dvmp /home/r2 --=20 Ethan Benson http://www.alaska.net/~erbenson/ --/e2eDi0V/xtL+Mc8 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 iEYEARECAAYFAjzHraUACgkQJKx7GixEevzIjACfYjPUKocHgPqTx+K/JCBiGtYv jc4An0ddEeJXEPTW3V6NbCn9Ms/ScUzi =FQF8 -----END PGP SIGNATURE----- --/e2eDi0V/xtL+Mc8-- From owner-linux-xfs@oss.sgi.com Thu Apr 25 02:13:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3P9DOwJ012655 for ; Thu, 25 Apr 2002 02:13:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3P9DJSN012653 for linux-xfs-outgoing; Thu, 25 Apr 2002 02:13: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 g3P9DCwJ012627 for ; Thu, 25 Apr 2002 02:13:14 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 170fJl-0004r2-00; Thu, 25 Apr 2002 10:13:33 +0100 Date: Thu, 25 Apr 2002 10:13:33 +0100 From: Christoph Hellwig To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: [PATCH] (repost) kmem_cache_zalloc Message-ID: <20020425101333.A18583@infradead.org> References: <1019682472.15455.33.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1019682472.15455.33.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Wed, Apr 24, 2002 at 04:07:52PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 04:07:52PM -0500, Eric Sandeen wrote: > We'd like to incorporate this into the kernel proper, and several others > chimed in that it would be useful, so here's the patch. If it's a no-go > with Linus, we can roll this functionality back under fs/xfs to reduce > our changes in the mainline kernel. What about getting rid of it completly instead? There are only two callers, one is in the pagebuf code and would benefit from letting slab cache initialized objects and the other in the emulation of IRIX's kmen_zone_zalloc.. Christoph From owner-linux-xfs@oss.sgi.com Thu Apr 25 03:09:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PA9HwJ019256 for ; Thu, 25 Apr 2002 03:09:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PA9H2C019255 for linux-xfs-outgoing; Thu, 25 Apr 2002 03:09:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [210.143.35.52]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PA9BwJ019225 for ; Thu, 25 Apr 2002 03:09:11 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO202.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g3PA9dR21144 for ; Thu, 25 Apr 2002 19:09:39 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g3PA9dR14978 for ; Thu, 25 Apr 2002 19:09:39 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g3PA9cr29554 for ; Thu, 25 Apr 2002 19:09:38 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA143 for ; Thu, 25 Apr 2002 19:09:35 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Thu Apr 25 19:09:34 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g3PA9Z667955 for ; Thu, 25 Apr 2002 19:09:35 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id g3PA9ZO04602 for ; Thu, 25 Apr 2002 19:09:35 +0900 To: linux-xfs@oss.sgi.com Subject: Re: maximum files In-Reply-To: <1019658798.27989.29.camel@jen.americas.sgi.com> References: <20020424160854G.masano@tnes.nec.co.jp> <1019658798.27989.29.camel@jen.americas.sgi.com> X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Common Lisp) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020425190934G.masano@tnes.nec.co.jp> Date: Thu, 25 Apr 2002 19:09:34 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thank you for your reply. From: Steve Lord > In order to deal with the 32 bit limit on Linux, and with issues with > 3rd party applications such as Legato Networker on Irix, changes > went in recently which adjust the inode placement policy of XFS to > restrict inodes to the part of the filesystem which keeps them within > 32 bits, unless the inode64 mount option is used. The fix is more > complex than that as we need to make data prefer space not suitable > for inodes to avoid filesystems which have lots of space but cannot > create new files. But it seems that XFSMNT_32BITINODES flag is always set. > The theoretical maximum for XFS without the limits imposed by the > Linux block and vfs layers is probably on the order of 2^6x which > is a very very big number and would probably require the output of > several major drive vendors for a long time to construct, around 115 > million 160G drives by my calculation! Great! How about 64bit linux? (e.g. XFS for IA-64 linux) -- Masano From owner-linux-xfs@oss.sgi.com Thu Apr 25 04:00: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 g3PB0wwJ020508 for ; Thu, 25 Apr 2002 04:00:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PB0wbw020507 for linux-xfs-outgoing; Thu, 25 Apr 2002 04:00:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from smtpzilla1.xs4all.nl (smtpzilla1.xs4all.nl [194.109.127.137]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PB0rwJ020481 for ; Thu, 25 Apr 2002 04:00:54 -0700 Received: from auto-nb1.xs4all.nl (213-84-127-28.adsl.xs4all.nl [213.84.127.28]) by smtpzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g3PB1Kpk018549; Thu, 25 Apr 2002 13:01:21 +0200 (CEST) Message-Id: <4.3.2.7.2.20020425130052.037a6910@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Apr 2002 13:02:44 +0200 To: ASANO Masahiro , linux-xfs@oss.sgi.com From: Seth Mos Subject: Re: maximum files In-Reply-To: <20020425190934G.masano@tnes.nec.co.jp> References: <1019658798.27989.29.camel@jen.americas.sgi.com> <20020424160854G.masano@tnes.nec.co.jp> <1019658798.27989.29.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 19:09 25-4-2002 +0900, ASANO Masahiro wrote: >Great! >How about 64bit linux? (e.g. XFS for IA-64 linux) Or x86-64 which is planned for release this autumn. At least that is what the AMD roadmap says. 64bit computing for mainstream pricing. I want one. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Thu Apr 25 06:35:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PDZtwJ025904 for ; Thu, 25 Apr 2002 06:35:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PDZtDT025903 for linux-xfs-outgoing; Thu, 25 Apr 2002 06:35:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PDZkwJ025875 for ; Thu, 25 Apr 2002 06:35:47 -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 IAA38528; Thu, 25 Apr 2002 08:36:10 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA34903; Thu, 25 Apr 2002 08:36:09 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PDWS008349; Thu, 25 Apr 2002 08:32:28 -0500 Subject: Re: maximum files From: Steve Lord To: ASANO Masahiro Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020425190934G.masano@tnes.nec.co.jp> References: <20020424160854G.masano@tnes.nec.co.jp> <1019658798.27989.29.camel@jen.americas.sgi.com> <20020425190934G.masano@tnes.nec.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 25 Apr 2002 08:32:28 -0500 Message-Id: <1019741548.8309.3.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 05:09, ASANO Masahiro wrote: > Thank you for your reply. > > From: Steve Lord > > > In order to deal with the 32 bit limit on Linux, and with issues with > > 3rd party applications such as Legato Networker on Irix, changes > > went in recently which adjust the inode placement policy of XFS to > > restrict inodes to the part of the filesystem which keeps them within > > 32 bits, unless the inode64 mount option is used. The fix is more > > complex than that as we need to make data prefer space not suitable > > for inodes to avoid filesystems which have lots of space but cannot > > create new files. > > But it seems that XFSMNT_32BITINODES flag is always set. On Linux yes, since the upper layers of the vfs impose this limitation on the size of the inode. Makes the inode64 mount option a little useless on linux to be honest. > > > The theoretical maximum for XFS without the limits imposed by the > > Linux block and vfs layers is probably on the order of 2^6x which > > is a very very big number and would probably require the output of > > several major drive vendors for a long time to construct, around 115 > > million 160G drives by my calculation! > > Great! > How about 64bit linux? (e.g. XFS for IA-64 linux) Well, so far that does not help much, it all depends on what the sizes of the basic types generated by gcc are on those platforms, I do not have a list for all platforms, but so far as I know, ia64 for example is still stuck with 32 bit inodes and 2Tbyte block devices. However, a patch was just floated on the ia64 list to do 64 bit device access and other components of that work have appeared in the past. 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 25 06:41:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PDfMwJ026205 for ; Thu, 25 Apr 2002 06:41:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PDfMHC026204 for linux-xfs-outgoing; Thu, 25 Apr 2002 06:41: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 g3PDfHwJ026178 for ; Thu, 25 Apr 2002 06:41:17 -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 IAA37893; Thu, 25 Apr 2002 08:41:42 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA73556; Thu, 25 Apr 2002 08:41:41 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PDc1X08367; Thu, 25 Apr 2002 08:38:01 -0500 Subject: Re: [PATCH] (repost) kmem_cache_zalloc From: Steve Lord To: Christoph Hellwig Cc: Eric Sandeen , linux-xfs@oss.sgi.com In-Reply-To: <20020425101333.A18583@infradead.org> References: <1019682472.15455.33.camel@stout.americas.sgi.com> <20020425101333.A18583@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 25 Apr 2002 08:38:00 -0500 Message-Id: <1019741880.8353.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 04:13, Christoph Hellwig wrote: > On Wed, Apr 24, 2002 at 04:07:52PM -0500, Eric Sandeen wrote: > > We'd like to incorporate this into the kernel proper, and several others > > chimed in that it would be useful, so here's the patch. If it's a no-go > > with Linus, we can roll this functionality back under fs/xfs to reduce > > our changes in the mainline kernel. > > What about getting rid of it completly instead? > > There are only two callers, one is in the pagebuf code and would benefit > from letting slab cache initialized objects and the other in the emulation > of IRIX's kmen_zone_zalloc.. It is a little more complex than those two places - they do not know how big the memory is, that is hidden in the zone itself - which is not accessible outside slab.c. You need to go back to the callers of kmem_zone_zalloc and do the work there. Actually there are only 19 of them, so it is not too bad. 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 25 06:46:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PDkEwJ026412 for ; Thu, 25 Apr 2002 06:46:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PDkEWN026411 for linux-xfs-outgoing; Thu, 25 Apr 2002 06:46:14 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PDk8wJ026383 for ; Thu, 25 Apr 2002 06:46:09 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g3PDk8b11681; Thu, 25 Apr 2002 15:46:08 +0200 Date: Thu, 25 Apr 2002 15:46:07 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Steve Lord Cc: ASANO Masahiro , linux-xfs@oss.sgi.com Subject: Re: maximum files Message-ID: <20020425154607.B28067@vestdata.no> References: <20020424160854G.masano@tnes.nec.co.jp> <1019658798.27989.29.camel@jen.americas.sgi.com> <20020425190934G.masano@tnes.nec.co.jp> <1019741548.8309.3.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1019741548.8309.3.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 25, 2002 at 08:32:28AM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g3PDk8b11681 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3PDkAwJ026384 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 08:32:28AM -0500, Steve Lord wrote: > > Great! > > How about 64bit linux? (e.g. XFS for IA-64 linux) > > Well, so far that does not help much, it all depends on what the sizes > of the basic types generated by gcc are on those platforms, I do not > have a list for all platforms, but so far as I know, ia64 for example > is still stuck with 32 bit inodes and 2Tbyte block devices. However, > a patch was just floated on the ia64 list to do 64 bit device access > and other components of that work have appeared in the past. Ben LaHaise wrote patches to support >2TB devices. It should work on both i386 and ia64 (and other platforms), but will ofcourse be faster on 64 bit platforms. I don't know if it has been included in 2.5 yet, or of it will be, but the patch is out there. -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Thu Apr 25 06:50: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 g3PDoDwJ026601 for ; Thu, 25 Apr 2002 06:50:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PDoDa3026600 for linux-xfs-outgoing; Thu, 25 Apr 2002 06:50:13 -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 g3PDo8wJ026571 for ; Thu, 25 Apr 2002 06:50:08 -0700 Received: by burgers.bubbanfriends.org (Postfix, from userid 500) id 4CA6E401A40; Thu, 25 Apr 2002 09:50:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by burgers.bubbanfriends.org (Postfix) with ESMTP id 2605AC0008D; Thu, 25 Apr 2002 09:50:41 -0400 (EDT) Date: Thu, 25 Apr 2002 09:50:40 -0400 (EDT) From: Mike Burger To: Roland_Kaiser Cc: linux-xfs@oss.sgi.com Subject: Re: Linux request. In-Reply-To: <200204250112.AA199491690@mail.deseretmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Try http://www.linux.org. On Thu, 25 Apr 2002, Roland_Kaiser wrote: > Hi, found your eMail- adress while surfing on: > http://rpmfind.net/linux/RPM/Vendors.html > > So far, I never got a hook on unix, but I understand it as fast and > reliable and opensource. What else are the advantages of this system? > Where can I get info, do you know some other Linux- sites?. > > My website: > http://www.aarontec.de/ > > Yours, > sincerly > > Roland Kaiser. > From owner-linux-xfs@oss.sgi.com Thu Apr 25 06:52:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PDq9wJ026701 for ; Thu, 25 Apr 2002 06:52:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PDq90v026700 for linux-xfs-outgoing; Thu, 25 Apr 2002 06:52:09 -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 g3PDq1wJ026665 for ; Thu, 25 Apr 2002 06:52: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 IAA38570; Thu, 25 Apr 2002 08:52:21 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA59392; Thu, 25 Apr 2002 08:52:21 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PDmeL08763; Thu, 25 Apr 2002 08:48:40 -0500 Subject: Re: maximum files From: Steve Lord To: Ragnar =?ISO-8859-1?Q?Kj=F8rstad?= Cc: ASANO Masahiro , linux-xfs@oss.sgi.com In-Reply-To: <20020425154607.B28067@vestdata.no> References: <20020424160854G.masano@tnes.nec.co.jp> <1019658798.27989.29.camel@jen.americas.sgi.com> <20020425190934G.masano@tnes.nec.co.jp> <1019741548.8309.3.camel@jen.americas.sgi.com> <20020425154607.B28067@vestdata.no> Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: Ximian Evolution 1.0.3 Date: 25 Apr 2002 08:48:40 -0500 Message-Id: <1019742520.8353.16.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3PDq2wJ026670 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 08:46, Ragnar Kjørstad wrote: > On Thu, Apr 25, 2002 at 08:32:28AM -0500, Steve Lord wrote: > > > Great! > > > How about 64bit linux? (e.g. XFS for IA-64 linux) > > > > Well, so far that does not help much, it all depends on what the sizes > > of the basic types generated by gcc are on those platforms, I do not > > have a list for all platforms, but so far as I know, ia64 for example > > is still stuck with 32 bit inodes and 2Tbyte block devices. However, > > a patch was just floated on the ia64 list to do 64 bit device access > > and other components of that work have appeared in the past. > > Ben LaHaise wrote patches to support >2TB devices. It should work on > both i386 and ia64 (and other platforms), but will ofcourse be faster on > 64 bit platforms. > > I don't know if it has been included in 2.5 yet, or of it will be, but > the patch is out there. It has not been, I think the issue was it made some basic types 64 bit across the board - which negatively impacts the 32 bit kernels. That's just from memory. The patch on the ia64 list was a lot more comprehensive, everything from the page cache, through fiber channel drivers to the partition table code was affected. It almost looks as if someone has tried it with real disk space in this case. It might have the same 64 bit on 32 bit issues though - but it should be possible to make it configurable. Here is a link: https://external-lists.vasoftware.com/archives//linux-ia64/2002-April/003416.html Steve > > > > -- > Ragnar Kjørstad > Big Storage -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Apr 25 06:56: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 g3PDuOwJ026980 for ; Thu, 25 Apr 2002 06:56:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PDuOjT026979 for linux-xfs-outgoing; Thu, 25 Apr 2002 06:56:24 -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 g3PDuIwJ026953 for ; Thu, 25 Apr 2002 06:56:19 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 170jjq-0007Jk-00; Thu, 25 Apr 2002 14:56:46 +0100 Date: Thu, 25 Apr 2002 14:56:46 +0100 From: Christoph Hellwig To: Steve Lord Cc: Eric Sandeen , linux-xfs@oss.sgi.com Subject: Re: [PATCH] (repost) kmem_cache_zalloc Message-ID: <20020425145646.A28129@infradead.org> References: <1019682472.15455.33.camel@stout.americas.sgi.com> <20020425101333.A18583@infradead.org> <1019741880.8353.8.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1019741880.8353.8.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 25, 2002 at 08:38:00AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 08:38:00AM -0500, Steve Lord wrote: > > There are only two callers, one is in the pagebuf code and would benefit > > from letting slab cache initialized objects and the other in the emulation > > of IRIX's kmen_zone_zalloc.. > > It is a little more complex than those two places - they do not know > how big the memory is, that is hidden in the zone itself - which is > not accessible outside slab.c. You need to go back to the callers of > kmem_zone_zalloc and do the work there. Actually there are only 19 > of them, so it is not too bad. parse /proc/slabinfo in kernelspace to find it When looking over all uses of kmen_zone_* in the XFS code I see some place that look like opportunities for a Linux SLAB cache - and that one should be easily emulatable on IRIX by always calling the constructure after getting memory from the lowlevel allocator (sorry for lack of IRIX lowlevel knowledge :)) Christoph From owner-linux-xfs@oss.sgi.com Thu Apr 25 08:01: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 g3PF1wwJ000697 for ; Thu, 25 Apr 2002 08:01:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PF1wZP000696 for linux-xfs-outgoing; Thu, 25 Apr 2002 08:01:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from musuko.uchicago.edu (musuko.uchicago.edu [128.135.39.147]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PF1owJ000666 for ; Thu, 25 Apr 2002 08:01:51 -0700 Received: (from sl70@localhost) by musuko.uchicago.edu (8.11.6/8.11.2) id g3PF2Jb24827; Thu, 25 Apr 2002 10:02:19 -0500 X-Authentication-Warning: musuko.uchicago.edu: sl70 set sender to s-luppescu@uchicago.edu using -f Subject: Worth upgrading to 1.1? From: Stuart Luppescu To: Linux XFS List Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-d/i8YyC3a/sPvovt3ebT" X-Mailer: Ximian Evolution 1.0.3 Date: 25 Apr 2002 10:02:19 -0500 Message-Id: <1019746939.22515.9.camel@musuko.uchicago.edu> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-d/i8YyC3a/sPvovt3ebT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I have kernel 2.4.18 with XFS 1.1 Prerelease 2 installed and haven't had any troubles with it. Is it worth it for me to upgrade to 1.1? (I can only find a Changelog showing what was changed between 1.02 and 1.1.) --=20 Stuart Luppescu -=3D- s-luppescu@uchicago.edu=20=20=20=20=20=20=20=20 University of Chicago -=3D- CCSR=20 =1B$B:MJ8$HCRF`H~$NIc=1B(B -=3D- Kernel 2.4.18-xfs=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 It's hard not to like a man of many qualities, even if most of them are bad.=20 =20 --=-d/i8YyC3a/sPvovt3ebT 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 iEYEABECAAYFAjzIGnsACgkQDBHcBS0tWxNTgACg0M/8fkFC7F9q9lwlZ3F/H33I uooAnRknWmTDntPymT9L6HqdUX+X//WZ =Baw9 -----END PGP SIGNATURE----- --=-d/i8YyC3a/sPvovt3ebT-- From owner-linux-xfs@oss.sgi.com Thu Apr 25 08:09:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PF9fwJ000946 for ; Thu, 25 Apr 2002 08:09:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PF9fmj000945 for linux-xfs-outgoing; Thu, 25 Apr 2002 08:09:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sol.rune.org (sol.rune.org [207.201.197.191]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PF9GwJ000914 for ; Thu, 25 Apr 2002 08:09:17 -0700 Received: from localhost (sarwer@localhost) by sol.rune.org (8.11.6/8.11.6) with ESMTP id g3PF9j713051; Thu, 25 Apr 2002 11:09:45 -0400 Date: Thu, 25 Apr 2002 11:09:45 -0400 (EDT) From: Sarwer Zafiruddin To: cc: Subject: XFS recovery on root filesystem Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I was curious about somthing. I have a system running the RedHat distribution of XFS 1.1 on a system. When I upgraded the RPM's and the redhat kernel (I recompiled the kernel using the SGI XFS kernel SRPM on my system) and rebooted the system, I noticed the following messages in my dmesg log (I rebooted the system remotely): XFS mounting filesystem ide0(3,2) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: ide0(3,2) (dev: 3/2) Ending XFS recovery on filesystem: ide0(3,2) (dev: 3/2) VFS: Mounted root (xfs filesystem) readonly. None of my other filesystems performed a recovery XFS mounting filesystem ide0(3,1) XFS mounting filesystem ide0(3,10) XFS mounting filesystem ide0(3,7) XFS mounting filesystem ide0(3,8) XFS mounting filesystem ide0(3,3) XFS mounting filesystem ide0(3,9) I was runing the SGI XFS 1.0.2 (using installer) Redhat 7.2, and the system was up for more than 120 days before the reboot. QUESTION #1: What could have prompted the recovery??? Un-clean unmount during the reboot??? The fact the upgrade process requires a xfs recovery to be performed on the root fs??? Could it be similar to ext2 where if the fs has not been check in X amount of days it does a fsck equivlent??? QUESTION #2: Should I bring my system down to maintaince, boot off CD and run xfs_repair on my root filesystem to make sure everything is consistant? Here is some extra info... [root@some /]# uname -a Linux some.host.name 2.4.9-31SGI_XFS_1.1 #1 Thu Apr 18 14:36:41 EDT 2002 i686 unknown [root@some /]# rpm -qa | grep -i xfs xfsdump-2.0.1-0 kernel-source-2.4.9-31SGI_XFS_1.1 anaconda-7.2-11XFS kernel-headers-2.4.9-31SGI_XFS_1.1 kernel-2.4.9-31SGI_XFS_1.1 anaconda-runtime-7.2-11XFS xfsprogs-devel-2.0.3-0 kernel-doc-2.4.9-31SGI_XFS_1.1 kernel-2.4.9-13SGI_XFS_1.0.2 xfsprogs-2.0.3-0 [root@some /]# kgcc -v Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) full dmesg... Linux version 2.4.9-31SGI_XFS_1.1 (root@some.host.name) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Apr 18 14:36:41 EDT 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 0000000006ffd000 (usable) BIOS-e820: 0000000006ffd000 - 0000000006fff000 (ACPI data) BIOS-e820: 0000000006fff000 - 0000000007000000 (ACPI NVS) BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) On node 0 totalpages: 28669 zone(0): 4096 pages. zone(1): 24573 pages. zone(2): 0 pages. Kernel command line: auto BOOT_IMAGE=linux ro root=302 BOOT_FILE=/boot/vmlinuz-2.4.9-31SGI_XFS_1.1 Initializing CPU#0 Detected 801.835 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 1599.07 BogoMIPS Memory: 108408k/114676k available (2521k kernel code, 5116k reserved, 97k data, 224k init, 0k highmem) kdb version 2.1 by Scott Lurndal, Keith Owens. Copyright SGI, All Rights Reserved Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) Mount-cache hash table entries: 2048 (order: 2, 16384 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 32768 (order: 6, 262144 bytes) CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 128K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000 CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000 CPU: Common caps: 0383f9ff 00000000 00000000 00000000 CPU: Intel Celeron (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. Checking for popad bug... OK. POSIX conformance testing by UNIFIX mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) mtrr: detected mtrr type: Intel PCI: PCI BIOS revision 2.10 entry at 0xf0e60, last bus=1 PCI: Using configuration type 1 PCI: Probing PCI hardware PCI: Using IRQ router SIS [1039/0008] at 00:01.0 isapnp: Scanning for PnP cards... isapnp: No Plug & Play device found Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket Simple Boot Flag extension found and enabled. apm: BIOS version 1.2 Flags 0x0b (Driver version 1.14) Starting kswapd v1.8 VFS: Diskquotas version dquot_6.5.0 initialized SGI XFS with ACLs, quota, no debug enabled pty: 512 Unix98 ptys configured Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled ttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Real Time Clock Driver v1.10e block: queued sectors max/low 71904kB/23968kB, 256 slots per queue RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize Uniform Multi-Platform E-IDE driver Revision: 6.31 ide: Assuming 33MHz PCI bus speed for PIO modes; override with idebus=xx SIS5513: IDE controller on PCI bus 00 dev 01 SIS5513: chipset revision 208 SIS5513: not 100% native mode: will probe irqs later SiS630 ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio hda: SAMSUNG SV2001H, ATA DISK drive hdc: WDC AC36400L, ATA DISK drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 ide1 at 0x170-0x177,0x376 on irq 15 hda: 39179952 sectors (20060 MB) w/1945KiB Cache, CHS=2438/255/63, UDMA(33) hdc: 12594960 sectors (6449 MB) w/256KiB Cache, CHS=13328/15/63, UDMA(33) Partition check: hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 > hdc: [PTBL] [784/255/63] hdc1 hdc2 hdc3 hdc4 < hdc5 hdc6 hdc7 hdc8 hdc9 hdc10 > floppy0: no floppy controllers found md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 8192 bind 8192) Linux IP multicast router 0.06 plus PIM-SM NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. XFS mounting filesystem ide0(3,2) XFS: WARNING: recovery required on readonly filesystem. XFS: write access will be enabled during mount. Starting XFS recovery on filesystem: ide0(3,2) (dev: 3/2) Ending XFS recovery on filesystem: ide0(3,2) (dev: 3/2) VFS: Mounted root (xfs filesystem) readonly. Freeing unused kernel memory: 224k freed Adding Swap: 265032k swap-space (priority -1) Adding Swap: 265032k swap-space (priority -2) XFS mounting filesystem ide0(3,1) XFS mounting filesystem ide0(3,10) XFS mounting filesystem ide0(3,7) XFS mounting filesystem ide0(3,8) XFS mounting filesystem ide0(3,3) XFS mounting filesystem ide0(3,9) 0x378: FIFO is 16 bytes 0x378: writeIntrThreshold is 16 0x378: readIntrThreshold is 16 0x378: PWord is 8 bits 0x378: Interrupts are ISA-Pulses 0x378: ECP port cfgA=0x10 cfgB=0x40 0x378: ECP settings irq= dma= parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP] parport0: irq 7 detected parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) parport0: cpp_daisy: aa5500ff(38) parport0: assign_addrs: aa5500ff(38) NET4: Linux IPX 0.47 for NET4.0 IPX Portions Copyright (c) 1995 Caldera, Inc. IPX Portions Copyright (c) 2000, 2001 Conectiva, Inc. NET4: AppleTalk 0.18a for Linux NET4.0 sis900.c: v1.07.11 4/10/2001 PCI: Found IRQ 10 for device 00:01.1 eth0: SiS 900 Internal MII PHY transceiver found at address 1. eth0: Using transceiver found at address 1 as default eth0: SiS 900 PCI Fast Ethernet at 0xd400, IRQ 10, 00:e0:18:06:72:a6. eth0: Media Link On 100mbps full-duplex LVM version 1.0.3(19/02/2002) module loaded Thanks in advance for any help... Sarwer Zafiruddin PS - Please CC any replies to me, I am not in the list... -------------------------- System Administrator Rune Information Services http://www.rune.org e-mail: sarwer@rune.org -------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 08:23: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 g3PFN7wJ001653 for ; Thu, 25 Apr 2002 08:23:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PFN76e001652 for linux-xfs-outgoing; Thu, 25 Apr 2002 08:23:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PFN1wJ001626 for ; Thu, 25 Apr 2002 08:23:02 -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 KAA40339; Thu, 25 Apr 2002 10:23:26 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id KAA27058; Thu, 25 Apr 2002 10:23:26 -0500 (CDT) Subject: Re: Worth upgrading to 1.1? From: Eric Sandeen To: Stuart Luppescu Cc: Linux XFS List In-Reply-To: <1019746939.22515.9.camel@musuko.uchicago.edu> References: <1019746939.22515.9.camel@musuko.uchicago.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 25 Apr 2002 10:23:26 -0500 Message-Id: <1019748206.30094.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 10:02, Stuart Luppescu wrote: > I have kernel 2.4.18 with XFS 1.1 Prerelease 2 installed and haven't had > any troubles with it. Is it worth it for me to upgrade to 1.1? (I can > only find a Changelog showing what was changed between 1.02 and 1.1.) I would. Sorry, should have been better about changelogs for prereleases. At least these were in there: refcache dirty timer fix ia64 warnings fix inode32 fix pagebuf_read_full_page error handling fix Also a quota bug, acl changes, and some userspace fixes. Nothing that's going to corrupt your data or anything catastrophic, but there's a reason we had 2 more prereleases after PR2! :) -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 25 08:25: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 g3PFPRwJ001781 for ; Thu, 25 Apr 2002 08:25:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PFPRAh001780 for linux-xfs-outgoing; Thu, 25 Apr 2002 08:25: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 g3PFPIwJ001747 for ; Thu, 25 Apr 2002 08:25: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 KAA32799; Thu, 25 Apr 2002 10:25:43 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA80648; Thu, 25 Apr 2002 10:25:43 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PFM2s10762; Thu, 25 Apr 2002 10:22:02 -0500 Subject: Re: XFS recovery on root filesystem From: Steve Lord To: Sarwer Zafiruddin 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: 25 Apr 2002 10:22:02 -0500 Message-Id: <1019748122.8309.52.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 10:09, Sarwer Zafiruddin wrote: > Hello, > > I was curious about somthing. I have a system running the RedHat > distribution of XFS 1.1 on a system. When I upgraded the RPM's and the > redhat kernel (I recompiled the kernel using the SGI XFS kernel SRPM on my > system) and rebooted the system, I noticed the following messages in my > dmesg log (I rebooted the system remotely): > > XFS mounting filesystem ide0(3,2) > XFS: WARNING: recovery required on readonly filesystem. > XFS: write access will be enabled during mount. > Starting XFS recovery on filesystem: ide0(3,2) (dev: 3/2) > Ending XFS recovery on filesystem: ide0(3,2) (dev: 3/2) > VFS: Mounted root (xfs filesystem) readonly. > > None of my other filesystems performed a recovery > > XFS mounting filesystem ide0(3,1) > XFS mounting filesystem ide0(3,10) > XFS mounting filesystem ide0(3,7) > XFS mounting filesystem ide0(3,8) > XFS mounting filesystem ide0(3,3) > XFS mounting filesystem ide0(3,9) > > I was runing the SGI XFS 1.0.2 (using installer) Redhat 7.2, and the > system was up for more than 120 days before the reboot. > > QUESTION #1: > > What could have prompted the recovery??? Un-clean unmount during the > reboot??? The fact the upgrade process requires a xfs recovery to be > performed on the root fs??? Could it be similar to ext2 where if the fs > has not been check in X amount of days it does a fsck equivlent??? Almost certainly the remount readonly in the shutdown path did not work, there was a bug in this, possibly your old kernel was suffering from it, or you had a version of the user space init scripts which limited the remount readonly to ext2 filesystems, although I thought that was 7.1 and earlier user space. Try another reboot with the current kernel and see if it comes up clean. > > QUESTION #2: > > Should I bring my system down to maintaince, boot off CD and run > xfs_repair on my root filesystem to make sure everything is consistant? > Probably not needed. 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 25 08:26:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PFQEwJ001869 for ; Thu, 25 Apr 2002 08:26:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PFQEaq001868 for linux-xfs-outgoing; Thu, 25 Apr 2002 08:26: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 g3PFPlwJ001798 for ; Thu, 25 Apr 2002 08:25:48 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id B0454C201; Thu, 25 Apr 2002 17:26: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 RAA15322; Thu, 25 Apr 2002 17:26:09 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id C602B57306; Thu, 25 Apr 2002 17:24:42 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id DEA5625835; Thu, 25 Apr 2002 17:24:41 +0200 (CEST) Message-ID: <3CC81FB9.3803729D@ch.sauter-bc.com> Date: Thu, 25 Apr 2002 17:24:41 +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: Sarwer Zafiruddin Cc: linux-xfs@oss.sgi.com Subject: Re: XFS recovery on root filesystem References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Sarwer Zafiruddin schrieb: > > Hello, > > I was curious about somthing. I have a system running the RedHat > distribution of XFS 1.1 on a system. When I upgraded the RPM's and the > redhat kernel (I recompiled the kernel using the SGI XFS kernel SRPM on my > system) and rebooted the system, I noticed the following messages in my > dmesg log (I rebooted the system remotely): > > XFS mounting filesystem ide0(3,2) > XFS: WARNING: recovery required on readonly filesystem. > XFS: write access will be enabled during mount. > Starting XFS recovery on filesystem: ide0(3,2) (dev: 3/2) > Ending XFS recovery on filesystem: ide0(3,2) (dev: 3/2) > VFS: Mounted root (xfs filesystem) readonly. > > None of my other filesystems performed a recovery I guess you have also updated glibc. IIRC when updating glibc, the root fs can not be unmounted properly (remount readonly) on shutdown and therefore you'll notice recovery on the first boot after glibc upgrade. It has always been like this and was very annoying with big root fs on ext2 :) I'm sure it's not kernel related. Can you confirm this? -Simon > > XFS mounting filesystem ide0(3,1) > XFS mounting filesystem ide0(3,10) > XFS mounting filesystem ide0(3,7) > XFS mounting filesystem ide0(3,8) > XFS mounting filesystem ide0(3,3) > XFS mounting filesystem ide0(3,9) > > I was runing the SGI XFS 1.0.2 (using installer) Redhat 7.2, and the > system was up for more than 120 days before the reboot. > > QUESTION #1: > > What could have prompted the recovery??? Un-clean unmount during the > reboot??? The fact the upgrade process requires a xfs recovery to be > performed on the root fs??? Could it be similar to ext2 where if the fs > has not been check in X amount of days it does a fsck equivlent??? > > QUESTION #2: > > Should I bring my system down to maintaince, boot off CD and run > xfs_repair on my root filesystem to make sure everything is consistant? > > Here is some extra info... > > [root@some /]# uname -a > Linux some.host.name 2.4.9-31SGI_XFS_1.1 #1 Thu Apr 18 14:36:41 EDT 2002 i686 unknown > [root@some /]# rpm -qa | grep -i xfs > xfsdump-2.0.1-0 > kernel-source-2.4.9-31SGI_XFS_1.1 > anaconda-7.2-11XFS > kernel-headers-2.4.9-31SGI_XFS_1.1 > kernel-2.4.9-31SGI_XFS_1.1 > anaconda-runtime-7.2-11XFS > xfsprogs-devel-2.0.3-0 > kernel-doc-2.4.9-31SGI_XFS_1.1 > kernel-2.4.9-13SGI_XFS_1.0.2 > xfsprogs-2.0.3-0 > [root@some /]# kgcc -v > Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs > gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) > > full dmesg... > > Linux version 2.4.9-31SGI_XFS_1.1 (root@some.host.name) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #1 Thu Apr 18 14:36:41 EDT 2002 > BIOS-provided physical RAM map: > BIOS-e820: 0000000000000000 - 00000000000a0000 (usable) > BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) > BIOS-e820: 0000000000100000 - 0000000006ffd000 (usable) > BIOS-e820: 0000000006ffd000 - 0000000006fff000 (ACPI data) > BIOS-e820: 0000000006fff000 - 0000000007000000 (ACPI NVS) > BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved) > On node 0 totalpages: 28669 > zone(0): 4096 pages. > zone(1): 24573 pages. > zone(2): 0 pages. > Kernel command line: auto BOOT_IMAGE=linux ro root=302 BOOT_FILE=/boot/vmlinuz-2.4.9-31SGI_XFS_1.1 > Initializing CPU#0 > Detected 801.835 MHz processor. > Console: colour VGA+ 80x25 > Calibrating delay loop... 1599.07 BogoMIPS > Memory: 108408k/114676k available (2521k kernel code, 5116k reserved, 97k data, 224k init, 0k highmem) > kdb version 2.1 by Scott Lurndal, Keith Owens. Copyright SGI, All Rights Reserved > Dentry-cache hash table entries: 16384 (order: 5, 131072 bytes) > Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) > Mount-cache hash table entries: 2048 (order: 2, 16384 bytes) > Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) > Page-cache hash table entries: 32768 (order: 6, 262144 bytes) > CPU: Before vendor init, caps: 0383f9ff 00000000 00000000, vendor = 0 > CPU: L1 I cache: 16K, L1 D cache: 16K > CPU: L2 cache: 128K > Intel machine check architecture supported. > Intel machine check reporting enabled on CPU#0. > CPU: After vendor init, caps: 0383f9ff 00000000 00000000 00000000 > CPU: After generic, caps: 0383f9ff 00000000 00000000 00000000 > CPU: Common caps: 0383f9ff 00000000 00000000 00000000 > CPU: Intel Celeron (Coppermine) stepping 06 > Enabling fast FPU save and restore... done. > Enabling unmasked SIMD FPU exception support... done. > Checking 'hlt' instruction... OK. > Checking for popad bug... OK. > POSIX conformance testing by UNIFIX > mtrr: v1.40 (20010327) Richard Gooch (rgooch@atnf.csiro.au) > mtrr: detected mtrr type: Intel > PCI: PCI BIOS revision 2.10 entry at 0xf0e60, last bus=1 > PCI: Using configuration type 1 > PCI: Probing PCI hardware > PCI: Using IRQ router SIS [1039/0008] at 00:01.0 > isapnp: Scanning for PnP cards... > isapnp: No Plug & Play device found > Linux NET4.0 for Linux 2.4 > Based upon Swansea University Computer Society NET3.039 > Initializing RT netlink socket > Simple Boot Flag extension found and enabled. > apm: BIOS version 1.2 Flags 0x0b (Driver version 1.14) > Starting kswapd v1.8 > VFS: Diskquotas version dquot_6.5.0 initialized > SGI XFS with ACLs, quota, no debug enabled > pty: 512 Unix98 ptys configured > Serial driver version 5.05c (2001-07-08) with MANY_PORTS MULTIPORT SHARE_IRQ SERIAL_PCI ISAPNP enabled > ttyS00 at 0x03f8 (irq = 4) is a 16550A > ttyS01 at 0x02f8 (irq = 3) is a 16550A > Real Time Clock Driver v1.10e > block: queued sectors max/low 71904kB/23968kB, 256 slots per queue > RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize > Uniform Multi-Platform E-IDE driver Revision: 6.31 > ide: Assuming 33MHz PCI bus speed for PIO modes; override with idebus=xx > SIS5513: IDE controller on PCI bus 00 dev 01 > SIS5513: chipset revision 208 > SIS5513: not 100% native mode: will probe irqs later > SiS630 > ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:pio > ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:pio > hda: SAMSUNG SV2001H, ATA DISK drive > hdc: WDC AC36400L, ATA DISK drive > ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 > ide1 at 0x170-0x177,0x376 on irq 15 > hda: 39179952 sectors (20060 MB) w/1945KiB Cache, CHS=2438/255/63, UDMA(33) > hdc: 12594960 sectors (6449 MB) w/256KiB Cache, CHS=13328/15/63, UDMA(33) > Partition check: > hda: hda1 hda2 hda3 hda4 < hda5 hda6 hda7 hda8 hda9 hda10 > > hdc: [PTBL] [784/255/63] hdc1 hdc2 hdc3 hdc4 < hdc5 hdc6 hdc7 hdc8 hdc9 hdc10 > > floppy0: no floppy controllers found > md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 > md: Autodetecting RAID arrays. > md: autorun ... > md: ... autorun DONE. > NET4: Linux TCP/IP 1.0 for NET4.0 > IP Protocols: ICMP, UDP, TCP, IGMP > IP: routing cache hash table of 512 buckets, 4Kbytes > TCP: Hash tables configured (established 8192 bind 8192) > Linux IP multicast router 0.06 plus PIM-SM > NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. > XFS mounting filesystem ide0(3,2) > XFS: WARNING: recovery required on readonly filesystem. > XFS: write access will be enabled during mount. > Starting XFS recovery on filesystem: ide0(3,2) (dev: 3/2) > Ending XFS recovery on filesystem: ide0(3,2) (dev: 3/2) > VFS: Mounted root (xfs filesystem) readonly. > Freeing unused kernel memory: 224k freed > Adding Swap: 265032k swap-space (priority -1) > Adding Swap: 265032k swap-space (priority -2) > XFS mounting filesystem ide0(3,1) > XFS mounting filesystem ide0(3,10) > XFS mounting filesystem ide0(3,7) > XFS mounting filesystem ide0(3,8) > XFS mounting filesystem ide0(3,3) > XFS mounting filesystem ide0(3,9) > 0x378: FIFO is 16 bytes > 0x378: writeIntrThreshold is 16 > 0x378: readIntrThreshold is 16 > 0x378: PWord is 8 bits > 0x378: Interrupts are ISA-Pulses > 0x378: ECP port cfgA=0x10 cfgB=0x40 > 0x378: ECP settings irq= dma= > parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,COMPAT,ECP] > parport0: irq 7 detected > parport0: cpp_daisy: aa5500ff(38) > parport0: assign_addrs: aa5500ff(38) > parport0: cpp_daisy: aa5500ff(38) > parport0: assign_addrs: aa5500ff(38) > NET4: Linux IPX 0.47 for NET4.0 > IPX Portions Copyright (c) 1995 Caldera, Inc. > IPX Portions Copyright (c) 2000, 2001 Conectiva, Inc. > NET4: AppleTalk 0.18a for Linux NET4.0 > sis900.c: v1.07.11 4/10/2001 > PCI: Found IRQ 10 for device 00:01.1 > eth0: SiS 900 Internal MII PHY transceiver found at address 1. > eth0: Using transceiver found at address 1 as default > eth0: SiS 900 PCI Fast Ethernet at 0xd400, IRQ 10, 00:e0:18:06:72:a6. > eth0: Media Link On 100mbps full-duplex > LVM version 1.0.3(19/02/2002) module loaded > > Thanks in advance for any help... > > Sarwer Zafiruddin > > PS - Please CC any replies to me, I am not in the list... > > -------------------------- > System Administrator > Rune Information Services > http://www.rune.org > e-mail: sarwer@rune.org > -------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 08:59: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 g3PFx4wJ014676 for ; Thu, 25 Apr 2002 08:59:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PFx4ot014675 for linux-xfs-outgoing; Thu, 25 Apr 2002 08:59:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zork.zork.net (mail@zork.zork.net [66.92.188.166]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PFwxwJ014646 for ; Thu, 25 Apr 2002 08:58:59 -0700 Received: from sneakums by zork.zork.net with local (Exim 3.35 #1 (Debian)) id 170lec-0006po-00; Thu, 25 Apr 2002 08:59:30 -0700 To: Linux XFS Subject: Re: XFS recovery on root filesystem References: <3CC81FB9.3803729D@ch.sauter-bc.com> From: Sean Neakums X-Worst-Pick-Up-Line-Ever: "Hey baby, wanna peer with my leafnode instance?" X-Groin-Mounted-Steering-Wheel: "Arrrr... it's driving me nuts!" X-Message-Flag: Message text advisory: AFFIRMATION OF THE CONSEQUENT, DENIAL OF THE ANTECEDENT X-Mailer: Norman Mail-Followup-To: Linux XFS Date: Thu, 25 Apr 2002 16:59:29 +0100 In-Reply-To: <3CC81FB9.3803729D@ch.sauter-bc.com> (Simon Matter's message of "Thu, 25 Apr 2002 17:24:41 +0200") Message-ID: <6uhelzeplq.fsf@zork.zork.net> Lines: 17 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk commence Simon Matter quotation: > I guess you have also updated glibc. IIRC when updating glibc, the > root fs can not be unmounted properly (remount readonly) on shutdown > and therefore you'll notice recovery on the first boot after glibc > upgrade. It has always been like this and was very annoying with > big root fs on ext2 :) I'm sure it's not kernel related. I have never seen this happen after glibc upgrades on Debian systems, and I can't think of a reason why it should happen at all. Steve's suggestion that it's the readonly-remount-path bug sounds a lot more plausible. -- ///////////////// | | The spark of a pin | (require 'gnu) | dropping, falling feather-like. \\\\\\\\\\\\\\\\\ | | There is too much noise. From owner-linux-xfs@oss.sgi.com Thu Apr 25 09:14: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 g3PGEpwJ016090 for ; Thu, 25 Apr 2002 09:14:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PGEptX016089 for linux-xfs-outgoing; Thu, 25 Apr 2002 09:14:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PGEkwJ016060 for ; Thu, 25 Apr 2002 09:14:46 -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 LAA41375; Thu, 25 Apr 2002 11:15:11 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id LAA07348; Thu, 25 Apr 2002 11:15:11 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PGBTt11653; Thu, 25 Apr 2002 11:11:29 -0500 Subject: Re: XFS recovery on root filesystem From: Steve Lord To: Sean Neakums Cc: Linux XFS In-Reply-To: <6uhelzeplq.fsf@zork.zork.net> References: <3CC81FB9.3803729D@ch.sauter-bc.com> <6uhelzeplq.fsf@zork.zork.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 25 Apr 2002 11:11:29 -0500 Message-Id: <1019751089.8353.54.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 10:59, Sean Neakums wrote: > commence Simon Matter quotation: > > > I guess you have also updated glibc. IIRC when updating glibc, the > > root fs can not be unmounted properly (remount readonly) on shutdown > > and therefore you'll notice recovery on the first boot after glibc > > upgrade. It has always been like this and was very annoying with > > big root fs on ext2 :) I'm sure it's not kernel related. > > I have never seen this happen after glibc upgrades on Debian systems, > and I can't think of a reason why it should happen at all. Steve's > suggestion that it's the readonly-remount-path bug sounds a lot more > plausible. It could be a case of dpkg being smarter than rpm here. 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 25 10:05: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 g3PH5wwJ017551 for ; Thu, 25 Apr 2002 10:05:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PH5nrU017549 for linux-xfs-outgoing; Thu, 25 Apr 2002 10:05: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 g3PH5gwJ017522 for ; Thu, 25 Apr 2002 10:05:43 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id 9CE9EC20B; Thu, 25 Apr 2002 19:06: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 TAA23525; Thu, 25 Apr 2002 19:06:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 217C357306; Thu, 25 Apr 2002 19:05: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 DB7A625835; Thu, 25 Apr 2002 19:05:15 +0200 (CEST) Message-ID: <3CC8374B.6E4CB508@ch.sauter-bc.com> Date: Thu, 25 Apr 2002 19:05:15 +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: Steve Lord Cc: Sean Neakums , Linux XFS Subject: Re: XFS recovery on root filesystem References: <3CC81FB9.3803729D@ch.sauter-bc.com> <6uhelzeplq.fsf@zork.zork.net> <1019751089.8353.54.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 Thu, 2002-04-25 at 10:59, Sean Neakums wrote: > > commence Simon Matter quotation: > > > > > I guess you have also updated glibc. IIRC when updating glibc, the > > > root fs can not be unmounted properly (remount readonly) on shutdown > > > and therefore you'll notice recovery on the first boot after glibc > > > upgrade. It has always been like this and was very annoying with > > > big root fs on ext2 :) I'm sure it's not kernel related. > > > > I have never seen this happen after glibc upgrades on Debian systems, > > and I can't think of a reason why it should happen at all. Steve's > > suggestion that it's the readonly-remount-path bug sounds a lot more > > plausible. > > It could be a case of dpkg being smarter than rpm here. Okay, the problem I remembered has affected RedHat until recently. The glibc RPM didn't 'telinit u' after upgrade so 'init' still used the old glibc and / could not be unmounted properly. http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=17345 I think steve was right with the remount readonly bug. You can try 'rpm -V xxx' on the upgraded packages to check integrity. Simon > > 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 25 10:49: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 g3PHnnwJ019437 for ; Thu, 25 Apr 2002 10:49:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PHnnfx019436 for linux-xfs-outgoing; Thu, 25 Apr 2002 10:49:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from sol.rune.org (sol.rune.org [207.201.197.191]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PHncwJ019408 for ; Thu, 25 Apr 2002 10:49:39 -0700 Received: from localhost (sarwer@localhost) by sol.rune.org (8.11.6/8.11.6) with ESMTP id g3PHo8F01428; Thu, 25 Apr 2002 13:50:08 -0400 Date: Thu, 25 Apr 2002 13:50:08 -0400 (EDT) From: Sarwer Zafiruddin To: cc: Sarwer Zafiruddin Subject: Re: XFS recovery on root filesystem In-Reply-To: <1019748122.8309.52.camel@jen.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 I rebooted the system and this time it came up without any recovery required. Come to think of it, the reboot I did after the 1.1 upgrade was the first reboot of the system since I installed it from the installer. :-) Thanks, Sarwer On 25 Apr 2002, Steve Lord wrote: > On Thu, 2002-04-25 at 10:09, Sarwer Zafiruddin wrote: > > Hello, > > > > I was curious about somthing. I have a system running the RedHat > > distribution of XFS 1.1 on a system. When I upgraded the RPM's and the > > redhat kernel (I recompiled the kernel using the SGI XFS kernel SRPM on my > > system) and rebooted the system, I noticed the following messages in my > > dmesg log (I rebooted the system remotely): > > > > XFS mounting filesystem ide0(3,2) > > XFS: WARNING: recovery required on readonly filesystem. > > XFS: write access will be enabled during mount. > > Starting XFS recovery on filesystem: ide0(3,2) (dev: 3/2) > > Ending XFS recovery on filesystem: ide0(3,2) (dev: 3/2) > > VFS: Mounted root (xfs filesystem) readonly. > > > > None of my other filesystems performed a recovery > > > > XFS mounting filesystem ide0(3,1) > > XFS mounting filesystem ide0(3,10) > > XFS mounting filesystem ide0(3,7) > > XFS mounting filesystem ide0(3,8) > > XFS mounting filesystem ide0(3,3) > > XFS mounting filesystem ide0(3,9) > > > > I was runing the SGI XFS 1.0.2 (using installer) Redhat 7.2, and the > > system was up for more than 120 days before the reboot. > > > > QUESTION #1: > > > > What could have prompted the recovery??? Un-clean unmount during the > > reboot??? The fact the upgrade process requires a xfs recovery to be > > performed on the root fs??? Could it be similar to ext2 where if the fs > > has not been check in X amount of days it does a fsck equivlent??? > > Almost certainly the remount readonly in the shutdown path did not work, > there was a bug in this, possibly your old kernel was suffering from it, > or you had a version of the user space init scripts which limited the > remount readonly to ext2 filesystems, although I thought that was 7.1 > and earlier user space. > > Try another reboot with the current kernel and see if it comes up clean. > > > > > QUESTION #2: > > > > Should I bring my system down to maintaince, boot off CD and run > > xfs_repair on my root filesystem to make sure everything is consistant? > > > > Probably not needed. > > Steve > > -- -------------------------- System Administrator Rune Information Services http://www.rune.org e-mail: sarwer@rune.org -------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 11:46:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PIk7wJ020429 for ; Thu, 25 Apr 2002 11:46:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PIk7CF020428 for linux-xfs-outgoing; Thu, 25 Apr 2002 11:46:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.trustium.com (adsl-64-165-6-11.dsl.sndg02.pacbell.net [64.165.6.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PIk3wJ020402 for ; Thu, 25 Apr 2002 11:46:03 -0700 Received: by adsl-64-165-6-11.dsl.sndg02.pacbell.net with Internet Mail Service (5.5.2653.19) id ; Thu, 25 Apr 2002 11:38:43 -0700 Message-ID: <44D5677E9B8478468DE31AE26DF0AFD6077C9D@adsl-64-165-6-11.dsl.sndg02.pacbell.net> From: Adam Milazzo To: "'linux-xfs@oss.sgi.com'" Subject: libxfs documentation Date: Thu, 25 Apr 2002 11:38:42 -0700 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 Is there any documentation available for libxfs besides the source code itself? Surely there has to be some documentation, if only internal, I would think. Does anybody know where and if something like this is available? I haven't been able to find any... Thanks! Adam M. From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:03:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJ3YwJ020716 for ; Thu, 25 Apr 2002 12:03:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJ3YJA020715 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:03:34 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cafes.net (ip3-182.cafes.net [207.65.182.3] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJ3MwJ020688 for ; Thu, 25 Apr 2002 12:03:25 -0700 Received: by mail.cafes.net (Postfix, from userid 500) id 59D268474B; Thu, 25 Apr 2002 13:56:52 -0500 (CDT) Date: Thu, 25 Apr 2002 13:56:52 -0500 From: Mike Eldridge To: linux-xfs@oss.sgi.com Subject: poor io performance with xfs+raid5 Message-ID: <20020425135652.I16048@ornery.cafes.net> 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 xfs/kernel gurus, i am having a problem with a xfs fs on a raid5 array. i experience extremely poor i/o performance. i notice a LOT of processes enter into an uninterruptable sleep state when attempting to read/write to the xfs filesystem. the system is configured as such: 60GB RAID5 (escalade 7850 + 4x20GB IBM deskstar) mounted on /var log=internal,bsize=4096,blocks=1839 agcount=58,agsize=262144 blocks realtime=none i am mostly a newbie when it comes to raid and xfs, so i do not have enough experience to diagnose the problem with 100% certainty. baptism by fire, i should say. i suspect that my problem is this use of raid5 [0], though i want to make sure i cover all bases. i was reading an article on ibm's developerworks website regarding xfs. this article mentions a few points regarding xfs settings that may cause the fs to suffer under heavy io load. the article mentions the following possible bottlenecks: - lack of an appropriately sized metadata log - too many allocation groups could this be the cause of my sleeping i/o-bound processes? i am extremely annoyed that i cannot yet move/grow the log using xfs_growfs, so i cannot say that my log is the problem without trashing the entire filesystem. looking at kupdated's used cpu time on the box, it's eaten close to 2h30m of time in its four days of uptime, a sharp contrast to the used cpu time of the kupdate process on the old box (2h over 94 days). this seems alarming to me, though the old box was running linux-2.2. could linux-2.4+xfs account for such an increase in kupdate's use of the cpu? i appreciate any insight/comments/suggestions/information -mike [0] raid5 - i'm now wanting to trash the raid5 array and instead create several mirrored pairs and then use LVM and stripe over the mirrored pairs. im hoping this will boost performance. -------------------------------------------------------------------------- /~\ the ascii all that is gold does not glitter \ / ribbon campaign not all those who wander are lost X against html -- jrr tolkien / \ email! radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:13:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJDgwJ020997 for ; Thu, 25 Apr 2002 12:13:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJDgWk020996 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:13:42 -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 g3PJDdwJ020969 for ; Thu, 25 Apr 2002 12:13:39 -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 170oem-0005wM-00; Thu, 25 Apr 2002 13:11:52 -0600 Message-ID: <3CC8556C.90809@emergence.com> Date: Thu, 25 Apr 2002 13:13:48 -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: Mike Eldridge CC: linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 References: <20020425135652.I16048@ornery.cafes.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk This was a known problem at release time: http://oss.sgi.com/projects/xfs/1.1_caveats.html # Software RAID5 performance XFS 1.1 supports MD RAID0, RAID1 and RAID5. RAID5 with an internal log may perform slightly worse with XFS than with ext2. This will be addressed in a future release. From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:14:39 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJEdwJ021057 for ; Thu, 25 Apr 2002 12:14:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJEco6021056 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:14:38 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJESwJ021027 for ; Thu, 25 Apr 2002 12:14: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 OAA44990; Thu, 25 Apr 2002 14:14:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id OAA88730; Thu, 25 Apr 2002 14:14:54 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PJBBt13765; Thu, 25 Apr 2002 14:11:11 -0500 Subject: Re: poor io performance with xfs+raid5 From: Steve Lord To: Mike Eldridge Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020425135652.I16048@ornery.cafes.net> References: <20020425135652.I16048@ornery.cafes.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 25 Apr 2002 14:11:10 -0500 Message-Id: <1019761870.8309.86.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The code which fixes this is stuck in my todo pile in an almost working state, but almost working includes a tendency to occasionally do a log write into a random spot and occasionally refuse to mount a filesystem. we really should remove the growfs info about the log, it has never been implemented - we would like to be able to do it too sometimes. A bigger log will not help you the fundamental problem here is unaligned writes to the log, it causes raid5 to flush its cache, this is the performance killer. How recent is your kernel? There are changes recently (last month) which reduce kupdated load in xfs dramatically. Steve On Thu, 2002-04-25 at 13:56, Mike Eldridge wrote: > xfs/kernel gurus, > > i am having a problem with a xfs fs on a raid5 array. i experience > extremely poor i/o performance. i notice a LOT of processes enter into > an uninterruptable sleep state when attempting to read/write to the xfs > filesystem. > > the system is configured as such: > 60GB RAID5 (escalade 7850 + 4x20GB IBM deskstar) mounted on /var > log=internal,bsize=4096,blocks=1839 > agcount=58,agsize=262144 blocks > realtime=none > > i am mostly a newbie when it comes to raid and xfs, so i do not have > enough experience to diagnose the problem with 100% certainty. baptism > by fire, i should say. > > i suspect that my problem is this use of raid5 [0], though i want to > make sure i cover all bases. > > i was reading an article on ibm's developerworks website regarding xfs. > this article mentions a few points regarding xfs settings that may cause > the fs to suffer under heavy io load. > > the article mentions the following possible bottlenecks: > - lack of an appropriately sized metadata log > - too many allocation groups > > could this be the cause of my sleeping i/o-bound processes? > > i am extremely annoyed that i cannot yet move/grow the log using > xfs_growfs, so i cannot say that my log is the problem without trashing > the entire filesystem. > > looking at kupdated's used cpu time on the box, it's eaten close to > 2h30m of time in its four days of uptime, a sharp contrast to the used > cpu time of the kupdate process on the old box (2h over 94 days). this > seems alarming to me, though the old box was running linux-2.2. could > linux-2.4+xfs account for such an increase in kupdate's use of the cpu? > > i appreciate any insight/comments/suggestions/information > > -mike > > [0] raid5 - i'm now wanting to trash the raid5 array and instead create > several mirrored pairs and then use LVM and stripe over the mirrored > pairs. im hoping this will boost performance. > > -------------------------------------------------------------------------- > /~\ the ascii all that is gold does not glitter > \ / ribbon campaign not all those who wander are lost > X against html -- jrr tolkien > / \ email! > > radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd > -------------------------------------------------------------------------- -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:23:15 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJNFwJ021419 for ; Thu, 25 Apr 2002 12:23:15 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJNF8g021418 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:23:15 -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 g3PJN3wJ021391 for ; Thu, 25 Apr 2002 12:23:03 -0700 Received: (qmail 5033 invoked by uid 100); 25 Apr 2002 19:17:22 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Apr 2002 19:17:21 -0000 Date: Thu, 25 Apr 2002 12:17:21 -0700 (PDT) From: Justin Coffey X-X-Sender: justin@paperboy.websocietyinc.com To: Steve Lord cc: Mike Eldridge , Subject: Re: poor io performance with xfs+raid5 In-Reply-To: <1019761870.8309.86.camel@jen.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 Quick related question... (and I haven't been following the group closely recently) does this affect any sort of hardware RAID 5? What about RAID 1+0? > The code which fixes this is stuck in my todo pile in an almost working > state, but almost working includes a tendency to occasionally do a log > write into a random spot and occasionally refuse to mount a filesystem. > > we really should remove the growfs info about the log, it has never > been implemented - we would like to be able to do it too sometimes. > A bigger log will not help you the fundamental problem here is unaligned > writes to the log, it causes raid5 to flush its cache, this is the > performance killer. > > How recent is your kernel? There are changes recently (last month) > which reduce kupdated load in xfs dramatically. > > Steve > > On Thu, 2002-04-25 at 13:56, Mike Eldridge wrote: > > xfs/kernel gurus, > > > > i am having a problem with a xfs fs on a raid5 array. i experience > > extremely poor i/o performance. i notice a LOT of processes enter into > > an uninterruptable sleep state when attempting to read/write to the xfs > > filesystem. > > > > the system is configured as such: > > 60GB RAID5 (escalade 7850 + 4x20GB IBM deskstar) mounted on /var > > log=internal,bsize=4096,blocks=1839 > > agcount=58,agsize=262144 blocks > > realtime=none > > > > i am mostly a newbie when it comes to raid and xfs, so i do not have > > enough experience to diagnose the problem with 100% certainty. baptism > > by fire, i should say. > > > > i suspect that my problem is this use of raid5 [0], though i want to > > make sure i cover all bases. > > > > i was reading an article on ibm's developerworks website regarding xfs. > > this article mentions a few points regarding xfs settings that may cause > > the fs to suffer under heavy io load. > > > > the article mentions the following possible bottlenecks: > > - lack of an appropriately sized metadata log > > - too many allocation groups > > > > could this be the cause of my sleeping i/o-bound processes? > > > > i am extremely annoyed that i cannot yet move/grow the log using > > xfs_growfs, so i cannot say that my log is the problem without trashing > > the entire filesystem. > > > > looking at kupdated's used cpu time on the box, it's eaten close to > > 2h30m of time in its four days of uptime, a sharp contrast to the used > > cpu time of the kupdate process on the old box (2h over 94 days). this > > seems alarming to me, though the old box was running linux-2.2. could > > linux-2.4+xfs account for such an increase in kupdate's use of the cpu? > > > > i appreciate any insight/comments/suggestions/information > > > > -mike > > > > [0] raid5 - i'm now wanting to trash the raid5 array and instead create > > several mirrored pairs and then use LVM and stripe over the mirrored > > pairs. im hoping this will boost performance. > > > > -------------------------------------------------------------------------- > > /~\ the ascii all that is gold does not glitter > > \ / ribbon campaign not all those who wander are lost > > X against html -- jrr tolkien > > / \ email! > > > > radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd > > -------------------------------------------------------------------------- > ------------------------------------------------------------------------ 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 Thu Apr 25 12:25:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJPGwJ021511 for ; Thu, 25 Apr 2002 12:25:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJPG5u021510 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:25:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJPBwJ021480 for ; Thu, 25 Apr 2002 12:25: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 OAA44645; Thu, 25 Apr 2002 14:25: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 OAA68376; Thu, 25 Apr 2002 14:25:17 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PJLYS13784; Thu, 25 Apr 2002 14:21:34 -0500 Subject: Re: poor io performance with xfs+raid5 From: Steve Lord To: Justin Coffey Cc: Mike Eldridge , 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: 25 Apr 2002 14:21:34 -0500 Message-Id: <1019762494.8353.88.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 14:17, Justin Coffey wrote: > > Quick related question... (and I haven't been following the group closely > recently) does this affect any sort of hardware RAID 5? What about RAID > 1+0? The alignment issue is mostly software raid5 specific. The ability to better align the writes will help on other configs to a lesser extent. 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 25 12:28:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJSXwJ021756 for ; Thu, 25 Apr 2002 12:28:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJSXOk021755 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:28:33 -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 g3PJSUwJ021727 for ; Thu, 25 Apr 2002 12:28:30 -0700 Received: (qmail 23076 invoked by uid 100); 25 Apr 2002 19:22:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Apr 2002 19:22:49 -0000 Date: Thu, 25 Apr 2002 12:22:49 -0700 (PDT) From: Justin Coffey X-X-Sender: justin@paperboy.websocietyinc.com To: Steve Lord cc: Mike Eldridge , Subject: Re: poor io performance with xfs+raid5 In-Reply-To: <1019762494.8353.88.camel@jen.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 > The alignment issue is mostly software raid5 specific. The ability to > better align the writes will help on other configs to a lesser extent. Thanks. We're in the design phase of a new product and it's likely to use some sort of largish NAS box. Most likely raid 5'ed. Initially (due to cost) we'll probably do software raid but we'll want to move to hardware level at some point. I guess that means ReiserFS for us for now? ------------------------------------------------------------------------ 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 Thu Apr 25 12:31: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 g3PJVdwJ021945 for ; Thu, 25 Apr 2002 12:31:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJVd7S021944 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:31:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJVYwJ021917 for ; Thu, 25 Apr 2002 12:31: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 OAA39789; Thu, 25 Apr 2002 14: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 OAA09498; Thu, 25 Apr 2002 14:32:00 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PJSGH13820; Thu, 25 Apr 2002 14:28:16 -0500 Subject: Re: poor io performance with xfs+raid5 From: Steve Lord To: Justin Coffey Cc: Mike Eldridge , 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: 25 Apr 2002 14:28:16 -0500 Message-Id: <1019762896.8353.92.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 14:22, Justin Coffey wrote: > > > The alignment issue is mostly software raid5 specific. The ability to > > better align the writes will help on other configs to a lesser extent. > > Thanks. We're in the design phase of a new product and it's likely to use > some sort of largish NAS box. Most likely raid 5'ed. Initially (due to > cost) we'll probably do software raid but we'll want to move to hardware > level at some point. I guess that means ReiserFS for us for now? Depends when you need the performance speed up... I can send you code now, it works most of the time, I just have a couple of anomalies to chase. Steve > > ------------------------------------------------------------------------ > Justin Coffey 858.535.9332 x 2025 > Technical Advisor justin@homes.com > Homes.com, Inc. http://homes.com > ------------------------------------------------------------------------ -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:33: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 g3PJXvwJ022077 for ; Thu, 25 Apr 2002 12:33:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJXvG0022076 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:33:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cafes.net (ip3-182.cafes.net [207.65.182.3] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJXowJ022022 for ; Thu, 25 Apr 2002 12:33:51 -0700 Received: by mail.cafes.net (Postfix, from userid 500) id A4C5F84107; Thu, 25 Apr 2002 14:29:59 -0500 (CDT) Date: Thu, 25 Apr 2002 14:29:59 -0500 From: Mike Eldridge To: Michael Best Cc: linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 Message-ID: <20020425142959.L16048@ornery.cafes.net> References: <20020425135652.I16048@ornery.cafes.net> <3CC8556C.90809@emergence.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC8556C.90809@emergence.com>; from mbest@emergence.com on Thu, Apr 25, 2002 at 01:13:48PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 01:13:48PM -0600, Michael Best wrote: > This was a known problem at release time: > > http://oss.sgi.com/projects/xfs/1.1_caveats.html > > # Software RAID5 performance > > XFS 1.1 supports MD RAID0, RAID1 and RAID5. RAID5 with an internal log > may perform slightly worse with XFS than with ext2. This will be > addressed in a future release. argh! i found this blurb on the 1.0.1 caveats page and looked for a link to the 1.1 caveats page to see if it still existed in the 1.1 release but could not find a link. i even guessed at some possible urls to no avail. thanks for the info. i have attempted to use xfs_growfs to change the log to an external log but cannot. any idea when this functionality will be available? not that it makes any difference since i can't wait any longer on this issue. -mike -------------------------------------------------------------------------- /~\ the ascii all that is gold does not glitter \ / ribbon campaign not all those who wander are lost X against html -- jrr tolkien / \ email! radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:35: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 g3PJZMwJ022230 for ; Thu, 25 Apr 2002 12:35:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJZMAS022229 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:35:22 -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 g3PJZIwJ022202 for ; Thu, 25 Apr 2002 12:35:18 -0700 Received: (qmail 14520 invoked by uid 100); 25 Apr 2002 19:29:37 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 25 Apr 2002 19:29:37 -0000 Date: Thu, 25 Apr 2002 12:29:36 -0700 (PDT) From: Justin Coffey X-X-Sender: justin@paperboy.websocietyinc.com To: Steve Lord cc: Mike Eldridge , Subject: Re: poor io performance with xfs+raid5 In-Reply-To: <1019762896.8353.92.camel@jen.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 Okay. We're about 3 weeks away from moving off of devel hardware anyway. > Depends when you need the performance speed up... I can send you code > now, it works most of the time, I just have a couple of anomalies to > chase. > > Steve > > > > > ------------------------------------------------------------------------ > > Justin Coffey 858.535.9332 x 2025 > > Technical Advisor justin@homes.com > > Homes.com, Inc. http://homes.com > > ------------------------------------------------------------------------ > ------------------------------------------------------------------------ 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 Thu Apr 25 12:35: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 g3PJZnwJ022324 for ; Thu, 25 Apr 2002 12:35:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJZn73022323 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:35:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cafes.net (ip3-182.cafes.net [207.65.182.3] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJZfwJ022295 for ; Thu, 25 Apr 2002 12:35:42 -0700 Received: by mail.cafes.net (Postfix, from userid 500) id CFFA284C4A; Thu, 25 Apr 2002 14:34:25 -0500 (CDT) Date: Thu, 25 Apr 2002 14:34:25 -0500 From: Mike Eldridge To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 Message-ID: <20020425143425.M16048@ornery.cafes.net> References: <20020425135652.I16048@ornery.cafes.net> <1019761870.8309.86.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1019761870.8309.86.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 25, 2002 at 02:11:10PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 02:11:10PM -0500, Steve Lord wrote: > The code which fixes this is stuck in my todo pile in an almost working > state, but almost working includes a tendency to occasionally do a log > write into a random spot and occasionally refuse to mount a filesystem. ack =( > we really should remove the growfs info about the log, it has never > been implemented - we would like to be able to do it too sometimes. > A bigger log will not help you the fundamental problem here is unaligned > writes to the log, it causes raid5 to flush its cache, this is the > performance killer. aye, i spent quite a while trying to figure out why i couldn't move the log. there are several erroneous references to a non-existant -x switch. i would definitely recommend removing the growfs info about the log. > How recent is your kernel? There are changes recently (last month) > which reduce kupdated load in xfs dramatically. vanilla linux-2.4.18 + xfs-1.1 i will gladly try one of the linux-2.4.19pre's if it will help. -mike -------------------------------------------------------------------------- /~\ the ascii all that is gold does not glitter \ / ribbon campaign not all those who wander are lost X against html -- jrr tolkien / \ email! radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:39: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 g3PJdjwJ022724 for ; Thu, 25 Apr 2002 12:39:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJdjo5022723 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:39:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cafes.net (ip3-182.cafes.net [207.65.182.3] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJddwJ022696 for ; Thu, 25 Apr 2002 12:39:39 -0700 Received: by mail.cafes.net (Postfix, from userid 500) id 4E6F384107; Thu, 25 Apr 2002 14:40:25 -0500 (CDT) Date: Thu, 25 Apr 2002 14:40:25 -0500 From: Mike Eldridge To: Simon Matter Cc: Justin Coffey , Steve Lord , linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 Message-ID: <20020425144025.N16048@ornery.cafes.net> References: <3CC85999.501431E5@ch.sauter-bc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC85999.501431E5@ch.sauter-bc.com>; from simon.matter@ch.sauter-bc.com on Thu, Apr 25, 2002 at 09:31:37PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 09:31:37PM +0200, Simon Matter wrote: > Justin Coffey schrieb: > > > > Quick related question... (and I haven't been following the group closely > > recently) does this affect any sort of hardware RAID 5? What about RAID > > 1+0? > > Hi, > > Hardware RAID is not affected at all. All levels of Software RAID beside > RAID5 are okay. The only problem is with Software RAID5 and internal > log. Under some circumstances, this config can slow down performance > _dramatically_. it should be noted that i am using hardware raid5: > > > > the system is configured as such: > > > > 60GB RAID5 (escalade 7850 + 4x20GB IBM deskstar) mounted on /var > > > > log=internal,bsize=4096,blocks=1839 > > > > agcount=58,agsize=262144 blocks > > > > realtime=none via a 3ware escalade 7850 ata-raid card. -mike -------------------------------------------------------------------------- /~\ the ascii all that is gold does not glitter \ / ribbon campaign not all those who wander are lost X against html -- jrr tolkien / \ email! radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:49: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 g3PJnTwJ022965 for ; Thu, 25 Apr 2002 12:49:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJnTJA022964 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:49:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from epimetheus.hosting4u.net (epimetheus.hosting4u.net [209.15.2.70]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJnNwJ022938 for ; Thu, 25 Apr 2002 12:49:24 -0700 Received: (qmail 21881 invoked from network); 25 Apr 2002 19:49:54 -0000 Received: from capricornus.hosting4u.net (HELO stewartsigns.com) (209.15.2.36) by mail-gate.hosting4u.net with SMTP; 25 Apr 2002 19:49:54 -0000 Received: from mikerock ([192.216.210.79]) by stewartsigns.com ; Thu, 25 Apr 2002 14:49:51 -0500 From: "Mikes work account" To: Subject: help Date: Thu, 25 Apr 2002 15:52:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Rcpt-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk April 25, 2002 Last weekend, I installed the 2.4.9-12SGI_XFS_1.0.2smp rpm on my Linux box which was running RedHat 7.1 2.4.9-12smp. I had no difficultywith the install except that the mkfs.xfs file was missing and I wondered why. Si I copied it from another box I had running an XFS filesystem which had loaded and configured without problems. I was able to then install and XFS filesystem and was able to automount the filesystem without errors. The problem I have is that my system performance has degraded since the XFS install. From all that I have read, my performance should have improved. We run about 80 to 100 logins over a thin client to this server and although it has been busy we have never experienced this level of degredation in performance. I did not install any of the patches and am not sure I know which I should install in the first place. Can you offer any assistance into why my system should be slower than it was. I have plenty of space and ram and am running on an IBM Netfinity 5000 with dual 450 processors. My supervisor wants me to go back to the ext2 FS and I am reluctant to do so because I feel I should be getting better performance with XFS if I can just get it tuned. Thank you in advance, You prompt attention will be appreciated. Michael C. Rock From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:49:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJnlwJ023021 for ; Thu, 25 Apr 2002 12:49:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJnlr2023020 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:49:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mx11.cluster1.charter.net (dc-mx11.cluster0.hsacorp.net [209.225.8.21]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJnfwJ022971 for ; Thu, 25 Apr 2002 12:49:41 -0700 Received: from [24.216.239.187] (HELO queso) by mx11.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 4504616; Thu, 25 Apr 2002 15:49:05 -0400 Date: Thu, 25 Apr 2002 14:50:04 -0500 (CDT) From: Gerald Carter X-X-Sender: jerry@queso.plainjoe.org To: Nathan Scott cc: Chris Tooley , , Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) In-Reply-To: <20020424084049.M63455@wobbly.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 Wed, 24 Apr 2002, Nathan Scott wrote: > On Tue, Apr 23, 2002 at 12:02:44PM -0500, Chris Tooley wrote: > > I did make the switch in configure from -lacl -lattr and faired no > > better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp > > kernel. > > > > checking if large file support can be enabled... yes > > checking whether to support ACLs... checking for acl_get_file in > > -lattr... no > > checking for ACL support... no > > Your configure changes are incorrect - they're looking in the wrong > library for acl_get_file (which is in libacl, not libattr), as I > said earlier you need to link with both libraries. > > It has been pointed out that we can do a better job when building > libacl so that it knows it depends on libattr (in fact this was > done at one point, but was accidentally dropped from the Makefile). > If you build and install the acl code from XFS CVS (have a look > though cmd/acl/doc/INSTALL), you should find that Samba gets > built correctly with no changes at all now. Can someone send me a quick patch for configure.in to deal with this? It would be much appreciated. I don't have an XFS box to test on, but would like to see this fixed for 2.2.4. Thanks. cheers, jerry --------------------------------------------------------------------- Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org -- http://www.plainjoe.org "Sam's Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca-- From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:51:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJp8wJ023104 for ; Thu, 25 Apr 2002 12:51:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJp8Jd023103 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:51:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itspec.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJp0wJ023063 for ; Thu, 25 Apr 2002 12:51:00 -0700 Received: (from ctooley@localhost) by itspec.amoa.org (8.11.6/8.11.6) id g3PJpfq02133; Thu, 25 Apr 2002 14:51:41 -0500 X-Authentication-Warning: itspec.amoa.org: ctooley set sender to ctooley@amoa.org using -f Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) From: Chris Tooley To: Gerald Carter Cc: Nathan Scott , samba@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 25 Apr 2002 14:51:40 -0500 Message-Id: <1019764300.1957.0.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Actually this is fixed in the acl rpms and new makefile. No change to Samba was required. Chris Tooely On Thu, 2002-04-25 at 14:50, Gerald Carter wrote: > On Wed, 24 Apr 2002, Nathan Scott wrote: > > > On Tue, Apr 23, 2002 at 12:02:44PM -0500, Chris Tooley wrote: > > > I did make the switch in configure from -lacl -lattr and faired no > > > better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp > > > kernel. > > > > > > checking if large file support can be enabled... yes > > > checking whether to support ACLs... checking for acl_get_file in > > > -lattr... no > > > checking for ACL support... no > > > > Your configure changes are incorrect - they're looking in the wrong > > library for acl_get_file (which is in libacl, not libattr), as I > > said earlier you need to link with both libraries. > > > > It has been pointed out that we can do a better job when building > > libacl so that it knows it depends on libattr (in fact this was > > done at one point, but was accidentally dropped from the Makefile). > > If you build and install the acl code from XFS CVS (have a look > > though cmd/acl/doc/INSTALL), you should find that Samba gets > > built correctly with no changes at all now. > > Can someone send me a quick patch for configure.in to deal with > this? It would be much appreciated. I don't have an XFS box > to test on, but would like to see this fixed for 2.2.4. Thanks. > > > > > > cheers, jerry > --------------------------------------------------------------------- > Hewlett-Packard http://www.hp.com > SAMBA Team http://www.samba.org > -- http://www.plainjoe.org > "Sam's Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 > --"I never saved anything for the swim back." Ethan Hawk in Gattaca-- > -- Chris Tooley IT Coordinator Austin Museum of Art 823 Congress Ave. Austin, TX 78701 office - (512)495-9224 x289 pager - (512)613-2603 ctooley@amoa.org From owner-linux-xfs@oss.sgi.com Thu Apr 25 12:54:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJsJwJ023457 for ; Thu, 25 Apr 2002 12:54:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJsJUq023456 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:54:19 -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 g3PJruwJ023392 for ; Thu, 25 Apr 2002 12:53:56 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id DB042C20D; Thu, 25 Apr 2002 21:32: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 VAA03504; Thu, 25 Apr 2002 21:32:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 93FC757306; Thu, 25 Apr 2002 21:31:39 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id F3A1425835; Thu, 25 Apr 2002 21:31:37 +0200 (CEST) Message-ID: <3CC85999.501431E5@ch.sauter-bc.com> Date: Thu, 25 Apr 2002 21:31:37 +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: Justin Coffey Cc: Steve Lord , Mike Eldridge , linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Justin Coffey schrieb: > > Quick related question... (and I haven't been following the group closely > recently) does this affect any sort of hardware RAID 5? What about RAID > 1+0? Hi, Hardware RAID is not affected at all. All levels of Software RAID beside RAID5 are okay. The only problem is with Software RAID5 and internal log. Under some circumstances, this config can slow down performance _dramatically_. Simon > > > The code which fixes this is stuck in my todo pile in an almost working > > state, but almost working includes a tendency to occasionally do a log > > write into a random spot and occasionally refuse to mount a filesystem. > > > > we really should remove the growfs info about the log, it has never > > been implemented - we would like to be able to do it too sometimes. > > A bigger log will not help you the fundamental problem here is unaligned > > writes to the log, it causes raid5 to flush its cache, this is the > > performance killer. > > > > How recent is your kernel? There are changes recently (last month) > > which reduce kupdated load in xfs dramatically. > > > > Steve > > > > On Thu, 2002-04-25 at 13:56, Mike Eldridge wrote: > > > xfs/kernel gurus, > > > > > > i am having a problem with a xfs fs on a raid5 array. i experience > > > extremely poor i/o performance. i notice a LOT of processes enter into > > > an uninterruptable sleep state when attempting to read/write to the xfs > > > filesystem. > > > > > > the system is configured as such: > > > 60GB RAID5 (escalade 7850 + 4x20GB IBM deskstar) mounted on /var > > > log=internal,bsize=4096,blocks=1839 > > > agcount=58,agsize=262144 blocks > > > realtime=none > > > > > > i am mostly a newbie when it comes to raid and xfs, so i do not have > > > enough experience to diagnose the problem with 100% certainty. baptism > > > by fire, i should say. > > > > > > i suspect that my problem is this use of raid5 [0], though i want to > > > make sure i cover all bases. > > > > > > i was reading an article on ibm's developerworks website regarding xfs. > > > this article mentions a few points regarding xfs settings that may cause > > > the fs to suffer under heavy io load. > > > > > > the article mentions the following possible bottlenecks: > > > - lack of an appropriately sized metadata log > > > - too many allocation groups > > > > > > could this be the cause of my sleeping i/o-bound processes? > > > > > > i am extremely annoyed that i cannot yet move/grow the log using > > > xfs_growfs, so i cannot say that my log is the problem without trashing > > > the entire filesystem. > > > > > > looking at kupdated's used cpu time on the box, it's eaten close to > > > 2h30m of time in its four days of uptime, a sharp contrast to the used > > > cpu time of the kupdate process on the old box (2h over 94 days). this > > > seems alarming to me, though the old box was running linux-2.2. could > > > linux-2.4+xfs account for such an increase in kupdate's use of the cpu? > > > > > > i appreciate any insight/comments/suggestions/information > > > > > > -mike > > > > > > [0] raid5 - i'm now wanting to trash the raid5 array and instead create > > > several mirrored pairs and then use LVM and stripe over the mirrored > > > pairs. im hoping this will boost performance. > > > > > > -------------------------------------------------------------------------- > > > /~\ the ascii all that is gold does not glitter > > > \ / ribbon campaign not all those who wander are lost > > > X against html -- jrr tolkien > > > / \ email! > > > > > > radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd > > > -------------------------------------------------------------------------- > > > > ------------------------------------------------------------------------ > 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 Thu Apr 25 12:57:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PJv8wJ023632 for ; Thu, 25 Apr 2002 12:57:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PJv8x9023631 for linux-xfs-outgoing; Thu, 25 Apr 2002 12:57:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itspec.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PJuvwJ023591 for ; Thu, 25 Apr 2002 12:56:57 -0700 Received: (from ctooley@localhost) by itspec.amoa.org (8.11.6/8.11.6) id g3PJuii02155; Thu, 25 Apr 2002 14:56:44 -0500 X-Authentication-Warning: itspec.amoa.org: ctooley set sender to ctooley@amoa.org using -f Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) From: Chris Tooley To: Chris Tooley Cc: Gerald Carter , Nathan Scott , samba@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: <1019764300.1957.0.camel@itspec.amoa.org> References: <1019764300.1957.0.camel@itspec.amoa.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 25 Apr 2002 14:56:44 -0500 Message-Id: <1019764604.1958.3.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 14:51, Chris Tooley wrote: > Actually this is fixed in the acl rpms and new makefile. No change to > Samba was required. > > Chris Tooely Of course what do I know, I can't even spell my own name. Chris Tooley > > On Thu, 2002-04-25 at 14:50, Gerald Carter wrote: > > On Wed, 24 Apr 2002, Nathan Scott wrote: > > > > > On Tue, Apr 23, 2002 at 12:02:44PM -0500, Chris Tooley wrote: > > > > I did make the switch in configure from -lacl -lattr and faired no > > > > better results. I'm using XFS version 1.1 from the 2.4.9-31SGI_XFSsmp > > > > kernel. > > > > > > > > checking if large file support can be enabled... yes > > > > checking whether to support ACLs... checking for acl_get_file in > > > > -lattr... no > > > > checking for ACL support... no > > > > > > Your configure changes are incorrect - they're looking in the wrong > > > library for acl_get_file (which is in libacl, not libattr), as I > > > said earlier you need to link with both libraries. > > > > > > It has been pointed out that we can do a better job when building > > > libacl so that it knows it depends on libattr (in fact this was > > > done at one point, but was accidentally dropped from the Makefile). > > > If you build and install the acl code from XFS CVS (have a look > > > though cmd/acl/doc/INSTALL), you should find that Samba gets > > > built correctly with no changes at all now. > > > > Can someone send me a quick patch for configure.in to deal with > > this? It would be much appreciated. I don't have an XFS box > > to test on, but would like to see this fixed for 2.2.4. Thanks. > > > > > > > > > > > > cheers, jerry > > --------------------------------------------------------------------- > > Hewlett-Packard http://www.hp.com > > SAMBA Team http://www.samba.org > > -- http://www.plainjoe.org > > "Sam's Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 > > --"I never saved anything for the swim back." Ethan Hawk in Gattaca-- > > > -- > Chris Tooley > IT Coordinator > Austin Museum of Art > 823 Congress Ave. > Austin, TX 78701 > office - (512)495-9224 x289 > pager - (512)613-2603 > ctooley@amoa.org > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba -- Chris Tooley IT Coordinator Austin Museum of Art 823 Congress Ave. Austin, TX 78701 office - (512)495-9224 x289 pager - (512)613-2603 ctooley@amoa.org From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:06:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PK6JwJ023944 for ; Thu, 25 Apr 2002 13:06:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PK6JGx023943 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:06:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dc-mx08.cluster1.charter.net (dc-mx08.cluster0.hsacorp.net [209.225.8.18]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PK6EwJ023915 for ; Thu, 25 Apr 2002 13:06:14 -0700 Received: from [24.216.239.187] (HELO queso) by dc-mx08.cluster1.charter.net (CommuniGate Pro SMTP 3.5.9) with ESMTP id 39823425; Thu, 25 Apr 2002 16:11:30 -0400 Date: Thu, 25 Apr 2002 15:06:37 -0500 (CDT) From: Gerald Carter X-X-Sender: jerry@queso.plainjoe.org To: Chris Tooley cc: Nathan Scott , , Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) In-Reply-To: <1019764300.1957.0.camel@itspec.amoa.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 25 Apr 2002, Chris Tooley wrote: > Actually this is fixed in the acl rpms and new makefile. No change to > Samba was required. > > Chris Tooely Cool. :-) Thanks for the update. I'll mark that one off my list :-) cheers, jerry --------------------------------------------------------------------- Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org -- http://www.plainjoe.org "Sam's Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca-- From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:06:08 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PK68wJ023911 for ; Thu, 25 Apr 2002 13:06:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PK68tY023910 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:06:08 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PK62wJ023881 for ; Thu, 25 Apr 2002 13:06:03 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id PAA45832; Thu, 25 Apr 2002 15:06:29 -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 PAA99227; Thu, 25 Apr 2002 15:06:28 -0500 (CDT) Subject: Re: help From: Eric Sandeen To: Mikes work account 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: 25 Apr 2002 15:06:28 -0500 Message-Id: <1019765188.30094.50.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 14:52, Mikes work account wrote: > April 25, 2002 > > Last weekend, I installed the 2.4.9-12SGI_XFS_1.0.2smp rpm on my Linux box > which was running RedHat 7.1 2.4.9-12smp. > I had no difficultywith the install except that the mkfs.xfs file was > missing and I wondered why. Si I copied it from another box I had running > an XFS filesystem which had loaded and configured without problems. Well, the mkfs.xfs userspace application is in the xfsprogs rpm, not the kernel rpm. > The problem I have is that my system performance has degraded since the XFS > install. From all that I have read, my performance should have improved. You haven't really explained what you're doing with the box, or how much you have migrated to XFS. Are all active filesystems now XFS? Are they on RAID? What kind? > I did not install any of the patches and am not sure I know which I should > install in the first place. I wouldn't go for the patches, most of them are snapshots. I would suggest upgrading to the 1.1 RPMs recently released, though. Without knowing the details of your drive setup, mounting with "logbufs=8" may help. -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 25 13:18: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 g3PKIVwJ024420 for ; Thu, 25 Apr 2002 13:18:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKIV6e024419 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:18:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from hermes.cs.brandeis.edu (IDENT:root@hermes.cs.brandeis.edu [129.64.2.5]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PKIRwJ024392 for ; Thu, 25 Apr 2002 13:18:28 -0700 Received: from [129.64.46.83] (dhcp-129.64.46.83.cs-i.brandeis.edu [129.64.46.83]) by hermes.cs.brandeis.edu (8.11.6/8.9.3) with ESMTP id g3PKIvd24556 for ; Thu, 25 Apr 2002 16:18:57 -0400 Mime-Version: 1.0 X-Sender: aaronm@mail.cs.brandeis.edu (Unverified) Message-Id: Date: Thu, 25 Apr 2002 16:19:41 -0400 To: linux-xfs@oss.sgi.com From: Aaron Macks Subject: Kernel SRPMS from 1.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Has anyone used the SRPM from the 1.1 distribution to build a kernel? I have a box that I can't take offline long enough for a full RH7.1->RH7.2 upgrade, and so the SRPM seems to be the best option. I just want to check if anyone has experience with it before I commit to scheduled downtime Aaron -- _______________________________________________________ Aaron Macks(aaronm@cs.brandeis.edu) My sheep has seven gall bladders, that makes me the King of the Universe! From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:18: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 g3PKInwJ024456 for ; Thu, 25 Apr 2002 13:18:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKIn3w024455 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:18: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 g3PKIfwJ024424 for ; Thu, 25 Apr 2002 13:18:41 -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 PAA43294; Thu, 25 Apr 2002 15:19:06 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA55203; Thu, 25 Apr 2002 15:19:06 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PKJ5O14302; Thu, 25 Apr 2002 15:19:05 -0500 Subject: Re: poor io performance with xfs+raid5 From: Steve Lord To: Mike Eldridge Cc: Simon Matter , Justin Coffey , linux-xfs@oss.sgi.com In-Reply-To: <20020425144025.N16048@ornery.cafes.net> References: <3CC85999.501431E5@ch.sauter-bc.com> <20020425144025.N16048@ornery.cafes.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 25 Apr 2002 15:19:05 -0500 Message-Id: <1019765945.12905.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 14:40, Mike Eldridge wrote: > On Thu, Apr 25, 2002 at 09:31:37PM +0200, Simon Matter wrote: > > > > Hi, > > > > Hardware RAID is not affected at all. All levels of Software RAID beside > > RAID5 are okay. The only problem is with Software RAID5 and internal > > log. Under some circumstances, this config can slow down performance > > _dramatically_. > > it should be noted that i am using hardware raid5: > > > > > > the system is configured as such: > > > > > 60GB RAID5 (escalade 7850 + 4x20GB IBM deskstar) mounted on /var > > > > > log=internal,bsize=4096,blocks=1839 > > > > > agcount=58,agsize=262144 blocks > > > > > realtime=none > > via a 3ware escalade 7850 ata-raid card. > Well, Duh! I should have seen that first time around, I get into the habit of reading my email too fast! We may be able to fix some things, if we can remake the filesystem. First you need to know the stripe unit of your raid - we can feed this into XFS to make it do stripe aligned allocations. This has to be done by hand on linux. Take a look at the mkfs.xfs man page and the section on sunit and swidth options. Probably bump your log size up from the default somewhat, not sure how it ended up as 1839 that is scary. You still have not said which kernel version you are running beyond 2.4, unless I speed read over that too. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:22:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PKMNwJ024747 for ; Thu, 25 Apr 2002 13:22:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKMNL1024746 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:22:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itspec.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PKMGwJ024720 for ; Thu, 25 Apr 2002 13:22:17 -0700 Received: (from ctooley@localhost) by itspec.amoa.org (8.11.6/8.11.6) id g3PKMxR02206; Thu, 25 Apr 2002 15:22:59 -0500 X-Authentication-Warning: itspec.amoa.org: ctooley set sender to ctooley@amoa.org using -f Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) From: Chris Tooley To: Gerald Carter Cc: Nathan Scott , samba@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 25 Apr 2002 15:22:58 -0500 Message-Id: <1019766178.1958.12.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 15:06, Gerald Carter wrote: > On 25 Apr 2002, Chris Tooley wrote: > > > Actually this is fixed in the acl rpms and new makefile. No change to > > Samba was required. > > > > Chris Tooely > > Cool. :-) Thanks for the update. I'll mark that one off my list :-) > That's not to say that the fix is in an official release, I just know that the CVS version that I used worked perfectly. Mr Scott: You think you guys could roll out new packages with the Makefile changes? Chris Tooley > > > > > cheers, jerry > --------------------------------------------------------------------- > Hewlett-Packard http://www.hp.com > SAMBA Team http://www.samba.org > -- http://www.plainjoe.org > "Sam's Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 > --"I never saved anything for the swim back." Ethan Hawk in Gattaca-- > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba -- Chris Tooley IT Coordinator Austin Museum of Art 823 Congress Ave. Austin, TX 78701 office - (512)495-9224 x289 pager - (512)613-2603 ctooley@amoa.org From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:28:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PKSZwJ024932 for ; Thu, 25 Apr 2002 13:28:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKSZtl024931 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:28: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 g3PKSTwJ024904 for ; Thu, 25 Apr 2002 13:28:29 -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 PAA44247; Thu, 25 Apr 2002 15:28:54 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id PAA95408; Thu, 25 Apr 2002 15:28:54 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PKSrM14346; Thu, 25 Apr 2002 15:28:53 -0500 Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) From: Steve Lord To: Chris Tooley Cc: Gerald Carter , Nathan Scott , samba@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: <1019766178.1958.12.camel@itspec.amoa.org> References: <1019766178.1958.12.camel@itspec.amoa.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 25 Apr 2002 15:28:53 -0500 Message-Id: <1019766533.8353.109.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 15:22, Chris Tooley wrote: > > On Thu, 2002-04-25 at 15:06, Gerald Carter wrote: > > On 25 Apr 2002, Chris Tooley wrote: > > > > > Actually this is fixed in the acl rpms and new makefile. No change to > > > Samba was required. > > > > > > Chris Tooely > > > > Cool. :-) Thanks for the update. I'll mark that one off my list :-) > > > That's not to say that the fix is in an official release, I just know > that the CVS version that I used worked perfectly. > > Mr Scott: You think you guys could roll out new packages with the > Makefile changes? > > Chris Tooley > Unless I mis read things: ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/i386/ is what you need. Those look current to me. 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 25 13:41:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PKffwJ025257 for ; Thu, 25 Apr 2002 13:41:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKffpV025256 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:41:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cafes.net (ip3-182.cafes.net [207.65.182.3] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PKfYwJ025230 for ; Thu, 25 Apr 2002 13:41:34 -0700 Received: by mail.cafes.net (Postfix, from userid 500) id 8BA64844E3; Thu, 25 Apr 2002 15:41:35 -0500 (CDT) Date: Thu, 25 Apr 2002 15:41:35 -0500 From: Mike Eldridge To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 Message-ID: <20020425154135.B14120@ornery.cafes.net> References: <3CC85999.501431E5@ch.sauter-bc.com> <20020425144025.N16048@ornery.cafes.net> <1019765945.12905.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1019765945.12905.102.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 25, 2002 at 03:19:05PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 03:19:05PM -0500, Steve Lord wrote: > Well, Duh! I should have seen that first time around, I get into the > habit of reading my email too fast! > > We may be able to fix some things, if we can remake the filesystem. > First you need to know the stripe unit of your raid - we can feed > this into XFS to make it do stripe aligned allocations. This has > to be done by hand on linux. Take a look at the mkfs.xfs man page > and the section on sunit and swidth options. Probably bump your log size > up from the default somewhat, not sure how it ended up as 1839 > that is scary. RAID5 on this card offers only a 64K stripe size. however, i will be recreating the array as RAID1 or RAID10, which offers stripe sizes from 64K to 1MB. i'm not sure which is the best way to go. i think that the best thing to do, considering additonal space requirements might be neccessary, is to go with multiple RAID1 arrays and let LVM do the striping. any caveats here? this particular box is a mail server and it handles a lot of i/o with pretty small files (< 64K). i want to optimize for performance. unfortunately, this is also my *first* foray into xfs/lvm/raid, so i want to make sure i have as much information as possible before i carve it all in stone. i need to go read some more about LVM... as for the log, yeah, just over 7MB, i have no idea either. info i have read suggests a 32MB log, but i'd like to use something bigger, perhaps 128MB. any caveats to using a log of this size? > You still have not said which kernel version you are running beyond 2.4, > unless I speed read over that too. i did in a previous email. :) it's vanilla 2.4.18 with the xfs-1.1 release patches applied. -mike -------------------------------------------------------------------------- /~\ the ascii all that is gold does not glitter \ / ribbon campaign not all those who wander are lost X against html -- jrr tolkien / \ email! radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:44:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PKiDwJ025461 for ; Thu, 25 Apr 2002 13:44:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKiDCj025460 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:44:13 -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 g3PKhwwJ025383 for ; Thu, 25 Apr 2002 13:43:59 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 2A33AC213; Thu, 25 Apr 2002 22:25: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 WAA07200; Thu, 25 Apr 2002 22:25:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3371257306; Thu, 25 Apr 2002 22:24:35 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id E8E2325835; Thu, 25 Apr 2002 22:24:33 +0200 (CEST) Message-ID: <3CC86601.EA449A5D@ch.sauter-bc.com> Date: Thu, 25 Apr 2002 22:24:33 +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: Aaron Macks Cc: linux-xfs@oss.sgi.com Subject: Re: Kernel SRPMS from 1.1 References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Aaron Macks schrieb: > > Has anyone used the SRPM from the 1.1 distribution to build a kernel? > I have a box that I can't take offline long enough for a full > RH7.1->RH7.2 upgrade, and so the SRPM seems to be the best option. I You can just install the binary kernel RPM since they are both exactly the same now for 7.1 and 7.2. Simon > just want to check if anyone has experience with it before I commit > to scheduled downtime > Aaron > -- > _______________________________________________________ > Aaron Macks(aaronm@cs.brandeis.edu) > My sheep has seven gall bladders, that makes me the King of the Universe! From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:44:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PKiEwJ025467 for ; Thu, 25 Apr 2002 13:44:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKiEmT025466 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:44: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 g3PKhuwJ025375 for ; Thu, 25 Apr 2002 13:43:56 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq01)) with ESMTP id E5BB0C216; Thu, 25 Apr 2002 22:12: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 WAA06294; Thu, 25 Apr 2002 22:12:06 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id 3AA9F57306; Thu, 25 Apr 2002 22:11:45 +0200 (CEST) Received: from ch.sauter-bc.com (sup.cad.sba [10.1.200.117]) by mobile.sauter-bc.com (Postfix) with ESMTP id 81FE625835; Thu, 25 Apr 2002 22:11:44 +0200 (CEST) Message-ID: <3CC86300.E6F23466@ch.sauter-bc.com> Date: Thu, 25 Apr 2002 22:11:44 +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: Mikes work account Cc: linux-xfs@oss.sgi.com Subject: Re: help References: Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Mikes work account schrieb: > > April 25, 2002 > > Last weekend, I installed the 2.4.9-12SGI_XFS_1.0.2smp rpm on my Linux box > which was running RedHat 7.1 2.4.9-12smp. Hi, Did you just upgrade the kernel on a original RedHat 7.1 box. If yes then it's clear that mkfs.xfs is not there because it doesn't belong to the XFS kernel RPM. Concerning your performance problem I strongly suggest upgrading to the current 2.4.9-31SGI_XFS_1.1smp kernel and trying again. It contains much improved XFS code. BTW what kind of storage are you using? Simon > I had no difficultywith the install except that the mkfs.xfs file was > missing and I wondered why. Si I copied it from another box I had running > an XFS filesystem which had loaded and configured without problems. > > I was able to then install and XFS filesystem and was able to automount the > filesystem without errors. > > The problem I have is that my system performance has degraded since the XFS > install. From all that I have read, my performance should have improved. > > We run about 80 to 100 logins over a thin client to this server and although > it has been busy we have never experienced this level of degredation in > performance. > > I did not install any of the patches and am not sure I know which I should > install in the first place. > > Can you offer any assistance into why my system should be slower than it > was. I have plenty of space and ram and am running on an IBM Netfinity 5000 > with dual 450 processors. > > My supervisor wants me to go back to the ext2 FS and I am reluctant to do so > because I feel I should be getting better performance with XFS if I can just > get it tuned. > > Thank you in advance, You prompt attention will be appreciated. > > Michael C. Rock From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:45: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 g3PKjVwJ025578 for ; Thu, 25 Apr 2002 13:45:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKjV0v025577 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:45:31 -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 g3PKjIwJ025540 for ; Thu, 25 Apr 2002 13:45:18 -0700 Received: (qmail 32452 invoked by uid 500); 25 Apr 2002 20:45:23 -0000 Subject: Re: poor io performance with xfs+raid5 From: Austin Gonyou To: Mike Eldridge Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <20020425154135.B14120@ornery.cafes.net> References: <20020425154135.B14120@ornery.cafes.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-e6o0YGVM9gVUOOrUdRSu" X-Mailer: Ximian Evolution 1.0.3.99 Date: 25 Apr 2002 15:45:23 -0500 Message-Id: <1019767523.23991.2.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-e6o0YGVM9gVUOOrUdRSu Content-Type: text/plain Content-Transfer-Encoding: quoted-printable What card is it, BTW? On Thu, 2002-04-25 at 15:41, Mike Eldridge wrote: > On Thu, Apr 25, 2002 at 03:19:05PM -0500, Steve Lord wrote: > > Well, Duh! I should have seen that first time around, I get into the > > habit of reading my email too fast! > >=20 > > We may be able to fix some things, if we can remake the filesystem. > > First you need to know the stripe unit of your raid - we can feed > > this into XFS to make it do stripe aligned allocations. This has > > to be done by hand on linux. Take a look at the mkfs.xfs man page > > and the section on sunit and swidth options. Probably bump your log > size > > up from the default somewhat, not sure how it ended up as 1839 > > that is scary. >=20 > RAID5 on this card offers only a 64K stripe size. however, i will be > recreating the array as RAID1 or RAID10, which offers stripe sizes from > 64K to 1MB. i'm not sure which is the best way to go. i think that the > best thing to do, considering additonal space requirements might be > neccessary, is to go with multiple RAID1 arrays and let LVM do the > striping. any caveats here? >=20 > this particular box is a mail server and it handles a lot of i/o with > pretty small files (< 64K). i want to optimize for performance. > unfortunately, this is also my *first* foray into xfs/lvm/raid, so i > want to make sure i have as much information as possible before i carve > it all in stone. >=20 > i need to go read some more about LVM... >=20 > as for the log, yeah, just over 7MB, i have no idea either. info i have > read suggests a 32MB log, but i'd like to use something bigger, perhaps > 128MB. any caveats to using a log of this size? >=20 > > You still have not said which kernel version you are running beyond > 2.4, > > unless I speed read over that too. >=20 > i did in a previous email. :) >=20 > it's vanilla 2.4.18 with the xfs-1.1 release patches applied. >=20 > -mike >=20 > ------------------------------------------------------------------------ > -- > /~\ the ascii all that is gold does not > glitter > \ / ribbon campaign not all those who wander are > lost > X against html -- jrr tolkien > / \ email! >=20 > radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd >=20 > ------------------------------------------------------------------------ > -- --=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 --=-e6o0YGVM9gVUOOrUdRSu 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 iD8DBQA8yGrj94g6ZVmFMoIRAuYMAKCxKq7VakIbOyBgNC3MGN5XGF7kwgCfYSTn cIroYNoacKQNf76/WDXkDPM= =LSmI -----END PGP SIGNATURE----- --=-e6o0YGVM9gVUOOrUdRSu-- From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:50: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 g3PKowwJ025967 for ; Thu, 25 Apr 2002 13:50:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKowst025966 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:50:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from stine.vestdata.no (IDENT:0@stine.vestdata.no [195.204.68.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PKopwJ025940 for ; Thu, 25 Apr 2002 13:50:52 -0700 Received: (from ragnark@localhost) by stine.vestdata.no (8.11.6/8.11.2) id g3PKmkQ27777; Thu, 25 Apr 2002 22:48:46 +0200 Date: Thu, 25 Apr 2002 22:48:46 +0200 From: =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= To: Steve Lord Cc: ASANO Masahiro , linux-xfs@oss.sgi.com Subject: Re: maximum files Message-ID: <20020425224846.D28067@vestdata.no> References: <20020424160854G.masano@tnes.nec.co.jp> <1019658798.27989.29.camel@jen.americas.sgi.com> <20020425190934G.masano@tnes.nec.co.jp> <1019741548.8309.3.camel@jen.americas.sgi.com> <20020425154607.B28067@vestdata.no> <1019742520.8353.16.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1019742520.8353.16.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 25, 2002 at 08:48:40AM -0500 X-MIME-Autoconverted: from 8bit to quoted-printable by stine.vestdata.no id g3PKmkQ27777 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3PKorwJ025941 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 08:48:40AM -0500, Steve Lord wrote: > > Ben LaHaise wrote patches to support >2TB devices. It should work on > > both i386 and ia64 (and other platforms), but will ofcourse be faster on > > 64 bit platforms. > > > > I don't know if it has been included in 2.5 yet, or of it will be, but > > the patch is out there. > > > It has not been, I think the issue was it made some basic types 64 bit > across the board - which negatively impacts the 32 bit kernels. That's > just from memory. It was a configuration-option, so it only impacted kernels that turned the feature on. > The patch on the ia64 list was a lot more comprehensive, everything from > the page cache, through fiber channel drivers to the partition table > code was affected. It almost looks as if someone has tried it with real > disk space in this case. It might have the same 64 bit on 32 bit issues > though - but it should be possible to make it configurable. We tested Ben's patches with real disk space - we had a few minor problems (like overflow in /proc/partitions and various kernel messages), but otherwise it worked. > Here is a link: > > https://external-lists.vasoftware.com/archives//linux-ia64/2002-April/003416.html Thanks. We'll check that out. -- Ragnar Kjørstad Big Storage From owner-linux-xfs@oss.sgi.com Thu Apr 25 13:56: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 g3PKuWwJ026153 for ; Thu, 25 Apr 2002 13:56:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PKuWOv026152 for linux-xfs-outgoing; Thu, 25 Apr 2002 13:56:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from kendy2.up.ac.za (kendy2.up.AC.za [137.215.94.33]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PKtdwJ026123 for ; Thu, 25 Apr 2002 13:55:54 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy2.up.ac.za with esmtp (Exim 3.35 #1) id 170qG8-0001jf-00; Thu, 25 Apr 2002 22:54:32 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 170qG7-00013m-00; Thu, 25 Apr 2002 22:54:31 +0200 Message-ID: <3CC86D07.AA5809D4@up.ac.za> Date: Thu, 25 Apr 2002 22:54:31 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-ifix-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Mikes work account CC: linux-xfs@oss.sgi.com Subject: Re: help References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *170qG7-00013m-00*kmmGtECpZJc* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Can you maybe give the output of xfs_info on all the mounted partitions and the mount options that you used. The output of df -h will also help. Paul Mikes work account wrote: > April 25, 2002 > > Last weekend, I installed the 2.4.9-12SGI_XFS_1.0.2smp rpm on my Linux box > which was running RedHat 7.1 2.4.9-12smp. > I had no difficultywith the install except that the mkfs.xfs file was > missing and I wondered why. Si I copied it from another box I had running > an XFS filesystem which had loaded and configured without problems. > > I was able to then install and XFS filesystem and was able to automount the > filesystem without errors. > > The problem I have is that my system performance has degraded since the XFS > install. From all that I have read, my performance should have improved. > > We run about 80 to 100 logins over a thin client to this server and although > it has been busy we have never experienced this level of degredation in > performance. > > I did not install any of the patches and am not sure I know which I should > install in the first place. > > Can you offer any assistance into why my system should be slower than it > was. I have plenty of space and ram and am running on an IBM Netfinity 5000 > with dual 450 processors. > > My supervisor wants me to go back to the ext2 FS and I am reluctant to do so > because I feel I should be getting better performance with XFS if I can just > get it tuned. > > Thank you in advance, You prompt attention will be appreciated. > > Michael C. Rock From owner-linux-xfs@oss.sgi.com Thu Apr 25 14:08:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PL8JwJ026500 for ; Thu, 25 Apr 2002 14:08:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PL8JvW026499 for linux-xfs-outgoing; Thu, 25 Apr 2002 14:08:19 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cafes.net (ip3-182.cafes.net [207.65.182.3] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PL87wJ026471 for ; Thu, 25 Apr 2002 14:08:08 -0700 Received: by mail.cafes.net (Postfix, from userid 500) id 14A1C83FB6; Thu, 25 Apr 2002 16:08:52 -0500 (CDT) Date: Thu, 25 Apr 2002 16:08:52 -0500 From: Mike Eldridge To: Austin Gonyou Cc: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 Message-ID: <20020425160852.C14120@ornery.cafes.net> References: <20020425154135.B14120@ornery.cafes.net> <1019767523.23991.2.camel@UberGeek> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1019767523.23991.2.camel@UberGeek>; from austin@coremetrics.com on Thu, Apr 25, 2002 at 03:45:23PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk i feel like a broken record. :) it's an escalade 7850 ata raid card. -mike On Thu, Apr 25, 2002 at 03:45:23PM -0500, Austin Gonyou wrote: > What card is it, BTW? > > > On Thu, 2002-04-25 at 15:41, Mike Eldridge wrote: > > On Thu, Apr 25, 2002 at 03:19:05PM -0500, Steve Lord wrote: > > > Well, Duh! I should have seen that first time around, I get into the > > > habit of reading my email too fast! > > > > > > We may be able to fix some things, if we can remake the filesystem. > > > First you need to know the stripe unit of your raid - we can feed > > > this into XFS to make it do stripe aligned allocations. This has > > > to be done by hand on linux. Take a look at the mkfs.xfs man page > > > and the section on sunit and swidth options. Probably bump your log > > size > > > up from the default somewhat, not sure how it ended up as 1839 > > > that is scary. > > > > RAID5 on this card offers only a 64K stripe size. however, i will be > > recreating the array as RAID1 or RAID10, which offers stripe sizes from > > 64K to 1MB. i'm not sure which is the best way to go. i think that the > > best thing to do, considering additonal space requirements might be > > neccessary, is to go with multiple RAID1 arrays and let LVM do the > > striping. any caveats here? > > > > this particular box is a mail server and it handles a lot of i/o with > > pretty small files (< 64K). i want to optimize for performance. > > unfortunately, this is also my *first* foray into xfs/lvm/raid, so i > > want to make sure i have as much information as possible before i carve > > it all in stone. > > > > i need to go read some more about LVM... > > > > as for the log, yeah, just over 7MB, i have no idea either. info i have > > read suggests a 32MB log, but i'd like to use something bigger, perhaps > > 128MB. any caveats to using a log of this size? > > > > > You still have not said which kernel version you are running beyond > > 2.4, > > > unless I speed read over that too. > > > > i did in a previous email. :) > > > > it's vanilla 2.4.18 with the xfs-1.1 release patches applied. > > > > -mike > > > > ------------------------------------------------------------------------ > > -- > > /~\ the ascii all that is gold does not > > glitter > > \ / ribbon campaign not all those who wander are > > lost > > X against html -- jrr tolkien > > / \ email! > > > > radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd > > > > ------------------------------------------------------------------------ > > -- > -- > 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 -------------------------------------------------------------------------- /~\ the ascii all that is gold does not glitter \ / ribbon campaign not all those who wander are lost X against html -- jrr tolkien / \ email! radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Thu Apr 25 14:24:41 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PLOfwJ026787 for ; Thu, 25 Apr 2002 14:24:41 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PLOZeK026786 for linux-xfs-outgoing; Thu, 25 Apr 2002 14:24: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 g3PLOWwJ026759 for ; Thu, 25 Apr 2002 14:24:32 -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 QAA46587 for ; Thu, 25 Apr 2002 16:24:58 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA69764 for ; Thu, 25 Apr 2002 16:24:58 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3PLOu215290; Thu, 25 Apr 2002 16:24:56 -0500 Message-Id: <200204252124.g3PLOu215290@jen.americas.sgi.com> Date: Thu, 25 Apr 2002 16:24:56 -0500 Subject: TAKE - small pagebuf fixes To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Also put some macros in the code to make 2.4 and 2.5 look closer to each other. Date: Thu Apr 25 14:23:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-jen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117475a linux/fs/xfs/pagebuf/page_buf_io.c - 1.27 - put back a fix that went missing, and fix a small memory leak in large (512K+) direct I/O. From owner-linux-xfs@oss.sgi.com Thu Apr 25 14:36: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 g3PLaRwJ027112 for ; Thu, 25 Apr 2002 14:36:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PLaRso027111 for linux-xfs-outgoing; Thu, 25 Apr 2002 14:36:27 -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 g3PLa9wJ027082 for ; Thu, 25 Apr 2002 14:36:09 -0700 Received: (qmail 14963 invoked by uid 500); 25 Apr 2002 21:36:10 -0000 Subject: Re: poor io performance with xfs+raid5 From: Austin Gonyou To: Mike Eldridge Cc: Steve Lord , linux-xfs@oss.sgi.com In-Reply-To: <20020425160852.C14120@ornery.cafes.net> References: <20020425160852.C14120@ornery.cafes.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Uav1sSmjSWgjxQnN5eRT" X-Mailer: Ximian Evolution 1.0.3.99 Date: 25 Apr 2002 16:36:10 -0500 Message-Id: <1019770570.21588.9.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-Uav1sSmjSWgjxQnN5eRT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Yeah..sorry I noticed it after reading again. :(=20 On Thu, 2002-04-25 at 16:08, Mike Eldridge wrote: > i feel like a broken record. :) >=20 > it's an escalade 7850 ata raid card. >=20 > -mike >=20 > On Thu, Apr 25, 2002 at 03:45:23PM -0500, Austin Gonyou wrote: > > What card is it, BTW? > >=20 > >=20 > > On Thu, 2002-04-25 at 15:41, Mike Eldridge wrote: > > > On Thu, Apr 25, 2002 at 03:19:05PM -0500, Steve Lord wrote: > > > > Well, Duh! I should have seen that first time around, I get into > the > > > > habit of reading my email too fast! > > > >=20 > > > > We may be able to fix some things, if we can remake the > filesystem. > > > > First you need to know the stripe unit of your raid - we can feed > > > > this into XFS to make it do stripe aligned allocations. This has > > > > to be done by hand on linux. Take a look at the mkfs.xfs man page > > > > and the section on sunit and swidth options. Probably bump your > log > > > size > > > > up from the default somewhat, not sure how it ended up as 1839 > > > > that is scary. > > >=20 > > > RAID5 on this card offers only a 64K stripe size. however, i will > be > > > recreating the array as RAID1 or RAID10, which offers stripe sizes > from > > > 64K to 1MB. i'm not sure which is the best way to go. i think that > the > > > best thing to do, considering additonal space requirements might be > > > neccessary, is to go with multiple RAID1 arrays and let LVM do the > > > striping. any caveats here? > > >=20 > > > this particular box is a mail server and it handles a lot of i/o > with > > > pretty small files (< 64K). i want to optimize for performance. > > > unfortunately, this is also my *first* foray into xfs/lvm/raid, so i > > > want to make sure i have as much information as possible before i > carve > > > it all in stone. > > >=20 > > > i need to go read some more about LVM... > > >=20 > > > as for the log, yeah, just over 7MB, i have no idea either. info i > have > > > read suggests a 32MB log, but i'd like to use something bigger, > perhaps > > > 128MB. any caveats to using a log of this size? > > >=20 > > > > You still have not said which kernel version you are running > beyond > > > 2.4, > > > > unless I speed read over that too. > > >=20 > > > i did in a previous email. :) > > >=20 > > > it's vanilla 2.4.18 with the xfs-1.1 release patches applied. > > >=20 > > > -mike > > >=20 > > > > ------------------------------------------------------------------------ > > > -- > > > /~\ the ascii all that is gold does not > > > glitter > > > \ / ribbon campaign not all those who wander are > > > lost > > > X against html -- jrr tolkien > > > / \ email! > > >=20 > > > radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd > > >=20 > > > > ------------------------------------------------------------------------ > > > -- > > --=20 > > Austin Gonyou > > Systems Architect, CCNA > > Coremetrics, Inc. > > Phone: 512-698-7250 > > email: austin@coremetrics.com > >=20 > > "It is the part of a good shepherd to shear his flock, not to skin > it." > > Latin Proverb >=20 >=20 >=20 >=20 > ------------------------------------------------------------------------ > -- > /~\ the ascii all that is gold does not > glitter > \ / ribbon campaign not all those who wander are > lost > X against html -- jrr tolkien > / \ email! >=20 > radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd >=20 > ------------------------------------------------------------------------ > -- --=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 --=-Uav1sSmjSWgjxQnN5eRT 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 iD8DBQA8yHbK94g6ZVmFMoIRAjNjAKDE+V69IAevc40VZ+sjTUURv+dqngCfTyDe b372I8Zd9OWX1PO7fS4X4Ys= =H+ca -----END PGP SIGNATURE----- --=-Uav1sSmjSWgjxQnN5eRT-- From owner-linux-xfs@oss.sgi.com Thu Apr 25 15:18:18 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PMIIwJ027562 for ; Thu, 25 Apr 2002 15:18:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PMIImW027561 for linux-xfs-outgoing; Thu, 25 Apr 2002 15:18:18 -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 g3PMHlwJ027522 for ; Thu, 25 Apr 2002 15:17:47 -0700 Message-Id: <200204252217.g3PMHlwJ027522@oss.sgi.com> Received: (qmail 8920 invoked from network); 25 Apr 2002 16:52:01 -0000 Received: from unknown (HELO appsales.net) (65.168.244.13) by 0 with SMTP; 25 Apr 2002 16:52:01 -0000 From: sendout@appsales.net To: Manufacturers@oss.sgi.com Subject: Manuf. Production/Control Software $1,495! Reply-To: info@appsales.net Date: 25 Apr 2002 10:03:16 -0700 MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk (JMSP042502)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 May 3rd 2002. (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 May 3rd, 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 Thu Apr 25 16:21:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PNLGwJ029615 for ; Thu, 25 Apr 2002 16:21:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PNLGAl029614 for linux-xfs-outgoing; Thu, 25 Apr 2002 16:21:16 -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 g3PNLBwJ029588 for ; Thu, 25 Apr 2002 16:21:11 -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 QAA1525579 for ; Thu, 25 Apr 2002 16:21:43 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by nodin.corp.sgi.com (8.11.4/8.11.4/nodin-1.0) with ESMTP id g3PNKg22109447 for ; Thu, 25 Apr 2002 16:20:42 -0700 (PDT) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA20309 for linux-xfs@oss.sgi.com; Fri, 26 Apr 2002 09:19:25 +1000 (EST) Date: Fri, 26 Apr 2002 09:19:25 +1000 (EST) From: Nathan Scott Message-Id: <200204252319.JAA20309@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - minor xfsprogs update Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Apr 25 16:18:45 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:117492a xfsprogs/doc/CHANGES - 1.61 - Update xfs_growfs man page; don't build libxlog.a with DEBUG enabled. xfsprogs/man/man8/xfs_growfs.8 - 1.4 - Update xfs_growfs man page. xfsprogs/libxlog/Makefile - 1.2 - don't build libxlog.a with DEBUG enabled. From owner-linux-xfs@oss.sgi.com Thu Apr 25 16:40:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3PNe1wJ029845 for ; Thu, 25 Apr 2002 16:40:01 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3PNe1M3029844 for linux-xfs-outgoing; Thu, 25 Apr 2002 16:40:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3PNdvwJ029813 for ; Thu, 25 Apr 2002 16:39:57 -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 QAA1527899 for ; Thu, 25 Apr 2002 16:40:28 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA06529 for linux-xfs@oss.sgi.com; Fri, 26 Apr 2002 09:39:11 +1000 (EST) Date: Fri, 26 Apr 2002 09:39:11 +1000 (EST) From: Nathan Scott Message-Id: <200204252339.JAA06529@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Thu Apr 25 16:38:11 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117494a linux/fs/xfs/pagebuf/page_buf_io.c - 1.28 - last change dropped initialization of "head", add it back. From owner-linux-xfs@oss.sgi.com Thu Apr 25 17:04:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q049wJ030511 for ; Thu, 25 Apr 2002 17:04:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q049uQ030510 for linux-xfs-outgoing; Thu, 25 Apr 2002 17:04:09 -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 g3Q042wJ030484 for ; Thu, 25 Apr 2002 17:04:02 -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 RAA1464121 for ; Thu, 25 Apr 2002 17:04:33 -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 KAA01099; Fri, 26 Apr 2002 10:03:16 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA80290; Fri, 26 Apr 2002 10:03:15 +1000 (AEST) Date: Fri, 26 Apr 2002 10:03:15 +1000 From: Nathan Scott To: Chris Tooley Cc: samba@lists.samba.org, linux-xfs@oss.sgi.com Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) Message-ID: <20020426100315.A80513@wobbly.melbourne.sgi.com> References: <1019766178.1958.12.camel@itspec.amoa.org> <1019766533.8353.109.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1019766533.8353.109.camel@jen.americas.sgi.com>; from lord@sgi.com on Thu, Apr 25, 2002 at 03:28:53PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 03:28:53PM -0500, Steve Lord wrote: > On Thu, 2002-04-25 at 15:22, Chris Tooley wrote: > > > > On Thu, 2002-04-25 at 15:06, Gerald Carter wrote: > > > On 25 Apr 2002, Chris Tooley wrote: > > > > > > > Actually this is fixed in the acl rpms and new makefile. No change to > > > > Samba was required. > > > > > > > > Chris Tooely > > > > > > Cool. :-) Thanks for the update. I'll mark that one off my list :-) > > > > > That's not to say that the fix is in an official release, I just know > > that the CVS version that I used worked perfectly. > > > > Mr Scott: You think you guys could roll out new packages with the > > Makefile changes? I'll chat with Eric about this, see what he thinks. You can easily "roll your own" packages from cvs by simply: # cd cmd/acl # ./Makepkgs and new rpms will pop out at the end. > > Unless I mis read things: > > ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/i386/ > > is what you need. Those look current to me. The libacl build problem cropped up right after 1.1 -- above has acl-2.0.9, fix is in 2.0.10, unfortunately. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 25 17:07:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q07xwJ030706 for ; Thu, 25 Apr 2002 17:07:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q07xWG030705 for linux-xfs-outgoing; Thu, 25 Apr 2002 17:07:59 -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 g3Q07uwJ030679 for ; Thu, 25 Apr 2002 17:07:56 -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 RAA945308 for ; Thu, 25 Apr 2002 17:08:27 -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 KAA01128; Fri, 26 Apr 2002 10:07:11 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA60210; Fri, 26 Apr 2002 10:07:10 +1000 (AEST) Date: Fri, 26 Apr 2002 10:07:10 +1000 From: Nathan Scott To: Chris Tooley Cc: linux-xfs@oss.sgi.com Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) Message-ID: <20020426100710.C80513@wobbly.melbourne.sgi.com> References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> <1019581365.26898.9.camel@itspec.amoa.org> <20020424084049.M63455@wobbly.melbourne.sgi.com> <1019657673.29084.7.camel@itspec.amoa.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1019657673.29084.7.camel@itspec.amoa.org>; from ctooley@amoa.org on Wed, Apr 24, 2002 at 09:14:33AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Wed, Apr 24, 2002 at 09:14:33AM -0500, Chris Tooley wrote: > Has anything else been changed in CVS? I'm hoping that nothing is > broken because I'm planning on putting the machine into production this > weekend. > [cmd/acl/doc/CHANGES] ... nothing else has changed. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 25 17:10: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 g3Q0A7wJ030861 for ; Thu, 25 Apr 2002 17:10:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q0A7h1030860 for linux-xfs-outgoing; Thu, 25 Apr 2002 17:10:07 -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 g3Q0A2wJ030830 for ; Thu, 25 Apr 2002 17:10:02 -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 RAA1398279 for ; Thu, 25 Apr 2002 17:10:34 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01158; Fri, 26 Apr 2002 10:09:17 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA80819; Fri, 26 Apr 2002 10:09:16 +1000 (AEST) Date: Fri, 26 Apr 2002 10:09:16 +1000 From: Nathan Scott To: Adam Milazzo Cc: "'linux-xfs@oss.sgi.com'" Subject: Re: libxfs documentation Message-ID: <20020426100915.D80513@wobbly.melbourne.sgi.com> References: <44D5677E9B8478468DE31AE26DF0AFD6077C9D@adsl-64-165-6-11.dsl.sndg02.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <44D5677E9B8478468DE31AE26DF0AFD6077C9D@adsl-64-165-6-11.dsl.sndg02.pacbell.net>; from adam@trustium.com on Thu, Apr 25, 2002 at 11:38:42AM -0700 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 11:38:42AM -0700, Adam Milazzo wrote: > Is there any documentation available for libxfs besides the source code > itself? Surely there has to be some documentation, if only internal, I would > think. Does anybody know where and if something like this is available? I > haven't been able to find any... There is none. libxfs == select bits of XFS kernel code compiled in userspace; for xfs_repair, mkfs.xfs and xfs_db only, it is not intended as a general purpose library. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 25 17:44: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 g3Q0i7wJ031227 for ; Thu, 25 Apr 2002 17:44:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q0i70p031226 for linux-xfs-outgoing; Thu, 25 Apr 2002 17:44:07 -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 g3Q0i3wJ031200 for ; Thu, 25 Apr 2002 17:44:03 -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 RAA1307277 for ; Thu, 25 Apr 2002 17:44:34 -0700 (PDT) mail_from (nathans@wobbly.melbourne.sgi.com) Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA01379; Fri, 26 Apr 2002 10:43:14 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA75086; Fri, 26 Apr 2002 10:43:13 +1000 (AEST) Date: Fri, 26 Apr 2002 10:43:13 +1000 From: Nathan Scott To: Matthew Geier Cc: linux-xfs@oss.sgi.com Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) Message-ID: <20020426104313.E80513@wobbly.melbourne.sgi.com> References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> <1019581365.26898.9.camel@itspec.amoa.org> <20020424084049.M63455@wobbly.melbourne.sgi.com> <1019657673.29084.7.camel@itspec.amoa.org> <1019684675.3cc72743d9ded@admin.arts.usyd.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1019684675.3cc72743d9ded@admin.arts.usyd.edu.au>; from matthew@arts.usyd.edu.au on Thu, Apr 25, 2002 at 07:44:35AM +1000 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 07:44:35AM +1000, Matthew Geier wrote: > The compile of samba 2.2.3a then failed on the quota code - some ones messed > with the quota interface as well. :-) The XFS quota interface hasn't changed, but we do now include the 32 bit VFS quota patches in the XFS releases. What were the error messages you saw? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 25 17:55:52 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q0tqwJ031476 for ; Thu, 25 Apr 2002 17:55:52 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q0tq9R031475 for linux-xfs-outgoing; Thu, 25 Apr 2002 17:55: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 g3Q0tlwJ031449 for ; Thu, 25 Apr 2002 17:55:47 -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 RAA1418092 for ; Thu, 25 Apr 2002 17:56:18 -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 KAA01452; Fri, 26 Apr 2002 10:54:47 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id KAA80875; Fri, 26 Apr 2002 10:54:45 +1000 (AEST) Date: Fri, 26 Apr 2002 10:54:45 +1000 From: Nathan Scott To: Willi.Langenberger@wu-wien.ac.at Cc: linux-xfs@oss.sgi.com Subject: Re: corrupt xfs filesystem -- xfs_repair dumps core Message-ID: <20020426105445.F80513@wobbly.melbourne.sgi.com> References: <15557.36194.760672.792045@slime.wu-wien.ac.at> <20020424082748.L63455@wobbly.melbourne.sgi.com> <15558.37214.558780.264419@slime.wu-wien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15558.37214.558780.264419@slime.wu-wien.ac.at>; from wlang@wu-wien.ac.at on Wed, Apr 24, 2002 at 01:05:02PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Wed, Apr 24, 2002 at 01:05:02PM +0200, Willi Langenberger wrote: > > > > Failing that, try "xfs_repair -L /dev/sdb" which skips the check for > > an empty log, zeroes it, then goes ahead with repairing. > > Unfortunatly the '-L' makes no difference: Oh, I see -- that check only comes into play later... hmmm, will have to try plan C. > > Failing that (!) we can get libxlog built non-debug so this assertion > > doesn't get tripped, and see how we go from there. > > Ok, i will see if i can do this... I've checked in a Makefile change to do this -- so, checkout CVS xfsprogs, rebuild from scratch, esp. ensuring libxlog and xfs_repair are completely rebuilt, then try the newly built xfs_repair binary and see if you have better luck. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Thu Apr 25 18:08:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q18swJ031762 for ; Thu, 25 Apr 2002 18:08:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q18sk1031761 for linux-xfs-outgoing; Thu, 25 Apr 2002 18:08:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from itspec.amoa.org (amoa.org [207.207.51.226]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3Q18iwJ031735 for ; Thu, 25 Apr 2002 18:08:45 -0700 Received: (from ctooley@localhost) by itspec.amoa.org (8.11.6/8.11.6) id g3Q19O902482; Thu, 25 Apr 2002 20:09:24 -0500 X-Authentication-Warning: itspec.amoa.org: ctooley set sender to ctooley@amoa.org using -f Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) From: Chris Tooley To: Nathan Scott Cc: samba@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: <20020426100315.A80513@wobbly.melbourne.sgi.com> References: <1019766178.1958.12.camel@itspec.amoa.org> <1019766533.8353.109.camel@jen.americas.sgi.com> <20020426100315.A80513@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 25 Apr 2002 20:09:23 -0500 Message-Id: <1019783363.1957.15.camel@itspec.amoa.org> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 19:03, Nathan Scott wrote: > On Thu, Apr 25, 2002 at 03:28:53PM -0500, Steve Lord wrote: > > On Thu, 2002-04-25 at 15:22, Chris Tooley wrote: > > > > > > On Thu, 2002-04-25 at 15:06, Gerald Carter wrote: > > > > On 25 Apr 2002, Chris Tooley wrote: > > > > > > > > > Actually this is fixed in the acl rpms and new makefile. No change to > > > > > Samba was required. > > > > > > > > > > Chris Tooely > > > > > > > > Cool. :-) Thanks for the update. I'll mark that one off my list :-) > > > > > > > That's not to say that the fix is in an official release, I just know > > > that the CVS version that I used worked perfectly. > > > > > > Mr Scott: You think you guys could roll out new packages with the > > > Makefile changes? > > I'll chat with Eric about this, see what he thinks. > > You can easily "roll your own" packages from cvs by simply: > > # cd cmd/acl > # ./Makepkgs > > and new rpms will pop out at the end. > > > > > Unless I mis read things: > > > > ftp://oss.sgi.com/projects/xfs/download/cmd_rpms/i386/ > > > > is what you need. Those look current to me. > > The libacl build problem cropped up right after 1.1 -- above has > acl-2.0.9, fix is in 2.0.10, unfortunately. Do you have a ball park when 2.0.10 will roll out or possibly a 2.0.9a? > > cheers. > > -- > Nathan > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba -- Chris Tooley IT Coordinator Austin Museum of Art 823 Congress Ave. Austin, TX 78701 office - (512)495-9224 x289 pager - (512)613-2603 ctooley@amoa.org From owner-linux-xfs@oss.sgi.com Thu Apr 25 19:04:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q248wJ032300 for ; Thu, 25 Apr 2002 19:04:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q248f8032299 for linux-xfs-outgoing; Thu, 25 Apr 2002 19:04:08 -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 g3Q240wJ032273 for ; Thu, 25 Apr 2002 19:04:01 -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 MAA23934; Fri, 26 Apr 2002 12:04:21 +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, 26 Apr 2002 12:04:21 +1000 Message-ID: <1019786661.3cc8b5a59c2a4@admin.arts.usyd.edu.au> Date: Fri, 26 Apr 2002 12:04:21 +1000 From: Matthew Geier To: Nathan Scott Cc: linux-xfs@oss.sgi.com Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) References: <20020418190627.6a4dc65c.cd@kalkatraz.de> <3CC05C1D.2080504@merlinsoftech.com> <20020420100247.H22886@wobbly.melbourne.sgi.com> <1019581365.26898.9.camel@itspec.amoa.org> <20020424084049.M63455@wobbly.melbourne.sgi.com> <1019657673.29084.7.camel@itspec.amoa.org> <1019684675.3cc72743d9ded@admin.arts.usyd.edu.au> <20020426104313.E80513@wobbly.melbourne.sgi.com> In-Reply-To: <20020426104313.E80513@wobbly.melbourne.sgi.com> 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 Quoting Nathan Scott : > On Thu, Apr 25, 2002 at 07:44:35AM +1000, Matthew Geier wrote: > > The compile of samba 2.2.3a then failed on the quota code - some ones > messed > > with the quota interface as well. :-) > > The XFS quota interface hasn't changed, but we do now include the > 32 bit VFS quota patches in the XFS releases. What were the error > messages you saw? A week ago now... :-) Something along the lines of 'type unknown'. Samba's configure had picked the 'old' quota interface, I had compiled the 'new' one into the kernel, but even after editing config.h to select 'V2' quota's the data structure still didn't exist. Some one renamed dqblk to if_dqpblk I think - #else /* LINUX_QUOTAS_2 */ struct if_dqblk D; ZERO_STRUCT(D); #ifndef QUOTABLOCK_SIZE I don't know if it was the correct thing to do or not, but the file compiled, as all file systems on this box are XFS, and samba will use the XFS calls if its an XFS file system... -- Matthew Geier matthew@arts.usyd.edu.au Arts IT Unit +61 2 9351 4713 Sydney University ------------------------------------------------- This mail sent through IMP at ArtsIT: http://admin.arts.usyd.edu.au/horde/imp/ From owner-linux-xfs@oss.sgi.com Thu Apr 25 22:27:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q5RgwJ001883 for ; Thu, 25 Apr 2002 22:27:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q5RfxD001882 for linux-xfs-outgoing; Thu, 25 Apr 2002 22:27:41 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla2.xs4all.nl (mxzilla2.xs4all.nl [194.109.6.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3Q5RZwJ001856 for ; Thu, 25 Apr 2002 22:27:36 -0700 Received: from xs4.xs4all.nl (knuffie@xs4.xs4all.nl [194.109.6.45]) by mxzilla2.xs4all.nl (8.12.0/8.12.0) with ESMTP id g3Q5S3Ph072262; Fri, 26 Apr 2002 07:28:03 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs4.xs4all.nl (8.9.0/8.9.0) with ESMTP id HAA23472; Fri, 26 Apr 2002 07:28:03 +0200 (CEST) Date: Fri, 26 Apr 2002 07:28:03 +0200 (CEST) From: Seth Mos To: Justin Coffey cc: Steve Lord , Mike Eldridge , Subject: Re: poor io performance with xfs+raid5 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 25 Apr 2002, Justin Coffey wrote: > > > The alignment issue is mostly software raid5 specific. The ability to > > better align the writes will help on other configs to a lesser extent. > > Thanks. We're in the design phase of a new product and it's likely to use > some sort of largish NAS box. Most likely raid 5'ed. Initially (due to > cost) we'll probably do software raid but we'll want to move to hardware > level at some point. I guess that means ReiserFS for us for now? Only software raid is affected by the unaligned access. If you use hardware raid like the escalade has there shouldn't be a problem. I have a 3disk software raid5 volume which performs reasonable even with thye current code base. Can you give some number about the disk performance? If you really need fast IO you should look into raid 1 or 10. These have a lot lower overhead then raid5. The card may be the limiting factor. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Apr 26 00:04:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q749wJ002638 for ; Fri, 26 Apr 2002 00:04:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q748QU002637 for linux-xfs-outgoing; Fri, 26 Apr 2002 00:04:08 -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 g3Q740wJ002611 for ; Fri, 26 Apr 2002 00:04:01 -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 g3Q72xbd092529; Fri, 26 Apr 2002 09:03:00 +0200 (CEST) Message-Id: <4.3.2.7.2.20020426085841.0397c9f8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Apr 2002 09:04:18 +0200 To: Mike Eldridge From: Seth Mos Subject: Re: poor io performance with xfs+raid5 Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020425154135.B14120@ornery.cafes.net> References: <1019765945.12905.102.camel@jen.americas.sgi.com> <3CC85999.501431E5@ch.sauter-bc.com> <20020425144025.N16048@ornery.cafes.net> <1019765945.12905.102.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk At 15:41 25-4-2002 -0500, Mike Eldridge wrote: >On Thu, Apr 25, 2002 at 03:19:05PM -0500, Steve Lord wrote: > > Well, Duh! I should have seen that first time around, I get into the > > habit of reading my email too fast! > > > > We may be able to fix some things, if we can remake the filesystem. > > First you need to know the stripe unit of your raid - we can feed > > this into XFS to make it do stripe aligned allocations. This has > > to be done by hand on linux. Take a look at the mkfs.xfs man page > > and the section on sunit and swidth options. Probably bump your log size > > up from the default somewhat, not sure how it ended up as 1839 > > that is scary. > >RAID5 on this card offers only a 64K stripe size. however, i will be >recreating the array as RAID1 or RAID10, which offers stripe sizes from >64K to 1MB. i'm not sure which is the best way to go. i think that the >best thing to do, considering additonal space requirements might be >neccessary, is to go with multiple RAID1 arrays and let LVM do the >striping. any caveats here? That should work just fine. >this particular box is a mail server and it handles a lot of i/o with >pretty small files (< 64K). i want to optimize for performance. >unfortunately, this is also my *first* foray into xfs/lvm/raid, so i >want to make sure i have as much information as possible before i carve >it all in stone. Use raid 1 since mail servers are a lot like databases, lots of reads and writes. Writes are always slow on raid5 and don't use it for a database or mailserver. make the filesystem with a 32MB log. mkfs.xfs -l size=32768b /dev/sda Mount the filesystem with more buffers (this also means that you can loose more data while it is in transit) although mail servers will probably write the file synchronously and those buffers could be useless. There is a chance that this also the problem you are encountering with the raid5 config. mount -t xfs -o logbufs=8 /dev/sda /var/spool/mail Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Fri Apr 26 00:31:01 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q7V0wJ002966 for ; Fri, 26 Apr 2002 00:31:00 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q7V04r002965 for linux-xfs-outgoing; Fri, 26 Apr 2002 00:31:00 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3Q7UkwJ002936 for ; Fri, 26 Apr 2002 00:30:47 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g3Q7VAV16249 for ; Fri, 26 Apr 2002 16:31:10 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g3Q7V8R09907 for ; Fri, 26 Apr 2002 16:31:09 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g3Q7V7r11892 for ; Fri, 26 Apr 2002 16:31:07 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA250 for ; Fri, 26 Apr 2002 16:06:41 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Fri Apr 26 16:06:40 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g3Q76e618128 for ; Fri, 26 Apr 2002 16:06:41 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id g3Q76eO15822 for ; Fri, 26 Apr 2002 16:06:40 +0900 To: linux-xfs@oss.sgi.com Subject: xfs_db correction request X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Common Lisp) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Apr_26_16:06:39_2002_953)--" Content-Transfer-Encoding: 7bit Message-Id: <20020426160640Y.masano@tnes.nec.co.jp> Date: Fri, 26 Apr 2002 16:06:40 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 95 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----Next_Part(Fri_Apr_26_16:06:39_2002_953)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I found minor bugs in xfs_db command. print cannot print `core.[amc]time.sec' at 64bit linux architecture because of sizeof(time_t)==8 write rrot miss-copying in overlap area write sequence/random `start' argument does not work -- Masano ----Next_Part(Fri_Apr_26_16:06:39_2002_953)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=patch-xfsdb Index: cmd/xfsprogs/db/fprint.c =================================================================== RCS file: /usr/localmnt/xfs/cvsroot/linux-2.4-xfs/cmd/xfsprogs/db/fprint.c,v retrieving revision 1.1 diff -u -r1.1 fprint.c --- cmd/xfsprogs/db/fprint.c 2001/01/15 05:36:03 1.1 +++ cmd/xfsprogs/db/fprint.c 2002/04/26 05:51:38 @@ -161,7 +161,7 @@ i++, bitpos += size) { if (array) dbprintf("%d:", i + base); - t=(time_t)getbitval((char *)obj + byteize(bitpos), 0, sizeof(time_t)*8, 0); + t=(time_t)getbitval((char *)obj + byteize(bitpos), 0, sizeof(int32_t)*8, 0); c = ctime(&t); dbprintf("%24.24s", c); if (i < count - 1) Index: cmd/xfsprogs/db/write.c =================================================================== RCS file: /usr/localmnt/xfs/cvsroot/linux-2.4-xfs/cmd/xfsprogs/db/write.c,v retrieving revision 1.1 diff -u -r1.1 write.c --- cmd/xfsprogs/db/write.c 2001/01/15 05:36:03 1.1 +++ cmd/xfsprogs/db/write.c 2002/04/26 05:51:43 @@ -277,7 +277,7 @@ hold_region = xmalloc(shift); memcpy(hold_region, base+(len-shift), shift); - memcpy(base+shift, base, len-shift); + memmove(base+shift, base, len-shift); memcpy(base, hold_region, shift); } @@ -295,7 +295,7 @@ int base; int range; int top; - char *buf = (char *)iocur_top->data; + char *buf; if (start == -1) start = 0; @@ -325,6 +325,7 @@ } range = top - base; + buf = (char *)iocur_top->data + start; tmp = 0; for (i = start; i < start+len; i++) { @@ -343,7 +344,7 @@ int to) { int i; - char *buf = (char *)iocur_top->data; + char *buf; if (start == -1) start = 0; @@ -355,6 +356,8 @@ dbprintf("length (%d) too large for data block size (%d)", len, iocur_top->len); } + + buf = (char *)iocur_top->data + start; for (i = start; i < start+len; i++) *buf++ = (char)lrand48(); ----Next_Part(Fri_Apr_26_16:06:39_2002_953)---- From owner-linux-xfs@oss.sgi.com Fri Apr 26 01:07:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3Q879wJ003476 for ; Fri, 26 Apr 2002 01:07:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3Q878DU003475 for linux-xfs-outgoing; Fri, 26 Apr 2002 01:07:08 -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 g3Q86xwJ003449 for ; Fri, 26 Apr 2002 01:07:00 -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 BAA1483992 for ; Fri, 26 Apr 2002 01:07:32 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA24622; Fri, 26 Apr 2002 18:06:15 +1000 (EST) Date: Fri, 26 Apr 2002 18:06:15 +1000 (EST) From: Nathan Scott Message-Id: <200204260806.SAA24622@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com, masano@tnes.nec.co.jp Subject: TAKE - xfsprogs Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Apr 26, 2002 at 04:06:40PM +0900, ASANO Masahiro wrote: > Hi, > > I found minor bugs in xfs_db command. > > print > cannot print `core.[amc]time.sec' at 64bit linux architecture > because of sizeof(time_t)==8 > > write rrot > miss-copying in overlap area > > write sequence/random > `start' argument does not work > ... Patch has been applied -- thanks! cheers. Date: Thu Apr 25 18:38:59 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:117504a xfsprogs/libxlog/xfs_log_recover.c - 1.4 - remove an unnecessary ifdef __KERNEL__ conditional, no asserts enabled now. Date: Fri Apr 26 01:04:03 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:117512a xfsprogs/db/write.c - 1.2 xfsprogs/db/fprint.c - 1.2 xfsprogs/doc/CHANGES - 1.62 - bug fixes from ASANO Masahiro . From owner-linux-xfs@oss.sgi.com Fri Apr 26 03:24:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QAOtwJ004954 for ; Fri, 26 Apr 2002 03:24:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QAOtQ3004953 for linux-xfs-outgoing; Fri, 26 Apr 2002 03:24:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from jim.iv (dial_up_dinamic_pool2_238.bn.by [212.98.161.238]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QAObwJ004926 for ; Fri, 26 Apr 2002 03:24:46 -0700 Received: from mail.ru (IDENT:dmitry@jim [127.0.0.1]) by jim.iv (8.12.1/8.12.1) with ESMTP id g3QAQrsx005695 for ; Fri, 26 Apr 2002 13:26:53 +0300 Message-ID: <3CC92B6D.3010006@mail.ru> Date: Fri, 26 Apr 2002 13:26:53 +0300 From: Dmitry Katsubo User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en, ru MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS error Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, XFS developers! I am using CVS 2.4.18-xfs kernel, and after the latest update and reboot I found the next error. The system continues running after it. Suppose, it would help you in finding the problem. kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000c kernel: printing eip: kernel: c01fb3b6 kernel: *pde = 00000000 kernel: Oops: 0000 kernel: CPU: 0 kernel: EIP: 0010:[cluster_write+6/272] Not tainted kernel: EIP: 0010:[] Not tainted kernel: EFLAGS: 00010246 kernel: eax: 00000000 ebx: 00000000 ecx: dfa36860 edx: ce3410c8 kernel: esi: c17b7e8c edi: c1356d20 ebp: 00000000 esp: c17b7e54 kernel: ds: 0018 es: 0018 ss: 0018 kernel: Process kupdated (pid: 7, stackpage=c17b7000) kernel: Stack: 00000000 c17b7e8c c1356d20 00000001 c01fb55f df64b340 ce3410c0 c1356d20 kernel: c17b7e8c 00000001 00010002 c01fed80 00000001 00000001 02756ec8 00000000 kernel: 00000000 00000000 00000000 00080000 00000001 00000047 c1356d20 0007f291 kernel: Call Trace: [pagebuf_delalloc_convert+159/192] [linvfs_pb_bmap+0/208] [pagebuf_write_full_page+127/224] [linvfs_pb_bmap+0/208] [xfs_write_full_page+37/64] kernel: Call Trace: [] [] [] [] [] kernel: [linvfs_pb_bmap+0/208] [linvfs_write_full_page+135/176] [write_buffer_delay+85/96] [write_some_buffers+237/272] [schedule+489/880] [flush_old_commits+239/352] kernel: [] [] [] [] [] [] kernel: [sync_unlocked_inodes+246/352] [process_timeout+0/80] [sync_old_buffers+28/64] [kupdate+247/256] [_stext+0/48] [kernel_thread+38/48] kernel: [] [] [] [] [] [] kernel: [kupdate+0/256] kernel: [] kernel: kernel: Code: 8b 45 0c 31 ff 8b 48 0c 85 c9 74 51 8b 5d 10 8b 43 08 8b 53 From owner-linux-xfs@oss.sgi.com Fri Apr 26 03:29: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 g3QATtwJ005135 for ; Fri, 26 Apr 2002 03:29:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QATtgk005134 for linux-xfs-outgoing; Fri, 26 Apr 2002 03:29:55 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from prserv.net (out2.prserv.net [32.97.166.32]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QATmwJ005100 for ; Fri, 26 Apr 2002 03:29:48 -0700 Received: from starfleet.attglobal.net (slip-32-100-182-205.wi.us.prserv.net[32.100.182.205]) by prserv.net (out2) with ESMTP id <2002042519073320202k4gd8e>; Thu, 25 Apr 2002 19:07:33 +0000 Received: (from skylar@localhost) by starfleet.attglobal.net (8.11.6/8.11.6) id g3PBf6e25743 for linux-xfs@oss.sgi.com; Thu, 25 Apr 2002 06:41:06 -0500 X-Authentication-Warning: starfleet.attglobal.net: skylar set sender to skylar@attglobal.net using -f Date: Thu, 25 Apr 2002 06:41:06 -0500 From: Skylar Thompson To: linux-xfs@oss.sgi.com Subject: Re: Linux request. Message-ID: <20020425114106.GA25737@starfleet.attglobal.net> Reply-To: Skylar Thompson Mail-Followup-To: linux-xfs@oss.sgi.com References: <200204250112.AA199491690@mail.deseretmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <200204250112.AA199491690@mail.deseretmail.com> User-Agent: Mutt/1.3.28i X-Sender: "Skylar Thompson" X-Accept-Primary-Language: en X-Accept-Secondary-Language: es X-Accept-Tertiary-Language: Quenya SMTP-Mailing-Host: starfleet.attglobal.net Organization: League of Morgoth X-Editor: VIM - Vi IMproved 6.1 (2002 Mar 24, compiled Mar 25 2002 16:11:05) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2002 at 01:12:34AM -0600, Roland_Kaiser wrote: > Hi, found your eMail- adress while surfing on: > http://rpmfind.net/linux/RPM/Vendors.html >=20 > So far, I never got a hook on unix, but I understand it as fast and > reliable and opensource. What else are the advantages of this system? > Where can I get info, do you know some other Linux- sites?. http://www.linux.com and http://www.linux.org are probably good places to start. If you want information on XFS, go to http://oss.sgi.com/projects/xfs/. --=20 -- Skylar Thompson (skylar@attglobal.net) --82I3+IH0IqGh5yIs 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 iD8DBQE8x+tSnMU1m27tfjARAgl+AKCgBQSrc9e6t6JXSnJsBxmMlsZ1QwCfcSK3 gK83xMGltFS+qmGohasilxo= =Vrq4 -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-linux-xfs@oss.sgi.com Fri Apr 26 04:30:28 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QBUSwJ006249 for ; Fri, 26 Apr 2002 04:30:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QBUSfI006248 for linux-xfs-outgoing; Fri, 26 Apr 2002 04:30:28 -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 g3QBUHwJ006221 for ; Fri, 26 Apr 2002 04:30:17 -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 g3QBPw3u013473; Fri, 26 Apr 2002 07:26:02 -0400 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id g3QBUkW28904; Fri, 26 Apr 2002 07:30:46 -0400 (EDT) Date: Fri, 26 Apr 2002 07:30:46 -0400 From: Thor Lancelot Simon To: Mike Eldridge Cc: linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 Message-ID: <20020426073045.A28894@pla-muek.reefedge.com> References: <3CC85999.501431E5@ch.sauter-bc.com> <20020425144025.N16048@ornery.cafes.net> <1019765945.12905.102.camel@jen.americas.sgi.com> <20020425154135.B14120@ornery.cafes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020425154135.B14120@ornery.cafes.net>; from diz@cafes.net on Thu, Apr 25, 2002 at 03:41:35PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 03:41:35PM -0500, Mike Eldridge wrote: > On Thu, Apr 25, 2002 at 03:19:05PM -0500, Steve Lord wrote: > > Well, Duh! I should have seen that first time around, I get into the > > habit of reading my email too fast! > > > > We may be able to fix some things, if we can remake the filesystem. > > First you need to know the stripe unit of your raid - we can feed > > this into XFS to make it do stripe aligned allocations. This has > > to be done by hand on linux. Take a look at the mkfs.xfs man page > > and the section on sunit and swidth options. Probably bump your log size > > up from the default somewhat, not sure how it ended up as 1839 > > that is scary. > > RAID5 on this card offers only a 64K stripe size. however, i will be And is also notorious for mediocre performance. It appears to have been implemented largely as a checkbox feature. Doing unaligned writes to a hardware RAID device can still be a problem, if the hardware RAID device can't at least cache enough data to coalesce writes up to its stripe size; one does, from time to time, see cheap RAID hardware in PCs that has exactly this problem, though IIRC there is another cause for the Escalade's crummy RAID5 performance. Thor From owner-linux-xfs@oss.sgi.com Fri Apr 26 05:13:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QCDJwJ006715 for ; Fri, 26 Apr 2002 05:13:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QCDJ1o006714 for linux-xfs-outgoing; Fri, 26 Apr 2002 05:13:19 -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 g3QCClwJ006684 for ; Fri, 26 Apr 2002 05:12:48 -0700 Received: from erbenson.alaska.net (8-pm21.nwc.alaska.net [209.112.143.8]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3QCDJw56469 for ; Fri, 26 Apr 2002 04:13:19 -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 A3C303978 for ; Fri, 26 Apr 2002 04:13:18 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 9D79F10287; Fri, 26 Apr 2002 04:13:18 -0800 (AKDT) Date: Fri, 26 Apr 2002 04:11:11 -0800 From: Ethan Benson To: Andreas Gruenbacher Cc: acl-devel@bestbits.at, linux-xfs@oss.sgi.org.sgi.com Subject: Re: default acl inheritence bug Message-ID: <20020426041111.F21791@plato.local.lan> References: <20020417011517.G20630@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xkXJwpr35CY/Lc3I" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ag@bestbits.at on Thu, Apr 25, 2002 at 02:51:49PM +0200 X-OS: Debian GNU Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --xkXJwpr35CY/Lc3I Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 25, 2002 at 02:51:49PM +0200, Andreas Gruenbacher wrote: > So this is the promised response to the suspected inheritance bug. To > reestablish the contect, here is Ethan's original posting: >=20 >=20 > On Wed, 17 Apr 2002, Ethan Benson wrote: > > > > i am trying to set a default acl to allow a user read permission to > > files created. > > > > so do: > > > > root@ash:/var/log/apache# setfacl -dm u:webstats:r-- . > > > > which renders: > > > > root@ash:/var/log/apache# getfacl . > > # file: . > > # owner: root > > # group: root > > user::rwx > > group::r-x > > other::r-x > > default:user::rwx > > default:user:webstats:r-- > > default:group::r-x > > default:mask::r-x > > default:other::r-x > > > > > > and then touch foo and get its permissions: > > > > root@ash:/var/log/apache# touch foo > > root@ash:/var/log/apache# getfacl foo > > # file: foo > > # owner: root > > # group: root > > user::rw- > > user:webstats:r-x #effective:r-- > > group::r-x #effective:r-- > > mask::r-- > > other::r-- > > > > why is the group and webstats user being given execute permission? > > (yes i know the mask revokes it, its still wrong and i don't want any > > user/group to have an x bit on *files*) > > > > when creating a file no execute bits should be set for anyone, why > > does this not work correctly? note this test is done on the SGI > > 2.4.18 XFS split patches. with acl 2.0.8. >=20 > Either something has gone wrong on your example above, or there is indeed > a bug in the XFS ACL implementation. No execute bit for user webstats > should ever spring into existence like this. i fiddled around with it for well over an hour trying to stop this behavior, i am quite certain about the above results (which are copy/pasted directly from my tty). in between tests i always completly stripped the acls with setfacl -b and verified that even the system.*acl* attrs were removed with getfattr -m . >=20 > In this particular situation, the correct ACL of the file foo would be: >=20 > $ getfacl foo > # file: foo > # owner: ag > # group: users > user::rw- > user:webstats:r-- > group::r-x #effective:r-- > mask::r-- > other::r-- >=20 > Ethan, could you please verify that this is what actually happens? > Otherwise, we should indeed file a bug report. i already verified it umteen times before i finally mailed you asking wtf was going on. >=20 > Apart from that, the usual permissions for users/groups who shall get > read/search access to a directory tree are `r-x' (and `rwx' for > read/write/search access), however. This allows users also to > search/change into directories created. yes the behavior on directories is exactly as i would expect. > As you have observed, the effective permissions are automatically > restricted by the mode parameter specified when creating > files/directories. Usually, this mode parameter is 666 for files, and 777 > for directories. It is alright to rely on the ACL mask entry to mask off > permissions. ok perhaps, but it seems wrong and hackish IMO. > This is what you would usually do/get: >=20 > $ mkdir dir > $ setfacl -m u:webstats:rx dir > $ setfacl -dm u:webstats:rx dir > $ getfacl dir > # file: dir > # owner: ag > # group: users > user::rwx > user:webstats:r-x > group::r-x > mask::r-x > other::r-x > default:user::rwx > default:user:webstats:r-x > default:group::r-x > default:mask::r-x > default:other::r-x >=20 > $ touch dir/file > $ getfacl dir/file > # file: dir/file > # owner: ag > # group: users > user::rw- > user:webstats:r-x #effective:r-- > group::r-x #effective:r-- > mask::r-- > other::r-- you get the same results as me, user webstats anomolously getting execute permission. > $ touch dir/subdir > $ getfacl dir/subdir > # file: dir/subdir > # owner: ag > # group: users > user::rwx > user:webstats:r-x > group::r-x > mask::r-x > other::r-x > default:user::rwx > default:user:webstats:r-x > default:group::r-x > default:mask::r-x > default:other::r-x this is what i get for directories as well, and i find this normal. its the file behavior which is wrong IMO. >=20 > The design alternative of removing all permissions from all ACL entries > that are not contained in the create mode would yield this result: >=20 > $ getfacl dir/file [ does not represent the implemented behavior! ] > # file: dir/file > # owner: ag > # group: users > user::rw- > user:webstats:r-- > group::r-- > mask::r-- > other::r-- this is what i expected. > This would introduce order dependencies on setting permissions, and lead > to unexpected results for non-ACL-aware applications. The following two > sequences of C commands would yield different ACLs on binary_file: >=20 > fd =3D open("binary_file", O_CREAT, 0755); > write(fd, buffer, size); > fchmod(fd, 0755); > close(fd); in this example the fchmod call is unnecessary and redundant, and would not break/change anything as i understand it. > fd =3D open("binary_file", O_CREAT, 0644); > write(fd, buffer, size); > fchmod(fd, 0755); > close(fd); i would consider this code broken. > One of the goals of POSIX ACLs is to retain compatibility with legacy > POSIX systems as far as possible. This is why the first approach was > chosen. but you are only partially working around this alleged problem, since if you say the fact that the webstats user above is getting execute permissions is wrong, then it will still be left without execute permissions after the above code examples perform chmod 755. > Another benefit of this approach is that it's possible to have only one > default ACL, for producing the desired permissions for files as well as > for directories that are created. Other systems with POSIX-like ACLs have > a default ACL for non-directories, and another default directory ACL. On > those systems, non-directories inherit the default ACL, and directories > inherit the default directory ACL. that system seems more flexible. >=20 > > looking at your examples the behavior im observing does indeed seem > > anomalous, should i report this to the XFS folks? >=20 > Yes, the example you gave does indeed look suspicious. I'm sure if your > example is correct the XFS folks will fix this in no time :-) >=20 > [Btw, I have corrected an error in > while writing this response...] my problem with this is i am *extremely* picky about permissions, in particular i believe that files should never ever have ANY execute permission bits unless its really an executable, so the fact that files are getting effectivly mode 654 instead of the correct 644 bothers me a great deal. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --xkXJwpr35CY/Lc3I 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 iEYEARECAAYFAjzJQ94ACgkQJKx7GixEevz6hACeLtc6UgBR4PRj9S75rx3pjann MawAn1QL+qqqV4GzUUuPczFJ9fp0hYOV =p8c1 -----END PGP SIGNATURE----- --xkXJwpr35CY/Lc3I-- From owner-linux-xfs@oss.sgi.com Fri Apr 26 05:50:50 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QCoowJ008173 for ; Fri, 26 Apr 2002 05:50:50 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QCooZK008172 for linux-xfs-outgoing; Fri, 26 Apr 2002 05:50:50 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QCogwJ008138 for ; Fri, 26 Apr 2002 05:50:42 -0700 Received: from mailgate4.nec.co.jp ([10.7.69.197]) by TYO201.gate.nec.co.jp (8.11.6/3.7W01080315) with ESMTP id g3QCpBV12498 for ; Fri, 26 Apr 2002 21:51:11 +0900 (JST) Received: from mailsv4.nec.co.jp (mailgate51.nec.co.jp [10.7.69.196]) by mailgate4.nec.co.jp (8.11.6/3.7W-MAILGATE-NEC) with ESMTP id g3QCpBR15308 for ; Fri, 26 Apr 2002 21:51:11 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp (THKTNES98740.tnes.nec.co.jp [10.1.101.4]) by mailsv4.nec.co.jp (8.11.6/3.7W-MAILSV4-NEC) with ESMTP id g3QCpAr26161 for ; Fri, 26 Apr 2002 21:51:10 +0900 (JST) Received: from thktnes98740.tnes.nec.co.jp ([10.1.101.4]) by thktnes98740.tnes.nec.co.jp (Post.Office MTA v3.1.2J release 205-101A-J ID# 0-0U10L2S100) with SMTP id AAA454 for ; Fri, 26 Apr 2002 21:51:08 +0900 Received: FROM mailsv.tnes.nec.co.jp BY thktnes98740.tnes.nec.co.jp ; Fri Apr 26 21:51:08 2002 +0900 Received: from rifu.bsd.tnes.nec.co.jp (IDENT:root@rifu.bsd.tnes.nec.co.jp [10.1.104.1]) by mailsv.tnes.nec.co.jp (8.11.6/3.7W01031510) with ESMTP id g3QCp9648086 for ; Fri, 26 Apr 2002 21:51:09 +0900 (JST) Received: from localhost (IDENT:masano@noshiro.bsd.tnes.nec.co.jp [10.1.104.24]) by rifu.bsd.tnes.nec.co.jp (8.10.2+3.3W/3.7W/BSD-TNES-MX01) with ESMTP id g3QCp9O31128 for ; Fri, 26 Apr 2002 21:51:09 +0900 To: linux-xfs@oss.sgi.com Subject: xfsdump correction request X-Mailer: Mew version 1.94.2 on XEmacs 21.4 (Common Lisp) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Apr_26_21:51:07_2002_969)--" Content-Transfer-Encoding: 7bit Message-Id: <20020426215109O.masano@tnes.nec.co.jp> Date: Fri, 26 Apr 2002 21:51:09 +0900 (JST) From: ASANO Masahiro X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk ----Next_Part(Fri_Apr_26_21:51:07_2002_969)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I found a minor bug in xfsdump command and fixed it. o "xfsdump -I mobjid=" causes segmentation fault. -- Masano ----Next_Part(Fri_Apr_26_21:51:07_2002_969)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=patch-xfsdump Index: cmd/xfsdump/inventory/inv_api.c =================================================================== RCS file: /usr/localmnt/xfs/cvsroot/linux-2.4-xfs/cmd/xfsdump/inventory/inv_api.c,v retrieving revision 1.3 diff -u -r1.3 inv_api.c --- cmd/xfsdump/inventory/inv_api.c 2001/09/28 09:49:27 1.3 +++ cmd/xfsdump/inventory/inv_api.c 2002/04/26 12:18:22 @@ -941,9 +941,9 @@ { uuid_t *u; u = malloc ( sizeof( uuid_t ) ); - uuid_unparse(value, *u); + uuid_parse(value, *u); prctx->mobj.type = INVT_MOID; - uuid_copy(prctx->mobj.value, *u); + prctx->mobj.value = (void *)u; } npreds2++; break; ----Next_Part(Fri_Apr_26_21:51:07_2002_969)---- From owner-linux-xfs@oss.sgi.com Fri Apr 26 06:27: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 g3QDRjwJ009255 for ; Fri, 26 Apr 2002 06:27:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QDRjBs009254 for linux-xfs-outgoing; Fri, 26 Apr 2002 06:27:45 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from janus.hosting4u.net (janus.hosting4u.net [209.15.2.37]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QDRfwJ009228 for ; Fri, 26 Apr 2002 06:27:41 -0700 Received: (qmail 29531 invoked from network); 26 Apr 2002 13:28:15 -0000 Received: from capricornus.hosting4u.net (HELO stewartsigns.com) (209.15.2.36) by mail-gate.hosting4u.net with SMTP; 26 Apr 2002 13:28:15 -0000 Received: from mikerock ([192.216.210.79]) by stewartsigns.com ; Fri, 26 Apr 2002 08:28:13 -0500 From: "Mikes work account" To: Subject: performance patches Date: Fri, 26 Apr 2002 09:30:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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 V6.00.2600.0000 X-Rcpt-To: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I received an email from Paul Schutte that referred to some performance patches for 2.4.9-31SGI_XFS_1.1smp. Can anyone be more specific. Are there any writeups on this? Michael C. Rock JM Stewart Corp From owner-linux-xfs@oss.sgi.com Fri Apr 26 06:46:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QDkbwJ009540 for ; Fri, 26 Apr 2002 06:46:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QDkba5009539 for linux-xfs-outgoing; Fri, 26 Apr 2002 06:46:37 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QDkWwJ009513 for ; Fri, 26 Apr 2002 06:46:32 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id IAA51493; Fri, 26 Apr 2002 08:47: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 IAA71023; Fri, 26 Apr 2002 08:47:01 -0500 (CDT) Date: Fri, 26 Apr 2002 08:47:00 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mikes work account cc: linux-xfs@oss.sgi.com Subject: Re: performance patches 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 Paul send the same patch to the list recently; it's on the list of things to look at. Can you follow up with the questions from yesterday; i.e. what sort of storage are you using, etc? -Eric On Fri, 26 Apr 2002, Mikes work account wrote: > I received an email from Paul Schutte that referred to some performance > patches for 2.4.9-31SGI_XFS_1.1smp. Can anyone be more specific. Are there > any writeups on this? > > Michael C. Rock > JM Stewart Corp > -- 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 26 06:47:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QDlPwJ009649 for ; Fri, 26 Apr 2002 06:47:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QDlOr9009648 for linux-xfs-outgoing; Fri, 26 Apr 2002 06:47:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from kendy2.up.ac.za (kendy2.up.AC.za [137.215.94.33]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QDlIwJ009603 for ; Fri, 26 Apr 2002 06:47:20 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy2.up.ac.za with esmtp (Exim 3.35 #1) id 1715yn-0003O8-00; Fri, 26 Apr 2002 15:41:41 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 1715ym-0002YE-00; Fri, 26 Apr 2002 15:41:40 +0200 Message-ID: <3CC95914.C4571235@up.ac.za> Date: Fri, 26 Apr 2002 15:41:40 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-ifix-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Mikes work account CC: linux-xfs@oss.sgi.com Subject: Re: performance patches References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1715ym-0002YE-00*4ffCs1rAhuQ* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I refered to improvements made since XFS 1.0.2 and XFS 1.1 Paul Mikes work account wrote: > I received an email from Paul Schutte that referred to some performance > patches for 2.4.9-31SGI_XFS_1.1smp. Can anyone be more specific. Are there > any writeups on this? > > Michael C. Rock > JM Stewart Corp From owner-linux-xfs@oss.sgi.com Fri Apr 26 06:57: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 g3QDvDwJ009929 for ; Fri, 26 Apr 2002 06:57:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QDvDo1009928 for linux-xfs-outgoing; Fri, 26 Apr 2002 06:57:13 -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 g3QDv2wJ009902 for ; Fri, 26 Apr 2002 06:57:06 -0700 Received: from kendy2.up.ac.za (kendy2.up.AC.za [137.215.94.33]) 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 GAA08509 for ; Fri, 26 Apr 2002 06:57:09 -0700 (PDT) mail_from (paul@up.ac.za) Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy2.up.ac.za with esmtp (Exim 3.35 #1) id 17168Z-0003hd-00; Fri, 26 Apr 2002 15:51:47 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 17168Y-00089B-00; Fri, 26 Apr 2002 15:51:46 +0200 Message-ID: <3CC95B72.2E16ADDA@up.ac.za> Date: Fri, 26 Apr 2002 15:51:46 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-ifix-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Mikes work account , linux-xfs@oss.sgi.com Subject: Re: performance patches References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *17168Y-00089B-00*dR2UCaXgIJs* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Paul send the same patch to the list recently; it's on the list of things > to look at. > > Can you follow up with the questions from yesterday; i.e. what sort of > storage are you using, etc? > > -Eric > That's not what I recommended to him. Here is my mail to him. I don't know what I have break with that patch that I send in and would rather have SGI guys test is first. >Don't bother with the xfs_info output. >Backup your data and then recreate the filesystems with the following: >mkfs.xfs -l size=8192b /dev/sdb5 >mkfs.xfs -l size=8192b /dev/sdb6 >change the lines in your fstab to >/dev/sdb5 /miketest xfs exec,dev,suid,rw,logbufs=8 1 1 >/dev/sdb6 /apps2 xfs exec,dev,suid,rw,logbufs=8 1 1 >I would very strongly suggest that you update your kernel to one of these >ftp://oss.sgi.com/projects/xfs/download/latest/kernel_rpms/2.4.9-31-RH/ >(Remember to update your xfsprogs as well.) >there is a few updates that helps performance. From owner-linux-xfs@oss.sgi.com Fri Apr 26 07:00: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 g3QE0nwJ010129 for ; Fri, 26 Apr 2002 07:00:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QE0nGO010128 for linux-xfs-outgoing; Fri, 26 Apr 2002 07:00: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 g3QE0iwJ010101 for ; Fri, 26 Apr 2002 07:00:44 -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 JAA39679; Fri, 26 Apr 2002 09:01:13 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id JAA70847; Fri, 26 Apr 2002 09:01:13 -0500 (CDT) Date: Fri, 26 Apr 2002 09:01:13 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Paul Schutte cc: Mikes work account , Subject: Re: performance patches In-Reply-To: <3CC95B72.2E16ADDA@up.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Ah, I stand corrected. And we're not ignoring that other patch, just backlogged! Thanks, -Eric On Fri, 26 Apr 2002, Paul Schutte wrote: > That's not what I recommended to him. > > Here is my mail to him. > I don't know what I have break with that patch that I send in and would rather > have SGI guys test is first. -- 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 26 07:09: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 g3QE9MwJ010359 for ; Fri, 26 Apr 2002 07:09:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QE9Moh010358 for linux-xfs-outgoing; Fri, 26 Apr 2002 07:09:22 -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 g3QE9GwJ010331 for ; Fri, 26 Apr 2002 07:09:16 -0700 Received: from kendy2.up.ac.za (kendy2.up.AC.za [137.215.94.33]) 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 HAA05815 for ; Fri, 26 Apr 2002 07:09:30 -0700 (PDT) mail_from (paul@up.ac.za) Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy2.up.ac.za with esmtp (Exim 3.35 #1) id 1716Pj-0004HA-00; Fri, 26 Apr 2002 16:09:31 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 1716Pi-0007Dh-00; Fri, 26 Apr 2002 16:09:30 +0200 Message-ID: <3CC95F9A.91A4F784@up.ac.za> Date: Fri, 26 Apr 2002 16:09:30 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-ifix-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Mikes work account , linux-xfs@oss.sgi.com Subject: Re: performance patches References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1716Pi-0007Dh-00*lRcta4ClZ46* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Is there a good reason for having the logsize=1200b by default ? I have found that it almost alway causes slowdown under heavy I/O. Can't we make it 8192b (32Mb) by default. 27968 kb is not much to sacrifice. It will help people that have no experience with XFS to go fast out of the box. Paul Eric Sandeen wrote: > Ah, I stand corrected. And we're not ignoring that other patch, just > backlogged! > > Thanks, > > -Eric > > On Fri, 26 Apr 2002, Paul Schutte wrote: > > > That's not what I recommended to him. > > > > Here is my mail to him. > > I don't know what I have break with that patch that I send in and would rather > > have SGI guys test is first. > > -- > 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 26 07:30:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QEU9wJ010705 for ; Fri, 26 Apr 2002 07:30:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QEU9hN010704 for linux-xfs-outgoing; Fri, 26 Apr 2002 07:30:09 -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 g3QEU1wJ010671 for ; Fri, 26 Apr 2002 07:30:02 -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 JAA57941; Fri, 26 Apr 2002 09:30:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA12812; Fri, 26 Apr 2002 09:30:30 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3QEULt24438; Fri, 26 Apr 2002 09:30:21 -0500 Subject: Re: performance patches From: Steve Lord To: Paul Schutte Cc: Eric Sandeen , Mikes work account , linux-xfs@oss.sgi.com In-Reply-To: <3CC95F9A.91A4F784@up.ac.za> References: <3CC95F9A.91A4F784@up.ac.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 26 Apr 2002 09:30:21 -0500 Message-Id: <1019831421.23258.16.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-26 at 09:09, Paul Schutte wrote: > Is there a good reason for having the logsize=1200b by default ? > > I have found that it almost alway causes slowdown under heavy I/O. > > Can't we make it 8192b (32Mb) by default. > 27968 kb is not much to sacrifice. > It will help people that have no experience with XFS to go fast out of the box. > > Paul > If you are putting xfs on a disk and not using it for I/O intensive operations, then a smaller log is all you need. There is a cost associated with a larger log - longer mount times even when the filesystem was cleanly unmounted. The default size does grow with larger filesystems, but I think they need to be pretty big before that kicks in. The sizing is more an Irix thing than a linux one - I think it does not kick in until 1 Tbyte. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Apr 26 08:01: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 g3QF1nwJ011293 for ; Fri, 26 Apr 2002 08:01:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QF1nAr011292 for linux-xfs-outgoing; Fri, 26 Apr 2002 08:01:49 -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 g3QF1gwJ011266 for ; Fri, 26 Apr 2002 08:01:42 -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 g3QEvR3u020622; Fri, 26 Apr 2002 10:57:27 -0400 Received: (from tls@localhost) by pla-muek.reefedge.com (8.11.6/8.11.6) id g3QF2F029725; Fri, 26 Apr 2002 11:02:15 -0400 (EDT) Date: Fri, 26 Apr 2002 11:02:15 -0400 From: Thor Lancelot Simon To: Steve Lord Cc: linux-xfs@oss.sgi.com Subject: Re: performance patches Message-ID: <20020426110215.A29694@pla-muek.reefedge.com> References: <3CC95F9A.91A4F784@up.ac.za> <1019831421.23258.16.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1019831421.23258.16.camel@jen.americas.sgi.com>; from lord@sgi.com on Fri, Apr 26, 2002 at 09:30:21AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Apr 26, 2002 at 09:30:21AM -0500, Steve Lord wrote: > > If you are putting xfs on a disk and not using it for I/O intensive > operations, then a smaller log is all you need. There is a cost > associated with a larger log - longer mount times even when the > filesystem was cleanly unmounted. > > The default size does grow with larger filesystems, but I think they > need to be pretty big before that kicks in. The sizing is more an Irix > thing than a linux one - I think it does not kick in until 1 Tbyte. According to the Irix 6.5.13 announcement: Improved exit codes for the xfsrestore and xfsdump commands. Changed the mkfs command to allow you to specify the size of an XFS allocation group, as an alternative to specifying the total number of allocation groups. Changed the mkfs command to allow you to specify the size of a stripe unit and the size of a stripe width in bytes or in filesystem blocks, as an alternative to specifying these values in 512-byte block units. Changed the default size of an XFS allocation group; larger filesystems will result in larger default allocation group sizes. The xfsdump and xfsrestore commands will provide the VSN of the tape that reached its end-of-volume (or the VSN of a new tape that needs to be mounted) and pass this VSN to the media_change_alert_program specified with the -c option. Changed the default size of an XFS log. The default log size grows with the size of the filesystem up to the maximum log size, 128 megabytes, on a 1 terabyte filesystem. Thor From owner-linux-xfs@oss.sgi.com Fri Apr 26 08:49: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 g3QFn6wJ012512 for ; Fri, 26 Apr 2002 08:49:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QFn6JC012511 for linux-xfs-outgoing; Fri, 26 Apr 2002 08:49:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from kendy2.up.ac.za (kendy2.up.AC.za [137.215.94.33]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QFmrwJ012472 for ; Fri, 26 Apr 2002 08:48:55 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy2.up.ac.za with esmtp (Exim 3.35 #1) id 1717y2-0006ka-00; Fri, 26 Apr 2002 17:49:02 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 1717y1-0003AW-00; Fri, 26 Apr 2002 17:49:01 +0200 Message-ID: <3CC976ED.2C947B0F@up.ac.za> Date: Fri, 26 Apr 2002 17:49:01 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-ifix-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Thor Lancelot Simon CC: Steve Lord , linux-xfs@oss.sgi.com Subject: Re: performance patches References: <3CC95F9A.91A4F784@up.ac.za> <1019831421.23258.16.camel@jen.americas.sgi.com> <20020426110215.A29694@pla-muek.reefedge.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1717y1-0003AW-00*Ya7Agq/FL.g* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I know that it grows with the size, but the rate is much too slow. If you create a 2Gb filesystem, you will have a 1200b log. If you create a 64Gb filesystem, you still have the same 1200b log. (That was still the case when a have set up my mailserver a month ago). If you have 80 clients logging in on a 8Gb partition as in his case, you can be sure to have your performance limited by your 1200b log. 1200b is good for a workstation, not for a high performance server. How was he suppose to know that. The size of the filesystem does not matter as much as the amount of I/O that you expect, as Steve pointed out. Larger filesystems obviously have potential for more I/O. Maybe I put this a bit harsh, but I am trying to defend XFS's honour. All the people that I encountered that said XFS's performace sucks, used the default log size. After corrrecting their mistake, they were impressed by XFS. I bet that we have lost a lot of people because of a too small log size. Paul Thor Lancelot Simon wrote: > On Fri, Apr 26, 2002 at 09:30:21AM -0500, Steve Lord wrote: > > > > If you are putting xfs on a disk and not using it for I/O intensive > > operations, then a smaller log is all you need. There is a cost > > associated with a larger log - longer mount times even when the > > filesystem was cleanly unmounted. > > > > The default size does grow with larger filesystems, but I think they > > need to be pretty big before that kicks in. The sizing is more an Irix > > thing than a linux one - I think it does not kick in until 1 Tbyte. > > According to the Irix 6.5.13 announcement: > > Improved exit codes for the xfsrestore and xfsdump commands. > > Changed the mkfs command to allow you to specify the size of an XFS > allocation group, as an alternative to specifying the total > number of allocation groups. > > Changed the mkfs command to allow you to specify the size of a > stripe unit and the size of a stripe width in bytes or in > filesystem blocks, as an alternative to specifying these values > in 512-byte block units. > > Changed the default size of an XFS allocation group; larger > filesystems will result in larger default allocation group sizes. > > The xfsdump and xfsrestore commands will provide the VSN of the > tape that reached its end-of-volume (or the VSN of a new tape > that needs to be mounted) and pass this VSN to the > media_change_alert_program specified with the -c option. > > Changed the default size of an XFS log. The default log size > grows with the size of the filesystem up to the maximum log > size, 128 megabytes, on a 1 terabyte filesystem. > > Thor From owner-linux-xfs@oss.sgi.com Fri Apr 26 08:53: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 g3QFrHwJ012735 for ; Fri, 26 Apr 2002 08:53:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QFrHg6012734 for linux-xfs-outgoing; Fri, 26 Apr 2002 08:53: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 g3QFrBwJ012707 for ; Fri, 26 Apr 2002 08:53:11 -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 KAA55567; Fri, 26 Apr 2002 10:53:41 -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 KAA92796; Fri, 26 Apr 2002 10:53:40 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3QFrV128075; Fri, 26 Apr 2002 10:53:31 -0500 Subject: Re: performance patches From: Steve Lord To: Paul Schutte Cc: Thor Lancelot Simon , linux-xfs@oss.sgi.com In-Reply-To: <3CC976ED.2C947B0F@up.ac.za> References: <3CC95F9A.91A4F784@up.ac.za> <1019831421.23258.16.camel@jen.americas.sgi.com> <20020426110215.A29694@pla-muek.reefedge.com> <3CC976ED.2C947B0F@up.ac.za> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 26 Apr 2002 10:53:31 -0500 Message-Id: <1019836411.23298.33.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-26 at 10:49, Paul Schutte wrote: > I know that it grows with the size, but the rate is much too slow. > If you create a 2Gb filesystem, you will have a 1200b log. > If you create a 64Gb filesystem, you still have the same 1200b log. > (That was still the case when a have set up my mailserver a month > ago). > > If you have 80 clients logging in on a 8Gb partition as in his case, > you can be sure to have your performance limited by your > 1200b log. > 1200b is good for a workstation, not for a high performance server. > How was he suppose to know that. > > The size of the filesystem does not matter as much as the amount > of I/O that you expect, as Steve pointed out. > Larger filesystems obviously have potential for more I/O. > > Maybe I put this a bit harsh, but I am trying to defend XFS's honour. > All the people that I encountered that said XFS's performace sucks, > used the default log size. > After corrrecting their mistake, they were impressed by XFS. > I bet that we have lost a lot of people because of a too small > log size. > > Paul > There is a new batch of mkfs changes coming down the pipe, when we merge this over I will play with the default mkfs sizes. And if someone can make xfs_growfs work on the log there is a case of virtual beer in it for them ;-) That is the ultimate solution here. Steve -- Steve Lord voice: +1-651-683-3511 Principal Engineer, Filesystem Software email: lord@sgi.com From owner-linux-xfs@oss.sgi.com Fri Apr 26 09:02:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QG2QwJ013005 for ; Fri, 26 Apr 2002 09:02:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QG2QBl013004 for linux-xfs-outgoing; Fri, 26 Apr 2002 09:02:26 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from kendy2.up.ac.za (kendy2.up.AC.za [137.215.94.33]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QG2FwJ012966 for ; Fri, 26 Apr 2002 09:02:17 -0700 Received: from [137.215.95.15] (helo=mx1.up.ac.za) by kendy2.up.ac.za with esmtp (Exim 3.35 #1) id 1718B5-0006yE-00; Fri, 26 Apr 2002 18:02:31 +0200 Received: from tzone.up.ac.za ([137.215.145.210] helo=up.ac.za) by mx1.up.ac.za with esmtp (Exim 3.12 #1) id 1718B4-0005Ee-00; Fri, 26 Apr 2002 18:02:30 +0200 Message-ID: <3CC97A16.63A0151A@up.ac.za> Date: Fri, 26 Apr 2002 18:02:30 +0200 From: Paul Schutte X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-xfs-ifix-tzone i686) X-Accept-Language: en MIME-Version: 1.0 To: Steve Lord CC: Thor Lancelot Simon , linux-xfs@oss.sgi.com Subject: Re: performance patches References: <3CC95F9A.91A4F784@up.ac.za> <1019831421.23258.16.camel@jen.americas.sgi.com> <20020426110215.A29694@pla-muek.reefedge.com> <3CC976ED.2C947B0F@up.ac.za> <1019836411.23298.33.camel@jen.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Scanner: exiscan *1718B4-0005Ee-00*eePvhOfxdd.* (University of Pretoria, South Africa) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Steve Lord wrote: > On Fri, 2002-04-26 at 10:49, Paul Schutte wrote: > > I know that it grows with the size, but the rate is much too slow. > > If you create a 2Gb filesystem, you will have a 1200b log. > > If you create a 64Gb filesystem, you still have the same 1200b log. > > (That was still the case when a have set up my mailserver a month > > ago). > > > > If you have 80 clients logging in on a 8Gb partition as in his case, > > you can be sure to have your performance limited by your > > 1200b log. > > 1200b is good for a workstation, not for a high performance server. > > How was he suppose to know that. > > > > The size of the filesystem does not matter as much as the amount > > of I/O that you expect, as Steve pointed out. > > Larger filesystems obviously have potential for more I/O. > > > > Maybe I put this a bit harsh, but I am trying to defend XFS's honour. > > All the people that I encountered that said XFS's performace sucks, > > used the default log size. > > After corrrecting their mistake, they were impressed by XFS. > > I bet that we have lost a lot of people because of a too small > > log size. > > > > Paul > > > > There is a new batch of mkfs changes coming down the pipe, when we merge > this over I will play with the default mkfs sizes. And if someone can > make xfs_growfs work on the log there is a case of virtual beer in it > for them ;-) That is the ultimate solution here. > > Steve > > -- > > Steve Lord voice: +1-651-683-3511 > Principal Engineer, Filesystem Software email: lord@sgi.com I do not know what is best. The quality of the product or the quality of service/people. Thanx GUYS you are the best. Paul From owner-linux-xfs@oss.sgi.com Fri Apr 26 09:17:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QGHKwJ014138 for ; Fri, 26 Apr 2002 09:17:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QGHKt4014137 for linux-xfs-outgoing; Fri, 26 Apr 2002 09:17:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QGHFwJ014096 for ; Fri, 26 Apr 2002 09:17:15 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id LAA53098; Fri, 26 Apr 2002 11:17:44 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id LAA39118; Fri, 26 Apr 2002 11:17:44 -0500 (CDT) Subject: Re: [Samba] Re: Can't get samba 2.2.3a to compile with ACL support (with logs) From: Eric Sandeen To: Chris Tooley Cc: Nathan Scott , samba@lists.samba.org, linux-xfs@oss.sgi.com In-Reply-To: <1019783363.1957.15.camel@itspec.amoa.org> References: <1019766178.1958.12.camel@itspec.amoa.org> <1019766533.8353.109.camel@jen.americas.sgi.com> <20020426100315.A80513@wobbly.melbourne.sgi.com> <1019783363.1957.15.camel@itspec.amoa.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Apr 2002 11:17:44 -0500 Message-Id: <1019837864.29093.2.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, 2002-04-25 at 20:09, Chris Tooley wrote: > Do you have a ball park when 2.0.10 will roll out or possibly a 2.0.9a? They're on oss now, SRPMS and x86 RPMS; ia64 will follow shortly. -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 26 11:25: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 g3QIPTwJ020467 for ; Fri, 26 Apr 2002 11:25:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QIPTHN020466 for linux-xfs-outgoing; Fri, 26 Apr 2002 11:25:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.trustium.com (adsl-64-165-6-11.dsl.sndg02.pacbell.net [64.165.6.11]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QIPOwJ020440 for ; Fri, 26 Apr 2002 11:25:24 -0700 Received: by adsl-64-165-6-11.dsl.sndg02.pacbell.net with Internet Mail Service (5.5.2653.19) id ; Fri, 26 Apr 2002 11:18:10 -0700 Message-ID: <44D5677E9B8478468DE31AE26DF0AFD6077C9F@adsl-64-165-6-11.dsl.sndg02.pacbell.net> From: Adam Milazzo To: "'Nathan Scott'" Cc: "'linux-xfs@oss.sgi.com'" Subject: RE: libxfs documentation Date: Fri, 26 Apr 2002 11:18:06 -0700 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 Gotcha, thanks :) I needed to write low-level, one-shot utility, but I was able to do what I needed with open(), lseek64(), and read() on the device node. Thanks again, Adam M. -----Original Message----- From: Nathan Scott [mailto:nathans@sgi.com] Sent: Thursday, April 25, 2002 5:09 PM To: Adam Milazzo Cc: 'linux-xfs@oss.sgi.com' Subject: Re: libxfs documentation On Thu, Apr 25, 2002 at 11:38:42AM -0700, Adam Milazzo wrote: > Is there any documentation available for libxfs besides the source code > itself? Surely there has to be some documentation, if only internal, I would > think. Does anybody know where and if something like this is available? I > haven't been able to find any... There is none. libxfs == select bits of XFS kernel code compiled in userspace; for xfs_repair, mkfs.xfs and xfs_db only, it is not intended as a general purpose library. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Fri Apr 26 12:04:12 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QJ4CwJ021921 for ; Fri, 26 Apr 2002 12:04:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QJ4CEY021920 for linux-xfs-outgoing; Fri, 26 Apr 2002 12:04:12 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QJ47wJ021888 for ; Fri, 26 Apr 2002 12:04:07 -0700 Received: from umbi.umd.edu ([129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GV6VPD00.D93 for ; Fri, 26 Apr 2002 15:05:37 -0400 Message-ID: <3CC9A4C9.9CA9A27A@umbi.umd.edu> Date: Fri, 26 Apr 2002 15:04:41 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Linux XFS Mailing List Subject: Red Hat 7.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm getting ready to upgrade a bunch of Red Hat 7.0 systems and I wondered: Has anyone got XFS kernel and xfsprogs to work on Red Hat 7.0? If it isn't too much of a pain, I might try to "convert" all of the filesystems before the upgrade rather than having to back everything up. I suppose I could just copy "/" then make a new XFS during the install, but then I have to port in any non-RPM software and settings from the old root files. Then I could "convert" the rest of the filesystems after the upgrade. Or maybe I could hack the install CD to have the tools executable off the CD, make a clean XFS, then copy the root back to the new fs. Thinking out loud, -- "Jonathan F. Dill" (dill@umbi.umd.edu) UMBI CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Fri Apr 26 12:14: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 g3QJELwJ022452 for ; Fri, 26 Apr 2002 12:14:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QJELZa022451 for linux-xfs-outgoing; Fri, 26 Apr 2002 12:14:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QJEFwJ022420 for ; Fri, 26 Apr 2002 12:14:15 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA61483; Fri, 26 Apr 2002 14:14:45 -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 OAA87015; Fri, 26 Apr 2002 14:14:45 -0500 (CDT) Subject: Re: Red Hat 7.0 From: Eric Sandeen To: Jonathan Dill Cc: Linux XFS Mailing List In-Reply-To: <3CC9A4C9.9CA9A27A@umbi.umd.edu> References: <3CC9A4C9.9CA9A27A@umbi.umd.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Apr 2002 14:14:45 -0500 Message-Id: <1019848485.30784.17.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Jonathan - Not quite sure what you're asking, are the 7.0 systems ext2-based? FWIW, the XFS installer CD already has executable tools - you could either boot it in "rescue" mode to get a shell and make filesystems, or during the install, you can alt-F* to the console which has the shell. -Eric On Fri, 2002-04-26 at 14:04, Jonathan Dill wrote: > I'm getting ready to upgrade a bunch of Red Hat 7.0 systems and I > wondered: Has anyone got XFS kernel and xfsprogs to work on Red Hat > 7.0? If it isn't too much of a pain, I might try to "convert" all of > the filesystems before the upgrade rather than having to back everything > up. > > I suppose I could just copy "/" then make a new XFS during the install, > but then I have to port in any non-RPM software and settings from the > old root files. Then I could "convert" the rest of the filesystems > after the upgrade. Or maybe I could hack the install CD to have the > tools executable off the CD, make a clean XFS, then copy the root back > to the new fs. -- 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 26 12:20: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 g3QJKTwJ022701 for ; Fri, 26 Apr 2002 12:20:29 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QJKTtK022700 for linux-xfs-outgoing; Fri, 26 Apr 2002 12:20:29 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from umbi3.umbi.umd.edu (umbi3.umbi.umd.edu [136.160.7.51]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QJKPwJ022672 for ; Fri, 26 Apr 2002 12:20:25 -0700 Received: from umbi.umd.edu ([129.6.113.5]) by umbi3.umbi.umd.edu (Netscape Messaging Server 4.15) with ESMTP id GV6WGJ00.9CJ; Fri, 26 Apr 2002 15:21:55 -0400 Message-ID: <3CC9A89B.9D89D7E8@umbi.umd.edu> Date: Fri, 26 Apr 2002 15:20:59 -0400 From: Jonathan Dill Organization: CARB X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i686) X-Accept-Language: en MIME-Version: 1.0 To: Eric Sandeen CC: Linux XFS Mailing List Subject: Re: Red Hat 7.0 References: <3CC9A4C9.9CA9A27A@umbi.umd.edu> <1019848485.30784.17.camel@stout.americas.sgi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Eric Sandeen wrote: > Not quite sure what you're asking, are the 7.0 systems ext2-based? The 7.0 systems are ext2-based. I wanted to know if I could install an XFS kernel and xfsprogs in Red Hat 7.0 and boot up an XFS kernel, but still in Red Hat 7.0. Then I can do a lot of the prep work "behind the scenes" while the systems are still running Red Hat 7.0. Then I'll just have the root fs to contend with during the install. > FWIW, the XFS installer CD already has executable tools - you could > either boot it in "rescue" mode to get a shell and make filesystems, or > during the install, you can alt-F* to the console which has the shell. -- "Jonathan F. Dill" (dill@umbi.umd.edu) UMBI CARB IT Coordinator Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Fri Apr 26 12:25:22 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QJPMwJ022992 for ; Fri, 26 Apr 2002 12:25:22 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QJPMOD022991 for linux-xfs-outgoing; Fri, 26 Apr 2002 12:25:22 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QJPHwJ022957 for ; Fri, 26 Apr 2002 12:25:17 -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 OAA59593; Fri, 26 Apr 2002 14:25:47 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id OAA86273; Fri, 26 Apr 2002 14:25:47 -0500 (CDT) Subject: Re: Red Hat 7.0 From: Eric Sandeen To: Jonathan Dill Cc: Linux XFS Mailing List In-Reply-To: <3CC9A89B.9D89D7E8@umbi.umd.edu> References: <3CC9A4C9.9CA9A27A@umbi.umd.edu> <1019848485.30784.17.camel@stout.americas.sgi.com> <3CC9A89B.9D89D7E8@umbi.umd.edu> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 26 Apr 2002 14:25:47 -0500 Message-Id: <1019849147.30784.22.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-26 at 14:20, Jonathan Dill wrote: > Eric Sandeen wrote: > > Not quite sure what you're asking, are the 7.0 systems ext2-based? > > The 7.0 systems are ext2-based. I wanted to know if I could install an > XFS kernel and xfsprogs in Red Hat 7.0 and boot up an XFS kernel, but > still in Red Hat 7.0. Then I can do a lot of the prep work "behind the > scenes" while the systems are still running Red Hat 7.0. Then I'll just > have the root fs to contend with during the install. Ah, I see. The XFS 1.1 RPMs will probably have dependency problems on a 7.0 system; rebuilding the SRPMS may help, although I think there are also build dependencies... So I guess my answer to the original question is "I don't know how well the 1.1 RPMs will work on a 7.0 system" :) -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 26 14:19:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QLJHwJ007265 for ; Fri, 26 Apr 2002 14:19:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QLJH5g007264 for linux-xfs-outgoing; Fri, 26 Apr 2002 14:19:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla4.xs4all.nl (mxzilla4.xs4all.nl [194.109.6.48]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QLJ9wJ007238 for ; Fri, 26 Apr 2002 14:19:10 -0700 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla4.xs4all.nl (8.12.0/8.12.0) with ESMTP id g3QLJeCJ051713; Fri, 26 Apr 2002 23:19:44 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id XAA28927; Fri, 26 Apr 2002 23:19:39 +0200 (CEST) Date: Fri, 26 Apr 2002 23:19:39 +0200 (CEST) From: Seth Mos To: Eric Sandeen cc: Jonathan Dill , Linux XFS Mailing List Subject: Re: Red Hat 7.0 In-Reply-To: <1019849147.30784.22.camel@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 26 Apr 2002, Eric Sandeen wrote: > On Fri, 2002-04-26 at 14:20, Jonathan Dill wrote: > > Eric Sandeen wrote: > > > Not quite sure what you're asking, are the 7.0 systems ext2-based? > > > > The 7.0 systems are ext2-based. I wanted to know if I could install an > > XFS kernel and xfsprogs in Red Hat 7.0 and boot up an XFS kernel, but > > still in Red Hat 7.0. Then I can do a lot of the prep work "behind the > > scenes" while the systems are still running Red Hat 7.0. Then I'll just > > have the root fs to contend with during the install. That sould work fine although you would probably need to compile from source. CVS will always work in this regard although it isn't really a 1.1 version. The userspace and XFS kernel all reside in CVS so you will have all utilities in one go. > Ah, I see. The XFS 1.1 RPMs will probably have dependency problems on a > 7.0 system; rebuilding the SRPMS may help, although I think there are > also build dependencies... You could install the kernel-source rpm and compile from there. > So I guess my answer to the original question is "I don't know how well > the 1.1 RPMs will work on a 7.0 system" :) I think they should do just fine. XFree will probably break because of DRM version dependency but I can't think of anything else right now. Cheers Seth From owner-linux-xfs@oss.sgi.com Fri Apr 26 14:48: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 g3QLm9wJ007545 for ; Fri, 26 Apr 2002 14:48:18 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QLm9co007544 for linux-xfs-outgoing; Fri, 26 Apr 2002 14:48:09 -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 g3QLm3wJ007516 for ; Fri, 26 Apr 2002 14:48:04 -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 QAA62558 for ; Fri, 26 Apr 2002 16:48:34 -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 QAA38815 for ; Fri, 26 Apr 2002 16:48:34 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3QLmYH06823; Fri, 26 Apr 2002 16:48:34 -0500 Message-Id: <200204262148.g3QLmYH06823@stout.americas.sgi.com> Date: Fri, 26 Apr 2002 16:48:34 -0500 Subject: TAKE - Fix up some error returns. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Still on the trail of the xfsdump + nfs oops, the first one below may help, but there is something else lurking... The xfs_iops.c mod fixes a case where we VOP_LOOKUP could fail, we don't set the inode ops, and yet return no error from linvfs_lookup. The linvfs_revalidate_core error handling should only matter in EIO cases where things have gotten pretty bad already. :) Date: Fri Apr 26 14:46:13 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-testing The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117593a linux/fs/xfs/linux/xfs_iops.c - 1.132 - Be sure to return an error if VOP_LOOKUP or linvfs_revalidate_core fails linux/fs/xfs/linux/xfs_ioctl.c - 1.57 - Return error with correct (+) sign if linvfs_revalidate_core fails From owner-linux-xfs@oss.sgi.com Fri Apr 26 15:15: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 g3QMFCwJ008252 for ; Fri, 26 Apr 2002 15:15:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QMFBdU008251 for linux-xfs-outgoing; Fri, 26 Apr 2002 15:15:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3QMF6wJ008213 for ; Fri, 26 Apr 2002 15:15: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 RAA62069 for ; Fri, 26 Apr 2002 17:15:37 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id RAA17032 for ; Fri, 26 Apr 2002 17:15:37 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3QMFb307007; Fri, 26 Apr 2002 17:15:37 -0500 Message-Id: <200204262215.g3QMFb307007@stout.americas.sgi.com> Date: Fri, 26 Apr 2002 17:15:37 -0500 Subject: TAKE - Fix vnode tracing in xfs debugging module Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some non-vnode tracing code made it into the vnode tracing function, this made for an unhappy case statement with duplicate case values. Also let this know about the linux-specific VMODIFIED vnode flag. Date: Fri Apr 26 15:13:55 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-testing The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117604a linux/fs/xfs/xfsidbg.c - 1.180 - Fix up vnode tracing - remove alloc tracing cases from vnode trace function - add VMODIFIED to list of known flags From owner-linux-xfs@oss.sgi.com Fri Apr 26 16:01:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3QN1DwJ009406 for ; Fri, 26 Apr 2002 16:01:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3QN1DCT009405 for linux-xfs-outgoing; Fri, 26 Apr 2002 16:01:13 -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 g3QN13wJ009377 for ; Fri, 26 Apr 2002 16:01:03 -0700 Received: (qmail 9545 invoked by uid 1000); 26 Apr 2002 23:10:14 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 26 Apr 2002 23:10:14 -0000 Date: Sat, 27 Apr 2002 02:10:14 +0300 (EEST) From: Mihai RUSU X-X-Sender: To: Paul Schutte cc: Thor Lancelot Simon , Steve Lord , Subject: Re: performance patches In-Reply-To: <3CC976ED.2C947B0F@up.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 26 Apr 2002, Paul Schutte wrote: > I know that it grows with the size, but the rate is much too slow. > If you create a 2Gb filesystem, you will have a 1200b log. > If you create a 64Gb filesystem, you still have the same 1200b log. > (That was still the case when a have set up my mailserver a month > ago). > > If you have 80 clients logging in on a 8Gb partition as in his case, > you can be sure to have your performance limited by your > 1200b log. > 1200b is good for a workstation, not for a high performance server. > How was he suppose to know that. > > The size of the filesystem does not matter as much as the amount > of I/O that you expect, as Steve pointed out. > Larger filesystems obviously have potential for more I/O. > > Maybe I put this a bit harsh, but I am trying to defend XFS's honour. > All the people that I encountered that said XFS's performace sucks, > used the default log size. > After corrrecting their mistake, they were impressed by XFS. > I bet that we have lost a lot of people because of a too small > log size. > > Paul > Hi guys Excuse me for dropping in but I wanted to say some things about this subject. We are using an XFS partition for a high I/O load (many IOPs, not too much transfer). The partition is 100Gb and its using its default log size (as per xfs_info) of 3200 blocks (4096 bytes for a block). Also I am monitoring (MRTG graphs) the IOPs as from /proc/stat | grep disk_io . Would it be right to consider from /proc/stat the firs value as the number of I/O transactions? Ex: disk_io: (3,0):(10899763,847269,16900622,10052494,159221833) (48,0):(52710982,15933971,287172411,36777011,545459600) Whould 52710982 be the number of I/O transactions of the device 48,0 ? If yes then would help very much to get statistics from them and maybe answer the question of a log of X size would lower the performance of XFS partition of Y size and Z transactions/s. PS: having a single XFS partition of device 48,0 Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated. From owner-linux-xfs@oss.sgi.com Fri Apr 26 17:28:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3R0ScwJ011103 for ; Fri, 26 Apr 2002 17:28:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3R0Sc4u011102 for linux-xfs-outgoing; Fri, 26 Apr 2002 17:28:38 -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 g3R0SXwJ011076 for ; Fri, 26 Apr 2002 17:28:34 -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 <20020427002904.ESMW322766.fep02-mail.bloor.is.net.cable.rogers.com@cr598116-a>; Fri, 26 Apr 2002 20:29:04 -0400 From: Gerald Henriksen To: Jonathan Dill Cc: linux-xfs@oss.sgi.com Subject: Re: Red Hat 7.0 Date: Fri, 26 Apr 2002 20:29:31 -0400 Message-ID: References: <3CC9A4C9.9CA9A27A@umbi.umd.edu> In-Reply-To: <3CC9A4C9.9CA9A27A@umbi.umd.edu> 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 Fri, 26 Apr 2002 20:29:04 -0400 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3R0SYwJ011077 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 26 Apr 2002 15:04:41 -0400, you wrote: >I'm getting ready to upgrade a bunch of Red Hat 7.0 systems and I >wondered: Has anyone got XFS kernel and xfsprogs to work on Red Hat >7.0? If it isn't too much of a pain, I might try to "convert" all of >the filesystems before the upgrade rather than having to back everything >up. Red Hat 7.0 shipped with kernel 2.2.16 (2.2.19 available as an update). To move to XFS you need to move to the 2.4 kernel series so you should see what changes to your system that requires. From owner-linux-xfs@oss.sgi.com Fri Apr 26 20:30:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3R3U9wJ015893 for ; Fri, 26 Apr 2002 20:30:09 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3R3U95G015892 for linux-xfs-outgoing; Fri, 26 Apr 2002 20:30:09 -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 g3R3U5wJ015858 for ; Fri, 26 Apr 2002 20:30:05 -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 WAA66260 for ; Fri, 26 Apr 2002 22:30:37 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id WAA48916 for ; Fri, 26 Apr 2002 22:30:37 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3R3UbP07388; Fri, 26 Apr 2002 22:30:37 -0500 Message-Id: <200204270330.g3R3UbP07388@stout.americas.sgi.com> Date: Fri, 26 Apr 2002 22:30:37 -0500 Subject: TAKE - UNDO part of that error return fix. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The change to linvfs_lookup isn't quite right, VOP_LOOKUP can return an error in normal circumstances, ENOENT in particular - and the negative dentry still needs to be created. Date: Fri Apr 26 20:28:52 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-testing The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117624a linux/fs/xfs/linux/xfs_iops.c - 1.133 - Whoops, that last change doesn't work, ENOENT is a "normal" error that apparently should not be passed back up. Back it all out for now. From owner-linux-xfs@oss.sgi.com Fri Apr 26 23:56: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 g3R6uWwJ019256 for ; Fri, 26 Apr 2002 23:56:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3R6uWq5019255 for linux-xfs-outgoing; Fri, 26 Apr 2002 23:56:32 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3R6uOwJ019229 for ; Fri, 26 Apr 2002 23:56:24 -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 XAA718915 for ; Fri, 26 Apr 2002 23:57:00 -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 QAA10897; Sat, 27 Apr 2002 16:55:43 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id QAA84713; Sat, 27 Apr 2002 16:55:42 +1000 (AEST) Date: Sat, 27 Apr 2002 16:55:42 +1000 From: Nathan Scott To: Dmitry Katsubo Cc: linux-xfs@oss.sgi.com Subject: Re: XFS error Message-ID: <20020427165542.C83002@wobbly.melbourne.sgi.com> References: <3CC92B6D.3010006@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3CC92B6D.3010006@mail.ru>; from dma_k@mail.ru on Fri, Apr 26, 2002 at 01:26:53PM +0300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, Apr 26, 2002 at 01:26:53PM +0300, Dmitry Katsubo wrote: > Hi, XFS developers! > > I am using CVS 2.4.18-xfs kernel, and after the latest > update and reboot I found the next error. The system continues > running after it. Suppose, it would help you > in finding the problem. This looks related to some code I put in recently - I will have a look on Monday. I'm about to put some more changes into that area too, so if you could grab cvs in an hour/two and see if the problem remains, that would be great. Thanks. > kernel: Unable to handle kernel NULL pointer dereference at virtual address 0000000c > kernel: printing eip: > kernel: c01fb3b6 > kernel: *pde = 00000000 > kernel: Oops: 0000 > kernel: CPU: 0 > kernel: EIP: 0010:[cluster_write+6/272] Not tainted > kernel: EIP: 0010:[] Not tainted > kernel: EFLAGS: 00010246 > kernel: eax: 00000000 ebx: 00000000 ecx: dfa36860 edx: ce3410c8 > kernel: esi: c17b7e8c edi: c1356d20 ebp: 00000000 esp: c17b7e54 > kernel: ds: 0018 es: 0018 ss: 0018 > kernel: Process kupdated (pid: 7, stackpage=c17b7000) > kernel: Stack: 00000000 c17b7e8c c1356d20 00000001 c01fb55f df64b340 ce3410c0 c1356d20 > kernel: c17b7e8c 00000001 00010002 c01fed80 00000001 00000001 02756ec8 00000000 > kernel: 00000000 00000000 00000000 00080000 00000001 00000047 c1356d20 0007f291 > kernel: Call Trace: [pagebuf_delalloc_convert+159/192] [linvfs_pb_bmap+0/208] [pagebuf_write_full_page+127/224] > [linvfs_pb_bmap+0/208] [xfs_write_full_page+37/64] > kernel: Call Trace: [] [] [] [] [] > kernel: [linvfs_pb_bmap+0/208] [linvfs_write_full_page+135/176] [write_buffer_delay+85/96] > [write_some_buffers+237/272] [schedule+489/880] > [flush_old_commits+239/352] > kernel: [] [] [] [] [] [] > kernel: [sync_unlocked_inodes+246/352] [process_timeout+0/80] [sync_old_buffers+28/64] [kupdate+247/256] > [_stext+0/48] [kernel_thread+38/48] > kernel: [] [] [] [] [] [] > kernel: [kupdate+0/256] > kernel: [] > kernel: > kernel: Code: 8b 45 0c 31 ff 8b 48 0c 85 c9 74 51 8b 5d 10 8b 43 08 8b 53 > -- Nathan From owner-linux-xfs@oss.sgi.com Sat Apr 27 00:32:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3R7W4wJ020500 for ; Sat, 27 Apr 2002 00:32:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3R7W4Sw020499 for linux-xfs-outgoing; Sat, 27 Apr 2002 00:32: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-d514e1d6.dsl.mediaWays.net [213.20.225.214]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3R7VxwJ020470 for ; Sat, 27 Apr 2002 00:32:00 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 171Mh4-0004jA-00; Sat, 27 Apr 2002 09:32:31 +0200 Message-ID: <3CCA540E.9E1AC742@berdmann.de> Date: Sat, 27 Apr 2002 09:32:30 +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: Ethan Benson CC: linux-xfs@oss.sgi.com Subject: Re: boot thinks / is still ext2 References: <3CC77E02.44593DF5@umbi.umd.edu> <20020424231757.C21791@plato.local.lan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > rsync isn't a very good tool for this, it will not preserve hard > links. man rsync: -H, --hard-links This tells rsync to recreate hard links on the remote system to be the same as the local system. Without this option hard links are treated like regular files. Note that rsync can only detect hard links if both parts of the link are in the list of files being sent. This option can be quite slow, so only use it if you need it. From owner-linux-xfs@oss.sgi.com Sat Apr 27 01:41:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3R8flwJ021471 for ; Sat, 27 Apr 2002 01:41:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3R8fl4d021470 for linux-xfs-outgoing; Sat, 27 Apr 2002 01:41:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3R8fewJ021443 for ; Sat, 27 Apr 2002 01:41:40 -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 BAA1751669 for ; Sat, 27 Apr 2002 01:42:17 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA56610 for linux-xfs@oss.sgi.com; Sat, 27 Apr 2002 18:41:00 +1000 (EST) Date: Sat, 27 Apr 2002 18:41:00 +1000 (EST) From: Nathan Scott Message-Id: <200204270841.SAA56610@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On-going multiple blocksizes work. Date: Sat Apr 27 01:30:41 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117626a linux/fs/xfs/linux/xfs_lrw.c - 1.133 - pass the correct offset into bmap, ie. the one used in the original xfs_bmapi call. seems to be benign though... Date: Sat Apr 27 01:38:25 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117627a linux/fs/xfs/pagebuf/page_buf_io.c - 1.29 - add a check to map match routine to ensure we don't attempt to match a buffer before the map starts; deadlock fixup for multiple blocksize only; ensure map_page can propogate bmap errors back out; refined the submit_page_io test to only skip non-dirty uptodate pages to get some write performance back at Steve's suggestion. linux/fs/xfs/pagebuf/page_buf.c - 1.17 - initial attempt at supporting multiple block sizes on the metadata path. lots of new code which is only executed for non-pagesized filesystems, so should be no change for pagesize case. had to move a few chunks of code around to allow some bit sharing, but shouldn't be any ill side-effects. linux/fs/xfs/pagebuf/page_buf_internal.h - 1.3 - move page_buffers macros in here for sharing, recant on need for offset match/map routines on metadata path. From owner-linux-xfs@oss.sgi.com Sat Apr 27 04:42:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3RBgZwJ023087 for ; Sat, 27 Apr 2002 04:42:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3RBgZG0023086 for linux-xfs-outgoing; Sat, 27 Apr 2002 04:42:35 -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 g3RBgTwJ023060 for ; Sat, 27 Apr 2002 04:42:30 -0700 Received: from ralf.wg ([192.168.1.2]) by ADSL-Bergs.RZ.RWTH-Aachen.DE with esmtp (Exim 3.33 #1) id 171Qaf-0005e6-00; Sat, 27 Apr 2002 13:42:09 +0200 From: "Ralf G. R. Bergs" To: "linux-xfs@oss.sgi.com" Cc: "Mihai RUSU" Date: Sat, 27 Apr 2002 13:42:09 +0200 Reply-To: "Ralf G. R. Bergs" X-Mailer: PMMail 2000 Professional (2.20.2475) For Windows 2000 (5.0.2195;2) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: performance patches Message-Id: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 27 Apr 2002 02:10:14 +0300 (EEST), Mihai RUSU wrote: >Whould 52710982 be the number of I/O transactions of the device 48,0 ? Format is (device major, disk index):(sum of all io requests, sum of read io requests, sum of blocks read, sum of write io requests, sum of blocks written) (Source: http://banyan.dlut.edu.cn/news/091901/0076.html) -- 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 Sat Apr 27 05:08:30 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3RC8UwJ023428 for ; Sat, 27 Apr 2002 05:08:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3RC8UvE023427 for linux-xfs-outgoing; Sat, 27 Apr 2002 05:08:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3RC8LwJ023400 for ; Sat, 27 Apr 2002 05:08:21 -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 HAA71151; Sat, 27 Apr 2002 07:08:54 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-17.corp.sgi.com [134.15.64.17]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA43194; Sat, 27 Apr 2002 07:08:51 -0500 (CDT) Subject: Re: performance patches From: Stephen Lord To: Mihai RUSU Cc: Paul Schutte , Thor Lancelot Simon , 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: 27 Apr 2002 07:01:23 -0500 Message-Id: <1019908885.1623.13.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Fri, 2002-04-26 at 18:10, Mihai RUSU wrote: > > Hi guys > > Excuse me for dropping in but I wanted to say some things about this > subject. > > We are using an XFS partition for a high I/O load (many IOPs, not too > much transfer). > The partition is 100Gb and its using its default log size (as per > xfs_info) of 3200 blocks (4096 bytes for a block). > Also I am monitoring (MRTG graphs) the IOPs as from /proc/stat | grep > disk_io . Would it be right to consider from /proc/stat the firs value > as the number of I/O transactions? > Ex: > > disk_io: (3,0):(10899763,847269,16900622,10052494,159221833) > (48,0):(52710982,15933971,287172411,36777011,545459600) > > Whould 52710982 be the number of I/O transactions of the device 48,0 ? > > If yes then would help very much to get statistics from them and maybe > answer the question of a log of X size would lower the performance of XFS > partition of Y size and Z transactions/s. > > PS: having a single XFS partition of device 48,0 > > Thanks > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. If you look in cmd/xfsmisc in the cvs tree you will find a script called xfs_stats.pl, make this an executable and it will dump all sorts of stats out of xfs. There is text further down the file which explains what the numbers mean. I have come across a command called iostat which you can get here: http://perso.wanadoo.fr/sebastien.godard/ which will report io requests nicely. Steve From owner-linux-xfs@oss.sgi.com Sat Apr 27 15:44:21 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3RMiFwJ030465 for ; Sat, 27 Apr 2002 15:44:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3RMiA69030463 for linux-xfs-outgoing; Sat, 27 Apr 2002 15:44:10 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fe140.worldonline.dk (fe140.worldonline.dk [212.54.64.183]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3RMi6wJ030429 for ; Sat, 27 Apr 2002 15:44:07 -0700 Received: (qmail 27059 invoked by uid 0); 27 Apr 2002 22:44:41 -0000 Received: from 213.237.15.210.adsl.od.worldonline.dk (HELO kurgan.dk) (213.237.15.210) by www.worldonline.dk with SMTP; 27 Apr 2002 22:44:41 -0000 Message-ID: <3CCB29DA.7060205@kurgan.dk> Date: Sun, 28 Apr 2002 00:44:42 +0200 From: Soren Birk Jacobsen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: XFS1.1 installer ISO? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk will there be installer ISO's of the XFS1.1 version? I can see that the 2.4.18 kernel matches the RedHat skipjack version so I assume an installer would be ideal for updating my current 2.4.9-31 XFS 7.2 redhat to the skipjack one? regards kurgan From owner-linux-xfs@oss.sgi.com Sat Apr 27 18:06:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3S16awJ032003 for ; Sat, 27 Apr 2002 18:06:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3S16a50032002 for linux-xfs-outgoing; Sat, 27 Apr 2002 18:06:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3S16VwJ031975 for ; Sat, 27 Apr 2002 18:06:31 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id UAA13329; Sat, 27 Apr 2002 20:07: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 UAA35925; Sat, 27 Apr 2002 20:07:06 -0500 (CDT) Date: Sat, 27 Apr 2002 20:07:05 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Soren Birk Jacobsen cc: linux-xfs@oss.sgi.com Subject: Re: XFS1.1 installer ISO? In-Reply-To: <3CCB29DA.7060205@kurgan.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk The 2.4.9-31 kernel RPMs are intended for RH Linux 7.1 and 7.2; the skipjack beta is based on 2.4.18, I think. There is currently no XFS installer for skipjack, and it's not on the schedule at this point. It would be nice to have, but it's not the highest priority right now. If anyone else wants to put it together, I would be happy to help by answering questions etc. (anaconda already includes xfs install bits; it just needs an xfs capable kernel & userspace added to the RPM set, and re-spin anaconda to boot the xfs kernel) -Eric On Sun, 28 Apr 2002, Soren Birk Jacobsen wrote: > will there be installer ISO's of the XFS1.1 version? > > I can see that the 2.4.18 kernel matches the RedHat skipjack version so > I assume an installer would be ideal for updating my current 2.4.9-31 > XFS 7.2 redhat to the skipjack one? -- 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 28 01:33:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3S8XlwJ003828 for ; Sun, 28 Apr 2002 01:33:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3S8Xl2X003827 for linux-xfs-outgoing; Sun, 28 Apr 2002 01:33:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mxzilla1.xs4all.nl (mxzilla1.xs4all.nl [194.109.6.54]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3S8XfwJ003801 for ; Sun, 28 Apr 2002 01:33:42 -0700 Received: from xs3.xs4all.nl (knuffie@xs3.xs4all.nl [194.109.6.44]) by mxzilla1.xs4all.nl (8.12.0/8.12.0) with ESMTP id g3S8YDrM010093; Sun, 28 Apr 2002 10:34:23 +0200 (CEST) Received: from localhost (knuffie@localhost) by xs3.xs4all.nl (8.9.0/8.9.0) with ESMTP id KAA00472; Sun, 28 Apr 2002 10:34:11 +0200 (CEST) Date: Sun, 28 Apr 2002 10:34:11 +0200 (CEST) From: Seth Mos To: Soren Birk Jacobsen cc: Subject: Re: XFS1.1 installer ISO? In-Reply-To: <3CCB29DA.7060205@kurgan.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 28 Apr 2002, Soren Birk Jacobsen wrote: > will there be installer ISO's of the XFS1.1 version? > > I can see that the 2.4.18 kernel matches the RedHat skipjack version so > I assume an installer would be ideal for updating my current 2.4.9-31 > XFS 7.2 redhat to the skipjack one? The 2.4.18 from skipjack is very different from what SGI has on their site. The SGI 2.4.18 is a standard linus kernel with XFS included. See the 1.1 kernels as a update to 1.0.2. You don't really need a installer for this. If there will be an installer it will be based on something that shipped (eg Red Hat 7.3/8.0) and not on beta versions. Cheers Seth From owner-linux-xfs@oss.sgi.com Sun Apr 28 03:16: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 g3SAG2wJ004985 for ; Sun, 28 Apr 2002 03:16:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SAG2u8004984 for linux-xfs-outgoing; Sun, 28 Apr 2002 03:16:02 -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 g3SAFswJ004957 for ; Sun, 28 Apr 2002 03:15:54 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 171ljG-0000hJ-00; Sun, 28 Apr 2002 11:16:26 +0100 Date: Sun, 28 Apr 2002 11:16:26 +0100 From: Christoph Hellwig To: Stephen Lord Cc: Mihai RUSU , Paul Schutte , Thor Lancelot Simon , linux-xfs@oss.sgi.com Subject: Re: performance patches Message-ID: <20020428111626.A2266@infradead.org> References: <1019908885.1623.13.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <1019908885.1623.13.camel@localhost.localdomain>; from lord@sgi.com on Sat, Apr 27, 2002 at 07:01:23AM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, Apr 27, 2002 at 07:01:23AM -0500, Stephen Lord wrote: > I have come across a command called iostat which you can get here: > http://perso.wanadoo.fr/sebastien.godard/ > > which will report io requests nicely. For full features (i.e. $BIGNUM of disks) you need sard support in your kernel. This has been in many vendor kernels for ages and a cleaned up version made it into 2.4.19-pre. Thats means for XFS1.1 the Red Hat rpms support it, but not the 2.4.18 based kernels. From owner-linux-xfs@oss.sgi.com Sun Apr 28 08:20: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 g3SFKKwJ013548 for ; Sun, 28 Apr 2002 08:20:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SFKKjT013547 for linux-xfs-outgoing; Sun, 28 Apr 2002 08:20:20 -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 g3SFJgwJ013507 for ; Sun, 28 Apr 2002 08:19:43 -0700 Received: from hch by phoenix.infradead.org with local (Exim 3.35 #5) id 171qTQ-00039n-00 for linux-xfs@oss.sgi.com; Sun, 28 Apr 2002 16:20:24 +0100 Date: Sun, 28 Apr 2002 16:20:24 +0100 From: Christoph Hellwig To: linux-xfs@oss.sgi.com Subject: [PATCH] cleanup pb_target handling Message-ID: <20020428162024.A11471@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk As FUP to the kmem_cache_alloc discussion I took a closer look at pagebuf_lock_enable(), one of the two users. The #ifdef 2.4.13> case doesn't need the zeroing at all as it initializes every single field directly afterwards, the other version doesn't even have a chance of compiling as it assumes pbr_addrspace is directly embedded in the pb_target instead of beeing a pointer. When makeing it directly embedded that code looks like it actually compiles and needs some additional zeroing in pbr_addrspace. But this is - like the other initialization only needed at the first time the object is initialized, as all these have to be back in the initial state when freed, makeing it ideal for a slab constructor. Next problem in that area: pagebuf_lock_enable() directly bdput()s the struct block_device whiches inode is refernced through PB_ADDR_SPACE over all of the pb_targets lifetime - adding pbr_bdev and doing bdput in pagebuf_lock_disable() fixes that. While in that area I've also applied a number of other cleanups: - keep a address_space pointer in pb_target for post 2.4.13 kernels, we always need it, not the inode. - add PBT_ADDR_SPACE to get address_space from pb_target. This fixes two places that couldn't compile for old kernels. - rename pbr_addrspace to pb_mapping. - rename pagebuf_registration_cach to pagebuf_target_cache. - don't NULL-initialize pagebuf_target_cache, it's in .bss. - move pagebuf_locking_init to the bottom of the file, where pagebuf_terminate_locking lives aswell and Linux sources tend to have init/exit code. - kill _pagebuf_registration_free, there was only one user, the name is misleading and when seeing the caller the NULL check was unneeded.. - kill misleading comment above pagebuf_lock_enable - general cleanup of pagebuf_lock_enable - fix misleading comment about mapping->page_lock - cleanup pagebuf_locking_init, the calling chain doesn't allow the cache to be non-NULL without serious kernel bugs. Index: linux/fs/xfs/pagebuf/page_buf.h =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/pagebuf/page_buf.h,v retrieving revision 1.10 diff -u -u -r1.10 page_buf.h --- linux/fs/xfs/pagebuf/page_buf.h 2002/03/28 19:45:15 1.10 +++ linux/fs/xfs/pagebuf/page_buf.h 2002/04/28 14:59:34 @@ -179,29 +179,23 @@ #define PBF_DONE(pb) (((pb)->pb_flags & (PBF_PARTIAL|PBF_NONE)) == 0) -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,13) typedef struct pb_target { kdev_t pbr_device; unsigned int pbr_blocksize; unsigned int pbr_blocksize_bits; - struct address_space *pbr_addrspace; -} pb_target_t; - -#define PB_ADDR_SPACE(pb) (&(pb)->pb_target->pbr_addrspace) - + struct block_device *pbr_bdev; +#if (LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,13)) + struct address_space pbr_mapping; +#define PBT_ADDR_SPACE(pbt) (&(pbt)->pbr_mapping) #else - -typedef struct pb_target { - kdev_t pbr_device; - unsigned int pbr_blocksize; - unsigned int pbr_blocksize_bits; - struct inode *pbr_inode; + struct address_space *pbr_mapping; +#define PBT_ADDR_SPACE(pbt) ((pbt)->pbr_mapping) +#endif } pb_target_t; -#define PB_ADDR_SPACE(pb) ((pb)->pb_target->pbr_inode->i_mapping) +#define PB_ADDR_SPACE(pb) PBT_ADDR_SPACE((pb)->pb_target) -#endif struct page_buf_s; Index: linux/fs/xfs/pagebuf/page_buf_locking.c =================================================================== RCS file: /cvs/linux-2.4-xfs/linux/fs/xfs/pagebuf/page_buf_locking.c,v retrieving revision 1.9 diff -u -u -r1.9 page_buf_locking.c --- linux/fs/xfs/pagebuf/page_buf_locking.c 2002/04/26 01:35:51 1.9 +++ linux/fs/xfs/pagebuf/page_buf_locking.c 2002/04/28 14:59:36 @@ -1,5 +1,6 @@ /* * Copyright (c) 2002 Silicon Graphics, Inc. All Rights Reserved. + * Portions Copyright (c) 2002 Christoph Hellwig. All Rights Reserved. * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -59,37 +60,13 @@ pb_hash_t pbhash[NHASH]; -static kmem_cache_t *pagebuf_registration_cache = NULL; +static kmem_cache_t *pagebuf_target_cache; /* * Initialization and Termination */ /* - * pagebuf_locking_init - */ - -int __init pagebuf_locking_init(void) -{ - int i; - - if (pagebuf_registration_cache == NULL) { - pagebuf_registration_cache = kmem_cache_create("page_buf_reg_t", - sizeof(pb_target_t), - 0, 0, NULL, NULL); - if (pagebuf_registration_cache == NULL) - return(-ENOMEM); - } - - for (i = 0; i < NHASH; i++) { - spin_lock_init(&pbhash[i].pb_hash_lock); - INIT_LIST_HEAD(&pbhash[i].pb_hash); - } - - return(0); -} - -/* * Hash calculation */ @@ -116,21 +93,6 @@ */ /* - * _pagebuf_registration_free - * - * Free a page_buf_registration_t object. The caller must hold - * the pagebuf_registered_inodes_lock. - */ - -static void -_pagebuf_registration_free(pb_target_t *target) -{ - if (target != NULL) { - kmem_cache_free(pagebuf_registration_cache, target); - } -} - -/* * _pagebuf_get_lockable_buffer * * Looks up, and creates if absent, a lockable buffer for @@ -363,23 +325,15 @@ pb_target_t *target) /* inode for buffers */ { destroy_buffers(target->pbr_device); - truncate_inode_pages(target->pbr_inode->i_mapping, 0LL); - _pagebuf_registration_free(target); + truncate_inode_pages(PBT_ADDR_SPACE(target), 0LL); + bdput(target->pbr_bdev); + kmem_cache_free(pagebuf_target_cache, target); return(0); } -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,13) -static struct address_space_operations pagebuf_aops = { - sync_page: block_sync_page, -}; -#endif - /* * pagebuf_lock_enable - * - * pagebuf_lock_enable enables buffer object locking for an inode. - * This call fails with -EBUSY if buffers are in use for this inode. */ pb_target_t * @@ -388,37 +342,23 @@ struct super_block *sb) { pb_target_t *target; - -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,13) - struct block_device *bdev = bdget(kdev); - if (!bdev) - return NULL; + target = kmem_cache_alloc(pagebuf_target_cache, SLAB_KERNEL); + if (target) { + target->pbr_bdev = bdget(kdev); + if (!target->pbr_bdev) + goto fail; + target->pbr_device = kdev; + pagebuf_target_blocksize(target, PAGE_CACHE_SIZE); +#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,4,13)) + target->pbr_mapping = target->pbr_bdev->bd_inode->i_mapping; #endif - - target = kmem_cache_zalloc(pagebuf_registration_cache, - SLAB_KERNEL); - if (target == NULL) { - return(NULL); } - target->pbr_device = kdev; -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,13) - target->pbr_inode = bdev->bd_inode; - bdput(bdev); -#else - INIT_LIST_HEAD(&target->pbr_addrspace.clean_pages); - INIT_LIST_HEAD(&target->pbr_addrspace.dirty_pages); - INIT_LIST_HEAD(&target->pbr_addrspace.locked_pages); - spin_lock_init(&target->pbr_addrspace.i_shared_lock); -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,4) - /* Also needed for AC kernels */ - spin_lock_init(&target->pbr_addrspace.page_lock); -#endif - target->pbr_addrspace.a_ops = &pagebuf_aops; -#endif - pagebuf_target_blocksize(target, PAGE_CACHE_SIZE); return target; +fail: + kmem_cache_free(pagebuf_target_cache, target); + return NULL; } void @@ -435,7 +375,7 @@ pb_target_t *target) { destroy_buffers(target->pbr_device); - truncate_inode_pages(target->pbr_inode->i_mapping, 0LL); + truncate_inode_pages(PBT_ADDR_SPACE(target), 0LL); return 0; } @@ -459,6 +399,65 @@ PB_TRACE(pb, PB_TRACE_REC(unlock), 0); } +#if (LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,13)) +static struct address_space_operations pagebuf_aops = { + sync_page: block_sync_page, +}; + +static void pb_target_ctor(void *p, kmem_cache_t * cachep, unsigned long flags) +{ + struct address_space *mapping = &(((pb_target_t *)p)->pbr_mapping); + + if ((flags & (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) == + SLAB_CTOR_CONSTRUCTOR) { + + memset(mapping, 0, sizeof(*mapping)); + INIT_LIST_HEAD(&mapping->clean_pages); + INIT_LIST_HEAD(&mapping->dirty_pages); + INIT_LIST_HEAD(&mapping->locked_pages); + mapping->a_ops = &pagebuf_aops; + spin_lock_init(&mapping->i_shared_lock); + + /* + * David Miller's pagecache lock splitting patch adds an + * additional per-mapping spinlock. Normally we do not + * care for out-of-tree patches, but this one is included + * in Red Hat's vendor kernels up to the heavily modified + * 2.4.9 series (7.1/7.2/AS). + * + * As there is no feature macro for the new lock, all we + * can do is to test against a macro added by this patch: + */ +#ifdef PAGECACHE_LOCK + spin_lock_init(&mapping->page_lock); +#endif + } +} +#else +#define pb_target_ctor NULL +#endif /* LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,13) */ + + +/* + * pagebuf_locking_init + */ + +int __init pagebuf_locking_init(void) +{ + int i; + + pagebuf_target_cache = kmem_cache_create("pb_target", + sizeof(pb_target_t), 0, 0, pb_target_ctor, NULL); + if (!pagebuf_target_cache) + return -ENOMEM; + + for (i = 0; i < NHASH; i++) { + spin_lock_init(&pbhash[i].pb_hash_lock); + INIT_LIST_HEAD(&pbhash[i].pb_hash); + } + + return 0; +} /* * pagebuf_terminate_locking. Do not define as __exit, it is called from @@ -467,6 +466,6 @@ void pagebuf_locking_terminate(void) { - if (pagebuf_registration_cache != NULL) - kmem_cache_destroy(pagebuf_registration_cache); + if (pagebuf_target_cache) + kmem_cache_destroy(pagebuf_target_cache); } From owner-linux-xfs@oss.sgi.com Sun Apr 28 08:51:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3SFpewJ014161 for ; Sun, 28 Apr 2002 08:51:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SFpeHe014160 for linux-xfs-outgoing; Sun, 28 Apr 2002 08:51:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fuerzag.ulatina.ac.cr (root@fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3SFpUwJ014120 for ; Sun, 28 Apr 2002 08:51:35 -0700 Received: from lucy.ulatina.ac.cr (fede2@lucy.ulatina.ac.cr [163.178.60.3]) by fuerzag.ulatina.ac.cr (8.11.6/8.10.2) with ESMTP id g3SFxMc31798 for ; Sun, 28 Apr 2002 09:59:22 -0600 Subject: [OT] Release 1.1 needs to be added to "XFS User Survey" From: Alvaro Figueroa To: XFS to linux port mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Apr 2002 09:44:38 -0600 Message-Id: <1020008678.7552.27.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I don't know if this is the right place to discuss this, so I marketed it OT. Release 1.1 need to be added to the Version field at the XFS User Survey at http://oss.sgi.com/projects/xfs/survey.html -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Sun Apr 28 09:29:05 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3SGT5wJ014950 for ; Sun, 28 Apr 2002 09:29:05 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SGT5oV014949 for linux-xfs-outgoing; Sun, 28 Apr 2002 09:29:05 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fuerzag.ulatina.ac.cr (root@fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3SGSiwJ014923 for ; Sun, 28 Apr 2002 09:28:48 -0700 Received: from lucy.ulatina.ac.cr (fede2@lucy.ulatina.ac.cr [163.178.60.3]) by fuerzag.ulatina.ac.cr (8.11.6/8.10.2) with ESMTP id g3SGakc32727 for ; Sun, 28 Apr 2002 10:36:46 -0600 Subject: xfsdump failing on sparc64 From: Alvaro Figueroa To: XFS to linux port mailing list Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Apr 2002 10:22:02 -0600 Message-Id: <1020010922.7552.29.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I'm running xfsdump -l 0 -F -E -L "blah" -M "blah" - /mnt. It fails saying: xfsdump: ERROR: /mnt/ does not identify a file system If I run strace to it, I see (stripped output): open("/etc/mtab", O_RDONLY) = 4 SYS_63() = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x700 1c000 read(4, "/dev/ide/host0/bus0/target0/lun0"..., 8192) = 344 brk(0x6c000) = 0x6c000 read(4, "", 8192) = 0 close(4) = 0 munmap(0x7001c000, 8192) = 0 SYS_139() = 0 getpid() = 371 write(2, "xfsdump: ", 9xfsdump: ) = 9 write(2, "ERROR: ", 7ERROR: ) = 7 write(2, "/mnt/ does not identify a file s"..., 38/mnt/ does not identify a file system ) = 38 So, I try to run it again, but instead of asking it to dump /mnt, I ask it to dump /dev/scsi/host0/bus0/target5/lun0/part1. It still fails. I get this 2 errors: xfsdump: unable to determinate uuid of fs mounted at /mnt: Invalid argument (...) xfsdump: unable to construct a file system handle for /mnt: Invalid argument Stripping a bit from the strace output, one can read: open("/etc/mtab", O_RDONLY) = 4 brk(0x6c000) = 0x6c000 SYS_63() = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x700 1e000 read(4, "/dev/ide/host0/bus0/target0/lun0"..., 8192) = 344 read(4, "", 8192) = 0 close(4) = 0 munmap(0x7001e000, 8192) = 0 SYS_139() = 0 open("/mnt", O_RDONLY|0x40000) = 4 ioctl(4, 0x405c5864, 0xeffff348) = -1 EINVAL (Invalid argument) close(4) = 0 getpid() = 254 write(1, "xfsdump: unable to determine uui"..., 74xfsdump: unable to determine u uid of fs mounted at /mnt: Invalid argument (...) open("/mnt", O_RDONLY|0x40000) = 5 ioctl(5, 0xc01c5868, 0xefffe418) = -1 EINVAL (Invalid argument) getpid() = 254 write(1, "xfsdump: unable to construct a f"..., 77xfsdump: unable to construct a file system handle for /mnt: Invalid argument ) = 77 After running xfsdump, one can read at dmesg: sys32_ioctl(xfsdump:149): Unknown cmd fd(4) cmd(405c5868) arg(effff348) sys32_ioctl(xfsdump:149): Unknown cmd fd(5) cmd(c01c5868) arg(efffe418) I have a blade 100 (sparc64, with an aic7xxx scsi controler) running a 3 day old cvs version. I hope this helps. If you guys need any other information, please let me know. Thanks in advance -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Sun Apr 28 09:48:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3SGmPwJ015349 for ; Sun, 28 Apr 2002 09:48:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SGmPlM015348 for linux-xfs-outgoing; Sun, 28 Apr 2002 09:48: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 g3SGmLwJ015322 for ; Sun, 28 Apr 2002 09:48:21 -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 LAA80643; Sun, 28 Apr 2002 11:49: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 LAA82758; Sun, 28 Apr 2002 11:48:59 -0500 (CDT) Date: Sun, 28 Apr 2002 11:48:59 -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: [OT] Release 1.1 needs to be added to "XFS User Survey" In-Reply-To: <1020008678.7552.27.camel@lucy> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Thanks, I added it, should show up within the hour. -Eric On 28 Apr 2002, Alvaro Figueroa wrote: > I don't know if this is the right place to discuss this, so I marketed > it OT. > > Release 1.1 need to be added to the Version field at the XFS User Survey > at http://oss.sgi.com/projects/xfs/survey.html -- 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 28 13:24:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3SKOKwJ017009 for ; Sun, 28 Apr 2002 13:24:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SKOKKn017008 for linux-xfs-outgoing; Sun, 28 Apr 2002 13:24:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from banix (mail@baana-pppoes-213-139-166-169.suomi.net [213.139.166.169]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3SKOEwJ016982 for ; Sun, 28 Apr 2002 13:24:16 -0700 Received: from bunnyh by banix with local (Exim 3.35 #1 (Debian)) id 171vE8-00008X-00 for ; Sun, 28 Apr 2002 23:24:56 +0300 Date: Sun, 28 Apr 2002 23:24:56 +0300 To: linux-xfs@oss.sgi.com Subject: DMAPI bug Message-ID: <20020428202456.GA481@banix.ihme.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: Juha K Kallio Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I noticed a nice bug with DMAPI. If you don't have the support in kernel, and try to mount with dmapi, it still gets mounted. On unmount it hangs with this: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... And when I try to mount it again, I get this: XFS: Filesystem loop(7,0) has duplicate UUID - can't mount mount: wrong fs type, bad option, bad superblock on /dev/loop0, or too many mounted file systems Clearly mount should give errors with unsupported options. That was quite confusing because I didn't get those kernel messages first over ssh connection :) From owner-linux-xfs@oss.sgi.com Sun Apr 28 15:27:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3SMRewJ017790 for ; Sun, 28 Apr 2002 15:27:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SMReoQ017789 for linux-xfs-outgoing; Sun, 28 Apr 2002 15:27:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3SMRZwJ017763 for ; Sun, 28 Apr 2002 15:27:36 -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 PAA1850896 for ; Sun, 28 Apr 2002 15:28:19 -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 IAA18570; Mon, 29 Apr 2002 08:26:58 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA92277; Mon, 29 Apr 2002 08:26:57 +1000 (AEST) Date: Mon, 29 Apr 2002 08:26:57 +1000 From: Nathan Scott To: Alvaro Figueroa Cc: XFS to linux port mailing list Subject: Re: xfsdump failing on sparc64 Message-ID: <20020429082656.O83002@wobbly.melbourne.sgi.com> References: <1020010922.7552.29.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020010922.7552.29.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Sun, Apr 28, 2002 at 10:22:02AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Apr 28, 2002 at 10:22:02AM -0600, Alvaro Figueroa wrote: > I'm running xfsdump -l 0 -F -E -L "blah" -M "blah" - /mnt. It fails > saying: > Sounds like you have an old xfsdump with a new kernel... which kernel version and which xfsdump version are you using? If your kernel is >=2.4.18 (or the 1.1 release) you will need 2.0+ tools. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Apr 28 15:35: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 g3SMZ6wJ017973 for ; Sun, 28 Apr 2002 15:35:06 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SMZ6TK017972 for linux-xfs-outgoing; Sun, 28 Apr 2002 15:35:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fuerzag.ulatina.ac.cr (root@fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3SMYxwJ017943 for ; Sun, 28 Apr 2002 15:35:00 -0700 Received: from lucy.ulatina.ac.cr (fede2@lucy.ulatina.ac.cr [163.178.60.3]) by fuerzag.ulatina.ac.cr (8.11.6/8.10.2) with ESMTP id g3SMh6c09911 for ; Sun, 28 Apr 2002 16:43:06 -0600 Subject: Re: xfsdump failing on sparc64 From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <20020429082656.O83002@wobbly.melbourne.sgi.com> References: <1020010922.7552.29.camel@lucy> <20020429082656.O83002@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Apr 2002 16:28:18 -0600 Message-Id: <1020032899.7548.51.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > Sounds like you have an old xfsdump with a new kernel... which > kernel version and which xfsdump version are you using? If your > kernel is >=2.4.18 (or the 1.1 release) you will need 2.0+ tools. I'm running a 2.4.18 kernel taken from the CVS a couple of days ago. And xfsdump --help claims its a 3.0. (BTW, I've just excecuted xfsdump --version, and take a look at its output (at the end) (...) [ -Y ] [ - (stdout) ] [ ] xfsdump: qlock.c:291: qlock_lock: Assertion `qlock_inited' failed. Aborted ) -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Sun Apr 28 15:42: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 g3SMgVwJ018157 for ; Sun, 28 Apr 2002 15:42:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SMgVkd018156 for linux-xfs-outgoing; Sun, 28 Apr 2002 15:42:31 -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 g3SMgPwJ018130 for ; Sun, 28 Apr 2002 15:42:25 -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 PAA1794163 for ; Sun, 28 Apr 2002 15:43:09 -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 IAA18667; Mon, 29 Apr 2002 08:41:51 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id IAA97743; Mon, 29 Apr 2002 08:41:51 +1000 (AEST) Date: Mon, 29 Apr 2002 08:41:50 +1000 From: Nathan Scott To: Alvaro Figueroa Cc: XFS to linux port mailing list Subject: Re: xfsdump failing on sparc64 Message-ID: <20020429084150.P83002@wobbly.melbourne.sgi.com> References: <1020010922.7552.29.camel@lucy> <20020429082656.O83002@wobbly.melbourne.sgi.com> <1020032899.7548.51.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020032899.7548.51.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Sun, Apr 28, 2002 at 04:28:18PM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk hi, On Sun, Apr 28, 2002 at 04:28:18PM -0600, Alvaro Figueroa wrote: > > Sounds like you have an old xfsdump with a new kernel... which > > kernel version and which xfsdump version are you using? If your > > kernel is >=2.4.18 (or the 1.1 release) you will need 2.0+ tools. > > I'm running a 2.4.18 kernel taken from the CVS a couple of days ago. > > And xfsdump --help claims its a 3.0. Yeah, that version numbers not helpful, sorry. We should fix that - its leftover from IRIX. To get the real version... "rpm -q xfsdump", if you use rpm; "dpkg -s xfsdump", if you use dpkg; ...or xfs_fsr -V will tell you the real package version. > (BTW, I've just excecuted xfsdump --version, and take a look at its > output (at the end) > > (...) > [ -Y ] > [ - (stdout) ] > [ ] > xfsdump: qlock.c:291: qlock_lock: Assertion `qlock_inited' failed. > Aborted Hmm... another one for the xfsdump guys to have a look at. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Apr 28 15:51:04 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3SMp4wJ018351 for ; Sun, 28 Apr 2002 15:51:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SMp4Ej018350 for linux-xfs-outgoing; Sun, 28 Apr 2002 15:51:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from fuerzag.ulatina.ac.cr (root@fuerzag.ulatina.ac.cr [163.178.60.45]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3SMouwJ018324 for ; Sun, 28 Apr 2002 15:50:58 -0700 Received: from lucy.ulatina.ac.cr (fede2@lucy.ulatina.ac.cr [163.178.60.3]) by fuerzag.ulatina.ac.cr (8.11.6/8.10.2) with ESMTP id g3SMx2c10315 for ; Sun, 28 Apr 2002 16:59:02 -0600 Subject: Re: xfsdump failing on sparc64 From: Alvaro Figueroa To: XFS to linux port mailing list In-Reply-To: <20020429084150.P83002@wobbly.melbourne.sgi.com> References: <1020010922.7552.29.camel@lucy> <20020429082656.O83002@wobbly.melbourne.sgi.com> <1020032899.7548.51.camel@lucy> <20020429084150.P83002@wobbly.melbourne.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/0.99.0 (Preview Release) Date: 28 Apr 2002 16:44:15 -0600 Message-Id: <1020033855.9253.55.camel@lucy> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > To get the real version... > "rpm -q xfsdump", if you use rpm; > "dpkg -s xfsdump", if you use dpkg; > ...or xfs_fsr -V will tell you the real package version. Nahh... I use Slackware[1]. It says 2.0.1. > Hmm... another one for the xfsdump guys to have a look at. Great. Thanks. [1] On sparc? Well, more or less. Its a community made sparc port. -- Alvaro Figueroa From owner-linux-xfs@oss.sgi.com Sun Apr 28 16:02: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 g3SN22wJ018586 for ; Sun, 28 Apr 2002 16:02:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3SN211B018585 for linux-xfs-outgoing; Sun, 28 Apr 2002 16:02:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3SN1twJ018559 for ; Sun, 28 Apr 2002 16:01:55 -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 QAA2096914 for ; Sun, 28 Apr 2002 16:02:39 -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 JAA18827; Mon, 29 Apr 2002 09:01:22 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA97594; Mon, 29 Apr 2002 09:01:21 +1000 (AEST) Date: Mon, 29 Apr 2002 09:01:21 +1000 From: Nathan Scott To: Alvaro Figueroa Cc: XFS to linux port mailing list Subject: Re: xfsdump failing on sparc64 Message-ID: <20020429090120.R83002@wobbly.melbourne.sgi.com> References: <1020010922.7552.29.camel@lucy> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020010922.7552.29.camel@lucy>; from fede2@fuerzag.ulatina.ac.cr on Sun, Apr 28, 2002 at 10:22:02AM -0600 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Apr 28, 2002 at 10:22:02AM -0600, Alvaro Figueroa wrote: > I'm running xfsdump -l 0 -F -E -L "blah" -M "blah" - /mnt. It fails > saying: > > xfsdump: ERROR: /mnt/ does not identify a file system > > If I run strace to it, I see (stripped output): > > open("/etc/mtab", O_RDONLY) = 4 > SYS_63() = 0 > mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) > = 0x700 > 1c000 > read(4, "/dev/ide/host0/bus0/target0/lun0"..., 8192) = 344 > brk(0x6c000) = 0x6c000 > read(4, "", 8192) = 0 > close(4) = 0 > munmap(0x7001c000, 8192) = 0 > SYS_139() = 0 > getpid() = 371 > write(2, "xfsdump: ", 9xfsdump: ) = 9 > write(2, "ERROR: ", 7ERROR: ) = 7 > write(2, "/mnt/ does not identify a file s"..., 38/mnt/ does not > identify a file > system > ) = 38 > OK, so its not a version number problem, its something else, I can't tell what from the above strace output. Your best bet will probably be gdb, step through the code till something goes astray & figure out what/why. The strace below shows it failing because you've given the device file as an argument rather than a mount point, which is incorrect. > So, I try to run it again, but instead of asking it to dump /mnt, I ask > it to dump /dev/scsi/host0/bus0/target5/lun0/part1. It still fails. I > get this 2 errors: > cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Apr 28 19:38:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3T2cZwJ020067 for ; Sun, 28 Apr 2002 19:38:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3T2cZa5020066 for linux-xfs-outgoing; Sun, 28 Apr 2002 19:38:35 -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 g3T2cMwJ020038 for ; Sun, 28 Apr 2002 19:38:22 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id TAA1874671 for ; Sun, 28 Apr 2002 19:39:07 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id MAA65695 for linux-xfs@oss.sgi.com; Mon, 29 Apr 2002 12:37:45 +1000 (AEST) Date: Mon, 29 Apr 2002 12:37:45 +1000 From: Timothy Shimmin To: linux-xfs@oss.sgi.com Subject: Re: default acl inheritance bug Message-ID: <20020429123745.K144037@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 On Fri, Apr 26, 2002 at 04:11:11AM -0800, Ethan Benson wrote: > On Thu, Apr 25, 2002 at 02:51:49PM +0200, Andreas Gruenbacher wrote: > > So this is the promised response to the suspected inheritance bug. To > > reestablish the contect, here is Ethan's original posting: > > > > > > On Wed, 17 Apr 2002, Ethan Benson wrote: > > > > > > i am trying to set a default acl to allow a user read permission to > > > files created. > > > > > > so do: > > > > > > root@ash:/var/log/apache# setfacl -dm u:webstats:r-- . > > > > > > which renders: > > > > > > root@ash:/var/log/apache# getfacl . > > > # file: . > > > # owner: root > > > # group: root > > > user::rwx > > > group::r-x > > > other::r-x > > > default:user::rwx > > > default:user:webstats:r-- > > > default:group::r-x > > > default:mask::r-x > > > default:other::r-x > > > > > > > > > and then touch foo and get its permissions: > > > > > > root@ash:/var/log/apache# touch foo > > > root@ash:/var/log/apache# getfacl foo > > > # file: foo > > > # owner: root > > > # group: root > > > user::rw- > > > user:webstats:r-x #effective:r-- > > > group::r-x #effective:r-- > > > mask::r-- > > > other::r-- > > > > > > why is the group and webstats user being given execute permission? > > > (yes i know the mask revokes it, its still wrong and i don't want any > > > user/group to have an x bit on *files*) > > > > > > when creating a file no execute bits should be set for anyone, why > > > does this not work correctly? note this test is done on the SGI > > > 2.4.18 XFS split patches. with acl 2.0.8. > > > > Either something has gone wrong on your example above, or there is indeed > > a bug in the XFS ACL implementation. No execute bit for user webstats > > should ever spring into existence like this. > > i fiddled around with it for well over an hour trying to stop this > behavior, i am quite certain about the above results (which are > copy/pasted directly from my tty). in between tests i always > completly stripped the acls with setfacl -b and verified that even the > system.*acl* attrs were removed with getfattr -m . > Hi Ethan, Yeah your behaviour with the file gaining execute permission in the user ACE definitely looks wrong _but_ I can NOT repeat it locally. tes@sagan /mnt/xfs0/testdir/test1> setfacl -dm u:tes:r-- . tes@sagan /mnt/xfs0/testdir/test1> getfacl . # file: . # owner: tes # group: tes user::rwx group::rwx other::r-x default:user::rwx default:user:tes:r-- default:group::rwx default:mask::rwx default:other::r-x tes@sagan /mnt/xfs0/testdir/test1> touch foo tes@sagan /mnt/xfs0/testdir/test1> getfacl foo # file: foo # owner: tes # group: tes user::rw- user:tes:r-- group::rwx #effective:rw- mask::rw- other::r-- You could try adding printk's in linux/fs/xfs/xfs_acl.c/xfs_acl_inherit() & xfs_acl_filter_mode() and see what is going wrong. OOI, what is the output from running "check 051" in the cmd/xfstests directory (i.e. the acl regression test) ? (You need to look at cmd/xfstests/README about setting this stuff up; one needs to setup some variables to point to xfs filesystems etc...) --Tim From owner-linux-xfs@oss.sgi.com Sun Apr 28 20:01:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3T31xwJ020360 for ; Sun, 28 Apr 2002 20:01:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3T31xHW020359 for linux-xfs-outgoing; Sun, 28 Apr 2002 20:01:59 -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 g3T31mwJ020331 for ; Sun, 28 Apr 2002 20:01:48 -0700 Received: from erbenson.alaska.net (149-pm19.nwc.alaska.net [209.112.142.149]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3T32Mw33077; Sun, 28 Apr 2002 19:02:22 -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 20CC23939; Sun, 28 Apr 2002 19:02:21 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 46D091028A; Sun, 28 Apr 2002 19:02:21 -0800 (AKDT) Date: Sun, 28 Apr 2002 19:02:21 -0800 From: Ethan Benson To: Timothy Shimmin Cc: Andreas Gruenbacher , linux-xfs@oss.sgi.com Subject: Re: default acl inheritence bug Message-ID: <20020428190221.G21791@plato.local.lan> Mail-Followup-To: Timothy Shimmin , Andreas Gruenbacher , linux-xfs@oss.sgi.com References: <20020417011517.G20630@plato.local.lan> <20020426041111.F21791@plato.local.lan> <"from erbenson"@alaska.net> <20020429123505.J144037@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RMedoP2+Pr6Rq0N2" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020429123505.J144037@boing.melbourne.sgi.com>; from tes@boing.melbourne.sgi.com on Mon, Apr 29, 2002 at 12:35:05PM +1000 X-OS: Debian GNU Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --RMedoP2+Pr6Rq0N2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2002 at 12:35:05PM +1000, Timothy Shimmin wrote: > Hi Ethan, >=20 > Yeah your behaviour with the file gaining execute permission in the > user ACE definitely looks wrong _but_ I can NOT repeat it locally. >=20 > tes@sagan /mnt/xfs0/testdir/test1> setfacl -dm u:tes:r-- . > tes@sagan /mnt/xfs0/testdir/test1> getfacl . > # file: . > # owner: tes > # group: tes > user::rwx > group::rwx > other::r-x > default:user::rwx > default:user:tes:r-- > default:group::rwx > default:mask::rwx > default:other::r-x >=20 > tes@sagan /mnt/xfs0/testdir/test1> touch foo > tes@sagan /mnt/xfs0/testdir/test1> getfacl foo > # file: foo > # owner: tes > # group: tes > user::rw- > user:tes:r-- > group::rwx #effective:rw- > mask::rw- > other::r-- >=20 > You could try adding printk's in=20 > linux/fs/xfs/xfs_acl.c/xfs_acl_inherit() & xfs_acl_filter_mode() and=20 > see what is going wrong. >=20 > OOI, what is the output from running "check 051" in > the cmd/xfstests directory (i.e. the acl regression test) ? > (You need to look at cmd/xfstests/README about setting this stuff up; > one needs to setup some variables to point to xfs filesystems etc...) i assume you used current CVS XFS? im on 2.4.18 split patches, so perhaps this is already fixed, ill check again when 2.4.19 is released. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --RMedoP2+Pr6Rq0N2 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 iEYEARECAAYFAjzMt70ACgkQJKx7GixEevyoNwCfdhPWGyBhoydSY96+pg4lq4vt W+wAmwYueuy3zBRpojTTMGwe7EdLbZEY =Ih8o -----END PGP SIGNATURE----- --RMedoP2+Pr6Rq0N2-- From owner-linux-xfs@oss.sgi.com Sun Apr 28 20:24: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 g3T3OvwJ020624 for ; Sun, 28 Apr 2002 20:24:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3T3OvPY020623 for linux-xfs-outgoing; Sun, 28 Apr 2002 20:24:57 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3T3OmwJ020597 for ; Sun, 28 Apr 2002 20:24:48 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id UAA2093420 for ; Sun, 28 Apr 2002 20:25:30 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA66617; Mon, 29 Apr 2002 13:24:03 +1000 (AEST) Date: Mon, 29 Apr 2002 13:24:02 +1000 From: Timothy Shimmin To: Ethan Benson Cc: Andreas Gruenbacher , linux-xfs@oss.sgi.com Subject: Re: default acl inheritence bug Message-ID: <20020429132402.N144037@boing.melbourne.sgi.com> References: <20020417011517.G20630@plato.local.lan> <20020426041111.F21791@plato.local.lan> <"from <20020429123505.J144037@boing.melbourne.sgi.com> <20020428190221.G21791@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020428190221.G21791@plato.local.lan>; from erbenson@alaska.net on Sun, Apr 28, 2002 at 07:02:21PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Apr 28, 2002 at 07:02:21PM -0800, Ethan Benson wrote: > On Mon, Apr 29, 2002 at 12:35:05PM +1000, Timothy Shimmin wrote: > > Hi Ethan, > > > > Yeah your behaviour with the file gaining execute permission in the > > user ACE definitely looks wrong _but_ I can NOT repeat it locally. > > > > tes@sagan /mnt/xfs0/testdir/test1> setfacl -dm u:tes:r-- . > > tes@sagan /mnt/xfs0/testdir/test1> getfacl . > > # file: . > > # owner: tes > > # group: tes > > user::rwx > > group::rwx > > other::r-x > > default:user::rwx > > default:user:tes:r-- > > default:group::rwx > > default:mask::rwx > > default:other::r-x > > > > tes@sagan /mnt/xfs0/testdir/test1> touch foo > > tes@sagan /mnt/xfs0/testdir/test1> getfacl foo > > # file: foo > > # owner: tes > > # group: tes > > user::rw- > > user:tes:r-- > > group::rwx #effective:rw- > > mask::rw- > > other::r-- > > > > You could try adding printk's in > > linux/fs/xfs/xfs_acl.c/xfs_acl_inherit() & xfs_acl_filter_mode() and > > see what is going wrong. > > > > OOI, what is the output from running "check 051" in > > the cmd/xfstests directory (i.e. the acl regression test) ? > > (You need to look at cmd/xfstests/README about setting this stuff up; > > one needs to setup some variables to point to xfs filesystems etc...) > > i assume you used current CVS XFS? Yep. > im on 2.4.18 split patches, so perhaps this is already fixed, Perhaps. (But I've never seen this as a bug before - so there were no intentional fixes AFAIK.) --Tim From owner-linux-xfs@oss.sgi.com Sun Apr 28 21:04:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3T44ewJ021105 for ; Sun, 28 Apr 2002 21:04:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3T44d7Y021104 for linux-xfs-outgoing; Sun, 28 Apr 2002 21:04:39 -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 g3T44QwJ021072 for ; Sun, 28 Apr 2002 21:04:26 -0700 Received: from erbenson.alaska.net (133-pm11.nwc.alaska.net [209.112.140.133]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3T44xV65965; Sun, 28 Apr 2002 20:04:59 -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 E43493939; Sun, 28 Apr 2002 20:04:58 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 6733A1028A; Sun, 28 Apr 2002 20:04:58 -0800 (AKDT) Date: Sun, 28 Apr 2002 20:04:58 -0800 From: Ethan Benson To: Timothy Shimmin Cc: Andreas Gruenbacher , linux-xfs@oss.sgi.com Subject: Re: default acl inheritence bug Message-ID: <20020428200458.I21791@plato.local.lan> Mail-Followup-To: Timothy Shimmin , Andreas Gruenbacher , linux-xfs@oss.sgi.com References: <20020417011517.G20630@plato.local.lan> <20020426041111.F21791@plato.local.lan> <"from erbenson"@alaska.net> <20020429132402.N144037@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zq44+AAfm4giZpo5" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020429132402.N144037@boing.melbourne.sgi.com>; from tes@boing.melbourne.sgi.com on Mon, Apr 29, 2002 at 01:24:02PM +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 --zq44+AAfm4giZpo5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2002 at 01:24:02PM +1000, Timothy Shimmin wrote: > > > tes@sagan /mnt/xfs0/testdir/test1> getfacl . > > > # file: . > > > # owner: tes > > > # group: tes > > > user::rwx > > > group::rwx > > > other::r-x > > > default:user::rwx > > > default:user:tes:r-- > > > default:group::rwx > > > default:mask::rwx > > > default:other::r-x > > >=20 > > > tes@sagan /mnt/xfs0/testdir/test1> touch foo > > > tes@sagan /mnt/xfs0/testdir/test1> getfacl foo > > > # file: foo > > > # owner: tes > > > # group: tes > > > user::rw- > > > user:tes:r-- > > > group::rwx #effective:rw- > > > mask::rw- > > > other::r-- >=20 > > im on 2.4.18 split patches, so perhaps this is already fixed,=20 > Perhaps. > (But I've never seen this as a bug before - so there were > no intentional fixes AFAIK.) >=20 your test is wrong, thats the problem, if you create a directory with your default acl then user tes won't have execute permission to it: eb@dogbert /home/eb/test$ getfacl . # file: . # owner: eb # group: eb user::rwx group::r-x other::r-x default:user::rwx default:user:bin:r-- default:group::r-x default:mask::r-x default:other::r-x eb@dogbert /home/eb/test$ mkdir foo eb@dogbert /home/eb/test$ getfacl foo # file: foo # owner: eb # group: eb user::rwx user:bin:r-- group::r-x mask::r-x other::r-x default:user::rwx default:user:bin:r-- default:group::r-x default:mask::r-x default:other::r-x so the obvious solution to this is set r-x for user:tes on the default acl, but that breaks file creation. one way or another you get broken behavior, if acls would follow standard unix behavior of files getting 666 masked by default and directories get 777 masked it would work. or perhaps not having separate default acls for files/dirs is just broken, which is the conclusion im coming to, at least with the current broken behavior. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --zq44+AAfm4giZpo5 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 iEYEARECAAYFAjzMxmoACgkQJKx7GixEevxcqgCcDSmEWWeBa6cF2DvFUoq+Gl1p oAsAn35Mnzk6bRPiaV58WxoCK8mITfPK =tMBB -----END PGP SIGNATURE----- --zq44+AAfm4giZpo5-- From owner-linux-xfs@oss.sgi.com Mon Apr 29 00:33: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 g3T7X7wJ023098 for ; Mon, 29 Apr 2002 00:33:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3T7X7aq023097 for linux-xfs-outgoing; Mon, 29 Apr 2002 00:33:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from swathi.krithika.net ([202.88.158.15]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3T7X0wJ023070 for ; Mon, 29 Apr 2002 00:33:03 -0700 Received: from localhost (localhost.krithika.net [127.0.0.1]) by swathi.krithika.net (Postfix) with ESMTP id 438E6C75D02 for ; Mon, 29 Apr 2002 13:03:43 +0530 (IST) Received: from localhost.krithika.net (localhost.krithika.net [127.0.0.1]) by swathi.krithika.net (Postfix) with ESMTP id E2EECC75D01 for ; Mon, 29 Apr 2002 13:03:42 +0530 (IST) Subject: Kbuild version in cvs From: Ajay Ramaswamy To: linux-xfs@oss.sgi.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 (1.0.2-2) Date: 29 Apr 2002 13:03:42 +0530 Message-Id: <1020065622.25388.1.camel@swathi.krithika.net> Mime-Version: 1.0 X-Virus-Scanned: by AMaViS snapshot-20020300 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Can someone tell me if the CVS version of the 2.4 tree has the new kbuild 2.5 code integrated? If not is there a patch? regards Ajay From owner-linux-xfs@oss.sgi.com Mon Apr 29 00:45: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 g3T7jnwJ023350 for ; Mon, 29 Apr 2002 00:45:49 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3T7jn8D023349 for linux-xfs-outgoing; Mon, 29 Apr 2002 00:45:49 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3T7jkwJ023322 for ; Mon, 29 Apr 2002 00:45:46 -0700 Received: from nodin.corp.sgi.com (nodin.corp.sgi.com [192.26.51.193]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA2006573 for ; Mon, 29 Apr 2002 00:46:33 -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 g3T7iE22919760; Mon, 29 Apr 2002 00:44:14 -0700 (PDT) Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 3D8AE3000B8; Mon, 29 Apr 2002 17:44:12 +1000 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id EDC6E94; Mon, 29 Apr 2002 17:44:12 +1000 (EST) X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 From: Keith Owens To: Ajay Ramaswamy Cc: linux-xfs@oss.sgi.com Subject: Re: Kbuild version in cvs In-reply-to: Your message of "29 Apr 2002 13:03:42 +0530." <1020065622.25388.1.camel@swathi.krithika.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 29 Apr 2002 17:44:07 +1000 Message-ID: <22246.1020066247@kao2.melbourne.sgi.com> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 29 Apr 2002 13:03:42 +0530, Ajay Ramaswamy wrote: >Can someone tell me if the CVS version of the 2.4 tree has the new >kbuild 2.5 code integrated? CVS contains just the XFS changes for kbuild 2.5. See http://marc.theaimsgroup.com/?l=linux-xfs&m=100510835713728&w=2 From owner-linux-xfs@oss.sgi.com Mon Apr 29 01:29: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 g3T8TdwJ023907 for ; Mon, 29 Apr 2002 01:29:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3T8TdkC023906 for linux-xfs-outgoing; Mon, 29 Apr 2002 01:29:39 -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 g3T8TNwJ023876 for ; Mon, 29 Apr 2002 01:29:23 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id BAA2050631 for ; Mon, 29 Apr 2002 01:30:08 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id SAA73363; Mon, 29 Apr 2002 18:28:46 +1000 (AEST) Date: Mon, 29 Apr 2002 18:28:46 +1000 From: Timothy Shimmin To: Ethan Benson Cc: linux-xfs@oss.sgi.com, ag@bestbits.at Subject: Re: default acl inheritence bug Message-ID: <20020429182846.R144037@boing.melbourne.sgi.com> References: <20020417011517.G20630@plato.local.lan> <20020426041111.F21791@plato.local.lan> <"from <20020429132402.N144037@boing.melbourne.sgi.com> <20020428200458.I21791@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020428200458.I21791@plato.local.lan>; from erbenson@alaska.net on Sun, Apr 28, 2002 at 08:04:58PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, Apr 28, 2002 at 08:04:58PM -0800, Ethan Benson wrote: > On Mon, Apr 29, 2002 at 01:24:02PM +1000, Timothy Shimmin wrote: > > > > tes@sagan /mnt/xfs0/testdir/test1> getfacl . > > > > # file: . > > > > # owner: tes > > > > # group: tes > > > > user::rwx > > > > group::rwx > > > > other::r-x > > > > default:user::rwx > > > > default:user:tes:r-- > > > > default:group::rwx > > > > default:mask::rwx > > > > default:other::r-x > > > > > > > > tes@sagan /mnt/xfs0/testdir/test1> touch foo > > > > tes@sagan /mnt/xfs0/testdir/test1> getfacl foo > > > > # file: foo > > > > # owner: tes > > > > # group: tes > > > > user::rw- > > > > user:tes:r-- > > > > group::rwx #effective:rw- > > > > mask::rw- > > > > other::r-- > > > > > im on 2.4.18 split patches, so perhaps this is already fixed, > > Perhaps. > > (But I've never seen this as a bug before - so there were > > no intentional fixes AFAIK.) > > > > your test is wrong, thats the problem, if you create a directory with > your default acl then user tes won't have execute permission to it: I don't understand your problem then. My example was based on your example for creating a file in the directory. And your example showed the file gaining the execute permission on a user ACE - which I don't see. Ethan previously wrote: > > root@ash:/var/log/apache# setfacl -dm u:webstats:r-- . > > > > which renders: > > > > root@ash:/var/log/apache# getfacl . > > # file: . > > # owner: root > > # group: root > > user::rwx > > group::r-x > > other::r-x > > default:user::rwx > > default:user:webstats:r-- > > default:group::r-x > > default:mask::r-x > > default:other::r-x > > > > > > and then touch foo and get its permissions: > > > > root@ash:/var/log/apache# touch foo > > root@ash:/var/log/apache# getfacl foo > > # file: foo > > # owner: root > > # group: root > > user::rw- > > user:webstats:r-x #effective:r-- > > group::r-x #effective:r-- > > mask::r-- > > other::r-- Ethan currently writes: > > eb@dogbert /home/eb/test$ getfacl . > # file: . > # owner: eb > # group: eb > user::rwx > group::r-x > other::r-x > default:user::rwx > default:user:bin:r-- > default:group::r-x > default:mask::r-x > default:other::r-x > > eb@dogbert /home/eb/test$ mkdir foo > eb@dogbert /home/eb/test$ getfacl foo > # file: foo > # owner: eb > # group: eb > user::rwx > user:bin:r-- > group::r-x > mask::r-x > other::r-x > default:user::rwx > default:user:bin:r-- > default:group::r-x > default:mask::r-x > default:other::r-x > > so the obvious solution to this is set r-x for user:tes on the default > acl, but that breaks file creation. one way or another you get broken > behavior, if acls would follow standard unix behavior of files getting > 666 masked by default and directories get 777 masked it would work. Well it's mkdir(1) which passes in a mode of 777 to the mkdir(2) call for directories. And touch(1) which uses 666 as the mode to creat(2) for files. > > or perhaps not having separate default acls for files/dirs is just > broken, which is the conclusion im coming to, at least with the > current broken behavior. > I see what you are getting at now but that is independent of the bug you reported earlier. --Tim From owner-linux-xfs@oss.sgi.com Mon Apr 29 01:37: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 g3T8bSwJ024196 for ; Mon, 29 Apr 2002 01:37:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3T8bSfj024195 for linux-xfs-outgoing; Mon, 29 Apr 2002 01:37:28 -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 g3T8b7wJ024150 for ; Mon, 29 Apr 2002 01:37:13 -0700 Received: from lizard.webland.de (lizard.webland.de [194.122.76.201]) by mx.de.kpnqwest.net (Postfix (mxkq02)) with ESMTP id 45D6DC217; Mon, 29 Apr 2002 10:11:02 +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 KAA14238; Mon, 29 Apr 2002 10:11:01 +0200 (MET DST) >Received: from mobile.sauter-bc.com (unknown [10.1.6.21]) by basel1.sauter-bc.com (Postfix) with ESMTP id D39FB57306; Mon, 29 Apr 2002 10:08: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 254E925835; Mon, 29 Apr 2002 10:08:15 +0200 (CEST) Message-ID: <3CCCFF6F.3A63C0AB@ch.sauter-bc.com> Date: Mon, 29 Apr 2002 10:08:15 +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: Jonathan Dill Cc: Linux XFS Mailing List Subject: Re: Red Hat 7.0 References: <3CC9A4C9.9CA9A27A@umbi.umd.edu> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Jonathan Dill schrieb: > > I'm getting ready to upgrade a bunch of Red Hat 7.0 systems and I > wondered: Has anyone got XFS kernel and xfsprogs to work on Red Hat > 7.0? If it isn't too much of a pain, I might try to "convert" all of > the filesystems before the upgrade rather than having to back everything > up. Try Google, IIRC I found a website once describing what you want. Simon > > I suppose I could just copy "/" then make a new XFS during the install, > but then I have to port in any non-RPM software and settings from the > old root files. Then I could "convert" the rest of the filesystems > after the upgrade. Or maybe I could hack the install CD to have the > tools executable off the CD, make a clean XFS, then copy the root back > to the new fs. > > Thinking out loud, > -- > "Jonathan F. Dill" (dill@umbi.umd.edu) > UMBI CARB IT Coordinator > Experimental Support Site http://concept.umbi.umd.edu From owner-linux-xfs@oss.sgi.com Mon Apr 29 04:38:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TBcPwJ026286 for ; Mon, 29 Apr 2002 04:38:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TBcP0D026285 for linux-xfs-outgoing; Mon, 29 Apr 2002 04:38:25 -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 g3TBbkwJ026255 for ; Mon, 29 Apr 2002 04:37:46 -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 g3TBbv7x080621; Mon, 29 Apr 2002 13:38:25 +0200 (CEST) Message-Id: <4.3.2.7.2.20020429132935.02dc9ef8@pop.xs4all.nl> X-Sender: knuffie@pop.xs4all.nl X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 29 Apr 2002 13:39:24 +0200 To: ken@sernet.com.cn From: Seth Mos Subject: Re: help! Cc: linux-xfs@oss.sgi.com In-Reply-To: <48256BAA.00343DE6.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 17:30 29-4-2002 +0800, ken@sernet.com.cn wrote: >Dear seth: > execuse me,Can you help me. > When I xfs_repair(the latest version 2.0.3),it will dump and post > "out >of memory" warning. > why it is ? > cpu : 333Mhz > ram: 64M ( include a 16M ramdisk) > harddisk: 120G ( only one partion) Have you sent this message to the xfs mailinglist? Is this the xfs_repair from CVS? What kernel version are you using? Does xfs_repair -n also stop with an out of memory error. Cheers -- Seth It might just be your lucky day, if you only knew. From owner-linux-xfs@oss.sgi.com Mon Apr 29 08:52:47 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TFqlwJ027960 for ; Mon, 29 Apr 2002 08:52:47 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TFqlBJ027959 for linux-xfs-outgoing; Mon, 29 Apr 2002 08:52:47 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TFqgwJ027929 for ; Mon, 29 Apr 2002 08:52: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 KAA61485; Mon, 29 Apr 2002 10:53:25 -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 KAA06778; Mon, 29 Apr 2002 10:53:25 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3TFqkc16266; Mon, 29 Apr 2002 10:52:46 -0500 Subject: Re: [PATCH] cleanup pb_target handling From: Steve Lord To: Christoph Hellwig Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020428162024.A11471@infradead.org> References: <20020428162024.A11471@infradead.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 29 Apr 2002 10:52:45 -0500 Message-Id: <1020095565.16224.96.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2002-04-28 at 10:20, Christoph Hellwig wrote: > As FUP to the kmem_cache_alloc discussion I took a closer look at > pagebuf_lock_enable(), one of the two users. > Thanks Christoph, looks good. 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 29 08:52:54 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TFqswJ027995 for ; Mon, 29 Apr 2002 08:52:54 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TFqsXe027994 for linux-xfs-outgoing; Mon, 29 Apr 2002 08:52:54 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TFqmwJ027933 for ; Mon, 29 Apr 2002 08:52:48 -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 KAA99965; Mon, 29 Apr 2002 10:53:30 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id KAA32199; Mon, 29 Apr 2002 10:53:29 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3TFqoT16270; Mon, 29 Apr 2002 10:52:50 -0500 Subject: Re: DMAPI bug From: Steve Lord To: Juha K Kallio Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020428202456.GA481@banix.ihme.org> References: <20020428202456.GA481@banix.ihme.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 29 Apr 2002 10:52:50 -0500 Message-Id: <1020095570.16192.97.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sun, 2002-04-28 at 15:24, Juha K Kallio wrote: > I noticed a nice bug with DMAPI. If you don't have the support in > kernel, and try to mount with dmapi, it still gets mounted. On unmount > it hangs with this: > > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice > day... > > And when I try to mount it again, I get this: > > XFS: Filesystem loop(7,0) has duplicate UUID - can't mount > mount: wrong fs type, bad option, bad superblock on /dev/loop0, or too > many mounted file systems > > Clearly mount should give errors with unsupported options. That was > quite confusing because I didn't get those kernel messages first over > ssh connection :) I talked with out DMAPI guy, and this will get fixed, right now he is working against an Irix deadline, so he is saving up all the Linux DMAPI work for later. i.e. it will get fixed, it may just take a little while. 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 29 09:51: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 g3TGpWwJ031126 for ; Mon, 29 Apr 2002 09:51:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TGpVoK031125 for linux-xfs-outgoing; Mon, 29 Apr 2002 09:51:31 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from tobi.high-tech-jobs.de (tobi.high-tech-jobs.de [213.70.139.195]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TGpQwJ031099 for ; Mon, 29 Apr 2002 09:51:27 -0700 Received: by tobi.high-tech-jobs.de (8.12.2/8.12.2) id g3TGq8wV005684 for ; Mon, 29 Apr 2002 18:52:08 +0200 Received: from UNKNOWN(213.158.1.52), claiming to be "island.home.net" via SMTP by tobi, id smtpdssDKBe; Mon Apr 29 18:52:01 2002 Content-Type: text/plain; charset="us-ascii" From: Michael Ivanov Reply-To: ivans@isle.spb.ru Organization: At home To: linux-xfs@oss.sgi.com Subject: Hi! Where can I download xfs patches for 2.5.10? Date: Mon, 29 Apr 2002 20:46:40 +0400 X-Mailer: KMail [version 1.4] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200204292046.40876.ivans@isle.spb.ru> Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi! Where can I download xfs patches for 2.5.10? The patchlist and ftp server show only 2.4 patches. Best regards -- \ / | | (OvO) | Michael Ivanov | (^^^) | | \^/ | E-mail: ivans@isle.spb.ru | ^ ^ | | From owner-linux-xfs@oss.sgi.com Mon Apr 29 10:28:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3THSYwJ002089 for ; Mon, 29 Apr 2002 10:28:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3THSXB3002088 for linux-xfs-outgoing; Mon, 29 Apr 2002 10:28:33 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3THSUwJ002062 for ; Mon, 29 Apr 2002 10:28:30 -0700 Received: from zeus-e8.americas.sgi.com (zeus-e8.americas.sgi.com [128.162.8.103]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id KAA2103476 for ; Mon, 29 Apr 2002 10:29:17 -0700 (PDT) mail_from (sandeen@sgi.com) 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 MAA02706; Mon, 29 Apr 2002 12:19:38 -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 MAA31739; Mon, 29 Apr 2002 12:19:38 -0500 (CDT) Subject: Re: Hi! Where can I download xfs patches for 2.5.10? From: Eric Sandeen To: ivans@isle.spb.ru Cc: linux-xfs@oss.sgi.com In-Reply-To: <200204292046.40876.ivans@isle.spb.ru> References: <200204292046.40876.ivans@isle.spb.ru> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 29 Apr 2002 12:19:37 -0500 Message-Id: <1020100778.2131.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Michael - Currently 2.5.10 + XFS is only available from CVS. The patch generation scripts broke when Linus changed his tarball format, and I have not fixed them yet. So CVS is the only way to go for now. -Eric On Mon, 2002-04-29 at 11:46, Michael Ivanov wrote: > Hi! Where can I download xfs patches for 2.5.10? > The patchlist and ftp server show only 2.4 patches. -- 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 29 11:10: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 g3TIA2wJ004594 for ; Mon, 29 Apr 2002 11:10:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TIA2Lr004593 for linux-xfs-outgoing; Mon, 29 Apr 2002 11:10:02 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.lbsd.net (mail.lbsd.net [196.25.111.97]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TI9VwJ004551 for ; Mon, 29 Apr 2002 11:09:38 -0700 Received: from localhost (nkukard@localhost) by mail.lbsd.net (8.12.1/8.12.1) with ESMTP id g3TIAfwB009042; Mon, 29 Apr 2002 20:10:41 +0200 Date: Mon, 29 Apr 2002 20:10:41 +0200 (SAST) From: Nigel Kukard To: Linux XFS Mailing List cc: Subject: ./configure - niceness Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=YiEDa0DAkWCtVeE4 Content-ID: Content-Disposition: INLINE 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. --YiEDa0DAkWCtVeE4 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Content-Disposition: INLINE SUMMARY ------- - Removed ROOT_PREFIX && PREFIX default environment variable usage - Fixed all configure *dir variables to properly work - Fixed --prefix & --exec-prefix and the like to work as expected as far as i can see everything builds & installs fine, including packages....etc, let me know if there any problems Kind Regards Nigel Kukard --YiEDa0DAkWCtVeE4 Content-Type: APPLICATION/X-GZIP; CHARSET=US-ASCII Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="xfs-1.1_prefix_fix.tar.gz" H4sIAByLzTwAA+1deVvbxtbPv/hTnOuSYMeWrdWySeFCwGl4QoAnkN6laR1h jbFejORXkgk0zXe/ZxbLspEXFtPQziQPlmY5muVsM7+Rxmn3FL2iVhqtfse7 qvSduN199sBB1VS1ZprPVFXVbEtN/2LQbdPWn6m2WTMM1TJ0C/ObumE+A/Wh K5IVBlHshADP/PPBuRO6U/PNS3+iwfU6HVAGoCg++aJ0vB7By5C0B2HkXRJw huxRbQd+xzsbhKk4xjKjhJyiKFkFVk4GBLb7IWg10Kx11VxX66DjwOdKpdJU aivvA5+V0huYmZUyeKmtLVAswyjbUOI/W1s5+AFc0nEGvTiCQhxAu+v4ZwSQ nbsROL5bDUIgV9is2DntkagMpwOv52J66FyQmIQYQ+J2cR0JUVoAu83XH38C ODw62Xu/99/mB4D32++aADs7APu7ACfbGPXfvSOAD0fvAbb/9Q7guIkJzZ23 hzmFkni/vb9/uLO/9xqp7R2ffNh7/fFk7/AA4Gh75932T83W6497+7uU9NGH 5pu9fyOpw8OTFr/JlW5DglU7xyu9sfqV/a4ra8ouu1r7trLyAyi7B+yO9Z+m W2rZNKHELrQ660P2T4lJFIPyO+RXU9XJw4sX6ept5PM5JQyCuNUPCY7bxnju NJUUgWHZ6iAKMU9SNCmFcednrQvHb7leiA3hOb5Vo64TkirG56DrXJLW716/ T1yase+ckWij4/QikoMOjrILng8ZJVNx9O4VuEEOaPA6wCvbgVWXpmn0T0Wr nP3OM8Rd4ueUlbGauTlYyaxJHA6wIiunIXHOefGOl8Nn+YT3Lm/hqTfZQoyh iTy5551OJGPMKDkapaeGYDLT6BljmcYe5PntiQdhTG/gklEWN5jMwrsU46sY hzl8FKFvrACQdjeAVafd8iHf7pL2ueefQTf4AiiS4cCnXQk7gIT6YdAmURSE +XylUmFF2nnQNl/Ucgojkk8UwbqmN7R1WJAcbL6wcqWbJGrW7UigEjj04Xjg o2aIAtQR3gWJYHXn6Ahoe1GpAPYKacdBeF3JjZgIG04zMXbnMa6IecUZCTkC 7za4FBqqXtYMKoV2jV5QKQT+aFqxA/LvkzK026A0aWUjFtkOXIIXYTA464qI iz7q7XAtovosImGZE/GDGP4PzVuSud3vV2hS24lhE2jv0BpWaOeTqxh+/LF5 +AZVV8/zCWDVaqkezKM+4vF6XR2Lhx8Ey/BY1MJRpZuO/tGJsE5xpbuZg+Nr P3auoBmGQZgD+jjU/604vEYlQFmg379Zrc2qSy6r/qDXA30zSQ0GMeqLr1Ag l06P811quA1NX4dPjCYS/5QvUtayXoncIrqI9Gjkt1xpGh29XrsNHdoYEoYb n8+Qn0C5hLXf4GVpDdK1hj9gmJr/bdTYr7y13z6t5j+n2IkqUE40xT/rgnm0 hmCehjFinvAClLCTPPLlkOHyq193dpR2+xtlJiUOHdeLvcB3egr2en5xttCN bLZo2E+ALfTGg7CFoRrfMVsYNc4Whqbeii38oBecBcget+AGU83kBkMznwA3 mLcS7uncgO7p98sNNjKBTbnBNOkF5Qbq+WD+yOmQjc/cVNLyXRdt3x8QERfW rp9XqiXleavVbz1f+zzFsFN3a1hwATNu2GbKBqcLTzHahlmfVYB2AOviPOuG T3nelrXVtbWva7Qml60ucVwStlZFa9dKEYm/rX3+lIcNbGec6q50AwttB5/q FsfaA4S5mIsKht3IFgzLuKVgiCZvLlUS6ubDSIJV/w4l4YbqY4JhamwGiW23 xRRyhVx5MWg55rFPZfgzEl85cRzSaYbSo1eL8L6p2ROsnEFnmhiMub+zytIO pXODSycUgk3T1lprSYEp4j1fkijZ1RH5+0gS735d493fsET3A9dJOKfC+e4x cjj9QVHgd7yZAMPYhaTQ1K1sKWw0FpLC6ks4vERm8jDF8a/hrN3Wsc9jEqLf hJOGIA7i6z6hcwnnMvBczASEmq0KwMsqK/8vAoOI0PWIEE5J26E3SAEuvLMu /qXLbcyJD0k8CNHrp+SCDs4u6LNEVxk66ypTrYmuGg5noZjDiawoqjKRYs3H 4ZwmoqaRGD3si/MsGaXxiZCO5jFR0ttC+ggVQDHupVmP1NRlPHKKU8P5OJNp N65JlBeKnPesrZU1ughimha9GC6CZAr/ly7B5+IoXsc4RCHaFRrrRXDqnRHf 9Rx/IUVgpyeiC9CcohRMs3EHOgsIeruVlHkQc3mD6sbAP/eDLz6dYh8TQqsU XUdVthRX6dJlPJRRPtV9/Z+TZuvwA10ju3DaYVBZVO7reqbcm1btltaX1ozK ZMQ80/F4UeNNwUt1nI1plJdqBr1gi5K0xZ3by2gjmV6IuX2WzIikRGwWkcSa fXfCU+TtB9iL0aMk0SvAUUU2IQk3ojXlo+lSDfl676dW82B3b/sAOZQuTiw8 mhNTy2Q0bW1po2mpJte5dn24wHy3sbTU+pLGsq4/+FjelFXUmGmFaemiWxr1 xGoDVnFSPXEriAoKDSJdhmIrbVTjoM08w35GFqFIA4p0FIn1K1RYTHXor4D7 Yax7b+V0W3o9k1EsVV+IUS4c9KcKRfhKn4i2eztEXibQ8+K4R9Uq1abAO+af AG/C4ALeOuGpFwX+i+OYkB7hdp93lWGzrrI0Lekq1rDCoNL+JfJ+J2jmC73A PyuCAtqvsLEBWvFVbiGmMrUHtag0vVCpDpP4CNDSyVxiJitamvXY1UnY+CbL +kGaY2u1WrmBw1AzVTEMzEs+8y6J34rCNlva5r8M/AidPqxR2eiEIObGn3IK wwk4z1QZckR5BmjCMJZ3B7KRcLHzUXX9l9/g15fV6ln+80jMhty9BhroyJq5 UtYjbz7r3s/h00cmR5uwunN48Ab18fHJ9snHYyFGwHvMNizuFNnqcGYUPd9C t/vk8HB/6/mquHp+xuLRtYqDoIfx4krEE58CbS2GFbiYOnaPeRTMk0JUMEfq TtDIAlgwY1Z0iqLAPQRFcZdKF+CJSBd3qfRoPEOUkWP8EdHNZwhcRWQQd6l0 AaqIdHEnWr1zdITx+HfUw9TX5z1Mr2i8GKo6Z27b0hLmnj3Cioh+s7ffPN74 tPo1fa/MZPU8Tvxnl75RLP9tDtt9Yql0SosyycBn1MDUh04TplBdMsXPX62K rHn4xwZcVSrCpN0eyK7gs6ahzxWKkmXD2ZiUYNOahW7IOpp405iPaKcLClAb /9dGoLZWpsu25RodydIPmKeqmlWaCnCA6q0H79gWBBygH8VuhK3eaeRWfBJv crxYgT0/ip1eTyDfL0ZqmplZJ/ZO0dTG14A1y5Vy4Po9GKAI8WkEm08gkbiL UwfWhRcUP0JNEsU52N5p7R3snRSGw4ztrHSLLF4M19vmNvrqhUldVeStU/mE XwL2dwPsjbKlU7CnVtYaYr0qrVOpq8YH4/jj6+OTwlhikYo+HWunxxYvcJZI QWHa0TCIQuDQLvp6fy76z9iRovNMp0MhCgZhmxR5vNOLAsGhqAyGuYDnoXPd M24TeO7CIBqgHFwDCtwuOUXHgLJQzLzRD8TtOtQXJYpdUYt/6U0HSsIQKVJp PskimLALWjYn9ChfzNi1MPYEkadI9wNQCqiNYq+NPvRpmKI0ZYPDGCWRJ6GE cwgKwgPnaLpmEJOLScIzt0aMkY8m6QuC402euYtinN5ky4dzDKpHo7nbLcZo iXwJKXQQRrsNbrktY4ywKFUcyhoTp4ixMDre6EBjx1IXw0NRQQHk8AnTEryf r7m2f9vceSeU/XGB5q+y5UhmDRJDvToGwdD0FsvV6jLLnaeLccJ2UwWHdo7Z B1stWxylwvoFg7iPQsu7kMZQxsQaHH48Ofp4UkC3hGWD18w4sMUGhmrzJvG1 VnjvnBMxCFOdm2KuNCJ7I0dxce/iRtkMLyMrz4S3kZUlw+swp3odMwmg96E1 1i17XUttqTOo51HCv3wzGDOrW4n7gDyJI8Hi7+Ka3M4xAcpGyIwd4PZyt/nm GH2Pnf2Pu83dVi4zFnD6zNph2gz+NhtljTPS0bufWj8jp1I7vAHM/75EBwLZ RCSOWWqRw0WXh4nBKNvQ+oscrGdJuJVTWOLeAdIZJYoZAk9EfyCdOJxg8MTj iaLReNnjicLReGlsfzp1OPHgie+3xygP51o8cfdwrORwSpIrcYXC4tkVRlFP rDWKT91i4kTzsfqczkTLsd6j+HSjo7ESx9OKpFoqmHuUlmooNnIUn2qj68QO TWAacmuoINmUaWdnBTO023izv0sve+7WHSWeLVNHM4WRZ5kl7zzH3cV9ojyV dizcwP8jaa8zbVsfLorsHeCcbH+/tX9CfdcNqlhX2i6sFk4Oj7ADi9XVAiYc bL9vFqsVHJboFctSqWCCKFsE5QJsy6I73lYL6aEs0szKzcw1bJBygh4cMl88 lEkYPanSc7wsUqV7kUpTghVhqwqTeqBIMQ+XOY7wxx9ZjU2ehiwREj+eU/Ec 8AVkPhXi4Kc6nLZn0j510H7N740bhY8nGpoau4ozSWEs8dbkejPp9ZzMgT+e VQZ9/OmPi4KbYz+HWkWbTU+sMI/xf2u3+TOOfvIUEUtXLfZ2koH8s3fuP0yg HhlTJPbyXgCZ/f6HZqqmOvn+h2mo8v2PxwjzzFzCHukXQMZ5ZvINkIwiE7ZM q63rtZQtm0Yv4x0QM/0OiMbfAdHkktLdlpS0Gt8byC5U+Q7IMpdjxCKeWdYt 2uO6zdd5RYc/iZdCqlRQ7/ZmiEKbyZGuESI1AnXZDpIhHsD3rQrczlgObrck mG55qJxpGGKrkmpJVO6RUTmcIrKhSLjTrOuMO03TlsDb7T0ItiY2zegni2HZ BTOmxfUFXImM5S8sqT9d8C1ZpWWrrkNtu5Fnu4H5FJ/NMaVzdDfnCF0iq077 r1HWDYm3SbxN4m1/HbxNeLKPD7oJEOtJYVsjO5wNbk2Y3Ono1mxCtzPsi+Bb jbFPRiwV37qt9b8fwsVf8DTrEuGSCNfyEK4p4jqEuGYJZBrjmknmHkKfiXIZ 2rqmSpRLolwS5ZIolwzzA6rRvsd0rL40AHAu/meZk/ifZUn871HCHCcgxR4p AHCSaSYQwMxCE5ZeryWrb9TST6eYgQFaEgN8sGUuw7DF90HohcQAl48BGpbF MUADJ3BPDwO86kSPBAGadZuDLDVNQoD0jVJLvJhn6fLFvD8dAqypJuNOq9aQ EOAdnAi6dDjd6g/XDKcVzVg3aCziTWS8g6fh/ycLA7KWTiCALE5CgA+wP8rk ECCqW12XEKCEACUE+BeCAJkj+50jgMp3gQCmjXAmBHjD3k7FAOeRumnXLXWG XZ+HAnL7rtUyUMDGd4AClu6JA5ocB7QlDihxwKXhgFNFVgCBs4UyhQTOIXQf 0c/GAhvrel1igRIL/JthgarEAmVYNKAX7A4u+kyzaktCAOfif/Yk/mdppiXx v8cIc4z/GHukEMCbbDOBAU4pOIkC2uuaNTLys6hm4IA1iQM+2FpX3ahzHJBd cByQrmgwtCP9lVAJDC4LGKxbNQ4M1s3GAsBg9GjIYPTdQYONep2BL42aLqFB +u2kGv+Qua4mB+JxCLDrCgQQL0bAoHvBI92LGd+YlEDgQkCgrmkq5UVdtS0J BN7Jm6BLiLNM/3DxcHrxjLUDbTG3InPB0Hh6gCASugj8Kv2EdaU9BgeK1ktA 8N5OEn17nwKCupECBJnGhl/LeP0L/zJ2cA6/SvRPon/LQP+ivy38l9Fyif89 Dv43bnczEcAMEzsVA5xPLsOcGzPN+WI4oJn1NuBfAAe0+CGydHugxAElDrgk HHCG2AokcJ5gprDAucTupwIy8MDGumEnB89LPFDigRIPlHigDKhJ6ZlcEVOl xnIAwDn4X82wrUn8zzB1if89Rphv9FPsMQ4ATvLNTQQws+jkt0DraJjHLPt0 uhkYYCONARocA5RHzNwNAzTrWlmjZ8yIC9aH2SdqLnDWYux6AT1PUWHH3Tqe X8BpqPjlR+zRhWV42dnoBH3iF/JDHOTS6eXLkP+SL76ic1qvA4V/dIri2MUC PSOvNIql628sjq7B9EN8VqfQwdLP3U8+UuHn7PFj9jg5QUblZFhxNXXsHix2 LudjnXMnTl1U+biIi9S4WPqtz8D8nsaFHYv88v4jg2bjzxmZmsVRc3Yh355d Pkhu1Y2yXqM9bteeMkjuns/I43rR+d2QdMhA0vlRgarFz8FMDrRdzjmY/Z4T IwNdtITqWfJxmPd93OKnYtomXV0rabaZ+v7uvJdpp5znOBh4Lsfa6dXfGmsf yQEmj27u9EpuXeev5Np1+VXeO/r1Yi1/ugueWsSfRiBj6c5a0MHPWLbXn/Lr uSgtV53JL/QOe0Ai8g+wbdEs11S6Zc4efqWXiYU4e457mS3qZbb6oJD/hzp1 oHCUdrFyB83C2+2fm62a+XoP63tCVyglbC9hewnbP1XYfgGnOik5yrtEvB+e Kt6ftu3TAP8bZnwW4j+PYIbTMGdVcBHMX88+4fL7xPzfb+98OMxA/SfjR+// WmVdZd8BFrvR0MKifX3HkJshbMkQ5eh8+FvpOSzf2+2D3f3mZE50N9weGV2x 3Dll910ai0657LnSeJIYE54GfBMBBZqGkLsAoGn0h+Z+c/s4SQlJjzjRMFFu XpCbFx5688JUDTTavTBbx4xvX5hD7p76LPsITzWZSckNDHIDg9zAIDcwyCCD DDLIIIMMMsgggwwyyCCDDDLIIIMMMsgggwwyyCCDDDLIIIMMMsjwNw//A2Hv FNkAyAAA --YiEDa0DAkWCtVeE4-- From owner-linux-xfs@oss.sgi.com Mon Apr 29 11:46: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 g3TIkOwJ007322 for ; Mon, 29 Apr 2002 11:46:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TIkOBM007321 for linux-xfs-outgoing; Mon, 29 Apr 2002 11:46:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from kungpao.alde.com ([216.12.238.181]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TIkAwJ007295 for ; Mon, 29 Apr 2002 11:46:14 -0700 Received: from kungpao.alde.com (localhost [127.0.0.1]) by kungpao.alde.com (8.12.2/8.12.2) with ESMTP id g3TIkw2L025516 for ; Mon, 29 Apr 2002 13:46:58 -0500 Received: from localhost (alde@localhost) by kungpao.alde.com (8.12.2/8.12.2/Debian -5) with ESMTP id g3TIkvmv025513 for ; Mon, 29 Apr 2002 13:46:57 -0500 X-Authentication-Warning: kungpao.alde.com: alde owned process doing -bs Date: Mon, 29 Apr 2002 13:46:57 -0500 (CDT) From: "Al D. Baran" To: linux-xfs@oss.sgi.com Subject: Running xfs_repair fails with malloc error Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Greetings, I'm running debian 3.0 beta with 2.4.18 kernel, running CVS downloaded kernel source. I have a disk /dev/hda: Disk /dev/hda: 255 heads, 63 sectors, 3736 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/hda1 * 1 102 819283+ 83 Linux /dev/hda2 103 168 530145 82 Linux swap /dev/hda3 169 806 5124735 83 Linux /dev/hda4 807 3736 23535225 83 Linux and its entries in fstab: /dev/hda1 / ext2 defaults,errors=remount-ro /dev/hda2 none swap sw /dev/hda3 /usr ext2 defaults /dev/hda4 /foo xfs logbufs=8,logbsize=32768,rw When running xfs_repair on /dev/hda4: Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... fatal error -- malloc failed in longform_dir2_entry_check (1073741836 bytes) # xfs_repair -V xfs_repair version 2.0.4 xfs_check reports: # xfs_check /dev/hda4 dir 21834061 block 0 entry /hristinaAngel bad inode number -72057594037927937 dir 21834061 block 8388608 extra leaf entry f784139b 9e dir ino 21834061 missing leaf entry for 97841398/9e link count mismatch for inode 21834061 (name ?), nlink 181, counted 180 disconnected inode 47456175, nlink 1 This is on a partition with appx 500k files and /dev/hda4 23530424 18565344 4965080 79% /foo I have an strace output if that is helpful... here are the last few lines: 6 _llseek(4, 17684439040, [17684439040], SEEK_SET) = 0 read(4, "IN\201\264\1\2\0\1\0\0\1\364\0\0\1\364\0\0\0\1\0\0\0\0"..., 8192) = 8192 old_mmap(NULL, 1073745920, PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = -1 ENOMEM (Cannot allocate memory) brk(0x484f4000) = 0x84f3000 old_mmap(NULL, 2097152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0x40232000 munmap(0x40232000, 843776) = 0 munmap(0x40400000, 204800) = 0 old_mmap(0x40300000, 32768, PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40300000 old_mmap(NULL, 1073745920, PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS, -1, ) = -1 ENOMEM (Cannot allocate memory) old_mmap(NULL, 1073745920, PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANONYMOUS, -1, ) = -1 ENOMEM (Cannot allocate memory) write(2, "\nfatal error -- ", 16) = 16 write(2, "malloc failed in longform_dir2_e"..., 62) = 62 _exit(1) = ? --Pete --- "Look, would it save you all this bother if I just gave up and went mad, Now?" "Imagination is more important than knowledge." --Einstein From owner-linux-xfs@oss.sgi.com Mon Apr 29 12:30:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TJUEwJ008216 for ; Mon, 29 Apr 2002 12:30:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TJU9fU008206 for linux-xfs-outgoing; Mon, 29 Apr 2002 12:30:09 -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 g3TJU4wJ008173 for ; Mon, 29 Apr 2002 12:30:05 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id OAA05219; Mon, 29 Apr 2002 14:30:48 -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 OAA03685; Mon, 29 Apr 2002 14:30:47 -0500 (CDT) Subject: Re: Running xfs_repair fails with malloc error From: Eric Sandeen To: "Al D. Baran" 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: 29 Apr 2002 14:30:47 -0500 Message-Id: <1020108647.5808.8.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Al - How are the files laid out? the malloc size is based on the size of the directory: freetab = malloc(FREETAB_SIZE(ip->i_d.di_size / mp->m_dirblksize)); Do you happen to have a -really- huge directory on the filesystem? Or maybe something has gone bad before this point... -Eric On Mon, 2002-04-29 at 13:46, Al D. Baran wrote: > fatal error -- malloc failed in longform_dir2_entry_check (1073741836 bytes) -- 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 29 12:29:23 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TJTNwJ008123 for ; Mon, 29 Apr 2002 12:29:23 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TJTN7q008122 for linux-xfs-outgoing; Mon, 29 Apr 2002 12:29:23 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta04.algx.net (chimta04.algx.net [216.99.233.79]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TJT9wJ008089 for ; Mon, 29 Apr 2002 12:29:09 -0700 Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx04.algx.net (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with ESMTP id <0GVC00GHD42M3K@chimmx04.algx.net> for linux-xfs@oss.sgi.com; Mon, 29 Apr 2002 09:54:32 -0500 (CDT) Date: Mon, 29 Apr 2002 10:50:31 -0400 (EDT) From: jtrostel@snapserver.com Subject: Re: default acl inheritence bug In-reply-to: <20020428190221.G21791@plato.local.lan> To: Ethan Benson Cc: linux-xfs@oss.sgi.com, Andreas Gruenbacher , Timothy Shimmin Reply-to: jtrostel@snapserver.com Message-id: Organization: Quantum Corp. / NASD MIME-version: 1.0 X-Mailer: XFMail 1.5.2 on Linux Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I do not see this behavior either (using code from CVS about 4/18) [root@jtsdell xfs_part]# getfacl test_dir # file: test_dir # owner: root # group: root user::rwx group::r-x other::r-x default:user::rwx default:user:a100:r-- default:group::r-x default:mask::r-x default:other::r-x [root@jtsdell xfs_part]# cd test_dir/ [root@jtsdell test_dir]# touch foo [root@jtsdell test_dir]# getfacl foo # file: foo # owner: root # group: root user::rw- user:a100:r-- group::r-x #effective:r-- mask::r-- other::r-- [root@jtsdell test_dir]# mkdir foo_dir [root@jtsdell test_dir]# getfacl foo_dir # file: foo_dir # owner: root # group: root user::rwx user:a100:r-- group::r-x mask::r-x other::r-x default:user::rwx default:user:a100:r-- default:group::r-x default:mask::r-x default:other::r-x On 29-Apr-2002 Ethan Benson wrote: > On Mon, Apr 29, 2002 at 12:35:05PM +1000, Timothy Shimmin wrote: >> Hi Ethan, >> >> Yeah your behaviour with the file gaining execute permission in the >> user ACE definitely looks wrong _but_ I can NOT repeat it locally. >> >> tes@sagan /mnt/xfs0/testdir/test1> setfacl -dm u:tes:r-- . >> tes@sagan /mnt/xfs0/testdir/test1> getfacl . >> # file: . >> # owner: tes >> # group: tes >> user::rwx >> group::rwx >> other::r-x >> default:user::rwx >> default:user:tes:r-- >> default:group::rwx >> default:mask::rwx >> default:other::r-x >> >> tes@sagan /mnt/xfs0/testdir/test1> touch foo >> tes@sagan /mnt/xfs0/testdir/test1> getfacl foo >> # file: foo >> # owner: tes >> # group: tes >> user::rw- >> user:tes:r-- >> group::rwx #effective:rw- >> mask::rw- >> other::r-- >> >> You could try adding printk's in >> linux/fs/xfs/xfs_acl.c/xfs_acl_inherit() & xfs_acl_filter_mode() and >> see what is going wrong. >> >> OOI, what is the output from running "check 051" in >> the cmd/xfstests directory (i.e. the acl regression test) ? >> (You need to look at cmd/xfstests/README about setting this stuff up; >> one needs to setup some variables to point to xfs filesystems etc...) > > i assume you used current CVS XFS? im on 2.4.18 split patches, so > perhaps this is already fixed, ill check again when 2.4.19 is released. > > -- > Ethan Benson > http://www.alaska.net/~erbenson/ -- John M. Trostel Senior Software Engineer Quantum Corp. / NASD jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Mon Apr 29 13:16:26 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TKGQwJ011152 for ; Mon, 29 Apr 2002 13:16:26 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TKGP46011151 for linux-xfs-outgoing; Mon, 29 Apr 2002 13:16:25 -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 g3TKGJwJ011121 for ; Mon, 29 Apr 2002 13:16:19 -0700 Received: (qmail 18539 invoked by uid 500); 29 Apr 2002 20:16:42 -0000 Subject: Chattr From: Austin Gonyou To: linux-xfs@oss.sgi.com Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-z+BGeDK/O5OXe8bkphJe" X-Mailer: Ximian Evolution 1.0.4.99 Date: 29 Apr 2002 15:16:42 -0500 Message-Id: <1020111402.18036.0.camel@UberGeek> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-z+BGeDK/O5OXe8bkphJe Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I know you guys are gonna shoot the hell outta me for this, but what can one do to set files immutable, as in chattr -i, with XFS? 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 --=-z+BGeDK/O5OXe8bkphJe 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 iD4DBQA8zaop94g6ZVmFMoIRAkQOAJjhDk+PA3ZXN+i228HeS7r/1+MLAJ4ztsMY hjEmjQHjvab0wbA8cIVfyg== =5ygw -----END PGP SIGNATURE----- --=-z+BGeDK/O5OXe8bkphJe-- From owner-linux-xfs@oss.sgi.com Mon Apr 29 13:59:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TKxawJ018784 for ; Mon, 29 Apr 2002 13:59:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TKxZJF018783 for linux-xfs-outgoing; Mon, 29 Apr 2002 13:59: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 g3TKxVwJ018757 for ; Mon, 29 Apr 2002 13:59:31 -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 QAA01627 for ; Mon, 29 Apr 2002 16:00:14 -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 QAA00502 for ; Mon, 29 Apr 2002 16:00:14 -0500 (CDT) From: Eric Sandeen Received: by stout.americas.sgi.com (8.11.6/SGI-client-1.7) id g3TL0EC07104; Mon, 29 Apr 2002 16:00:14 -0500 Message-Id: <200204292100.g3TL0EC07104@stout.americas.sgi.com> Date: Mon, 29 Apr 2002 16:00:14 -0500 Subject: TAKE - Error reporting in linvfs_lookup. Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk linvfs_lookup wasn't reporting all errors to the caller. My previous "fix" returned ENOENT as well, which is quite clearly documented as the wrong thing to do, in vfs.txt. :-) This will return any errors _except_ ENOENT up to the caller, in the ENOENT case the inode is null, and a negative dentry is created. Date: Mon Apr 29 13:57:56 PDT 2002 Workarea: stout.americas.sgi.com:/localhome/src/sandeen/2.4.x-xfs/workarea-alwaysclean The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117732a linux/fs/xfs/linux/xfs_iops.c - 1.134 - Error reporting - return any errors except ENOENT to caller From owner-linux-xfs@oss.sgi.com Mon Apr 29 14:07: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 g3TL7YwJ019084 for ; Mon, 29 Apr 2002 14:07:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TL7Y2N019083 for linux-xfs-outgoing; Mon, 29 Apr 2002 14:07: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 g3TL7UwJ019057 for ; Mon, 29 Apr 2002 14:07: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 QAA91458 for ; Mon, 29 Apr 2002 16:08:14 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id QAA32951 for ; Mon, 29 Apr 2002 16:08:14 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3TL7Xc22878; Mon, 29 Apr 2002 16:07:33 -0500 Message-Id: <200204292107.g3TL7Xc22878@jen.americas.sgi.com> Date: Mon, 29 Apr 2002 16:07:33 -0500 Subject: TAKE - irq fix up To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk >From Andi Kleen, a couple of remaining uses of the wrong type for irq values. Date: Mon Apr 29 14:07:07 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117735a linux/fs/xfs/xfs_dquot_item.c - 1.26 - fix a use of int for irq values linux/fs/xfs/linux/xfs_vnode.h - 1.29 - use unsigned long for irq values From owner-linux-xfs@oss.sgi.com Mon Apr 29 14:54:35 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TLsZwJ020040 for ; Mon, 29 Apr 2002 14:54:35 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TLsZJV020039 for linux-xfs-outgoing; Mon, 29 Apr 2002 14:54:35 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from kungpao.alde.com ([216.12.238.181]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TLsNwJ020011 for ; Mon, 29 Apr 2002 14:54:27 -0700 Received: from kungpao.alde.com (localhost [127.0.0.1]) by kungpao.alde.com (8.12.2/8.12.2) with ESMTP id g3TLtC2L031884; Mon, 29 Apr 2002 16:55:12 -0500 Received: from localhost (alde@localhost) by kungpao.alde.com (8.12.2/8.12.2/Debian -5) with ESMTP id g3TLtBNL031881; Mon, 29 Apr 2002 16:55:11 -0500 X-Authentication-Warning: kungpao.alde.com: alde owned process doing -bs Date: Mon, 29 Apr 2002 16:55:10 -0500 (CDT) From: "Al D. Baran" To: Eric Sandeen cc: linux-xfs@oss.sgi.com Subject: Re: Running xfs_repair fails with malloc error In-Reply-To: <1020108647.5808.8.camel@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 The largest directory has 15k entries: Total for ./web/k/k_labo: = 1720 Total for ./web/j: = 3120 Total for ./web/com/cgi-bin/aa: = 5113 Total for ./web/6794: = 5732 Total for ./web/tabo: = 15244 the largest nested directory structure is 15: Longest is ./web/com/cgi-bin/aa/scan/rf=0,title,price,description,pic,picb,code,act1,act2,act3/fi=products.asc/rl=title/sp=results2/ra=yes/rm=0/rx=999/rg=yes/st=text with 15 --Pete On 29 Apr 2002, Eric Sandeen wrote: > Date: 29 Apr 2002 14:30:47 -0500 > From: Eric Sandeen > To: Al D. Baran > Cc: linux-xfs@oss.sgi.com > Subject: Re: Running xfs_repair fails with malloc error > > Hi Al - > > How are the files laid out? the malloc size is based on the size of the > directory: > > freetab = malloc(FREETAB_SIZE(ip->i_d.di_size / mp->m_dirblksize)); > > Do you happen to have a -really- huge directory on the filesystem? Or > maybe something has gone bad before this point... > > -Eric > > On Mon, 2002-04-29 at 13:46, Al D. Baran wrote: > > > fatal error -- malloc failed in longform_dir2_entry_check (1073741836 bytes) > > -- > Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs > sandeen@sgi.com SGI, Inc. > --- "Look, would it save you all this bother if I just gave up and went mad, Now?" "Imagination is more important than knowledge." --Einstein From owner-linux-xfs@oss.sgi.com Mon Apr 29 15:32:55 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TMWtwJ021288 for ; Mon, 29 Apr 2002 15:32:55 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TMWtd2021287 for linux-xfs-outgoing; Mon, 29 Apr 2002 15:32:55 -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 g3TMWmwJ021255 for ; Mon, 29 Apr 2002 15:32:48 -0700 Received: from erbenson.alaska.net (198-pm32.nwc.alaska.net [209.112.158.198]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3TMXVu05767; Mon, 29 Apr 2002 14:33: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 B263039D5; Mon, 29 Apr 2002 14:33:29 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 413A21028A; Mon, 29 Apr 2002 14:33:30 -0800 (AKDT) Date: Mon, 29 Apr 2002 14:33:30 -0800 From: Ethan Benson To: jtrostel@snapserver.com Cc: linux-xfs@oss.sgi.com, Andreas Gruenbacher Subject: Re: default acl inheritence bug Message-ID: <20020429143330.J21791@plato.local.lan> Mail-Followup-To: jtrostel@snapserver.com, linux-xfs@oss.sgi.com, Andreas Gruenbacher References: <20020428190221.G21791@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9iyR+p8Z2cn535Lj" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jtrostel@snapserver.com on Mon, Apr 29, 2002 at 10:50:31AM -0400 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 --9iyR+p8Z2cn535Lj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2002 at 10:50:31AM -0400, jtrostel@snapserver.com wrote: > [root@jtsdell test_dir]# mkdir foo_dir > [root@jtsdell test_dir]# getfacl foo_dir > # file: foo_dir > # owner: root > # group: root > user::rwx > user:a100:r-- ^^^^ and this is not broken? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --9iyR+p8Z2cn535Lj 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 iEYEARECAAYFAjzNyjkACgkQJKx7GixEevyu0gCeJQcQAwtkEW7QT2sFeEDRLMR4 ZTQAoIRX0SAFQQt5FojltT7hKx5vtfSW =t6Tu -----END PGP SIGNATURE----- --9iyR+p8Z2cn535Lj-- From owner-linux-xfs@oss.sgi.com Mon Apr 29 16:06: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 g3TN6CwJ022288 for ; Mon, 29 Apr 2002 16:06:12 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TN6CXx022287 for linux-xfs-outgoing; Mon, 29 Apr 2002 16:06:12 -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-d514e1f2.dsl.mediaWays.net [213.20.225.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TN67wJ022261 for ; Mon, 29 Apr 2002 16:06:08 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 172KEM-0007kH-00 for linux-xfs@oss.sgi.com; Tue, 30 Apr 2002 01:06:50 +0200 Message-ID: <3CCDD20A.B3D65343@berdmann.de> Date: Tue, 30 Apr 2002 01:06:50 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: SGI XFS 1.0.2a ISO / xfsrestore in rescue mode Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, this ISO images misses libhandle.so.0 and libattr.so.0 in rescue mode, so xfsrestore fails due to these libraries missing. I have a workaround: mke2fs a floppy, mount it and copy (cp -p) /sbin/xfsrestore, /lib/libattr.so.0 and /lib/libhandle.0 to it. Don't forget to umount before ejecting. When being in rescue mode booted off the CD or its bootnet.img and network, mount the floppy to /fl and call xfsrestore in this way: LD_LIBRARY_PATH=/fl /fl/xfsrestore -r - . XFS developers: please make sure xfsrestore is working on the next ISO. It is very handy for disaster recovery oder just for cloning systems. From owner-linux-xfs@oss.sgi.com Mon Apr 29 16:25:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TNPwwJ023762 for ; Mon, 29 Apr 2002 16:25:58 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TNPwI9023761 for linux-xfs-outgoing; Mon, 29 Apr 2002 16:25:58 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cafes.net (ip3-182.cafes.net [207.65.182.3] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TNPrwJ023735 for ; Mon, 29 Apr 2002 16:25:53 -0700 Received: by mail.cafes.net (Postfix, from userid 500) id D6743633C6FC; Mon, 29 Apr 2002 18:26:17 -0500 (CDT) Date: Mon, 29 Apr 2002 18:26:17 -0500 From: Mike Eldridge To: linux-xfs@oss.sgi.com Subject: Re: Hi! Where can I download xfs patches for 2.5.10? Message-ID: <20020429182617.D8336@ornery.cafes.net> References: <200204292046.40876.ivans@isle.spb.ru> <1020100778.2131.1.camel@stout.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020100778.2131.1.camel@stout.americas.sgi.com>; from sandeen@sgi.com on Mon, Apr 29, 2002 at 12:19:37PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Apr 29, 2002 at 12:19:37PM -0500, Eric Sandeen wrote: > Hi Michael - > > Currently 2.5.10 + XFS is only available from CVS. The patch generation > scripts broke when Linus changed his tarball format, and I have not > fixed them yet. So CVS is the only way to go for now. you mention "patch generation scripts" -- are these publically available? i attempted to patch a 2.4.19-pre7 kernel and ran into quite a few rejections. i fixed most of them, but it seems the pre7 kernel has some changes with respect to the quota stuff that are a bit over my head at this point in time. -mike -------------------------------------------------------------------------- /~\ the ascii all that is gold does not glitter \ / ribbon campaign not all those who wander are lost X against html -- jrr tolkien / \ email! radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Apr 29 16:33: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 g3TNXiwJ024001 for ; Mon, 29 Apr 2002 16:33:44 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TNXiY3024000 for linux-xfs-outgoing; Mon, 29 Apr 2002 16:33:44 -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-d514e1f2.dsl.mediaWays.net [213.20.225.242]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TNXGwJ023951 for ; Mon, 29 Apr 2002 16:33:16 -0700 Received: from apollo.berdmann.de ([192.168.1.2] helo=berdmann.de) by ente.berdmann.de with esmtp (Exim 3.22 #1) id 172Kee-00084J-00 for linux-xfs@oss.sgi.com; Tue, 30 Apr 2002 01:34:00 +0200 Message-ID: <3CCDD868.39BE6C38@berdmann.de> Date: Tue, 30 Apr 2002 01:34:00 +0200 From: "Bernhard R. Erdmann" X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.18-SGI_XFS_1.1 i586) X-Accept-Language: de, en, fr MIME-Version: 1.0 To: Linux XFS Mailing List Subject: "XFS User Survey" is broken References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk > > Release 1.1 need to be added to the Version field at the XFS User Survey > > at http://oss.sgi.com/projects/xfs/survey.html Mason error error in file: /oss/www/mason/obj/projects/xfs/surveyinput.html line 43: Can't locate Mail/Sender.pm in @INC (@INC contains: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux /usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl . /etc/httpd/ /etc/httpd/lib/perl) context: ... 39: 40: 41: use Data::Dumper; 42: use POSIX qw(strftime); 43: use Mail::Sender; 44: 45: $m->comp('xfsTemplate',top=>1,side=>1); 46: $_out->(' 47:

The XFS team thanks you for your response.

... code stack: /oss/www/mason/obj/projects/xfs/surveyinput.html:43 Mail/Sender.pm:43 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Parser.pm:1177 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm:378 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm:116 raw_error raw error: Error during compilation of /oss/www/projects/xfs/surveyinput.html: Can't locate Mail/Sender.pm in @INC (@INC contains: /usr/lib/perl5/5.6.1/i386-linux /usr/lib/perl5/5.6.1 /usr/lib/perl5/site_perl/5.6.1/i386-linux /usr/lib/perl5/site_perl/5.6.1 /usr/lib/perl5/site_perl/5.6.0/i386-linux /usr/lib/perl5/site_perl/5.6.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.6.1/i386-linux /usr/lib/perl5/vendor_perl/5.6.1 /usr/lib/perl5/vendor_perl . /etc/httpd/ /etc/httpd/lib/perl) at /oss/www/mason/obj/projects/xfs/surveyinput.html line 43. HTML::Mason::Interp::__ANON__('Can\'t locate Mail/Sender.pm in @INC (@INC contains: /usr/lib/pe...') called at /oss/www/mason/obj/projects/xfs/surveyinput.html line 43 HTML::Mason::Commands::BEGIN() called at Mail/Sender.pm line 43 eval {...} called at Mail/Sender.pm line 43 require /oss/www/mason/obj/projects/xfs/surveyinput.html called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Parser.pm line 1177 HTML::Mason::Parser::eval_object_text('HTML::Mason::Parser=HASH(0x843270c)', 'object_file', '/oss/www/mason/obj/projects/xfs/surveyinput.html', 'error', 'SCALAR(0x82a6834)') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 378 HTML::Mason::Interp::load('HTML::Mason::Interp=HASH(0x843546c)', '/projects/xfs/surveyinput.html') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 HTML::Mason::Request::exec('HTML::Mason::Request::ApacheHandler=HASH(0x8425a20)', '/projects/xfs/surveyinput.html', 'DRIVE1', 'ide', 'DRIVE2', 'scsi', 'HARDWARE', 'ia32', ...) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 914 HTML::Mason::ApacheHandler::handle_request_1('HTML::Mason::ApacheHandler=HASH(0x84353f4)', 'Apache=SCALAR(0x83fbf14)', 'HTML::Mason::Request::ApacheHandler=HASH(0x8425a20)', undef) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x84353f4)', 'Apache=SCALAR(0x83fbf14)') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 1019 HTML::Mason::ApacheHandler::handler('Apache=SCALAR(0x83fbf14)') called at Mail/Sender.pm line 43 eval {...} called at Mail/Sender.pm line 43 BEGIN failed--compilation aborted at /oss/www/mason/obj/projects/xfs/surveyinput.html line 43. HTML::Mason::Interp::__ANON__('Can\'t locate Mail/Sender.pm in @INC (@INC contains: /usr/lib/pe...') called at /oss/www/mason/obj/projects/xfs/surveyinput.html line 43 require /oss/www/mason/obj/projects/xfs/surveyinput.html called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Parser.pm line 1177 HTML::Mason::Parser::eval_object_text('HTML::Mason::Parser=HASH(0x843270c)', 'object_file', '/oss/www/mason/obj/projects/xfs/surveyinput.html', 'error', 'SCALAR(0x82a6834)') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 378 HTML::Mason::Interp::load('HTML::Mason::Interp=HASH(0x843546c)', '/projects/xfs/surveyinput.html') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 HTML::Mason::Request::exec('HTML::Mason::Request::ApacheHandler=HASH(0x8425a20)', '/projects/xfs/surveyinput.html', 'DRIVE1', 'ide', 'DRIVE2', 'scsi', 'HARDWARE', 'ia32', ...) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 914 HTML::Mason::ApacheHandler::handle_request_1('HTML::Mason::ApacheHandler=HASH(0x84353f4)', 'Apache=SCALAR(0x83fbf14)', 'HTML::Mason::Request::ApacheHandler=HASH(0x8425a20)', undef) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x84353f4)', 'Apache=SCALAR(0x83fbf14)') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 1019 HTML::Mason::ApacheHandler::handler('Apache=SCALAR(0x83fbf14)') called at /oss/www/mason/obj/projects/xfs/surveyinput.html line 43 eval {...} called at /oss/www/mason/obj/projects/xfs/surveyinput.html line 43 HTML::Mason::Interp::__ANON__('Error during compilation of /oss/www/projects/xfs/surveyinput.ht...') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 418 HTML::Mason::Interp::_compilation_error('HTML::Mason::Interp=HASH(0x843546c)', '/oss/www/projects/xfs/surveyinput.html', 'Can\'t locate Mail/Sender.pm in @INC (@INC contains: /usr/lib/pe...') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 386 HTML::Mason::Interp::load('HTML::Mason::Interp=HASH(0x843546c)', '/projects/xfs/surveyinput.html') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 HTML::Mason::Request::exec('HTML::Mason::Request::ApacheHandler=HASH(0x8425a20)', '/projects/xfs/surveyinput.html', 'DRIVE1', 'ide', 'DRIVE2', 'scsi', 'HARDWARE', 'ia32', ...) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 914 HTML::Mason::ApacheHandler::handle_request_1('HTML::Mason::ApacheHandler=HASH(0x84353f4)', 'Apache=SCALAR(0x83fbf14)', 'HTML::Mason::Request::ApacheHandler=HASH(0x8425a20)', undef) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x84353f4)', 'Apache=SCALAR(0x83fbf14)') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 1019 HTML::Mason::ApacheHandler::handler('Apache=SCALAR(0x83fbf14)') called at /dev/null line 0 eval {...} called at /dev/null line 0 From owner-linux-xfs@oss.sgi.com Mon Apr 29 16:35: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 g3TNZ2wJ024094 for ; Mon, 29 Apr 2002 16:35:02 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TNZ18F024093 for linux-xfs-outgoing; Mon, 29 Apr 2002 16:35:01 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.cafes.net (ip3-182.cafes.net [207.65.182.3] (may be forged)) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3TNYtwJ024062 for ; Mon, 29 Apr 2002 16:34:55 -0700 Received: by mail.cafes.net (Postfix, from userid 500) id 385EF671E1FC; Mon, 29 Apr 2002 18:35:20 -0500 (CDT) Date: Mon, 29 Apr 2002 18:35:20 -0500 From: Mike Eldridge To: linux-xfs@oss.sgi.com Subject: Re: poor io performance with xfs+raid5 Message-ID: <20020429183520.E8336@ornery.cafes.net> References: <20020425135652.I16048@ornery.cafes.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020425135652.I16048@ornery.cafes.net>; from diz@cafes.net on Thu, Apr 25, 2002 at 01:56:52PM -0500 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Thu, Apr 25, 2002 at 01:56:52PM -0500, Mike Eldridge wrote: > xfs/kernel gurus, > > i am having a problem with a xfs fs on a raid5 array. i experience > extremely poor i/o performance. i notice a LOT of processes enter into > an uninterruptable sleep state when attempting to read/write to the xfs > filesystem. hi all, i thank you all for the feedback regarding my problem. after a good 18 hours of downtime (backing up 40GB of data from the xfs partition took most of that time), all of my i/o problems have disappeared. for those interested, here's what i did: - used the escalade for RAID0 across the 4 20GB drives - created the fs with an external 32MB log (even though it's currently using a seperate partition on the same array for the log) - mounted using logbufs=8 i'm pretty sure that it was the small log that was giving my problems, as this box is a mail server that does a lot of fs updates. i intend to recreate the problem on a test machine i have here with the same setup to make sure. thanks all, -mike -------------------------------------------------------------------------- /~\ the ascii all that is gold does not glitter \ / ribbon campaign not all those who wander are lost X against html -- jrr tolkien / \ email! radiusd+mysql: http://www.cafes.net/~diz/kiss-radiusd -------------------------------------------------------------------------- From owner-linux-xfs@oss.sgi.com Mon Apr 29 16:54:57 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3TNsvwJ024860 for ; Mon, 29 Apr 2002 16:54:57 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3TNsujL024859 for linux-xfs-outgoing; Mon, 29 Apr 2002 16:54: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 g3TNsqwJ024833 for ; Mon, 29 Apr 2002 16:54:52 -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 QAA2285571 for ; Mon, 29 Apr 2002 16:55:40 -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 JAA27640; Tue, 30 Apr 2002 09:54:23 +1000 Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.9.3/8.9.3) id JAA00740; Tue, 30 Apr 2002 09:54:23 +1000 (AEST) Date: Tue, 30 Apr 2002 09:54:22 +1000 From: Nathan Scott To: Nigel Kukard Cc: Linux XFS Mailing List Subject: Re: ./configure - niceness Message-ID: <20020430095422.A100718@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 nkukard@lbsd.net on Mon, Apr 29, 2002 at 08:10:41PM +0200 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, Apr 29, 2002 at 08:10:41PM +0200, Nigel Kukard wrote: > SUMMARY > ------- > - Removed ROOT_PREFIX && PREFIX default environment variable usage > - Fixed all configure *dir variables to properly work > - Fixed --prefix & --exec-prefix and the like to work as expected > > > as far as i can see everything builds & installs fine, including > packages....etc, let me know if there any problems > > > Kind Regards > Nigel Kukard > Thanks Nigel, I'll have a proper look though it as soon as I get a chance. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Apr 29 17:37:17 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3U0bHwJ025695 for ; Mon, 29 Apr 2002 17:37:17 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U0bHlH025694 for linux-xfs-outgoing; Mon, 29 Apr 2002 17:37:17 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from blount.mail.mindspring.net (blount.mail.mindspring.net [207.69.200.226]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3U0b7wJ025668 for ; Mon, 29 Apr 2002 17:37:07 -0700 Received: from user-vcaujjg.dsl.mindspring.com ([216.175.78.112] helo=jtsdell) by blount.mail.mindspring.net with esmtp (Exim 3.33 #1) id 172LeP-0001vg-00; Mon, 29 Apr 2002 20:37:49 -0400 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: <20020429143330.J21791@plato.local.lan> Date: Mon, 29 Apr 2002 20:34:02 -0400 (EDT) Reply-To: jtrostel@snapserver.com Organization: Quantum Corp. / NASD From: jtrostel@snapserver.com To: Ethan Benson Subject: Re: default acl inheritence bug Cc: Andreas Gruenbacher , linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On 29-Apr-2002 Ethan Benson wrote: > On Mon, Apr 29, 2002 at 10:50:31AM -0400, jtrostel@snapserver.com wrote: > >> [root@jtsdell test_dir]# mkdir foo_dir >> [root@jtsdell test_dir]# getfacl foo_dir >> # file: foo_dir >> # owner: root >> # group: root >> user::rwx >> user:a100:r-- > ^^^^ > and this is not broken? Er... um... I don't think so. I had an access and a default acl on the parent directory of user::rwx group::r-x other::r-x default:user::rwx default:user:a100:r-- default:group::r-x default:mask::r-x default:other::r-x The default acl will be applied to foo_dir [root@jtsdell test_dir]# mkdir foo_dir [root@jtsdell test_dir]# getfacl foo_dir # file: foo_dir # owner: root # group: root user::rwx user:a100:r-- group::r-x mask::r-x other::r-x default:user::rwx default:user:a100:r-- default:group::r-x default:mask::r-x default:other::r-x So both the default and the access acls on foo_dir are the same and include an entry of r-- for the additional user 'a100'. >From the 'acl' man page: If a default ACL is associated with a directory, the mode parameter to the functions creating file objects and the default ACL of the directory are used to determine the ACL of the new object: 1. The new object inherits the default ACL of the containing directory as its access ACL. 2. The access ACL entries corresponding to the file permission bits are modified so that they contain no permissions that are not contained in the permissions specified by the mode parameter. -- John M. Trostel Senior Software Engineer Quantum Corp. / NASD jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Mon Apr 29 17:51: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 g3U0pOwJ026063 for ; Mon, 29 Apr 2002 17:51:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U0pOUh026062 for linux-xfs-outgoing; Mon, 29 Apr 2002 17:51:24 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mta4-rme.xtra.co.nz (mta4-rme.xtra.co.nz [210.86.15.132]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3U0pFwJ026034 for ; Mon, 29 Apr 2002 17:51:16 -0700 Received: from localhost.localdomain ([210.86.78.169]) by mta4-rme.xtra.co.nz with ESMTP id <20020430005149.EFOH13839.mta4-rme.xtra.co.nz@localhost.localdomain>; Tue, 30 Apr 2002 12:51:49 +1200 Subject: Re: Hi! Where can I download xfs patches for 2.5.10? From: mdew To: Mike Eldridge Cc: xfs In-Reply-To: <20020429182617.D8336@ornery.cafes.net> References: <200204292046.40876.ivans@isle.spb.ru> <1020100778.2131.1.camel@stout.americas.sgi.com> <20020429182617.D8336@ornery.cafes.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-k6uD7Imp/ibIWb9v7IJ9" X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 12:51:53 +1200 Message-Id: <1020127914.492.65.camel@mdew> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk --=-k6uD7Imp/ibIWb9v7IJ9 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2002-04-30 at 11:26, Mike Eldridge wrote: > On Mon, Apr 29, 2002 at 12:19:37PM -0500, Eric Sandeen wrote: > > Hi Michael -=20 > >=20 > > Currently 2.5.10 + XFS is only available from CVS. The patch generation > > scripts broke when Linus changed his tarball format, and I have not > > fixed them yet. So CVS is the only way to go for now. >=20 > you mention "patch generation scripts" -- are these publically > available? >=20 > i attempted to patch a 2.4.19-pre7 kernel and ran into quite a few > rejections. i fixed most of them, but it seems the pre7 kernel has some > changes with respect to the quota stuff that are a bit over my head at > this point in time. >=20 > -mike Why not try Andrea's VM+fixes? Runs fine on here... http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre= 7aa2.gz http://www.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre= 7aa2.bz2 --=20 ph33r! Linux mdew 2.4.19-pre7-xfs-aa #4 Fri Apr 26 12:14:19 NZST 2002 i686 unknown GPG Key: http://mdew.orcon.net.nz/gpg =20=20 --=-k6uD7Imp/ibIWb9v7IJ9 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 iD8DBQA8zeqpH5J/xul0J+4RAgW4AJ9r8KoXlRSPZfmIY7Jx4KcMlAWV9QCfWX/K o8YNLcO9dvieXfn6j21Vswc= =G0No -----END PGP SIGNATURE----- --=-k6uD7Imp/ibIWb9v7IJ9-- From owner-linux-xfs@oss.sgi.com Mon Apr 29 18:00:37 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3U10bwJ026289 for ; Mon, 29 Apr 2002 18:00:37 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U10biC026288 for linux-xfs-outgoing; Mon, 29 Apr 2002 18:00:37 -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.52]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3U10WwJ026262 for ; Mon, 29 Apr 2002 18:00:33 -0700 Received: by china.sercomm.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 48256BAB.0005D33E ; Tue, 30 Apr 2002 09:03:37 +0800 X-Lotus-FromDomain: CHINA From: ken@sernet.com.cn To: Seth Mos cc: linux-xfs@oss.sgi.com Message-ID: <48256BAB.0005D1DE.00@china.sercomm.com> Date: Tue, 30 Apr 2002 09:03:33 +0800 Subject: Re: 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 seth: Linux kernel my use is 2.4.14,is XFS patched. xfs_repair is get from xfs_progs.2.0.3-0.i386.rpm Message print when I repairing: " Phrase 1-Find and verify superblock...." "Out of Memory : killed process 2761(xfs_repair)." then end the application. If this is my memory reason.(RAM 64M --include 16M ramdisk). rgds ken From owner-linux-xfs@oss.sgi.com Mon Apr 29 18:08: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 g3U18WwJ026661 for ; Mon, 29 Apr 2002 18:08:32 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U18W0h026660 for linux-xfs-outgoing; Mon, 29 Apr 2002 18:08: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 g3U18QwJ026630 for ; Mon, 29 Apr 2002 18:08:26 -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 UAA08102; Mon, 29 Apr 2002 20:09:10 -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 UAA63898; Mon, 29 Apr 2002 20:09:10 -0500 (CDT) Date: Mon, 29 Apr 2002 20:09:10 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Mike Eldridge cc: linux-xfs@oss.sgi.com Subject: Re: Hi! Where can I download xfs patches for 2.5.10? In-Reply-To: <20020429182617.D8336@ornery.cafes.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 29 Apr 2002, Mike Eldridge wrote: > you mention "patch generation scripts" -- are these publically > available? I could make them available, but... > i attempted to patch a 2.4.19-pre7 kernel and ran into quite a few > rejections. i fixed most of them, but it seems the pre7 kernel has some > changes with respect to the quota stuff that are a bit over my head at > this point in time. That's not what they do. The scripts I talked about automatically check out CVS and diff against the latest 2.4.X-preY kernel, then upload the resulting patch to oss.sgi.com. The "latest 2.4.X-preY kernel" part of the script is broken atm. If you want to try patching xfs against a -pre kernel, I'd suggest using the mergetrees kernel, that's how I usually merge in a new kernel. You use it something like: mergetrees linux-pre linux linux-xfs linux-pre-xfs where the last 4 arguments are the -pre kernel, the (previous) vanilla kernel, the current linux-xfs tree (based on the vanilla kernel) and the resulting tree with the -pre and the -xfs code. It's not magic, but it can make merging easier sometimes. -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 29 18:10:14 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3U1AEwJ026763 for ; Mon, 29 Apr 2002 18:10:14 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U1AEoC026762 for linux-xfs-outgoing; Mon, 29 Apr 2002 18:10: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 g3U1AAwJ026736 for ; Mon, 29 Apr 2002 18:10:10 -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 UAA09306; Mon, 29 Apr 2002 20:10:54 -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 UAA75836; Mon, 29 Apr 2002 20:10:54 -0500 (CDT) Date: Mon, 29 Apr 2002 20:10:54 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: "Bernhard R. Erdmann" cc: Linux XFS Mailing List Subject: Re: "XFS User Survey" is broken In-Reply-To: <3CCDD868.39BE6C38@berdmann.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 30 Apr 2002, Bernhard R. Erdmann wrote: > > > Release 1.1 need to be added to the Version field at the XFS User Survey > > > at http://oss.sgi.com/projects/xfs/survey.html Yep, it's missing a perl module. OTOH oss seems to be broken in several ways at the moment, this one seems kind of minor. :( -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 29 20:19: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 g3U3JuwJ028888 for ; Mon, 29 Apr 2002 20:19:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U3Ju7K028887 for linux-xfs-outgoing; Mon, 29 Apr 2002 20:19:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from mail.broadpark.no (217-13-4-9.dd.nextgentel.com [217.13.4.9]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3U3JnwJ028860 for ; Mon, 29 Apr 2002 20:19:49 -0700 Received: from broadpark.no (213-187-174-3.dd.nextgentel.com [213.187.174.3]) by mail.broadpark.no (Postfix) with ESMTP id A79DA7E32 for ; Tue, 30 Apr 2002 00:56:04 +0200 (MEST) Message-ID: <3CCDCF84.2@broadpark.no> Date: Tue, 30 Apr 2002 00:56:04 +0200 From: Kjell Randa User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901 X-Accept-Language: en-us MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Log messages Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi, After some work work on several filesystem including mkfs -t xfs, xfs_repair, .. I find the fpllowing messages in /var/log/messages Apr 30 00:14:27 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x80041272 Apr 30 00:14:58 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x40041271 Apr 30 00:14:58 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x80041272 Apr 30 00:15:08 eagle syslogd 1.4.1: restart. Apr 30 00:16:06 eagle kernel: XFS mounting filesystem lvm(58,9) Apr 30 00:17:51 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x40041271 Apr 30 00:17:51 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x80041272 Apr 30 00:20:33 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x40041271 Apr 30 00:20:33 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x80041272 Apr 30 00:26:31 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x40041271 Apr 30 00:26:31 eagle kernel: lvm -- lvm_blk_ioctl: unknown command 0x80041272 Apr 30 00:26:59 eagle kernel: XFS mounting filesystem lvm(58,9) Anything to worry about? Running 2.4.9-31SGI_XFS_1.1smp on redHat 7.2 using lvm and software raid 0. Regards Kjell Randa From owner-linux-xfs@oss.sgi.com Mon Apr 29 20:59:20 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3U3xKwJ029445 for ; Mon, 29 Apr 2002 20:59:20 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U3xKvJ029444 for linux-xfs-outgoing; Mon, 29 Apr 2002 20:59:20 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3U3xCwJ029404 for ; Mon, 29 Apr 2002 20:59:12 -0700 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.55.149]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id VAA2296061 for ; Mon, 29 Apr 2002 21:00:01 -0700 (PDT) mail_from (nathans@snort.melbourne.sgi.com) Received: (from nathans@localhost) by snort.melbourne.sgi.com (SGI-8.9.3/8.9.3) id NAA70362 for linux-xfs@oss.sgi.com; Tue, 30 Apr 2002 13:58:44 +1000 (EST) Date: Tue, 30 Apr 2002 13:58:44 +1000 (EST) From: Nathan Scott Message-Id: <200204300358.NAA70362@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - pagebuf Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk More blocksize changes; MikeO, I think the last one is the problem you're hitting with large files in the pagesize blocksize case too, let me know whether/not this helps. cheers. Date: Sun Apr 28 22:09:04 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117662a linux/fs/xfs/pagebuf/page_buf.c - 1.18 - move the block number calculation outside the loop for >pgize blocksizes; also fix up locking of buffer_heads in here. Date: Mon Apr 29 17:48:06 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117771a linux/fs/xfs/pagebuf/page_buf.c - 1.19 - tidy up some of the new multiple blocksize code paths, fix an inconsistent block number calculation along the way causing me occasional log corruption. Date: Mon Apr 29 20:54:26 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117794a linux/fs/xfs/pagebuf/page_buf_io.c - 1.30 - ensure page index -> offset calculation done in 64 bits to prevent falsely tripping __pb_match_offset_to_mapping BUG test with large offsets. From owner-linux-xfs@oss.sgi.com Mon Apr 29 23:21:25 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3U6LPwJ031192 for ; Mon, 29 Apr 2002 23:21:25 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U6LPmJ031191 for linux-xfs-outgoing; Mon, 29 Apr 2002 23:21:25 -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 g3U6LFwJ031163 for ; Mon, 29 Apr 2002 23:21:15 -0700 Received: from erbenson.alaska.net (201-pm32.nwc.alaska.net [209.112.158.201]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3U6M4u19797 for ; Mon, 29 Apr 2002 22:22:04 -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 46BEB39D5 for ; Mon, 29 Apr 2002 22:22:03 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 2A5491028A; Mon, 29 Apr 2002 22:22:03 -0800 (AKDT) Date: Mon, 29 Apr 2002 22:22:03 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: default acl inheritence bug Message-ID: <20020429222203.K21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020429143330.J21791@plato.local.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="451BZW+OUuJBCAYj" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jtrostel@snapserver.com on Mon, Apr 29, 2002 at 08:34:02PM -0400 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 --451BZW+OUuJBCAYj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 29, 2002 at 08:34:02PM -0400, jtrostel@snapserver.com wrote: > default:user::rwx > default:user:a100:r-- > default:group::r-x > default:mask::r-x > default:other::r-x >=20 > The default acl will be applied to foo_dir so please explain how to set a default acl which will grant user a100 r-- for newly created files and r-x for newly created directories.=20=20 > So both the default and the access acls on foo_dir are the same and inclu= de an > entry of r-- for the additional user 'a100'. >=20 > >From the 'acl' man page: >=20 > If a default ACL is associated with a directory, the mode parameter = to > the functions creating file objects and the default ACL of the direc= tory > are used to determine the ACL of the new object: >=20 > 1. The new object inherits the default ACL of the containing direc= tory > as its access ACL. >=20 > 2. The access ACL entries corresponding to the file permission bit= s are > modified so that they contain no permissions that are not conta= ined > in the permissions specified by the mode parameter. >=20 the way i read this #2 should ensure that execute permission is removed from user a100 for file creation if the default acl lists a100:r-x, but thats not what occurs, user a100 is always given execute permission to the newly created file, which is not desired. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --451BZW+OUuJBCAYj 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 iEYEARECAAYFAjzOOAsACgkQJKx7GixEevxJHgCfXTkAy5sy7ED85cr8UZ+afErx DK8AnidJCLaHut8f8C7As0CBSHtVBWdZ =g1tT -----END PGP SIGNATURE----- --451BZW+OUuJBCAYj-- From owner-linux-xfs@oss.sgi.com Tue Apr 30 00:15:09 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3U7F8wJ031672 for ; Tue, 30 Apr 2002 00:15:08 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U7F8Se031671 for linux-xfs-outgoing; Tue, 30 Apr 2002 00:15:08 -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 g3U7F0wJ031645 for ; Tue, 30 Apr 2002 00:15:01 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by deliverator.sgi.com (980309.SGI.8.8.8-aspam-6.2/980310.SGI-aspam) via ESMTP id AAA2294847 for ; Tue, 30 Apr 2002 00:15:50 -0700 (PDT) mail_from (tes@boing.melbourne.sgi.com) Received: (from tes@localhost) by boing.melbourne.sgi.com (SGI-8.9.3/8.9.3) id RAA02391; Tue, 30 Apr 2002 17:14:28 +1000 (AEST) Date: Tue, 30 Apr 2002 17:14:28 +1000 From: Timothy Shimmin To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: default acl inheritence bug Message-ID: <20020430171428.L793932@boing.melbourne.sgi.com> References: <20020429143330.J21791@plato.local.lan> <20020429222203.K21791@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0us In-Reply-To: <20020429222203.K21791@plato.local.lan>; from erbenson@alaska.net on Mon, Apr 29, 2002 at 10:22:03PM -0800 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ethan, On Mon, Apr 29, 2002 at 10:22:03PM -0800, Ethan Benson wrote: > On Mon, Apr 29, 2002 at 08:34:02PM -0400, jtrostel@snapserver.com wrote: > > default:user::rwx > > default:user:a100:r-- > > default:group::r-x > > default:mask::r-x > > default:other::r-x > > > > The default acl will be applied to foo_dir > > so please explain how to set a default acl which will grant user a100 > r-- for newly created files and r-x for newly created directories. You can't. This is not a bug - it is the way it is :) You'd really need separate defaul ACLs for files and dirs as you suggested earlier. And as mentioned previously, this kind of thing is achieved for normal unix permissions by the userspace commands setting up the appropriate mode parameter. > > > So both the default and the access acls on foo_dir are the same and include an > > entry of r-- for the additional user 'a100'. > > > > >From the 'acl' man page: > > > > If a default ACL is associated with a directory, the mode parameter to > > the functions creating file objects and the default ACL of the directory > > are used to determine the ACL of the new object: > > > > 1. The new object inherits the default ACL of the containing directory > > as its access ACL. > > > > 2. The access ACL entries corresponding to the file permission bits are > > modified so that they contain no permissions that are not contained > > in the permissions specified by the mode parameter. > > > > the way i read this #2 should ensure that execute permission is > removed from user a100 for file creation if the default acl lists > a100:r-x, but thats not what occurs, user a100 is always given execute > permission to the newly created file, which is not desired. The mode bits specify the permissions, ugo, which parallel with USER_OBJ, GROUP_OBJ (or MASK ACE if there is one) and OTHER ACEs - not USER ACEs. --Tim From owner-linux-xfs@oss.sgi.com Tue Apr 30 00:29: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 g3U7TpwJ031995 for ; Tue, 30 Apr 2002 00:29:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U7TpJM031994 for linux-xfs-outgoing; Tue, 30 Apr 2002 00:29:51 -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 g3U7TgwJ031966 for ; Tue, 30 Apr 2002 00:29:42 -0700 Received: from erbenson.alaska.net (201-pm32.nwc.alaska.net [209.112.158.201]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3U7UUu59551 for ; Mon, 29 Apr 2002 23:30:30 -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 956F939D5 for ; Mon, 29 Apr 2002 23:30:29 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 8B1721028A; Mon, 29 Apr 2002 23:30:29 -0800 (AKDT) Date: Mon, 29 Apr 2002 23:30:29 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: default acl inheritence bug Message-ID: <20020429233029.L21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <20020429143330.J21791@plato.local.lan> <20020429222203.K21791@plato.local.lan> <"from erbenson"@alaska.net> <20020430171428.L793932@boing.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HTLCc13+3hfAZ6SL" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020430171428.L793932@boing.melbourne.sgi.com>; from tes@boing.melbourne.sgi.com on Tue, Apr 30, 2002 at 05:14:28PM +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 --HTLCc13+3hfAZ6SL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2002 at 05:14:28PM +1000, Timothy Shimmin wrote: > Hi Ethan, >=20 > On Mon, Apr 29, 2002 at 10:22:03PM -0800, Ethan Benson wrote: > > On Mon, Apr 29, 2002 at 08:34:02PM -0400, jtrostel@snapserver.com wrote: > > > default:user::rwx > > > default:user:a100:r-- > > > default:group::r-x > > > default:mask::r-x > > > default:other::r-x > > >=20 > > > The default acl will be applied to foo_dir > >=20 > > so please explain how to set a default acl which will grant user a100 > > r-- for newly created files and r-x for newly created directories.=20= =20 > You can't. > This is not a bug - it is the way it is :) that is broken. > You'd really need separate defaul ACLs for files and dirs=20 > as you suggested earlier. which is what should be done then IMO. --=20 Ethan Benson http://www.alaska.net/~erbenson/ --HTLCc13+3hfAZ6SL 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 iEYEARECAAYFAjzOSBUACgkQJKx7GixEevzU0ACgmPErdTUEfEC7j1qw0F66YHeb suoAnRxJP/WcuQ2Vk4rQ4FXLCZCbT1w6 =BbTR -----END PGP SIGNATURE----- --HTLCc13+3hfAZ6SL-- From owner-linux-xfs@oss.sgi.com Tue Apr 30 02:41: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 g3U9fjwJ002846 for ; Tue, 30 Apr 2002 02:41:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U9fjUf002845 for linux-xfs-outgoing; Tue, 30 Apr 2002 02:41: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 g3U9ffwJ002819 for ; Tue, 30 Apr 2002 02:41:41 -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 EAA13387 for ; Tue, 30 Apr 2002 04:42:27 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id EAA60166 for ; Tue, 30 Apr 2002 04:42:27 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3U9fej30418; Tue, 30 Apr 2002 04:41:40 -0500 Message-Id: <200204300941.g3U9fej30418@jen.americas.sgi.com> Date: Tue, 30 Apr 2002 04:41:40 -0500 Subject: TAKE - more irq changes to unsigned long To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Apr 30 02:41:04 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-jen The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117798a linux/fs/xfs/xfs_qm_syscalls.c - 1.58 linux/fs/xfs/xfs_vfsops.c - 1.342 linux/fs/xfs/xfs_mount.c - 1.279 linux/fs/xfs/xfs_qm.c - 1.72 linux/fs/xfs/xfs_utils.c - 1.41 linux/fs/xfs/xfs_fsops.c - 1.75 linux/fs/xfs/xfs_bmap.c - 1.281 linux/fs/xfs_dmapi/dmapi_session.c - 1.6 From owner-linux-xfs@oss.sgi.com Tue Apr 30 02:55: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 g3U9tRwJ003177 for ; Tue, 30 Apr 2002 02:55:27 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3U9tRNZ003176 for linux-xfs-outgoing; Tue, 30 Apr 2002 02:55: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 g3U9tLwJ003150 for ; Tue, 30 Apr 2002 02:55:21 -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 EAA13412; Tue, 30 Apr 2002 04:56:07 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id EAA54158; Tue, 30 Apr 2002 04:56:07 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3U9tKZ02413; Tue, 30 Apr 2002 04:55:20 -0500 Message-Id: <200204300955.g3U9tKZ02413@jen.americas.sgi.com> Date: Tue, 30 Apr 2002 04:55:20 -0500 Subject: TAKE - better mmap write support in pagebuf To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Some multiple blocksize work, and better optimization of allocation and writes in the mmap write case where memory pressure is the cause of data getting flushed. We used to fragment files really badly in this case, now fragmentation is reasonable - which causes major speedup of some loads. Tridge, this one fixes fstest -m Steve Date: Tue Apr 30 02:52:40 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-base The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: 2.4.x-xfs:slinx:117799a linux/fs/xfs/linux/xfs_iops.c - 1.135 - Fix writepage for the case of unmapped buffer heads from mmap write, and writepage and release page checks in the variable blocksize case. linux/fs/xfs/pagebuf/page_buf_io.c - 1.31 - Add support for clustering pages written via mmap write - massive speedup in the case of heavy mmap write pressure. From owner-linux-xfs@oss.sgi.com Tue Apr 30 03:34: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 g3UAYVwJ003705 for ; Tue, 30 Apr 2002 03:34:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UAYUYP003704 for linux-xfs-outgoing; Tue, 30 Apr 2002 03:34:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UAYEwJ003677 for ; Tue, 30 Apr 2002 03:34:14 -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 FAA11823 for ; Tue, 30 Apr 2002 05:35: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 FAA39218 for ; Tue, 30 Apr 2002 05:35:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3UAYDm11725; Tue, 30 Apr 2002 05:34:13 -0500 Message-Id: <200204301034.g3UAYDm11725@jen.americas.sgi.com> Date: Tue, 30 Apr 2002 05:34:13 -0500 Subject: TAKE - merge changes into 2.5 tree To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Push a bunch of stuff onto the 2.5 xfs tree, this should include all the x86-64 related changes. Date: Tue Apr 30 02:44:14 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: sandeen Merged by: lord Merged mods: 2.4.x-xfs:slinx:116695a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:116695a linux/fs/xfs/xfs_log_recover.c - 1.226 - Merge of 2.4.x-xfs:slinx:116695a by lord. Cut and paste error - s/last_blk/new_blk Subject: TAKE - Date: Tue Apr 30 03:12:35 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Author: sandeen Merged by: lord Merged mods: 2.4.x-xfs:slinx:116903a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:116903a linux/fs/xfs/xfs_vfsops.c - 1.341 - Merge of 2.4.x-xfs:slinx:116903a by lord. set mount struct flag for irixsgid linux/fs/xfs/xfs_clnt.h - 1.27 - Merge of 2.4.x-xfs:slinx:116903a by lord. add mount option flag for irixsgid linux/fs/xfs/xfs_mount.h - 1.139 - Merge of 2.4.x-xfs:slinx:116903a by lord. add mount struct flag for irixsgid linux/fs/xfs/xfs_inode.c - 1.336 - Merge of 2.4.x-xfs:slinx:116903a by lord. 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.175 - Merge of 2.4.x-xfs:slinx:116903a by lord. add irixsgid mount opton to mimic irix sgid bit inheritance linux/Documentation/filesystems/xfs.txt - 1.9 - Merge of 2.4.x-xfs:slinx:116903a by lord. Document irixsgid mount option Subject: TAKE - Date: Tue Apr 30 03:26:54 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Merged by: lord Merged mods: 2.4.x-xfs:slinx:117593a,2.4.x-xfs:slinx:117604a,2.4.x-xfs:slinx:117624a 2.4.x-xfs:slinx:117732a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:117800a linux/fs/xfs/xfsidbg.c - 1.182 - Merge of 2.4.x-xfs:slinx:117604a originally by sandeen on 04/26/02 Fix up vnode tracing - remove alloc tracing cases from vnode trace function - add VMODIFIED to list of known flags linux/fs/xfs/linux/xfs_iops.c - 1.135 - Merge of 2.4.x-xfs:slinx:117593a originally by sandeen on 04/26/02 Be sure to return an error if VOP_LOOKUP or linvfs_revalidate_core fails Merge of 2.4.x-xfs:slinx:117624a originally by sandeen on 04/26/02 Whoops, that last change doesn't work, ENOENT is a "normal" error that apparently should not be passed back up. Back it all out for now. Merge of 2.4.x-xfs:slinx:117732a originally by sandeen on 04/29/02 Error reporting - return any errors except ENOENT to caller linux/fs/xfs/linux/xfs_ioctl.c - 1.60 - Merge of 2.4.x-xfs:slinx:117593a originally by sandeen on 04/26/02 Return error with correct (+) sign if linvfs_revalidate_core fails Subject: TAKE - Date: Tue Apr 30 03:33:22 PDT 2002 Workarea: jen.americas.sgi.com:/src/lord/xfs-linux.2.5 Merged by: lord Merged mods: 2.4.x-xfs:slinx:117735a,2.4.x-xfs:slinx:117798a The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.5.x-xfs Modid: 2.5.x-xfs:slinx:117801a linux/fs/xfs/xfs_qm_syscalls.c - 1.59 - Merge of 2.4.x-xfs:slinx:117798a originally by lord on 04/30/02 more irq changes to unsigned long linux/fs/xfs/xfs_dquot_item.c - 1.26 - Merge of 2.4.x-xfs:slinx:117735a originally by lord on 04/29/02 fix a use of int for irq values linux/fs/xfs/xfs_vfsops.c - 1.342 linux/fs/xfs/xfs_mount.c - 1.280 linux/fs/xfs/xfs_qm.c - 1.73 linux/fs/xfs/xfs_utils.c - 1.41 linux/fs/xfs/xfs_fsops.c - 1.76 linux/fs/xfs/xfs_bmap.c - 1.281 - Merge of 2.4.x-xfs:slinx:117798a originally by lord on 04/30/02 more irq changes to unsigned long linux/fs/xfs/linux/xfs_vnode.h - 1.31 - Merge of 2.4.x-xfs:slinx:117735a originally by lord on 04/29/02 use unsigned long for irq values linux/fs/xfs_dmapi/dmapi_session.c - 1.6 - Merge of 2.4.x-xfs:slinx:117798a originally by lord on 04/30/02 more irq changes to unsigned long From owner-linux-xfs@oss.sgi.com Tue Apr 30 04:50: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 g3UBoDwJ004893 for ; Tue, 30 Apr 2002 04:50:13 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UBoDHu004892 for linux-xfs-outgoing; Tue, 30 Apr 2002 04:50:13 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from netsgo.com ([211.39.34.130]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UBnpwJ004854 for ; Tue, 30 Apr 2002 04:49:52 -0700 Received: from unknown[210.93.208.137] (envelope sender: ) by 211.39.34.130 (TERRACE MAILCENTER) with ESMTP for ; Tue, 30 Apr 2002 20:48:37 KST +0900 Message-ID: <000801c1f03d$0df0a2f0$89d05dd2@netsgo.com> From: "Heejoon Park" To: Subject: Cannot see pdf or ps files... Date: Tue, 30 Apr 2002 20:49:12 +0900 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 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id g3UBoDwJ004894 Hello, I cannot see any pdf or ps files in http://oss.sgi.com/projects/xfs page. I got the following error. I'd appreciated if you can fix it. -------------------> Mason error error in file: /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf line 13: '<%' with no matching '%>' context: ... 9: H‰ŒV?£H}??bÍÕ‰ve?)ì¾8?Cc??º‰×û??Ûë¬V??rêÔ©‚ûÒ??‚²?/font> 10: ñ¯€œAž†A–C?!¬½ÛÇ??ïËšþí¼?,:Q+ CµÝˆZÃïÃŒ?÷Õv???~ó¾–èðè1??@???~åk?/MBH?LŽ×?öî?D 2F€?–À??:wu͵žÍ?dIú¿ÕF??D‹E<›³8 11: ºÛp|:@%O ??E["‰kh?"ŽN?@½×†÷'I Wg]ut?wA¹Áxª?K ×õ VX???GUáí?Ï»q?µYÏ»C ?/font> 12: t?u??ˆS?$¡±.õ¦’k?œž?Ç®??äµ9eÕéS)à &1°S1„“?Q-zò«??JT?Ke&?6?~??†KM%’·"1YµäŠJ?1|F²Õ???c „Õ?vŸt?W2;‰Ÿ‘µ©Þ)? ?¼ê€z¶½q?¶˜???z:J?·ž?æñ"™–??gÿ‡F?9KB?B?ª œåiPøû-Æø|›ÄYA¡æM\úè?³Ðÿ_ûÄ ³U???Cy??uxmj:N?äí æê¯q[\e…–??©jÕ¶YòÝ8ëôÄúDl?Ñ©v-????l°JcIŒu 13: ‹ ?NhÜ­qO»4q à½?;ÞíØÙÚô–×ÂUt.Q‡¤??çÓŠÈ?™ù?F?ÕâoŒk?", ÇÊd?RN?r?n?m³©(!?l?¤© ¨/>{?«it??j??x??ôÍ8??N{?O?1gù¤ýð¨½Ô¿??DÁYxŒE<%þ±aâø¢´â¥???Ì»$?f?.b”ó???­zZ?âªH]0m??6/¢boh¼G?’µ§Ûª‰f?lt;Ãc?l–ñ? 14: Ýã4Ew¼¿p?ƒx?–úôãâ\vB¾¡Ašçh`]XŒ¢9ÆÇ?ÓõÉé?j¿Ä?,?0/ ?/?}s-?wÿÅûG€<â´ 15: endstream 16: endobj 17: 3 0 obj ... code stack: /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf:13 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm:374 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm:116 raw_error raw error: Error during compilation of /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf: '' (line 13) HTML::Mason::Interp::__ANON__('Error during compilation of /oss/www/projects/xfs/design_docs/xf...') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 418 HTML::Mason::Interp::_compilation_error('HTML::Mason::Interp=HASH(0x80e6c04)', '/oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf', '\'\' (line 13)^J') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 374 HTML::Mason::Interp::load('HTML::Mason::Interp=HASH(0x80e6c04)', '/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 HTML::Mason::Request::exec('HTML::Mason::Request::ApacheHandler=HASH(0x82a9dd8)', '/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 914 HTML::Mason::ApacheHandler::handle_request_1('HTML::Mason::ApacheHandler=HASH(0x80e6b8c)', 'Apache=SCALAR(0x8539ff0)', 'HTML::Mason::Request::ApacheHandler=HASH(0x82a9dd8)', undef) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x80e6b8c)', 'Apache=SCALAR(0x8539ff0)') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 1019 HTML::Mason::ApacheHandler::handler('Apache=SCALAR(0x8539ff0)') called at /dev/null line 0 eval {...} called at /dev/null line 0 [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Tue Apr 30 04:54: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 g3UBsUwJ006539 for ; Tue, 30 Apr 2002 04:54:30 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UBsUxe006538 for linux-xfs-outgoing; Tue, 30 Apr 2002 04:54:30 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from n-top.com ([203.236.43.170]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UBsFwJ006511 for ; Tue, 30 Apr 2002 04:54:16 -0700 Received: by n-top.com (6.5.019) id 3CCD684200004729 for linux-xfs@oss.sgi.com; Tue, 30 Apr 2002 20:49:36 +0900 Date: Tue, 30 Apr 2002 20:49:36 +0900 (added by postmaster@n-top.com) Message-ID: <3CCD684200004729@wmbox10.n-top.com> From: "mrbliss" To: linux-xfs@oss.sgi.com Subject: Cannot see pdf or ps files... Reply-To: mrbliss@nate.com MIME-Version: 1.0 References: N Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id g3UBsHwJ006513 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hello, I cannot see any pdf or ps files in http://oss.sgi.com/projects/xfs page. I got the following error. I'd appreciated if you can fix it. -------------------> Mason error error in file: /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf line 13: '<%' with no matching '%>' context: ... 9: H뎹V?쥹}??뢡ÍÕ룊ve?)ì¾8?Cc??틝×û??Ûë촚??rêÔ쯾ûÒ??궟?/font> 10: ñ¯€쏛엱A뺺?!¬½ÛÇ??ïË쌏í¼?,:Q+ 뢇µÝ늎Ãï횑?÷Õv???~ó¾뽬ðè1??@???~곩k?/MBH?L롒?öî?D 2F€?뼽??:wu͵왤?dI멁¿ÕF??D딢<쎋8 11: ºÛp|:@%O ??E["뎽kh?"랲?@½×놑'I Wg]ut?wA¹Áx뜧?K ×õ VX???G뛘áí?Ï»q?킱Ï»C ?/font> 12: t?u??늆?$¡±.õ¦뭟?쐾?Ç®??äµ9eÕéS)씳 &1캳1꼻?Q-zò«??JT?Ke&?6?~??낻M%뮮"1Yµä둎?1|F²Õ???c 꾎?v웪?W2;돓뫓©Þ)? ?¼ê€z뜺뤍q?텣???z:J?퇍?æñ"솘??gÿ놣?9KB?B?첓쒎iPøû-Æø|쎝YA¡æM\úè?³Ðÿ_ûÄ 쿢???Cy??uxmj:N?äí졿ê¯q[\e뀟??쯬Õ¶YòÝ8ëôÄúDl?Ñ©v-????l캨cI똵 13: 떊?NhÜ­qO퍖4q à½?;ÞíØÙÚô뽛헧t.Q눃??çÓ듗?숛?F?Õâo똩?", ÇÊd?R륬?r?n?m³©(!?l?¤©젴/>{?쳃t??j??x??ôÍ8??N{?O?1gù¤ýð¨½Ô¿??D햊x똄<%þ±aâø¢´â¥???Ì»$?f?.b뷆???춟Z?âªH]0m??6/줮걇h퍰?뮫§Û챼f?lt;홤?l뽵?걧 14: Ýã4Ew¼¿p?긹?혯úôãâ\vB¾¡A싩h`]X뙝9ÆÇ?ÓõÉé?j¿Ä?,?0/ ?/?}s-?wÿÅûG€<â´ 15: endstream 16: endobj 17: 3 0 obj ... code stack: /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf:13 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm:374 /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm:116 raw_error raw error: Error during compilation of /oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf: '' (line 13) HTML::Mason::Interp::__ANON__('Error during compilation of /oss/www/projects/xfs/design_docs/xf...') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 418 HTML::Mason::Interp::_compilation_error('HTML::Mason::Interp=HASH(0x80e6c04)', '/oss/www/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf', '\'\' (line 13)^J') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Interp.pm line 374 HTML::Mason::Interp::load('HTML::Mason::Interp=HASH(0x80e6c04)', '/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/Request.pm line 116 HTML::Mason::Request::exec('HTML::Mason::Request::ApacheHandler=HASH(0x82a9dd8)', '/projects/xfs/design_docs/xfsdocs93_pdf/64bit.pdf') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 914 HTML::Mason::ApacheHandler::handle_request_1('HTML::Mason::ApacheHandler=HASH(0x80e6b8c)', 'Apache=SCALAR(0x8539ff0)', 'HTML::Mason::Request::ApacheHandler=HASH(0x82a9dd8)', undef) called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 eval {...} called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 560 HTML::Mason::ApacheHandler::handle_request('HTML::Mason::ApacheHandler=HASH(0x80e6b8c)', 'Apache=SCALAR(0x8539ff0)') called at /usr/lib/perl5/site_perl/5.6.1/HTML/Mason/ApacheHandler.pm line 1019 HTML::Mason::ApacheHandler::handler('Apache=SCALAR(0x8539ff0)') called at /dev/null line 0 eval {...} called at /dev/null line 0 ======================================================= test From owner-linux-xfs@oss.sgi.com Tue Apr 30 05:02: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 g3UC2pwJ008626 for ; Tue, 30 Apr 2002 05:02:51 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UC2pp4008625 for linux-xfs-outgoing; Tue, 30 Apr 2002 05:02:51 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UC2mwJ008599 for ; Tue, 30 Apr 2002 05:02: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 HAA14401; Tue, 30 Apr 2002 07:03:34 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-15.corp.sgi.com [134.15.64.15]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id HAA41380; Tue, 30 Apr 2002 07:03:33 -0500 (CDT) Subject: Re: Cannot see pdf or ps files... From: Stephen Lord To: Heejoon Park Cc: linux-xfs@oss.sgi.com In-Reply-To: <000801c1f03d$0df0a2f0$89d05dd2@netsgo.com> References: <000801c1f03d$0df0a2f0$89d05dd2@netsgo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 06:55:36 -0500 Message-Id: <1020167737.1706.1.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-30 at 06:49, Heejoon Park wrote: > Hello, I cannot see any pdf or ps files in http://oss.sgi.com/projects/xfs page. > > I got the following error. > I'd appreciated if you can fix it. > It is an Apache configuration problem since the machine was reinstalled, not sure when it will get fixed - someone already tried once. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 30 06:51: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 g3UDpLwJ010969 for ; Tue, 30 Apr 2002 06:51:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UDpLnG010968 for linux-xfs-outgoing; Tue, 30 Apr 2002 06:51:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UDpHwJ010942 for ; Tue, 30 Apr 2002 06:51:17 -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 IAA15627; Tue, 30 Apr 2002 08:52:03 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id IAA67731; Tue, 30 Apr 2002 08:52:03 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3UDpF925452; Tue, 30 Apr 2002 08:51:15 -0500 Subject: Re: Chattr From: Steve Lord To: Austin Gonyou Cc: linux-xfs@oss.sgi.com In-Reply-To: <1020111402.18036.0.camel@UberGeek> References: <1020111402.18036.0.camel@UberGeek> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 08:51:14 -0500 Message-Id: <1020174674.24262.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Mon, 2002-04-29 at 15:16, Austin Gonyou wrote: > I know you guys are gonna shoot the hell outta me for this, but what can > one do to set files immutable, as in chattr -i, with XFS? TIA > -- Sorry, no can do, XFS does not have an immutable inode concept. All you can do is close the permissions down on the inode. 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 30 06:57:36 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UDvawJ011166 for ; Tue, 30 Apr 2002 06:57:36 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UDvaui011165 for linux-xfs-outgoing; Tue, 30 Apr 2002 06:57:36 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from shakti.rupa.com (foobar@adsl-66-125-43-50.dsl.lsan03.pacbell.net [66.125.43.50]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UDvSwJ011139 for ; Tue, 30 Apr 2002 06:57:28 -0700 Received: from shakti.rupa.com (localhost [127.0.0.1]) by localhost.rupa.com (Postfix) with ESMTP id CCB6F4D4CB for ; Tue, 30 Apr 2002 06:58:18 -0700 (PDT) Mailbox-Line: From rupa-list@rupa.com Tue Apr 30 06:58:20 2002 Received: by shakti.rupa.com (Postfix, from userid 9) id C51834D4C9; Tue, 30 Apr 2002 06:58:18 -0700 (PDT) Received: from 192.168.1.20 by 192.168.1.20 with nntp; 30 Apr 2002 06:58:18 PDT To: linux-xfs@oss.sgi.com Subject: OOPS - 2.4.18 xfs from March 19ish From: Rupa Schomaker Mail-Copies-To: never Date: Tue, 30 Apr 2002 06:58:18 -0700 Message-ID: User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) Cancel-Lock: sha1:hRcOAQgi8RMi/s9gHMiB61RGuUo= MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 192.168.1.20 X-Spam-Status: No, hits=-100.0 required=5.0 tests=USER_IN_WHITELIST version=2.20 X-Spam-Level: Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk CVS 2.4.18 xfs kernel from around March 19. Dunno if this is an XFS problem, but thought I'd start here. Uptime is 41days. Kernel went into kdb, did a "go" and we kept on going. The system was doing a backup at the time (backup continued after "go"). Clock was frozen while in kdb, had to manually run ntpdate to sync it back up... Right after dumping the oops, I got one entry of: Apr 30 01:14:39 shakti kernel: <4>eth0: card reports no resources. eth0 is i82557/i82558 10/100 Ethernet, 00:60:B0:3C:DD:62, IRQ 12. bt in kdb agreed with the ksymoops output: Warning (expand_objects): object /lib/modules/2.4.18-xfs-lvm/kernel/drivers/md/lvm-mod.o for module lvm-mod has changed since load Warning (compare_maps): mismatch on symbol partition_name , ksyms_base says c026c150, System.map says c0150a70. Ignoring ksyms_base entry Apr 30 01:14:39 shakti kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000 Apr 30 01:14:39 shakti kernel: 00000000 Apr 30 01:14:39 shakti kernel: *pde = 00000000 Apr 30 01:14:39 shakti kernel: Oops: 0000 Apr 30 01:14:39 shakti kernel: CPU: 0 Apr 30 01:14:39 shakti kernel: EIP: 0010:[<00000000>] Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 Apr 30 01:14:39 shakti kernel: EFLAGS: 00010286 Apr 30 01:14:39 shakti kernel: eax: 00000000 ebx: e5829444 ecx: e5829330 edx: e582820c Apr 30 01:14:39 shakti kernel: esi: 00000202 edi: c03d4f80 ebp: e7fe9f18 esp: e7fe9f04 Apr 30 01:14:39 shakti kernel: ds: 0018 es: 0018 ss: 0018 Apr 30 01:14:39 shakti kernel: Process kswapd (pid: 4, stackpage=e7fe9000) Apr 30 01:14:39 shakti kernel: Stack: c01faa06 e582820c 00000000 e5829320 e72f8400 e7fe9f24 c01f9d41 e5829444 Apr 30 01:14:39 shakti kernel: e7fe9f3c c0141a9d e5829320 cee9f0f8 cee9f0e0 e5829320 e7fe9f54 c013f926 Apr 30 01:14:39 shakti kernel: e5829320 00000010 000001d0 00000020 e7fe9f60 c013fc0c 00000620 e7fe9f84 Apr 30 01:14:39 shakti kernel: Call Trace: [] [] [] [] [] Apr 30 01:14:39 shakti kernel: [] [] [] [] [] [] Apr 30 01:14:39 shakti kernel: Code: Bad EIP value. >>EIP; 00000000 Before first symbol >>ebx; e5829444 <_end+253c4024/283adbe0> >>ecx; e5829330 <_end+253c3f10/283adbe0> >>edx; e582820c <_end+253c2dec/283adbe0> >>edi; c03d4f80 >>ebp; e7fe9f18 <_end+27b84af8/283adbe0> >>esp; e7fe9f04 <_end+27b84ae4/283adbe0> Trace; c01faa06 Trace; c01f9d41 Trace; c0141a9d Trace; c013f926 Trace; c013fc0c Trace; c0128e78 Trace; c0128ed1 Trace; c0128f74 Trace; c0128fde Trace; c0129107 Trace; c01056e4 -- -rupa From owner-linux-xfs@oss.sgi.com Tue Apr 30 07:25:31 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UEPVwJ011581 for ; Tue, 30 Apr 2002 07:25:31 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UEPUst011580 for linux-xfs-outgoing; Tue, 30 Apr 2002 07:25:30 -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 g3UEPNwJ011552 for ; Tue, 30 Apr 2002 07:25:23 -0700 Received: from erbenson.alaska.net (29-pm21.nwc.alaska.net [209.112.143.29]) by hob.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3UEQEw13333 for ; Tue, 30 Apr 2002 06:26:14 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id D0F473924 for ; Tue, 30 Apr 2002 06:26:11 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 398081028A; Tue, 30 Apr 2002 06:26:08 -0800 (AKDT) Date: Tue, 30 Apr 2002 06:26:08 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020430062608.M21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="00hq2S6J2Jlg6EbK" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020174674.24262.0.camel@jen.americas.sgi.com>; from lord@sgi.com on Tue, Apr 30, 2002 at 08:51:14AM -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 --00hq2S6J2Jlg6EbK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2002 at 08:51:14AM -0500, Steve Lord wrote: > On Mon, 2002-04-29 at 15:16, Austin Gonyou wrote: > > I know you guys are gonna shoot the hell outta me for this, but what can > > one do to set files immutable, as in chattr -i, with XFS? TIA > > --=20 >=20 > Sorry, no can do, XFS does not have an immutable inode concept. All > you can do is close the permissions down on the inode. which doesn't work since 1) root is immune to permissions and 2) there is no append-only permission bit. as i understand it there are some unused bits left in the XFS inode, so adding these is possible (and if current implementations set these to zero on create and ignore and leave alone on modify the change would be fully backward compatible (other then older implementations ignoring them)). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --00hq2S6J2Jlg6EbK 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 iEYEARECAAYFAjzOqX8ACgkQJKx7GixEevwFHgCeOUL+gbMHz6aLQNWnW4pcMC5j gVAAn1STW1oBFmGdVGRv4xhrPm+U2Pjg =Q2T2 -----END PGP SIGNATURE----- --00hq2S6J2Jlg6EbK-- From owner-linux-xfs@oss.sgi.com Tue Apr 30 07:53:16 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UErGwJ011952 for ; Tue, 30 Apr 2002 07:53:16 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UErG4i011951 for linux-xfs-outgoing; Tue, 30 Apr 2002 07:53:16 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UEr4wJ011925 for ; Tue, 30 Apr 2002 07:53: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 JAA16645; Tue, 30 Apr 2002 09:53:51 -0500 (CDT) Received: from jen.americas.sgi.com (jen.americas.sgi.com [128.162.187.49]) by daisy-e185.americas.sgi.com (SGI-8.9.3/SGI-server-1.7) with ESMTP id JAA09528; Tue, 30 Apr 2002 09:53:50 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3UEr2F28299; Tue, 30 Apr 2002 09:53:02 -0500 Subject: Re: Chattr From: Steve Lord To: Ethan Benson Cc: linux-xfs@oss.sgi.com In-Reply-To: <20020430062608.M21791@plato.local.lan> References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 09:53:02 -0500 Message-Id: <1020178382.24279.31.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-30 at 09:26, Ethan Benson wrote: > On Tue, Apr 30, 2002 at 08:51:14AM -0500, Steve Lord wrote: > > On Mon, 2002-04-29 at 15:16, Austin Gonyou wrote: > > > I know you guys are gonna shoot the hell outta me for this, but what can > > > one do to set files immutable, as in chattr -i, with XFS? TIA > > > -- > > > > Sorry, no can do, XFS does not have an immutable inode concept. All > > you can do is close the permissions down on the inode. > > which doesn't work since 1) root is immune to permissions and 2) there > is no append-only permission bit. > > as i understand it there are some unused bits left in the XFS inode, > so adding these is possible (and if current implementations set these > to zero on create and ignore and leave alone on modify the change > would be fully backward compatible (other then older implementations > ignoring them)). I said you cannot do it, I was referring to the existing code, yes it is possible, but currently only ext2 and ext3 support this, and chattr is an ext2 utility, not a generic linux filesystem utility. Adding it also introduces an on disk incompatibility between Irix and Linux, and probably we could not take the code back to Irix, given its origin. So we would need to version the superblock - we would need that anyway for backward compatibility. All in all it gets to be a larger project than you might think. My problem now is definitely not lack of work ;-) 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 30 08:22:34 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UFMYwJ013737 for ; Tue, 30 Apr 2002 08:22:34 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UFMYWa013736 for linux-xfs-outgoing; Tue, 30 Apr 2002 08:22: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 g3UFLDwJ013702 for ; Tue, 30 Apr 2002 08:21:13 -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 KAA18732 for ; Tue, 30 Apr 2002 10:22: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 KAA06809 for ; Tue, 30 Apr 2002 10:22:00 -0500 (CDT) From: Steve Lord Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3UFLBN29684; Tue, 30 Apr 2002 10:21:11 -0500 Message-Id: <200204301521.g3UFLBN29684@jen.americas.sgi.com> Date: Tue, 30 Apr 2002 10:21:11 -0500 Subject: TAKE - merge up to 2.5.11 To: linux-xfs@oss.sgi.com Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk With the addition of Al Viro's dcache leak fix. Date: Tue Apr 30 08:16:48 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:117818a linux/drivers/video/fbcon-accel.h - 1.1 linux/fs/ntfs/attrib.c - 1.1 linux/Documentation/DocBook/scsidrivers.tmpl - 1.1 linux/fs/ntfs/volume.h - 1.1 linux/fs/ntfs/attraops.c - 1.1 linux/include/sound/uda1341.h - 1.1 linux/fs/ntfs/upcase.c - 1.1 linux/fs/ntfs/types.h - 1.1 linux/fs/ntfs/time.c - 1.1 linux/fs/ntfs/compress.c - 1.1 linux/sound/arm/Config.in - 1.1 linux/drivers/scsi/scsi_mid_low_api.txt - 1.1 linux/drivers/scsi/aic7xxx/aic7xxx_core.c - 1.1 linux/arch/ia64/lib/ip_fast_csum.S - 1.1 linux/drivers/char/synclinkmp.c - 1.1 linux/sound/arm/Config.help - 1.1 linux/fs/ntfs/file.c - 1.1 linux/sound/i2c/l3/Makefile - 1.1 linux/fs/ntfs/ntfs.h - 1.1 linux/fs/ntfs/namei.c - 1.1 linux/fs/ntfs/mst.c - 1.1 linux/fs/ntfs/mft.h - 1.1 linux/fs/ntfs/mft.c - 1.1 linux/sound/pci/rme32.c - 1.1 linux/fs/ntfs/malloc.h - 1.1 linux/sound/arm/Makefile - 1.1 linux/fs/ntfs/layout.h - 1.1 linux/drivers/char/pcmcia/synclink_cs.c - 1.1 linux/fs/ntfs/ChangeLog - 1.1 linux/sound/arm/sa11xx-uda1341.c - 1.1 linux/sound/i2c/l3/uda1341.c - 1.1 linux/fs/ntfs/endian.h - 1.1 linux/fs/ntfs/aops.c - 1.1 linux/drivers/video/fbcon-accel.c - 1.1 linux/fs/ntfs/debug.c - 1.1 linux/fs/ntfs/debug.h - 1.1 linux/fs/ntfs/attrib.h - 1.1 linux/scripts/tkparse.c - 1.8 linux/scripts/patch-kernel - 1.5 linux/scripts/Configure - 1.15 linux/net/irda/ircomm/Makefile - 1.8 linux/mm/mremap.c - 1.30 linux/mm/mprotect.c - 1.26 linux/mm/memory.c - 1.80 linux/lib/vsprintf.c - 1.16 linux/kernel/signal.c - 1.30 linux/kernel/sched.c - 1.67 linux/kernel/ksyms.c - 1.143 linux/kernel/fork.c - 1.56 linux/kernel/exit.c - 1.45 linux/ipc/sem.c - 1.18 linux/include/video/sbusfb.h - 1.5 linux/include/video/fbcon.h - 1.12 linux/include/scsi/sg.h - 1.13 linux/include/scsi/scsi.h - 1.6 linux/include/linux/ntfs_fs_sb.h - 1.11 linux/include/linux/ntfs_fs_i.h - 1.10 linux/include/linux/ntfs_fs.h - 1.7 linux/include/linux/msdos_fs.h - 1.19 linux/include/linux/mm.h - 1.86 linux/include/linux/loop.h - 1.7 linux/include/linux/hdreg.h - 1.20 linux/include/linux/fs.h - 1.168 linux/include/linux/fb.h - 1.23 linux/include/linux/dcache.h - 1.24 linux/include/linux/blkdev.h - 1.55 linux/include/linux/blk.h - 1.32 linux/include/asm-sparc64/ide.h - 1.12 linux/include/asm-ppc/ide.h - 1.16 linux/include/asm-mips/ide.h - 1.11 linux/include/asm-m68k/system.h - 1.9 linux/include/asm-m68k/ide.h - 1.7 linux/include/asm-i386/processor.h - 1.36 linux/include/asm-i386/mmu_context.h - 1.19 linux/include/asm-i386/ide.h - 1.8 linux/include/asm-i386/desc.h - 1.9 linux/include/asm-arm/ide.h - 1.4 linux/include/asm-alpha/ide.h - 1.7 linux/fs/super.c - 1.85 linux/fs/stat.c - 1.24 linux/fs/ntfs/util.h - 1.7 linux/fs/ntfs/util.c - 1.7 linux/fs/ntfs/sysctl.h - 1.5 linux/fs/ntfs/sysctl.c - 1.4 linux/fs/ntfs/support.h - 1.8 linux/fs/ntfs/support.c - 1.15 linux/fs/ntfs/super.h - 1.8 linux/fs/ntfs/super.c - 1.12 linux/fs/ntfs/struct.h - 1.8 linux/fs/ntfs/ntfstypes.h - 1.6 linux/fs/ntfs/ntfsendian.h - 1.5 linux/fs/ntfs/macros.h - 1.8 linux/fs/ntfs/inode.h - 1.6 linux/fs/ntfs/inode.c - 1.15 linux/fs/ntfs/fs.c - 1.43 linux/fs/ntfs/dir.h - 1.5 linux/fs/ntfs/dir.c - 1.11 linux/fs/ntfs/attr.h - 1.6 linux/fs/ntfs/attr.c - 1.9 linux/fs/ntfs/Makefile - 1.16 linux/fs/namei.c - 1.52 linux/fs/fat/misc.c - 1.14 linux/fs/fat/inode.c - 1.43 linux/fs/fat/file.c - 1.21 linux/fs/fat/fatfs_syms.c - 1.14 linux/fs/fat/cache.c - 1.18 linux/fs/dcache.c - 1.36 linux/fs/buffer.c - 1.119 linux/fs/block_dev.c - 1.46 linux/fs/Config.in - 1.85 linux/drivers/video/virgefb.c - 1.16 linux/drivers/video/vfb.c - 1.14 linux/drivers/video/vesafb.c - 1.22 linux/drivers/video/valkyriefb.c - 1.16 linux/drivers/video/tgafb.c - 1.19 linux/drivers/video/tcxfb.c - 1.9 linux/drivers/video/skeletonfb.c - 1.10 linux/drivers/video/sgivwfb.c - 1.15 linux/drivers/video/sbusfb.c - 1.21 linux/drivers/video/retz3fb.c - 1.16 linux/drivers/video/q40fb.c - 1.12 linux/drivers/video/pm2fb.c - 1.12 linux/drivers/video/platinumfb.c - 1.15 linux/drivers/video/offb.c - 1.20 linux/drivers/video/macfb.c - 1.14 linux/drivers/video/leofb.c - 1.11 linux/drivers/video/imsttfb.c - 1.22 linux/drivers/video/igafb.c - 1.18 linux/drivers/video/hpfb.c - 1.13 linux/drivers/video/g364fb.c - 1.12 linux/drivers/video/fm2fb.c - 1.13 linux/drivers/video/fbmem.c - 1.47 linux/drivers/video/fbgen.c - 1.8 linux/drivers/video/fbcon.c - 1.25 linux/drivers/video/fbcon-afb.c - 1.7 linux/drivers/video/fbcmap.c - 1.5 linux/drivers/video/dnfb.c - 1.14 linux/drivers/video/cyberfb.c - 1.16 linux/drivers/video/creatorfb.c - 1.14 linux/drivers/video/controlfb.c - 1.21 linux/drivers/video/clgenfb.c - 1.27 linux/drivers/video/chipsfb.c - 1.17 linux/drivers/video/cgthreefb.c - 1.10 linux/drivers/video/cgsixfb.c - 1.13 linux/drivers/video/cgfourteenfb.c - 1.12 linux/drivers/video/bwtwofb.c - 1.11 linux/drivers/video/atafb.c - 1.15 linux/drivers/video/amifb.c - 1.23 linux/drivers/video/acornfb.c - 1.24 linux/drivers/video/S3triofb.c - 1.12 linux/drivers/scsi/sr.c - 1.41 linux/drivers/scsi/sg.c - 1.30 linux/drivers/scsi/scsi.h - 1.28 linux/drivers/scsi/scsi.c - 1.54 linux/drivers/scsi/qlogicfc.c - 1.28 linux/drivers/scsi/qlogicfas.c - 1.14 linux/drivers/scsi/ide-scsi.c - 1.33 linux/drivers/scsi/gdth_proc.c - 1.13 linux/drivers/scsi/Config.in - 1.28 linux/drivers/net/rrunner.c - 1.20 linux/drivers/isdn/Config.in - 1.26 linux/drivers/char/Makefile - 1.57 linux/drivers/char/Config.in - 1.57 linux/drivers/cdrom/sonycd535.c - 1.18 linux/drivers/cdrom/sjcd.c - 1.15 linux/drivers/cdrom/sbpcd.c - 1.20 linux/drivers/cdrom/optcd.c - 1.16 linux/drivers/cdrom/mcdx.c - 1.13 linux/drivers/cdrom/mcd.c - 1.16 linux/drivers/cdrom/gscd.c - 1.15 linux/drivers/cdrom/cm206.c - 1.17 linux/drivers/cdrom/cdu31a.c - 1.14 linux/drivers/cdrom/aztcd.c - 1.17 linux/drivers/block/xd.c - 1.34 linux/drivers/block/swim3.c - 1.14 linux/drivers/block/rd.c - 1.49 linux/drivers/block/ps2esdi.c - 1.36 linux/drivers/block/paride/pf.c - 1.23 linux/drivers/block/paride/pd.c - 1.28 linux/drivers/block/paride/pcd.c - 1.18 linux/drivers/block/loop.c - 1.55 linux/drivers/block/ll_rw_blk.c - 1.99 linux/drivers/block/floppy.c - 1.37 linux/drivers/block/ataflop.c - 1.21 linux/drivers/block/amiflop.c - 1.22 linux/drivers/block/acsi.c - 1.27 linux/drivers/acorn/block/mfmhd.c - 1.21 linux/drivers/acorn/block/fd1772.c - 1.15 linux/arch/sparc64/defconfig - 1.66 linux/arch/sparc/defconfig - 1.31 linux/arch/ppc/defconfig - 1.40 linux/arch/mips/lib/ide-std.c - 1.6 linux/arch/mips/lib/ide-no.c - 1.5 linux/arch/mips/defconfig - 1.22 linux/arch/m68k/lib/semaphore.S - 1.5 linux/arch/m68k/kernel/traps.c - 1.11 linux/arch/m68k/kernel/signal.c - 1.16 linux/arch/m68k/kernel/head.S - 1.7 linux/arch/m68k/kernel/entry.S - 1.16 linux/arch/m68k/ifpsp060/os.S - 1.4 linux/arch/m68k/ifpsp060/iskeleton.S - 1.3 linux/arch/m68k/ifpsp060/fskeleton.S - 1.3 linux/arch/m68k/fpsp040/skeleton.S - 1.3 linux/arch/m68k/atari/ataints.c - 1.6 linux/arch/i386/math-emu/reg_round.S - 1.6 linux/arch/i386/math-emu/reg_norm.S - 1.3 linux/arch/i386/math-emu/fpu_system.h - 1.5 linux/arch/i386/math-emu/fpu_asm.h - 1.4 linux/arch/i386/kernel/trampoline.S - 1.5 linux/arch/i386/kernel/setup.c - 1.74 linux/arch/i386/kernel/process.c - 1.48 linux/arch/i386/kernel/ldt.c - 1.11 linux/arch/i386/kernel/head.S - 1.23 linux/arch/i386/kernel/entry.S - 1.54 linux/arch/i386/kernel/apm.c - 1.42 linux/arch/i386/defconfig - 1.107 linux/arch/i386/config.in - 1.79 linux/arch/i386/boot/setup.S - 1.27 linux/arch/i386/boot/compressed/head.S - 1.8 linux/arch/arm/mm/proc-arm2,3.S - 1.13 linux/arch/arm/lib/uaccess.S - 1.9 linux/arch/arm/lib/uaccess-armo.S - 1.7 linux/arch/arm/lib/io-acorn.S - 1.9 linux/arch/arm/lib/floppydma.S - 1.4 linux/arch/arm/lib/delay.S - 1.7 linux/arch/arm/lib/backtrace.S - 1.8 linux/arch/arm/kernel/entry-common.S - 1.22 linux/arch/arm/kernel/entry-armv.S - 1.29 linux/arch/arm/kernel/entry-armo.S - 1.14 linux/arch/arm/kernel/calls.S - 1.18 linux/arch/arm/defconfig - 1.20 linux/arch/arm/boot/compressed/head.S - 1.18 linux/arch/alpha/kernel/ptrace.c - 1.15 linux/arch/alpha/defconfig - 1.27 linux/Rules.make - 1.19 linux/Makefile - 1.196 linux/MAINTAINERS - 1.104 linux/Documentation/filesystems/ntfs.txt - 1.13 linux/CREDITS - 1.79 linux/include/linux/ide.h - 1.47 linux/drivers/video/vga16fb.c - 1.15 linux/drivers/video/cyber2000fb.c - 1.31 linux/drivers/block/blkpg.c - 1.20 linux/arch/arm/boot/compressed/ll_char_wr.S - 1.4 linux/drivers/block/cpqarray.c - 1.44 linux/arch/arm/def-configs/rpc - 1.8 linux/arch/arm/def-configs/footbridge - 1.12 linux/arch/arm/def-configs/ebsa110 - 1.9 linux/arch/arm/def-configs/a5k - 1.6 linux/drivers/char/raw.c - 1.23 linux/include/asm-i386/hw_irq.h - 1.27 linux/fs/partitions/sun.c - 1.5 linux/fs/partitions/sgi.c - 1.6 linux/fs/partitions/msdos.c - 1.21 linux/fs/partitions/check.c - 1.39 linux/fs/partitions/amiga.c - 1.4 linux/fs/partitions/acorn.c - 1.15 linux/arch/m68k/math-emu/fp_entry.S - 1.5 linux/arch/i386/kernel/i8259.c - 1.28 linux/drivers/net/fc/iph5526.c - 1.19 linux/drivers/block/DAC960.c - 1.46 linux/arch/sh/lib/memmove.S - 1.4 linux/arch/sh/kernel/head.S - 1.10 linux/arch/sh/kernel/entry.S - 1.23 linux/arch/sh/defconfig - 1.19 linux/drivers/video/p9100fb.c - 1.6 linux/net/irda/ircomm/ircomm_core.c - 1.13 linux/drivers/block/swim_iop.c - 1.10 linux/arch/m68k/kernel/sun3-head.S - 1.4 linux/arch/i386/kernel/pci-pc.c - 1.38 linux/drivers/video/tdfxfb.c - 1.19 linux/Documentation/vm/locking - 1.7 linux/arch/arm/def-configs/brutus - 1.10 linux/mm/highmem.c - 1.39 linux/include/asm-sh/ide.h - 1.11 linux/drivers/video/aty128fb.c - 1.25 linux/drivers/video/acornfb.h - 1.5 linux/drivers/char/pcmcia/Makefile - 1.5 linux/drivers/char/pcmcia/Config.in - 1.7 linux/drivers/scsi/sun3_scsi.c - 1.9 linux/arch/ppc/configs/walnut_defconfig - 1.17 linux/arch/ppc/configs/pmac_defconfig - 1.7 linux/arch/ppc/configs/oak_defconfig - 1.17 linux/arch/ppc/configs/mbx_defconfig - 1.12 linux/arch/ppc/configs/gemini_defconfig - 1.19 linux/arch/ppc/configs/common_defconfig - 1.27 linux/arch/ppc/configs/apus_defconfig - 1.13 linux/include/linux/agp_backend.h - 1.16 linux/drivers/char/agp/agpgart_be.c - 1.35 linux/drivers/char/agp/agp.h - 1.22 linux/arch/i386/kernel/apic.c - 1.29 linux/arch/i386/kernel/mpparse.c - 1.19 linux/drivers/scsi/scsi_scan.c - 1.23 linux/include/asm-sparc/ide.h - 1.9 linux/drivers/video/dn_cfb8.c - 1.9 linux/drivers/video/dn_cfb4.c - 1.8 linux/arch/ia64/kernel/gate.S - 1.10 linux/drivers/atm/iphase.c - 1.12 linux/arch/ia64/kernel/acpi.c - 1.13 linux/arch/ia64/tools/print_offsets.c - 1.12 linux/arch/ia64/defconfig - 1.16 linux/arch/ia64/config.in - 1.28 linux/arch/ia64/kernel/setup.c - 1.15 linux/arch/ia64/kernel/signal.c - 1.15 linux/arch/ia64/kernel/traps.c - 1.14 linux/arch/ia64/lib/Makefile - 1.10 linux/arch/ia64/kernel/ivt.S - 1.17 linux/arch/ia64/lib/checksum.c - 1.3 linux/arch/ia64/lib/copy_page.S - 1.8 linux/arch/ia64/lib/do_csum.S - 1.7 linux/arch/ia64/mm/fault.c - 1.11 linux/arch/ia64/lib/memset.S - 1.6 linux/include/asm-ia64/ioctls.h - 1.5 linux/include/asm-ia64/ide.h - 1.8 linux/include/asm-ia64/errno.h - 1.2 linux/include/asm-ia64/siginfo.h - 1.12 linux/include/asm-ia64/processor.h - 1.19 linux/include/linux/raid/md.h - 1.12 linux/include/asm-ia64/page.h - 1.13 linux/include/linux/raid/linear.h - 1.3 linux/include/asm-ia64/system.h - 1.14 linux/include/asm-ia64/string.h - 1.6 linux/include/asm-arm/proc-armv/locks.h - 1.5 linux/drivers/video/sun3fb.c - 1.9 linux/arch/m68k/mac/baboon.c - 1.5 linux/arch/mips/defconfig-decstation - 1.8 linux/arch/mips/defconfig-ip22 - 1.9 linux/drivers/video/matrox/matroxfb_crtc2.c - 1.8 linux/drivers/video/matrox/matroxfb_base.h - 1.12 linux/drivers/video/matrox/matroxfb_base.c - 1.16 linux/include/asm-mips64/ide.h - 1.8 linux/arch/mips64/defconfig - 1.18 linux/drivers/atm/fore200e.c - 1.14 linux/arch/mips64/lib/ide-std.c - 1.4 linux/arch/mips64/lib/ide-no.c - 1.4 linux/arch/mips64/defconfig-ip22 - 1.11 linux/arch/mips64/defconfig-ip27 - 1.10 linux/drivers/video/riva/fbdev.c - 1.17 linux/drivers/video/hgafb.c - 1.14 linux/include/linux/usb.h - 1.36 linux/drivers/ide/trm290.c - 1.6 linux/drivers/ide/pdc202xx.c - 1.19 linux/drivers/ide/ide.c - 1.51 linux/drivers/ide/ide-tape.c - 1.25 linux/drivers/ide/ide-proc.c - 1.18 linux/drivers/ide/ide-probe.c - 1.30 linux/drivers/ide/ide-pmac.c - 1.11 linux/drivers/ide/ide-floppy.c - 1.22 linux/drivers/ide/ide-dma.c - 1.26 linux/drivers/ide/ide-disk.c - 1.33 linux/drivers/ide/ide-cd.h - 1.13 linux/drivers/ide/ide-cd.c - 1.33 linux/drivers/ide/Makefile - 1.21 linux/drivers/ide/Config.in - 1.23 linux/drivers/block/elevator.c - 1.17 linux/Documentation/DocBook/Makefile - 1.27 linux/drivers/video/sa1100fb.c - 1.13 linux/include/linux/fs_struct.h - 1.7 linux/fs/partitions/ibm.c - 1.11 linux/drivers/usb/serial/digi_acceleport.c - 1.26 linux/include/linux/raid/raid1.h - 1.8 linux/arch/arm/def-configs/lart - 1.6 linux/arch/s390/defconfig - 1.10 linux/include/asm-s390/ide.h - 1.3 linux/drivers/s390/block/dasd.c - 1.23 linux/arch/arm/def-configs/assabet - 1.7 linux/arch/arm/def-configs/graphicsclient - 1.6 linux/arch/arm/def-configs/lusl7200 - 1.4 linux/arch/mips64/kernel/ioctl32.c - 1.12 linux/fs/xfs/xfs_rw.c - 1.357 linux/fs/xfs/xfs_buf.h - 1.87 linux/fs/xfs/xfs_buf_item.c - 1.118 linux/fs/xfs/xfs_mount.c - 1.281 linux/fs/xfs/xfs_trans_buf.c - 1.99 linux/fs/xfs/linux/xfs_iops.c - 1.137 linux/kdb/modules/kdbm_pg.c - 1.57 linux/Documentation/filesystems/Locking - 1.12 linux/drivers/video/hitfb.c - 1.7 linux/drivers/usb/serial/keyspan.c - 1.27 linux/arch/ia64/kernel/ia64_ksyms.c - 1.12 linux/drivers/mtd/ftl.c - 1.15 linux/arch/mips/defconfig-rm200 - 1.5 linux/arch/ppc/configs/rpxlite_defconfig - 1.12 linux/arch/ppc/configs/rpxcllf_defconfig - 1.13 linux/arch/ppc/configs/est8260_defconfig - 1.13 linux/arch/ppc/configs/bseip_defconfig - 1.12 linux/Documentation/cachetlb.txt - 1.10 linux/include/asm-arm/proc-armo/locks.h - 1.3 linux/drivers/media/video/bttv-driver.c - 1.21 linux/drivers/media/video/bttv-cards.c - 1.12 linux/drivers/media/radio/radio-sf16fmi.c - 1.12 linux/drivers/md/lvm.c - 1.30 linux/drivers/md/raid1.c - 1.19 linux/drivers/md/raid5.c - 1.26 linux/arch/arm/def-configs/shark - 1.6 linux/arch/i386/kernel/bluesmoke.c - 1.19 linux/drivers/md/linear.c - 1.7 linux/drivers/md/md.c - 1.43 linux/drivers/md/raid0.c - 1.7 linux/drivers/scsi/cpqfcTSstructs.h - 1.8 linux/drivers/video/sis/sis_main.c - 1.11 linux/drivers/video/stifb.c - 1.4 linux/include/asm-parisc/ide.h - 1.3 linux/arch/arm/def-configs/integrator - 1.4 linux/arch/arm/def-configs/neponset - 1.4 linux/arch/arm/def-configs/pangolin - 1.4 linux/arch/arm/lib/io-readsw-armv3.S - 1.4 linux/arch/arm/lib/io-readsw-armv4.S - 1.4 linux/arch/arm/lib/io-writesw-armv3.S - 1.4 linux/arch/arm/lib/io-writesw-armv4.S - 1.4 linux/arch/parisc/defconfig - 1.5 linux/drivers/video/matrox/matroxfb_g450.c - 1.5 linux/include/asm-i386/mmu.h - 1.3 linux/arch/ia64/kernel/iosapic.c - 1.7 linux/fs/reiserfs/stree.c - 1.22 linux/fs/reiserfs/prints.c - 1.14 linux/fs/reiserfs/journal.c - 1.27 linux/arch/ppc/configs/power3_defconfig - 1.10 linux/arch/ppc/configs/ibmchrp_defconfig - 1.10 linux/include/asm-s390x/ide.h - 1.3 linux/arch/arm/boot/compressed/head-shark.S - 1.5 linux/arch/cris/defconfig - 1.10 linux/arch/cris/kernel/entry.S - 1.13 linux/drivers/s390/char/tapeblock.c - 1.9 linux/drivers/s390/char/tape34xx.c - 1.8 linux/arch/s390x/defconfig - 1.9 linux/drivers/s390/block/xpram.c - 1.14 linux/include/asm-cris/ide.h - 1.4 linux/drivers/scsi/aic7xxx/aic7xxx.c - 1.8 linux/drivers/scsi/aic7xxx/Makefile - 1.5 linux/arch/ppc/configs/TQM860L_defconfig - 1.11 linux/arch/ppc/configs/TQM850L_defconfig - 1.10 linux/arch/ppc/configs/TQM823L_defconfig - 1.10 linux/arch/ppc/configs/SPD823TS_defconfig - 1.10 linux/arch/ppc/configs/SM850_defconfig - 1.10 linux/arch/ppc/configs/IVMS8_defconfig - 1.11 linux/drivers/video/epson1355fb.c - 1.5 linux/drivers/video/maxinefb.c - 1.5 linux/drivers/video/pmag-ba-fb.c - 1.4 linux/drivers/video/pmagb-b-fb.c - 1.4 linux/arch/mips/defconfig-it8172 - 1.5 linux/arch/mips/defconfig-ddb5476 - 1.5 linux/drivers/mtd/nftlcore.c - 1.14 linux/arch/cris/drivers/lpslave/e100lpslavenet.c - 1.5 linux/Documentation/sonypi.txt - 1.7 linux/drivers/char/sonypi.h - 1.7 linux/drivers/usb/usb-skeleton.c - 1.10 linux/drivers/char/sonypi.c - 1.7 linux/drivers/video/pvr2fb.c - 1.5 linux/fs/ntfs/unistr.c - 1.6 linux/fs/ntfs/unistr.h - 1.3 linux/drivers/video/aty/atyfb_base.c - 1.10 linux/drivers/char/drm/drm_agpsupport.h - 1.4 linux/drivers/video/sa1100fb.h - 1.4 linux/arch/arm/def-configs/anakin - 1.2 linux/arch/arm/def-configs/flexanet - 1.3 linux/arch/arm/def-configs/freebird - 1.2 linux/arch/arm/def-configs/freebird_new - 1.2 linux/arch/arm/def-configs/h3600 - 1.3 linux/arch/arm/def-configs/huw_webpanel - 1.2 linux/arch/arm/def-configs/jornada720 - 1.3 linux/arch/arm/def-configs/omnimeter - 1.2 linux/arch/arm/def-configs/pfs168_mqtft - 1.2 linux/arch/arm/def-configs/pfs168_mqvga - 1.2 linux/arch/arm/def-configs/pfs168_sastn - 1.2 linux/arch/arm/def-configs/pfs168_satft - 1.2 linux/arch/arm/def-configs/pleb - 1.2 linux/drivers/video/tx3912fb.c - 1.3 linux/drivers/video/sstfb.c - 1.6 linux/drivers/video/radeonfb.c - 1.9 linux/arch/mips/defconfig-atlas - 1.2 linux/arch/mips/defconfig-ddb5477 - 1.2 linux/arch/mips/defconfig-malta - 1.2 linux/arch/mips/defconfig-nino - 1.2 linux/arch/mips/defconfig-ocelot - 1.2 linux/arch/mips/defconfig-pb1000 - 1.2 linux/arch/mips64/defconfig-ip32 - 1.2 linux/include/linux/raid/multipath.h - 1.3 linux/drivers/md/multipath.c - 1.6 linux/drivers/ide/ataraid.c - 1.8 linux/drivers/mtd/devices/blkmtd.c - 1.9 linux/arch/arm/def-configs/adsbitsy - 1.2 linux/arch/arm/def-configs/cerfcube - 1.2 linux/arch/arm/def-configs/cerfpda - 1.2 linux/arch/arm/def-configs/cerfpod - 1.2 linux/arch/arm/def-configs/edb7211 - 1.2 linux/arch/arm/def-configs/epxa10db - 1.3 linux/arch/arm/def-configs/graphicsmaster - 1.2 linux/arch/arm/mach-sa1100/sleep.S - 1.3 linux/fs/jbd/journal.c - 1.9 linux/drivers/video/sis/sis_main.h - 1.2 linux/fs/ext3/inode.c - 1.10 linux/fs/ext3/super.c - 1.15 linux/fs/reiserfs/procfs.c - 1.7 linux/include/linux/bio.h - 1.8 linux/fs/bio.c - 1.13 linux/drivers/block/block_ioctl.c - 1.8 linux/mm/mempool.c - 1.6 linux/include/linux/mempool.h - 1.3 linux/Documentation/usb/ehci.txt - 1.2 linux/arch/arm/def-configs/adi_evb - 1.2 linux/arch/arm/def-configs/iq80310 - 1.5 linux/arch/arm/def-configs/system3 - 1.2 linux/arch/arm/mach-arc/head.S - 1.2 linux/arch/arm/kernel/head.S - 1.4 linux/fs/xfs/pagebuf/page_buf_io.c - 1.28 linux/fs/xfs/pagebuf/page_buf_locking.c - 1.10 linux/fs/xfs/pagebuf/page_buf.c - 1.18 linux/fs/xfs/pagebuf/page_buf.h - 1.11 linux/drivers/ide/ide-taskfile.c - 1.10 linux/drivers/video/neofb.c - 1.6 linux/drivers/video/neofb.h - 1.2 linux/arch/cris/Config.help - 1.5 linux/arch/cris/drivers/Config.help - 1.2 linux/arch/i386/Config.help - 1.8 linux/arch/ia64/Config.help - 1.6 linux/fs/Config.help - 1.9 linux/drivers/usb/Config.help - 1.7 linux/drivers/scsi/Config.help - 1.2 linux/drivers/char/Config.help - 1.4 linux/drivers/char/pcmcia/Config.help - 1.2 linux/drivers/ide/Config.help - 1.10 linux/drivers/base/core.c - 1.8 linux/fs/xattr.c - 1.4 linux/Documentation/filesystems/porting - 1.7 linux/sound/sound_core.c - 1.3 linux/sound/ppc/awacs.c - 1.3 linux/sound/pci/ymfpci/ymfpci_main.c - 1.4 linux/sound/pci/ymfpci/ymfpci.c - 1.6 linux/sound/pci/via8233.c - 1.5 linux/sound/pci/via686.c - 1.5 linux/sound/pci/trident/trident_main.c - 1.4 linux/sound/pci/trident/trident.c - 1.5 linux/sound/pci/sonicvibes.c - 1.5 linux/sound/pci/rme9652/rme9652.c - 1.5 linux/sound/pci/rme96.c - 1.5 linux/sound/pci/nm256/nm256.c - 1.5 linux/sound/pci/maestro3.c - 1.5 linux/sound/pci/korg1212/korg1212.c - 1.5 linux/sound/pci/intel8x0.c - 1.5 linux/sound/pci/ice1712.c - 1.5 linux/sound/pci/fm801.c - 1.5 linux/sound/pci/es1968.c - 1.5 linux/sound/pci/es1938.c - 1.5 linux/sound/pci/ens1370.c - 1.5 linux/sound/pci/emu10k1/memory.c - 1.3 linux/sound/pci/emu10k1/emumixer.c - 1.4 linux/sound/pci/emu10k1/emu10k1_main.c - 1.5 linux/sound/pci/emu10k1/emu10k1.c - 1.5 linux/sound/pci/cs46xx/cs46xx_lib.c - 1.4 linux/sound/pci/cs46xx/cs46xx.c - 1.5 linux/sound/pci/cs4281.c - 1.5 linux/sound/pci/cmipci.c - 1.5 linux/sound/pci/als4000.c - 1.5 linux/sound/pci/ali5451/ali5451.c - 1.5 linux/sound/pci/ac97/ac97_codec.c - 1.5 linux/sound/pci/ac97/Makefile - 1.4 linux/sound/pci/Makefile - 1.3 linux/sound/pci/Config.in - 1.3 linux/arch/ppc/configs/FADS_defconfig - 1.2 linux/arch/ppc/configs/TQM8260_defconfig - 1.2 linux/arch/ppc/configs/adir_defconfig - 1.2 linux/arch/ppc/configs/ash_defconfig - 1.2 linux/arch/ppc/configs/ceder_defconfig - 1.2 linux/arch/ppc/configs/cpci405_defconfig - 1.2 linux/arch/ppc/configs/ep405_defconfig - 1.2 linux/arch/ppc/configs/ev64260_defconfig - 1.2 linux/arch/ppc/configs/iSeries_defconfig - 1.2 linux/arch/ppc/configs/k2_defconfig - 1.4 linux/arch/ppc/configs/lopec_defconfig - 1.2 linux/arch/ppc/configs/mcpn765_defconfig - 1.2 linux/arch/ppc/configs/menf1_defconfig - 1.4 linux/arch/ppc/configs/mvme5100_defconfig - 1.3 linux/arch/ppc/configs/pcore_defconfig - 1.2 linux/arch/ppc/configs/pplus_defconfig - 1.4 linux/arch/ppc/configs/prpmc750_defconfig - 1.2 linux/arch/ppc/configs/prpmc800_defconfig - 1.2 linux/arch/ppc/configs/redwood5_defconfig - 1.2 linux/arch/ppc/configs/redwood_defconfig - 1.2 linux/arch/ppc/configs/sandpoint_defconfig - 1.4 linux/arch/ppc/configs/spruce_defconfig - 1.2 linux/arch/ppc/configs/zx4500_defconfig - 1.2 linux/arch/ppc/kernel/ppc4xx_setup.c - 1.2 linux/arch/ppc/platforms/chrp_setup.c - 1.3 linux/arch/ppc/platforms/k2_setup.c - 1.2 linux/arch/ppc/platforms/lopec_setup.c - 1.2 linux/arch/ppc/platforms/mcpn765_setup.c - 1.2 linux/arch/ppc/platforms/menf1_setup.c - 1.2 linux/arch/ppc/platforms/pmac_setup.c - 1.2 linux/arch/ppc/platforms/pplus_setup.c - 1.2 linux/arch/ppc/platforms/prep_setup.c - 1.2 linux/arch/ppc/platforms/rpxclassic.h - 1.2 linux/arch/ppc/platforms/rpxlite.h - 1.2 linux/arch/ppc/platforms/sandpoint_setup.c - 1.2 linux/arch/x86_64/boot/compressed/head.S - 1.2 linux/arch/x86_64/defconfig - 1.6 linux/arch/x86_64/kernel/bluesmoke.c - 1.3 linux/arch/x86_64/kernel/head.S - 1.3 linux/sound/isa/sb/sb_common.c - 1.5 linux/sound/isa/sb/Makefile - 1.4 linux/sound/isa/gus/Makefile - 1.3 linux/sound/isa/cs423x/cs4236.c - 1.5 linux/sound/isa/cs423x/Makefile - 1.3 linux/sound/isa/cmi8330.c - 1.5 linux/sound/isa/ad1848/ad1848_lib.c - 1.4 linux/sound/isa/ad1848/Makefile - 1.3 linux/sound/i2c/cs8427.c - 1.3 linux/sound/i2c/Makefile - 1.4 linux/sound/drivers/opl3/opl3_lib.c - 1.4 linux/sound/drivers/opl3/Makefile - 1.4 linux/sound/drivers/mpu401/mpu401_uart.c - 1.5 linux/sound/drivers/mpu401/Makefile - 1.4 linux/sound/drivers/dummy.c - 1.4 linux/sound/core/sound.c - 1.4 linux/sound/core/seq/seq_virmidi.c - 1.5 linux/sound/core/seq/seq_queue.h - 1.4 linux/sound/core/seq/seq_queue.c - 1.5 linux/sound/core/seq/seq_ports.c - 1.4 linux/sound/core/seq/seq_midi_event.c - 1.5 linux/sound/core/seq/seq_midi.c - 1.4 linux/sound/core/seq/seq_dummy.c - 1.4 linux/sound/core/seq/seq_clientmgr.c - 1.4 linux/sound/core/seq/oss/seq_oss_midi.c - 1.4 linux/sound/core/seq/instr/Makefile - 1.4 linux/sound/core/seq/Makefile - 1.6 linux/sound/core/rtctimer.c - 1.8 linux/sound/core/pcm_native.c - 1.5 linux/sound/core/pcm_lib.c - 1.4 linux/sound/core/pcm.c - 1.3 linux/sound/core/oss/pcm_oss.c - 1.5 linux/sound/core/misc.c - 1.5 linux/sound/core/memory.c - 1.5 linux/sound/core/device.c - 1.5 linux/sound/core/Makefile - 1.6 linux/sound/core/Config.in - 1.6 linux/sound/Makefile - 1.5 linux/sound/Config.in - 1.3 linux/include/asm-x86_64/ide.h - 1.2 linux/include/sound/version.h - 1.6 linux/include/sound/sndmagic.h - 1.3 linux/include/sound/seq_midi_event.h - 1.2 linux/include/sound/seq_kernel.h - 1.3 linux/include/sound/rawmidi.h - 1.3 linux/include/sound/minors.h - 1.2 linux/include/sound/i2c.h - 1.2 linux/include/sound/emu10k1.h - 1.4 linux/include/sound/driver.h - 1.3 linux/include/sound/core.h - 1.6 linux/include/sound/asound.h - 1.5 linux/include/sound/asequencer.h - 1.2 linux/include/sound/ac97_codec.h - 1.3 linux/include/asm-ppc64/ide.h - 1.2 linux/arch/ppc64/defconfig - 1.3 linux/fs/jfs/jfs_logmgr.h - 1.3 linux/arch/arm/def-configs/badge4 - 1.3 linux/arch/arm/def-configs/fortunet - 1.2 linux/arch/arm/def-configs/stork - 1.2 linux/fs/jfs/jfs_logmgr.c - 1.3 linux/fs/jfs/jfs_mount.c - 1.3 linux/sound/pci/Config.help - 1.2 linux/include/asm-ia64/sn/sn2/shub_md.h - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-generic-sp - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-hp-sp - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-mp - 1.3 linux/arch/ia64/sn/configs/sn1/defconfig-bigsur-sp - 1.3 linux/arch/ia64/sn/configs/sn1/defconfig-dig-mp - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-dig-sp - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-generic-mp - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-prom-medusa - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-modules - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-mp-syn1-0 - 1.2 linux/arch/ia64/sn/configs/sn1/defconfig-sn1-sp - 1.2 linux/arch/ia64/sn/configs/sn2/defconfig-dig-numa - 1.2 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-dig-mp - 1.2 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-dig-sp - 1.2 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp - 1.2 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-mp-modules - 1.2 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-prom-medusa - 1.2 linux/arch/ia64/sn/configs/sn2/defconfig-sn2-sp - 1.2 linux/arch/i386/kernel/acpi_wakeup.S - 1.3 linux/lib/radix-tree.c - 1.3 linux/drivers/ide/ide-tcq.c - 1.3 linux/drivers/usb/class/printer.c - 1.3 linux/drivers/usb/core/Config.in - 1.2 linux/drivers/usb/input/hid-core.c - 1.2 linux/drivers/usb/media/dabusb.h - 1.2 linux/drivers/usb/core/usb.c - 1.4 linux/drivers/usb/host/ehci-hub.c - 1.3 linux/drivers/usb/host/ohci-hub.c - 1.3 linux/fs/partitions/efi.c - 1.2 linux/drivers/usb/media/usbvideo.c - 1.2 linux/drivers/usb/image/mdc800.c - 1.3 linux/drivers/usb/image/scanner.c - 1.3 linux/drivers/usb/image/scanner.h - 1.2 linux/drivers/usb/input/hiddev.c - 1.3 linux/drivers/usb/media/Makefile - 1.3 linux/drivers/usb/media/dabusb.c - 1.3 linux/drivers/video/clps711xfb.c - 1.2 linux/drivers/video/anakinfb.c - 1.3 linux/drivers/usb/net/usbnet.c - 1.3 linux/drivers/usb/net/pegasus.h - 1.3 linux/drivers/usb/media/usbvideo.h - 1.2 linux/mm/readahead.c - 1.2 linux/drivers/usb/misc/auerswald.c - 1.3 linux/include/asm-ia64/acpi.h - 1.2 linux/drivers/isdn/i4l/Makefile - 1.2 linux/arch/ia64/hp/zx1/hpzx1_misc.c - 1.2 linux/arch/ia64/hp/common/sba_iommu.c - 1.2 linux/drivers/usb/misc/brlvger.c - 1.2 linux/include/linux/brlvger.h - 1.2 linux/drivers/isdn/hardware/avm/Config.in - 1.2 linux/drivers/isdn/capi/Config.in - 1.2 From owner-linux-xfs@oss.sgi.com Tue Apr 30 09:56:11 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UGuBwJ024381 for ; Tue, 30 Apr 2002 09:56:11 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UGuBQv024380 for linux-xfs-outgoing; Tue, 30 Apr 2002 09:56:11 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dns.securities.com (mail01.securities.com [57.69.12.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UGtxwJ024350 for ; Tue, 30 Apr 2002 09:56:00 -0700 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g3UGup114446; Tue, 30 Apr 2002 12:56:51 -0400 Date: Tue, 30 Apr 2002 12:56:51 -0400 (EDT) From: Benito Venegas To: cc: Marek Kubita Subject: mkfs problem:: no left space on device Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi guys: I have some problems in one server, when I run mkfs (mkfs.xfs) I got an error: No space left on device HW: PE2450 MEM: 384 MB OS: RH 7.1 updted kernel: 2.4.9-31SGI_XFS_1.1 Command: #mkfs -t xfs -f /dev/sdc1 xfsprogs version: xfsprogs-2.0.3-0 Standard output: meta-data=/dev/sdc1 isize=256 agcount=6294979, agsize=1048576 blks data = bsize=4096 blocks=6600763899904, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=32768 realtime =none extsz=65536 blocks=0, rtextents=0 mkfs.xfs: write failed: No space left on device Fdisk details #fdisk -l /dev/sdc Disk /dev/sdc: 255 heads, 63 sectors, 38694 cylinders Units = cylinders of 16065 * 512 bytes Device Boot Start End Blocks Id System /dev/sdc1 1 38694 310809523+ 83 Linux I had downgraded xfsprogs version (including devel version) to recreate file system. xfsprogs-1.3.13-0 Command: mkfs -t xfs -f /dev/sdc1 meta-data=/dev/sdc1 isize=256 agcount=75, agsize=1048576 blks data = bsize=4096 blocks=77702380, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=0 = imaxbits=31 naming =version 2 bsize=4096 log =internal log bsize=4096 blocks=9485 realtime =none extsz=65536 blocks=0, rtextents=0 when I did that I saw there is a oversize blocks (6600763899904 v/s 77702380 and some other variables are different between bot mkfs.xfs version). I don't know why. I saved a strace output for first command. I am not expert analyzing code, but I will try to see what happened. In the list, I found some guys having the same problem but I don't now if it's fixed now in the current cvs tree. Steve, Eric / Team you can tell me if you need and extended strace version (-v) to see where is the problem. -- Benito A. Venegas System Engineer, Technology 225 Park Ave. South (6th floor ISI) New York, NY 10003 A Euromoney Institutional Investor company. ********************************************************************** This communication contains information which is confidential. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error please notify us by e-mail or by telephone (as above) and then delete the e-mail and all attachments and any copies thereof. ********************************************************************** From owner-linux-xfs@oss.sgi.com Tue Apr 30 09:53:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UGrewJ024276 for ; Tue, 30 Apr 2002 09:53:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UGrepm024275 for linux-xfs-outgoing; Tue, 30 Apr 2002 09:53:40 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UGrZwJ024245 for ; Tue, 30 Apr 2002 09:53:35 -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 LAA18013 for ; Tue, 30 Apr 2002 11:54:22 -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 LAA79383 for ; Tue, 30 Apr 2002 11:54:22 -0500 (CDT) Received: by jen.americas.sgi.com (8.11.6/SGI-client-1.7) id g3UGrW407646; Tue, 30 Apr 2002 11:53:32 -0500 Subject: Re: TAKE - better mmap write support in pagebuf From: Steve Lord To: linux-xfs@oss.sgi.com In-Reply-To: <200204300955.g3U9tKZ02413@jen.americas.sgi.com> References: <200204300955.g3U9tKZ02413@jen.americas.sgi.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 11:53:32 -0500 Message-Id: <1020185612.7562.32.camel@jen.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-30 at 04:55, Steve Lord wrote: > Some multiple blocksize work, and better optimization of allocation > and writes in the mmap write case where memory pressure is the cause > of data getting flushed. We used to fragment files really badly in > this case, now fragmentation is reasonable - which causes major > speedup of some loads. > I would hold off taking this code until I do some more work on it, looks like I fixed one lot of performance by killing another one.... dbench throughput has gone down the tubes. Not sure yet when it came in - sometime in the last 24 hours I think. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 30 10:51: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 g3UHp7wJ025268 for ; Tue, 30 Apr 2002 10:51:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UHp7G9025267 for linux-xfs-outgoing; Tue, 30 Apr 2002 10:51:07 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from chimta02.algx.net (chimta02.algx.net [216.99.233.77]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UHorwJ025239 for ; Tue, 30 Apr 2002 10:50:53 -0700 Received: from jtsdell (66-2-81-26.customer.algx.net [66.2.81.26]) by chimmx02.algx.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GVE00KV25OJ9S@chimmx02.algx.net> for linux-xfs@oss.sgi.com; Tue, 30 Apr 2002 12:24:37 -0500 (CDT) Date: Tue, 30 Apr 2002 13:20:28 -0400 (EDT) From: jtrostel@snapserver.com Subject: Query about setfacl behavior To: acl-devel@bestbits.at, Timothy Shimmin , XFS list Reply-to: jtrostel@snapserver.com Message-id: Organization: Quantum Corp. / NASD MIME-version: 1.0 X-Mailer: XFMail 1.5.2 on Linux Content-type: text/plain; charset=iso-8859-15 Content-transfer-encoding: 7BIT X-Priority: 3 (Normal) Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk I am wondering if this is correct behavior... Using XFS CVS tip as of this morning (4/30/02) which gives me acl 2.0.10 [jt@jtsdevel xfs_part]$ getfacl --version getfacl 2.0.10 Set up an xfs partition with acls as follows: [jt@jtsdevel xfs_part]$ pwd /mnt/xfs_part [jt@jtsdevel xfs_part]$ getfacl . # file: . # owner: root # group: root user::rwx group::rwx mask::rwx other::rwx default:user::rwx default:group::rwx default:mask::rwx default:other::rwx I then created a new directoryon that partition, named jts_dir [jt@jtsdevel xfs_part]$ mkdir jts_dir [jt@jtsdevel xfs_part]$ getfacl jts_dir/ # file: jts_dir # owner: jt # group: jt user::rwx group::rwx mask::rwx other::rwx default:user::rwx default:group::rwx default:mask::rwx default:other::rwx Now.. I added an auxillary user 'a1' to the access aces. [jt@jtsdevel xfs_part]$ setfacl -m u:a1:rwx jts_dir/ [jt@jtsdevel xfs_part]$ getfacl jts_dir/ # file: jts_dir # owner: jt # group: jt user::rwx user:a1:rwx group::rwx mask::rwx other::rwx default:user::rwx default:group::rwx default:mask::rwx default:other::rwx Change the mask ace to no perms [jt@jtsdevel xfs_part]$ setfacl -m m::--- jts_dir/ [jt@jtsdevel xfs_part]$ getfacl jts_dir/ # file: jts_dir # owner: jt # group: jt user::rwx user:a1:rwx #effective:--- group::rwx #effective:--- mask::--- other::rwx default:user::rwx default:group::rwx default:mask::rwx default:other::rwx NOW! Change the aux. user 'a1' perms to something else, for instance 'rw'. The mask ace is also changed now. (It went from --- to rwx) Why? [jt@jtsdevel xfs_part]$ setfacl -m u:a1:rw jts_dir/ [jt@jtsdevel xfs_part]$ getfacl jts_dir/ # file: jts_dir # owner: jt # group: jt user::rwx user:a1:rw- group::rwx mask::rwx other::rwx default:user::rwx default:group::rwx default:mask::rwx default:other::rwx P.S. (For XFS folks: chacl -l returns the same values) -- John M. Trostel Senior Software Engineer Quantum Corp. / NASD jtrostel@snapserver.com From owner-linux-xfs@oss.sgi.com Tue Apr 30 11:08: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 g3UI8SwJ025678 for ; Tue, 30 Apr 2002 11:08:28 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UI8S5Z025677 for linux-xfs-outgoing; Tue, 30 Apr 2002 11:08:28 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UI8MwJ025651 for ; Tue, 30 Apr 2002 11:08:22 -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 NAA21116; Tue, 30 Apr 2002 13:09:09 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id NAA74884; Tue, 30 Apr 2002 13:09:08 -0500 (CDT) Subject: Re: mkfs problem:: no left space on device From: Eric Sandeen To: Benito Venegas Cc: linux-xfs@oss.sgi.com, Marek Kubita In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 30 Apr 2002 13:09:08 -0500 Message-Id: <1020190149.20886.23.camel@stout.americas.sgi.com> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Benito - On Tue, 2002-04-30 at 11:56, Benito Venegas wrote: > I have some problems in one server, when I run mkfs (mkfs.xfs) I got an > error: > I had downgraded xfsprogs version (including devel version) to recreate > file system. <1.3 worked> > > when I did that I saw there is a oversize blocks (6600763899904 v/s > 77702380 and some other variables are different between bot mkfs.xfs > version). I don't know why. This is almost certainly from the fact that xfsprogs 2.0+ uses BLKGETSIZE64, whereas pre-2.0 uses BLKGETSIZE. It appears that BLKGETSIZE64 is broken somehow in your setup. I'll send you a test program offline, to see what's going on. What scsi driver are you using? -Eric -- 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 30 11:36:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UIauwJ026101 for ; Tue, 30 Apr 2002 11:36:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UIauhH026100 for linux-xfs-outgoing; Tue, 30 Apr 2002 11:36:56 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from dns.securities.com (mail01.securities.com [57.69.12.71]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UIanwJ026074 for ; Tue, 30 Apr 2002 11:36:50 -0700 Received: from localhost (venevene@localhost) by dns.securities.com (8.11.6/8.11.6) with ESMTP id g3UIbcr20274; Tue, 30 Apr 2002 14:37:38 -0400 Date: Tue, 30 Apr 2002 14:37:38 -0400 (EDT) From: Benito Venegas To: Eric Sandeen cc: , Marek Kubita Subject: Re: mkfs problem:: no left space on device In-Reply-To: <1020190149.20886.23.camel@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 30 Apr 2002, Eric Sandeen wrote: > Hi Benito - > > On Tue, 2002-04-30 at 11:56, Benito Venegas wrote: > > > I have some problems in one server, when I run mkfs (mkfs.xfs) I got an > > error: > > > > > I had downgraded xfsprogs version (including devel version) to recreate > > file system. > > <1.3 worked> > I am using now 1.3.13 > > > > when I did that I saw there is a oversize blocks (6600763899904 v/s > > 77702380 and some other variables are different between bot mkfs.xfs > > version). I don't know why. > > This is almost certainly from the fact that xfsprogs 2.0+ uses > BLKGETSIZE64, whereas pre-2.0 uses BLKGETSIZE. It appears that > BLKGETSIZE64 is broken somehow in your setup. > > I'll send you a test program offline, to see what's going on. Waiting for it. > > What scsi driver are you using? Qlogic (qla2x00) > > -Eric > > -- Benito From owner-linux-xfs@oss.sgi.com Tue Apr 30 12:13: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 g3UJDdwJ026763 for ; Tue, 30 Apr 2002 12:13:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UJDdmr026762 for linux-xfs-outgoing; Tue, 30 Apr 2002 12:13:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UJDYwJ026736 for ; Tue, 30 Apr 2002 12:13:34 -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 OAA23745; Tue, 30 Apr 2002 14:14:21 -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 OAA81951; Tue, 30 Apr 2002 14:14:21 -0500 (CDT) Date: Tue, 30 Apr 2002 14:14:21 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Benito Venegas cc: linux-xfs@oss.sgi.com, Marek Kubita Subject: Re: mkfs problem:: no left space on device In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 30 Apr 2002, Benito Venegas wrote: > > What scsi driver are you using? > > > Qlogic (qla2x00) Ah, it's broken w.r.t. ioctls it doesn't know. Rather than returning an error, it will return random data :/ See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=62038 "qlogic drivers don't fail on unimplemented IOCTLs" For now, xfsprogs 1.3 is probably ok, or it would be fairly easy to modify your 2.0+ source to not use the BLKGETSIZE64 ioctl. -Eric -- 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 30 13:58:07 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UKw7wJ027777 for ; Tue, 30 Apr 2002 13:58:07 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UKw6Ic027776 for linux-xfs-outgoing; Tue, 30 Apr 2002 13:58:06 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from web13105.mail.yahoo.com (web13105.mail.yahoo.com [216.136.174.150]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UKw1wJ027748 for ; Tue, 30 Apr 2002 13:58:01 -0700 Message-ID: <20020430205854.12140.qmail@web13105.mail.yahoo.com> Received: from [208.35.40.2] by web13105.mail.yahoo.com via HTTP; Tue, 30 Apr 2002 13:58:54 PDT Date: Tue, 30 Apr 2002 13:58:54 -0700 (PDT) From: Ravi Wijayaratne Subject: xfs_force_shutdown problem To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi all We are seeing the following problem after some heavy I/O on our Software Raid 0 with LVM XFS system. xfs_force_shutdown(lvm(58,0),0x8) called from line 1039 of file xfs_trans.c. Return address = 0xc01cf019 kernel Apr 26 10:54:55 Corruption of in-memory data detected. Shutting down filesystem: lvm(58,0) kernel Apr 26 10:54:55 When we run xfsrepair afterwards we get many messages about file system integrity violations. We are running Linux 2.4.18 kernel. I have seen several postings about this problem in the xfs mailing list and the FAQ. Is there a fix for the above problem ? Thank you Ravi ===== ------------------------------ Ravi Wijayaratne __________________________________________________ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com From owner-linux-xfs@oss.sgi.com Tue Apr 30 14:11:40 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ULBdwJ028780 for ; Tue, 30 Apr 2002 14:11:40 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ULBdsY028779 for linux-xfs-outgoing; Tue, 30 Apr 2002 14:11:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ULBWwJ028751 for ; Tue, 30 Apr 2002 14:11:33 -0700 Received: from poppy-e185.americas.sgi.com (poppy-e185.americas.sgi.com [128.162.185.207]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id QAA03587; Tue, 30 Apr 2002 16:12:20 -0500 (CDT) Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.187.5]) by poppy-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA51392; Tue, 30 Apr 2002 16:12:20 -0500 (CDT) Date: Tue, 30 Apr 2002 16:12:20 -0500 (CDT) From: Eric Sandeen X-X-Sender: sandeen@stout.americas.sgi.com To: Ravi Wijayaratne cc: linux-xfs@oss.sgi.com Subject: Re: xfs_force_shutdown problem In-Reply-To: <20020430205854.12140.qmail@web13105.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Hi Ravi - The shutdown / in-memory corruption essentially means that something stomped on an in-memory structure, and when this was detected, the filesystem shut down. In the past, we have seen LVM+XFS cause stack overflows, which could maybe cause this, but would more likely oops. In general, these are pretty hard to debug. :( What version of LVM are you using? The output of xfs_repair might also be helpful. (I think force_shutdown causes a dirty log; you'd need to mount the filesystem to replay the log first, _then_ run xfs_repair to see if there are problems. xfs_repair on a dirty log will generate lots of errors and generally should not be done - see the -L option). -Eric On Tue, 30 Apr 2002, Ravi Wijayaratne wrote: > Hi all > > We are seeing the following problem after some heavy > I/O on our Software Raid 0 with LVM XFS system. > > xfs_force_shutdown(lvm(58,0),0x8) called from line > 1039 of file xfs_trans.c. Return address = 0xc01cf019 > kernel Apr 26 10:54:55 > Corruption of in-memory data detected. Shutting > down filesystem: lvm(58,0) kernel Apr 26 10:54:55 > > When we run xfsrepair afterwards we get many messages > about file system integrity violations. > > We are running Linux 2.4.18 kernel. I have seen > several postings about this problem in the xfs mailing > list and the FAQ. Is there a fix for the above problem > ? -- 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 30 14:21: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 g3ULLdwJ029069 for ; Tue, 30 Apr 2002 14:21:39 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ULLdi0029068 for linux-xfs-outgoing; Tue, 30 Apr 2002 14:21:39 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from bittersweet.hegbloom.net (ns.hegbloom.net [63.105.27.231]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3ULLYwJ029042 for ; Tue, 30 Apr 2002 14:21:34 -0700 Received: from bittersweet.hegbloom.net (localhost [127.0.0.1]) by bittersweet.hegbloom.net (8.12.3/8.12.3/Debian -6) with ESMTP id g3ULMQ0T017227 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 30 Apr 2002 14:22:27 -0700 Received: (from karlheg@localhost) by bittersweet.hegbloom.net (8.12.3/8.12.3/Debian -6) id g3ULMQAl017225; Tue, 30 Apr 2002 14:22:26 -0700 X-Authentication-Warning: bittersweet.hegbloom.net: karlheg set sender to karlheg@hegbloom.net using -f Subject: "Invalid client ID" after system lockup and subsequent reset ? From: "Karl M. Hegbloom" To: XFS Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 14:22:26 -0700 Message-Id: <1020201746.3216.27.camel@bittersweet> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Several times I've had my SMP machine with EVMS and XFS filesystems lock up and need to be reset. After the reboot, sometimes filesystems won't mount (it tends to be the "/var" partition) and I must boot to single user mode. When I attempt to mount the filesystem to cause the log replay, it refuses to do so, giving an error about an "invalid client id". I must then run "xfs_repair -L" on it to get the machine back online. What does that error mean, and is there a way to make it mount anyway and replay the log? How can I debug system lockups like that, so that I can give a meaningful and useful bug report? Will someone please work with me in private mail (or direct me to the relevant mailing list or documentation) and teach me how to debug the Linux kernel, to find lockups and such? -- As any limb well and duly exercised, grows stronger, the nerves of the body are corroborated thereby. --I. Watts. We are deB.ORG; You will be freed. From owner-linux-xfs@oss.sgi.com Tue Apr 30 14:26: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 g3ULQOwJ029284 for ; Tue, 30 Apr 2002 14:26:24 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ULQOTE029283 for linux-xfs-outgoing; Tue, 30 Apr 2002 14:26:24 -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 g3ULQJwJ029255 for ; Tue, 30 Apr 2002 14:26:19 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 4D0B61E6F9; Tue, 30 Apr 2002 23:27:07 +0200 (MEST) Date: Tue, 30 Apr 2002 23:27:06 +0200 From: Andi Kleen To: Steve Lord Cc: Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020430232706.A28044@wotan.suse.de> References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020178382.24279.31.camel@jen.americas.sgi.com> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 30, 2002 at 09:53:02AM -0500, Steve Lord wrote: > I said you cannot do it, I was referring to the existing code, yes it > is possible, but currently only ext2 and ext3 support this, and chattr > is an ext2 utility, not a generic linux filesystem utility. > > Adding it also introduces an on disk incompatibility between Irix and > Linux, and probably we could not take the code back to Irix, given its > origin. So we would need to version the superblock - we would need that > anyway for backward compatibility. All in all it gets to be a larger > project than you might think. My problem now is definitely not lack of > work ;-) If one would put it into a new extended attribute then I guess it could be compatible to irix. Disadvantage: checking it is more costly than just a bit in the main inode, but I guess when ACLs is enabled it has to search the EAs for each inode open anyways, so it probably won't make too much difference. -Andi From owner-linux-xfs@oss.sgi.com Tue Apr 30 14:48:56 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3ULmuwJ029574 for ; Tue, 30 Apr 2002 14:48:56 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3ULmuta029573 for linux-xfs-outgoing; Tue, 30 Apr 2002 14:48: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 g3ULmnwJ029543 for ; Tue, 30 Apr 2002 14:48: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 QAA21388; Tue, 30 Apr 2002 16:49:37 -0500 (CDT) Received: from sgi.com (ImuPLORglglYpe7r65OnbxkNj84QGNAS@cf-vpn-sw-corp-64-74.corp.sgi.com [134.15.64.74]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id QAA80180; Tue, 30 Apr 2002 16:49:37 -0500 (CDT) Message-ID: <3CCF122F.3030109@sgi.com> Date: Tue, 30 Apr 2002 16:52:47 -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: "Karl M. Hegbloom" CC: XFS Subject: Re: "Invalid client ID" after system lockup and subsequent reset ? References: <1020201746.3216.27.camel@bittersweet> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Karl M. Hegbloom wrote: >Several times I've had my SMP machine with EVMS and XFS filesystems lock >up and need to be reset. After the reboot, sometimes filesystems won't >mount (it tends to be the "/var" partition) and I must boot to single >user mode. > >When I attempt to mount the filesystem to cause the log replay, it >refuses to do so, giving an error about an "invalid client id". I must >then run "xfs_repair -L" on it to get the machine back online. > >What does that error mean, and is there a way to make it mount anyway >and replay the log? > >How can I debug system lockups like that, so that I can give a >meaningful and useful bug report? Will someone please work with me in >private mail (or direct me to the relevant mailing list or >documentation) and teach me how to debug the Linux kernel, to find >lockups and such? > This sounds like a corrupted log, the question is, who is doing the corruption here. Bad clientid means there was something in the log which was not recognized. Since EVMS and XFS have not had a lot of exposure with each other, I would suspect EVMS is not taking well to the XFS log writes, they are variable in size, between 512 bytes and 32K, and they can start on any 512 byte boundary. Not much else in Linux does I/O like this, possibly EVMS is dropping part of the I/O. I would raise this on the evms mailing list as well as the xfs one, we can then work out between us what is going on. Next time it happens, try xfs_logprint -t /dev/xxx before you mount the filesystem. It might fail in a similar manner to the kernel though. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 30 15:26:59 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UMQxwJ030035 for ; Tue, 30 Apr 2002 15:26:59 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UMQxFG030034 for linux-xfs-outgoing; Tue, 30 Apr 2002 15:26:59 -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 g3UMQnwJ030006 for ; Tue, 30 Apr 2002 15:26:49 -0700 Received: from erbenson.alaska.net (144-pm11.nwc.alaska.net [209.112.140.144]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3UMRfV25381 for ; Tue, 30 Apr 2002 14:27:41 -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 CA80D3924 for ; Tue, 30 Apr 2002 14:27:39 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id 92A291028A; Tue, 30 Apr 2002 14:27:39 -0800 (AKDT) Date: Tue, 30 Apr 2002 14:27:39 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020430142739.N21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jB+02Y6wHc2pEa2x" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020178382.24279.31.camel@jen.americas.sgi.com>; from lord@sgi.com on Tue, Apr 30, 2002 at 09:53:02AM -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 --jB+02Y6wHc2pEa2x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2002 at 09:53:02AM -0500, Steve Lord wrote: > On Tue, 2002-04-30 at 09:26, Ethan Benson wrote: > > On Tue, Apr 30, 2002 at 08:51:14AM -0500, Steve Lord wrote: > > > On Mon, 2002-04-29 at 15:16, Austin Gonyou wrote: > > > > I know you guys are gonna shoot the hell outta me for this, but wha= t can > > > > one do to set files immutable, as in chattr -i, with XFS? TIA > > > > --=20 > > >=20 > > > Sorry, no can do, XFS does not have an immutable inode concept. All > > > you can do is close the permissions down on the inode. > >=20 > > which doesn't work since 1) root is immune to permissions and 2) there > > is no append-only permission bit. > >=20 > > as i understand it there are some unused bits left in the XFS inode, > > so adding these is possible (and if current implementations set these > > to zero on create and ignore and leave alone on modify the change > > would be fully backward compatible (other then older implementations > > ignoring them)). >=20 > I said you cannot do it, I was referring to the existing code, yes it > is possible, but currently only ext2 and ext3 support this, and chattr > is an ext2 utility, not a generic linux filesystem utility. >=20 > Adding it also introduces an on disk incompatibility between Irix and > Linux, and probably we could not take the code back to Irix, given its > origin. So we would need to version the superblock - we would need that > anyway for backward compatibility. All in all it gets to be a larger > project than you might think. My problem now is definitely not lack of > work ;-) why do you necessarily have to version the superblock? do current implemementations blow up if the existing reserved inodes are anything but zero? --=20 Ethan Benson http://www.alaska.net/~erbenson/ --jB+02Y6wHc2pEa2x 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 iEYEARECAAYFAjzPGlsACgkQJKx7GixEevzA2ACdGWBfBU12RXJDPNQ3YavTolCr issAn1vkmocbh/hAriOdOVlcsZ5MXWf3 =aNPV -----END PGP SIGNATURE----- --jB+02Y6wHc2pEa2x-- From owner-linux-xfs@oss.sgi.com Tue Apr 30 15:30:33 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UMUXwJ030209 for ; Tue, 30 Apr 2002 15:30:33 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UMUX6Z030208 for linux-xfs-outgoing; Tue, 30 Apr 2002 15:30:33 -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 g3UMUPwJ030179 for ; Tue, 30 Apr 2002 15:30:25 -0700 Received: from erbenson.alaska.net (144-pm11.nwc.alaska.net [209.112.140.144]) by malik.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3UMVGu99417 for ; Tue, 30 Apr 2002 14:31:16 -0800 (AKDT) (envelope-from erbenson@alaska.net) Received: from plato.local.lan (plato.local.lan [192.168.0.4]) by erbenson.alaska.net (Postfix) with ESMTP id 95BA83924 for ; Tue, 30 Apr 2002 14:31:15 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id A491B1028A; Tue, 30 Apr 2002 14:31:15 -0800 (AKDT) Date: Tue, 30 Apr 2002 14:31:15 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020430143115.O21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> <20020430232706.A28044@wotan.suse.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="b/Q3JWIUAuLE0ZFy" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020430232706.A28044@wotan.suse.de>; from ak@suse.de on Tue, Apr 30, 2002 at 11:27:06PM +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 --b/Q3JWIUAuLE0ZFy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2002 at 11:27:06PM +0200, Andi Kleen wrote: > On Tue, Apr 30, 2002 at 09:53:02AM -0500, Steve Lord wrote: > > I said you cannot do it, I was referring to the existing code, yes it > > is possible, but currently only ext2 and ext3 support this, and chattr > > is an ext2 utility, not a generic linux filesystem utility. > >=20 > > Adding it also introduces an on disk incompatibility between Irix and > > Linux, and probably we could not take the code back to Irix, given its > > origin. So we would need to version the superblock - we would need that > > anyway for backward compatibility. All in all it gets to be a larger > > project than you might think. My problem now is definitely not lack of > > work ;-) >=20 > If one would put it into a new extended attribute then I guess it could > be compatible to irix.=20 >=20 > Disadvantage: checking it is more costly than just a bit in the main inod= e, > but I guess when ACLs is enabled it has to search the EAs for each inode= =20 > open anyways, so it probably won't make too much difference. i believe that would be considered too ugly of a kludge, immutable/append-only are bits, not attributes. it also gets messy since you need to establish an entirely new xattr namespace whose access is controlled by CAP_LINUX_IMMUTABLE if you really want to do it right. (with ext2/3 when you remove CAP_LINUX_IMMUTABLE from the capability bounding set root cannot set or remove these bits, but if you use the system.* namespace root could just remove them with setfattr). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --b/Q3JWIUAuLE0ZFy 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 iEYEARECAAYFAjzPGzMACgkQJKx7GixEevzfqACfZNDmvI/Yg3XXS4Rwc8V4kYKy jBsAn3dSECSKoYrlRT8OSuc4NfbVdYJk =Bwkh -----END PGP SIGNATURE----- --b/Q3JWIUAuLE0ZFy-- From owner-linux-xfs@oss.sgi.com Tue Apr 30 15:34:19 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UMYIwJ030409 for ; Tue, 30 Apr 2002 15:34:19 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UMYI03030408 for linux-xfs-outgoing; Tue, 30 Apr 2002 15:34:18 -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 g3UMYAwJ030380 for ; Tue, 30 Apr 2002 15:34:10 -0700 Received: from erbenson.alaska.net (144-pm11.nwc.alaska.net [209.112.140.144]) by iris.slb.nwc.acsalaska.net (8.11.6/8.11.6) with ESMTP id g3UMZ3V29798 for ; Tue, 30 Apr 2002 14:35:03 -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 EFB2C3924 for ; Tue, 30 Apr 2002 14:35:01 -0800 (AKDT) Received: by plato.local.lan (Postfix, from userid 1000) id F1D4C1028A; Tue, 30 Apr 2002 14:35:01 -0800 (AKDT) Date: Tue, 30 Apr 2002 14:35:01 -0800 From: Ethan Benson To: linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020430143501.P21791@plato.local.lan> Mail-Followup-To: linux-xfs@oss.sgi.com References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DRfr/2Y1Zz/5r+Kb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1020178382.24279.31.camel@jen.americas.sgi.com>; from lord@sgi.com on Tue, Apr 30, 2002 at 09:53:02AM -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 --DRfr/2Y1Zz/5r+Kb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 30, 2002 at 09:53:02AM -0500, Steve Lord wrote: >=20 > I said you cannot do it, I was referring to the existing code, yes it > is possible, but currently only ext2 and ext3 support this, and chattr > is an ext2 utility, not a generic linux filesystem utility. chattr is a ext2 utility, but immutable/append-only are not an ext2/linux invention, they also exist on the *BSDs, they even go further in implementing two versions of both, a system one only available to root and not alterable if the securelevel >=3D 1 and a user one which the owner of the file may use (user append-only i can see as useful, but user immutable is questionable). --=20 Ethan Benson http://www.alaska.net/~erbenson/ --DRfr/2Y1Zz/5r+Kb 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 iEYEARECAAYFAjzPHBUACgkQJKx7GixEevyxYQCfXZIBAD0BEA+IhaLo0Oe+sOeS LFsAn2ABkkw9mdfqrzmnbXfqfd3YFGu1 =65DB -----END PGP SIGNATURE----- --DRfr/2Y1Zz/5r+Kb-- From owner-linux-xfs@oss.sgi.com Tue Apr 30 16:40: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 g3UNeLwJ030935 for ; Tue, 30 Apr 2002 16:40:21 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UNeLZT030934 for linux-xfs-outgoing; Tue, 30 Apr 2002 16:40:21 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from deliverator.sgi.com (deliverator.sgi.com [204.94.214.10]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UNeIwJ030908 for ; Tue, 30 Apr 2002 16:40:18 -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 QAA2564399 for ; Tue, 30 Apr 2002 16:41:10 -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 JAA48866 for linux-xfs@oss.sgi.com; Wed, 1 May 2002 09:39:50 +1000 (EST) Date: Wed, 1 May 2002 09:39:50 +1000 (EST) From: Nathan Scott Message-Id: <200204302339.JAA48866@snort.melbourne.sgi.com> To: linux-xfs@oss.sgi.com Subject: TAKE - acl-2.0.11 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk Date: Tue Apr 30 16:38:38 PDT 2002 Workarea: snort.melbourne.sgi.com:/home/nathans/pagebuf The following file(s) were checked into: bonnie.engr.sgi.com:/isms/slinx/2.4.x-xfs Modid: xfs-cmds:slinx:117896a cmd/acl/VERSION - 1.28 cmd/acl/doc/CHANGES - 1.32 cmd/acl/debian/changelog - 1.23 cmd/acl/test/setfacl.test - 1.3 cmd/acl/libacl/__acl_to_any_text.c - 1.2 - __acl_to_any_text bug fix from Andreas, test updates. From owner-linux-xfs@oss.sgi.com Tue Apr 30 16:48:38 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UNmcwJ031120 for ; Tue, 30 Apr 2002 16:48:38 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UNmcTm031119 for linux-xfs-outgoing; Tue, 30 Apr 2002 16:48:38 -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 g3UNmWwJ031091 for ; Tue, 30 Apr 2002 16:48:33 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 7B9231E487; Wed, 1 May 2002 01:49:21 +0200 (MEST) Date: Wed, 1 May 2002 01:49:19 +0200 From: Andi Kleen To: Ethan Benson Cc: linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020501014919.A12139@wotan.suse.de> References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> <20020430232706.A28044@wotan.suse.de> <20020430143115.O21791@plato.local.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020430143115.O21791@plato.local.lan> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 30, 2002 at 02:31:15PM -0800, Ethan Benson wrote: > On Tue, Apr 30, 2002 at 11:27:06PM +0200, Andi Kleen wrote: > > On Tue, Apr 30, 2002 at 09:53:02AM -0500, Steve Lord wrote: > > > I said you cannot do it, I was referring to the existing code, yes it > > > is possible, but currently only ext2 and ext3 support this, and chattr > > > is an ext2 utility, not a generic linux filesystem utility. > > > > > > Adding it also introduces an on disk incompatibility between Irix and > > > Linux, and probably we could not take the code back to Irix, given its > > > origin. So we would need to version the superblock - we would need that > > > anyway for backward compatibility. All in all it gets to be a larger > > > project than you might think. My problem now is definitely not lack of > > > work ;-) > > > > If one would put it into a new extended attribute then I guess it could > > be compatible to irix. > > > > Disadvantage: checking it is more costly than just a bit in the main inode, > > but I guess when ACLs is enabled it has to search the EAs for each inode > > open anyways, so it probably won't make too much difference. > > i believe that would be considered too ugly of a kludge, > immutable/append-only are bits, not attributes. it also gets messy It's just an implementation detail how the bits are stored, users do not notice as long as the ext2 attr ioctl is supported. -Andi From owner-linux-xfs@oss.sgi.com Tue Apr 30 16:56:42 2002 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.12.3/8.12.3) with ESMTP id g3UNugwJ031325 for ; Tue, 30 Apr 2002 16:56:42 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g3UNugJi031324 for linux-xfs-outgoing; Tue, 30 Apr 2002 16:56:42 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g3UNuZwJ031298 for ; Tue, 30 Apr 2002 16:56:35 -0700 Received: from tulip-e185.americas.sgi.com (tulip-e185.americas.sgi.com [128.162.185.208]) by zeus-e8.americas.sgi.com (SGI-SGI-8.9.3/americas-smart-nospam1.1) with ESMTP id SAA24812; Tue, 30 Apr 2002 18:57:23 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-21.corp.sgi.com [134.15.64.21]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id SAA89232; Tue, 30 Apr 2002 18:57:22 -0500 (CDT) Subject: Re: Chattr From: Stephen Lord To: Andi Kleen Cc: Ethan Benson , linux-xfs@oss.sgi.com In-Reply-To: <20020501014919.A12139@wotan.suse.de> References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> <20020430232706.A28044@wotan.suse.de> <20020430143115.O21791@plato.local.lan> <20020501014919.A12139@wotan.suse.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 18:49:09 -0500 Message-Id: <1020210550.1179.3.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-30 at 18:49, Andi Kleen wrote: > On Tue, Apr 30, 2002 at 02:31:15PM -0800, Ethan Benson wrote: > > On Tue, Apr 30, 2002 at 11:27:06PM +0200, Andi Kleen wrote: > > > On Tue, Apr 30, 2002 at 09:53:02AM -0500, Steve Lord wrote: > > > > I said you cannot do it, I was referring to the existing code, yes it > > > > is possible, but currently only ext2 and ext3 support this, and chattr > > > > is an ext2 utility, not a generic linux filesystem utility. > > > > > > > > Adding it also introduces an on disk incompatibility between Irix and > > > > Linux, and probably we could not take the code back to Irix, given its > > > > origin. So we would need to version the superblock - we would need that > > > > anyway for backward compatibility. All in all it gets to be a larger > > > > project than you might think. My problem now is definitely not lack of > > > > work ;-) > > > > > > If one would put it into a new extended attribute then I guess it could > > > be compatible to irix. > > > > > > Disadvantage: checking it is more costly than just a bit in the main inode, > > > but I guess when ACLs is enabled it has to search the EAs for each inode > > > open anyways, so it probably won't make too much difference. > > > > i believe that would be considered too ugly of a kludge, > > immutable/append-only are bits, not attributes. it also gets messy > > It's just an implementation detail how the bits are stored, users do not > notice as long as the ext2 attr ioctl is supported. > > -Andi I dug some more and there does not appear to be checking on unused bits in the di_flags field of the on disk inode, although that does not include xfs_check which is a rather byzantine chunk of code. So it might be possible to use a bit in here. Like I said though, right now I am not going to get near something like this for quite a while. Andi, is immutable checking all done above the vfs or do filesystems have to enforce it as well? Steve From owner-linux-xfs@oss.sgi.com Tue Apr 30 17:12: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 g410C4wJ031633 for ; Tue, 30 Apr 2002 17:12:04 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g410C4Ko031632 for linux-xfs-outgoing; Tue, 30 Apr 2002 17:12:04 -0700 X-Authentication-Warning: oss.sgi.com: majordomo set sender to owner-linux-xfs@oss.sgi.com using -f Received: from zeus-e8.americas.sgi.com ([198.149.7.103]) by oss.sgi.com (8.12.3/8.12.3) with SMTP id g410BxwJ031606 for ; Tue, 30 Apr 2002 17:11:59 -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 TAA25798; Tue, 30 Apr 2002 19:12:48 -0500 (CDT) Received: from [192.168.1.101] (cf-vpn-sw-corp-64-21.corp.sgi.com [134.15.64.21]) by tulip-e185.americas.sgi.com (980427.SGI.8.8.8/SGI-server-1.7) with ESMTP id TAA87778; Tue, 30 Apr 2002 19:12:47 -0500 (CDT) Subject: Re: Chattr From: Stephen Lord To: Stephen Lord Cc: Andi Kleen , Ethan Benson , linux-xfs@oss.sgi.com In-Reply-To: <1020210550.1179.3.camel@localhost.localdomain> References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> <20020430232706.A28044@wotan.suse.de> <20020430143115.O21791@plato.local.lan> <20020501014919.A12139@wotan.suse.de> <1020210550.1179.3.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 30 Apr 2002 19:04:33 -0500 Message-Id: <1020211474.1179.6.camel@localhost.localdomain> Mime-Version: 1.0 Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, 2002-04-30 at 18:49, Stephen Lord wrote: > > I dug some more and there does not appear to be checking on unused bits > in the di_flags field of the on disk inode, although that does not > include xfs_check which is a rather byzantine chunk of code. So it > might be possible to use a bit in here. Like I said though, right > now I am not going to get near something like this for quite a while. > > Andi, is immutable checking all done above the vfs or do filesystems > have to enforce it as well? > > Steve > OK, I answered that myself - maybe we can do this quickly - provided chattr does not check the filesystem type it is applied too. Steve From owner-linux-xfs@oss.sgi.com Tue Apr 30 17: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 g410ajwJ031852 for ; Tue, 30 Apr 2002 17:36:45 -0700 Received: (from majordomo@localhost) by oss.sgi.com (8.12.3/8.12.3/Submit) id g410ajKZ031851 for linux-xfs-outgoing; Tue, 30 Apr 2002 17:36:45 -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 g410adwJ031825 for ; Tue, 30 Apr 2002 17:36:39 -0700 Received: from Hermes.suse.de (Charybdis.suse.de [213.95.15.201]) by Cantor.suse.de (Postfix) with ESMTP id 29AB01EB72; Wed, 1 May 2002 02:37:28 +0200 (MEST) Date: Wed, 1 May 2002 02:37:26 +0200 From: Andi Kleen To: Stephen Lord Cc: Andi Kleen , Ethan Benson , linux-xfs@oss.sgi.com Subject: Re: Chattr Message-ID: <20020501023726.A15270@wotan.suse.de> References: <1020111402.18036.0.camel@UberGeek> <1020174674.24262.0.camel@jen.americas.sgi.com> <20020430062608.M21791@plato.local.lan> <1020178382.24279.31.camel@jen.americas.sgi.com> <20020430232706.A28044@wotan.suse.de> <20020430143115.O21791@plato.local.lan> <20020501014919.A12139@wotan.suse.de> <1020210550.1179.3.camel@localhost.localdomain> <1020211474.1179.6.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1020211474.1179.6.camel@localhost.localdomain> User-Agent: Mutt/1.3.22.1i Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Tue, Apr 30, 2002 at 07:04:33PM -0500, Steve Lord wrote: > On Tue, 2002-04-30 at 18:49, Stephen Lord wrote: > > > > > I dug some more and there does not appear to be checking on unused bits > > in the di_flags field of the on disk inode, although that does not > > include xfs_check which is a rather byzantine chunk of code. So it > > might be possible to use a bit in here. Like I said though, right > > now I am not going to get near something like this for quite a while. That would be the simplest way after all if it works. > > > > Andi, is immutable checking all done above the vfs or do filesystems > > have to enforce it as well? I think it's done in the file system. > OK, I answered that myself - maybe we can do this quickly - provided > chattr does not check the filesystem type it is applied too. I don't think it does. It just does the ioctl. P.S.: Overall I don't think immutable/append-only are too useful because attackers can always get rid of them by mknod'ing a device and writing to the disk directly and forcing an inode flush. So it may not be worth much effort for the pseudo security ones, as they only give a false sense of security. immutable is sometimes useful to prevent mistakes, but not for more. The only ones that may be worth it are 'S' (force O_SYNC, especially for directories e.g. to handle qmail/postfix spool dirs without forcing synchronous for the whole fs), 'A' (no atime) and 'd' for incremental backup purposes. -And