From owner-linux-xfs@oss.sgi.com Sun Jan 1 20:44:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 01 Jan 2006 20:45:02 -0800 (PST) Received: from iss04.interliant.com (iss04.interliant.com [207.113.241.148]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k024irwL007320 for ; Sun, 1 Jan 2006 20:44:59 -0800 Received: from EX-008.mail.navisite.com (ex-008.interliant.com [207.113.240.188]) by iss04.interliant.com (8.10.2/8.10.2) with ESMTP id k024i6v17522 for ; Sun, 1 Jan 2006 22:44:06 -0600 (CST) Received: from EX-101.mail.navisite.com ([172.16.1.24]) by EX-008.mail.navisite.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Jan 2006 22:40:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Kernel Panic 2.6.14.5 with xfs Date: Sun, 1 Jan 2006 22:42:29 -0600 Message-ID: <9560740CA5C0C54BB3853AC9A4164BBB01BD8963@EX-101.mail.navisite.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Kernel Panic 2.6.14.5 with xfs thread-index: AcYPVu/JFTwDO/8xSBmtDypSh3YKwg== From: "Jose Thomas" To: X-OriginalArrivalTime: 02 Jan 2006 04:40:53.0465 (UTC) FILETIME=[B6C5AC90:01C60F56] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k024ixwL007331 X-archive-position: 7031 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tjose@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 1597 Lines: 54 Greetings, With a vanilla kernel (2.6.14.5), I checked XFS and rebuild the kernel; by following standard procedure; Make menuconfig Make bzImage Make modules Make modules_install Make install. All went on with out throwing any errors. Then I rebooted the system, but a kernel panic is occuring The following are the message from the console; ========================================================== Booting 'Red hat Enterprise Linux AS 92.6.14.5)' root (hd0,0) Filesystem type is ext2fs, partition type 0x83 kernel /vmlinuz-2.6.14.5 ro root=LABEL=/ rhgb quit bigphysarea=102623 elevator=deadline [Linux-bzImage, setup=0x1e00, size=ox1d7b0d] initrd /initrd-2.6.14.5.img [Linux-initrd @ 0x37f70000, 0x7f521 bytes] Uncompressing Linux... Ok, booting the kernel. ibm_acpi:ec object not found ide0: I/O resource 0x1F0-0x1F7 not free. ide0: ports already in use, skipping probe Red Hat nash version 4.2.1.3 starting mkrootdev: lable / not found mount: error 2 mounting ext3 mount: error 2 mounting none switchroot: mount failed: 22 umount /initrd/dev/ failed: 2 Kernel panic - not syncing: Attempted to kill init! ============================================================= Kindly let me know any body encounter similar kind of problems or any suggestive solutions? Any experimental attempt is also welcome. The system is a Dell OPTILEX GX520. OS used to build was RHEL 4. Thanks in advance Jose ============================================ Jose Thomas tjose@kasenna.com http://www.kasenna.com/ 91-80-51391632(Office),91-98451-87820 (cell) ============================================ From owner-linux-xfs@oss.sgi.com Mon Jan 2 01:42:50 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Jan 2006 01:42:51 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k029gnwL013715 for ; Mon, 2 Jan 2006 01:42:50 -0800 Received: by wproxy.gmail.com with SMTP id i32so1970871wra for ; Mon, 02 Jan 2006 01:39:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=FXIMXpbCEXSJ/i86x74E96Qj3cIK69U8Z5ENP0LA/tJEVPxbPZxMvKchmWNX6wyv1/Jw38abXl4ve9AgTOiu0+PUE9bqbyl+qKNPpbOEzBiHHVlx8jzDTkiPQ7+i8y2yGzgBPfZSJEQwwxU8W3JEqGVN+TkXvuKNDs9ayoUhFQA= Received: by 10.54.76.4 with SMTP id y4mr168225wra; Mon, 02 Jan 2006 01:39:02 -0800 (PST) Received: by 10.54.122.7 with HTTP; Mon, 2 Jan 2006 01:39:02 -0800 (PST) Message-ID: <5d96567b0601020139u6e132403mc346c5c5881cc54a@mail.gmail.com> Date: Mon, 2 Jan 2006 11:39:02 +0200 From: "Raz Ben-Jehuda(caro)" To: linux-xfs@oss.sgi.com Subject: xfs_rtcp MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k029gowL013717 X-archive-position: 7035 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: raziebe@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 214 Lines: 11 hello. my name is raz. i have mouted xfs volume with realtime extersion. i have begin copying with xfs_rtcp. looking at the iostat it looked that the writing is done in 300 KB/s. why ? can i speed it up ? -- Raz From owner-linux-xfs@oss.sgi.com Mon Jan 2 13:32:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Jan 2006 13:32:38 -0800 (PST) Received: from FPNYEXCBE01.opus-i.corp (mail4.opus-i.net [209.10.181.136]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k02LWWwL018941 for ; Mon, 2 Jan 2006 13:32:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 MIME-Version: 1.0 Subject: linux_xfs and spam problems Date: Mon, 2 Jan 2006 16:26:59 -0500 Message-ID: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: linux_xfs and spam problems Thread-Index: AcYPgI9/5r0D6kZXTKCdY2VrD1L77AAYrPwD From: "Allan Haywood" To: Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7056 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: ahaywood@datallegro.com Precedence: bulk X-list: linux-xfs Content-Length: 218 Lines: 11 Does anyone know who is the administrator for this mailing list. I am getting a TON of SPAM comming through linux-xfs. Allan Haywood Data Warehouse Systems Specialist DATAllegro [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Mon Jan 2 21:07:45 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Jan 2006 21:07:51 -0800 (PST) Received: from ext.storadinc.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0357fwL027140 for ; Mon, 2 Jan 2006 21:07:45 -0800 Received: from agami.com ([192.168.168.132]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k0353fSQ003304 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 2 Jan 2006 21:03:45 -0800 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.10/8.12.10) with ESMTP id k0353aL5025860 for ; Mon, 2 Jan 2006 21:03:36 -0800 Received: from [192.168.0.207] ([10.123.200.1]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jan 2006 21:03:35 -0800 Message-ID: <43BA04AF.2060703@agami.com> Date: Tue, 03 Jan 2006 10:29:27 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Unexpected xfs_buf_item_init initialization and inflexible xfs_buf_item_zone References: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> In-Reply-To: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jan 2006 05:03:35.0806 (UTC) FILETIME=[0D3429E0:01C61023] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7063 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: stripathi@agami.com Precedence: bulk X-list: linux-xfs Content-Length: 2991 Lines: 76 Hi, While changing the (current default) number of inode allocated at once, I found two things a bit unexpected: Section A: ---------- xfs_buf_item_init() /* * chunks is the number of XFS_BLI_CHUNK size pieces * the buffer can be divided into. Make sure not to * truncate any pieces. map_size is the size of the * bitmap needed to describe the chunks of the buffer. */ chunks = (int)((XFS_BUF_COUNT(bp) + (XFS_BLI_CHUNK - 1)) >> XFS_BLI_SHIFT); map_size = (int)((chunks + NBWORD) >> BIT_TO_WORD_SHIFT); ---> 2 For 4096 block page (linux default), one map is required per page. Given this, line 2 appears odd. Instead, it should be map_size = (int)((chunks + NBWORD -1) >> BIT_TO_WORD_SHIFT); Also, chunks calculation may go well off the mark of the blocks are not page aligned. The code does not block alignment check. It only checks for sectoral alignment. For example, lets say I need 32768 pb_buffer_length. However, the offset is not 4096 aligned. Lets say it starts at, 2048. Given this, _pagebuf_lookup_pages will prepare 8 + 1 pages. page_count = page_buf_btoc(end) - page_buf_btoct(bp->pb_file_offset); In this case, chunks calculated will suffice for only 8 pages. In this particular case, the statement 2 makes amend for it and allocates correct map size. But, it oversteps when the offset is block (4096) aligned. That is, if offset was 0, still it will allocate 9 pages. It affects the xfs_next_bit called in xfs_buf_item_size and xfs_buf_item_format. If last chunk of the 8 blocks allocated are dirty, the code will over step into 9th (which might be not even cached) page and potentially return in "unable to handle paging request". This is because the xfs_next_bit will not return -1 as it does not see the end due to map size overstepping. Instead, the calculation should rely on page count directly as XFS_PAGE_COUNT(bp) bp->bp_page_count. Section B: --------- xfs_init() ..... /* * The size of the zone allocated buf log item is the maximum * size possible under XFS. This wastes a little bit of memory, * but it is much faster. */ xfs_buf_item_zone = kmem_zone_init((sizeof(xfs_buf_log_item_t) + (((XFS_MAX_BLOCKSIZE / XFS_BLI_CHUNK) / NBWORD) * sizeof(int))), "xfs_buf_item"); This restricts the Maximum Possible blocks which can be dirtied in a buf item to 17 pages (xfs_buf_log_item_t contains one map and + part yields 16 maps). It appears very inflexible scheme. I am trying to allocate inodes in data stripe width at a time. One representative stripe width is 32 blocks (4096). However, due to this limitation (which I noticed after very late), it looks impossible. I will really appreciate if one can comment if I have misunderstood something. Regards, Shailendra From owner-linux-xfs@oss.sgi.com Mon Jan 2 22:20:14 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 02 Jan 2006 22:20:16 -0800 (PST) Received: from mail1.digitalresources.net (mail1.digitalresources.net [69.80.0.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k036KAwL000735 for ; Mon, 2 Jan 2006 22:20:14 -0800 Received: from sirak (mmds-216-19-43-110.sqpk.az.commspeed.net [216.19.43.110]) by mail1.digitalresources.net (Vircom SMTPRS 4.2.425.16) with SMTP id for ; Mon, 2 Jan 2006 23:16:14 -0700 X-Modus-ReverseDNS: OK X-Modus-BlackList: 216.19.43.110=OK;murrah@aspect1.net=OK X-Modus-RBL: 216.19.43.110=OK X-Modus-Trusted: 216.19.43.110=NO Message-ID: <001901c6102d$096ae150$fe01a8c0@sirak> From: "murrah boswell" To: References: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> Subject: Re: linux_xfs and spam problems Date: Mon, 2 Jan 2006 23:15:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-archive-position: 7064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: murrah@aspect1.net Precedence: bulk X-list: linux-xfs Content-Length: 332 Lines: 14 > Does anyone know who is the administrator for this mailing list. > > I am getting a TON of SPAM comming through linux-xfs. same here! not much response from technical xfs related questions (actually a goose egg), but spam-a-lot. in the process of converting all systems to ext3, so will be rid of both soon. murrah boswell From owner-linux-xfs@oss.sgi.com Tue Jan 3 03:27:01 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 03:27:04 -0800 (PST) Received: from node1.mail8.netdiscounter.de (node1.mail8.netdiscounter.de [62.112.137.244]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k03BR0wL001649 for ; Tue, 3 Jan 2006 03:27:00 -0800 Received: from localhost (localhost [127.0.0.1]) by mail8.netdiscounter.de (Postfix) with ESMTP id 960C270000A2 for ; Tue, 3 Jan 2006 12:23:11 +0100 (CET) Received: from node1.mail8.netdiscounter.de ([127.0.0.1]) by localhost (mail8 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04241-06 for ; Tue, 3 Jan 2006 12:23:09 +0100 (CET) Received: from [10.10.10.197] (eth0.asg420.netdiscounter.de [62.112.128.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail8.netdiscounter.de (Postfix) with ESMTP id 87FEC70000A9 for ; Tue, 3 Jan 2006 12:23:09 +0100 (CET) Message-ID: <43BA5E9E.6040108@netdiscounter.de> Date: Tue, 03 Jan 2006 12:23:10 +0100 From: "Michael Reck [ Netdiscounter GmbH]" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Problem with mixed Files Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-archive-position: 7071 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mreck@netdiscounter.de Precedence: bulk X-list: linux-xfs Content-Length: 6223 Lines: 153 Hi, We are using XFS on an Mailserver. We have a strange Problem which could be tracked down to Filesystem or Hardware level. The Problem: Some of the stored mails get`s mixxed with various contents of the Filesystem or other Mails. The Files "look" normal dumped with "od" - no strange content. This Problem could be reproduced. If we send and massive amount of Data slighly smaller than Blocksize some of the generated Files gets mixxed. If i should guess, i would say that the files get filled with content to fill the Inode. One of this Files: mail8:# cat 1136200241.M378338P21770V000000000000000FI2D87F6C0_0.* Return-Path: X-Original-To: Delivered-To: Received: from localhost (localhost [127.0.0.1]) by mail8.netdiscounter.de (Postfix) with ESMTP id 402E2407E6D for ; Mon, 2 Jan 2006 12:10:41 +0100 (CET) Received: from node2.mail8.netdiscounter.de ([127.0.0.1]) by localhost (mail8 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20751-02 for ; Mon, 2 Jan 2006 12:10:41 +0100 (CET) Received-SPF: none (mail8.netdiscounter.de: 212.185.119.14 is neither permitted nor denied by domain of 93660.t-wp.de) client-ip=212.185.119.14; envelope-from=apache@93660.t-wp.de; helo=93660.t-wp.de; Received: from 93660.t-wp.de (93660.t-wp.de [212.185.119.14]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by mail8.netdiscounter.de (Postfix) with ESMTP id E4747407E6B for ; Mon, 2 Jan 2006 12:10:38 +0100 (CET) Received: (from apache@localhost) by 93660.t-wp.de (8.11.6/8.11.6) id k02BAch16561; Mon, 2 Jan 2006 12:10:38 +0100 Date: Mon, 2 Jan 2006 12:10:38 +0100 From: Apache Message-Id: <200601021110.k02BAch16561@93660.t-wp.de> To: Subject: Kontaktformular X-Virus-Scanned: by amavisd-new-2.3.1 (20050509) at netdiscounter.de X-Spam-Status: No, hits=-0.685 tagged_above=-999 required=4 tests=[AWL=-0.686, BAYES_50=0.001] X-Spam-Level: Kontakt_Titel: Kontakt_Anrede: Frau Kontakt_Vorname: Birgit Kontakt_Name: Geiger Kontakt_Strasse: Im Hlderle 10 Kontakt_Ort: 72224 Ebhausen Vertriebsschiene: Kontakt_Rueckrufnummer: 1234 Kontakt_email: Markt_in: 71083 Herrenberg, Daimlerstra>sonderzeichen>e / Filial-Nummer: 20_113 Vertriebsschiene: Baumarkt & Garten Kontakt_Anliegen: Warum erhalten unsere Nachbarn und wir selten bis berhaupt nie Ihren Baumarktprospekt, Bewohner in anderen Straen aber regelmig? This is the End of the Mail - in the "od" output the File has two "\n" and this parts beginns ( linebreaks only from mailclient) 5 28807:1130141327 1135943767.M312321P24833V000000000000000FI2D87E881_0.mail8,S=5487:2,S 5668 28808:1130141327 1135943824.M129273P25264V000000000000000FI2D87E883_0.mail8,S=12492:2,S 12847 28809:1130141327 1135945115.M266543P2366V0000000000000802I2487E882_0.mail8,S=1787:2,S 1824 28810:1130141327 1135945205.M514301P3648V0000000000000802I2487E884_0.mail8,S=10589:2,S 10823 28811:1130141327 1135945366.M860531P5857V0000000000000802I2487E885_0.mail8,S=2333:2,S 2390 28812:1130141327 1135945389.M112532P6184V0000000000000802I2487E887_0.mail8,S=3311:2,S 3391 28813:1130141327 1135945512.M142142P5376V000000000000000FI2D87E886_0.mail8,S=2946:2,S 4214 28814:1130141327 1135945514.M134569P5401V000000000000000FI2D87E889_0.mail8,S=2909:2,S 3012 28815:1130141327 1135945581.M825132P5862V000000000000000FI2D87E888_0.mail8,S=2346:2,S 2406 28816:1130141327 1135945660.M161409P9937V0000000000000802I2487E88B_0.mail8,S=3843:2,S 3960 28817:1130141327 1135945726.M828291P10844V0000000000000802I2487E88A_0.mail8,S=78387:2,S 79724 28818:1130141327 1135946430.M606564P21067V0000000000000802I2487E88C_0.mail8,S=2413:2,S 2472 28819:1130141327 1135946555.M460388P13335V000000000000000FI2D87E88D_0.mail8,S=3005:2,S 3067 28820:1130141327 1135946793.M590835P26374V0000000000000802I2487E88E_0.mail8,S=9277:2,S 9423 28821:1130141327 1135947014.M366813P16832V000000000000000FI2D87E88F_0.mail8,S=2692:2,S 2751 28822:1130141327 1135947298.M110137P18967V000000000000000FI2D87E890_0.mail8,S=4175:2,S 4271 28823:1130141327 1135947301.M494113P19005V000000000000000FI2D87E893_0.mail8,S=9940:2,S 10203 28824:1130141327 1135947341.M765305P19319V000000000000000FI2D87E894_0.mail8,S=2101:2,S 2144 28825:1130141327 1135947375.M99169P19545V000000000000000FI2D87E892_0.mail8,S=27248:2,S 28212 28826:1130141327 1135947442.M929929P20009V000000000000000FI2D87E896_0.mail8,S=1769:2,S 1806 28827:1130141327 1135947463.M939901P20147V000000000000000FI2D87E897_0.mail8,S=1769:2,S 1806 28828:1130141327 1135947880.M537067P9183V0000000000000802I2487E895_0.mail8,S=6320:2,S 6492 28829:1130141327 Please notice that these output is not always the same. We also had mixed Files from two independ files ( mails). Since we use Maildir, each Mail is one File, no mess in the Mailserver is possible. If i dump the Mails to mysql with a wrapper, avoiding any write to disc, this Problem does not exist. I don`t know if this is an Bug, feature or just SuSE`s implementation is crap, but i gues it`s an fs issue or something in the storage part. I started an search for similar Problems, but found only an old bug (202 if i remember correct). If i should start an xfs_repair or any operation which need to unmount the Filesystem we`re getting killed from our customers. The System is handling about 1,2 Million Mails per Day and unmounting the Homes is only possible for 1-3h on sunday night. I work on a new storage and it would be nice to know how to avoid this problem on the new storage. If you need any information, just ask for it. And sorry for the bad english... Greets Michael Ps: Operating System is SuSE-Linux 9.3, since dmesg don`t show the XFS Version: modinfo xfs filename: /lib/modules/2.6.11.4-20a-smp/kernel/fs/xfs/xfs.ko author: Silicon Graphics, Inc. description: SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled license: GPL vermagic: 2.6.11.4-20a-smp SMP 586 REGPARM gcc-3.3 supported: yes depends: exportfs srcversion: 75C138C5A04275B95B29184 From owner-linux-xfs@oss.sgi.com Tue Jan 3 03:43:36 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 03:43:42 -0800 (PST) Received: from iss04.interliant.com (iss04.interliant.com [207.113.241.148]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k03BhZwL003748 for ; Tue, 3 Jan 2006 03:43:35 -0800 Received: from EX-007.mail.navisite.com (ex-007.interliant.com [207.113.240.186]) by iss04.interliant.com (8.10.2/8.10.2) with ESMTP id k03Bglv20323; Tue, 3 Jan 2006 05:42:47 -0600 (CST) Received: from EX-101.mail.navisite.com ([172.16.1.24]) by EX-007.mail.navisite.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Jan 2006 05:39:31 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Kernel Panic 2.6.14.5 with xfs Date: Tue, 3 Jan 2006 05:41:21 -0600 Message-ID: <9560740CA5C0C54BB3853AC9A4164BBB01BD8B4A@EX-101.mail.navisite.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Kernel Panic 2.6.14.5 with xfs thread-index: AcYQL3WMbP40JdXZSyecsVp8MarZuwAKkMTg From: "Jose Thomas" To: "Shailendra Tripathi" Cc: X-OriginalArrivalTime: 03 Jan 2006 11:39:31.0120 (UTC) FILETIME=[5C796B00:01C6105A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k03BhawL003812 X-archive-position: 7073 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: tjose@kasenna.com Precedence: bulk X-list: linux-xfs Content-Length: 2656 Lines: 80 Thankyou Shailendra for the response. With further experiment, I went on to disable to ACPI in the kernel config and rebuild and booted successfully with XFS (without ACPI). Don't know how true it is, but many people are saying that DELL have an error prone ACPI firware and not work well with Linux in many cases. Any comments for discussion. Thanks Jose -----Original Message----- From: Shailendra Tripathi [mailto:stripathi@agami.com] Sent: Tuesday, January 03, 2006 11:58 AM To: Jose Thomas Subject: Re: Kernel Panic 2.6.14.5 with xfs Hi Jose, Your configuration doe not appear to be saved. You are saying that you have selected XFS, however boot messages is clearly showing that the file system type is 0x83. Did you rebuilt the initrd image ? > root (hd0,0) > Filesystem type is ext2fs, partition type 0x83 > kernel /vmlinuz-2.6.14.5 ro root=LABEL=/ rhgb quit bigphysarea=102623 > elevator=deadline -shailendra Jose Thomas wrote: > Greetings, > > With a vanilla kernel (2.6.14.5), I checked XFS and rebuild the > kernel; by following standard procedure; Make menuconfig Make bzImage > Make modules Make modules_install Make install. > > All went on with out throwing any errors. > Then I rebooted the system, but a kernel panic is occuring The > following are the message from the console; > > ========================================================== > Booting 'Red hat Enterprise Linux AS 92.6.14.5)' > > root (hd0,0) > Filesystem type is ext2fs, partition type 0x83 kernel > /vmlinuz-2.6.14.5 ro root=LABEL=/ rhgb quit bigphysarea=102623 > elevator=deadline [Linux-bzImage, setup=0x1e00, size=ox1d7b0d] initrd > /initrd-2.6.14.5.img [Linux-initrd @ 0x37f70000, 0x7f521 bytes] > > Uncompressing Linux... Ok, booting the kernel. > ibm_acpi:ec object not found > ide0: I/O resource 0x1F0-0x1F7 not free. > ide0: ports already in use, skipping probe Red Hat nash version > 4.2.1.3 starting > mkrootdev: lable / not found > mount: error 2 mounting ext3 > mount: error 2 mounting none > switchroot: mount failed: 22 > umount /initrd/dev/ failed: 2 > Kernel panic - not syncing: Attempted to kill init! > ============================================================= > > Kindly let me know any body encounter similar kind of problems or any > suggestive solutions? Any experimental attempt is also welcome. > > The system is a Dell OPTILEX GX520. > OS used to build was RHEL 4. > > Thanks in advance > Jose > > ============================================ > Jose Thomas > tjose@kasenna.com > http://www.kasenna.com/ > 91-80-51391632(Office),91-98451-87820 (cell) > ============================================ > > From owner-linux-xfs@oss.sgi.com Tue Jan 3 08:36:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 08:36:06 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k03Ga4wL009089 for ; Tue, 3 Jan 2006 08:36:04 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k03Iev8j020447 for ; Tue, 3 Jan 2006 10:40:57 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k03GVFQT28449686; Tue, 3 Jan 2006 10:31:16 -0600 (CST) Message-ID: <43BAA6D3.8080604@sgi.com> Date: Tue, 03 Jan 2006 10:31:15 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: murrah boswell CC: linux-xfs@oss.sgi.com Subject: Re: linux_xfs and spam problems References: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> <001901c6102d$096ae150$fe01a8c0@sirak> In-Reply-To: <001901c6102d$096ae150$fe01a8c0@sirak> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7089 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 894 Lines: 31 murrah boswell wrote: > >>Does anyone know who is the administrator for this mailing list. >> >>I am getting a TON of SPAM comming through linux-xfs. > > > same here! not much response from technical xfs related questions (actually > a goose egg), No need for hyperbole... > but spam-a-lot. There were some problems with the machine hosting the list over last week, and people were off on vacation, so it didn't get immediate attention. While we've resisted closing the list to non-subscribers in the past, we're talking about revisiting that decision. It's just too hard to keep up with the spammers. > in the process of converting all systems to ext3, so will be rid of both > soon. You may find that you've got a new set of problems ;-) Nothing against ext3, but every filesystem will probably have it's own set of idiosyncracies to deal with. -Eric > murrah boswell > From owner-linux-xfs@oss.sgi.com Tue Jan 3 14:14:09 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 14:14:11 -0800 (PST) Received: from 163.com (bj44-206.i.netease.com [202.108.44.206]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k03ME6m2030426 for ; Tue, 3 Jan 2006 14:14:08 -0800 Received: from bit-4885f3a87d3 (unknown [211.68.8.22]) by smtp3 (Coremail) with SMTP id HwDvA__gukMSlq8D.23980S4; Wed, 04 Jan 2006 04:39:32 +0800 (CST) Date: Wed, 4 Jan 2006 05:01:18 +0800 From: "=?gb2312?B?0OzT8A==?=" To: "linux-xfs" Subject: help with using xfs filesystem X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Message-Id: <43BAF646.11992D.10775> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id k03ME9m2030429 X-archive-position: 7099 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: bitgreen@163.com Precedence: bulk X-list: linux-xfs Content-Length: 591 Lines: 13 Dear Sir, or Lady, I am sorry to disturb you. My operating system is Red Hat Linux 9. And the Linux kernel is kernel-2.4.20-8smp. I am trying to use xfs filesystem. I have downloaded the "kernel-smp-2.4.20-20.9.XFS1.3.1.i686.rpm" and "xfsprogs-2.5.6.src.tar.gz" packages. Can you do me the favor to tell me what and how I shall do, since I am pretty new user of linux operating system? Your kind help are appreciated! 　　Best wishes　　　　 　　　　　　　yours sincerely Clark 　　　　　　　　bitgreen@163.com 　　　　　　　　　　2006-01-04 From owner-linux-xfs@oss.sgi.com Tue Jan 3 19:04:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 19:05:01 -0800 (PST) Received: from gazelle.npgx.com.au (gazelle.npgx.com.au [203.14.211.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0434wm2014643 for ; Tue, 3 Jan 2006 19:04:59 -0800 Received: from npgx.com.au (localhost.localdomain [127.0.0.1]) by gazelle.npgx.com.au (8.12.10/8.12.10) with ESMTP id k041mn1P002731 for ; Wed, 4 Jan 2006 12:48:49 +1100 From: "Michael Mansour" To: linux-xfs@oss.sgi.com Subject: RHEL4/SL4 XFS stack problem? Date: Wed, 4 Jan 2006 11:48:49 +1000 Message-Id: <20060104014041.M15493@npgx.com.au> X-Mailer: Open WebMail 2.51 20050627 X-OriginatingIP: 161.114.228.150 (mic) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-NPGX-MailScanner-Information: Please contact NPGX for more information X-NPGX-MailScanner: Found to be virus free X-NPGX-MailScanner-From: mic@npgx.com.au X-archive-position: 7101 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mic@npgx.com.au Precedence: bulk X-list: linux-xfs Content-Length: 1184 Lines: 33 Hi, After building a couple of clusters using xfs on the shared storage device (and using md and lvm on top of that), I'm getting this error now which hard crashes my machines: do_IRQ: stack overflow: 284 [] do_IRQ+0x44/0x130 I'm using Scientific Linux 4.2 (RHEL4 Update 2) with a SL Contrib kernel of: kernel-smp-2.6.9-11.EL.XFS which has xfs support. I also use the xfsprogs rpm supplied by Dag Wieers. I run on an x86 platform. After googling quite a bit, it seems that RH have caused an issue with their RHEL4 release by only enabling a 4k stack, where it seems that XFS requires an 8k stack? I'd really like to know how to fix this problem as I just finished months of works building a couple of SL4 clustered environments using XFS, and now with this problem am looking at the unpleasant alternative of getting rid of the XFS filesystems and changing them to ext3, which will take me approximately half a day of work per cluster for the added benefit of a slower filesystem. I just visited the SGI site to see if there's any hints to fixes of this problem there, which is where I got this email address from. Any help is very much appreciated. Michael. From owner-linux-xfs@oss.sgi.com Tue Jan 3 20:55:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 20:55:05 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k044t2m2022725 for ; Tue, 3 Jan 2006 20:55:03 -0800 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k044pExT027230 for ; Tue, 3 Jan 2006 22:51:14 -0600 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k046xx1t000572 for ; Tue, 3 Jan 2006 22:59:59 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k044pDDN23062270; Tue, 3 Jan 2006 22:51:13 -0600 (CST) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k044pCP81384316; Tue, 3 Jan 2006 22:51:13 -0600 (CST) Date: Tue, 3 Jan 2006 22:51:12 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@penguin.americas.sgi.com To: =?gb2312?B?0OzT8A==?= cc: linux-xfs Subject: Re: help with using xfs filesystem In-Reply-To: <43BAF646.11992D.10775> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-archive-position: 7103 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 923 Lines: 26 On Wed, 4 Jan 2006, [gb2312] 俾嚼 wrote: > Dear Sir, or Lady, > > I am sorry to disturb you. > My operating system is Red Hat Linux 9. And the Linux kernel is kernel-2.4.20-8smp. I am trying to use xfs filesystem. I have downloaded the "kernel-smp-2.4.20-20.9.XFS1.3.1.i686.rpm" and "xfsprogs-2.5.6.src.tar.gz" packages. Can you do me the favor to tell me what and how I shall do, since I am pretty new user of linux operating system? > Your kind help are appreciated! Boot the kernel, untar & build xfsprogs, mkfs.xfs /dev/foo & mount it. More basic help than that is beyond the scope of the mailing list; a good book on the Linux OS might help. But I'd suggest starting with a more recent, supported operating system. -Eric > 　　Best wishes　　　　 > > 　　　　　　　yours sincerely > Clark > 　　　　　　　　bitgreen@163.com > 　　　　　　　　　　2006-01-04 > > From owner-linux-xfs@oss.sgi.com Tue Jan 3 20:52:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 20:52:18 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k044qGm2022488 for ; Tue, 3 Jan 2006 20:52:17 -0800 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k044mSxT026567 for ; Tue, 3 Jan 2006 22:48:28 -0600 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k046vB1K032382 for ; Tue, 3 Jan 2006 22:57:11 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k044mPDN23055003; Tue, 3 Jan 2006 22:48:25 -0600 (CST) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k044mOP81384601; Tue, 3 Jan 2006 22:48:24 -0600 (CST) Date: Tue, 3 Jan 2006 22:48:24 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@penguin.americas.sgi.com To: Michael Mansour cc: linux-xfs@oss.sgi.com Subject: Re: RHEL4/SL4 XFS stack problem? In-Reply-To: <20060104014041.M15493@npgx.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7102 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1584 Lines: 46 On Wed, 4 Jan 2006, Michael Mansour wrote: > Hi, > > After building a couple of clusters using xfs on the shared storage device > (and using md and lvm on top of that), I'm getting this error now which hard > crashes my machines: > > do_IRQ: stack overflow: 284 > [] do_IRQ+0x44/0x130 The rest of the message would be most interesting, to see what your stack actually looks like. Recent xfs is reasonable on 4k stacks and there are a few things in the works to make it better. But depending on what you stack up in your IO path you could probably still blow it. -Eric > I'm using Scientific Linux 4.2 (RHEL4 Update 2) with a SL Contrib kernel of: > > kernel-smp-2.6.9-11.EL.XFS > > which has xfs support. I also use the xfsprogs rpm supplied by Dag Wieers. I > run on an x86 platform. > > After googling quite a bit, it seems that RH have caused an issue with their > RHEL4 release by only enabling a 4k stack, where it seems that XFS requires an > 8k stack? > > I'd really like to know how to fix this problem as I just finished months of > works building a couple of SL4 clustered environments using XFS, and now with > this problem am looking at the unpleasant alternative of getting rid of the > XFS filesystems and changing them to ext3, which will take me approximately > half a day of work per cluster for the added benefit of a slower filesystem. > > I just visited the SGI site to see if there's any hints to fixes of this > problem there, which is where I got this email address from. > > Any help is very much appreciated. > > Michael. > > From owner-linux-xfs@oss.sgi.com Tue Jan 3 21:03:14 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 21:03:19 -0800 (PST) Received: from gazelle.npgx.com.au (gazelle.npgx.com.au [203.14.211.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0453Dm2023614 for ; Tue, 3 Jan 2006 21:03:14 -0800 Received: from npgx.com.au (localhost.localdomain [127.0.0.1]) by gazelle.npgx.com.au (8.12.10/8.12.10) with ESMTP id k044xG1P022580; Wed, 4 Jan 2006 15:59:16 +1100 From: "Michael Mansour" To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: RHEL4/SL4 XFS stack problem? Date: Wed, 4 Jan 2006 14:59:16 +1000 Message-Id: <20060104045336.M58734@npgx.com.au> In-Reply-To: References: <20060104014041.M15493@npgx.com.au> X-Mailer: Open WebMail 2.51 20050627 X-OriginatingIP: 161.114.228.150 (mic) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-NPGX-MailScanner-Information: Please contact NPGX for more information X-NPGX-MailScanner: Found to be virus free X-NPGX-MailScanner-From: mic@npgx.com.au X-archive-position: 7104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mic@npgx.com.au Precedence: bulk X-list: linux-xfs Content-Length: 2232 Lines: 66 Hi Eric, > > After building a couple of clusters using xfs on the shared storage device > > (and using md and lvm on top of that), I'm getting this error now which hard > > crashes my machines: > > > > do_IRQ: stack overflow: 284 > > [] do_IRQ+0x44/0x130 > > The rest of the message would be most interesting, to see what your > stack actually looks like. What I've shown above is the only bit I can see on the console, can't use the keyboard or anything at that point and I have to physically powercycle the server. > Recent xfs is reasonable on 4k stacks and there are a few things in > the works to make it better. But depending on what you stack up in > your IO path you could probably still blow it. Hmm... ok, my stack is: md for IDE disk mirrors lvm for LV support drbd for the shared storage xfs formatted the filesystem I run the linuxha.net HA software which uses drbd for network-linked shared storage. Do you think all that stacking is the problem? would the previous email stating that I can build from kernel.org using RH config file but changing to 8k stack make this work? Thanks. Michael. > -Eric > > > I'm using Scientific Linux 4.2 (RHEL4 Update 2) with a SL Contrib kernel of: > > > > kernel-smp-2.6.9-11.EL.XFS > > > > which has xfs support. I also use the xfsprogs rpm supplied by Dag Wieers. I > > run on an x86 platform. > > > > After googling quite a bit, it seems that RH have caused an issue with their > > RHEL4 release by only enabling a 4k stack, where it seems that XFS requires an > > 8k stack? > > > > I'd really like to know how to fix this problem as I just finished months of > > works building a couple of SL4 clustered environments using XFS, and now with > > this problem am looking at the unpleasant alternative of getting rid of the > > XFS filesystems and changing them to ext3, which will take me approximately > > half a day of work per cluster for the added benefit of a slower filesystem. > > > > I just visited the SGI site to see if there's any hints to fixes of this > > problem there, which is where I got this email address from. > > > > Any help is very much appreciated. > > > > Michael. > > > > ------- End of Original Message ------- From owner-linux-xfs@oss.sgi.com Tue Jan 3 21:10:29 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 03 Jan 2006 21:10:30 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k045ASm2024245 for ; Tue, 3 Jan 2006 21:10:28 -0800 Received: from omx2.sgi.com ([198.149.32.25]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k0456exT030621 for ; Tue, 3 Jan 2006 23:06:40 -0600 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k047FP9d004156 for ; Tue, 3 Jan 2006 23:15:25 -0800 Received: from poppy-e236.americas.sgi.com (poppy-e236.americas.sgi.com [128.162.236.207]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k0456dDN23061336; Tue, 3 Jan 2006 23:06:39 -0600 (CST) Received: from penguin.americas.sgi.com (penguin.americas.sgi.com [128.162.240.135]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k0456cP81383102; Tue, 3 Jan 2006 23:06:38 -0600 (CST) Date: Tue, 3 Jan 2006 23:06:38 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@penguin.americas.sgi.com To: Michael Mansour cc: linux-xfs@oss.sgi.com Subject: Re: RHEL4/SL4 XFS stack problem? In-Reply-To: <20060104045336.M58734@npgx.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 2828 Lines: 82 On Wed, 4 Jan 2006, Michael Mansour wrote: > Hi Eric, > > > > After building a couple of clusters using xfs on the shared storage device > > > (and using md and lvm on top of that), I'm getting this error now which hard > > > crashes my machines: > > > > > > do_IRQ: stack overflow: 284 > > > [] do_IRQ+0x44/0x130 > > > > The rest of the message would be most interesting, to see what your > > stack actually looks like. > > What I've shown above is the only bit I can see on the console, can't use the > keyboard or anything at that point and I have to physically powercycle the server. Hm, hard to say then. > > Recent xfs is reasonable on 4k stacks and there are a few things in > > the works to make it better. But depending on what you stack up in > > your IO path you could probably still blow it. > > Hmm... ok, my stack is: > > md for IDE disk mirrors > lvm for LV support > drbd for the shared storage > xfs formatted the filesystem hm, yes, that's pretty optimistic :) Just for kicks you could run http://oss.sgi.com/~sandeen/stackcheck-i386 against each of those modules & see if any large stack users show up that might matter. > I run the linuxha.net HA software which uses drbd for network-linked shared > storage. > > Do you think all that stacking is the problem? would the previous email > stating that I can build from kernel.org using RH config file but changing to > 8k stack make this work? It might. There are some arguments that because 8k stacks must share with IRQ stacks, you're just as likely to have problems, but it seems that usually 8k stacks are a bit more forgiving... -Eric > Thanks. > > Michael. > > > -Eric > > > > > I'm using Scientific Linux 4.2 (RHEL4 Update 2) with a SL Contrib kernel of: > > > > > > kernel-smp-2.6.9-11.EL.XFS > > > > > > which has xfs support. I also use the xfsprogs rpm supplied by Dag Wieers. I > > > run on an x86 platform. > > > > > > After googling quite a bit, it seems that RH have caused an issue with their > > > RHEL4 release by only enabling a 4k stack, where it seems that XFS requires an > > > 8k stack? > > > > > > I'd really like to know how to fix this problem as I just finished months of > > > works building a couple of SL4 clustered environments using XFS, and now with > > > this problem am looking at the unpleasant alternative of getting rid of the > > > XFS filesystems and changing them to ext3, which will take me approximately > > > half a day of work per cluster for the added benefit of a slower filesystem. > > > > > > I just visited the SGI site to see if there's any hints to fixes of this > > > problem there, which is where I got this email address from. > > > > > > Any help is very much appreciated. > > > > > > Michael. > > > > > > > ------- End of Original Message ------- > From owner-linux-xfs@oss.sgi.com Wed Jan 4 02:07:27 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 04 Jan 2006 02:07:32 -0800 (PST) Received: from gazelle.npgx.com.au (gazelle.npgx.com.au [203.14.211.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k04A7Pm2008237 for ; Wed, 4 Jan 2006 02:07:26 -0800 Received: from npgx.com.au (localhost.localdomain [127.0.0.1]) by gazelle.npgx.com.au (8.12.10/8.12.10) with ESMTP id k04A3J1P021514; Wed, 4 Jan 2006 21:03:19 +1100 From: "Michael Mansour" To: Eric Sandeen Cc: linux-xfs@oss.sgi.com Subject: Re: RHEL4/SL4 XFS stack problem? Date: Wed, 4 Jan 2006 20:03:19 +1000 Message-Id: <20060104095516.M31708@npgx.com.au> In-Reply-To: References: <20060104045336.M58734@npgx.com.au> X-Mailer: Open WebMail 2.51 20050627 X-OriginatingIP: 203.14.211.3 (mic) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-NPGX-MailScanner-Information: Please contact NPGX for more information X-NPGX-MailScanner: Found to be virus free X-NPGX-MailScanner-From: mic@npgx.com.au X-archive-position: 7107 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: mic@npgx.com.au Precedence: bulk X-list: linux-xfs Content-Length: 4809 Lines: 157 Hi Eric, > > Hi Eric, > > > > > > After building a couple of clusters using xfs on the shared storage device > > > > (and using md and lvm on top of that), I'm getting this error now which hard > > > > crashes my machines: > > > > > > > > do_IRQ: stack overflow: 284 > > > > [] do_IRQ+0x44/0x130 > > > > > > The rest of the message would be most interesting, to see what your > > > stack actually looks like. > > > > What I've shown above is the only bit I can see on the console, can't use the > > keyboard or anything at that point and I have to physically powercycle the server. > > Hm, hard to say then. > > > > Recent xfs is reasonable on 4k stacks and there are a few things in > > > the works to make it better. But depending on what you stack up in > > > your IO path you could probably still blow it. > > > > Hmm... ok, my stack is: > > > > md for IDE disk mirrors > > lvm for LV support > > drbd for the shared storage > > xfs formatted the filesystem > > hm, yes, that's pretty optimistic :) > > Just for kicks you could run http://oss.sgi.com/~sandeen/stackcheck- > i386 against each of those modules & see if any large stack users > show up that might matter. # stackcheck /lib/modules/2.6.9-11.EL.XFSsmp/kernel/drivers/block/drbd.ko 144 drbd_ioctl_set_net 1c0 drbd_ioctl_get_conf # stackcheck /lib/modules/2.6.9-11.EL.XFSsmp/kernel/fs/xfs/xfs.ko 124 linvfs_mknod 134 xfs_bmapi 134 xfs_swapext 158 xfs_trans_init # stackcheck /lib/modules/2.6.9-11.EL.XFSsmp/kernel/fs/jbd/jbd.ko 114 log_do_checkpoint 168 journal_commit_transaction # stackcheck /lib/modules/2.6.9-11.EL.XFSsmp/kernel/fs/lockd/lockd.ko 120 nlm4svc_proc_cancel_msg 120 nlm4svc_proc_granted_msg 120 nlm4svc_proc_lock_msg 120 nlm4svc_proc_test_msg 120 nlm4svc_proc_unlock_msg 120 nlmsvc_proc_cancel_msg 120 nlmsvc_proc_granted_msg 120 nlmsvc_proc_lock_msg 120 nlmsvc_proc_test_msg 120 nlmsvc_proc_unlock_msg 2a0 nlmclnt_reclaim 2b0 nlmclnt_proc # stackcheck /lib/modules/2.6.9-11.EL.XFSsmp/kernel/fs/nfs/nfs.ko 118 encode_attrs 128 nfs_lookup 130 nfs_lookup_revalidate 14c nfs3_proc_link 158 nfs_proc_create 160 nfs_mkdir 160 nfs_mknod 168 _nfs4_open_delegation_recall 16c nfs3_proc_rename 170 _nfs4_open_reclaim 170 nfs_symlink 19c nfs_readdir 208 _nfs4_do_open 22c nfs3_proc_create Dynamic 00001794 nfs_sillyrename 17c0: 29 cc sub %ecx,%esp All that doesn't really mean much to me :) > > I run the linuxha.net HA software which uses drbd for network-linked shared > > storage. > > > > Do you think all that stacking is the problem? would the previous email > > stating that I can build from kernel.org using RH config file but changing to > > 8k stack make this work? > > It might. There are some arguments that because 8k stacks must > share with IRQ stacks, you're just as likely to have problems, but > it seems that usually 8k stacks are a bit more forgiving... I thought long and hard about this Eric, and although I like XFS alot and do wish to use it, I've relunctantly decided to migrate those XFS filesystems to ext3. Being these are production clusters built on SL42 (RHEL4 Update 2), I really do need them to be supported by vendor releases without too much tinkering from my end. Because of this though, I feel compelled after more than 12 years with RH, to checkout SUSE the next time I'm building servers. Out of the box they seem to support all the good stuff (php5, XFS, etc) where RH seems to lag behind. Thanks for your help. Michael. > -Eric > > > Thanks. > > > > Michael. > > > > > -Eric > > > > > > > I'm using Scientific Linux 4.2 (RHEL4 Update 2) with a SL Contrib kernel of: > > > > > > > > kernel-smp-2.6.9-11.EL.XFS > > > > > > > > which has xfs support. I also use the xfsprogs rpm supplied by Dag Wieers. I > > > > run on an x86 platform. > > > > > > > > After googling quite a bit, it seems that RH have caused an issue with their > > > > RHEL4 release by only enabling a 4k stack, where it seems that XFS requires an > > > > 8k stack? > > > > > > > > I'd really like to know how to fix this problem as I just finished months of > > > > works building a couple of SL4 clustered environments using XFS, and now with > > > > this problem am looking at the unpleasant alternative of getting rid of the > > > > XFS filesystems and changing them to ext3, which will take me approximately > > > > half a day of work per cluster for the added benefit of a slower filesystem. > > > > > > > > I just visited the SGI site to see if there's any hints to fixes of this > > > > problem there, which is where I got this email address from. > > > > > > > > Any help is very much appreciated. > > > > > > > > Michael. > > > > > > > > > > ------- End of Original Message ------- > > ------- End of Original Message ------- From owner-linux-xfs@oss.sgi.com Fri Jan 6 00:19:23 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Jan 2006 00:19:28 -0800 (PST) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k068JNm2031084 for ; Fri, 6 Jan 2006 00:19:23 -0800 Received: by zproxy.gmail.com with SMTP id x7so3208879nzc for ; Fri, 06 Jan 2006 00:15:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=OBGWNIB0APfN07xv1lKffzNLXOeyQpoSMSMe3U3U8HDf2g8CA3wnPzKB88LqUpDevjb2C1OhSfijhXZo6aeAU55K4oBcZQmj77l3MvI52FjD0dDRblqSiVxm3aSwo97UfQ5JVVuS5KWkyDkvW3KCNvrYJlkeYRCuqe3UcV34AT0= Received: by 10.65.249.15 with SMTP id b15mr1810152qbs; Thu, 05 Jan 2006 22:33:03 -0800 (PST) Received: by 10.65.250.12 with HTTP; Thu, 5 Jan 2006 22:33:03 -0800 (PST) Message-ID: <57b14b4a0601052233o165bf73el@mail.gmail.com> Date: Fri, 6 Jan 2006 14:33:03 +0800 From: cold To: linux-xfs@oss.sgi.com Subject: Have the correct patch to kernel of 2.4.21-EL for ia64 machine? MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: zhaijidong@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 464 Lines: 12 Hello, My system is Itanium64 1.5G, RedHat AS 3.0, kernel is 2.4.21-EL. I wanto know if sgi supply the patch to the kernel for 2.4.21-EL. I have downloaded the patch from the ftp server of SGI. ftp://oss.sgi.com, the patch is linux-2.4.21-core-xfs-1.3.1.patch and linux-xfs-1.3.1.patch. But they can not apply to this kernel. There some errors when I patch that. Can you give some advice? Thank you very much! jidong [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Fri Jan 6 14:05:02 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Jan 2006 14:05:05 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k06M51m2026401 for ; Fri, 6 Jan 2006 14:05:01 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k06M1BxT027181 for ; Fri, 6 Jan 2006 16:01:12 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k06M1BQT28653887 for ; Fri, 6 Jan 2006 16:01:11 -0600 (CST) Resent-From: Eric Sandeen Resent-To: linux-xfs@oss.sgi.com Resent-Date: Fri, 6 Jan 2006 16:01:10 -0600 Resent-Message-Id: <43BEE8A6.2060907@sgi.com> Resent-User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Thunderbird/1.0.6 Fedora/1.0.6-1.1.fc4 Message-ID: <43BEDB55.6020501@sgi.com> Date: Fri, 06 Jan 2006 15:04:21 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cold CC: linux-xfs@oss.sgi.com Subject: Re: Have the correct patch to kernel of 2.4.21-EL for ia64 machine? References: <57b14b4a0601052233o165bf73el@mail.gmail.com> In-Reply-To: <57b14b4a0601052233o165bf73el@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7131 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 769 Lines: 23 cold wrote: > Hello, > My system is Itanium64 1.5G, RedHat AS 3.0, kernel is 2.4.21-EL. I wanto > know if sgi supply the patch to the kernel for 2.4.21-EL. > I have downloaded the patch from the ftp server of SGI. ftp://oss.sgi.com, > the patch is linux-2.4.21-core-xfs-1.3.1.patch and linux-xfs-1.3.1.patch. > But they can not apply to this kernel. There some errors when I patch that. > Can you give some advice? Thank you very much! > jidong > > > [[HTML alternate version deleted]] > You might look at: ftp://oss.sgi.com/projects/xfs/testing/RHEL3/ the kernel src.rpm has some patches in it to support kdb & large block devices, perhaps some other things.. and there are also xfs & dmapi src.rpms which contain the necessary code & patches. -Eric From owner-linux-xfs@oss.sgi.com Fri Jan 6 14:54:48 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 06 Jan 2006 14:54:51 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k06Msmm2028917 for ; Fri, 6 Jan 2006 14:54:48 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k07108Ml012498 for ; Fri, 6 Jan 2006 17:00:08 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k06MnvDN23237882; Fri, 6 Jan 2006 16:49:57 -0600 (CST) Message-ID: <43BEF414.5010407@sgi.com> Date: Fri, 06 Jan 2006 16:49:56 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael Reck [ Netdiscounter GmbH]" CC: linux-xfs@oss.sgi.com Subject: Re: Problem with mixed Files References: <43BA5E9E.6040108@netdiscounter.de> In-Reply-To: <43BA5E9E.6040108@netdiscounter.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 949 Lines: 27 Sorry, somehow this did not make it to my inbox, but I saw it on the web archives... Michael Reck [ Netdiscounter GmbH] wrote: > Hi, > > We are using XFS on an Mailserver. We have a strange Problem which could > be tracked down to Filesystem or Hardware level. > > The Problem: > Some of the stored mails get`s mixxed with various contents of the > Filesystem or other Mails. The Files "look" normal dumped with "od" - no > strange content. This Problem could be reproduced. If we send and > massive amount of Data slighly smaller than Blocksize some of the > generated Files gets mixxed. For starters, what is the blocksize on your filesystem? xfs_info /mount/point will tell you. I would guess that this is stale disk date coming through, but not certain. I've seen something like this but only when block size < page size. But the default block size is 4k, and it also looks like you are running on a 4k page system, correct? -Eric From owner-linux-xfs@oss.sgi.com Sat Jan 7 07:51:52 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 07 Jan 2006 07:51:59 -0800 (PST) Received: from calsoftinc.com (calsoftinc.com [64.62.215.98]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k07Fpqm2010100 for ; Sat, 7 Jan 2006 07:51:52 -0800 Received: from 203.199.144.195 ([203.199.144.195]) by calsoftinc.com for ; Sat, 7 Jan 2006 06:37:43 -0800 Date: Sat, 7 Jan 2006 20:03:58 +0530 (IST) From: Alok Kataria X-X-Sender: alokk@pravin.s To: Christoph Hellwig , nathans@sgi.com cc: shai@scalex86.org, kiran@scalex86.org, linux-xfs@oss.sgi.com Subject: Re: XFS mount alignment patch Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7135 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: alokk@calsoftinc.com Precedence: bulk X-list: linux-xfs Content-Length: 6790 Lines: 146 On Fri, 2006-01-06 at 21:48, Christoph Hellwig wrote: > Any chance you could archive the alignment without the use of anonymous > structs? XFS still needs to compile with compilers that don't support > this (non-ANIS C) feature, and it looks quite ugly. > This version doesn't use anonymous structs. Please check if this could be applied. Thanks & Regards, Alok -- This patch seperates out the members of xfs_mount into those showing readmostly behavior and those which don't show any specific behaviour. The readmostly variables are put into seperate internode cacheline to avoid thrashing. Signed-off-by: Alok N Kataria Signed-off-by: Ravikiran Thirumalai Signed-off-by: Shai Fultheim Index: linux-2.6.15/fs/xfs/xfs_mount.h =================================================================== --- linux-2.6.15.orig/fs/xfs/xfs_mount.h 2006-01-07 06:29:11.000000000 -0800 +++ linux-2.6.15/fs/xfs/xfs_mount.h 2006-01-07 06:31:43.000000000 -0800 @@ -267,7 +267,12 @@ typedef struct xfs_ioops { #define XFS_IODONE(vfsp) \ (*(mp)->m_io_ops.xfs_iodone)(vfsp) - +/* + * The varaibles in this structute are seperated into those showing + * read mostly behavior and those which don't show any definite behavior. + * These variabes are put into seperate internode cachelines, to avoid thrashing + * of readmostly variables. + */ typedef struct xfs_mount { bhv_desc_t m_bhv; /* vfs xfs behavior */ xfs_tid_t m_tid; /* next unused tid for fs */ @@ -276,39 +281,13 @@ typedef struct xfs_mount { uint m_ail_gen; /* fs AIL generation count */ xfs_sb_t m_sb; /* copy of fs superblock */ lock_t m_sb_lock; /* sb counter mutex */ - struct xfs_buf *m_sb_bp; /* buffer for superblock */ - char *m_fsname; /* filesystem name */ - int m_fsname_len; /* strlen of fs name */ - char *m_rtname; /* realtime device name */ - char *m_logname; /* external log device name */ - int m_bsize; /* fs logical block size */ xfs_agnumber_t m_agfrotor; /* last ag where space found */ xfs_agnumber_t m_agirotor; /* last ag dir inode alloced */ lock_t m_agirotor_lock;/* .. and lock protecting it */ - xfs_agnumber_t m_maxagi; /* highest inode alloc group */ - uint m_ihsize; /* size of next field */ - struct xfs_ihash *m_ihash; /* fs private inode hash table*/ struct xfs_inode *m_inodes; /* active inode list */ struct list_head m_del_inodes; /* inodes to reclaim */ mutex_t m_ilock; /* inode list mutex */ uint m_ireclaims; /* count of calls to reclaim*/ - uint m_readio_log; /* min read size log bytes */ - uint m_readio_blocks; /* min read size blocks */ - uint m_writeio_log; /* min write size log bytes */ - uint m_writeio_blocks; /* min write size blocks */ - struct log *m_log; /* log specific stuff */ - int m_logbufs; /* number of log buffers */ - int m_logbsize; /* size of each log buffer */ - uint m_rsumlevels; /* rt summary levels */ - uint m_rsumsize; /* size of rt summary, bytes */ - struct xfs_inode *m_rbmip; /* pointer to bitmap inode */ - struct xfs_inode *m_rsumip; /* pointer to summary inode */ - struct xfs_inode *m_rootip; /* pointer to root directory */ - struct xfs_quotainfo *m_quotainfo; /* disk quota information */ - xfs_buftarg_t *m_ddev_targp; /* saves taking the address */ - xfs_buftarg_t *m_logdev_targp;/* ptr to log device */ - xfs_buftarg_t *m_rtdev_targp; /* ptr to rt device */ -#define m_dev m_ddev_targp->pbr_dev __uint8_t m_dircook_elog; /* log d-cookie entry bits */ __uint8_t m_blkbit_log; /* blocklog + NBBY */ __uint8_t m_blkbb_log; /* blocklog - BBSHIFT */ @@ -331,14 +310,45 @@ typedef struct xfs_mount { struct xfs_perag *m_perag; /* per-ag accounting info */ struct rw_semaphore m_peraglock; /* lock for m_perag (pointer) */ sema_t m_growlock; /* growfs mutex */ - int m_fixedfsid[2]; /* unchanged for life of FS */ uint m_dmevmask; /* DMI events for this FS */ - __uint64_t m_flags; /* global mount flags */ uint m_attroffset; /* inode attribute offset */ uint m_dir_node_ents; /* #entries in a dir danode */ uint m_attr_node_ents; /* #entries in attr danode */ int m_ialloc_inos; /* inodes in inode allocation */ int m_ialloc_blks; /* blocks in inode allocation */ + __uint64_t m_resblks_avail;/* available reserved blocks */ + atomic_t m_active_trans; /* number trans frozen */ + + /* All the variables below this show read-mostly behaviour */ + struct xfs_buf *m_sb_bp ____cacheline_internodealigned_in_smp; + /* buffer for superblock */ + char *m_fsname; /* filesystem name */ + int m_fsname_len; /* strlen of fs name */ + char *m_rtname; /* realtime device name */ + char *m_logname; /* external log device name */ + int m_bsize; /* fs logical block size */ + xfs_agnumber_t m_maxagi; /* highest inode alloc group */ + uint m_ihsize; /* size of next field */ + struct xfs_ihash *m_ihash; /* fs private inode hash table*/ + uint m_readio_log; /* min read size log bytes */ + uint m_readio_blocks; /* min read size blocks */ + uint m_writeio_log; /* min write size log bytes */ + uint m_writeio_blocks; /* min write size blocks */ + struct log *m_log; /* log specific stuff */ + int m_logbufs; /* number of log buffers */ + int m_logbsize; /* size of each log buffer */ + uint m_rsumlevels; /* rt summary levels */ + uint m_rsumsize; /* size of rt summary, bytes */ + struct xfs_inode *m_rbmip; /* pointer to bitmap inode */ + struct xfs_inode *m_rsumip; /* pointer to summary inode */ + struct xfs_inode *m_rootip; /* pointer to root directory */ + struct xfs_quotainfo *m_quotainfo; /* disk quota information */ + xfs_buftarg_t *m_ddev_targp; /* saves taking the address */ + xfs_buftarg_t *m_logdev_targp;/* ptr to log device */ + xfs_buftarg_t *m_rtdev_targp; /* ptr to rt device */ +#define m_dev m_ddev_targp->pbr_dev + int m_fixedfsid[2]; /* unchanged for life of FS */ + __uint64_t m_flags; /* global mount flags */ int m_litino; /* size of inode union area */ int m_inoalign_mask;/* mask sb_inoalignmt if used */ uint m_qflags; /* quota status flags */ @@ -346,7 +356,6 @@ typedef struct xfs_mount { __uint64_t m_maxicount; /* maximum inode count */ __uint64_t m_maxioffset; /* maximum inode offset */ __uint64_t m_resblks; /* total reserved blocks */ - __uint64_t m_resblks_avail;/* available reserved blocks */ #if XFS_BIG_INUMS xfs_ino_t m_inoadd; /* add value for ino64_offset */ #endif @@ -372,7 +381,6 @@ typedef struct xfs_mount { struct xfs_dmops m_dm_ops; /* vector of DMI ops */ struct xfs_qmops m_qm_ops; /* vector of XQM ops */ struct xfs_ioops m_io_ops; /* vector of I/O ops */ - atomic_t m_active_trans; /* number trans frozen */ } xfs_mount_t; /* From owner-linux-xfs@oss.sgi.com Sun Jan 8 14:50:15 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 08 Jan 2006 14:50:26 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k08MoCm2024231 for ; Sun, 8 Jan 2006 14:50:13 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA09247; Mon, 9 Jan 2006 08:35:09 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k08LZ7dM59761502; Mon, 9 Jan 2006 08:35:08 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k08LZ42g59707865; Mon, 9 Jan 2006 08:35:04 +1100 (EST) Date: Mon, 9 Jan 2006 08:35:04 +1100 From: David Chinner To: Alok Kataria Cc: Christoph Hellwig , nathans@sgi.com, shai@scalex86.org, kiran@scalex86.org, linux-xfs@oss.sgi.com Subject: Re: XFS mount alignment patch Message-ID: <20060108213503.GY43335175@melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-archive-position: 7137 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 745 Lines: 25 On Sat, Jan 07, 2006 at 08:03:58PM +0530, Alok Kataria wrote: > On Fri, 2006-01-06 at 21:48, Christoph Hellwig wrote: > > Any chance you could archive the alignment without the use of anonymous > > structs? XFS still needs to compile with compilers that don't support > > this (non-ANIS C) feature, and it looks quite ugly. > > > > This version doesn't use anonymous structs. Please check if this could be > applied. Do you have any benchmark numbers for CPU usage or performance improvement with this patch? I have experimented with this sort of change in the past and seen no measurable benefit when XFS has been CPU bound rather than disk I/O bound. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Mon Jan 9 04:40:38 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 04:40:41 -0800 (PST) Received: from mail.coremedia.com (mail.coremedia.com [217.111.0.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09CeSm2001075 for ; Mon, 9 Jan 2006 04:40:37 -0800 Received: from localhost (localhost [127.0.0.1]) by mail.coremedia.com (Postfix) with ESMTP id B87053660AC for ; Mon, 9 Jan 2006 11:34:20 +0100 (CET) Received: from mail.coremedia.com ([127.0.0.1]) by localhost (masq [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11287-06 for ; Mon, 9 Jan 2006 11:34:19 +0100 (CET) Received: from mars.coremedia.com (smtp.coremedia.com [10.1.2.8]) by mail.coremedia.com (Postfix) with ESMTP id 6983D364E86 for ; Mon, 9 Jan 2006 11:34:19 +0100 (CET) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Problems using xfs on RAID 5 volumes Date: Mon, 9 Jan 2006 11:34:56 +0100 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00C0_01C61510.B769C4A0" Message-ID: <37191A9D3396224A92F6F9306DFB119D0142A7B0@MARS.coremedia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Problems using xfs on RAID 5 volumes Thread-Index: AcYVCFWXpPQJrAdCQ9aZciM4ewrS0A== From: "Horchler, Joerg" To: X-archive-position: 7139 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: joerg.horchler@coremedia.com Precedence: bulk X-list: linux-xfs Content-Length: 17420 Lines: 391 This is a multi-part message in MIME format. ------=_NextPart_000_00C0_01C61510.B769C4A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00C1_01C61510.B769C4A0" ------=_NextPart_001_00C1_01C61510.B769C4A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 we have a big problem using XFS on our fileserver. Our configuration is: We are using a Dell PowerVault as external RAID Array which is configured with two logical volumes. Each logical volume is configured with 7 physical disks. Six disks are configured to form a RAID 5 and the last is configured as hot spare. Our server is a 'SuSE Linux Enterprise Server 9' running with kernel 2.6.5-7.151-smp. xfsprogs of version 2.6.25-0.2 are installed. I don't know which version of XFS is installed with the running kernel.=20 Now our problem: Every time a physical disk fails (and the RAID swaps from state OPTIMAL to DEGRADED) the RAID rebuilds onto the hot spare. During this rebuild we get a lot of XFS errors in our dmesg: 0x0: 66 4e 1f 21 5d 98 0e d9 23 70 65 00 1f 02 00 7d Filesystem "dm-4": XFS internal error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. Caller 0xf918f522 Call Trace: [] xfs_da_do_buf+0x5ee/0x900 [xfs] [] xfs_da_read_buf+0x42/0x50 [xfs] [] xfs_da_read_buf+0x42/0x50 [xfs] [] ip_append_data+0x5d0/0x770 [] xfs_da_read_buf+0x42/0x50 [xfs] [] xfs_dir2_block_getdents+0x9f/0x2e0 [xfs] [] xfs_dir2_block_getdents+0x9f/0x2e0 [xfs] [] xfs_attr_fetch+0x149/0x170 [xfs] [] in_group_p+0x39/0x80 [] xfs_bmap_last_offset+0x122/0x140 [xfs] [] xfs_dir2_isblock+0x1a/0x70 [xfs] [] xfs_dir2_getdents+0xc9/0x150 [xfs] [] xfs_dir2_put_dirent64_direct+0x0/0xb0 [xfs] [] xfs_dir2_put_dirent64_direct+0x0/0xb0 [xfs] [] xfs_readdir+0x58/0xb0 [xfs] [] linvfs_readdir+0x100/0x206 [xfs] [] linvfs_permission+0xf/0x20 [xfs] [] linvfs_permission+0x0/0x20 [xfs] [] permission+0x5a/0x70 [] nfs3svc_encode_entry_plus+0x0/0x50 [nfsd] [] open_private_file+0x2a/0xf0 [] vfs_readdir+0x95/0xc0 [] nfs3svc_encode_entry_plus+0x0/0x50 [nfsd] [] nfsd_readdir+0xa9/0x100 [nfsd] [] nfsd3_proc_readdirplus+0xdf/0x1f0 [nfsd] [] nfs3svc_encode_entry_plus+0x0/0x50 [nfsd] [] nfs3svc_decode_readdirplusargs+0x0/0x1a0 [nfsd] [] nfsd_dispatch+0x136/0x1e0 [nfsd] [] svc_authenticate+0x4d/0x8d [] svc_process+0x509/0x650 [] common_interrupt+0x18/0x20 [] nfsd+0x1c4/0x369 [nfsd] [] nfsd+0x0/0x369 [nfsd] [] kernel_thread_helper+0x5/0x10 nfsd: non-standard errno: -990 The more curious problem is that during such a rebuild we loose some files on the filesystem. The worst case was that XFS stops the filesystem which produces I/O errors. Then we have to remount and repair the filesystem which produces several GB of data lost.=20 Is XFS (as caching filesystem) a bad idea on top of a RAID 5 system? Does anyone know about such errors? Can we fix this by running a kernel update? Thanks in advance J=F6rg Horchler ------=_NextPart_001_00C1_01C61510.B769C4A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Problems using xfs on RAID 5 volumes

Hi,

we have a big problem using XFS on our f= ileserver. Our configuration is:

We are using a Dell PowerVault as extern= al RAID Array which is configured with two logical volumes. Each logical vo= lume is configured with 7 physical disks. Six disks are configured to form = a RAID 5 and the last is configured as hot spare. Our server is a 'SuSE Lin= ux Enterprise Server 9' running with kernel  2.6.5-7.151-smp. xfsprogs= of version 2.6.25-0.2 are installed. I don't know which version of XFS is = installed with the running kernel.

Now our problem:

Every time a physical disk fails (and th= e RAID swaps from state OPTIMAL to DEGRADED) the RAID rebuilds onto the hot= spare. During this rebuild we get a lot of XFS errors in our dmesg:=

0x0: 66 4e 1f 21 5d 98 0e d9 23 70 65 00= 1f 02 00 7d
Filesystem "dm-4": XFS intern= al error xfs_da_do_buf(2) at line 2273 of file fs/xfs/xfs_da_btree.c. = Caller 0xf918f522
Call Trace:
 [<f918f16e>] xfs_da_do_buf+= 0x5ee/0x900 [xfs]
 [<f918f522>] xfs_da_read_bu= f+0x42/0x50 [xfs]
 [<f918f522>] xfs_da_read_bu= f+0x42/0x50 [xfs]
 [<c02e7ae0>] ip_append_data= +0x5d0/0x770
 [<f918f522>] xfs_da_read_bu= f+0x42/0x50 [xfs]
 [<f919509f>] xfs_dir2_block= _getdents+0x9f/0x2e0 [xfs]
 [<f919509f>] xfs_dir2_block= _getdents+0x9f/0x2e0 [xfs]
 [<f9176fc9>] xfs_attr_fetch= +0x149/0x170 [xfs]
 [<c01375b9>] in_group_p+0x3= 9/0x80
 [<f917bc92>] xfs_bmap_last_= offset+0x122/0x140 [xfs]
 [<f91939ca>] xfs_dir2_isblo= ck+0x1a/0x70 [xfs]
 [<f9193d09>] xfs_dir2_getde= nts+0xc9/0x150 [xfs]
 [<f91936a0>] xfs_dir2_put_d= irent64_direct+0x0/0xb0 [xfs]
 [<f91936a0>] xfs_dir2_put_d= irent64_direct+0x0/0xb0 [xfs]
 [<f91c6958>] xfs_readdir+0x= 58/0xb0 [xfs]
 [<f91cf720>] linvfs_readdir= +0x100/0x206 [xfs]
 [<f91d197f>] linvfs_permiss= ion+0xf/0x20 [xfs]
 [<f91d1970>] linvfs_permiss= ion+0x0/0x20 [xfs]
 [<c0180e8a>] permission+0x5= a/0x70
 [<f9375bf0>] nfs3svc_encode= _entry_plus+0x0/0x50 [nfsd]
 [<c0172b4a>] open_private_f= ile+0x2a/0xf0
 [<c0186755>] vfs_readdir+0x= 95/0xc0
 [<f9375bf0>] nfs3svc_encode= _entry_plus+0x0/0x50 [nfsd]
 [<f936be19>] nfsd_readdir+0= xa9/0x100 [nfsd]
 [<f9372c4f>] nfsd3_proc_rea= ddirplus+0xdf/0x1f0 [nfsd]
 [<f9375bf0>] nfs3svc_encode= _entry_plus+0x0/0x50 [nfsd]
 [<f9375ef0>] nfs3svc_decode= _readdirplusargs+0x0/0x1a0 [nfsd]
 [<f9367156>] nfsd_dispatch+= 0x136/0x1e0 [nfsd]
 [<c033242d>] svc_authentica= te+0x4d/0x8d
 [<c032ee69>] svc_process+0x= 509/0x650
 [<c010a158>] common_interru= pt+0x18/0x20
 [<f9367624>] nfsd+0x1c4/0x3= 69 [nfsd]
 [<f9367460>] nfsd+0x0/0x369= [nfsd]
 [<c0107005>] kernel_thread_= helper+0x5/0x10

nfsd: non-standard errno: -990

The more curious problem is that during = such a rebuild we loose some files on the filesystem. The worst case was th= at XFS stops the filesystem which produces I/O errors. Then we have to remo= unt and repair the filesystem which produces several GB of data lost.

Is XFS (as caching filesystem) a bad ide= a on top of a RAID 5 system? Does anyone know about such errors? Can we fix= this by running a kernel update?

Thanks in advance
J=F6rg Horchler

------=_NextPart_001_00C1_01C61510.B769C4A0-- ------=_NextPart_000_00C0_01C61510.B769C4A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH AQAAoIITDTCCBVswggNDoAMCAQICEBLkZ1FQgeWWR0z4WOAjNgEwDQYJKoZI hvcNAQEFBQAwQDELMAkGA1UEBhMCREUxFTATBgNVBAoTDENvcmVNZWRpYSBB RzEaMBgGA1UEAxMRQ29yZU1lZGlhIFJvb3QgQ0EwHhcNMDUwOTE5MDkzMDI2 WhcNMTUwOTE5MDkzOTU5WjBAMQswCQYDVQQGEwJERTEVMBMGA1UEChMMQ29y ZU1lZGlhIEFHMRowGAYDVQQDExFDb3JlTWVkaWEgUm9vdCBDQTCCAiIwDQYJ KoZIhvcNAQEBBQADggIPADCCAgoCggIBALQUsCRinh6WUJxiaujTXbDdKTCC aY2L7AHJsEviZiazD6twy7j3p1uVM9B4ZHIon6W3IJlcFOfOc81zTsKvJROm 2ABZv6luclhROtUI+4fG47mmXmbPTeK/Vavnu7hfLmPlNpF2lUqZVFf5GBy+ yhmMCUkTaA5Yuwm7PSB7FJzXhiDC+Tm42sRbBmkQzGUYkXeCnZ/XYxd4TKlm h5bOec1eaHI958xO5ByspnRMMZSqUuGvYaoovIdpN+A3X8u02TBQggUT4J5G Y8Pyk1/Y4wknX3YVdRiULuOYdFQQKQvM90ok+pPsAwVA7XNuqq/3lphBPplo tZyX9ivO9NNeGy94vlqs8uUPEoVoXOqdMffBnGvsAGeyVPizSqrRPVesU2BU WtDHJmKsjBmd8XeCCUCZjpP71WJnUEzVkFcc+MxmM0hcn13PSD2iRXKvmhMg 2ZSQQxQbsFnoz8S0IHM3Z7DqOgcbuRalYYb73OU6ZHxs/s8yHHeKWF7/Tw09 Nj8nC+I0Y91Vg/6o156ZC2x8wWkX9B3psL38yszhpro0ASvWEvNsDy8QPm4U 5jfbsadmqlz8qZZDumHe6TQu0KYZKNA5zIPKOJ/KqZTumZxqzt2HYkucYUj3 jJ4whyt2Tt9jYkpK2s5D6BDcU48NeEC28tXxDXkjGhuPYaJrB00QshCXAgMB AAGjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQW BBT6dCvUg+SukWIUtjL5FUYROmARiTAQBgkrBgEEAYI3FQEEAwIBADANBgkq hkiG9w0BAQUFAAOCAgEAr3wywwFqzqS9K7BSDbOQZm7CWd9IOHgAwYCkIR98 FAfjCGBDpYpVz8PuiLDMIa3dtwhnBjpahBhkBk1OqXD+BkwU26Bk+QuENyw7 ebY/qQFCbZAYvK8Jf8t7v93AL+0/A5zz/HQRoR86DDHVBrMWg05GxHiwTdwh sUr0qbtFsFTTHPlOgb5XQSdCgGlENPujeAlcJXkNj3zMiGjMsOL97BRx8+Q8 RE3tnLMrYcAUzKA0wUPFHNzlg4GODQ28Ym9NMTETIuHYOXHbnyXv8P8HZDpf Bnk8j+qMK1i/EDgARcF/P+fsb9Odr4zzZZKhRzFtNC4fHqN2gTXAeCZz5txG L5rLjuPXvDy3kVKKv1wuNpxKhBhIxMXKlDGTrdeBD+c6vY7uyZVy04OVCvne 3sRjrqJC1dlxZBoTu1lIU1RtVeck24zOyT8ge2fSKYZamrOPbgx55Evr5iM8 9QssgwSSr7rq+1RZymwjoizlA/5WgDLW4gs0uCgzHp+P3soxNrTO5KKSlrxY lkARh/fRmMFLA86Gj2fk94YGPduQFJaBpKdV8WMvl5zsatsdn2/OP0+03cBh xwjM2qAjEsfPPFGo2x/lDkmtHoszoXqW206Rxu9hE8So2aDp1vXhBC0xy6ja 77/pW6NwKS6FS+YSP3MzN6Dr319GpjL6XrjNyX2FzIgwggazMIIFm6ADAgEC AgobGzKCAAAAAABhMA0GCSqGSIb3DQEBBQUAMG8xCzAJBgNVBAYTAkRFMRMw EQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJY29yZW1lZGlh MRUwEwYDVQQKDAxDb3JlTWVkaWEgQUcxGTAXBgNVBAMMEENvcmVNZWRpYSBT dWIgQ0EwHhcNMDUwOTIwMTI0NzIyWhcNMDYwOTIwMTI0NzIyWjCBlDETMBEG CgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkWCWNvcmVtZWRpYTEO MAwGA1UECwwFU3RhZmYxCzAJBgNVBAsMAklTMRgwFgYDVQQDDA9Ib3JjaGxl ciwgSm9lcmcxKzApBgkqhkiG9w0BCQEWHGpvZXJnLmhvcmNobGVyQGNvcmVt ZWRpYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOVGwC5cTQ+M s7V+CJfwi6IYlIysXom/34DfnSjvz1Rp/LWIxiRY3oieXo2kuGi1eBzTAoFp TfNhisS17NWlttbn4ER4FhM2fKsMRINxbi0YksbpX1WtLGiv7F/8qWFg+6bI w1OVj8h4jBinyuEIG1RTjoc7e5TA2+VIlPhfIOyVAgMBAAGjggOtMIIDqTAL BgNVHQ8EBAMCBaAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODAN BggqhkiG9w0DBAIBODAHBgUrDgMCBzAdBgNVHQ4EFgQUxt+Go99FIkM3QdXu leQWCAJHX7owPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIzZQKgqPMYoGF kTmF6Nxoho7sflyE1ogXgcXKWQIBZAIBAzAfBgNVHSMEGDAWgBQ494WfpaGr 0GYIimx88L89FnuWfTCCAQoGA1UdHwSCAQEwgf4wgfuggfiggfWGgbtsZGFw Oi8vL0NOPUNvcmVNZWRpYSUyMFN1YiUyMENBLENOPXBsdXRvLENOPUNEUCxD Tj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25m aWd1cmF0aW9uLERDPWNvcmVtZWRpYSxEQz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBv aW50hjVodHRwOi8vd3d3LmNvcmVtZWRpYS5jb20vcGtpL0NvcmVNZWRpYSUy MFN1YiUyMENBLmNybDCCASEGCCsGAQUFBwEBBIIBEzCCAQ8wgbUGCCsGAQUF BzAChoGobGRhcDovLy9DTj1Db3JlTWVkaWElMjBTdWIlMjBDQSxDTj1BSUEs Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29u ZmlndXJhdGlvbixEQz1jb3JlbWVkaWEsREM9Y29tP2NBQ2VydGlmaWNhdGU/ YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MFUGCCsG AQUFBzAChklodHRwOi8vd3d3LmNvcmVtZWRpYS5jb20vcGtpL3BsdXRvLmNv cmVtZWRpYS5jb21fQ29yZU1lZGlhJTIwU3ViJTIwQ0EuY3J0MCkGA1UdJQQi MCAGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNwoDBDA1BgkrBgEEAYI3 FQoEKDAmMAoGCCsGAQUFBwMCMAoGCCsGAQUFBwMEMAwGCisGAQQBgjcKAwQw TwYDVR0RBEgwRqAmBgorBgEEAYI3FAIDoBgMFmpob3JjaGxlQGNvcmVtZWRp YS5jb22BHGpvZXJnLmhvcmNobGVyQGNvcmVtZWRpYS5jb20wDQYJKoZIhvcN AQEFBQADggEBAAxpVAfNql7xFBbluYsTU945ktroUG0rb/tFz13N4bdf3iwd CLOlKHrag/4G+vEnepNn7/yhe7C5nFiahonhfLjCd3w9+vnm7i9AUbYvAi6M utTEJRlnTLiCm2DvPGGx2GkPzxPbixjF5vG41GhyqYnFJuj/hxEw3QnoDjyP /FY9X9LgTzqtQOtCRzDAPu27nRKceTrousmuPIAjJqGZ3fseL3YPO/AWTL6O VY8HfBDNany8ROv20tUJVfwxhEeerYjsifDnPS3TAhEHdozXzyQrtqWP3rTd EnJ4hOVIkV3fDmhRxSjWJBz0HW87veI7MuzrqUPUZIhKWJiQUKRGTVUwggbz MIIE26ADAgECAgphWjbJAAAAAAADMA0GCSqGSIb3DQEBBQUAMEAxCzAJBgNV BAYTAkRFMRUwEwYDVQQKEwxDb3JlTWVkaWEgQUcxGjAYBgNVBAMTEUNvcmVN ZWRpYSBSb290IENBMB4XDTA1MDkxOTEwNDMyN1oXDTEwMDkxOTEwNTMyN1ow bzELMAkGA1UEBhMCREUxEzARBgoJkiaJk/IsZAEZFgNjb20xGTAXBgoJkiaJ k/IsZAEZFgljb3JlbWVkaWExFTATBgNVBAoMDENvcmVNZWRpYSBBRzEZMBcG A1UEAwwQQ29yZU1lZGlhIFN1YiBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMRQd5D+HRxXvIBifUa4B0O5P2lVNtE3+TTRJAnn/mrri5zF LJ254Ek9k1QUnTPlBXfGomnPZ4Eki6xuLx1VXd+O0xfj9lf8RGn+5Zo3bOlm WfIgacTXxQHhRpFif2KCRgLIYHqMAGZOERtNkVKpHp592TM1MNYd3puFovew PJkkw7HOYCxkC5mauTDUsF/w000PWFIfQ5s+bLz3a9ZTVPgxqN+XOZpslljO tmvra4rvgXQpHnuAHQ1M62sy67sXIyOzNyaJ6S9brtd/HrSGI3SlfAugiOjp LG5A0K3h3Tl5z4PDCRTJ4DEeTAfFOpVfhGa54JsNmSgooG7u+MuZS5cCAwEA AaOCAr4wggK6MA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFDj3hZ+loavQ ZgiKbHzwvz0We5Z9MA4GA1UdDwEB/wQEAwIBBjAQBgkrBgEEAYI3FQEEAwIB ADAZBgkrBgEEAYI3FAIEDB4KAFMAdQBiAEMAQTAfBgNVHSMEGDAWgBT6dCvU g+SukWIUtjL5FUYROmARiTCCAQ4GA1UdHwSCAQUwggEBMIH+oIH7oIH4hjZo dHRwOi8vd3d3LmNvcmVtZWRpYS5jb20vcGtpL0NvcmVNZWRpYSUyMFJvb3Ql MjBDQS5jcmyGgb1sZGFwOi8vL0NOPUNvcmVNZWRpYSUyMFJvb3QlMjBDQSxD Tj1yb290Y2EsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9Y29yZW1lZGlhLERDPWNv bT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9 Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggEWBggrBgEFBQcBAQSCAQgwggEEMEkG CCsGAQUFBzAChj1odHRwOi8vd3d3LmNvcmVtZWRpYS5jb20vcGtpL3Jvb3Rj YV9Db3JlTWVkaWElMjBSb290JTIwQ0EuY3J0MIG2BggrBgEFBQcwAoaBqWxk YXA6Ly8vQ049Q29yZU1lZGlhJTIwUm9vdCUyMENBLENOPUFJQSxDTj1QdWJs aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0 aW9uLERDPWNvcmVtZWRpYSxEQz1jb20/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29i amVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJKoZIhvcNAQEF BQADggIBADZbc53DGm9i61bMHU3Xr0/yVWSYeraZRvDlFfuRESRRwd83lggG yIV/z3Aer09CdUo0DKb5OTiid+0wZSMfjAsXq2BxgQICpvAv+o4X5VLkCjT0 gQQZ+/V+6zl38k3aBKaNGrQMfzfiobOztsknlFYGN1CY4KvX8ozUL7TRWcvX S0KsHFvVxYFuM3jHN8nYJGwO5ZgQdKgPgXT0J19pFJ/GrLJ4kysbpFvpvdE1 wjnZvYrgt4H9W2J5oAcapRSqFukfcbnh6P+TP6tYE/nk1rWmzOQ+HE0naWSi GZuqUjGWZmIIljOhGMFkgqQbWnhhrvGWkZt0Vh8tZwDkk2E9hjkcVsHT5MPm Q5oSEkACPij7gae1CWPDGzUzMuDtHdUJCQK075k/NrHIGB0Amtus5Fcay4lZ 6AdQMBtJxCuJhYQM4EZHBx3Dtiz9811BSb+iEFJYEKpfuKKgCXwRw674rqMu +wXpWlmH2fFXlRI9gO80bWiAzeAbFBbjTFD33AEtDYz+vXhSh8SFtLcKh1T8 pSzEBDbvl5rzOvc4advhbxBwjlRiW14BkiH3kS7AXVn9jVzAyMXDVPQ0E+Rt SclD1Ei8roIoeYsnJYZJYwxYvmtxsxsWXTIufND6a2TgKvwlydcwQWm/+WKc w/LM/tzqokhw0n1HwsIFmmNRzVMnypIKMYIDDTCCAwkCAQEwfTBvMQswCQYD VQQGEwJERTETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT8ixkARkW CWNvcmVtZWRpYTEVMBMGA1UECgwMQ29yZU1lZGlhIEFHMRkwFwYDVQQDDBBD b3JlTWVkaWEgU3ViIENBAgobGzKCAAAAAABhMAkGBSsOAwIaBQCgggHmMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDEw OTEwMzQ1NlowIwYJKoZIhvcNAQkEMRYEFKVDTcD5EDD19uWvTrwKsGvj7/rg MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsO AwIaMAoGCCqGSIb3DQIFMIGMBgkrBgEEAYI3EAQxfzB9MG8xCzAJBgNVBAYT AkRFMRMwEQYKCZImiZPyLGQBGRYDY29tMRkwFwYKCZImiZPyLGQBGRYJY29y ZW1lZGlhMRUwEwYDVQQKDAxDb3JlTWVkaWEgQUcxGTAXBgNVBAMMEENvcmVN ZWRpYSBTdWIgQ0ECChsbMoIAAAAAAGEwgY4GCyqGSIb3DQEJEAILMX+gfTBv MQswCQYDVQQGEwJERTETMBEGCgmSJomT8ixkARkWA2NvbTEZMBcGCgmSJomT 8ixkARkWCWNvcmVtZWRpYTEVMBMGA1UECgwMQ29yZU1lZGlhIEFHMRkwFwYD VQQDDBBDb3JlTWVkaWEgU3ViIENBAgobGzKCAAAAAABhMA0GCSqGSIb3DQEB AQUABIGATUCyDYTgpPRlO11ECs6/bRqScOFGKy9KjZpSCddbyZWDJgj///0A idwAlecZsO91D1dKRTRI+4Ikc0ICuFf6UBAKNztVTVEv7BEy3QrGEZTSpm8T U+ScNLGJdjidELQlAJ3lCBdWrv3PeZ9nx0gopJJYpCyLM+wVxjiozz4ni60A AAAAAAA= ------=_NextPart_000_00C0_01C61510.B769C4A0-- From owner-linux-xfs@oss.sgi.com Mon Jan 9 09:49:49 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 09:49:57 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09Hnnm2023827 for ; Mon, 9 Jan 2006 09:49:49 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.54 #1 (Red Hat Linux)) id 1Ew09r-0000O9-NG; Mon, 09 Jan 2006 16:46:11 +0000 Date: Mon, 9 Jan 2006 16:46:11 +0000 From: Christoph Hellwig To: Sam Ravnborg Cc: hch@infradead.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060109164611.GA1382@infradead.org> Mail-Followup-To: Christoph Hellwig , Sam Ravnborg , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20060109164214.GA10367@mars.ravnborg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060109164214.GA10367@mars.ravnborg.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 7141 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 643 Lines: 17 On Mon, Jan 09, 2006 at 05:42:14PM +0100, Sam Ravnborg wrote: > Hi hch. > > Any specific reason why xfs uses a indirection for the Makefile? > It is planned to drop export of VERSION, PATCHLEVEL etc. from > main makefile and it is OK except for xfs due to the funny > Makefile indirection. > > I suggest: > git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile I'd be all for it, but the SGI people like this layout to keep a common fs/xfs for both 2.4 and 2.6 (with linux-2.4 and linux-2.6 subdirs respectively) p.s. and no, I'm not official xfs maintainer and never have been, so cc set to linux-xfs were all interested parties hang around. From owner-linux-xfs@oss.sgi.com Mon Jan 9 11:23:06 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 11:23:13 -0800 (PST) Received: from pqueueb.post.tele.dk (pqueueb.post.tele.dk [193.162.153.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09JN5m2027930 for ; Mon, 9 Jan 2006 11:23:05 -0800 Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by pqueueb.post.tele.dk (Postfix) with ESMTP id 81B633DE4E5 for ; Mon, 9 Jan 2006 18:20:09 +0100 (CET) Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id 755B21EC308; Mon, 9 Jan 2006 18:19:54 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 6372B43CD24; Mon, 9 Jan 2006 18:19:38 +0100 (CET) Date: Mon, 9 Jan 2006 18:19:38 +0100 From: Sam Ravnborg To: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060109171938.GA19283@mars.ravnborg.org> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060109164611.GA1382@infradead.org> User-Agent: Mutt/1.5.11 X-archive-position: 7142 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: linux-xfs Content-Length: 1073 Lines: 30 On Mon, Jan 09, 2006 at 04:46:11PM +0000, Christoph Hellwig wrote: > On Mon, Jan 09, 2006 at 05:42:14PM +0100, Sam Ravnborg wrote: > > Hi hch. > > > > Any specific reason why xfs uses a indirection for the Makefile? > > It is planned to drop export of VERSION, PATCHLEVEL etc. from > > main makefile and it is OK except for xfs due to the funny > > Makefile indirection. > > > > I suggest: > > git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile > > I'd be all for it, but the SGI people like this layout to keep a common > fs/xfs for both 2.4 and 2.6 (with linux-2.4 and linux-2.6 subdirs respectively) > I have the following in my tree right now to make it compile. But it looks pointless to me. All other submitters are asked to keep backward compatibility cruft out of kernel proper - the same should hold for xfs. Sam diff --git a/fs/xfs/Makefile b/fs/xfs/Makefile index 49e3e7e..0630339 100644 --- a/fs/xfs/Makefile +++ b/fs/xfs/Makefile @@ -1 +1 @@ -include $(TOPDIR)/fs/xfs/Makefile-linux-$(VERSION).$(PATCHLEVEL) +include $(srctree)/fs/xfs/Makefile-linux-2.6 From owner-linux-xfs@oss.sgi.com Mon Jan 9 13:05:15 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 13:05:18 -0800 (PST) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09L5Em2003925 for ; Mon, 9 Jan 2006 13:05:15 -0800 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id 01D401EC32B; Mon, 9 Jan 2006 22:01:20 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 6312543CD24; Mon, 9 Jan 2006 22:01:05 +0100 (CET) Date: Mon, 9 Jan 2006 22:01:05 +0100 From: Sam Ravnborg To: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060109210105.GA13853@mars.ravnborg.org> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060109164611.GA1382@infradead.org> User-Agent: Mutt/1.5.11 X-archive-position: 7144 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: linux-xfs Content-Length: 1770 Lines: 49 On Mon, Jan 09, 2006 at 04:46:11PM +0000, Christoph Hellwig wrote: > On Mon, Jan 09, 2006 at 05:42:14PM +0100, Sam Ravnborg wrote: > > Hi hch. > > > > Any specific reason why xfs uses a indirection for the Makefile? > > It is planned to drop export of VERSION, PATCHLEVEL etc. from > > main makefile and it is OK except for xfs due to the funny > > Makefile indirection. > > > > I suggest: > > git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile > > I'd be all for it, but the SGI people like this layout to keep a common > fs/xfs for both 2.4 and 2.6 (with linux-2.4 and linux-2.6 subdirs respectively) > > p.s. and no, I'm not official xfs maintainer and never have been, so cc set > to linux-xfs were all interested parties hang around. Following is what I have committed in my tree to avod using the now un-exported symbols. Sam diff-tree a9aa1ffaac7c8d6f093bb8f7cdeea761a5e25f53 (from 0d20babd86b40fa5ac55d9ebf31d05f6f7082161) Author: Sam Ravnborg Date: Mon Jan 9 20:48:03 2006 +0100 kbuild/xfs: introduce fs/xfs/Kbuild In kbuild the file named 'Kbuild' has precedence over the file named Makefile. Utilise a file named Kbuild to include the 2.6 Makefile for xfs - since the xfs people likes to keep their arch specific Makefiles separate. With this patch xfs does no longer rely on the KERNELRELEASE components to be global. Signed-off-by: Sam Ravnborg diff --git a/fs/xfs/Kbuild b/fs/xfs/Kbuild new file mode 100644 index 0000000..2566e96 --- /dev/null +++ b/fs/xfs/Kbuild @@ -0,0 +1,6 @@ +# +# The xfs people like to share Makefile with 2.6 and 2.4. +# Utilise file named Kbuild file which has precedence over Makefile. +# + +include $(srctree)/$(obj)/Makefile-linux-2.6 From owner-linux-xfs@oss.sgi.com Mon Jan 9 13:01:30 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 13:01:37 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k09L1Sm2003642 for ; Mon, 9 Jan 2006 13:01:30 -0800 Received: from snort.melbourne.sgi.com (snort.melbourne.sgi.com [134.14.54.149]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA06868; Tue, 10 Jan 2006 07:57:21 +1100 Received: from snort.melbourne.sgi.com (localhost [127.0.0.1]) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k09KvHdM62302908; Tue, 10 Jan 2006 07:57:18 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k09KvEUT62777958; Tue, 10 Jan 2006 07:57:14 +1100 (EST) Date: Tue, 10 Jan 2006 07:57:14 +1100 From: David Chinner To: "Horchler, Joerg" Cc: linux-xfs@oss.sgi.com Subject: Re: Problems using xfs on RAID 5 volumes Message-ID: <20060109205714.GL58731470@melbourne.sgi.com> References: <37191A9D3396224A92F6F9306DFB119D0142A7B0@MARS.coremedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <37191A9D3396224A92F6F9306DFB119D0142A7B0@MARS.coremedia.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7143 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: dgc@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1838 Lines: 48 On Mon, Jan 09, 2006 at 11:34:56AM +0100, Horchler, Joerg wrote: > Hi, > > we have a big problem using XFS on our fileserver. Our configuration is: > > We are using a Dell PowerVault as external RAID Array which is configured > with two logical volumes. Each logical volume is configured with 7 physical > disks. Six disks are configured to form a RAID 5 and the last is configured > as hot spare. Our server is a 'SuSE Linux Enterprise Server 9' running with > kernel 2.6.5-7.151-smp. xfsprogs of version 2.6.25-0.2 are installed. I > don't know which version of XFS is installed with the running kernel. > > Now our problem: > > Every time a physical disk fails (and the RAID swaps from state OPTIMAL to > DEGRADED) the RAID rebuilds onto the hot spare. During this rebuild we get a > lot of XFS errors in our dmesg: > > 0x0: 66 4e 1f 21 5d 98 0e d9 23 70 65 00 1f 02 00 7d > Filesystem "dm-4": XFS internal error xfs_da_do_buf(2) at line 2273 of file > fs/xfs/xfs_da_btree.c. Caller 0xf918f522 That indicates that XFS has received corrupt data from the disk when reading a directory entry. Given that you've had a disk failure and the volume is rebuilding, I'd suspect a RAID problem.... > nfsd: non-standard errno: -990 EFSCORRUPTED. > The more curious problem is that during such a rebuild we loose some files > on the filesystem. The worst case was that XFS stops the filesystem which > produces I/O errors. Then we have to remount and repair the filesystem which > produces several GB of data lost. This sounds like your RAID controller is not rebuilding the underlying volume correctly or has some problem with writing new data to the volume while a reconstruction is in progress. This does not sound like an XFS problem at all. Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Mon Jan 9 13:08:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 13:09:01 -0800 (PST) Received: from omx2.sgi.com (omx2-ext.sgi.com [192.48.171.19]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09L8um2004504 for ; Mon, 9 Jan 2006 13:08:56 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k09NEa9Y006473 for ; Mon, 9 Jan 2006 15:14:36 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by flecktone.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k09L3wDN23422678; Mon, 9 Jan 2006 15:03:58 -0600 (CST) Message-ID: <43C2CFBD.8040901@sgi.com> Date: Mon, 09 Jan 2006 15:03:57 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Sam Ravnborg , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> In-Reply-To: <20060109164611.GA1382@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7145 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 1233 Lines: 34 Christoph Hellwig wrote: > On Mon, Jan 09, 2006 at 05:42:14PM +0100, Sam Ravnborg wrote: > >>Hi hch. >> >>Any specific reason why xfs uses a indirection for the Makefile? >>It is planned to drop export of VERSION, PATCHLEVEL etc. from >>main makefile and it is OK except for xfs due to the funny >>Makefile indirection. >> >>I suggest: >>git mv fs/xfs/Makefile-linux-2.6 fs/xfs/Makefile > > > I'd be all for it, but the SGI people like this layout to keep a common > fs/xfs for both 2.4 and 2.6 (with linux-2.4 and linux-2.6 subdirs respectively) > > p.s. and no, I'm not official xfs maintainer and never have been, so cc set > to linux-xfs were all interested parties hang around. > Yep, our internal tree has both linux-2.4/ and linux-2.6/ subdirs, so this is handy internal to sgi. But I don't have a big problem with the kernel.org code losing the indirection, even if we keep it here. I'd check with Nathan first though, because he'd have to work around that difference when he pushes code out. Out of curiosity, what's the reason to drop VERSION & PATCHLEVEL... seems handy if you have a common body of code that needs to build for various kernels, with various Makefiles to suit. As above. :) Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 9 13:09:45 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 13:09:46 -0800 (PST) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09L9Wm2004800 for ; Mon, 9 Jan 2006 13:09:45 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.54 #1 (Red Hat Linux)) id 1Ew4Cy-0002cV-FN; Mon, 09 Jan 2006 21:05:40 +0000 Date: Mon, 9 Jan 2006 21:05:40 +0000 From: Christoph Hellwig To: Sam Ravnborg Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060109210540.GA9972@infradead.org> Mail-Followup-To: Christoph Hellwig , Sam Ravnborg , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <20060109210105.GA13853@mars.ravnborg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060109210105.GA13853@mars.ravnborg.org> User-Agent: Mutt/1.4.2.1i X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html X-archive-position: 7146 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: linux-xfs Content-Length: 298 Lines: 10 > +# > +# The xfs people like to share Makefile with 2.6 and 2.4. > +# Utilise file named Kbuild file which has precedence over Makefile. > +# > + > +include $(srctree)/$(obj)/Makefile-linux-2.6 What about just putting the content of the current Makefile-linux-2.6 into the Kbuild file directly? From owner-linux-xfs@oss.sgi.com Mon Jan 9 13:22:22 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 13:22:23 -0800 (PST) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09LMLm2006045 for ; Mon, 9 Jan 2006 13:22:21 -0800 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id 7A7A11EC335; Mon, 9 Jan 2006 22:18:27 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id A294C43CD24; Mon, 9 Jan 2006 22:18:11 +0100 (CET) Date: Mon, 9 Jan 2006 22:18:11 +0100 From: Sam Ravnborg To: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060109211811.GB14477@mars.ravnborg.org> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <20060109210105.GA13853@mars.ravnborg.org> <20060109210540.GA9972@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060109210540.GA9972@infradead.org> User-Agent: Mutt/1.5.11 X-archive-position: 7147 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: linux-xfs Content-Length: 786 Lines: 21 On Mon, Jan 09, 2006 at 09:05:40PM +0000, Christoph Hellwig wrote: > > +# > > +# The xfs people like to share Makefile with 2.6 and 2.4. > > +# Utilise file named Kbuild file which has precedence over Makefile. > > +# > > + > > +include $(srctree)/$(obj)/Makefile-linux-2.6 > > What about just putting the content of the current Makefile-linux-2.6 > into the Kbuild file directly? People do not expect this - since the Kbuild filename is not used expect in the top-level directory. So as a principle of minimum suprise I left the old Makefile as-is, and introduced the new Kbuild file. If xfs people likes it different then they can change it anytime. If I one day start my little "kbuild file parser to a single makefile" project it may be the day where we do the transition. Sam From owner-linux-xfs@oss.sgi.com Mon Jan 9 13:24:12 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 13:24:13 -0800 (PST) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09LOBm2006338 for ; Mon, 9 Jan 2006 13:24:11 -0800 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id 9E4281EC326; Mon, 9 Jan 2006 22:20:20 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 1FA7643CD24; Mon, 9 Jan 2006 22:20:05 +0100 (CET) Date: Mon, 9 Jan 2006 22:20:05 +0100 From: Sam Ravnborg To: Eric Sandeen Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060109212005.GC14477@mars.ravnborg.org> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <43C2CFBD.8040901@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43C2CFBD.8040901@sgi.com> User-Agent: Mutt/1.5.11 X-archive-position: 7148 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: linux-xfs Content-Length: 494 Lines: 12 On Mon, Jan 09, 2006 at 03:03:57PM -0600, Eric Sandeen wrote: > Out of curiosity, what's the reason to drop VERSION & PATCHLEVEL... seems > handy if you have a common body of code that needs to build for various > kernels, with various Makefiles to suit. As above. :) The kernel is supposed to hold the code for the kernel - not a lot of backward compatibiliy cruft. In many places they were used to define KERNELRELEASE - but wrongly since definition of KERNELRELEASE has changed. Sam From owner-linux-xfs@oss.sgi.com Mon Jan 9 13:27:35 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 13:27:36 -0800 (PST) Received: from omx1.americas.sgi.com (omx1-ext.sgi.com [192.48.179.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09LRYm2007079 for ; Mon, 9 Jan 2006 13:27:34 -0800 Received: from ledzep.americas.sgi.com (ledzep.americas.sgi.com [198.149.16.14]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k09LNhxT026900 for ; Mon, 9 Jan 2006 15:23:43 -0600 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by ledzep.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k09LNeQT28840196; Mon, 9 Jan 2006 15:23:41 -0600 (CST) Message-ID: <43C2D45B.2050704@sgi.com> Date: Mon, 09 Jan 2006 15:23:39 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ravnborg CC: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <43C2CFBD.8040901@sgi.com> <20060109212005.GC14477@mars.ravnborg.org> In-Reply-To: <20060109212005.GC14477@mars.ravnborg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7149 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sandeen@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 901 Lines: 25 Sam Ravnborg wrote: > On Mon, Jan 09, 2006 at 03:03:57PM -0600, Eric Sandeen wrote: > > >>Out of curiosity, what's the reason to drop VERSION & PATCHLEVEL... seems >>handy if you have a common body of code that needs to build for various >>kernels, with various Makefiles to suit. As above. :) > > The kernel is supposed to hold the code for the kernel - not a lot of > backward compatibiliy cruft. Understood, and it makes sense to yank that compat cruft from kernel.org codebases. But it seems useful for projects outside the kernel which would like to know which kernel they are building against, as far as the build system goes. I've seen a few drivers out there that try to keep building for both 2.4 & 2.6. I guess for 2.4 & 2.6, the same can be accomplished by using Makefile and Kbuild for 2.4 and 2.6.... Maybe you can export it only if KBUILD_EXTMOD is set :) Thanks, -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 9 13:49:53 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 13:49:56 -0800 (PST) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k09Lnqm2008285 for ; Mon, 9 Jan 2006 13:49:52 -0800 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id D75CC1EC318; Mon, 9 Jan 2006 22:46:00 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id F37BC43CD24; Mon, 9 Jan 2006 22:45:44 +0100 (CET) Date: Mon, 9 Jan 2006 22:45:44 +0100 From: Sam Ravnborg To: Eric Sandeen Cc: Christoph Hellwig , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060109214544.GA17315@mars.ravnborg.org> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <43C2CFBD.8040901@sgi.com> <20060109212005.GC14477@mars.ravnborg.org> <43C2D45B.2050704@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43C2D45B.2050704@sgi.com> User-Agent: Mutt/1.5.11 X-archive-position: 7150 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: sam@ravnborg.org Precedence: bulk X-list: linux-xfs Content-Length: 924 Lines: 29 On Mon, Jan 09, 2006 at 03:23:39PM -0600, Eric Sandeen wrote: > codebases. > > But it seems useful for projects outside the kernel which would like to > know which kernel they are building against, as far as the build system > goes. I've seen a few drivers out there that try to keep building for both > 2.4 & 2.6. > > I guess for 2.4 & 2.6, the same can be accomplished by using Makefile and > Kbuild for 2.4 and 2.6.... Good point. External modules slipped my mind when I did this change. We have today: VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 15 EXTRAVERSION = EXTRAVERSION will soon become -rc1 No sane driver will check for more than VERISON, PATCHLEVEL, SUBLEVEL. xfs for once only used VERSION, PATCHLEVEL. googling a little gave lot's of very ugly examples how it can be done using grep, perl etc. So there is a legitim need for the variable anyway. So I will re-export VERISON, PATCHLEVEL, SUBLEVEL. Sam From owner-linux-xfs@oss.sgi.com Mon Jan 9 23:32:45 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 09 Jan 2006 23:32:49 -0800 (PST) Received: from larry.melbourne.sgi.com (mverd138.asia.info.net [61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0A7Whm2008780 for ; Mon, 9 Jan 2006 23:32:44 -0800 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA20965 for ; Tue, 10 Jan 2006 17:26:16 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 149BB494A272; Tue, 10 Jan 2006 17:26:15 +1100 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 904196 - Merge up to 2.6.15 Message-Id: <20060110062615.149BB494A272@chook.melbourne.sgi.com> Date: Tue, 10 Jan 2006 17:26:15 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7151 X-ecartis-version: Ecartis v1.0.0 Sender: linux-xfs-bounce@oss.sgi.com Errors-to: linux-xfs-bounce@oss.sgi.com X-original-sender: nathans@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 42558 Lines: 536 Date: Tue Jan 10 17:25:20 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/2.6.x-xfs Inspected by: torvalds@osdl.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: 2.6.x-xfs-melb:linux:24948a split-patches/kdb-v4.4-2.6.15-common-1 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.15-common-1 split-patches/kdb-v4.4-2.6.15-ia64-1 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.15-ia64-1 split-patches/kdb-v4.4-2.6.15-i386-1 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.15-i386-1 MAINTAINERS - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/MAINTAINERS.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h Makefile - 1.33 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Makefile.diff?r1=text&tr1=1.33&r2=text&tr2=1.32&f=h arch/arm/kernel/calls.S - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/calls.S.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/arm/kernel/entry-armv.S - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/entry-armv.S.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/arm/kernel/entry-common.S - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/arm/kernel/entry-common.S.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/i386/Makefile - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/Makefile.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/i386/kernel/entry.S - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/entry.S.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/i386/kernel/i8259.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/i8259.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h arch/i386/kernel/io_apic.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/io_apic.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h arch/i386/kernel/irq.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/irq.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/i386/kernel/process.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/process.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/i386/kernel/reboot.c - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/reboot.c.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h arch/i386/kernel/smp.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/smp.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h arch/i386/kernel/smpboot.c - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/smpboot.c.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h arch/i386/kernel/traps.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/traps.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h arch/i386/kernel/vmlinux.lds.S - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/i386/pci/Makefile - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/pci/Makefile.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ia64/Makefile - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/Makefile.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/ia64/kernel/mca.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/mca.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/ia64/kernel/smp.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/smp.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/ia64/kernel/traps.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/traps.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h arch/ia64/kernel/unwind.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/unwind.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/ia64/kernel/vmlinux.lds.S - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h arch/sparc/Kconfig - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/Kconfig.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h arch/sparc/kernel/sys_sunos.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/sys_sunos.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/sparc/kernel/vmlinux.lds.S - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/sparc64/Kconfig - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/Kconfig.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/sparc64/Makefile - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/Makefile.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/sparc64/kernel/sys_sunos32.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/sys_sunos32.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/sparc64/kernel/vmlinux.lds.S - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/kernel/vmlinux.lds.S.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/sparc64/solaris/misc.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/sparc64/solaris/misc.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/um/sys-i386/Makefile - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-i386/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/x86_64/mm/init.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/mm/init.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/x86_64/pci/Makefile - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/x86_64/pci/Makefile.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/acpi/utilities/utmisc.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/utilities/utmisc.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/char/Kconfig - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/Kconfig.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/char/drm/radeon_cp.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/drm/radeon_cp.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/char/keyboard.c - 1.23 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/keyboard.c.diff?r1=text&tr1=1.23&r2=text&tr2=1.22&f=h drivers/char/vc_screen.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/char/vc_screen.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/fc4/Kconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/fc4/Kconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/input/joystick/warrior.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/joystick/warrior.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/input/misc/Kconfig - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/misc/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/input/mouse/sermouse.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/mouse/sermouse.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/input/serio/i8042.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/input/serio/i8042.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/md/md.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/md/md.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/media/dvb/ttpci/av7110.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/ttpci/av7110.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/media/video/saa7134/Makefile - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7134/Makefile.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/media/video/saa7134/saa7134-oss.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7134/saa7134-oss.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/mtd/maps/Kconfig - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mtd/maps/Kconfig.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/net/ppp_generic.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/ppp_generic.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/net/sungem.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/sungem.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/net/tg3.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tg3.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/net/tg3.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/tg3.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/s390/net/qeth_mpc.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_mpc.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/s390/net/qeth_mpc.h - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_mpc.h.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/scsi/libata-scsi.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/libata-scsi.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/scsi/scsi_scan.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_scan.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/serial/8250.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/8250.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h drivers/serial/Kconfig - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/Kconfig.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/usb/core/usb.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/core/usb.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/usb/host/ohci-hcd.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-hcd.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/usb/host/ohci-pci.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-pci.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/usb/host/ohci-q.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/host/ohci-q.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h drivers/usb/input/aiptek.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/aiptek.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h drivers/usb/input/hid-core.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/hid-core.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h drivers/usb/input/kbtab.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/kbtab.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/usb/input/usbkbd.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/usbkbd.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/usb/input/wacom.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/input/wacom.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/usb/storage/scsiglue.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/usb/storage/scsiglue.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h drivers/video/Kconfig - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/Kconfig.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h drivers/video/console/Kconfig - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/console/Kconfig.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/video/logo/Kconfig - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/logo/Kconfig.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/video/sbuslib.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/sbuslib.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h fs/lockd/clntlock.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/lockd/clntlock.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/nfs/direct.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfs/direct.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h fs/nfs/file.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfs/file.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h fs/nfs/inode.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfs/inode.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h fs/partitions/Kconfig - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/partitions/Kconfig.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/proc/generic.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/proc/generic.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h fs/proc/proc_misc.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/proc/proc_misc.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&