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&f=h include/acpi/acglobal.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/acpi/acglobal.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-i386/kmap_types.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/kmap_types.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h include/asm-i386/mach-default/irq_vectors.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/mach-default/irq_vectors.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h include/asm-i386/param.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/param.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-i386/ptrace.h - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/ptrace.h.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h include/asm-ia64/topology.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/topology.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h include/asm-x86_64/param.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/param.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/asm-x86_64/rwlock.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/rwlock.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/asm-x86_64/topology.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-x86_64/topology.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/linux/console.h - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/console.h.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h include/linux/ipv6_route.h - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/ipv6_route.h.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h include/linux/irq.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/irq.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h include/linux/n_r3964.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/n_r3964.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/nfs_fs.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/nfs_fs.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/linux/preempt.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/preempt.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/linux/rtnetlink.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/rtnetlink.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h include/linux/sysctl.h - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/sysctl.h.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h include/net/if_inet6.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/if_inet6.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h include/net/xfrm.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/net/xfrm.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h init/Kconfig - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/init/Kconfig.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h init/main.c - 1.27 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/init/main.c.diff?r1=text&tr1=1.27&r2=text&tr2=1.26&f=h ipc/sem.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/ipc/sem.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h kernel/exit.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/exit.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h kernel/futex.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/futex.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h kernel/kallsyms.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/kallsyms.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h kernel/module.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/module.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h kernel/params.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/params.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h kernel/printk.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/printk.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h kernel/sched.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/sched.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h kernel/signal.c - 1.21 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/signal.c.diff?r1=text&tr1=1.21&r2=text&tr2=1.20&f=h kernel/sysctl.c - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kernel/sysctl.c.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h mm/swapfile.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/swapfile.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h net/8021q/vlan.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/8021q/vlan.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/bridge/br_netfilter.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/bridge/br_netfilter.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h net/core/filter.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/core/filter.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h net/ipv4/netfilter/Makefile - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/netfilter/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv4/xfrm4_policy.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv4/xfrm4_policy.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h net/ipv6/addrconf.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/addrconf.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h net/ipv6/icmp.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/icmp.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h net/ipv6/mcast.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/mcast.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h net/ipv6/netfilter/Kconfig - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/netfilter/Kconfig.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/ipv6/route.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/route.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h net/ipv6/xfrm6_policy.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/ipv6/xfrm6_policy.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/netrom/nr_in.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/netrom/nr_in.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h net/sctp/socket.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sctp/socket.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h net/sunrpc/auth_gss/auth_gss.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sunrpc/auth_gss/auth_gss.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h net/sunrpc/rpc_pipe.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sunrpc/rpc_pipe.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h net/xfrm/xfrm_policy.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/xfrm/xfrm_policy.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h net/xfrm/xfrm_state.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/xfrm/xfrm_state.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h sound/sparc/Kconfig - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/sound/sparc/Kconfig.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/net/forcedeth.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/forcedeth.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h drivers/media/dvb/ttpci/av7110_hw.h - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/dvb/ttpci/av7110_hw.h.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/macintosh/therm_pm72.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/macintosh/therm_pm72.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h Documentation/kdb/kdb.mm - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb.mm.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h Documentation/kdb/kdb_bp.man - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_bp.man.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h Documentation/kdb/kdb_bt.man - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_bt.man.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h Documentation/kdb/kdb_env.man - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_env.man.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h Documentation/kdb/kdb_ll.man - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_ll.man.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h Documentation/kdb/kdb_md.man - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_md.man.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h Documentation/kdb/kdb_rd.man - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_rd.man.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h Documentation/kdb/kdb_sr.man - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_sr.man.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h Documentation/kdb/kdb_ss.man - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_ss.man.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h Documentation/kdb/slides - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/slides.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h kdb/Makefile - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/Makefile.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h kdb/kdbmain.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdbmain.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h kdb/modules/kdbm_vm.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/kdbm_vm.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h kdb/modules/kdbm_task.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/kdbm_task.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/linux/dis-asm.h - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/dis-asm.h.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h include/linux/kdb.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/kdb.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/linux/kdbprivate.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/kdbprivate.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h kdb/modules/kdbm_pg.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/kdbm_pg.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h kdb/modules/Makefile - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/Makefile.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h kdb/ChangeLog - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/ChangeLog.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h kdb/kdbsupport.c - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdbsupport.c.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h kdb/kdb_bp.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdb_bp.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h kdb/kdb_bt.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdb_bt.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h kdb/kdb_id.c - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdb_id.c.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h kdb/kdb_io.c - 1.15 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdb_io.c.diff?r1=text&tr1=1.15&r2=text&tr2=1.14&f=h kdb/kdb_cmds - 1.14 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/kdb_cmds.diff?r1=text&tr1=1.14&r2=text&tr2=1.13&f=h kdb/modules/kdbm_x86.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/kdbm_x86.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/asm-i386/kdbprivate.h - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/kdbprivate.h.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/i386/kdb/ChangeLog - 1.20 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/ChangeLog.diff?r1=text&tr1=1.20&r2=text&tr2=1.19&f=h arch/i386/kdb/Makefile - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/Makefile.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/i386/kdb/i386-dis.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/i386-dis.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/i386/kdb/kdba_bp.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/kdba_bp.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/i386/kdb/kdba_bt.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/kdba_bt.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/i386/kdb/kdba_id.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/kdba_id.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/i386/kdb/kdba_io.c - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/kdba_io.c.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h arch/i386/kdb/kdbasupport.c - 1.17 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/kdbasupport.c.diff?r1=text&tr1=1.17&r2=text&tr2=1.16&f=h arch/i386/kdb/pc_keyb.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/pc_keyb.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h include/asm-i386/kdb.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/kdb.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h drivers/serial/pxa.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/pxa.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h drivers/scsi/scsi_transport_fc.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/scsi/scsi_transport_fc.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h include/scsi/scsi_transport_fc.h - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/scsi/scsi_transport_fc.h.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h split-patches/series - 1.30 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/series.diff?r1=text&tr1=1.30&r2=text&tr2=1.29&f=h drivers/s390/net/qeth_main.c - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_main.c.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h drivers/s390/net/qeth_proc.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_proc.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/s390/net/qeth_sys.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_sys.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/serial/amba-pl011.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/amba-pl011.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h mm/hugetlb.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/hugetlb.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h mm/mempolicy.c - 1.10 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/mm/mempolicy.c.diff?r1=text&tr1=1.10&r2=text&tr2=1.9&f=h Documentation/kdb/kdb_ps.man - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/Documentation/kdb/kdb_ps.man.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h arch/i386/kdb/kdb_cmds - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/kdb/kdb_cmds.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-i386/bfd.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/bfd.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h include/asm-i386/ansidecl.h - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-i386/ansidecl.h.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h drivers/serial/sn_console.c - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/sn_console.c.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h arch/ppc/platforms/85xx/mpc85xx_cds_common.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ppc/platforms/85xx/mpc85xx_cds_common.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/hostfs/hostfs_kern.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/hostfs/hostfs_kern.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h arch/i386/Kconfig.debug - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/Kconfig.debug.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h drivers/mmc/mmc_block.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/mmc/mmc_block.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/um/os-Linux/user_syms.c - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/user_syms.c.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h arch/ia64/Kconfig.debug - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/Kconfig.debug.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h drivers/serial/8250_early.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/serial/8250_early.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h drivers/video/intelfb/intelfb.h - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/intelfb/intelfb.h.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/video/intelfb/intelfbdrv.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/intelfb/intelfbdrv.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h arch/um/sys-x86_64/Makefile - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/sys-x86_64/Makefile.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/acpi/processor_idle.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/processor_idle.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/acpi/processor_thermal.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/acpi/processor_thermal.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h drivers/media/video/tveeprom.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/tveeprom.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h fs/proc/mmu.c - 1.7 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/proc/mmu.c.diff?r1=text&tr1=1.7&r2=text&tr2=1.6&f=h kdb/modules/kdbm_sched.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/kdb/modules/kdbm_sched.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/kdbprivate.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/kdbprivate.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/kdb_break.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/kdb_break.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/kdb.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/kdb.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/bfd.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/bfd.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h include/asm-ia64/ansidecl.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/asm-ia64/ansidecl.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h drivers/s390/net/qeth_eddp.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_eddp.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/s390/net/qeth_tso.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/s390/net/qeth_tso.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/ia64/kdb/kdbasupport.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdbasupport.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/kdba_pod.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdba_pod.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/kdba_jmp.S - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdba_jmp.S.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/kdba_io.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdba_io.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/kdba_id.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdba_id.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/kdba_fru.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdba_fru.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/kdba_bt.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdba_bt.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/kdba_bp.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdba_bp.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/kdb_cmds - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/kdb_cmds.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/ia64.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/ia64.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/ia64-opc.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/ia64-opc.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/ia64-opc.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/ia64-opc.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/ia64-dis.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/ia64-dis.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/ia64-asmtab.h - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/ia64-asmtab.h.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/ia64-asmtab.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/ia64-asmtab.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/cpu-ia64-opc.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/cpu-ia64-opc.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/Makefile - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/Makefile.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h arch/ia64/kdb/ChangeLog - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/ia64/kdb/ChangeLog.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h fs/relayfs/relay.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/relayfs/relay.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h include/linux/relayfs_fs.h - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/include/linux/relayfs_fs.h.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/nfsd/nfs3acl.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfsd/nfs3acl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h fs/nfsd/nfs2acl.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/fs/nfsd/nfs2acl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/um/os-Linux/start_up.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/um/os-Linux/start_up.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h net/dccp/ipv4.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/dccp/ipv4.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/wireless/orinoco_nortel.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/wireless/orinoco_nortel.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/net/phy/phy_device.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/net/phy/phy_device.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h lib/spinlock_debug.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/lib/spinlock_debug.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h net/sunrpc/xprtsock.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/net/sunrpc/xprtsock.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h block/scsi_ioctl.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/block/scsi_ioctl.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h lib/swiotlb.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/lib/swiotlb.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/video/cx25840/cx25840-core.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/cx25840/cx25840-core.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/video/em28xx/em28xx-core.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/em28xx/em28xx-core.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/em28xx/em28xx-i2c.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/em28xx/em28xx-i2c.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/em28xx/em28xx-video.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/em28xx/em28xx-video.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/em28xx/em28xx.h - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/em28xx/em28xx.h.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/media/video/saa7127.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7127.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/video/saa7134/Kconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7134/Kconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h drivers/media/video/saa7134/saa7134-alsa.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/media/video/saa7134/saa7134-alsa.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/platforms/pseries/xics.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/platforms/pseries/xics.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/i386/Makefile.cpu - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/i386/Makefile.cpu.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h arch/powerpc/mm/hash_utils_64.c - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/mm/hash_utils_64.c.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h drivers/video/console/fbcon_ud.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/drivers/video/console/fbcon_ud.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/kernel/entry_64.S - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/kernel/entry_64.S.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/configs/pseries_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/configs/pseries_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/configs/ppc64_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/configs/ppc64_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/configs/maple_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/configs/maple_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/configs/iseries_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/configs/iseries_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/configs/g5_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/configs/g5_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h arch/powerpc/configs/cell_defconfig - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/arch/powerpc/configs/cell_defconfig.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-v4.4-2.6.15-rc6-ia64-1 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.15-rc6-ia64-1.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-v4.4-2.6.15-rc6-i386-1 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.15-rc6-i386-1.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h split-patches/kdb-v4.4-2.6.15-rc6-common-1 - 1.2 - deleted http://oss.sgi.com/cgi-bin/cvsweb.cgi/linux-2.6-xfs/split-patches/kdb-v4.4-2.6.15-rc6-common-1.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h From owner-linux-xfs@oss.sgi.com Tue Jan 10 00:32:46 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 00:32:53 -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 k0A8Whm2017985 for ; Tue, 10 Jan 2006 00:32:44 -0800 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA22706; Tue, 10 Jan 2006 18:31:30 +1100 Message-ID: <43C36270.4090008@sgi.com> Date: Tue, 10 Jan 2006 18:29:52 +1100 From: Timothy Shimmin User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Shailendra Tripathi CC: linux-xfs@oss.sgi.com Subject: Re: Unexpected xfs_buf_item_init initialization and inflexible xfs_buf_item_zone References: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> <43BA04AF.2060703@agami.com> In-Reply-To: <43BA04AF.2060703@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7152 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: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 3284 Lines: 87 Hi Shailendra, Thanks for the report. I'll get back to you tomorrow on this when I look more at the code. Regards, Tim. Shailendra Tripathi wrote: > 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 Tue Jan 10 00:53:24 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 00:53:32 -0800 (PST) Received: from smtp.osdl.org (smtp.osdl.org [65.172.181.4]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0A8rNm2019289 for ; Tue, 10 Jan 2006 00:53:23 -0800 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id k0A7jjDZ026977 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 9 Jan 2006 23:45:46 -0800 Received: from bix (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id k0A7jjdo016731; Mon, 9 Jan 2006 23:45:45 -0800 Date: Mon, 9 Jan 2006 23:45:32 -0800 From: Andrew Morton To: Eric Sandeen Cc: hch@infradead.org, sam@ravnborg.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-Id: <20060109234532.78bda36a.akpm@osdl.org> In-Reply-To: <43C2CFBD.8040901@sgi.com> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <43C2CFBD.8040901@sgi.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.129 $ X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7153 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: akpm@osdl.org Precedence: bulk X-list: linux-xfs Content-Length: 706 Lines: 19 It'd be nice to fix this: bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o SPLIT include/linux/autoconf.h -> include/config/* SHIPPED scripts/genksyms/lex.c SHIPPED scripts/genksyms/parse.h SHIPPED scripts/genksyms/keywords.c HOSTCC scripts/genksyms/lex.o SHIPPED scripts/genksyms/parse.c HOSTCC scripts/genksyms/parse.o HOSTLD scripts/genksyms/genksyms HOSTCC scripts/mod/file2alias.o HOSTCC scripts/mod/modpost.o HOSTLD scripts/mod/modpost scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No such file or directory make[1]: *** No rule to make target `/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop. make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2 From owner-linux-xfs@oss.sgi.com Tue Jan 10 07:13:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 07:14:02 -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 k0AFDum2016625 for ; Tue, 10 Jan 2006 07:13: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 k0AHOmWr018135 for ; Tue, 10 Jan 2006 09:24:48 -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 k0AFE5DN23504351; Tue, 10 Jan 2006 09:14:05 -0600 (CST) Message-ID: <43C3CF3D.4000701@sgi.com> Date: Tue, 10 Jan 2006 09:14:05 -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: Andrew Morton CC: hch@infradead.org, sam@ravnborg.org, 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> <20060109234532.78bda36a.akpm@osdl.org> In-Reply-To: <20060109234532.78bda36a.akpm@osdl.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7159 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: 876 Lines: 26 Andrew Morton wrote: > It'd be nice to fix this: > > bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o > SPLIT include/linux/autoconf.h -> include/config/* > SHIPPED scripts/genksyms/lex.c > SHIPPED scripts/genksyms/parse.h > SHIPPED scripts/genksyms/keywords.c > HOSTCC scripts/genksyms/lex.o > SHIPPED scripts/genksyms/parse.c > HOSTCC scripts/genksyms/parse.o > HOSTLD scripts/genksyms/genksyms > HOSTCC scripts/mod/file2alias.o > HOSTCC scripts/mod/modpost.o > HOSTLD scripts/mod/modpost > scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No such file or directory > make[1]: *** No rule to make target `/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop. > make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2 I'll see what I can do to fix this up and a couple of other kbuild issues I've run into recently. Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Jan 10 08:34:32 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 08:34:34 -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 k0AGYWm2024823 for ; Tue, 10 Jan 2006 08:34:32 -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 k0AIjR3a002367 for ; Tue, 10 Jan 2006 10:45:27 -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 k0AGYhDN23506338; Tue, 10 Jan 2006 10:34:44 -0600 (CST) Message-ID: <43C3E222.7020203@sgi.com> Date: Tue, 10 Jan 2006 10:34:42 -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: Andrew Morton CC: hch@infradead.org, sam@ravnborg.org, 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> <20060109234532.78bda36a.akpm@osdl.org> In-Reply-To: <20060109234532.78bda36a.akpm@osdl.org> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7160 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: 1153 Lines: 31 Andrew Morton wrote: > It'd be nice to fix this: > > bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o > SPLIT include/linux/autoconf.h -> include/config/* > SHIPPED scripts/genksyms/lex.c > SHIPPED scripts/genksyms/parse.h > SHIPPED scripts/genksyms/keywords.c > HOSTCC scripts/genksyms/lex.o > SHIPPED scripts/genksyms/parse.c > HOSTCC scripts/genksyms/parse.o > HOSTLD scripts/genksyms/genksyms > HOSTCC scripts/mod/file2alias.o > HOSTCC scripts/mod/modpost.o > HOSTLD scripts/mod/modpost > scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No such file or directory > make[1]: *** No rule to make target `/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop. > make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2 Hm, maybe Sam can correct me if I'm wrong, but I'm not sure that kbuild will support more than one Makefile/Kbuild file per module; so if we have some code in a subdirectory, I think it all needs to be driven from the parent directory's Makefile... and then the above doesn't work. Sam, is there any way to make this work with some code for the module in a subdirectory? Thanks, -Eric From owner-linux-xfs@oss.sgi.com Tue Jan 10 12:00:14 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 12:00: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 k0AK0Dm2000873 for ; Tue, 10 Jan 2006 12:00:14 -0800 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id 4E5D71EC4CB; Tue, 10 Jan 2006 21:01:11 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id B40A843CD24; Tue, 10 Jan 2006 21:00:54 +0100 (CET) Date: Tue, 10 Jan 2006 21:00:54 +0100 From: Sam Ravnborg To: Andrew Morton Cc: Eric Sandeen , hch@infradead.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060110200054.GA14721@mars.ravnborg.org> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <43C2CFBD.8040901@sgi.com> <20060109234532.78bda36a.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060109234532.78bda36a.akpm@osdl.org> User-Agent: Mutt/1.5.11 X-archive-position: 7161 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: 1539 Lines: 37 On Mon, Jan 09, 2006 at 11:45:32PM -0800, Andrew Morton wrote: > > It'd be nice to fix this: > > bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o > SPLIT include/linux/autoconf.h -> include/config/* > SHIPPED scripts/genksyms/lex.c > SHIPPED scripts/genksyms/parse.h > SHIPPED scripts/genksyms/keywords.c > HOSTCC scripts/genksyms/lex.o > SHIPPED scripts/genksyms/parse.c > HOSTCC scripts/genksyms/parse.o > HOSTLD scripts/genksyms/genksyms > HOSTCC scripts/mod/file2alias.o > HOSTCC scripts/mod/modpost.o > HOSTLD scripts/mod/modpost > scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No such file or directory > make[1]: *** No rule to make target `/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop. > make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2 xfs as one of the very few users in the kernel has split up .o files in several directories. And kbuild does not have support for specifying that is shall link to a .o file that is being build in a sub-directory. This is in general noe encouraged for the kernel - it is not common practice. And therefore not something I have planned to implement. If there is a general consensus that we like to have this then it is doable, but it will uglify scripts/Makefile.lib even more. For xfs this is 37 .o files that are build in three directories. The easy fix would be to move the files to stay just under the xfs/ directory like all others - but xfs people prefer not to do so to stay compatible with their external source tree. Sam From owner-linux-xfs@oss.sgi.com Tue Jan 10 12:01:08 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 12:01:10 -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 k0AK17m2000937 for ; Tue, 10 Jan 2006 12:01:08 -0800 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id F052B1EC5C4; Tue, 10 Jan 2006 21:02:19 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 3CF8143CD24; Tue, 10 Jan 2006 21:02:03 +0100 (CET) Date: Tue, 10 Jan 2006 21:02:03 +0100 From: Sam Ravnborg To: Eric Sandeen Cc: Andrew Morton , hch@infradead.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060110200203.GB14721@mars.ravnborg.org> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <43C2CFBD.8040901@sgi.com> <20060109234532.78bda36a.akpm@osdl.org> <43C3E222.7020203@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43C3E222.7020203@sgi.com> User-Agent: Mutt/1.5.11 X-archive-position: 7162 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: 1344 Lines: 35 On Tue, Jan 10, 2006 at 10:34:42AM -0600, Eric Sandeen wrote: > Andrew Morton wrote: > >It'd be nice to fix this: > > > >bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o > > SPLIT include/linux/autoconf.h -> include/config/* > > SHIPPED scripts/genksyms/lex.c > > SHIPPED scripts/genksyms/parse.h > > SHIPPED scripts/genksyms/keywords.c > > HOSTCC scripts/genksyms/lex.o > > SHIPPED scripts/genksyms/parse.c > > HOSTCC scripts/genksyms/parse.o > > HOSTLD scripts/genksyms/genksyms > > HOSTCC scripts/mod/file2alias.o > > HOSTCC scripts/mod/modpost.o > > HOSTLD scripts/mod/modpost > >scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No > >such file or directory > >make[1]: *** No rule to make target > >`/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop. > >make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2 > > Hm, maybe Sam can correct me if I'm wrong, but I'm not sure that kbuild > will support more than one Makefile/Kbuild file per module; so if we have > some code in a subdirectory, I think it all needs to be driven from the > parent directory's Makefile... and then the above doesn't work. > > Sam, is there any way to make this work with some code for the module in a > subdirectory? Hi Eric - I covered this in my reply to Andrew. The short version - no, and it is not planned. Sam From owner-linux-xfs@oss.sgi.com Tue Jan 10 15:06:41 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 15:07:07 -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 k0AN6dm2012340 for ; Tue, 10 Jan 2006 15:06:40 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA10744; Wed, 11 Jan 2006 08:55:10 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0ALtKkt8293400; Wed, 11 Jan 2006 08:55:23 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0ALtHK38297229; Wed, 11 Jan 2006 08:55:17 +1100 (EST) Date: Wed, 11 Jan 2006 08:55:17 +1100 From: Nathan Scott To: linux-xfs@oss.sgi.com Cc: jpiszcz@lucidpixels.com Subject: Re: xfs_db -c frag -r /dev/hda1 - Segmentation fault (fwd) Message-ID: <20060111085516.A8264023@wobbly.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-archive-position: 7163 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: 760 Lines: 28 [ Justin, do you hang out here? My reply to you bounced yesterday - something at your end thought it was spam ] ----- Forwarded message from Nathan Scott ----- Date: Tue, 10 Jan 2006 16:30:26 +1100 To: Justin Piszcz User-Agent: Mutt/1.2.5i From: Nathan Scott Subject: Re: xfs_db -c frag -r /dev/hda1 - Segmentation fault Hi there, On Sun, Dec 25, 2005 at 06:46:26PM -0500, Justin Piszcz wrote: > Oops, you are the one who supplied the fix! > > I guess my question is when will it make it into Debian etch? This was fixed in xfsprogs-2.7.7 which is in the archive already (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338207). cheers. -- Nathan ----- End forwarded message ----- From owner-linux-xfs@oss.sgi.com Tue Jan 10 20:33:14 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 20:33:19 -0800 (PST) Received: from yamt.dyndns.org (FLA1Adj210.kng.mesh.ad.jp [60.236.232.210]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0B4X5m2008516 for ; Tue, 10 Jan 2006 20:33:14 -0800 Received: from me (localhost [127.0.0.1]) by yamt.dyndns.org (Postfix) with SMTP id C16D01170A; Wed, 11 Jan 2006 11:34:10 +0900 (JST) Received: (nullmailer pid 368 invoked by uid 1000); Wed, 11 Jan 2006 02:33:55 -0000 To: linux-xfs@oss.sgi.com Subject: fix of xfs large symlink problem X-Mailer: Cue version 0.8 (041105-2302/takashi) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="NextPart-20060111112913-0032300" Date: Wed, 11 Jan 2006 11:33:55 +0900 Message-Id: <1136946835.156223.1265.nullmailer@yamt.dyndns.org> From: YAMAMOTO Takashi X-archive-position: 7164 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: yamamoto@valinux.co.jp Precedence: bulk X-list: linux-xfs Content-Length: 1373 Lines: 53 --NextPart-20060111112913-0032300 Content-Type: Text/Plain; charset=us-ascii hi, the attached patch fixes the problem that linvfs_follow_link truncates large symlink contents. YAMAMOTO Takashi --NextPart-20060111112913-0032300 Content-Type: Text/Plain; charset=us-ascii Content-Disposition: attachment; filename="vaj_2.6.12-rc5_xfs-follow-link__0.patch" --- linux/fs/xfs/linux-2.6/xfs_iops.c.BACKUP 2005-05-25 12:31:20.000000000 +0900 +++ linux/fs/xfs/linux-2.6/xfs_iops.c 2005-08-08 11:21:31.000000000 +0900 @@ -388,7 +388,7 @@ linvfs_follow_link( ASSERT(dentry); ASSERT(nd); - link = (char *)kmalloc(MAXNAMELEN+1, GFP_KERNEL); + link = (char *)kmalloc(MAXPATHLEN+1, GFP_KERNEL); if (!link) { nd_set_link(nd, ERR_PTR(-ENOMEM)); return 0; @@ -404,12 +404,12 @@ linvfs_follow_link( vp = LINVFS_GET_VP(dentry->d_inode); iov.iov_base = link; - iov.iov_len = MAXNAMELEN; + iov.iov_len = MAXPATHLEN; uio->uio_iov = &iov; uio->uio_offset = 0; uio->uio_segflg = UIO_SYSSPACE; - uio->uio_resid = MAXNAMELEN; + uio->uio_resid = MAXPATHLEN; uio->uio_iovcnt = 1; VOP_READLINK(vp, uio, 0, NULL, error); @@ -417,7 +417,7 @@ linvfs_follow_link( kfree(link); link = ERR_PTR(-error); } else { - link[MAXNAMELEN - uio->uio_resid] = '\0'; + link[MAXPATHLEN - uio->uio_resid] = '\0'; } kfree(uio); --NextPart-20060111112913-0032300-- From owner-linux-xfs@oss.sgi.com Tue Jan 10 21:27:24 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 10 Jan 2006 21:27:29 -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 k0B5RMm2010724 for ; Tue, 10 Jan 2006 21:27:23 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21605; Wed, 11 Jan 2006 16:28:29 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0B5Sdkt8293625; Wed, 11 Jan 2006 16:28:41 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id k0B5QUw6002190; Wed, 11 Jan 2006 16:26:31 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id k0B5QRZ4002188; Wed, 11 Jan 2006 16:26:27 +1100 Date: Wed, 11 Jan 2006 16:26:27 +1100 From: Nathan Scott To: YAMAMOTO Takashi Cc: linux-xfs@oss.sgi.com Subject: Re: fix of xfs large symlink problem Message-ID: <20060111052627.GA2173@frodo> References: <1136946835.156223.1265.nullmailer@yamt.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1136946835.156223.1265.nullmailer@yamt.dyndns.org> User-Agent: Mutt/1.5.3i X-archive-position: 7165 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: 243 Lines: 13 On Wed, Jan 11, 2006 at 11:33:55AM +0900, YAMAMOTO Takashi wrote: > hi, > > the attached patch fixes the problem that > linvfs_follow_link truncates large symlink contents. Looks good, I'll get this merged in - thanks! cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Wed Jan 11 00:20:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Jan 2006 00:20:47 -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 k0B8KZm2028259 for ; Wed, 11 Jan 2006 00:20:36 -0800 Received: from [134.14.55.141] (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA25084; Wed, 11 Jan 2006 19:21:38 +1100 Message-ID: <43C4BFAF.1060507@sgi.com> Date: Wed, 11 Jan 2006 19:19:59 +1100 From: Timothy Shimmin User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Shailendra Tripathi CC: linux-xfs@oss.sgi.com Subject: Re: Unexpected xfs_buf_item_init initialization and inflexible xfs_buf_item_zone References: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> <43BA04AF.2060703@agami.com> In-Reply-To: <43BA04AF.2060703@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7166 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: tes@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 4247 Lines: 100 Hi Shailendra, Thanks for the report. Shailendra Tripathi wrote: > 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); > > Yes I agree, that the map_size is going to be unnecessarily large (potentially by 1). where N = number of total bits in map = number of 128 byte chunks ("chunks") and n = number of bits in an int ("NBWORD") map_size = ((N + (n-1))/n) number of ints The existing calculation of ((N + n)/n) will be wrong when N is a multiple of n, it will go over by 1. i.e. it will be wrong when N is a multiple of 32. The question, however, is if this will cause a problem and not just a slight waste of space. Some concerns that spring to mind: 1) Will the allocation of space for the blf_data_map be matched by the accesses of the map? The allocation size is set in the setting up of the xfs_buf_item_zone. It does this to: sizeof(xfs_buf_log_item_t) + XFS_MAX_BLOCK_SIZE / XFS_BLI_CHUNK / NBWORD * sizeof(int) = sizeof(xfs_buf_log_item_t) + 64K / 128 / 32 * 4 And this basically sizes it for a buffer of the largest block (64K) and for 1 extra in xfs_buf_log_item_t's blf_data_map[1]. So we do seem to actually cater for 1 extra here. And so the accesses which use xfs_next_bit & blf_map_size when they go over what covers the buffer, they will not go over the zone limit. 2) Will the oversized map cause us to access beyond the buffer and its pages? Well, looking at xfs_buf_item_format() and xfs_buf_item_size(), they call upon xfs_buf_offset(). However, it looks like they would do so only for a bit in the map which was turned on (1). And the extra bits at the end of the map will be zeroed at xfs_buf_item_init() stage using kmem_zone_zalloc(). And should never be turned on by xfs_buf_item_log() as the byte offsets given would always be within the buffer. So I think xfs_next_bit() will just scan over these final zeroes and then return -1. But maybe I've missed something? > 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. > > I'm not that au fait with the page buf code. But I do not understand your page alignment concern. The map is just storing which parts of the buffer (down to a 128 byte level) need to be logged. (During xfs_buf_item_format() when it transforms the map into vectors it will look up the regions to see if the adjacent bits are actually contiguous (and not in another page for example) and if not then it will use an extra vector) > 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. > But I would think it won't overstep because this extra end part of the map will be zeroed out. Have I missed something? Thanks muchly, Tim. From owner-linux-xfs@oss.sgi.com Wed Jan 11 05:01:12 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Jan 2006 05:01:18 -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 k0BD18m2013159 for ; Wed, 11 Jan 2006 05:01:12 -0800 Received: from agami.com ([192.168.168.102]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k0BB49AS009111 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 11 Jan 2006 03:04:09 -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 k0BB44L5024691 for ; Wed, 11 Jan 2006 03:04:04 -0800 Received: from [192.168.0.207] ([10.123.200.1]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jan 2006 03:04:01 -0800 Message-ID: <43C4E52F.4040306@agami.com> Date: Wed, 11 Jan 2006 16:29:59 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Shimmin CC: linux-xfs@oss.sgi.com Subject: Re: Unexpected xfs_buf_item_init initialization and inflexible xfs_buf_item_zone References: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> <43BA04AF.2060703@agami.com> <43C4BFAF.1060507@sgi.com> In-Reply-To: <43C4BFAF.1060507@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jan 2006 11:04:01.0829 (UTC) FILETIME=[BA9F6550:01C6169E] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7168 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: 6780 Lines: 147 Hi Tim, Thanks so much for the response. Comments inlined. > Yes I agree, that the map_size is going to be unnecessarily large > (potentially by 1). > where N = number of total bits in map = number of 128 byte chunks > ("chunks") > and n = number of bits in an int ("NBWORD") > map_size = ((N + (n-1))/n) number of ints > > The existing calculation of ((N + n)/n) will be wrong when N is a > multiple of n, > it will go over by 1. i.e. it will be wrong when N is a multiple of 32. > The question, however, is if this will cause a problem and not just > a slight waste of space. Given that the chunks calculation relies on buf count (not on page count), this extra addition appears mandatory. So, it appears that it has been intentionally set to extra one to compensate its usage along with buf count. If non-aligned (non 4k aligned) request for full 64K buffer comes in xfs_trans_read_buf, the buffer actually created may be of higher size as buffers are created in multiples of PAGE_SIZE (4k). For example, if xfs_buf_get_flags gets ioff= 2K, and length is 16 blocks(4k), the buffer created will be of 17 pages. Hence, the dirtied chunks can be in 17th page as well. The chunks calculated here should be for complete buffer (not the allocation request) as this is what logging code will finally see (it does not know the original request) and the maps will account for the complete buffer (first 2k as well). However, chunks & map calculated using buf count will only suffice for 16 pages. This forces to have the map_size off by 1. chunks = (int)((XFS_BUF_COUNT(bp) + (XFS_BLI_CHUNK - 1)) >> XFS_BLI_SHIFT); map_size = (int)((chunks + NBWORD) >> BIT_TO_WORD_SHIFT); Isn't understanding this will be far more easier if (and logically more correct?) if it would have been chunks = (int)((XFS_PAGE_COUNT(bp) (XFS_BLI_CHUNK - 1)) >> XFS_BLI_SHIFT); and map_size = (int)((chunks + NBWORD -1) >> BIT_TO_WORD_SHIFT); I realize now the current code is correct, however, it took me a while to figure out this indirect relation. When I changed the map_size calculation to correct it, I got "unable to handle page request" because of the above chunks calculation. And, the second part which I was interested to know was (not very clear in my mail) as to where from this XFS_MAX_BLOCKSIZE comes and how buf log item code is dependent upon this. I am unable to get the correlation between this size and the max buffer size. To be precise, can I figure what is the maximum size of a buf item which can be created with the block size of 4k (or what is the maximum number of pages which can be dirtied in any transaction in worst case). If it is dependent upon blocksize, why not to make the buf_item_zone initialization dependent upon the blocksize someway to avoid the wastage of space. It is really significant if the number of inodes supported on the system is high. (If it can be avoided, it can be an icing on cake). 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"); I also need to know this because I have changed the size of the inode allocated at once from 64 inodes to full stripe width allocation. I noticed that I have been crossing the 16 + 1 page limit. I allocate an ad hoc higher number to avoid this. This creates more wastage of space. Alternatively, I will have to go for dynamic allocation of maps which may be costlier as the comment above this initialization says so. -shailendra > Some concerns that spring to mind: > > 1) Will the allocation of space for the blf_data_map be matched by the > accesses > of the map? > The allocation size is set in the setting up of the xfs_buf_item_zone. > It does this to: > sizeof(xfs_buf_log_item_t) + XFS_MAX_BLOCK_SIZE / XFS_BLI_CHUNK / > NBWORD * sizeof(int) > = sizeof(xfs_buf_log_item_t) + 64K / 128 / 32 * 4 > And this basically sizes it for a buffer of the largest block (64K) and > for 1 extra in xfs_buf_log_item_t's blf_data_map[1]. > So we do seem to actually cater for 1 extra here. > And so the accesses which use xfs_next_bit & blf_map_size when they go over > what covers the buffer, they will not go over the zone limit. > > 2) Will the oversized map cause us to access beyond the buffer and its > pages? > Well, looking at xfs_buf_item_format() and xfs_buf_item_size(), they call > upon xfs_buf_offset(). However, it looks like they would do so only for > a bit > in the map which was turned on (1). And the extra bits at the end of the > map > will be zeroed at xfs_buf_item_init() stage using kmem_zone_zalloc(). > And should never be turned on by xfs_buf_item_log() as the byte offsets > given would always be within the buffer. > So I think xfs_next_bit() will just scan over these final zeroes and then > return -1. > But maybe I've missed something? > >> 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. >> >> > > I'm not that au fait with the page buf code. > But I do not understand your page alignment concern. The map is just > storing > which parts of the buffer (down to a 128 byte level) need to be logged. > (During xfs_buf_item_format() when it transforms the map into vectors it > will look up the regions to see if the adjacent bits are actually > contiguous (and not in another page for example) > and if not then it will use an extra vector) > >> 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. >> > > But I would think it won't overstep because this extra end part of the > map will > be zeroed out. > Have I missed something? > > Thanks muchly, > Tim. From owner-linux-xfs@oss.sgi.com Wed Jan 11 14:58:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Jan 2006 14:58:07 -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 k0BMw2m2017561 for ; Wed, 11 Jan 2006 14:58:03 -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 JAA14200; Thu, 12 Jan 2006 09:59:01 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8C01348757E7; Thu, 12 Jan 2006 09:59:00 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 947953 - fix follow_link Message-Id: <20060111225900.8C01348757E7@chook.melbourne.sgi.com> Date: Thu, 12 Jan 2006 09:59:00 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7169 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: 679 Lines: 17 Fix follow_link when dealing with symlinks larger than 256 bytes. Thanks to Yamamoto Takashi. Date: Thu Jan 12 09:58:38 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-linux Inspected by: yamamoto@valinux.co.jp The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-kern/xfs-linux-melb Modid: xfs-linux-melb:xfs-kern:24962a linux-2.6/xfs_iops.c - 1.235 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.235&r2=text&tr2=1.234&f=h linux-2.4/xfs_iops.c - 1.217 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.4/xfs_iops.c.diff?r1=text&tr1=1.217&r2=text&tr2=1.216&f=h From owner-linux-xfs@oss.sgi.com Wed Jan 11 21:39:43 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 11 Jan 2006 21:39:51 -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 k0C5dhm2012556 for ; Wed, 11 Jan 2006 21:39:43 -0800 Received: from flecktone.americas.sgi.com (flecktone.americas.sgi.com [198.149.16.15]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k0C5esxT030281 for ; Wed, 11 Jan 2006 23:40:54 -0600 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 k0C5esDN23609507 for ; Wed, 11 Jan 2006 23:40:54 -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 k0C5eskp437660 for ; Wed, 11 Jan 2006 23:40:54 -0600 (CST) Date: Wed, 11 Jan 2006 23:40:54 -0600 (CST) From: Eric Sandeen X-X-Sender: sandeen@penguin.americas.sgi.com To: linux-xfs@oss.sgi.com Subject: [ANNOUNCE] new xfs userspace on oss.sgi.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7170 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: 4641 Lines: 117 It's that random time of year again, when we push out the latest userspace for xfs :) Everything has updates this time: acl-2.2.34 attr-2.4.27 dmapi-2.2.3 xfsdump-2.2.33 xfsprogs-2.7.10 Changes since last push follow: ==> ./acl/doc/CHANGES <== 2.2.34 (05 December 2005) * Debian packaging updates 2.2.33 (10 November 2005) * Sync up build system (m4 macros, etc) with other projects * Update SGI copyright/licence notices ==> ./attr/doc/CHANGES <== attr-2.4.27 (05 December 2005) - Revert xattr.h/attributes.h to stating "Lesser GPL", accidentally marked "GPL" in previous version. attr-2.4.26 (10 November 2005) - Sync up build system (m4 macros, etc) with other projects - Update SGI copyright/licence notices attr-2.4.25 (11 October 2005) - Add French translation from the debian-l10n-french folks (thanks to Guilhelm Panaget) ==> ./dmapi/doc/CHANGES <== dmapi-2.2.3 (21 November 2005) - Make use of getdents64 instead of plain getdents. - Remove remaining uses of Linux kernel types to resolve some build issues with newer versions of XFS headers. dmapi-2.2.2 (10 November 2005) - Sync up build system (m4 macros, etc) with other projects - Update SGI copyright/licence notices ==> ./xfsdump/doc/CHANGES <== xfsdump-2.2.33 (16 December 2005) - Add option to allow dump time to be overridden. Useful if doing incremental dumps of snapshots. Thanks to David Brown. xfsdump-2.2.32 (29 November 2005) - Dump and restore project ids and project quotas. - Remove xfsdq(8) and xfsrq(8); use xfs_quota(8) to dump and restore quotas now. - Fix the setting of extended inode flags during restore. Some flags must be set before writing file data, and others must be set after writing file data and extended attributes. xfsdump-2.2.31 (10 November 2005) - Sync up build system (m4 macros, etc) with other projects - Update SGI copyright/licence notices ==> ./xfsprogs/doc/CHANGES <== xfsprogs-2.7.10 (16 December 2005) - Make xfs_db keep trying when root inode can't be read. - Make xfs_db check AGF BNO and CNT btree consistency. - Tweak a couple of libxfs headers so they can be used by C++ programs (removes nested struct declarations, which are used outside the scope they're declared in). - Fix a rounding issue in xfs_quota time reporting, making it more consistent with the standard quota utilities. - Fix dopey libxfs message "Unmount and run xfs_repair.", especially annoying when printed by xfs_repair itself. - Fix a dir2 xfs_repair bug, misdiagnosing a valid dir as corrupt. Thanks to Masanori Tsuda. xfsprogs-2.7.9 (08 December 2005) - Fix thinko in libxcmd cvtnum routine - Fix EFI/EFD printing in xfs_logprint xfsprogs-2.7.8 (05 December 2005) - Extend xfs_io to do aligned direct IO automatically - Report direct IO parameters (dioinfo) in xfs_io - Make xfs_mkfile a shell script wrapper around xfs_io xfsprogs-2.7.7 (16 November 2005) - Fix some gcc compiler warnings on 64 bit platforms. - Remove last reference to a (kernel) header. - Updated aclocal.m4 - Fix a bug in xfs_io lsproj/chproj recursive modes. - Add xfs_io recursive modes for the extsize command. - Add xfs_db version command modes for attr1 and attr2. xfsprogs-2.7.6 (31 October 2005) - Add support for the inode extent size hint for the regular data device (previously was realtime only), and allow the optional inheritance of this property. - Add support for additional read/write patterns in xfs_io (reverse and random, in addition to sequential forwards). - Add some mkfs debugging options to aid testing inheritance of realtime, project ID, and extsize inode attributes. - Add mkfs option for forcing use of ATTR2, and make growfs report its use. - Fix use of cursor in attr_list_by_handle() libhandle code. - Fix several compiler warnings when building on IRIX. xfsprogs-2.7.5 (26 October 2005) - Fix an endian bug in xfs_db "frag" command. - Fix some errors on the xfs_quota(8) man page. xfsprogs-2.7.4 (08 October 2005) - Fix read and write calls in xfs_io to allow buffers larger than 4GiB on 64 bit platforms. - FreeBSD build tweaks from Craig Rodrigues. - Fixed a few minor compiler warnings. From owner-linux-xfs@oss.sgi.com Thu Jan 12 00:02:00 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Jan 2006 00:02:02 -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 k0C81um2022759 for ; Thu, 12 Jan 2006 00:02:00 -0800 Received: from agami.com ([192.168.168.102]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k0C836AS019356 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Thu, 12 Jan 2006 00:03:07 -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 k0C831L5005822 for ; Thu, 12 Jan 2006 00:03:01 -0800 Received: from [192.168.0.207] ([10.123.200.1]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jan 2006 00:03:00 -0800 Message-ID: <43C60C44.3080007@agami.com> Date: Thu, 12 Jan 2006 13:29:00 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Shimmin CC: linux-xfs@oss.sgi.com Subject: Re: Unexpected xfs_buf_item_init initialization and inflexible xfs_buf_item_zone References: <14BC3454F4B4614FBC4F3FB19A84C372050C5F@FPNYEXCBE01.opus-i.corp> <43BA04AF.2060703@agami.com> <43C4BFAF.1060507@sgi.com> In-Reply-To: <43C4BFAF.1060507@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jan 2006 08:03:00.0726 (UTC) FILETIME=[9B505960:01C6174E] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7171 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: 5565 Lines: 139 Hi Tim, I figured out the max_buf_len. It is limited to the max(XFS_INODE_CLUSTER_SIZE, blocksize) which will be always 2 blocks/pages for filesystem created with blocksize 4k on linux. I added small code and recorded the 8192 such entries and they confirmed the same (gdb) p xfs_max_buf_len $1 = 2 (gdb) p xfs_buf_len (number of pages dirtied) $2 = {1 , 2, 2, 2, 2, 1 , 2, 2, 2, 2, 1 , 2, 2, 2, 2, 1 , 2, 2, 2, 2, 1 , 2, 2, 2, 2, 1 , 2, 2, 2, 2, 1 , 2, 2, 2, 2, 1 , 2, 2, 2, 2, 1 , 2, 2, 2, 2, 1 } From this, it does appear that 60 bytes are wasted per transactionally active inode by xfs_buf_item_zone which can be potentially saved though at the cost of one inflexibility - one system potentially can't have a filesystem of different blocksizes. On linux, 4k seems to be default and not sure if it is really a point of concern if it is changed. Any comments ? Regards, Shailendra Timothy Shimmin wrote: > Hi Shailendra, > > Thanks for the report. > > Shailendra Tripathi wrote: > >> 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); >> >> > > Yes I agree, that the map_size is going to be unnecessarily large > (potentially by 1). > where N = number of total bits in map = number of 128 byte chunks > ("chunks") > and n = number of bits in an int ("NBWORD") > map_size = ((N + (n-1))/n) number of ints > > The existing calculation of ((N + n)/n) will be wrong when N is a > multiple of n, > it will go over by 1. i.e. it will be wrong when N is a multiple of 32. > The question, however, is if this will cause a problem and not just > a slight waste of space. > > Some concerns that spring to mind: > > 1) Will the allocation of space for the blf_data_map be matched by the > accesses > of the map? > The allocation size is set in the setting up of the xfs_buf_item_zone. > It does this to: > sizeof(xfs_buf_log_item_t) + XFS_MAX_BLOCK_SIZE / XFS_BLI_CHUNK / > NBWORD * sizeof(int) > = sizeof(xfs_buf_log_item_t) + 64K / 128 / 32 * 4 > And this basically sizes it for a buffer of the largest block (64K) and > for 1 extra in xfs_buf_log_item_t's blf_data_map[1]. > So we do seem to actually cater for 1 extra here. > And so the accesses which use xfs_next_bit & blf_map_size when they go over > what covers the buffer, they will not go over the zone limit. > > 2) Will the oversized map cause us to access beyond the buffer and its > pages? > Well, looking at xfs_buf_item_format() and xfs_buf_item_size(), they call > upon xfs_buf_offset(). However, it looks like they would do so only for > a bit > in the map which was turned on (1). And the extra bits at the end of the > map > will be zeroed at xfs_buf_item_init() stage using kmem_zone_zalloc(). > And should never be turned on by xfs_buf_item_log() as the byte offsets > given would always be within the buffer. > So I think xfs_next_bit() will just scan over these final zeroes and then > return -1. > But maybe I've missed something? > >> 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. >> >> > > I'm not that au fait with the page buf code. > But I do not understand your page alignment concern. The map is just > storing > which parts of the buffer (down to a 128 byte level) need to be logged. > (During xfs_buf_item_format() when it transforms the map into vectors it > will look up the regions to see if the adjacent bits are actually > contiguous (and not in another page for example) > and if not then it will use an extra vector) > >> 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. >> > > But I would think it won't overstep because this extra end part of the > map will > be zeroed out. > Have I missed something? > > Thanks muchly, > Tim. > From owner-linux-xfs@oss.sgi.com Thu Jan 12 00:36:24 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Jan 2006 00:36:28 -0800 (PST) Received: from gold.veritas.com (gold.veritas.com [143.127.12.110]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0C8aOm2029017 for ; Thu, 12 Jan 2006 00:36:24 -0800 Received: from sxchcon2-int.veritas.com (HELO SVLXCHCON2.enterprise.veritas.com) ([10.137.18.172]) by gold.veritas.com with ESMTP; 11 Jan 2006 23:03:23 -0800 Received: from itpxchmb2.enterprise.veritas.com ([10.216.17.1]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 11 Jan 2006 23:03:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 MIME-Version: 1.0 Subject: regarding xfs.. Date: Thu, 12 Jan 2006 12:32:38 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: regarding xfs.. Thread-Index: AcYXRfpts28Q8NzqRceAik+wgGmGdQ== From: "Bhaskar Singhal" To: X-OriginalArrivalTime: 12 Jan 2006 07:03:25.0100 (UTC) FILETIME=[48131EC0:01C61746] Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7172 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: bhaskar_singhal@symantec.com Precedence: bulk X-list: linux-xfs Content-Length: 983 Lines: 73 Hi, I am trying to perform split of a logical volume with xfs on it. Split goes thru but I am not able to mount the mirror or the cow. For eg: I have a logical volume /dev/mapper/volgp01-vol01 Mkfs -t xfs /dev/mapper/volgp01-vol01 Mount /dev/mapper/volgp01-vol01 /testmount To perform split. Xfs_freeze -f /testmount Split /dev/mapper/volgp01-vol01 We get /dev/mapper/volgp01-vol01Snap001 /dev/mapper/volgp01-vol01Snap001-cow Now on trying Mount /dev/mapper/volgp01-vol01Snap001 /testmount_alt Mount: wrong fstype, bad option, bad super block, on /dev/mapper/volgp01-vol01Snap001 or too many file system mounted I also tried Mount /dev/mapper/volgp01-vol01Snap001-cow /testmount_alt Mount:/dev/mapper/volgp01-vol01Snap001-cow already mounted or /testmount_alt is busy (/testmount_alt is not busy which I checked). Please let me know where I am missing something. Thanks & Regards Bhaskar [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 12 07:28:55 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Jan 2006 07:29: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 k0CFSsm2032745 for ; Thu, 12 Jan 2006 07:28:54 -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 k0CHe3PT030113 for ; Thu, 12 Jan 2006 09:40:04 -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 k0CFT2DN23633133; Thu, 12 Jan 2006 09:29:02 -0600 (CST) Message-ID: <43C675BE.60201@sgi.com> Date: Thu, 12 Jan 2006 09:29:02 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bhaskar Singhal CC: linux-xfs@oss.sgi.com Subject: Re: regarding xfs.. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7173 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: 373 Lines: 14 Bhaskar Singhal wrote: > Now on trying > > Mount /dev/mapper/volgp01-vol01Snap001 /testmount_alt > > Mount: wrong fstype, bad option, bad super block, on > /dev/mapper/volgp01-vol01Snap001 or too many file system mounted > See what the kernel actually said on this failure, for starters. The userspace error is not useful, it's just a generic error message. -Eric From owner-linux-xfs@oss.sgi.com Thu Jan 12 07:36:30 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Jan 2006 07:36:31 -0800 (PST) Received: from silver.veritas.com (silver.veritas.com [143.127.12.111]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0CFaUm2000928 for ; Thu, 12 Jan 2006 07:36:30 -0800 Received: from sxchcon2-int.veritas.com (HELO SVLXCHCON2.enterprise.veritas.com) ([10.137.18.172]) by silver.veritas.com with ESMTP; 12 Jan 2006 07:37:37 -0800 Received: from itpxchmb2.enterprise.veritas.com ([10.216.17.1]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 12 Jan 2006 07:37:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: regarding xfs.. Date: Thu, 12 Jan 2006 21:07:19 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: regarding xfs.. Thread-Index: AcYXjO/ppI1s7x7BQcWTTciQL/wabQAAL5pw From: "Bhaskar Singhal" To: "Eric Sandeen" Cc: X-OriginalArrivalTime: 12 Jan 2006 15:37:24.0530 (UTC) FILETIME=[15CEB120:01C6178E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k0CFaUm2000936 X-archive-position: 7174 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: bhaskar_singhal@symantec.com Precedence: bulk X-list: linux-xfs Content-Length: 748 Lines: 33 Hi Eric, Thanks, but I got the solution. I should actually try to mount with option nouuid i.e. Mount -o nouuid dev/mapper/volgp01-vol01Snap001 /testmount_alt This works. -bhaskar -----Original Message----- From: Eric Sandeen [mailto:sandeen@sgi.com] Sent: Thursday, January 12, 2006 8:59 PM To: Bhaskar Singhal Cc: linux-xfs@oss.sgi.com Subject: Re: regarding xfs.. Bhaskar Singhal wrote: > Now on trying > > Mount /dev/mapper/volgp01-vol01Snap001 /testmount_alt > > Mount: wrong fstype, bad option, bad super block, on > /dev/mapper/volgp01-vol01Snap001 or too many file system mounted > See what the kernel actually said on this failure, for starters. The userspace error is not useful, it's just a generic error message. -Eric From owner-linux-xfs@oss.sgi.com Thu Jan 12 07:42:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Jan 2006 07:42: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 k0CFg4m2001756 for ; Thu, 12 Jan 2006 07:42:04 -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 k0CFhExT014673 for ; Thu, 12 Jan 2006 09:43:15 -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 k0CFhDQT29044820; Thu, 12 Jan 2006 09:43:14 -0600 (CST) Message-ID: <43C67911.2060908@sgi.com> Date: Thu, 12 Jan 2006 09:43:13 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bhaskar Singhal CC: linux-xfs@oss.sgi.com Subject: Re: regarding xfs.. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7175 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: 414 Lines: 18 Bhaskar Singhal wrote: > Hi Eric, > > Thanks, but I got the solution. > > I should actually try to mount with option nouuid i.e. > Mount -o nouuid dev/mapper/volgp01-vol01Snap001 /testmount_alt > > This works. > > -bhaskar Yep, that was my guess. There's been talk about removing the uuid checking, but we need to be sure that some other sgi products won't be unhappy with duplicate uuids first... -Eric From owner-linux-xfs@oss.sgi.com Thu Jan 12 15:17:24 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Jan 2006 15:17:25 -0800 (PST) Received: from uproxy.gmail.com (uproxy.gmail.com [66.249.92.192]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0CNHNm2001892 for ; Thu, 12 Jan 2006 15:17:24 -0800 Received: by uproxy.gmail.com with SMTP id j3so279554ugf for ; Thu, 12 Jan 2006 15:18: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:content-transfer-encoding:content-disposition; b=GUFEcBcjZDeFqSsvcKOftDyFsCJW5faLsFFVYF9WJNfz9L/eLGBWOwU3vU2WB7Npxqw/tqj6TQMaL7s/SPLHYCbng13xKR/K5FTNG0CM7L8Mqb4hG+y0319zZHA+0Kz8qGFGp8mdS6DgLvhXvvgH1d0qs/21/btLgKW7RPwQ4aQ= Received: by 10.49.17.20 with SMTP id u20mr18131nfi; Thu, 12 Jan 2006 13:45:03 -0800 (PST) Received: by 10.48.243.9 with HTTP; Thu, 12 Jan 2006 13:45:03 -0800 (PST) Message-ID: <596b75860601121345i3a4a9629m37cbde23b058bc0c@mail.gmail.com> Date: Thu, 12 Jan 2006 14:45:03 -0700 From: Kyle Sallee To: linux-xfs@oss.sgi.com Subject: Source tarballs where please? 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 k0CNHOm2001897 X-archive-position: 7177 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: kyle.sallee@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 220 Lines: 8 Where does one download the source tarballs for attr-2.4.24.src.tar.gz and other XFS releated tarballs or a more current version please? Please reply directly since I am not subscribed to this email list. Thanks, Kyle From owner-linux-xfs@oss.sgi.com Thu Jan 12 15:59:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 12 Jan 2006 15:59:06 -0800 (PST) Received: from larry.melbourne.sgi.com ([61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0CNx2m2004826 for ; Thu, 12 Jan 2006 15:59:03 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA19090; Fri, 13 Jan 2006 10:59:59 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0D00Akt8330459; Fri, 13 Jan 2006 11:00:11 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id k0CNvxx7001268; Fri, 13 Jan 2006 10:58:00 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id k0CNvv1w001266; Fri, 13 Jan 2006 10:57:57 +1100 Date: Fri, 13 Jan 2006 10:57:57 +1100 From: Nathan Scott To: Kyle Sallee Cc: linux-xfs@oss.sgi.com Subject: Re: Source tarballs where please? Message-ID: <20060112235757.GA1234@frodo> References: <596b75860601121345i3a4a9629m37cbde23b058bc0c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <596b75860601121345i3a4a9629m37cbde23b058bc0c@mail.gmail.com> User-Agent: Mutt/1.5.3i X-archive-position: 7178 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: 259 Lines: 10 On Thu, Jan 12, 2006 at 02:45:03PM -0700, Kyle Sallee wrote: > Where does one download the source tarballs for > attr-2.4.24.src.tar.gz and other XFS releated tarballs > or a more current version please? ftp://oss.sgi.com/projects/xfs/cmd_tars/ -- Nathan From owner-linux-xfs@oss.sgi.com Fri Jan 13 00:06:52 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 13 Jan 2006 00:06:53 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0D86pm2000521 for ; Fri, 13 Jan 2006 00:06:52 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 5903E2800BF; Fri, 13 Jan 2006 00:10:48 -0600 (CST) Message-ID: <43C74466.4010700@sgi.com> Date: Fri, 13 Jan 2006 00:10:46 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott Cc: Kyle Sallee , linux-xfs@oss.sgi.com Subject: Re: Source tarballs where please? References: <596b75860601121345i3a4a9629m37cbde23b058bc0c@mail.gmail.com> <20060112235757.GA1234@frodo> In-Reply-To: <20060112235757.GA1234@frodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7179 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: 425 Lines: 16 Nathan Scott wrote: > On Thu, Jan 12, 2006 at 02:45:03PM -0700, Kyle Sallee wrote: > >>Where does one download the source tarballs for >>attr-2.4.24.src.tar.gz and other XFS releated tarballs >>or a more current version please? > > > ftp://oss.sgi.com/projects/xfs/cmd_tars/ > My mistake, sorry - copied tar.gz files which the normal universe uses for source packages, but now the src.tar.gz files are there :) -Eric From owner-linux-xfs@oss.sgi.com Sat Jan 14 10:59:46 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Jan 2006 10:59:51 -0800 (PST) Received: from mail.ait.gr (mail.ait.gr [193.201.22.3]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0EIxim2002324 for ; Sat, 14 Jan 2006 10:59:45 -0800 Received: from mail.ait.gr ([127.0.0.1]) by mail.ait.gr (8.12.11/8.11.6) with ESMTP id k0EI1k4R004332 for ; Sat, 14 Jan 2006 20:01:46 +0200 (EET) Received: from webmail.ait.gr (webmail.ait.gr [193.201.22.7]) by mail.ait.gr (8.12.11/8.11.6) with SMTP id k0EI1jYm004329 for ; Sat, 14 Jan 2006 20:01:46 +0200 (EET) Received: from ppp29-adsl-27.ath.forthnet.gr ([62.1.240.27]) (SquirrelMail authenticated user vmil) by webmail.ait.gr with HTTP; Sat, 14 Jan 2006 20:01:46 +0200 (EET) Message-ID: <2067.62.1.240.27.1137261706.squirrel@webmail.ait.gr> Date: Sat, 14 Jan 2006 20:01:46 +0200 (EET) Subject: xfs problem From: vmil@ait.edu.gr To: linux-xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-archive-position: 7180 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: vmil@ait.edu.gr Precedence: bulk X-list: linux-xfs Content-Length: 503 Lines: 11 I have a machine with debian that is running 2.6.13 kernel without any problem. I am trying to migrate to 2.6.15. I copied the .config file and without doing any significant changes (just added the fuser mount) I compiled the kernel with xfs build inside the kernel as before and rebooted. The system couldn't boot and I received a kernel panic message. the last lines of the output where: XFS: bad magic number XFS: SB validate failed The previous kernel continues to boot just fine. Any suggestion? From owner-linux-xfs@oss.sgi.com Sat Jan 14 16:55:46 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Jan 2006 16:55:52 -0800 (PST) Received: from web36404.mail.mud.yahoo.com (web36404.mail.mud.yahoo.com [209.191.85.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0F0tkm2003850 for ; Sat, 14 Jan 2006 16:55:46 -0800 Received: (qmail 14361 invoked by uid 60001); 14 Jan 2006 23:56:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=bp6Jb/9J320j4HtqaMoa+2T4KYzKxbkn+dKjhRaJYyEwj8/NI1b9PGUBY6RG03hSZZ4MAS89//+WwY661PTK2KtYEyq/NdnAZK+5wgyTEcMKxEKQGL5DsHttJY1o3w+V+JmKNXq5I98XHA3dv0Lowa+fd0BG0JHk++TK6cQpvSc= ; Message-ID: <20060114235656.14359.qmail@web36404.mail.mud.yahoo.com> Received: from [68.232.131.147] by web36404.mail.mud.yahoo.com via HTTP; Sat, 14 Jan 2006 15:56:56 PST Date: Sat, 14 Jan 2006 15:56:56 -0800 (PST) From: Robert Thralls Subject: mkswap'ed an xfs partition To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-archive-position: 7181 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: rob_thralls@yahoo.com Precedence: bulk X-list: linux-xfs Content-Length: 601 Lines: 16 I typed "mkswap /dev/hda4" instead of "mkswap /dev/sda4" and applied it to = an xfs storage partition! I have no experience repairing xfs. I have not mo= unted or done anything else with this partition yet. Is there a way to rec= over everything or at least a list of everything that was lost? Could I ju= st do a "mkfs.xfs /dev/hda4" and pretend it never happened? =20 kernel 2.6.15, gentoo, xfsprogs-2.6.25 =20 =09=09 --------------------------------- Yahoo! Photos =96 Showcase holiday pictures in hardcover Photo Books. You design it and we=92ll bind it! [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Sat Jan 14 17:18:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Jan 2006 17:18:44 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0F1Igm2005961 for ; Sat, 14 Jan 2006 17:18:42 -0800 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id k0F0Bm8g004025 for ; Sat, 14 Jan 2006 16:11:49 -0800 Message-ID: <43C99344.9000502@tlinx.org> Date: Sat, 14 Jan 2006 16:11:48 -0800 From: "L. A. Walsh" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en, en_US MIME-Version: 1.0 To: Linux-Xfs Subject: is this list or project still alive? comments on latest benchmarks? Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7182 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1047 Lines: 25 This is a multi-pronged email..., sorta... Haven't seen any email from this list since 12/15/05. Is this list still alive? Is the xfs project still alive? Also was wondering if there were any comments on the recent benchmarks mentioned on "slashdot" where xfs showed up last by minor amounts in almost all areas. The differences were minor, but notable for bean counters -- was it a bad test or bad configuration for xfs or are development resources being spent on the other filesystems at too great an amount for xfs to keep pace? Are there still reasons why one should stay with xfs other than warm fuzzies? Copying (using tar or cpio) a kernel tree seemed to be pretty file system stressful. XFS did seem to be lower on cpu usage in some of the tests compared to some of the higher performing filesystems, but the overall performance was frustrating (still being a firm xfs "fan"). Perhaps the others aren't up to speed in the extended attribute support yet? Anyway -- suppose I should see if this bounces or gets answered. -Linda From owner-linux-xfs@oss.sgi.com Sat Jan 14 17:23:44 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Jan 2006 17:23:49 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0F1Ndm2006820 for ; Sat, 14 Jan 2006 17:23:43 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id 6E7AB1A11DC63; Sat, 14 Jan 2006 20:24:47 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 6C621A0A42E6; Sat, 14 Jan 2006 20:24:47 -0500 (EST) Date: Sat, 14 Jan 2006 20:24:47 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: "L. A. Walsh" cc: Linux-Xfs Subject: Re: is this list or project still alive? comments on latest benchmarks? In-Reply-To: <43C99344.9000502@tlinx.org> Message-ID: References: <43C99344.9000502@tlinx.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7183 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: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 1703 Lines: 46 Your e-mail must be getting blocked, someone justed posted to list less than an hour ago. I still think XFS is the best file system, I've "heard" the following: 1) That JFS takes hours to fsck large filesystems. 2) That ReiserV3 has corrupted peoples files (I've seen this personally) 3) EXT3 also has some scalability issues. I use XFS on over > 15 disks and almost every time I had any problem it was an actual disk failure. XFS as you know is a little slow with deleting files, but that can be fixed. http://everything2.com/index.pl?node_id=1479435 Justin. On Sat, 14 Jan 2006, L. A. Walsh wrote: > This is a multi-pronged email..., sorta... > > Haven't seen any email from this list since 12/15/05. Is this list > still alive? > > Is the xfs project still alive? > > Also was wondering if there were any comments on the recent benchmarks > mentioned on "slashdot" where xfs showed up last by minor amounts > in almost all areas. The differences were minor, but notable for > bean counters -- was it a bad test or bad configuration for xfs > or are development resources being spent on the other filesystems > at too great an amount for xfs to keep pace? > Are there still reasons why one should stay with xfs other than > warm fuzzies? Copying (using tar or cpio) a kernel tree seemed to > be pretty file system stressful. XFS did seem to be lower on cpu > usage in some of the tests compared to some of the higher performing > filesystems, but the overall performance was frustrating (still being > a firm xfs "fan"). Perhaps the others aren't up to speed in the extended > attribute support yet? > Anyway -- suppose I should see if this bounces or gets answered. > -Linda > > From owner-linux-xfs@oss.sgi.com Sat Jan 14 18:33:01 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Jan 2006 18:33:12 -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 k0F2Wxm2012124 for ; Sat, 14 Jan 2006 18:33:00 -0800 Received: from mail.ocs.com.au (kao1.melbourne.sgi.com [134.14.55.179]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA12865 for ; Sun, 15 Jan 2006 12:27:34 +1100 Received: from ocs3.ocs.com.au (ocs3.ocs.com.au [192.168.255.3]) by mail.ocs.com.au (Postfix) with ESMTP id D1CDDE0B206; Sun, 15 Jan 2006 12:27:30 +1100 (EST) Received: by ocs3.ocs.com.au (Postfix, from userid 16331) id 9573FEAF; Sun, 15 Jan 2006 12:27:30 +1100 (EST) Received: from ocs3.ocs.com.au (localhost [127.0.0.1]) by ocs3.ocs.com.au (Postfix) with ESMTP id 6E98580180; Sun, 15 Jan 2006 12:27:30 +1100 (EST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.1-RC1 From: Keith Owens To: Jan Engelhardt cc: Bernd Eckenfels , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Quota on xfs vfsroot In-reply-to: Your message of "Sat, 14 Jan 2006 10:35:34 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 15 Jan 2006 12:27:30 +1100 Message-ID: <30975.1137288450@ocs3.ocs.com.au> X-archive-position: 7184 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 712 Lines: 17 Jan Engelhardt (on Sat, 14 Jan 2006 10:35:34 +0100 (MET)) wrote: > >>> the xfs_quota manpage says that one needs to use the "root-flags=" boot >>> parameter to enable quota for the root filesystem, but I do not see a >>> matching __setup() definition anywhere in the fs/xfs/ folder. So, how do I >>> have quota activated then? >> >>init/do_mounts.c:__setup("rootflags=", root_data_setup); >>It is a general boot line flag, not xfs specific. > >Ah, thank you. >Weird manpage program wrapped rootflags into "root-\nflags" at EOL, sigh. One of the many reasons that man pages should have hyphenation turned off. In current *roff, the command is '.nh'. Some older versions of *roff used '.hy off' or '.hy 0'. From owner-linux-xfs@oss.sgi.com Sat Jan 14 22:40:30 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Jan 2006 22:40:33 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0F6eTm2030312 for ; Sat, 14 Jan 2006 22:40:29 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 2E58D2800BF; Sun, 15 Jan 2006 00:41:33 -0600 (CST) Message-ID: <43C9EE9B.7090502@sgi.com> Date: Sun, 15 Jan 2006 00:41:31 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Thralls Cc: linux-xfs@oss.sgi.com Subject: Re: mkswap'ed an xfs partition References: <20060114235656.14359.qmail@web36404.mail.mud.yahoo.com> In-Reply-To: <20060114235656.14359.qmail@web36404.mail.mud.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 7185 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: 858 Lines: 21 Robert Thralls wrote: > I typed "mkswap /dev/hda4" instead of "mkswap /dev/sda4" and applied it to an xfs storage partition! I have no experience repairing xfs. I have not mounted or done anything else with this partition yet. Is there a way to recover everything or at least a list of everything that was lost? Could I just do a "mkfs.xfs /dev/hda4" and pretend it never happened? > > kernel 2.6.15, gentoo, xfsprogs-2.6.25 > don't mkfs it! I -think- that mkswap just stamps a signature onto the front of the disk; I'm guessing that xfs_repair can recover from this. You could dd hda4 into an image file if you have room, to test it there first. -Eric > > --------------------------------- > Yahoo! Photos – Showcase holiday pictures in hardcover > Photo Books. You design it and we’ll bind it! > > [[HTML alternate version deleted]] > From owner-linux-xfs@oss.sgi.com Sat Jan 14 22:43:53 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Jan 2006 22:43:55 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0F6hrm2030696 for ; Sat, 14 Jan 2006 22:43:53 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 084112800BF; Sun, 15 Jan 2006 00:45:02 -0600 (CST) Message-ID: <43C9EF6D.6010001@sgi.com> Date: Sun, 15 Jan 2006 00:45:01 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vmil@ait.edu.gr Cc: linux-xfs@oss.sgi.com Subject: Re: xfs problem References: <2067.62.1.240.27.1137261706.squirrel@webmail.ait.gr> In-Reply-To: <2067.62.1.240.27.1137261706.squirrel@webmail.ait.gr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7186 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: 673 Lines: 18 vmil@ait.edu.gr wrote: > I have a machine with debian that is running 2.6.13 kernel without any > problem. I am trying to migrate to 2.6.15. I copied the .config file and > without doing any significant changes (just added the fuser mount) I > compiled the kernel with xfs build inside the kernel as before and > rebooted. The system couldn't boot and I received a kernel panic message. > the last lines of the output where: > XFS: bad magic number > XFS: SB validate failed > > The previous kernel continues to boot just fine. Any suggestion? > Hm, maybe check the bootloader config first, just to be sure you're mounting the right device...? Just a thought. -Eric From owner-linux-xfs@oss.sgi.com Sat Jan 14 23:46:40 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 14 Jan 2006 23:46:44 -0800 (PST) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0F7kem2002468 for ; Sat, 14 Jan 2006 23:46:40 -0800 Received: (qmail 99847 invoked from network); 15 Jan 2006 06:47:50 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.231.253.61 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 15 Jan 2006 06:47:50 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 2549851ED33; Sat, 14 Jan 2006 22:47:45 -0800 (PST) Date: Sat, 14 Jan 2006 22:47:45 -0800 From: Chris Wedgwood To: Robert Thralls Cc: linux-xfs@oss.sgi.com Subject: Re: mkswap'ed an xfs partition Message-ID: <20060115064745.GA16805@taniwha.stupidest.org> References: <20060114235656.14359.qmail@web36404.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060114235656.14359.qmail@web36404.mail.mud.yahoo.com> X-archive-position: 7187 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 641 Lines: 16 On Sat, Jan 14, 2006 at 03:56:56PM -0800, Robert Thralls wrote: > I typed "mkswap /dev/hda4" instead of "mkswap /dev/sda4" and applied > it to an xfs storage partition! I have no experience repairing > xfs. I have not mounted or done anything else with this partition > yet. Is there a way to recover everything or at least a list of > everything that was lost? Could I just do a "mkfs.xfs /dev/hda4" > and pretend it never happened? try xfs_repair presumably SB0 is intack (as I don't think swap uses this) if not it will scan for another one which should take a while hopefully this will get most if not all of your filesystem back From owner-linux-xfs@oss.sgi.com Sun Jan 15 01:53:14 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 01:53:21 -0800 (PST) Received: from pasmtp.tele.dk ([193.162.159.95]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0F9rDm2014271 for ; Sun, 15 Jan 2006 01:53:14 -0800 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id 978061EC320; Sun, 15 Jan 2006 10:54:12 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id ACFAF43C2C7; Sun, 15 Jan 2006 10:54:10 +0100 (CET) Date: Sun, 15 Jan 2006 10:54:10 +0100 From: Sam Ravnborg To: Andrey Borzenkov Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6: xfs is rebuilt on every .config change Message-ID: <20060115095410.GA8195@mars.ravnborg.org> References: <200601151226.49461.arvidjaar@mail.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200601151226.49461.arvidjaar@mail.ru> User-Agent: Mutt/1.5.11 X-archive-position: 7188 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: 876 Lines: 23 On Sun, Jan 15, 2006 at 12:26:46PM +0300, Andrey Borzenkov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This happened for a long time, actually in late 2.5.x (that I have started > with). Every time I make some changes to config - or simply do make oldconfig > - - xfs is rebuilt. This happens when there are *no* changes related to xfs > alltogether. E.g. I now applied 2.6.15.1 patch and xfs got rebuilt again. The xfs source files do: #include To gain access to actual kernel release. So each time you do a change to the tree that causes version.h to be updated the xfs source files will be recompiled. Note that version.h includes "UTS_NAME" - unfortunately. So you will see version.h being updated rather often if you have enabled the "Automatically append version information to the version string" in the "General Setup" menu. Sam From owner-linux-xfs@oss.sgi.com Sun Jan 15 02:32:29 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 02:32:35 -0800 (PST) Received: from mx4.mail.ru (fallback.mail.ru [194.67.57.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0FAWSm2016841 for ; Sun, 15 Jan 2006 02:32:29 -0800 Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 8278C822572 for ; Sun, 15 Jan 2006 12:27:10 +0300 (MSK) Received: from [83.237.61.49] (port=53168 helo=cooker.home.net) by mx3.mail.ru with asmtp id 1Ey4A6-000JD5-00; Sun, 15 Jan 2006 12:26:58 +0300 From: Andrey Borzenkov To: linux-xfs@oss.sgi.com Subject: 2.6: xfs is rebuilt on every .config change Date: Sun, 15 Jan 2006 12:26:46 +0300 User-Agent: KMail/1.9.1 Cc: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601151226.49461.arvidjaar@mail.ru> X-archive-position: 7189 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: arvidjaar@mail.ru Precedence: bulk X-list: linux-xfs Content-Length: 744 Lines: 23 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This happened for a long time, actually in late 2.5.x (that I have started with). Every time I make some changes to config - or simply do make oldconfig - - xfs is rebuilt. This happens when there are *no* changes related to xfs alltogether. E.g. I now applied 2.6.15.1 patch and xfs got rebuilt again. It may be nitpicking, but it is huge module, I have relatively slow system ans sometimes want to quickly test some trvial changes. xfs doubles compile time (at the very least). Regards - -andrey -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyhVZR6LMutpd94wRAufSAJkBc/y6KK5wkcyxVliZkuTYpdcn5QCgmovu xRdPIPFuQNbI+u3Bv+AI1hA= =cI9T -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Jan 15 05:15:07 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 05:15:20 -0800 (PST) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0FDF2m2028706 for ; Sun, 15 Jan 2006 05:15:07 -0800 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k0FCBVo3009220; Sun, 15 Jan 2006 13:11:34 +0100 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k0FCBVCA009214; Sun, 15 Jan 2006 13:11:31 +0100 Date: Sun, 15 Jan 2006 13:11:31 +0100 (MET) From: Jan Engelhardt To: Keith Owens cc: Bernd Eckenfels , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Quota on xfs vfsroot In-Reply-To: <30975.1137288450@ocs3.ocs.com.au> Message-ID: References: <30975.1137288450@ocs3.ocs.com.au> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1283855629-491261280-1137327091=:4174" X-archive-position: 7190 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: jengelh@linux01.gwdg.de Precedence: bulk X-list: linux-xfs Content-Length: 945 Lines: 27 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1283855629-491261280-1137327091=:4174 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT >>Ah, thank you. >>Weird manpage program wrapped rootflags into "root-\nflags" at EOL, sigh. > >One of the many reasons that man pages should have hyphenation turned >off. In current *roff, the command is '.nh'. Some older versions of >*roff used '.hy off' or '.hy 0'. The man program itself is very weird too - produces stylized ` and ' when utf8 is active, making it ‘ and ’, which breaks example code snippets. Manpages should rather opt-in for "fun stuff" like `' and hyphenation rather than opt-out. Oh well. Jan Engelhardt -- | Alphagate Systems, http://alphagate.hopto.org/ | jengelh's site, http://jengelh.hopto.org/ --1283855629-491261280-1137327091=:4174-- From owner-linux-xfs@oss.sgi.com Sun Jan 15 09:33:34 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 09:33:38 -0800 (PST) Received: from mx4.mail.ru ([194.67.57.14]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0FHXXm2014217 for ; Sun, 15 Jan 2006 09:33:34 -0800 Received: from mx3.mail.ru (mx3.mail.ru [194.67.23.149]) by mx4.mail.ru (mPOP.Fallback_MX) with ESMTP id 131E781CB31 for ; Sun, 15 Jan 2006 20:34:33 +0300 (MSK) Received: from [83.237.61.49] (port=15539 helo=cooker.home.net) by mx3.mail.ru with asmtp id 1EyBli-000Pcu-00; Sun, 15 Jan 2006 20:34:18 +0300 From: Andrey Borzenkov To: Sam Ravnborg Subject: Re: 2.6: xfs is rebuilt on every .config change Date: Sun, 15 Jan 2006 20:34:11 +0300 User-Agent: KMail/1.9.1 Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <200601151226.49461.arvidjaar@mail.ru> <20060115095410.GA8195@mars.ravnborg.org> In-Reply-To: <20060115095410.GA8195@mars.ravnborg.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200601152034.16467.arvidjaar@mail.ru> X-archive-position: 7191 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: arvidjaar@mail.ru Precedence: bulk X-list: linux-xfs Content-Length: 2434 Lines: 74 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 15 January 2006 12:54, Sam Ravnborg wrote: > On Sun, Jan 15, 2006 at 12:26:46PM +0300, Andrey Borzenkov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > This happened for a long time, actually in late 2.5.x (that I have > > started with). Every time I make some changes to config - or simply do > > make oldconfig - - xfs is rebuilt. This happens when there are *no* > > changes related to xfs alltogether. E.g. I now applied 2.6.15.1 patch and > > xfs got rebuilt again. > > The xfs source files do: > #include > To gain access to actual kernel release. > > So each time you do a change to the tree that causes version.h to be > updated the xfs source files will be recompiled. > Ah, thanks. Now the obvious question is, why in-tree code should bother with version checking? The patch removes version check and dependency on linux/version.h from xfs_dmapi.h. Signed-off-by: Andrey Borzenkov - --- linux-2.6.15/fs/xfs/xfs_dmapi.h.version_h 2006-01-03 06:21:10.000000000 +0300 +++ linux-2.6.15/fs/xfs/xfs_dmapi.h 2006-01-15 20:20:12.000000000 +0300 @@ -18,7 +18,6 @@ #ifndef __XFS_DMAPI_H__ #define __XFS_DMAPI_H__ - -#include /* Values used to define the on-disk version of dm_attrname_t. All * on-disk attribute names start with the 8-byte string "SGI_DMI_". * @@ -159,24 +158,9 @@ typedef enum { /* * Based on IO_ISDIRECT, decide which i_ flag is set. */ - -#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,0) #define DM_SEM_FLAG_RD(ioflags) (((ioflags) & IO_ISDIRECT) ? \ DM_FLAGS_ISEM : 0) #define DM_SEM_FLAG_WR (DM_FLAGS_IALLOCSEM_WR | DM_FLAGS_ISEM) - -#endif - - - -#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)) && \ - - (LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,22)) - -#define DM_SEM_FLAG_RD(ioflags) (((ioflags) & IO_ISDIRECT) ? \ - - DM_FLAGS_IALLOCSEM_RD : DM_FLAGS_ISEM) - -#define DM_SEM_FLAG_WR (DM_FLAGS_IALLOCSEM_WR | DM_FLAGS_ISEM) - -#endif - - - -#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,4,21) - -#define DM_SEM_FLAG_RD(ioflags) (((ioflags) & IO_ISDIRECT) ? \ - - 0 : DM_FLAGS_ISEM) - -#define DM_SEM_FLAG_WR (DM_FLAGS_ISEM) - -#endif /* -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDyoeYR6LMutpd94wRAskpAKCu/gV8aNZsX0+fqc9/5fXfQBujsACgjaKf JvgEK78RgVdD5N+kPDUtoFA= =BPLI -----END PGP SIGNATURE----- From owner-linux-xfs@oss.sgi.com Sun Jan 15 13:10:22 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 13:10:25 -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 k0FLAKm2029339 for ; Sun, 15 Jan 2006 13:10:21 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA00587; Mon, 16 Jan 2006 08:11:20 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0FLBVkt8446636; Mon, 16 Jan 2006 08:11:31 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0FLBQSH8446052; Mon, 16 Jan 2006 08:11:26 +1100 (EST) Date: Mon, 16 Jan 2006 08:11:26 +1100 From: Nathan Scott To: Andrey Borzenkov , Sam Ravnborg Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org Subject: Re: 2.6: xfs is rebuilt on every .config change Message-ID: <20060116081126.C8430989@wobbly.melbourne.sgi.com> References: <200601151226.49461.arvidjaar@mail.ru> <20060115095410.GA8195@mars.ravnborg.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060115095410.GA8195@mars.ravnborg.org>; from sam@ravnborg.org on Sun, Jan 15, 2006 at 10:54:10AM +0100 X-archive-position: 7192 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: 601 Lines: 19 On Sun, Jan 15, 2006 at 10:54:10AM +0100, Sam Ravnborg wrote: > On Sun, Jan 15, 2006 at 12:26:46PM +0300, Andrey Borzenkov wrote: > > - - xfs is rebuilt. This happens when there are *no* changes related to xfs > > alltogether. E.g. I now applied 2.6.15.1 patch and xfs got rebuilt again. > > The xfs source files do: > #include > To gain access to actual kernel release. > > So each time you do a change to the tree that causes version.h to be > updated the xfs source files will be recompiled. We really don't need that in mainline - I'll clean this up shortly. thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jan 15 13:31:49 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 13:31:55 -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 k0FLVlm2030607 for ; Sun, 15 Jan 2006 13:31:48 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id IAA01103; Mon, 16 Jan 2006 08:32:52 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0FLX3kt8419924; Mon, 16 Jan 2006 08:33:03 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0FLWwtg8443753; Mon, 16 Jan 2006 08:32:58 +1100 (EST) Date: Mon, 16 Jan 2006 08:32:58 +1100 From: Nathan Scott To: Jan Engelhardt Cc: Keith Owens , Bernd Eckenfels , linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: Quota on xfs vfsroot Message-ID: <20060116083258.E8430989@wobbly.melbourne.sgi.com> References: <30975.1137288450@ocs3.ocs.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jengelh@linux01.gwdg.de on Sun, Jan 15, 2006 at 01:11:31PM +0100 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id k0FLVnm2030612 X-archive-position: 7193 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: 703 Lines: 21 On Sun, Jan 15, 2006 at 01:11:31PM +0100, Jan Engelhardt wrote: > >>Ah, thank you. > >>Weird manpage program wrapped rootflags into "root-\nflags" at EOL, sigh. > > > >One of the many reasons that man pages should have hyphenation turned > >off. In current *roff, the command is '.nh'. Some older versions of > >*roff used '.hy off' or '.hy 0'. > > The man program itself is very weird too - produces stylized ` and ' > when utf8 is active, making it ‘ and ’, which breaks example code snippets. > Manpages should rather opt-in for "fun stuff" like `' and hyphenation > rather than opt-out. Oh well. > Less whining, more patching - could you send me a fixed xfs_quota.8? thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Sun Jan 15 14:47:07 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 14:47:23 -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 k0FMl5m2002154 for ; Sun, 15 Jan 2006 14:47:06 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA02440; Mon, 16 Jan 2006 09:48:10 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0FMmLkt8449229; Mon, 16 Jan 2006 09:48:21 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0FMmH228417725; Mon, 16 Jan 2006 09:48:17 +1100 (EST) Date: Mon, 16 Jan 2006 09:48:17 +1100 From: Nathan Scott To: Andrew Morton , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com Subject: Re: 2.6.15-mm3 bisection: git-xfs.patch makes reiserfs oops Message-ID: <20060116094817.A8425113@wobbly.melbourne.sgi.com> References: <20060110235554.GA3527@inferi.kami.home> <20060110170037.4a614245.akpm@osdl.org> <20060115221458.GA3521@inferi.kami.home> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20060115221458.GA3521@inferi.kami.home>; from malattia@linux.it on Sun, Jan 15, 2006 at 11:14:58PM +0100 X-archive-position: 7194 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: 1624 Lines: 53 On Sun, Jan 15, 2006 at 11:14:58PM +0100, Mattia Dongili wrote: > [CC-in relevant people/ML] > > Hello! > > second bisection result! > > On Tue, Jan 10, 2006 at 05:00:37PM -0800, Andrew Morton wrote: > > Mattia Dongili wrote: > [...] > > > 1- reiser3 oopsed[1] twice while suspending to ram. It seems > > > reproducible (have some activity on the fs and suspend) > > > > No significant reiser3 changes in there, so I'd be suspecting something > > else has gone haywire. > > you're right: git-xfs.patch is the bad guy. > > Unfortunately netconsole isn't helpful in capturing the oops (no serial > ports here) but I have two more shots (more readable): > http://oioio.altervista.org/linux/dsc03148.jpg > http://oioio.altervista.org/linux/dsc03149.jpg Hmm, thats odd. It seems to be coming from: reiserfs_commit_page -> reiserfs_add_ordered_list -> __add_jh(inline) I guess XFS may have left a buffer_head in an unusual state (with some private flag/b_private set), somehow, and perhaps that buffer_head has later been allocated for a page in a reiserfs write. Does this patch, below, help at all? I see one BUG check in __add_jh for non-NULL b_private, but can't see the top of your console output from the photos - is there a preceding line with "kernel BUG at ..." in it? cheers. -- Nathan --- fs/buffer.c.orig 2006-01-16 10:15:01.332010750 +1100 +++ fs/buffer.c 2006-01-16 10:18:15.276131500 +1100 @@ -1027,7 +1027,7 @@ try_again: /* Link the buffer to its page */ set_bh_page(bh, page, offset); - bh->b_end_io = NULL; + init_buffer(bh, NULL, NULL); } return head; /* From owner-linux-xfs@oss.sgi.com Sun Jan 15 15:21:15 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 15:21:21 -0800 (PST) Received: from aa003msg.fastwebnet.it (213-140-2-70.ip.fastwebnet.it [213.140.2.70]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0FNLEm2003843 for ; Sun, 15 Jan 2006 15:21:15 -0800 Received: from ms005msg.fastwebnet.it (10.31.41.25) by aa003msg.fastwebnet.it (7.2.069.1) id 43CAA20A0000E713; Mon, 16 Jan 2006 00:22:00 +0100 Received: from inferi (23.251.77.98) by ms005msg.fastwebnet.it (7.2.069.3) id 43B15D9F00E203D8; Mon, 16 Jan 2006 00:22:00 +0100 Received: from mattia by inferi with local (Exim 4.60) (envelope-from ) id 1EyHD3-0004o5-AC; Mon, 16 Jan 2006 00:22:53 +0100 Date: Mon, 16 Jan 2006 00:22:51 +0100 From: Mattia Dongili To: Nathan Scott Cc: Andrew Morton , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com Subject: Re: 2.6.15-mm3 bisection: git-xfs.patch makes reiserfs oops Message-ID: <20060115232250.GD3521@inferi.kami.home> Mail-Followup-To: Nathan Scott , Andrew Morton , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com References: <20060110235554.GA3527@inferi.kami.home> <20060110170037.4a614245.akpm@osdl.org> <20060115221458.GA3521@inferi.kami.home> <20060116094817.A8425113@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060116094817.A8425113@wobbly.melbourne.sgi.com> X-Message-Flag: Cranky? Try Free Software instead! X-Operating-System: Linux 2.6.15-rc5-mm3-1 i686 X-Editor: Vim http://www.vim.org/ X-Disclaimer: Buh! User-Agent: Mutt/1.5.11 X-archive-position: 7195 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: malattia@linux.it Precedence: bulk X-list: linux-xfs Content-Length: 1515 Lines: 39 On Mon, Jan 16, 2006 at 09:48:17AM +1100, Nathan Scott wrote: > On Sun, Jan 15, 2006 at 11:14:58PM +0100, Mattia Dongili wrote: [...] > > you're right: git-xfs.patch is the bad guy. > > > > Unfortunately netconsole isn't helpful in capturing the oops (no serial > > ports here) but I have two more shots (more readable): > > http://oioio.altervista.org/linux/dsc03148.jpg > > http://oioio.altervista.org/linux/dsc03149.jpg > > Hmm, thats odd. It seems to be coming from: > reiserfs_commit_page -> reiserfs_add_ordered_list -> __add_jh(inline) > > I guess XFS may have left a buffer_head in an unusual state (with some > private flag/b_private set), somehow, and perhaps that buffer_head has > later been allocated for a page in a reiserfs write. Does this patch, > below, help at all? I won't be able to test and report until tomorrow afternoon (CET), please be patient. > I see one BUG check in __add_jh for non-NULL b_private, but can't see > the top of your console output from the photos - is there a preceding > line with "kernel BUG at ..." in it? this is another shot of the same oops caught some days ago http://oioio.altervista.org/linux/dsc03133.jpg unfortunately it happened while running X so that's all I currently have... and I can't remember now about the BUG. oh, and BTW I have / and /usr on reiserfs while /home is xfs and I can easily reproduce the oops by starting X (with a simple user so fiddling in /home) and then installing and removing software in /usr. thanks. -- mattia :wq! From owner-linux-xfs@oss.sgi.com Sun Jan 15 15:37:57 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 15:38:00 -0800 (PST) Received: from aa004msg.fastwebnet.it (213-140-2-71.ip.fastwebnet.it [213.140.2.71]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0FNbum2004802 for ; Sun, 15 Jan 2006 15:37:57 -0800 Received: from ms003msg.fastwebnet.it (10.31.41.45) by aa004msg.fastwebnet.it (7.2.069.1) id 43CAC4B900000F9C; Sun, 15 Jan 2006 23:14:04 +0100 Received: from inferi (23.251.77.98) by ms003msg.fastwebnet.it (7.2.069.3) id 43B15EDE00E8914F; Sun, 15 Jan 2006 23:14:04 +0100 Received: from mattia by inferi with local (Exim 4.60) (envelope-from ) id 1EyG9K-0000ws-Mi; Sun, 15 Jan 2006 23:14:58 +0100 Date: Sun, 15 Jan 2006 23:14:58 +0100 From: Mattia Dongili To: Andrew Morton Cc: linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com Subject: 2.6.15-mm3 bisection: git-xfs.patch makes reiserfs oops Message-ID: <20060115221458.GA3521@inferi.kami.home> Mail-Followup-To: Andrew Morton , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com References: <20060110235554.GA3527@inferi.kami.home> <20060110170037.4a614245.akpm@osdl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060110170037.4a614245.akpm@osdl.org> X-Message-Flag: Cranky? Try Free Software instead! X-Operating-System: Linux 2.6.15-rc5-mm3-1 i686 X-Editor: Vim http://www.vim.org/ X-Disclaimer: Buh! User-Agent: Mutt/1.5.11 X-archive-position: 7196 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: malattia@linux.it Precedence: bulk X-list: linux-xfs Content-Length: 767 Lines: 28 [CC-in relevant people/ML] Hello! second bisection result! On Tue, Jan 10, 2006 at 05:00:37PM -0800, Andrew Morton wrote: > Mattia Dongili wrote: [...] > > 1- reiser3 oopsed[1] twice while suspending to ram. It seems > > reproducible (have some activity on the fs and suspend) > > No significant reiser3 changes in there, so I'd be suspecting something > else has gone haywire. you're right: git-xfs.patch is the bad guy. Unfortunately netconsole isn't helpful in capturing the oops (no serial ports here) but I have two more shots (more readable): http://oioio.altervista.org/linux/dsc03148.jpg http://oioio.altervista.org/linux/dsc03149.jpg BTW: I'm building -mm4 right now, will report tomorrow if the oops persists. -- mattia :wq! From owner-linux-xfs@oss.sgi.com Sun Jan 15 16:18:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 15 Jan 2006 16:18:46 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0G0Igm2006796 for ; Sun, 15 Jan 2006 16:18:42 -0800 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id k0G0JjFO010591; Sun, 15 Jan 2006 16:19:46 -0800 Message-ID: <43CAE6A1.9010409@tlinx.org> Date: Sun, 15 Jan 2006 16:19:45 -0800 From: "L. A. Walsh" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en, en_US MIME-Version: 1.0 To: Justin Piszcz CC: Linux-Xfs Subject: Re: is this list or project still alive? comments on latest benchmarks? References: <43C99344.9000502@tlinx.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7197 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1093 Lines: 35 fsck? on a Journaling file system? "That don't make no sense!" ;=) XFS has shown up pretty well against most contenders in tests from 2 years ago like the article you mention, but this latest bench I was mentioning was one mentioned a week or so back on slashdot, here: http://linux.slashdot.org/article.pl?sid=06/01/06/1539235 It pointed to a an updated benchmark with updated file-system software on Linux Gazette here: http://linuxgazette.net/122/TWDT.html#piszcz The have graphs of time taken and cpu time used. XFS didn't take the lead in any of the tests. Maybe the test was optimized for smaller computers? Will try resubbing to the list -- maybe got dropped off (sigh), thanks for the response. Linda Justin Piszcz wrote: > Your e-mail must be getting blocked, someone justed posted to list > less than an hour ago. I still think XFS is the best file system, > I've "heard" the following: > > 1) That JFS takes hours to fsck large filesystems. > 2) That ReiserV3 has corrupted peoples files (I've seen this personally) > 3) EXT3 also has some scalability issues. From owner-linux-xfs@oss.sgi.com Mon Jan 16 01:01:00 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 01:01:06 -0800 (PST) Received: from smtp.pzkagis.cz ([83.240.30.214]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0G90tm2004012 for ; Mon, 16 Jan 2006 01:00:58 -0800 Received: from soptik.pzkagis.cz (localhost.localdomain [127.0.0.1]) by smtp.pzkagis.cz (8.13.1/8.13.1) with ESMTP id k0G7ubQt016210; Mon, 16 Jan 2006 08:56:37 +0100 Received: (from luf@localhost) by soptik.pzkagis.cz (8.13.1/8.13.1/Submit) id k0G7uapT016209; Mon, 16 Jan 2006 08:56:36 +0100 Date: Mon, 16 Jan 2006 08:56:36 +0100 From: Ludek Finstrle To: Justin Piszcz Cc: Linux XFS Subject: Re: is this list or project still alive? comments on latest benchmarks? Message-ID: <20060116075636.GA15867@soptik.pzkagis.cz> References: <43C99344.9000502@tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-archive-position: 7198 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: ludek.finstrle@pzkagis.cz Precedence: bulk X-list: linux-xfs Content-Length: 252 Lines: 12 > XFS as you know is a little slow with deleting files, but that can be > fixed. > > http://everything2.com/index.pl?node_id=1479435 Very nice. Is there a way to change the xfs log size option without mkfs.xfs (mkfs.xfs -l size=64m)? Thanks, Luf From owner-linux-xfs@oss.sgi.com Mon Jan 16 01:06:47 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 01:07:08 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0G96jm2004478 for ; Mon, 16 Jan 2006 01:06:46 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id 0EB131A11DC63; Mon, 16 Jan 2006 04:07:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id 0CAC7A0A42E6; Mon, 16 Jan 2006 04:07:53 -0500 (EST) Date: Mon, 16 Jan 2006 04:07:53 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: Ludek Finstrle cc: Linux XFS Subject: Re: is this list or project still alive? comments on latest benchmarks? In-Reply-To: <20060116075636.GA15867@soptik.pzkagis.cz> Message-ID: References: <43C99344.9000502@tlinx.org> <20060116075636.GA15867@soptik.pzkagis.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7199 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: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 487 Lines: 23 That is a good question, from what I have read it has to be specified at the filesystem creation time; however, maybe someone on the list knows otherwise. Thanks, Justin. On Mon, 16 Jan 2006, Ludek Finstrle wrote: >> XFS as you know is a little slow with deleting files, but that can be >> fixed. >> >> http://everything2.com/index.pl?node_id=1479435 > > Very nice. Is there a way to change the xfs log size option without > mkfs.xfs (mkfs.xfs -l size=64m)? > > Thanks, > > Luf > From owner-linux-xfs@oss.sgi.com Mon Jan 16 01:29:35 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 01:29:43 -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 k0G9TUm2006207 for ; Mon, 16 Jan 2006 01:29:35 -0800 Received: from agami.com ([192.168.168.119]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k0G9Ubhq007973 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jan 2006 01:30:37 -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 k0G9UWL5027146 for ; Mon, 16 Jan 2006 01:30:32 -0800 Received: from [192.168.0.207] ([10.123.200.1]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jan 2006 01:30:31 -0800 Message-ID: <43CB66C9.2050809@agami.com> Date: Mon, 16 Jan 2006 14:56:33 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Piszcz CC: Ludek Finstrle , Linux XFS Subject: Re: is this list or project still alive? comments on latest benchmarks? References: <43C99344.9000502@tlinx.org> <20060116075636.GA15867@soptik.pzkagis.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jan 2006 09:30:31.0742 (UTC) FILETIME=[7ED0CDE0:01C61A7F] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7200 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: 1361 Lines: 48 Hi Justin, Log sizes can't be changed as of now. Though the xfs_growfs exports the interface, it is yet not implemented internally. This is what I get when I try to change this: [root@ga09 root]# xfs_growfs -L 16384 /lfs/fs1 meta-data=/lfs/fs1 isize=512 agcount=2, agsize=14651136 blks = sectsz=512 data = bsize=4096 blocks=29300736, imaxpct=25 = sunit=24 swidth=24 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32760, version=2 = sectsz=512 sunit=24 blks realtime =none extsz=6291456 blocks=0, rtextents=0 xfs_growfs: log growth not supported yet Regards, Shailendra Justin Piszcz wrote: > That is a good question, from what I have read it has to be specified at > the filesystem creation time; however, maybe someone on the list knows > otherwise. > > Thanks, > > Justin. > > On Mon, 16 Jan 2006, Ludek Finstrle wrote: > >>> XFS as you know is a little slow with deleting files, but that can be >>> fixed. >>> >>> http://everything2.com/index.pl?node_id=1479435 >> >> >> Very nice. Is there a way to change the xfs log size option without >> mkfs.xfs (mkfs.xfs -l size=64m)? >> >> Thanks, >> >> Luf >> > > From owner-linux-xfs@oss.sgi.com Mon Jan 16 02:31:16 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 02:31:33 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0GAVGm2009678 for ; Mon, 16 Jan 2006 02:31:16 -0800 Received: from [192.168.1.101] (c-71-198-107-69.hsd1.ca.comcast.net[71.198.107.69]) by comcast.net (rwcrmhc14) with ESMTP id <200601160929550140022288e>; Mon, 16 Jan 2006 09:30:01 +0000 Message-ID: <43CB6796.4040104@namesys.com> Date: Mon, 16 Jan 2006 01:29:58 -0800 From: Hans Reiser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nathan Scott CC: Andrew Morton , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com, Jeff Mahoney , Mattia Dongili Subject: Re: 2.6.15-mm3 bisection: git-xfs.patch makes reiserfs oops References: <20060110235554.GA3527@inferi.kami.home> <20060110170037.4a614245.akpm@osdl.org> <20060115221458.GA3521@inferi.kami.home> <20060116094817.A8425113@wobbly.melbourne.sgi.com> In-Reply-To: <20060116094817.A8425113@wobbly.melbourne.sgi.com> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7201 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: reiser@namesys.com Precedence: bulk X-list: linux-xfs Content-Length: 1753 Lines: 65 Thanks Nathan, Mattia, and Andrew. vs, can you or Jeff look at whether our buffer head inits are sufficiently hardened by next Monday (I know that vs has a lot of mail to catch up to)? Jeff, if you have time before then, it would be nice if you could handle it, I know hardening V3 is an interest of yours. Thanks, Hans Nathan Scott wrote: >On Sun, Jan 15, 2006 at 11:14:58PM +0100, Mattia Dongili wrote: > > >>[CC-in relevant people/ML] >> >>Hello! >> >>second bisection result! >> >>On Tue, Jan 10, 2006 at 05:00:37PM -0800, Andrew Morton wrote: >> >> >>>Mattia Dongili wrote: >>> >>> >>[...] >> >> >>>>1- reiser3 oopsed[1] twice while suspending to ram. It seems >>>> reproducible (have some activity on the fs and suspend) >>>> >>>> >>>No significant reiser3 changes in there, so I'd be suspecting something >>>else has gone haywire. >>> >>> >>you're right: git-xfs.patch is the bad guy. >> >>Unfortunately netconsole isn't helpful in capturing the oops (no serial >>ports here) but I have two more shots (more readable): >>http://oioio.altervista.org/linux/dsc03148.jpg >>http://oioio.altervista.org/linux/dsc03149.jpg >> >> > >Hmm, thats odd. It seems to be coming from: >reiserfs_commit_page -> reiserfs_add_ordered_list -> __add_jh(inline) > >I guess XFS may have left a buffer_head in an unusual state (with some >private flag/b_private set), somehow, and perhaps that buffer_head has >later been allocated for a page in a reiserfs write. Does this patch, >below, help at all? > >I see one BUG check in __add_jh for non-NULL b_private, but can't see >the top of your console output from the photos - is there a preceding >line with "kernel BUG at ..." in it? > >cheers. > > > From owner-linux-xfs@oss.sgi.com Mon Jan 16 04:03:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 04:04:07 -0800 (PST) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0GC3wm2014943 for ; Mon, 16 Jan 2006 04:03:59 -0800 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k0GC56Yg010195; Mon, 16 Jan 2006 13:05:08 +0100 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k0GC55Lq010189; Mon, 16 Jan 2006 13:05:06 +0100 Date: Mon, 16 Jan 2006 13:05:05 +0100 (MET) From: Jan Engelhardt To: Nathan Scott cc: Keith Owens , Bernd Eckenfels , Linux Kernel Mailing List , linux-xfs@oss.sgi.com Subject: Re: Quota on xfs vfsroot In-Reply-To: <20060116083258.E8430989@wobbly.melbourne.sgi.com> Message-ID: References: <30975.1137288450@ocs3.ocs.com.au> <20060116083258.E8430989@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1283855629-148570452-1137413105=:7465" X-archive-position: 7202 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: jengelh@linux01.gwdg.de Precedence: bulk X-list: linux-xfs Content-Length: 735 Lines: 22 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1283855629-148570452-1137413105=:7465 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: 8BIT >> The man program itself is very weird too - produces stylized ` and ' >> when utf8 is active, making it ‘ and ’, which breaks example code snippets. >> Manpages should rather opt-in for "fun stuff" like `' and hyphenation >> rather than opt-out. Oh well. > >Less whining, more patching - could you send me a fixed xfs_quota.8? I don't know too much roff syntax. Sorry for the inconvenience. Jan Engelhardt -- --1283855629-148570452-1137413105=:7465-- From owner-linux-xfs@oss.sgi.com Mon Jan 16 05:00:06 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 05:00:19 -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 k0GD06m2022655 for ; Mon, 16 Jan 2006 05:00:06 -0800 Received: from hch by pentafluge.infradead.org with local (Exim 4.54 #1 (Red Hat Linux)) id 1EySqE-0003Cm-2v; Mon, 16 Jan 2006 11:48:06 +0000 Date: Mon, 16 Jan 2006 11:48:06 +0000 From: Christoph Hellwig To: Hans Reiser Cc: Nathan Scott , Andrew Morton , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com, Jeff Mahoney , Mattia Dongili Subject: Re: 2.6.15-mm3 bisection: git-xfs.patch makes reiserfs oops Message-ID: <20060116114805.GB12069@infradead.org> Mail-Followup-To: Christoph Hellwig , Hans Reiser , Nathan Scott , Andrew Morton , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com, Jeff Mahoney , Mattia Dongili References: <20060110235554.GA3527@inferi.kami.home> <20060110170037.4a614245.akpm@osdl.org> <20060115221458.GA3521@inferi.kami.home> <20060116094817.A8425113@wobbly.melbourne.sgi.com> <43CB6796.4040104@namesys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43CB6796.4040104@namesys.com> 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: 7203 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: 550 Lines: 12 On Mon, Jan 16, 2006 at 01:29:58AM -0800, Hans Reiser wrote: > Thanks Nathan, Mattia, and Andrew. > > vs, can you or Jeff look at whether our buffer head inits are > sufficiently hardened by next Monday (I know that vs has a lot of mail > to catch up to)? Jeff, if you have time before then, it would be nice > if you could handle it, I know hardening V3 is an interest of yours. Chris Mason just sent a patch to -fsdevel that initialized bh->b_private in reiserfs. Mattia, I'll bounce you the patch privately, could you try to see if it helps? From owner-linux-xfs@oss.sgi.com Mon Jan 16 05:53:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 05:53:17 -0800 (PST) Received: from picard.linux.it (picard.linux.it [213.254.12.146]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0GDr3m2025518 for ; Mon, 16 Jan 2006 05:53:04 -0800 Received: from picard.linux.it (localhost [127.0.0.1]) by picard.linux.it (Postfix) with ESMTP id 2037E43DD; Mon, 16 Jan 2006 12:51:25 +0100 (CET) Received: from 83.103.117.254 (SquirrelMail authenticated user malattia) by picard.linux.it with HTTP; Mon, 16 Jan 2006 12:51:25 +0100 (CET) Message-ID: <14017.83.103.117.254.1137412285.squirrel@picard.linux.it> In-Reply-To: <43CB6796.4040104@namesys.com> References: <20060110235554.GA3527@inferi.kami.home> <20060110170037.4a614245.akpm@osdl.org> <20060115221458.GA3521@inferi.kami.home> <20060116094817.A8425113@wobbly.melbourne.sgi.com> <43CB6796.4040104@namesys.com> Date: Mon, 16 Jan 2006 12:51:25 +0100 (CET) Subject: Re: 2.6.15-mm3 bisection: git-xfs.patch makes reiserfs oops From: "Mattia Dongili" To: "Hans Reiser" Cc: "Nathan Scott" , "Andrew Morton" , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com, "Jeff Mahoney" , "Mattia Dongili" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-archive-position: 7204 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: malattia@linux.it Precedence: bulk X-list: linux-xfs Content-Length: 972 Lines: 31 [...] > Nathan Scott wrote: >>On Sun, Jan 15, 2006 at 11:14:58PM +0100, Mattia Dongili wrote: [...] >>>you're right: git-xfs.patch is the bad guy. >>> >>>Unfortunately netconsole isn't helpful in capturing the oops (no serial >>>ports here) but I have two more shots (more readable): >>>http://oioio.altervista.org/linux/dsc03148.jpg >>>http://oioio.altervista.org/linux/dsc03149.jpg >>> >>> >> >>Hmm, thats odd. It seems to be coming from: >>reiserfs_commit_page -> reiserfs_add_ordered_list -> __add_jh(inline) >> >>I guess XFS may have left a buffer_head in an unusual state (with some >>private flag/b_private set), somehow, and perhaps that buffer_head has >>later been allocated for a page in a reiserfs write. Does this patch, >>below, help at all? Yes, it does help, good catch! I'm currently running -mm4, which presented the same behaviour, with your one liner and I can't reproduce the oops anymore (fortunately for my root FS!). thanks -- mattia :wq! From owner-linux-xfs@oss.sgi.com Mon Jan 16 07:49:24 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 07:49:32 -0800 (PST) Received: from picard.linux.it (picard.linux.it [213.254.12.146]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0GFnNm2031703 for ; Mon, 16 Jan 2006 07:49:24 -0800 Received: from picard.linux.it (localhost [127.0.0.1]) by picard.linux.it (Postfix) with ESMTP id 46D3C449E; Mon, 16 Jan 2006 16:50:32 +0100 (CET) Received: from 83.103.117.254 (SquirrelMail authenticated user malattia) by picard.linux.it with HTTP; Mon, 16 Jan 2006 16:50:32 +0100 (CET) Message-ID: <6142.83.103.117.254.1137426632.squirrel@picard.linux.it> In-Reply-To: <20060116114805.GB12069@infradead.org> References: <20060110235554.GA3527@inferi.kami.home> <20060110170037.4a614245.akpm@osdl.org> <20060115221458.GA3521@inferi.kami.home> <20060116094817.A8425113@wobbly.melbourne.sgi.com> <43CB6796.4040104@namesys.com> <20060116114805.GB12069@infradead.org> Date: Mon, 16 Jan 2006 16:50:32 +0100 (CET) Subject: Re: 2.6.15-mm3 bisection: git-xfs.patch makes reiserfs oops From: "Mattia Dongili" To: "Christoph Hellwig" Cc: "Hans Reiser" , "Nathan Scott" , "Andrew Morton" , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com, "Jeff Mahoney" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-archive-position: 7205 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: malattia@linux.it Precedence: bulk X-list: linux-xfs Content-Length: 749 Lines: 22 On Mon, January 16, 2006 12:48 pm, Christoph Hellwig said: > On Mon, Jan 16, 2006 at 01:29:58AM -0800, Hans Reiser wrote: >> Thanks Nathan, Mattia, and Andrew. >> >> vs, can you or Jeff look at whether our buffer head inits are >> sufficiently hardened by next Monday (I know that vs has a lot of mail >> to catch up to)? Jeff, if you have time before then, it would be nice >> if you could handle it, I know hardening V3 is an interest of yours. > > Chris Mason just sent a patch to -fsdevel that initialized bh->b_private > in reiserfs. Mattia, I'll bounce you the patch privately, could you try > to see if it helps? It does help, as does Nathan's patch. BTW: I'm testing it on -mm4 (I reproduced the same oops here) Thanks -- mattia :wq! From owner-linux-xfs@oss.sgi.com Mon Jan 16 14:28:13 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 14:28:19 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0GMSDm2030702 for ; Mon, 16 Jan 2006 14:28:13 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 132F12800BF; Mon, 16 Jan 2006 16:29:12 -0600 (CST) Message-ID: <43CC1E37.5090007@sgi.com> Date: Mon, 16 Jan 2006 16:29:11 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Piszcz Cc: Ludek Finstrle , Linux XFS Subject: Re: is this list or project still alive? comments on latest benchmarks? References: <43C99344.9000502@tlinx.org> <20060116075636.GA15867@soptik.pzkagis.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7206 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: 799 Lines: 33 Justin Piszcz wrote: > That is a good question, from what I have read it has to be specified at > the filesystem creation time; however, maybe someone on the list knows > otherwise. It's not implemented/supported. If you have an external log, or wish to move to an external log, it can be done with xfs_db hackery to an offline filesystem. Very-unsupported tips for doing this were posted to the list quite a long time ago. -Eric > Thanks, > > Justin. > > On Mon, 16 Jan 2006, Ludek Finstrle wrote: > >>> XFS as you know is a little slow with deleting files, but that can be >>> fixed. >>> >>> http://everything2.com/index.pl?node_id=1479435 >> >> >> Very nice. Is there a way to change the xfs log size option without >> mkfs.xfs (mkfs.xfs -l size=64m)? >> >> Thanks, >> >> Luf >> > From owner-linux-xfs@oss.sgi.com Mon Jan 16 15:18:58 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 15:19:02 -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 k0GNIvm2001102 for ; Mon, 16 Jan 2006 15:18:58 -0800 Received: from mars.ravnborg.org (0x50a0757d.hrnxx9.adsl-dhcp.tele.dk [80.160.117.125]) by pasmtp.tele.dk (Postfix) with ESMTP id E8A491EC323; Tue, 17 Jan 2006 00:19:56 +0100 (CET) Received: by mars.ravnborg.org (Postfix, from userid 1000) id 7448543C2BA; Tue, 17 Jan 2006 00:19:52 +0100 (CET) Date: Tue, 17 Jan 2006 00:19:52 +0100 From: Sam Ravnborg To: Eric Sandeen Cc: Andrew Morton , hch@infradead.org, linux-kernel@vger.kernel.org, linux-xfs@oss.sgi.com Subject: Re: xfs: Makefile-linux-2.6 => Makefile? Message-ID: <20060116231952.GA8752@mars.ravnborg.org> References: <20060109164214.GA10367@mars.ravnborg.org> <20060109164611.GA1382@infradead.org> <43C2CFBD.8040901@sgi.com> <20060109234532.78bda36a.akpm@osdl.org> <43C3E222.7020203@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43C3E222.7020203@sgi.com> User-Agent: Mutt/1.5.11 X-archive-position: 7207 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: 1701 Lines: 42 On Tue, Jan 10, 2006 at 10:34:42AM -0600, Eric Sandeen wrote: > Andrew Morton wrote: > >It'd be nice to fix this: > > > >bix:/usr/src/25> make fs/xfs/linux-2.6/xfs_iops.o > > SPLIT include/linux/autoconf.h -> include/config/* > > SHIPPED scripts/genksyms/lex.c > > SHIPPED scripts/genksyms/parse.h > > SHIPPED scripts/genksyms/keywords.c > > HOSTCC scripts/genksyms/lex.o > > SHIPPED scripts/genksyms/parse.c > > HOSTCC scripts/genksyms/parse.o > > HOSTLD scripts/genksyms/genksyms > > HOSTCC scripts/mod/file2alias.o > > HOSTCC scripts/mod/modpost.o > > HOSTLD scripts/mod/modpost > >scripts/Makefile.build:15: /usr/src/devel/fs/xfs/linux-2.6/Makefile: No > >such file or directory > >make[1]: *** No rule to make target > >`/usr/src/devel/fs/xfs/linux-2.6/Makefile'. Stop. > >make: *** [fs/xfs/linux-2.6/xfs_iops.o] Error 2 > > Hm, maybe Sam can correct me if I'm wrong, but I'm not sure that kbuild > will support more than one Makefile/Kbuild file per module; so if we have > some code in a subdirectory, I think it all needs to be driven from the > parent directory's Makefile... and then the above doesn't work. > > Sam, is there any way to make this work with some code for the module in a > subdirectory? Hi Eric. I forgot to point out one ugly solution for this. You can include a dummy Kbuild (Makefile) in each directory to support this. I recall that reiser4 had similar question and this was the solution I pointed out for them too. No - I am not in favour of it. But for local development it could make sense. So it may solve the "Eric" part of it, but not the "Andrew" part of it since these file will never get in the mainstream kernel (hopefully). Sam From owner-linux-xfs@oss.sgi.com Mon Jan 16 19:26:52 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 19:27:16 -0800 (PST) Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.154]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0H3Qqm2019894 for ; Mon, 16 Jan 2006 19:26:52 -0800 Received: from [192.168.1.101] (c-71-198-107-69.hsd1.ca.comcast.net[71.198.107.69]) by comcast.net (rwcrmhc14) with ESMTP id <200601170327540140026rnee>; Tue, 17 Jan 2006 03:28:00 +0000 Message-ID: <43CC643E.3000507@namesys.com> Date: Mon, 16 Jan 2006 19:27:58 -0800 From: Hans Reiser User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christoph Hellwig CC: Nathan Scott , Andrew Morton , linux-kernel@vger.kernel.org, reiserfs-dev@namesys.com, linux-xfs@oss.sgi.com, Jeff Mahoney , Mattia Dongili Subject: Re: 2.6.15-mm3 bisection: git-xfs.patch makes reiserfs oops References: <20060110235554.GA3527@inferi.kami.home> <20060110170037.4a614245.akpm@osdl.org> <20060115221458.GA3521@inferi.kami.home> <20060116094817.A8425113@wobbly.melbourne.sgi.com> <43CB6796.4040104@namesys.com> <20060116114805.GB12069@infradead.org> In-Reply-To: <20060116114805.GB12069@infradead.org> X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-archive-position: 7208 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: reiser@namesys.com Precedence: bulk X-list: linux-xfs Content-Length: 732 Lines: 27 Christoph Hellwig wrote: >On Mon, Jan 16, 2006 at 01:29:58AM -0800, Hans Reiser wrote: > > >>Thanks Nathan, Mattia, and Andrew. >> >>vs, can you or Jeff look at whether our buffer head inits are >>sufficiently hardened by next Monday (I know that vs has a lot of mail >>to catch up to)? Jeff, if you have time before then, it would be nice >>if you could handle it, I know hardening V3 is an interest of yours. >> >> > >Chris Mason just sent a patch to -fsdevel that initialized bh->b_private >in reiserfs. Mattia, I'll bounce you the patch privately, could you try >to see if it helps? > > > > > I remember wondering if that fixed it, but was too lazy to go back and look at whether it was exactly equivalent.;-) Hans From owner-linux-xfs@oss.sgi.com Mon Jan 16 19:39:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 19:39:40 -0800 (PST) Received: from mail.sandeen.net (sandeen.net [209.173.210.139]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0H3dbm2020874 for ; Mon, 16 Jan 2006 19:39:37 -0800 Received: from [10.0.0.4] (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id E4C0A2800BF; Mon, 16 Jan 2006 21:40:45 -0600 (CST) Message-ID: <43CC673B.8050808@sgi.com> Date: Mon, 16 Jan 2006 21:40:43 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ravnborg Cc: Andrew Morton , hch@infradead.org, 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> <20060109234532.78bda36a.akpm@osdl.org> <43C3E222.7020203@sgi.com> <20060116231952.GA8752@mars.ravnborg.org> In-Reply-To: <20060116231952.GA8752@mars.ravnborg.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7209 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: 672 Lines: 21 Sam Ravnborg wrote: >>Sam, is there any way to make this work with some code for the module in a >>subdirectory? > > > Hi Eric. > I forgot to point out one ugly solution for this. > You can include a dummy Kbuild (Makefile) in each directory to support > this. I recall that reiser4 had similar question and this was the > solution I pointed out for them too. > No - I am not in favour of it. But for local development it could make > sense. > So it may solve the "Eric" part of it, but not the "Andrew" part of it > since these file will never get in the mainstream kernel (hopefully). > > Sam Thanks, Sam - I'd considered that, too. We may do it locally. -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 16 20:18:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 16 Jan 2006 20:18:07 -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 k0H4I2m2025160 for ; Mon, 16 Jan 2006 20:18:02 -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 OAA08779; Tue, 17 Jan 2006 14:19:07 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 26107494E42C; Tue, 17 Jan 2006 14:19:06 +1100 (EST) To: linux-xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 948197 - kernel BUG at mm/filemap.c:479 Message-Id: <20060117031906.26107494E42C@chook.melbourne.sgi.com> Date: Tue, 17 Jan 2006 14:19:06 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 7210 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: 726 Lines: 19 Fix a race in xfs_submit_ioend() where we can be completing I/O for a page while we are still submitting other buffers on the same page for I/O. Date: Tue Jan 17 14:18:01 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: nathans The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:25004a fs/xfs/linux-2.6/xfs_aops.c - 1.112 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_aops.c.diff?r1=text&tr1=1.112&r2=text&tr2=1.111&f=h - Start writeback on all buffers in the ioend list before we start submitting them so that a page will not be completed until all buffers on it are done. From owner-linux-xfs@oss.sgi.com Tue Jan 17 07:26:18 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 07:26:21 -0800 (PST) Received: from hotmail.com (bay110-f1.bay110.hotmail.com [65.54.229.11]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0HFQHm2032623 for ; Tue, 17 Jan 2006 07:26:17 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Jan 2006 05:40:26 -0800 Message-ID: Received: from 65.54.229.220 by by110fd.bay110.hotmail.msn.com with HTTP; Tue, 17 Jan 2006 13:40:26 GMT X-Originating-IP: [194.237.142.21] X-Originating-Email: [dmarkic@hotmail.com] X-Sender: dmarkic@hotmail.com From: "Dubravko Markic" To: linux-xfs@oss.sgi.com Subject: Real-time section on Xfs Date: Tue, 17 Jan 2006 14:40:26 +0100 Mime-Version: 1.0 Content-Type: text/html; format=flowed X-OriginalArrivalTime: 17 Jan 2006 13:40:26.0408 (UTC) FILETIME=[92BF0280:01C61B6B] X-archive-position: 7211 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: dmarkic@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 724 Lines: 6
Hello,
      I am interested to find out if it is possible to make tests on the real-time section in xfs on a linux machine. By this i mean if there is a way to create/copy/move files on to the real-time section in order to test it on a linux machine? Or is this option only available in the IRIX environment? Does this mean that whatever tests i want to run on the linux machine, in order to test the peroformance of the filesystem, is limited only to the data section? Thanks for you help
 
Regards,
Dubo 
From owner-linux-xfs@oss.sgi.com Tue Jan 17 07:36:54 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 07:36:58 -0800 (PST) Received: from hotmail.com (bay110-f12.bay110.hotmail.com [65.54.229.22]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0HFasm2001159 for ; Tue, 17 Jan 2006 07:36:54 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 17 Jan 2006 05:51:03 -0800 Message-ID: Received: from 65.54.229.220 by by110fd.bay110.hotmail.msn.com with HTTP; Tue, 17 Jan 2006 13:51:03 GMT X-Originating-IP: [194.237.142.21] X-Originating-Email: [dmarkic@hotmail.com] X-Sender: dmarkic@hotmail.com From: "Dubravko Markic" To: linux-xfs@oss.sgi.com Subject: A bit more clarification Date: Tue, 17 Jan 2006 14:51:03 +0100 Mime-Version: 1.0 Content-Type: text/html; format=flowed X-OriginalArrivalTime: 17 Jan 2006 13:51:03.0459 (UTC) FILETIME=[0E754730:01C61B6D] X-archive-position: 7212 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: dmarkic@hotmail.com Precedence: bulk X-list: linux-xfs Content-Length: 1566 Lines: 9
Hello again,
      
I just want to add to my previous mail and clarify a few things. I am testing different filesystems on the linux machine (reiser, jfs, xfs, ext2 etc....). What i have done is that i have created a large binary file (2Gb) and i have written a program which reads through the file and records each individual read in miliseconds. This is for the purpose of trying to figure out which system is best suited for video-on-demand task. Now i have done my homework on each filesystem, including xfs, and i know that xfs is uniqe in that it has a real-time section for faster data processing.
 
As i previously wrote to you in my first mail, i am wondering if this real-time section can be put to the test in the linux environment. I have already created and mounted xfs with a data and a real-time section. But then what? I mean what can i do with the real-time section. I read somewhere that files created/moved/copied in the real-time section have to be done in some "complicated" and tedious way. But that it is not possbile to do this in linux? Is that true? I am left with only being able to test the data section of the xfs system? Thanks for all your help in advance. I hope it's a bit easier to answer my questions now that you have a bit more input from my side.
 
Regards
Dubo
From owner-linux-xfs@oss.sgi.com Tue Jan 17 08:01:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 08:01:38 -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 k0HG1bm2002978 for ; Tue, 17 Jan 2006 08:01:37 -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 k0HIDSOn015737 for ; Tue, 17 Jan 2006 10:13:28 -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 k0HG2hDN23953401; Tue, 17 Jan 2006 10:02:43 -0600 (CST) Message-ID: <43CD1523.2090302@sgi.com> Date: Tue, 17 Jan 2006 10:02:43 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dubravko Markic CC: linux-xfs@oss.sgi.com Subject: Re: A bit more clarification References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7213 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: 1836 Lines: 36 Dubravko Markic wrote: > Hello again, > > I just want to add to my previous mail and clarify a few things. I am > testing different filesystems on the linux machine (reiser, jfs, xfs, > ext2 etc....). What i have done is that i have created a large binary > file (2Gb) and i have written a program which reads through the file and > records each individual read in miliseconds. This is for the purpose of > trying to figure out which system is best suited for video-on-demand > task. Now i have done my homework on each filesystem, including xfs, and > i know that xfs is uniqe in that it has a real-time section for faster > data processing. > > As i previously wrote to you in my first mail, i am wondering if this > real-time section can be put to the test in the linux environment. I > have already created and mounted xfs with a data and a real-time > section. But then what? I mean what can i do with the real-time section. > I read somewhere that files created/moved/copied in the real-time > section have to be done in some "complicated" and tedious way. But that > it is not possbile to do this in linux? Is that true? I am left with > only being able to test the data section of the xfs system? Thanks for > all your help in advance. I hope it's a bit easier to answer my > questions now that you have a bit more input from my side. realtime should work on Linux. In a nutshell, you must mark the file as realtime before the first write to it, (actually, I think, anytime when it is of 0 length) and after that you must do direct IO to/from the file (I believe that direct IO is still a requirement, someone can correct me if I'm wrong...) see the xfsctl man page; mark the file as realtime with XFS_IOC_FSSETXATTR and set the xflag: XFS_XFLAG_REALTIME. See also XFS_XFLAG_RTINHERIT. -Eric From owner-linux-xfs@oss.sgi.com Tue Jan 17 12:15:46 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 12:15:50 -0800 (PST) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0HKFim2029250 for ; Tue, 17 Jan 2006 12:15:45 -0800 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k0HKGqCl021723; Tue, 17 Jan 2006 21:16:54 +0100 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k0HKGp9R021705; Tue, 17 Jan 2006 21:16:51 +0100 Date: Tue, 17 Jan 2006 21:16:51 +0100 (MET) From: Jan Engelhardt To: linux-xfs@oss.sgi.com cc: Linux Kernel Mailing List Subject: xfs depends on exportfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7214 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: jengelh@linux01.gwdg.de Precedence: bulk X-list: linux-xfs Content-Length: 425 Lines: 15 Hi, I could not find a clue on the first try on why xfs needs exportfs. The Kconfig says "select EXPORTFS if CONFIG_NFSD!=n", but there are no occurrences of CONFIG_NFS* or CONFIG_EXP* in any of the files in fs/xfs/. Did I miss something or this a superfluous line in Kconfig? Interestingly tho, `modinfo xfs.ko` returns "exportfs", so I suppose it's somewhere, well hidden. If so, where? Regards, Jan Engelhardt -- From owner-linux-xfs@oss.sgi.com Tue Jan 17 12:41:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 12:41:22 -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 k0HKfFm2002875 for ; Tue, 17 Jan 2006 12:41:16 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id HAA00325; Wed, 18 Jan 2006 07:42:14 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0HKgQkt8497701; Wed, 18 Jan 2006 07:42:27 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0HKgN008485085; Wed, 18 Jan 2006 07:42:23 +1100 (EST) Date: Wed, 18 Jan 2006 07:42:23 +1100 From: Nathan Scott To: Jan Engelhardt Cc: linux-xfs@oss.sgi.com, Linux Kernel Mailing List Subject: Re: xfs depends on exportfs Message-ID: <20060118074223.A8500612@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jengelh@linux01.gwdg.de on Tue, Jan 17, 2006 at 09:16:51PM +0100 X-archive-position: 7215 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: 532 Lines: 17 On Tue, Jan 17, 2006 at 09:16:51PM +0100, Jan Engelhardt wrote: > Hi, > > I could not find a clue on the first try on why xfs needs exportfs. > The Kconfig says "select EXPORTFS if CONFIG_NFSD!=n", but there are no > occurrences of CONFIG_NFS* or CONFIG_EXP* in any of the files in fs/xfs/. > Did I miss something or this a superfluous line in Kconfig? Interestingly > tho, `modinfo xfs.ko` returns "exportfs", so I suppose it's somewhere, well > hidden. If so, where? xfs_export.c, find_exported_dentry. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 17 12:51:43 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 12:51:47 -0800 (PST) Received: from flyingAngel.upjs.sk (static113-109.rudna.net [212.20.113.109]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0HKpdm2006403 for ; Tue, 17 Jan 2006 12:51:42 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id C3F8E102F0D; Tue, 17 Jan 2006 00:46:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id BEBDA180127; Tue, 17 Jan 2006 00:46:33 +0100 (CET) Date: Tue, 17 Jan 2006 00:46:33 +0100 (CET) From: Jan Derfinak To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - Merge up to 2.6.15 In-Reply-To: <20060110062615.149BB494A272@chook.melbourne.sgi.com> Message-ID: References: <20060110062615.149BB494A272@chook.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7216 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: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 1932 Lines: 46 On Tue, 10 Jan 2006, Nathan Scott wrote: > 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 Hello. I would like to ask when will be these changes visible through public XFS CVS? > > > 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 > 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 > 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 > 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 > 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 In freshly updated tree I have: grep Makefile linux-2.6-xfs/CVS/Entries /Makefile/1.32/Wed Dec 21 16:47:55 2005/-ko/ Xfs-cmds CVS seem to be broken too: cvs -z9 update -dP cvs update: Updating . cvs update: failed to create lock directory for /cvs/xfs-cmds' (/cvs/xfs-cmds/#cvs.lock): Permission denied cvs update: failed to obtain dir lock in repository /cvs/xfs-cmds' cvs [update aborted]: read lock failed - giving up jan From owner-linux-xfs@oss.sgi.com Tue Jan 17 14:24:01 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 14:24:03 -0800 (PST) Received: from elfstone.noviforum.si ([193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0HMO1m2014022 for ; Tue, 17 Jan 2006 14:24:01 -0800 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 8E0D01B94F for ; Tue, 17 Jan 2006 23:24:59 +0100 (CET) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 6154D1B949 for ; Tue, 17 Jan 2006 23:24:59 +0100 (CET) Subject: duplicate files From: Gorazd Golob To: linux-xfs@oss.sgi.com Content-Type: text/plain Date: Tue, 17 Jan 2006 23:24:58 +0100 Message-Id: <1137536698.10112.63.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7217 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: gorazd.golob@noviforum.si Precedence: bulk X-list: linux-xfs Content-Length: 507 Lines: 17 hi! I have one interesting problem on xfs partition formated with -b size=1k - some (very rarerly but they does) files appear like this on file system: $ ls -ila f4407c24c1f31d2304c8f8d4825* 237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 f4407c24c1f31d2304c8f8d48258.dat.gz 237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 f4407c24c1f31d2304c8f8d48258.dat.gz Same problem appear on kernels 2.6.11 and 2.6.12.6 (x86 and x86_x64). Have anyone already seen something like this? Thanks, Gorazd From owner-linux-xfs@oss.sgi.com Tue Jan 17 14:47:38 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 14:47:42 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0HMlcm2018028 for ; Tue, 17 Jan 2006 14:47:38 -0800 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id k0HMmkkG031429 for ; Tue, 17 Jan 2006 14:48:46 -0800 Message-ID: <43CD744E.9030606@tlinx.org> Date: Tue, 17 Jan 2006 14:48:46 -0800 From: "L. A. Walsh" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en, en_US MIME-Version: 1.0 To: Linux-Xfs Subject: unwritten extent flag on linux Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7219 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 2210 Lines: 52 The mkfs.xfs manpage I have on my system talks about an unwritten extent flag (all this talk about optimizing performance got me to looking at what mkfs ops were considered optimal). While the 7/2003 article didn't note a large difference in performance on the kernel used at that time, I noted the manpage saying about the "unwritten" option: "... If the suboption is omitted, unwritten extent flagging is enabled. If unwritten extents are flagged, filesys- tem write performance will be negatively affected for preallo- cated file extents, since extra filesystem transactions are required to convert extent flags for the range of the file writ- ten. This suboption should be disabled if the filesystem needs to be used on operating system versions which do not support the flagging capability." I.e flagging is enabled by default, but is bad for performance and should be disabled on OS's that don't support the flagging capability. Does linux support the 'flagging' capability? Am sorta guessing it does. What does it mean for an OS to support the 'flagging' capability? Guessing: It's a way to "pre-journal" that space has been allocated but not yet zeroed in case there is a system crash that happens when xfs is allocating fresh file blocks (extents) that might contain 'old data' (not zeroed yet). This way the flag gets set at allocation time that the blocks need to be zeroed, so even if a crash happens before they are actually zeroed, when the system recovers, those blocks are still marked on disk as needing to be initialized -- which will be done by an OS that supports the flagging capability. In any event this appears to make disk extent allocation a two step process to ensure the blocks are safely zeroed before reuse (a requirement on a multi-level secure OS). OS's that don't support the flag checking can disable the flagging, as they won't bother to check the flag on later access and zero it (perhaps return garbage or sensitive information), but at least they might as well turn off the flagging as it certainly provides no benefit. Is that the right idea or am I talking about something completely different? Thanks... Linda From owner-linux-xfs@oss.sgi.com Tue Jan 17 14:48:38 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 14:48:39 -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 k0HMmam2018291 for ; Tue, 17 Jan 2006 14:48:37 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04150; Wed, 18 Jan 2006 09:49:36 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0HMnmkt8485143; Wed, 18 Jan 2006 09:49:48 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0HMnk2Y8504787; Wed, 18 Jan 2006 09:49:46 +1100 (EST) Date: Wed, 18 Jan 2006 09:49:45 +1100 From: Nathan Scott To: Gorazd Golob Cc: linux-xfs@oss.sgi.com Subject: Re: duplicate files Message-ID: <20060118094945.I8500612@wobbly.melbourne.sgi.com> References: <1137536698.10112.63.camel@dacun.noviforum.si> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1137536698.10112.63.camel@dacun.noviforum.si>; from gorazd.golob@noviforum.si on Tue, Jan 17, 2006 at 11:24:58PM +0100 X-archive-position: 7220 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: 702 Lines: 28 On Tue, Jan 17, 2006 at 11:24:58PM +0100, Gorazd Golob wrote: > hi! Hello. > I have one interesting problem on xfs partition formated with -b size=1k Can you send xfs_info output? > - some (very rarerly but they does) files appear like this on file > system: > > $ ls -ila f4407c24c1f31d2304c8f8d4825* > 237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 > f4407c24c1f31d2304c8f8d48258.dat.gz > 237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 > f4407c24c1f31d2304c8f8d48258.dat.gz > > Same problem appear on kernels 2.6.11 and 2.6.12.6 (x86 and x86_x64). > Have anyone already seen something like this? Nope. Any ideas on how to reproduce it? Is NFS being used? cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 17 14:45:50 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 14:45:54 -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 k0HMjmm2017806 for ; Tue, 17 Jan 2006 14:45:50 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA04106; Wed, 18 Jan 2006 09:46:53 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0HMl1kt8410648; Wed, 18 Jan 2006 09:47:02 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id k0HMihjK001022; Wed, 18 Jan 2006 09:44:44 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id k0HMieEx001020; Wed, 18 Jan 2006 09:44:40 +1100 Date: Wed, 18 Jan 2006 09:44:40 +1100 From: Nathan Scott To: Jan Derfinak , c.pascoe@itee.uq.edu.au Cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - Merge up to 2.6.15 Message-ID: <20060117224440.GA945@frodo> References: <20060110062615.149BB494A272@chook.melbourne.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.3i X-archive-position: 7218 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: 248 Lines: 13 On Tue, Jan 17, 2006 at 12:46:33AM +0100, Jan Derfinak wrote: > > I would like to ask when will be these changes visible through public XFS > CVS? > All the CVS export issues should now be resolved now (Works For Me (TM)). thanks. -- Nathan From owner-linux-xfs@oss.sgi.com Tue Jan 17 15:08:08 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 15:08:10 -0800 (PST) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0HN88m2021250 for ; Tue, 17 Jan 2006 15:08:08 -0800 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 3C02E1B94E; Wed, 18 Jan 2006 00:09:16 +0100 (CET) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id 0B6D11B949; Wed, 18 Jan 2006 00:09:15 +0100 (CET) Subject: Re: duplicate files From: Gorazd Golob To: Nathan Scott Cc: linux-xfs@oss.sgi.com In-Reply-To: <20060118094945.I8500612@wobbly.melbourne.sgi.com> References: <1137536698.10112.63.camel@dacun.noviforum.si> <20060118094945.I8500612@wobbly.melbourne.sgi.com> Content-Type: text/plain Date: Wed, 18 Jan 2006 00:09:15 +0100 Message-Id: <1137539355.10112.84.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7221 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: gorazd.golob@noviforum.si Precedence: bulk X-list: linux-xfs Content-Length: 1645 Lines: 45 > Can you send xfs_info output? > This one is on 2.6.11 - x86 - partiton is on 72gb scsi drive: meta-data=/xxxxx isize=256 agcount=16, agsize=4480124 blks = sectsz=512 data = bsize=1024 blocks=71681984, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=1024 blocks=35000, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 with xfsprogs-2.6.13 compiled for i486 And 2.6.12-6 - x86_64 - partition is on MD raid1 - but don't have xfs_info on system - I'll have it tommorow - I guess ;) I have installed xfsprogs-2.6.36 compiled for Intel's cpus with EM64T (nocona). Hardware for both systems is not the same. > > - some (very rarerly but they does) files appear like this on file > > system: > > > > $ ls -ila f4407c24c1f31d2304c8f8d4825* > > 237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 > > f4407c24c1f31d2304c8f8d48258.dat.gz > > 237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 > > f4407c24c1f31d2304c8f8d48258.dat.gz > > > > Same problem appear on kernels 2.6.11 and 2.6.12.6 (x86 and x86_x64). > > Have anyone already seen something like this? > > Nope. Any ideas on how to reproduce it? Is NFS being used? > Yep - we are reproducing every day - but not intentialy. No NFS used - just writting and reading files from partition (with o_direct and without it). Maybe is just that we have about 5 milion files on those partitions. > cheers. > From owner-linux-xfs@oss.sgi.com Tue Jan 17 15:19:49 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 15:19:50 -0800 (PST) Received: from flyingAngel.upjs.sk (static113-109.rudna.net [212.20.113.109]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0HNJem2022306 for ; Tue, 17 Jan 2006 15:19:48 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 292B3102F0D; Wed, 18 Jan 2006 00:17:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 246AF18011E; Wed, 18 Jan 2006 00:17:05 +0100 (CET) Date: Wed, 18 Jan 2006 00:17:04 +0100 (CET) From: Jan Derfinak To: Nathan Scott cc: c.pascoe@itee.uq.edu.au, linux-xfs@oss.sgi.com Subject: Re: TAKE 904196 - Merge up to 2.6.15 In-Reply-To: <20060117224440.GA945@frodo> Message-ID: References: <20060110062615.149BB494A272@chook.melbourne.sgi.com> <20060117224440.GA945@frodo> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7222 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: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 157 Lines: 10 On Wed, 18 Jan 2006, Nathan Scott wrote: > All the CVS export issues should now be resolved now (Works For Me (TM)). > It works for me too. Thanks. jan From owner-linux-xfs@oss.sgi.com Tue Jan 17 21:38:30 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 21:38:34 -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 k0I5cTm2024810 for ; Tue, 17 Jan 2006 21:38:30 -0800 Received: from kao2.melbourne.sgi.com (kao2.melbourne.sgi.com [134.14.55.180]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14470; Wed, 18 Jan 2006 16:39:20 +1100 Received: by kao2.melbourne.sgi.com (Postfix, from userid 16331) id 64119EB3; Wed, 18 Jan 2006 16:39:20 +1100 (EST) Received: from kao2.melbourne.sgi.com (localhost [127.0.0.1]) by kao2.melbourne.sgi.com (Postfix) with ESMTP id 5F4498018C; Wed, 18 Jan 2006 16:39:20 +1100 (EST) X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.1-RC1 From: Keith Owens To: Jan Engelhardt cc: linux-xfs@oss.sgi.com, Linux Kernel Mailing List Subject: Re: xfs depends on exportfs In-reply-to: Your message of "Tue, 17 Jan 2006 21:16:51 BST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 18 Jan 2006 16:39:20 +1100 Message-ID: <10055.1137562760@kao2.melbourne.sgi.com> X-archive-position: 7223 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: kaos@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 536 Lines: 12 Jan Engelhardt (on Tue, 17 Jan 2006 21:16:51 +0100 (MET)) wrote: >I could not find a clue on the first try on why xfs needs exportfs. >The Kconfig says "select EXPORTFS if CONFIG_NFSD!=n", but there are no >occurrences of CONFIG_NFS* or CONFIG_EXP* in any of the files in fs/xfs/. >Did I miss something or this a superfluous line in Kconfig? Interestingly >tho, `modinfo xfs.ko` returns "exportfs", so I suppose it's somewhere, well >hidden. If so, where? XFS uses find_exported_dentry(). Hint: nm fs/xfs/xfs.ko | grep ' U .*exp' From owner-linux-xfs@oss.sgi.com Tue Jan 17 21:55:25 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 17 Jan 2006 21:55:30 -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 k0I5tKm2026197 for ; Tue, 17 Jan 2006 21:55:25 -0800 Received: from agami.com ([192.168.168.119]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k0I5uNXM029430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 17 Jan 2006 21:56:27 -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 k0I5uHL5024003 for ; Tue, 17 Jan 2006 21:56:17 -0800 Received: from [192.168.0.207] ([10.123.200.1]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jan 2006 21:56:16 -0800 Message-ID: <43CDD795.3060005@agami.com> Date: Wed, 18 Jan 2006 11:22:21 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gorazd Golob CC: Nathan Scott , linux-xfs@oss.sgi.com Subject: Re: duplicate files References: <1137536698.10112.63.camel@dacun.noviforum.si> <20060118094945.I8500612@wobbly.melbourne.sgi.com> <1137539355.10112.84.camel@dacun.noviforum.si> In-Reply-To: <1137539355.10112.84.camel@dacun.noviforum.si> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 Jan 2006 05:56:17.0177 (UTC) FILETIME=[E5B95890:01C61BF3] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7224 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: 2003 Lines: 64 Hi, Can you try some other command instead of 'ls'. I suspect that the 'ls -lia' filter is doing something strange. I wish to rule out this possibility. Can you just do the following as well, meanwhile. find -name 'f4407c24c1f31d2304c8f8d4825*' Regards, Shailendra Gorazd Golob wrote: >>Can you send xfs_info output? >> > > This one is on 2.6.11 - x86 - partiton is on 72gb scsi drive: > meta-data=/xxxxx isize=256 agcount=16, agsize=4480124 blks > = sectsz=512 > data = bsize=1024 blocks=71681984, > imaxpct=25 > = sunit=0 swidth=0 blks, unwritten=1 > naming =version 2 bsize=4096 > log =internal bsize=1024 blocks=35000, version=1 > = sectsz=512 sunit=0 blks > realtime =none extsz=65536 blocks=0, rtextents=0 > > with xfsprogs-2.6.13 compiled for i486 > > And 2.6.12-6 - x86_64 - partition is on MD raid1 - but don't have > xfs_info on system - I'll have it tommorow - I guess ;) I have installed > xfsprogs-2.6.36 compiled for Intel's cpus with EM64T (nocona). > > Hardware for both systems is not the same. > > >>>- some (very rarerly but they does) files appear like this on file >>>system: >>> >>>$ ls -ila f4407c24c1f31d2304c8f8d4825* >>>237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 >>>f4407c24c1f31d2304c8f8d48258.dat.gz >>>237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 >>>f4407c24c1f31d2304c8f8d48258.dat.gz >>> >>>Same problem appear on kernels 2.6.11 and 2.6.12.6 (x86 and x86_x64). >>>Have anyone already seen something like this? >> >>Nope. Any ideas on how to reproduce it? Is NFS being used? >> > > Yep - we are reproducing every day - but not intentialy. No NFS used - > just writting and reading files from partition (with o_direct and > without it). Maybe is just that we have about 5 milion files on those > partitions. > > > >>cheers. >> > > > From owner-linux-xfs@oss.sgi.com Wed Jan 18 13:04:22 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Wed, 18 Jan 2006 13:04:28 -0800 (PST) Received: from elfstone.noviforum.si (elfstone.noviforum.si [193.189.169.107]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0IL4Mm2000901 for ; Wed, 18 Jan 2006 13:04:22 -0800 Received: from localhost (localhost [127.0.0.1]) by elfstone.noviforum.si (ESMTP) with ESMTP id 22BCF1B91E; Wed, 18 Jan 2006 22:05:29 +0100 (CET) Received: from dacun.noviforum.si (dacun.noviforum.si [192.168.2.26]) by elfstone.noviforum.si (ESMTP) with ESMTP id E9E351B91C; Wed, 18 Jan 2006 22:05:28 +0100 (CET) Subject: Re: duplicate files From: Gorazd Golob To: Shailendra Tripathi Cc: Nathan Scott , linux-xfs@oss.sgi.com In-Reply-To: <43CDD795.3060005@agami.com> References: <1137536698.10112.63.camel@dacun.noviforum.si> <20060118094945.I8500612@wobbly.melbourne.sgi.com> <1137539355.10112.84.camel@dacun.noviforum.si> <43CDD795.3060005@agami.com> Content-Type: text/plain Date: Wed, 18 Jan 2006 22:05:28 +0100 Message-Id: <1137618328.11603.63.camel@dacun.noviforum.si> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit X-archive-position: 7226 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: gorazd.golob@noviforum.si Precedence: bulk X-list: linux-xfs Content-Length: 2504 Lines: 76 What we've figured out so far is that "duplicate" files occur during create and write operation of new file. Chances that file will be "duplicated" are max 1 file per milion. The problem is that write fails (but content is written properly) And as I wrote in previous mail find is showing same as ls. Gorazd On Wed, 2006-01-18 at 11:22 +0530, Shailendra Tripathi wrote: > Hi, > Can you try some other command instead of 'ls'. I suspect that the 'ls > -lia' filter is doing something strange. I wish to rule out this > possibility. > > Can you just do the following as well, meanwhile. > > find -name 'f4407c24c1f31d2304c8f8d4825*' > > Regards, > Shailendra > > Gorazd Golob wrote: > >>Can you send xfs_info output? > >> > > > > This one is on 2.6.11 - x86 - partiton is on 72gb scsi drive: > > meta-data=/xxxxx isize=256 agcount=16, agsize=4480124 blks > > = sectsz=512 > > data = bsize=1024 blocks=71681984, > > imaxpct=25 > > = sunit=0 swidth=0 blks, unwritten=1 > > naming =version 2 bsize=4096 > > log =internal bsize=1024 blocks=35000, version=1 > > = sectsz=512 sunit=0 blks > > realtime =none extsz=65536 blocks=0, rtextents=0 > > > > with xfsprogs-2.6.13 compiled for i486 > > > > And 2.6.12-6 - x86_64 - partition is on MD raid1 - but don't have > > xfs_info on system - I'll have it tommorow - I guess ;) I have installed > > xfsprogs-2.6.36 compiled for Intel's cpus with EM64T (nocona). > > > > Hardware for both systems is not the same. > > > > > >>>- some (very rarerly but they does) files appear like this on file > >>>system: > >>> > >>>$ ls -ila f4407c24c1f31d2304c8f8d4825* > >>>237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 > >>>f4407c24c1f31d2304c8f8d48258.dat.gz > >>>237047122 -rw-r--r-- 1 xxx yyy 6107 2006-01-16 23:33 > >>>f4407c24c1f31d2304c8f8d48258.dat.gz > >>> > >>>Same problem appear on kernels 2.6.11 and 2.6.12.6 (x86 and x86_x64). > >>>Have anyone already seen something like this? > >> > >>Nope. Any ideas on how to reproduce it? Is NFS being used? > >> > > > > Yep - we are reproducing every day - but not intentialy. No NFS used - > > just writting and reading files from partition (with o_direct and > > without it). Maybe is just that we have about 5 milion files on those > > partitions. > > > > > > > >>cheers. > >> > > > > > > From owner-linux-xfs@oss.sgi.com Thu Jan 19 01:40:16 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Jan 2006 01:40:17 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0J9eFm2015998 for ; Thu, 19 Jan 2006 01:40:16 -0800 Received: by wproxy.gmail.com with SMTP id i32so161562wra for ; Thu, 19 Jan 2006 01:41:23 -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=fE1vq4CNyuNlpuTyx1pnUI1dnIKElLjoHowmH56UqGifweGv2zQsI+zKmPx8+axbA1eN5EUZwearHwz8xbob63C+6gc9EpgZfcYsf2j6O7fJSpK++dMfvbe+Ie9w5vGcy3cJiP9mwyRO08Yc6BgoxuZzfO1Nb+IvZrYDdA1fxxM= Received: by 10.54.122.13 with SMTP id u13mr491539wrc; Thu, 19 Jan 2006 00:36:42 -0800 (PST) Received: by 10.54.96.19 with HTTP; Thu, 19 Jan 2006 00:36:42 -0800 (PST) Message-ID: <83cd3f900601190036u199be661y1ef2398ab721c49@mail.gmail.com> Date: Thu, 19 Jan 2006 00:36:42 -0800 From: Muhammad Khaleel To: linux-xfs@oss.sgi.com Subject: FASTEST FILESYSTEM MIME-Version: 1.0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit X-archive-position: 7227 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: khaleel5000@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 154 Lines: 6 Hello i am a newbie and wanted 2 ask whick filesystem would be the fastest the XFS or reiser4 ? or any third one ?? [[HTML alternate version deleted]] From owner-linux-xfs@oss.sgi.com Thu Jan 19 01:49:12 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Jan 2006 01:49:17 -0800 (PST) Received: from lucidpixels.com (lucidpixels.com [66.45.37.187]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0J9nCm2016816 for ; Thu, 19 Jan 2006 01:49:12 -0800 Received: by lucidpixels.com (Postfix, from userid 1001) id B7B8E1A11DC63; Thu, 19 Jan 2006 04:50:17 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by lucidpixels.com (Postfix) with ESMTP id A511FA0A42E6; Thu, 19 Jan 2006 04:50:17 -0500 (EST) Date: Thu, 19 Jan 2006 04:50:17 -0500 (EST) From: Justin Piszcz X-X-Sender: jpiszcz@p34 To: Muhammad Khaleel cc: linux-xfs@oss.sgi.com Subject: Re: FASTEST FILESYSTEM In-Reply-To: <83cd3f900601190036u199be661y1ef2398ab721c49@mail.gmail.com> Message-ID: References: <83cd3f900601190036u199be661y1ef2398ab721c49@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7228 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: jpiszcz@lucidpixels.com Precedence: bulk X-list: linux-xfs Content-Length: 425 Lines: 17 Please see: http://linuxgazette.net/122/piszcz.html You may wish to consider which filesystem is also the most stable, how long it takes to recover from an unclean shutdown, filesystem mount times and so on. On Thu, 19 Jan 2006, Muhammad Khaleel wrote: > Hello i am a newbie and wanted 2 ask whick filesystem would be the fastest > the XFS or reiser4 ? or any third one ?? > > > [[HTML alternate version deleted]] > > From owner-linux-xfs@oss.sgi.com Thu Jan 19 02:03:26 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Jan 2006 02:03:33 -0800 (PST) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0JA3Pm2018553 for ; Thu, 19 Jan 2006 02:03:25 -0800 Received: (qmail 30367 invoked from network); 19 Jan 2006 10:04:31 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.132.18.199 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 19 Jan 2006 10:04:31 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id CBCD151ED20; Thu, 19 Jan 2006 02:04:27 -0800 (PST) Date: Thu, 19 Jan 2006 02:04:27 -0800 From: Chris Wedgwood To: Muhammad Khaleel Cc: linux-xfs@oss.sgi.com Subject: Re: FASTEST FILESYSTEM Message-ID: <20060119100427.GA18353@taniwha.stupidest.org> References: <83cd3f900601190036u199be661y1ef2398ab721c49@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83cd3f900601190036u199be661y1ef2398ab721c49@mail.gmail.com> X-archive-position: 7229 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 195 Lines: 7 On Thu, Jan 19, 2006 at 12:36:42AM -0800, Muhammad Khaleel wrote: > Hello i am a newbie and wanted 2 ask whick filesystem would be the > fastest the XFS or reiser4 ? or any third one ?? tmpfs From owner-linux-xfs@oss.sgi.com Thu Jan 19 09:28:08 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 19 Jan 2006 09:28:16 -0800 (PST) Received: from flyingAngel.upjs.sk ([212.20.113.109]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0JHS7m2026954 for ; Thu, 19 Jan 2006 09:28:07 -0800 Received: by flyingAngel.upjs.sk (Postfix, from userid 500) id 088D0102F19; Thu, 19 Jan 2006 18:25:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by flyingAngel.upjs.sk (Postfix) with ESMTP id 0792918012E; Thu, 19 Jan 2006 18:25:09 +0100 (CET) Date: Thu, 19 Jan 2006 18:25:08 +0100 (CET) From: Jan Derfinak To: Nathan Scott cc: linux-xfs@oss.sgi.com Subject: Re: TAKE 947953 - fix follow_link In-Reply-To: <20060111225900.8C01348757E7@chook.melbourne.sgi.com> Message-ID: References: <20060111225900.8C01348757E7@chook.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7230 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: ja@mail.upjs.sk Precedence: bulk X-list: linux-xfs Content-Length: 573 Lines: 18 On Thu, 12 Jan 2006, Nathan Scott wrote: Hello. It seems again that public cvs is not synchronized. This TAKE and TAKE 948197 are not visible for public. > Modid: xfs-linux-melb:xfs-kern:24962a > linux-2.6/xfs_iops.c - 1.235 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/> linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.235&r2=text&tr2=1.234&f=h > http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.235&r2=text&tr2=1.234&f=h grep xfs_iops.c fs/xfs/linux-2.6/CVS/Entries /xfs_iops.c/1.234/Wed Dec 21 16:50:39 2005/-ko/ jan From owner-linux-xfs@oss.sgi.com Fri Jan 20 07:37:39 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 20 Jan 2006 07:37:42 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0KFbbm2001727 for ; Fri, 20 Jan 2006 07:37:38 -0800 Received: (qmail 8228 invoked by uid 0); 20 Jan 2006 14:38:44 -0000 Received: from 84.131.117.228 by www068.gmx.net with HTTP; Fri, 20 Jan 2006 15:38:44 +0100 (MET) Date: Fri, 20 Jan 2006 15:38:44 +0100 (MET) From: =?ISO-8859-1?Q?=22J=F6rg_Thiel=22?= To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Subject: Missing Superblock X-Priority: 3 (Normal) X-Authenticated: #13874924 Message-ID: <14536.1137767924@www068.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-archive-position: 7231 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: j-t1@gmx.net Precedence: bulk X-list: linux-xfs Content-Length: 2707 Lines: 72 Hello All! I have a problem with an XFS on a crypted device. The XFS worked fine using a cryptoloop on an external USB disc. I mounted and unmounted ist several times without any problems. After rebooting the computer I cannot mount the fs anymore. dmesg output is: loop: registered Twofish encryption SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled SGI XFS Quota Management subsystem XFS mounting filesystem loop2 XFS: Log inconsistent (didn't find previous header) XFS: failed to find log head XFS: log mount/recovery failed: error 5 XFS: log mount failed xfs_check /dev/loop2 says: xfs_check: cannot read root inode (22) xfs_check: cannot read realtime summary inode (22) xfs_check: device /dev/loop2 unusable (not an XFS filesystem?) and xfs_repair: xfs_repair /dev/loop2 Phase 1 - find and verify superblock... couldn't verify primary superblock - not enough secondary superblocks with matching geometry !!! attempting to find secondary superblock... dumping the first block: dd if=/dev/loop2 of=blocks bs=512 count=1 and od -xa blocks: 0000000 4658 4253 0000 0010 0000 0000 5d04 008f X F S B nul nul dle nul nul nul nul nul eot ] si nul 0000020 0000 0000 0000 0000 0000 0000 0000 0000 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul 0000040 f768 a3df 335c 1c4e 11b6 38f6 050e 47aa h w _ # \ 3 N fs 6 dc1 v 8 so enq * G 0000060 0000 0000 0004 0400 0000 0000 0000 8000 nul nul nul nul eot nul nul eot nul nul nul nul nul nul nul nul 0000100 0000 0000 0000 8100 0000 0000 0000 8200 nul nul nul nul nul nul nul soh nul nul nul nul nul nul nul stx 0000120 0000 1000 4500 f0d8 0000 1000 0000 0000 nul nul nul dle nul E X p nul nul nul dle nul nul nul nul 0000140 0000 0080 8430 0002 0001 1000 0000 0000 nul nul nul nul 0 eot stx nul soh nul nul dle nul nul nul nul 0000160 0000 0000 0000 0000 090c 0408 0017 1900 nul nul nul nul nul nul nul nul ff ht bs eot etb nul nul em 0000200 0000 0000 0100 803e 0000 0000 0000 2301 nul nul nul nul nul soh > nul nul nul nul nul nul nul soh # 0000220 0000 0000 9001 6d84 0000 0000 0000 0000 nul nul nul nul soh dle eot m nul nul nul nul nul nul nul nul 0000240 0000 0000 0000 0000 0000 0000 0000 0000 The decryption doesn't seem to be the problem as doing a cat /dev/loop2 | strings shows the correct content of some ascii files and the data above seem to be some XFS stuff. Has anyone any idea how i can get my 200Gig of data back???? Thanks for help! Jörg -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie From owner-linux-xfs@oss.sgi.com Sat Jan 21 16:08:30 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 21 Jan 2006 16:08:35 -0800 (PST) Received: from cne142.neoplus.adsl.tpnet.pl (aarv92.neoplus.adsl.tpnet.pl [83.5.207.92]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0M08Sm2028453 for ; Sat, 21 Jan 2006 16:08:29 -0800 Received: from satan.blackhosts (localhost [127.0.0.1]) by cne142.neoplus.adsl.tpnet.pl (8.13.3/8.13.3) with ESMTP id k0LLVWg0022700 for ; Sat, 21 Jan 2006 22:31:33 +0100 Received: (from qboosh@localhost) by satan.blackhosts (8.13.3/8.13.3/Submit) id k0LLVWhP022697 for linux-xfs@oss.sgi.com; Sat, 21 Jan 2006 22:31:32 +0100 Date: Sat, 21 Jan 2006 22:31:32 +0100 From: Jakub Bogusz To: linux-xfs@oss.sgi.com Subject: Polish translation for xfsprogs and update for attr Message-ID: <20060121213132.GA22501@fngna.oyu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="k1lZvvs/B4yU6o8G" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.5.9i X-archive-position: 7233 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: qboosh@pld-linux.org Precedence: bulk X-list: linux-xfs Content-Length: 7445 Lines: 235 --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I made Polish translation for xfsprogs package, it's available at http://qboosh.cs.net.pl/pl.po/xfsprogs-2.7.11.pl.po (to be added as po/pl.po to package, then pl should be added to LINGUAS in Makefile) I noticed that xfsprogs.pot included in package is outdated, and even XGETTEXTFILES list in po/Makefile is out of date... Attached patch (xfsprogs-po.patch) updates XGETTEXTFILES and fixes "initializer is not constant" errors, which appear when building xfsprogs with gettext support (at least using gcc 4.x). I've also updated pl.po for attr 2.4.28 - patch attached (attr-pl.po-update.patch). BTW: attr.pot included in attr-2.4.28 package is outdated too. -- Jakub Bogusz http://qboosh.cs.net.pl/ --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="xfsprogs-po.patch" --- xfsprogs-2.7.10/po/Makefile.orig 2006-01-14 19:17:22.717637750 +0100 +++ xfsprogs-2.7.10/po/Makefile 2006-01-14 19:28:41.960087750 +0100 @@ -6,39 +6,49 @@ include $(TOPDIR)/include/builddefs # Currently LINGUAS is undefined, so buildmacros provides no targets. -LINGUAS = +LINGUAS = pl LSRCFILES = $(LINGUAS:%=%.po) $(PKG_NAME).pot # TODO: db/ logprint/ XGETTEXTFILES = \ - $(TOPDIR)/growfs/explore.c \ + $(TOPDIR)/copy/xfs_copy.c \ $(TOPDIR)/growfs/xfs_growfs.c \ - $(TOPDIR)/imap/xfs_imap.c \ + $(TOPDIR)/io/attr.c \ $(TOPDIR)/io/bmap.c \ - $(TOPDIR)/io/command.c \ $(TOPDIR)/io/fadvise.c \ $(TOPDIR)/io/file.c \ $(TOPDIR)/io/freeze.c \ $(TOPDIR)/io/fsync.c \ - $(TOPDIR)/io/help.c \ + $(TOPDIR)/io/getrusage.c \ + $(TOPDIR)/io/imap.c \ $(TOPDIR)/io/init.c \ $(TOPDIR)/io/inject.c \ - $(TOPDIR)/io/input.c \ + $(TOPDIR)/io/madvise.c \ + $(TOPDIR)/io/mincore.c \ $(TOPDIR)/io/mmap.c \ $(TOPDIR)/io/open.c \ + $(TOPDIR)/io/parent.c \ $(TOPDIR)/io/pread.c \ $(TOPDIR)/io/prealloc.c \ $(TOPDIR)/io/pwrite.c \ - $(TOPDIR)/io/quit.c \ $(TOPDIR)/io/resblks.c \ + $(TOPDIR)/io/sendfile.c \ $(TOPDIR)/io/shutdown.c \ $(TOPDIR)/io/truncate.c \ - $(TOPDIR)/mkfile/xfs_mkfile.c \ - $(TOPDIR)/mkfs/proto.c \ - $(TOPDIR)/mkfs/xfs_mkfs.c \ + $(TOPDIR)/libdisk/dm.c \ $(TOPDIR)/libdisk/drivers.c \ + $(TOPDIR)/libdisk/evms.c \ + $(TOPDIR)/libdisk/fstype.c \ $(TOPDIR)/libdisk/lvm.c \ $(TOPDIR)/libdisk/md.c \ + $(TOPDIR)/libdisk/pttype.c \ + $(TOPDIR)/libdisk/xvm.c \ + $(TOPDIR)/libxcmd/command.c \ + $(TOPDIR)/libxcmd/help.c \ + $(TOPDIR)/libxcmd/input.c \ + $(TOPDIR)/libxcmd/paths.c \ + $(TOPDIR)/libxcmd/projects.c \ + $(TOPDIR)/libxcmd/quit.c \ $(TOPDIR)/libxfs/darwin.c \ $(TOPDIR)/libxfs/freebsd.c \ $(TOPDIR)/libxfs/init.c \ @@ -48,6 +58,18 @@ $(TOPDIR)/libxfs/trans.c \ $(TOPDIR)/libxfs/util.c \ $(TOPDIR)/libxlog/util.c \ + $(TOPDIR)/mkfs/proto.c \ + $(TOPDIR)/mkfs/xfs_mkfs.c \ + $(TOPDIR)/quota/edit.c \ + $(TOPDIR)/quota/free.c \ + $(TOPDIR)/quota/init.c \ + $(TOPDIR)/quota/path.c \ + $(TOPDIR)/quota/project.c \ + $(TOPDIR)/quota/quot.c \ + $(TOPDIR)/quota/quota.c \ + $(TOPDIR)/quota/report.c \ + $(TOPDIR)/quota/state.c \ + $(TOPDIR)/quota/util.c \ $(TOPDIR)/repair/agheader.c \ $(TOPDIR)/repair/attr_repair.c \ $(TOPDIR)/repair/avl.c \ --- xfsprogs-2.7.11/quota/util.c.orig 2006-01-17 04:46:52.000000000 +0100 +++ xfsprogs-2.7.11/quota/util.c 2006-01-21 19:41:12.312619500 +0100 @@ -190,7 +190,7 @@ form_to_string( uint form) { - static char *forms[] = { + char *forms[] = { _("Blocks"), _("Inodes"), _("Realtime Blocks") }; if (form & XFS_BLOCK_QUOTA) @@ -206,7 +206,7 @@ type_to_string( uint type) { - static char *types[] = { _("User"), _("Group"), _("Project") }; + char *types[] = { _("User"), _("Group"), _("Project") }; if (type & XFS_USER_QUOTA) return types[0]; --k1lZvvs/B4yU6o8G Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: attachment; filename="attr-pl.po-update.patch" Content-Transfer-Encoding: 8bit --- attr-2.4.28/po/pl.po.orig 2006-01-12 06:06:29.000000000 +0100 +++ attr-2.4.28/po/pl.po 2006-01-21 21:15:43.579051500 +0100 @@ -5,40 +5,42 @@ # msgid "" msgstr "" -"Project-Id-Version: attr-2.4.23\n" +"Project-Id-Version: attr-2.4.28\n" "POT-Creation-Date: 2004-01-28 21:04+0100\n" -"PO-Revision-Date: 2005-08-06 18:24+0200\n" +"PO-Revision-Date: 2006-01-21 21:13+0100\n" "Last-Translator: Jakub Bogusz \n" "Language-Team: Polish \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=ISO-8859-2\n" "Content-Transfer-Encoding: 8bit\n" -#: ../attr/attr.c:57 +#: ../attr/attr.c:46 #, c-format msgid "" "Usage: %s [-LRSq] -s attrname [-V attrvalue] pathname # set value\n" " %s [-LRSq] -g attrname pathname # get value\n" " %s [-LRSq] -r attrname pathname # remove attr\n" +" %s [-LRq] -l pathname # list attrs \n" " -s reads a value from stdin and -g writes a value to stdout\n" msgstr "" "Sk³adnia: %s [-LRSq] -s atrybut [-V warto¶æ] ¶cie¿ka # ustawienie warto¶ci\n" " %s [-LRSq] -g atrybut ¶cie¿ka # odczytanie warto¶ci\n" " %s [-LRSq] -r atrybut ¶cie¿ka # usuniêcie atrybutu\n" +" %s [-LRq] -l ¶cie¿ka # lista atrybutów\n" " -s odczytuje warto¶æ ze standardowego wej¶cia,\n" " -g zapisuje na standardowe wyj¶cie\n" -#: ../attr/attr.c:90 ../attr/attr.c:108 ../attr/attr.c:117 +#: ../attr/attr.c:83 ../attr/attr.c:100 ../attr/attr.c:109 ../attr/attr.c:118 #, c-format -msgid "Only one of -s, -g, or -r allowed\n" -msgstr "Dozwolone jest tylko jedno z -s, -g lub -r\n" +msgid "Only one of -s, -g, -r, or -l allowed\n" +msgstr "Dozwolone jest tylko jedno z -s, -g, -r lub -l\n" -#: ../attr/attr.c:99 +#: ../attr/attr.c:91 #, c-format msgid "-V only allowed with -s\n" msgstr "-V dozwolone tylko z -s\n" -#: ../attr/attr.c:137 +#: ../attr/attr.c:136 #, c-format msgid "Unrecognized option: %c\n" msgstr "Nierozpoznana opcja: %c\n" @@ -58,25 +60,35 @@ msgid "Attribute \"%s\" set to a %d byte value for %s:\n" msgstr "Atrybut \"%1$s\" dla %3$s ustawiono na warto¶æ %2$d-bajtow±:\n" -#: ../attr/attr.c:197 +#: ../attr/attr.c:194 #, c-format msgid "Could not get \"%s\" for %s\n" msgstr "Nie mo¿na odczytaæ \"%s\" dla %s\n" -#: ../attr/attr.c:202 +#: ../attr/attr.c:199 #, c-format msgid "Attribute \"%s\" had a %d byte value for %s:\n" msgstr "Atrybut \"%1$s\" dla %3$s mia³ warto¶æ %2$d-bajtow±:\n" -#: ../attr/attr.c:218 +#: ../attr/attr.c:212 #, c-format msgid "Could not remove \"%s\" for %s\n" msgstr "Nie mo¿na usun±æ \"%s\" dla %s\n" -#: ../attr/attr.c:226 +#: ../attr/attr.c:230 #, c-format -msgid "At least one of -s, -g, or -r is required\n" -msgstr "Wymagane jest jedno z -s, -g lub -r\n" +msgid "Could not list \"%s\" for %s\n" +msgstr "Nie mo¿na wypisaæ listy \"%s\" dla %s\n" + +#: ../attr/attr.c:240 +#, c-format +msgid "Attribute \"%s\" has a %d byte value for %s\n" +msgstr "Atrybut \"%1$s\" dla %3$s ma warto¶æ %2$d-bajtow±\n" + +#: ../attr/attr.c:252 +#, c-format +msgid "At least one of -s, -g, -r, or -l is required\n" +msgstr "Wymagane jest co najmniej jedno z -s, -g, -r lub -l\n" #: ../getfattr/getfattr.c:98 ../setfattr/setfattr.c:70 msgid "No such attribute" --k1lZvvs/B4yU6o8G-- From owner-linux-xfs@oss.sgi.com Mon Jan 23 07:26:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Jan 2006 07:26:46 -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 k0NFQgm2027159 for ; Mon, 23 Jan 2006 07:26:42 -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 k0NHScgN026503 for ; Mon, 23 Jan 2006 09:28:38 -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 k0NFQhQT29768030; Mon, 23 Jan 2006 09:26:44 -0600 (CST) Message-ID: <43D4F5B2.7020007@sgi.com> Date: Mon, 23 Jan 2006 09:26:42 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakub Bogusz CC: linux-xfs@oss.sgi.com Subject: Re: Polish translation for xfsprogs and update for attr References: <20060121213132.GA22501@fngna.oyu> In-Reply-To: <20060121213132.GA22501@fngna.oyu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7236 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: 930 Lines: 27 Jakub Bogusz wrote: > Hello, > > I made Polish translation for xfsprogs package, it's available at > > http://qboosh.cs.net.pl/pl.po/xfsprogs-2.7.11.pl.po > > (to be added as po/pl.po to package, then pl should be added to LINGUAS > in Makefile) > I noticed that xfsprogs.pot included in package is outdated, and even > XGETTEXTFILES list in po/Makefile is out of date... > Attached patch (xfsprogs-po.patch) updates XGETTEXTFILES and fixes > "initializer is not constant" errors, which appear when building xfsprogs > with gettext support (at least using gcc 4.x). > > I've also updated pl.po for attr 2.4.28 - patch attached > (attr-pl.po-update.patch). > BTW: attr.pot included in attr-2.4.28 package is outdated too. > Thank you Jakub - Nathan usually handles this stuff, so it may not get rolled in until he gets back from a trip. But it's very appreciated, thank you! -Eric (who should read up on i18n some day!) From owner-linux-xfs@oss.sgi.com Mon Jan 23 07:36:30 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Jan 2006 07:36:31 -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 k0NFaTm2027895 for ; Mon, 23 Jan 2006 07:36:29 -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 k0NHcR6M028318 for ; Mon, 23 Jan 2006 09:38:27 -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 k0NFaWQT29773403; Mon, 23 Jan 2006 09:36:33 -0600 (CST) Message-ID: <43D4F800.8050406@sgi.com> Date: Mon, 23 Jan 2006 09:36:32 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?J=F6rg_Thiel?= CC: linux-xfs@oss.sgi.com Subject: Re: Missing Superblock on encrypted fs References: <14536.1137767924@www068.gmx.net> In-Reply-To: <14536.1137767924@www068.gmx.net> Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-archive-position: 7237 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: 597 Lines: 23 Jörg Thiel wrote: > xfs_repair /dev/loop2 > Phase 1 - find and verify superblock... > couldn't verify primary superblock - not enough secondary superblocks with > matching geometry !!! Not sure offhand, and I don't have any experience with xfs on crypto block devices... For starters, how about xfs_db -r /dev/loop2, then: xfs_db> sb 0 xfs_db> p xfs_db> sb 1 xfs_db> p ... etc, to see how the various superblocks differ & why repair doesn't think they match (note, there will normally be some variation in a few fields, as not all superblocks are fully filled out at mkfs time... ) -Eric From owner-linux-xfs@oss.sgi.com Mon Jan 23 09:14:06 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Jan 2006 09:14:10 -0800 (PST) Received: from mail.sessys.com (24-151-19-179.dhcp.nwtn.ct.charter.com [24.151.19.179] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0NHE5m2004897 for ; Mon, 23 Jan 2006 09:14:05 -0800 Received: from mail.sessys.com (mail.sessys.com [192.168.0.2]) by mail.sessys.com (8.13.4/8.13.4-SES) with ESMTP id k0NG6K4S011110 for ; Mon, 23 Jan 2006 11:06:20 -0500 Date: Mon, 23 Jan 2006 11:06:20 -0500 (EST) From: "Sean P. Elble" To: linux-xfs@oss.sgi.com Subject: Problems With 2.4 XFS-NFS CVS Tree/Linux 2.6.15.1 Client Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7238 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: elbles@sessys.com Precedence: bulk X-list: linux-xfs Content-Length: 3571 Lines: 73 Hi, I have 2 servers setup, one is strictly a file server with a 100 GB drive formatted with XFS (with the operating system residing on another drive formatted as ext2), exporting shares via NFS from both the XFS partition and the ext2 partitions. The ext2 partitions export fine, and can be read fine on the "client" (really, the server that does most of the work, which is running the 2.6.15.1 kernel), but there are major issues with the XFS partition. It seems to export fine, and I can run an ls at the top of the NFS mount, but nothing else works, and I mean nothing else. What follows is the output of the mount, pwd, and ls commands on the client: /dev/md0 on / type ext3 (rw) /dev/proc on /proc type proc (rw) /dev/sys on /sys type sysfs (rw) /dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620) /dev/sda1 on /boot type ext3 (rw) /dev/shm on /dev/shm type tmpfs (rw) /dev/md1 on /usr type ext3 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) /proc on /var/named/chroot/proc type none (rw,bind) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) intranet:/ on /mnt/intranet type nfs (rw,addr=192.168.0.1) intranet:/home on /mnt/intranet_home type nfs (rw,addr=192.168.0.1) /mnt/intranet_home ls: cannot read symbolic link ftp: Input/output error total 24K drwxr-xr-x 6 root root 68 Jan 17 13:14 . drwxr-xr-x 4 root root 4.0K Jan 14 01:58 .. lrwxrwxrwx 1 root root 25 Jul 23 2005 ftp drwxr-xr-x 6 elbles admin 57 Jan 14 21:07 httpd drwxr-xr-x 380 elbles admin 12K Dec 15 13:32 mp3s drwxr-xr-x 2 root root 22 Dec 17 02:04 netlogon drwxr-xr-x 9 root root 98 Jul 23 2005 network $[elbles@zeus intranet_home]$ cd mp3s/ -bash: cd: mp3s/: Stale NFS file handle That same message occurs for any instance of file access on the client, on that NFS export. Normally, I'd think a NFS problem, but since this only happens on the XFS file system, I'm thinking it's a bug in the XFS code. The NFS server is running a CVS checkout of the 2.4 XFS tree from sometime around 11:00 PM EST on January 19th. And yes, I know it is not wise to run a CVS tree of a kernel on a machine, but this machine needs to run a recent 2.4 kernel, and I also need POSIX ACL support (in addition to XFS) support. Also, some quick output from the NFS server from nfsstat: Server rpc stats: calls badcalls badauth badclnt xdrcall 457 4 4 0 0 Server nfs v2: null getattr setattr root lookup readlink 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% read wrcache write create remove rename 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% link symlink mkdir rmdir readdir fsstat 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% Server nfs v3: null getattr setattr lookup access readlink 8 1% 49 10% 0 0% 32 7% 24 5% 11 2% read write create mkdir symlink mknod 0 0% 0 0% 0 0% 0 0% 0 0% 0 0% remove rmdir rename link readdir readdirplus 0 0% 0 0% 0 0% 0 0% 0 0% 11 2% fsstat fsinfo pathconf commit 318 69% 4 0% 0 0% 0 0% There are *NO* messages in the dmesg log or /var/log/messages about NFS. If anyone needs more information, I will gladly post it ASAP. If anyone can help me with this issue, I'd really appreciate it. Thanks, in advance. -Sean Elble From owner-linux-xfs@oss.sgi.com Mon Jan 23 12:28:58 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Jan 2006 12:28:59 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0NKSvm2021532 for ; Mon, 23 Jan 2006 12:28:58 -0800 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id k0NKU2GN011814 for ; Mon, 23 Jan 2006 12:30:03 -0800 Message-ID: <43D53CCA.3010808@tlinx.org> Date: Mon, 23 Jan 2006 12:30:02 -0800 From: Linda Walsh User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en, en_US MIME-Version: 1.0 To: Linux-Xfs Subject: xfsdump, fs-attr "d" & directories Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7239 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 597 Lines: 19 I was wondering, regarding the "d" attribute on files. It says it specifies not to dump the specific file. Is support for marking directories non-dumpable planned? Should would be nice to partition off certain directories and anything underneath them as items not to be dumped, for example I might want to dump "/var", as many system settings are stored there, but may not care to dump contents of /var/tmp, or /var/squid/cache. But with those directories, setting the "d" on individual files isn't a great solution. Would be nice to disable dumping of those entire directory trees. Linda From owner-linux-xfs@oss.sgi.com Mon Jan 23 14:04:37 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Jan 2006 14:04:40 -0800 (PST) Received: from mail.davidb.org (mail.davidb.org [66.93.32.219]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0NM4am2027669 for ; Mon, 23 Jan 2006 14:04:37 -0800 Received: from davidb by mail.davidb.org with local (Exim 4.54 #1 (Debian)) id 1F18ex-00055B-8b; Mon, 23 Jan 2006 12:51:31 -0800 Date: Mon, 23 Jan 2006 12:51:31 -0800 From: David Brown To: Linda Walsh Cc: Linux-Xfs Subject: Re: xfsdump, fs-attr "d" & directories Message-ID: <20060123205131.GA19438@old.davidb.org> Mail-Followup-To: Linda Walsh , Linux-Xfs References: <43D53CCA.3010808@tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D53CCA.3010808@tlinx.org> User-Agent: Mutt/1.5.11 X-archive-position: 7240 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: davidb@davidb.org Precedence: bulk X-list: linux-xfs Content-Length: 559 Lines: 19 On Mon, Jan 23, 2006 at 12:30:02PM -0800, Linda Walsh wrote: > I was wondering, regarding the "d" attribute on files. > > It says it specifies not to dump the specific file. > > Is support for marking directories non-dumpable planned? The 'd' attribute on directories will be inherited by any new files or directories that are created under it. To start, you'll want to do a recursive set of the attribute 'chattr -R'. Once you set the attribute on the directory, newly created entities will also get it. Be sure to also specify '-e' to xfsdump. Dave From owner-linux-xfs@oss.sgi.com Mon Jan 23 18:16:16 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 23 Jan 2006 18:16:23 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0O2GGm2024429 for ; Mon, 23 Jan 2006 18:16:16 -0800 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id k0O2GnRo003904; Mon, 23 Jan 2006 18:16:50 -0800 Message-ID: <43D58E10.4010605@tlinx.org> Date: Mon, 23 Jan 2006 18:16:48 -0800 From: Linda Walsh User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en, en_US MIME-Version: 1.0 To: David Brown CC: Linux-Xfs Subject: Re: xfsdump, fs-attr "d" & directories References: <43D53CCA.3010808@tlinx.org> <20060123205131.GA19438@old.davidb.org> In-Reply-To: <20060123205131.GA19438@old.davidb.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7241 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: xfs@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 854 Lines: 31 David Brown wrote: >On Mon, Jan 23, 2006 at 12:30:02PM -0800, Linda Walsh wrote: > > >>I was wondering, regarding the "d" attribute on files. >>It says it specifies not to dump the specific file. >>Is support for marking directories non-dumpable planned? >> >> >The 'd' attribute on directories will be inherited by any new files or >directories that are created under it. > >To start, you'll want to do a recursive set of the attribute 'chattr -R'. >Once you set the attribute on the directory, newly created entities will >also get it. > >Be sure to also specify '-e' to xfsdump. > > --- Thanks! That inherited 'd' is an interesting behavior. Is it new? Where would it have been documented for me to have looked it up myself? Don't see it under my 'chattr' or 'xfsdump' man pages (though they might be dated...) Thanks again! Linda From owner-linux-xfs@oss.sgi.com Tue Jan 24 07:23:41 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Jan 2006 07:23:46 -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 k0OFNbm2030236 for ; Tue, 24 Jan 2006 07:23:41 -0800 Received: from agami.com ([192.168.168.149]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k0OFOemF016004 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 24 Jan 2006 07:24:40 -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 k0OFOZr1031406 for ; Tue, 24 Jan 2006 07:24:35 -0800 Received: from [192.168.0.207] ([10.123.200.1]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 07:24:33 -0800 Message-ID: <43D645CD.3030102@agami.com> Date: Tue, 24 Jan 2006 20:50:45 +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: No local regular files References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 15:24:34.0621 (UTC) FILETIME=[47DCE6D0:01C620FA] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7244 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: 1348 Lines: 33 Hi, I had an impression that XFS writes the data on the inode itself if data is pretty small. However, recently I came to know that for regular files it does not do the same, at least on Linux XFS. xfs_iformat() .... /* * no local regular files yet */ if (unlikely((INT_GET(dip->di_core.di_mode, ARCH_CONVERT ) & S_IFMT) == S_IFREG)) { xfs_fs_cmn_err(CE_WARN, ip->i_mount, "corrupt inode (local format for regular file) %Lu. Unmount and run xfs_repair.", (unsigned long long) ip->i_ino); XFS_CORRUPTION_ERROR("xfs_iformat(4)", XFS_ERRLEVEL_LOW, ip->i_mount, dip); return XFS_ERROR(EFSCORRUPTED); } Am wondering what might be the reason for non-inclusion and whether it was ever implemented in XFS ? If implemented on IRIX XFS, what is potential reason for not being available on Linux ? Or, it is just that it does not give any benefit. I believe that there are significant number of such small files Regards, Shailendra From owner-linux-xfs@oss.sgi.com Tue Jan 24 07:39:09 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Jan 2006 07:39:13 -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 k0OFd9m2032081 for ; Tue, 24 Jan 2006 07:39:09 -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 k0OHfDSn016135 for ; Tue, 24 Jan 2006 09:41:13 -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 k0OFdAQT29836860; Tue, 24 Jan 2006 09:39:11 -0600 (CST) Message-ID: <43D64A1E.4030005@sgi.com> Date: Tue, 24 Jan 2006 09:39:10 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shailendra Tripathi CC: linux-xfs@oss.sgi.com Subject: Re: No local regular files References: <43D645CD.3030102@agami.com> In-Reply-To: <43D645CD.3030102@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7245 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: 752 Lines: 25 Shailendra Tripathi wrote: > Am wondering what might be the reason for non-inclusion and whether > it was ever implemented in XFS ? If implemented on IRIX XFS, what is > potential reason for not being available on Linux ? Or, it is just that > it does not give any benefit. I believe that there are significant > number of such small files I don't think this behavior is any different from Irix: xfs3 1# cd /tmp xfs3 2# touch foo xfs3 3# xfs_bmap -v foo foo: no extents xfs3 4# echo a > foo xfs3 5# xfs_bmap -v foo foo: EXT: FILE-OFFSET BLOCK-RANGE AG AG-OFFSET TOTAL FLG 0: [0..7]: 11168..11175 0 11168..11175 8 xfs3 6# du foo 8 foo xfs3 7# uname -a IRIX64 cxfs3 6.5 07010238 IP27 -Eric From owner-linux-xfs@oss.sgi.com Tue Jan 24 09:04:54 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Jan 2006 09:05:03 -0800 (PST) Received: from smtp109.sbc.mail.mud.yahoo.com (smtp109.sbc.mail.mud.yahoo.com [68.142.198.208]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0OH4sm2009813 for ; Tue, 24 Jan 2006 09:04:54 -0800 Received: (qmail 34368 invoked from network); 24 Jan 2006 17:01:55 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.132.18.199 with login) by smtp109.sbc.mail.mud.yahoo.com with SMTP; 24 Jan 2006 17:01:55 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id A719251FB80; Tue, 24 Jan 2006 09:01:54 -0800 (PST) Date: Tue, 24 Jan 2006 09:01:54 -0800 From: Chris Wedgwood To: Shailendra Tripathi Cc: linux-xfs@oss.sgi.com Subject: Re: No local regular files Message-ID: <20060124170154.GA11338@taniwha.stupidest.org> References: <43D645CD.3030102@agami.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D645CD.3030102@agami.com> X-archive-position: 7246 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 751 Lines: 17 On Tue, Jan 24, 2006 at 08:50:45PM +0530, Shailendra Tripathi wrote: > I had an impression that XFS writes the data on the inode > itself if data is pretty small. However, recently I came to know > that for regular files it does not do the same, at least on Linux > XFS. Only for metadata, for regular files I think only reiserfs does this. Doing it probably makes more complicated especially for writes/flushes. I think reiserfs unpacks these files when opened in write for this reason (and optionally packs them again then the file is closed). Performance usually suffers so it ends up being a trade-off between some space-savings and performance. Given disks are insanely large I'm not sure there is much incentive for this for many people. From owner-linux-xfs@oss.sgi.com Tue Jan 24 12:41:48 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Jan 2006 12:41:55 -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 k0OKflm2030003 for ; Tue, 24 Jan 2006 12:41:47 -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 k0OKgqOX013061 for ; Tue, 24 Jan 2006 14:42:52 -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 k0OMhr7m021268 for ; Tue, 24 Jan 2006 14:43:53 -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 k0OKfmDN24420670; Tue, 24 Jan 2006 14:41:48 -0600 (CST) Received: from attica.americas.sgi.com (attica.americas.sgi.com [128.162.236.44]) by poppy-e236.americas.sgi.com (8.12.9/ASC-news-1.4) with ESMTP id k0OKflko1810359; Tue, 24 Jan 2006 14:41:47 -0600 (CST) Received: by attica.americas.sgi.com (Postfix, from userid 9762) id 62896494420; Tue, 24 Jan 2006 14:41:47 -0600 (CST) To: linux-xfs@sgi.com, sgi.bugs.xfs@sgi.com Subject: TAKE 947610 - Fix ref count assert failure caused by attribute insertion failure Message-Id: <20060124204147.62896494420@attica.americas.sgi.com> Date: Tue, 24 Jan 2006 14:41:47 -0600 (CST) From: yingping@sgi.com (Yingping Lu) X-archive-position: 7247 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: yingping@sgi.com Precedence: bulk X-list: linux-xfs Content-Length: 740 Lines: 17 Interim solution for attribute insertion failure during file creation due to ENOSPC. The current solution removes the inode when the attribute insertion fails. Long term solution would be to make the inode creation and attribute insertion atomic. Date: Tue Jan 24 12:38:10 PST 2006 Workarea: attica.americas.sgi.com:/data/lwork/attica3/yingping/xfs-kern Inspected by: tes The following file(s) were checked into: bonnie.engr.sgi.com:/isms/xfs-kern/xfs-linux Modid: xfs-linux:xfs-kern:205193a linux-2.6/xfs_iops.c - 1.237 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.237&r2=text&tr2=1.236&f=h - Add a cleanup code to handle the failure in attribute insertion due to ENOSPC. From owner-linux-xfs@oss.sgi.com Tue Jan 24 15:51:09 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Jan 2006 15:51:13 -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 k0ONp4m2010485 for ; Tue, 24 Jan 2006 15:51:08 -0800 Received: from agami.com ([192.168.168.149]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k0ONq9mF020766 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 24 Jan 2006 15:52:09 -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 k0ONq4r1005585 for ; Tue, 24 Jan 2006 15:52:04 -0800 Received: from [10.123.200.12] ([10.123.200.12]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jan 2006 15:52:04 -0800 Message-ID: <43D6BE03.1020901@agami.com> Date: Wed, 25 Jan 2006 05:23:39 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chris Wedgwood CC: linux-xfs@oss.sgi.com Subject: Re: No local regular files References: <43D645CD.3030102@agami.com> <20060124170154.GA11338@taniwha.stupidest.org> In-Reply-To: <20060124170154.GA11338@taniwha.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jan 2006 23:52:04.0499 (UTC) FILETIME=[2D678E30:01C62141] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7248 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: 1239 Lines: 30 Chris Wedgwood wrote: >Only for metadata, for regular files I think only reiserfs does this. >Doing it probably makes more complicated especially for >writes/flushes. > > I think reiserfs unpacks these files when opened in >write for this reason (and optionally packs them again then the file >is closed). > > > It should not be that tricky for XFS though. Inodes are read in at least page sized buffer (or 2 page , depending upon the buffer) and are written back in full buffers In fact, that's how shortform directories are being handled. >Performance usually suffers so it ends up being a trade-off between >some space-savings and performance. Given disks are insanely large >I'm not sure there is much incentive for this for many people. > > If file always remains in local format, the performance should not be affected (instead it should gain as no extent allocation, no extra I/O to the disk invariably at a different address). If the format changes, there will be overhead of copying the inode data to the newly created block. I am not at all concerned with space saving. I am just thinking if short form directories can be supported on local inode, what makes it tough to have the same thing for regular files. From owner-linux-xfs@oss.sgi.com Tue Jan 24 15:56:38 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Jan 2006 15:56:44 -0800 (PST) Received: from baikonur.stro.at (baikonur.stro.at [213.239.196.228]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0ONubm2010961 for ; Tue, 24 Jan 2006 15:56:38 -0800 Received: from nancy (stallburg.stro.at [128.131.216.190]) by baikonur.stro.at (Postfix) with ESMTP id 82AC45C00B; Tue, 24 Jan 2006 22:54:34 +0100 (CET) Received: from max by nancy with local (Exim 4.60) (envelope-from ) id 1F1W7H-00028a-R7; Tue, 24 Jan 2006 22:54:19 +0100 Date: Tue, 24 Jan 2006 22:54:19 +0100 From: maximilian attems To: linux-xfs@oss.sgi.com, nathans@sgi.com Cc: Steve Langasek , 347556@bugs.debian.org Subject: Re: Bug#347556: linux-image-2.6.15-1-alpha-generic: undefined symbols in xfs.ko on Message-ID: <20060124215419.GA8208@nancy> References: <20060111140322.6230.53907.reportbug@quetzlcoatl.dodds.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060111140322.6230.53907.reportbug@quetzlcoatl.dodds.net> User-Agent: Mutt/1.5.11 X-archive-position: 7249 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: maks@sternwelten.at Precedence: bulk X-list: linux-xfs Content-Length: 628 Lines: 28 hello, latest stable 2.6.15 has troubles with xfs on alpha, could you please hunt that? On Wed, 11 Jan 2006, Steve Langasek wrote: > Package: linux-2.6 > Version: 2.6.15-1 > Severity: grave > > Hah, this is special. So I tried to upgrade my kernel in order to test bug > #347186, and I can't mount my /usr partition due to missing symbols in > xfs.ko: > > $ nm -u /lib/modules/2.6.15-1-alpha-generic/kernel/fs/xfs/xfs.ko |grep cmpx > U __cmpxchg_called_with_bad_pointer > $ > > could we have build-time errors instead of clever error messages turned into > symbol names please? :) > regards -- maks From owner-linux-xfs@oss.sgi.com Tue Jan 24 15:58:29 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 24 Jan 2006 15:58:34 -0800 (PST) Received: from tennyson.dodds.net (dsl093-039-086.pdx1.dsl.speakeasy.net [66.93.39.86]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0ONwTm2011425 for ; Tue, 24 Jan 2006 15:58:29 -0800 Received: by tennyson.dodds.net (Postfix, from userid 1000) id A9EC424001; Tue, 24 Jan 2006 14:58:34 -0800 (PST) Date: Tue, 24 Jan 2006 14:58:34 -0800 From: Steve Langasek To: maximilian attems Cc: linux-xfs@oss.sgi.com, nathans@sgi.com, 347556@bugs.debian.org Subject: Re: Bug#347556: linux-image-2.6.15-1-alpha-generic: undefined symbols in xfs.ko on Message-ID: <20060124225834.GA25967@tennyson.dodds.net> References: <20060111140322.6230.53907.reportbug@quetzlcoatl.dodds.net> <20060124215419.GA8208@nancy> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="u3/rZRmxL6MmkK24" Content-Disposition: inline In-Reply-To: <20060124215419.GA8208@nancy> User-Agent: Mutt/1.5.9i X-archive-position: 7250 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: vorlon@debian.org Precedence: bulk X-list: linux-xfs Content-Length: 1579 Lines: 44 --u3/rZRmxL6MmkK24 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 24, 2006 at 10:54:19PM +0100, maximilian attems wrote: > hello, > latest stable 2.6.15 has troubles with xfs on alpha, > could you please hunt that? This isn't an XFS problem, it's an Alpha problem. We've already diagnosed this on IRC, and it turns out to be due to the alpha upstream maintainers trying to out-clever the kernel's standard clever handling of "inline", which results in code that must always be inlined not always being inlined. This doesn't affect just the xfs module, it also affects drm.ko. Anyway, a tentative fix has been proposed, to use the always_inline attribute explicitly for this function, but it remains to be implemented -- I don't have space here to do test kernel builds for alpha without doing a lot of shuffling, and nobse hasn't gotten back to me on it since the day we had that discussion on IRC. --=20 Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/ --u3/rZRmxL6MmkK24 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFD1rEaKN6ufymYLloRAhl5AKDJ/jHzhbaWEYpBZD6+2YEwkXR4+QCeLenO qPWdXF4QnkT1/ohaZffU9Zo= =pUiW -----END PGP SIGNATURE----- --u3/rZRmxL6MmkK24-- From owner-linux-xfs@oss.sgi.com Thu Jan 26 02:32:33 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Jan 2006 02:32:39 -0800 (PST) Received: from web70108.mail.krs.yahoo.com (web70108.mail.krs.yahoo.com [202.165.108.50]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0QAWWm2021900 for ; Thu, 26 Jan 2006 02:32:33 -0800 Received: (qmail 1757 invoked by uid 60001); 26 Jan 2006 09:33:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.kr; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zfc0rNFeORGQTfHx5fj9/vbVD4CunUXGjBBiIV/mFdN1SA1+PS3Y5WXTS939foCRxp2+hnHc9Tjl+roSA0AETom1lWc+rfCboE002jrT6jJeEJPUmd4ef+XqTw2xuVczio/8ECBA3vx50msNM6CJj+Hr4Q3OUzRke2IYHxLKT+0= ; Message-ID: <20060126093335.1755.qmail@web70108.mail.krs.yahoo.com> Received: from [220.73.122.205] by web70108.mail.krs.yahoo.com via HTTP; Thu, 26 Jan 2006 18:33:35 KST Date: Thu, 26 Jan 2006 18:33:35 +0900 (KST) From: Seungsu Yi Subject: moving disconnected inodes to lost+found To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=euc-kr Content-Transfer-Encoding: 8bit X-archive-position: 7252 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: snssroot@yahoo.co.kr Precedence: bulk X-list: linux-xfs Content-Length: 5678 Lines: 157 Hi, Sir A few days ago, I got a problem. As I moved the files on the hard disk with xfs to another disk, Messages come like this " can't read that files." after for a long stop. And then I carefully do below here. Same problem still is. And then what am I doing now? I Don't know . please let me know. thanks. From Lee snssroot@yahoo.co.kr ----------------------------------------------------------------- # xfs_repair -L /dev/sdb1 Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - clear lost+found (if it exists) ... - clearing existing "lost+found" inode - deleting existing "lost+found" entry - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - ensuring existence of lost+found directory - traversing filesystem starting at / ... - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... disconnected inode 950480190, moving to lost+found disconnected inode 950480191, moving to lost+found disconnected inode 950480192, moving to lost+found disconnected inode 950480193, moving to lost+found disconnected inode 950480194, moving to lost+found disconnected inode 950480195, moving to lost+found disconnected inode 950480196, moving to lost+found disconnected inode 950480197, moving to lost+found disconnected inode 950480198, moving to lost+found disconnected inode 950480199, moving to lost+found disconnected inode 950480200, moving to lost+found disconnected inode 950480201, moving to lost+found disconnected inode 950480202, moving to lost+found disconnected inode 950480203, moving to lost+found disconnected inode 950480204, moving to lost+found disconnected inode 950480205, moving to lost+found disconnected inode 950480206, moving to lost+found disconnected inode 950480207, moving to lost+found disconnected inode 950480208, moving to lost+found disconnected inode 950480209, moving to lost+found disconnected inode 950480210, moving to lost+found disconnected inode 950480211, moving to lost+found disconnected inode 950480212, moving to lost+found disconnected inode 950480213, moving to lost+found disconnected inode 950480214, moving to lost+found disconnected inode 950480215, moving to lost+found disconnected inode 950480216, moving to lost+found disconnected inode 950480217, moving to lost+found disconnected inode 950480218, moving to lost+found disconnected inode 950480219, moving to lost+found disconnected inode 950480220, moving to lost+found disconnected inode 950480221, moving to lost+found disconnected inode 950480222, moving to lost+found disconnected inode 950480223, moving to lost+found disconnected inode 950481088, moving to lost+found disconnected inode 950481089, moving to lost+found disconnected inode 950481090, moving to lost+found disconnected inode 950481091, moving to lost+found disconnected inode 950481092, moving to lost+found disconnected inode 950481093, moving to lost+found disconnected inode 950481094, moving to lost+found disconnected inode 950481095, moving to lost+found disconnected inode 950481096, moving to lost+found disconnected inode 950481097, moving to lost+found disconnected inode 950481098, moving to lost+found disconnected inode 950481099, moving to lost+found disconnected inode 950481100, moving to lost+found disconnected inode 950481101, moving to lost+found disconnected inode 950481102, moving to lost+found disconnected inode 950481103, moving to lost+found disconnected inode 950481104, moving to lost+found disconnected inode 950481105, moving to lost+found disconnected inode 950481106, moving to lost+found disconnected inode 950481107, moving to lost+found disconnected inode 950481108, moving to lost+found disconnected inode 950481109, moving to lost+found disconnected inode 950481110, moving to lost+found disconnected inode 950481111, moving to lost+found disconnected inode 950481112, moving to lost+found disconnected inode 950481113, moving to lost+found disconnected inode 950481114, moving to lost+found Phase 7 - verify and correct link counts... done # -------------------------------------------------------------- ________________________________________________________ ¾ßÈÄ! ¸ð¹ÙÀÏ - ÈÞ´ëÆù¿¡ ´ëÇÑ ¸ðµç Àç¹Ì! À¯¹«¼± ¾ßÈÄ!¸ð¹ÙÀÏÀ» Áñ±â¼¼¿ä http://kr.mobile.yahoo.com From owner-linux-xfs@oss.sgi.com Thu Jan 26 11:41:04 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Jan 2006 11:41:05 -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 k0QJf4m2001742 for ; Thu, 26 Jan 2006 11:41:04 -0800 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k0QLhP6j012483 for ; Thu, 26 Jan 2006 13:43:26 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k0QJwPAP10774138; Thu, 26 Jan 2006 11:58:25 -0800 (PST) Message-ID: <43D9260B.6040203@sgi.com> Date: Thu, 26 Jan 2006 13:42:03 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Seungsu Yi CC: linux-xfs@oss.sgi.com Subject: Re: moving disconnected inodes to lost+found References: <20060126093335.1755.qmail@web70108.mail.krs.yahoo.com> In-Reply-To: <20060126093335.1755.qmail@web70108.mail.krs.yahoo.com> Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit X-archive-position: 7253 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: 492 Lines: 16 Seungsu Yi wrote: > Hi, Sir > > A few days ago, I got a problem. As I moved the files > on the hard disk with xfs to another disk, Messages > come like this " can't read that files." after for a > long stop. And then I carefully do below here. Same > problem still is. > And then what am I doing now? I Don't know . please > let me know. repair always un-links lost+found/ and then re-discovers the files in it. Rename it, re-run xfs_repair, and you should get a clean, quiet run. -Eric From owner-linux-xfs@oss.sgi.com Thu Jan 26 12:15:09 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Jan 2006 12:15:14 -0800 (PST) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0QKF6m2004623 for ; Thu, 26 Jan 2006 12:15:08 -0800 Received: by wproxy.gmail.com with SMTP id i12so493049wra for ; Thu, 26 Jan 2006 12:16:10 -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=dVpm9r6bASOIacgaTTBn055JiTrA/kW5ir0szQd9UEpEDSyv/YCjHWtfEsnFL/jIyOG5RTHa5uFxjV05oJZeERG1aaPYAAPvcYh88gLDrwdz1iNLdu24Wd7sSZN6zK+9ZV8Va95G/u/fOGw5hbo9mjSbjkB7GeBqi7DnDXhhU9A= Received: by 10.65.228.12 with SMTP id f12mr1236660qbr; Thu, 26 Jan 2006 10:25:31 -0800 (PST) Received: by 10.65.222.7 with HTTP; Thu, 26 Jan 2006 10:25:31 -0800 (PST) Message-ID: <4f52331f0601261025h9002e41q5df1e15888be7b@mail.gmail.com> Date: Thu, 26 Jan 2006 10:25:31 -0800 From: Fong Vang To: linux-xfs@oss.sgi.com Subject: data loss with delayed allocaton 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 k0QKF9m2004629 X-archive-position: 7254 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: sudoyang@gmail.com Precedence: bulk X-list: linux-xfs Content-Length: 373 Lines: 9 I just read the following article: http://madpenguin.org/cms/index.php/?m=show&opt=printable&id=6045 Near the end, this line caught my attention: "the delay means that while a crash will not destroy FS, it might result in significant loss of data that has not yet been written to the disc." I'm just wondering if this delay parameter is tunable and what the default is. From owner-linux-xfs@oss.sgi.com Thu Jan 26 14:44:17 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Jan 2006 14:44:20 -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 k0QMiHm2017516 for ; Thu, 26 Jan 2006 14:44:17 -0800 Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k0R0kfYs031062 for ; Thu, 26 Jan 2006 16:46:41 -0800 Received: from [128.162.232.50] (stout.americas.sgi.com [128.162.232.50]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k0QN1fAP10839255; Thu, 26 Jan 2006 15:01:41 -0800 (PST) Message-ID: <43D950FE.1040801@sgi.com> Date: Thu, 26 Jan 2006 16:45:18 -0600 From: Eric Sandeen User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fong Vang CC: linux-xfs@oss.sgi.com Subject: Re: data loss with delayed allocaton References: <4f52331f0601261025h9002e41q5df1e15888be7b@mail.gmail.com> In-Reply-To: <4f52331f0601261025h9002e41q5df1e15888be7b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7255 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: 919 Lines: 23 Fong Vang wrote: > I just read the following article: > http://madpenguin.org/cms/index.php/?m=show&opt=printable&id=6045 > > Near the end, this line caught my attention: "the delay means that > while a crash will not destroy FS, it might result in significant loss > of data that has not yet been written to the disc." Just before that he says "One thing some might find disturbing about the file system, is delayed allocation." So he's talking about delayed allocation here. But delaying the actual allocation of blocks for data is not the same as delaying the flushing of the data into those blocks. File data flushing is controlled by bdflush as with other filesystems. Blocks are allocated at flush time - this is the "delay" part, and affects when blocks get allocated, not when data is flushed. The article also says that disks have 512k sectors ;-) So don't believe everything you read.... -Eric From owner-linux-xfs@oss.sgi.com Thu Jan 26 15:05:02 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Thu, 26 Jan 2006 15:05:03 -0800 (PST) Received: from MAIL01HQ.adic.com (mail01hq.adic.com [63.81.117.10]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0QN51m2019286 for ; Thu, 26 Jan 2006 15:05:01 -0800 Received: from [172.16.82.67] ([172.16.82.67]) by MAIL01HQ.adic.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Jan 2006 14:03:59 -0800 Message-ID: <43D9474E.3070607@xfs.org> Date: Thu, 26 Jan 2006 16:03:58 -0600 From: Steve Lord User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: Fong Vang CC: linux-xfs@oss.sgi.com Subject: Re: data loss with delayed allocaton References: <4f52331f0601261025h9002e41q5df1e15888be7b@mail.gmail.com> In-Reply-To: <4f52331f0601261025h9002e41q5df1e15888be7b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jan 2006 22:03:59.0361 (UTC) FILETIME=[68C98710:01C622C4] X-archive-position: 7256 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: lord@xfs.org Precedence: bulk X-list: linux-xfs Content-Length: 835 Lines: 20 Fong Vang wrote: > I just read the following article: > http://madpenguin.org/cms/index.php/?m=show&opt=printable&id=6045 > > Near the end, this line caught my attention: "the delay means that > while a crash will not destroy FS, it might result in significant loss > of data that has not yet been written to the disc." > > I'm just wondering if this delay parameter is tunable and what the default is. > Just the same delay as if the data was written out into already allocated space. Unless you do a write with O_SYNC or O_DIRECT or use fsync, there is always a delay between a write call completing and the data hitting the disk. The only difference with delayed allocation is that the allocate is done with the flush rather than with the write. The timing difference on the flush to disk is not going to be measurable. Steve From owner-linux-xfs@oss.sgi.com Fri Jan 27 19:20:22 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Jan 2006 19:20:24 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0S3KMm2007084 for ; Fri, 27 Jan 2006 19:20:22 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id k0S1sCC9000184 for ; Fri, 27 Jan 2006 20:54:12 -0500 (EST) Date: Fri, 27 Jan 2006 20:54:12 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: Need to up reservation ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7258 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: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 1090 Lines: 25 Dear all, After the following messages, my (remote) system hang: Jan 27 02:15:38 hat10 kernel: Filesystem "md(9,3)": xfs_log_write: reservation ran out. Need to up reservation Jan 27 02:15:38 hat10 kernel: xfs_force_shutdown(md(9,3),0x8) called from line 1739 of file xfs_log.c. Return address = 0xc01e2a9b Jan 27 02:15:38 hat10 kernel: Filesystem "md(9,3)": Corruption of in-memory data detected. Shutting down filesystem: md(9,3) Jan 27 02:15:38 hat10 kernel: Please umount the filesystem, and rectify the problem(s) Jan 27 02:15:38 hat10 kernel: xfs_force_shutdown(md(9,3),0x2) called from line 1321 of file xfs_log.c. Return address = 0xc01e2a9b This is a PIV PC with 0.5Gb RAM, RH9.0 Linux with 2.4.22 kernel patched for XFS support (2.4.22-xfs-031010). The previous uptime was something like half a year. The questions are the usual: 1. What could be the problem? I suspect faulty memory. 2. What could be done from __remotely__? Someone hard-reset the PC, and it booted up fine, but with a mounted / I can not run xfs_check or repair. Ideas welcome ... Best wishes Gaspar From owner-linux-xfs@oss.sgi.com Fri Jan 27 19:09:15 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Fri, 27 Jan 2006 19:09:17 -0800 (PST) Received: from cfa.harvard.edu (cfa.harvard.edu [131.142.10.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0S39Em2006004 for ; Fri, 27 Jan 2006 19:09:15 -0800 Received: from titan (titan [131.142.24.40]) by cfa.harvard.edu (8.12.9-20030924/8.12.9/cfunix Mast-Sol 1.0) with ESMTP id k0S26OrR001442 for ; Fri, 27 Jan 2006 21:06:24 -0500 (EST) Date: Fri, 27 Jan 2006 21:06:24 -0500 (EST) From: Gaspar Bakos Reply-To: gbakos@cfa.harvard.edu To: linux-xfs@oss.sgi.com Subject: Need to up reservation ... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7257 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: gbakos@cfa.harvard.edu Precedence: bulk X-list: linux-xfs Content-Length: 414 Lines: 14 Hi, I realized that my previous email was on a subject that has been discussed on the list long time ago, and the kernel and probably XFS version are quite old. However, the system is under 'industrial' use with kernel drivers specific to the 2.4 kernel, migrating to 2.6 would not be possible right now. Also, it has been running fine since 2004, so I was quite surprised that a 'bug' came out. Cheers Gaspar From owner-linux-xfs@oss.sgi.com Sat Jan 28 03:44:10 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Jan 2006 03:44:18 -0800 (PST) Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0SBi9m2010957 for ; Sat, 28 Jan 2006 03:44:10 -0800 Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1012B1711F; Sat, 28 Jan 2006 11:42:34 +0100 (CET) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id 0A5541710C; Sat, 28 Jan 2006 11:42:33 +0100 (CET) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id 164F55030E5; Sat, 28 Jan 2006 11:42:30 +0100 (CET) Date: Sat, 28 Jan 2006 11:42:30 +0100 From: Christian Guggenberger To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: Need to up reservation ... Message-ID: <20060128104229.GA5431@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 7259 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: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 1189 Lines: 23 On Fri, Jan 27, 2006 at 08:54:12PM -0500, Gaspar Bakos wrote: > Dear all, > > After the following messages, my (remote) system hang: > > Jan 27 02:15:38 hat10 kernel: Filesystem "md(9,3)": xfs_log_write: reservation ran out. Need to up reservation > Jan 27 02:15:38 hat10 kernel: xfs_force_shutdown(md(9,3),0x8) called from line 1739 of file xfs_log.c. Return address = 0xc01e2a9b > Jan 27 02:15:38 hat10 kernel: Filesystem "md(9,3)": Corruption of in-memory data detected. Shutting down filesystem: md(9,3) > Jan 27 02:15:38 hat10 kernel: Please umount the filesystem, and rectify the problem(s) > Jan 27 02:15:38 hat10 kernel: xfs_force_shutdown(md(9,3),0x2) called from line 1321 of file xfs_log.c. Return address = 0xc01e2a9b > > This is a PIV PC with 0.5Gb RAM, RH9.0 Linux with 2.4.22 kernel patched > for XFS support (2.4.22-xfs-031010). The previous uptime was something > like half a year. > This is probably Bug #284 (and #313) - http://oss.sgi.com/bugzilla/show_bug.cgi?id=284, which started to happen in 2.4.22 CVS days. It has been fixed by Glen Overby sometime in March 2004. I guess, uprading your kernel to 2.4.32 should solve this problem. cheers. - Christian From owner-linux-xfs@oss.sgi.com Sat Jan 28 07:50:40 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sat, 28 Jan 2006 07:50:45 -0800 (PST) Received: from rrzmta2.rz.uni-regensburg.de (rrzmta2.rz.uni-regensburg.de [132.199.1.17]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0SFodm2031006 for ; Sat, 28 Jan 2006 07:50:40 -0800 Received: from rrzmta2.rz.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id EEF3D17082; Sat, 28 Jan 2006 16:51:48 +0100 (CET) Received: from pc51072.physik.uni-regensburg.de (pc51072.physik.uni-regensburg.de [132.199.98.129]) by rrzmta2.rz.uni-regensburg.de (Postfix) with ESMTP id DEFB517079; Sat, 28 Jan 2006 16:51:48 +0100 (CET) Received: by pc51072.physik.uni-regensburg.de (Postfix, from userid 28561) id 701495030E5; Sat, 28 Jan 2006 16:51:42 +0100 (CET) Date: Sat, 28 Jan 2006 16:51:42 +0100 From: Christian Guggenberger To: Gaspar Bakos Cc: linux-xfs@oss.sgi.com Subject: Re: Need to up reservation ... Message-ID: <20060128155142.GA12452@pc51072.physik.uni-regensburg.de> Reply-To: christian.guggenberger@physik.uni-regensburg.de References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-archive-position: 7260 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: christian.guggenberger@physik.uni-regensburg.de Precedence: bulk X-list: linux-xfs Content-Length: 687 Lines: 20 On Fri, Jan 27, 2006 at 09:06:24PM -0500, Gaspar Bakos wrote: > Hi, > > I realized that my previous email was on a subject that has been > discussed on the list long time ago, and the kernel and probably XFS > version are quite old. > > However, the system is under 'industrial' use with kernel drivers > specific to the 2.4 kernel, migrating to 2.6 would not be possible > right now. Also, it has been running fine since 2004, so I was quite > surprised that a 'bug' came out. > IIRC, a hotfix for that problem would be mounting your xfs filesystem(s) with the "ikeep" mount option. "noikeep" had been the default in 2.4.22 CVS days, which triggered this bug. cheers. - Christian From owner-linux-xfs@oss.sgi.com Sun Jan 29 03:06:59 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Jan 2006 03:07:03 -0800 (PST) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0TB6wm2003162 for ; Sun, 29 Jan 2006 03:06:59 -0800 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k0TB7qiQ022496; Sun, 29 Jan 2006 12:07:54 +0100 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k0TB7pGE022480; Sun, 29 Jan 2006 12:07:51 +0100 Date: Sun, 29 Jan 2006 12:07:51 +0100 (MET) From: Jan Engelhardt To: Linux Kernel Mailing List cc: linux-xfs@oss.sgi.com Subject: reinitializing quota on xfs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7261 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: jengelh@linux01.gwdg.de Precedence: bulk X-list: linux-xfs Content-Length: 711 Lines: 24 Hi, for some strange reason, `quota -v` showed an impossible number in the inodes (files) field, something that resembled 2^64 - n, n={1..100}. I do not know how it happened, but I wanted to reinitialize the quota. Though, how does one do that with XFS? (Since it's different from the vfsv0 quota architecture.) By chance, I could make xfs reinit it using: quotaoff /D touch /D/something umount /D mount /D # impliclty mounts with usrquota,grpquota (options in fstab) but it would have been nicer to have a mount option. Jan Engelhardt -- | Software Engineer and Linux/Unix Network Administrator | Alphagate Systems, http://alphagate.hopto.org/ | jengelh's site, http://jengelh.hopto.org/ From owner-linux-xfs@oss.sgi.com Sun Jan 29 08:44:47 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Jan 2006 08:44:48 -0800 (PST) Received: from smtp.meme.com (janus.meme.com [69.17.73.118]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0TGikm2032278 for ; Sun, 29 Jan 2006 08:44:47 -0800 Received: by smtp.meme.com (Postfix, from userid 1001) id 480DB1FFE5; Sun, 29 Jan 2006 09:40:51 -0600 (CST) Received: from mofo.meme.com (unknown [192.168.1.2]) by smtp.meme.com (Postfix) with ESMTP id B17E61FFE2 for ; Sun, 29 Jan 2006 09:40:49 -0600 (CST) Received: from mofo (localhost.localdomain [127.0.0.1]) by mofo.meme.com (Postfix) with ESMTP id 856616E421 for ; Sun, 29 Jan 2006 09:40:49 -0600 (CST) Date: Sun, 29 Jan 2006 15:40:49 +0000 From: "Karl O. Pinc" Subject: Allocations for zero length files To: linux-xfs@oss.sgi.com X-Mailer: Balsa 2.3.0 Message-Id: <1138549249l.9913l.0l@mofo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-archive-position: 7262 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: kop@meme.com Precedence: bulk X-list: linux-xfs Content-Length: 580 Lines: 19 Hi, If I make a zero length file in xfs is any disk allocated for the data portion? I'm thinking of storing lots (units of 10**6) of small keys as empty files with names that are the keys. I suppose some keys could be larger, is there a limit on filename length? (Thanks for not making me go to the trouble of coming up with some free partition space to try this out. I'm afriad of loopback mount lockups, although maybe that was all related to Linux 2.4.) Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein From owner-linux-xfs@oss.sgi.com Sun Jan 29 14:09:49 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Jan 2006 14:09:52 -0800 (PST) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0TM9mm2024868 for ; Sun, 29 Jan 2006 14:09:49 -0800 Received: (qmail 41842 invoked from network); 29 Jan 2006 22:10:49 -0000 Received: from unknown (HELO stupidest.org) (cwedgwood@sbcglobal.net@70.132.18.199 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 29 Jan 2006 22:10:49 -0000 Received: by taniwha.stupidest.org (Postfix, from userid 38689) id 2415751FB80; Sun, 29 Jan 2006 14:10:48 -0800 (PST) Date: Sun, 29 Jan 2006 14:10:48 -0800 From: Chris Wedgwood To: David Chinner Cc: Shailendra Tripathi , linux-xfs@oss.sgi.com Subject: Re: No local regular files Message-ID: <20060129221048.GA17971@taniwha.stupidest.org> References: <43D645CD.3030102@agami.com> <20060124170154.GA11338@taniwha.stupidest.org> <43D6BE03.1020901@agami.com> <20060129220627.GO43335175@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060129220627.GO43335175@melbourne.sgi.com> X-archive-position: 7264 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: cw@f00f.org Precedence: bulk X-list: linux-xfs Content-Length: 366 Lines: 9 On Mon, Jan 30, 2006 at 09:06:27AM +1100, David Chinner wrote: > I can think of several tricky problems that need to be solved before > this could work. I'm not aware of any practical benchmark where there is a performance gain by doing this (fir reiser3 anyhow) and since disks are insanely large and cheap I just don't see the point given the added complexity. From owner-linux-xfs@oss.sgi.com Sun Jan 29 14:05:54 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Jan 2006 14:06:01 -0800 (PST) Received: from larry.melbourne.sgi.com ([61.14.31.138]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id k0TM5rm2024573 for ; Sun, 29 Jan 2006 14:05:54 -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 JAA07020; Mon, 30 Jan 2006 09:06:37 +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 k0TM6WdM88451473; Mon, 30 Jan 2006 09:06:33 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0TM6RA385239677; Mon, 30 Jan 2006 09:06:27 +1100 (EST) Date: Mon, 30 Jan 2006 09:06:27 +1100 From: David Chinner To: Shailendra Tripathi Cc: Chris Wedgwood , linux-xfs@oss.sgi.com Subject: Re: No local regular files Message-ID: <20060129220627.GO43335175@melbourne.sgi.com> References: <43D645CD.3030102@agami.com> <20060124170154.GA11338@taniwha.stupidest.org> <43D6BE03.1020901@agami.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43D6BE03.1020901@agami.com> User-Agent: Mutt/1.4.2.1i X-archive-position: 7263 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: 1793 Lines: 51 On Wed, Jan 25, 2006 at 05:23:39AM +0530, Shailendra Tripathi wrote: > Chris Wedgwood wrote: > > >Only for metadata, for regular files I think only reiserfs does this. > >Doing it probably makes more complicated especially for > >writes/flushes. > > > > I think reiserfs unpacks these files when opened in > >write for this reason (and optionally packs them again then the file > >is closed). > > > > > > > It should not be that tricky for XFS though. I can think of several tricky problems that need to be solved before this could work. When do you convert from in line to out of line data? During delayed allocation when flushing the page? i.e. how do you propose to keep the page cache and the pagebuf coherent as we'd be caching the same data in two different places now, both with different locking, life cycles and flushing strategies? How do you handle the data in caches being remapped to different disk blocks when it gets moved to a different location? How do you represent the inline data via xfs_bmapi and friends? Is the inline data an extent? How do you represent the data offset on disk when it's not a multiple of the filesystem block size? You'll need a new transaction for converting in-line to out of line format (and vice versa) so that a crash between removing the data form the inode and writing the new extents won't lose the data in the inode.... Also, consider tail pushing the AIL. If there's data in the inode, your tail push now has to pull data out of the page cache for each inode in the cluster that stale data is not written back. I can see potential for some nasty inode locking problems there. That's just off the top of my head - I'm sure there's more..... ;) Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Sun Jan 29 14:33:28 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Jan 2006 14:33:34 -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 k0TMXRm2027263 for ; Sun, 29 Jan 2006 14:33:27 -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 JAA07599; Mon, 30 Jan 2006 09:34:25 +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 k0TMYNdM87912076; Mon, 30 Jan 2006 09:34:23 +1100 (EST) Received: (from dgc@localhost) by snort.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0TMYIlN87796947; Mon, 30 Jan 2006 09:34:18 +1100 (EST) Date: Mon, 30 Jan 2006 09:34:18 +1100 From: David Chinner To: Chris Wedgwood Cc: David Chinner , Shailendra Tripathi , linux-xfs@oss.sgi.com Subject: Re: No local regular files Message-ID: <20060129223418.GP43335175@melbourne.sgi.com> References: <43D645CD.3030102@agami.com> <20060124170154.GA11338@taniwha.stupidest.org> <43D6BE03.1020901@agami.com> <20060129220627.GO43335175@melbourne.sgi.com> <20060129221048.GA17971@taniwha.stupidest.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060129221048.GA17971@taniwha.stupidest.org> User-Agent: Mutt/1.4.2.1i X-archive-position: 7265 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: 598 Lines: 20 On Sun, Jan 29, 2006 at 02:10:48PM -0800, Chris Wedgwood wrote: > On Mon, Jan 30, 2006 at 09:06:27AM +1100, David Chinner wrote: > > > I can think of several tricky problems that need to be solved before > > this could work. > > I'm not aware of any practical benchmark where there is a performance > gain by doing this (fir reiser3 anyhow) and since disks are insanely > large and cheap I just don't see the point given the added complexity. Agreed. I'm just pointing out that it's not something trivial.... Cheers, Dave. -- Dave Chinner R&D Software Enginner SGI Australian Software Group From owner-linux-xfs@oss.sgi.com Sun Jan 29 22:50:08 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Sun, 29 Jan 2006 22:50:14 -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 k0U6o4m2031443 for ; Sun, 29 Jan 2006 22:50:08 -0800 Received: from agami.com ([192.168.168.110]) by ext.storadinc.com (8.12.5/8.12.5) with ESMTP id k0U6p4FS023766 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 29 Jan 2006 22:51:04 -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 k0U6oxr1020301 for ; Sun, 29 Jan 2006 22:50:59 -0800 Received: from [192.168.0.207] ([10.123.200.1]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jan 2006 22:50:58 -0800 Message-ID: <43DDB672.6010502@agami.com> Date: Mon, 30 Jan 2006 12:17:14 +0530 From: Shailendra Tripathi User-Agent: Mozilla Thunderbird 0.9 (X11/20041127) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Karl O. Pinc" CC: linux-xfs@oss.sgi.com Subject: Re: Allocations for zero length files References: <1138549249l.9913l.0l@mofo> In-Reply-To: <1138549249l.9913l.0l@mofo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jan 2006 06:50:59.0059 (UTC) FILETIME=[86D5CC30:01C62569] X-Scanned-By: MIMEDefang 2.36 X-archive-position: 7266 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: 1177 Lines: 35 Hi Karl, The length will be limited to in this case to standard XFS name limit of 255 as you appear to be interested in regular file names. The difference is in symbolic links. If symbolic link is less than a constant, it is stored on the inode itself. This constant is dependent upon the inodesize(In presence of extended attributes, this constant is dependent upon some other factor as well). For example, with 256 inodesize, the maximum which you can possibly store as symbolic link is 156 bytes name. Regards, Shailendra Karl O. Pinc wrote: > Hi, > > If I make a zero length file in xfs is any disk allocated for the > data portion? I'm thinking of storing lots (units of 10**6) of > small keys as empty files with names that are the keys. > > I suppose some keys could be larger, is there a limit on filename > length? > > (Thanks for not making me go to the trouble of coming up with > some free partition space to try this out. I'm afriad > of loopback mount lockups, although maybe that was > all related to Linux 2.4.) > > > Karl > Free Software: "You don't pay back, you pay forward." > -- Robert A. Heinlein > > From owner-linux-xfs@oss.sgi.com Mon Jan 30 01:18:11 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 01:18:14 -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 k0U9I8m2014552 for ; Mon, 30 Jan 2006 01:18:10 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA20147; Mon, 30 Jan 2006 20:19:02 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0U9JCkt8050738; Mon, 30 Jan 2006 20:19:12 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0U9J9838868995; Mon, 30 Jan 2006 20:19:09 +1100 (EST) Date: Mon, 30 Jan 2006 20:19:08 +1100 From: Nathan Scott To: Jan Engelhardt Cc: Linux Kernel Mailing List , linux-xfs@oss.sgi.com Subject: Re: reinitializing quota on xfs Message-ID: <20060130201908.A8865130@wobbly.melbourne.sgi.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jengelh@linux01.gwdg.de on Sun, Jan 29, 2006 at 12:07:51PM +0100 X-archive-position: 7267 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: 694 Lines: 22 On Sun, Jan 29, 2006 at 12:07:51PM +0100, Jan Engelhardt wrote: > Hi, > > for some strange reason, `quota -v` showed an impossible number in the > inodes (files) field, something that resembled 2^64 - n, n={1..100}. I do It would be really good if we could get a test case for this; it gets reported once in a blue moon, so there does seem to be some latent issue there... > not know how it happened, but I wanted to reinitialize the quota. Though, > how does one do that with XFS? (Since it's different from the vfsv0 quota > architecture.) See xfs_quota(8) from recent versions of xfsprogs, or in older ones theres doco in /usr/share/doc/xfsprogs*/README.quota. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 30 01:21:03 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 01:21:06 -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 k0U9L1m2014909 for ; Mon, 30 Jan 2006 01:21:02 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id UAA20179; Mon, 30 Jan 2006 20:21:57 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0U9M8kt8868604; Mon, 30 Jan 2006 20:22:09 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0U9M7xw8844766; Mon, 30 Jan 2006 20:22:07 +1100 (EST) Date: Mon, 30 Jan 2006 20:22:06 +1100 From: Nathan Scott To: "Karl O. Pinc" Cc: linux-xfs@oss.sgi.com Subject: Re: Allocations for zero length files Message-ID: <20060130202206.B8865130@wobbly.melbourne.sgi.com> References: <1138549249l.9913l.0l@mofo> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1138549249l.9913l.0l@mofo>; from kop@meme.com on Sun, Jan 29, 2006 at 03:40:49PM +0000 X-archive-position: 7268 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: 636 Lines: 28 On Sun, Jan 29, 2006 at 03:40:49PM +0000, Karl O. Pinc wrote: > Hi, > > If I make a zero length file in xfs is any disk allocated for the > data portion? Nope. > I suppose some keys could be larger, is there a limit on filename > length? 255 for pathname components (IIRC), and 1024 for full paths (also IIRC). > of loopback mount lockups, although maybe that was > all related to Linux 2.4.) It doesn't hurt to report it if there is some issue still, but should be fine - I use loopback from time to time without any problems. > Karl > Free Software: "You don't pay back, you pay forward." cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 30 01:46:09 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 01:46:10 -0800 (PST) Received: from linux01.gwdg.de (linux01.gwdg.de [134.76.13.21]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0U9k8m2017629 for ; Mon, 30 Jan 2006 01:46:08 -0800 Received: from linux01.gwdg.de (localhost [127.0.0.1]) by linux01.gwdg.de (8.13.3/8.13.3/SuSE Linux 0.7) with ESMTP id k0U9l96j014196; Mon, 30 Jan 2006 10:47:11 +0100 Received: from localhost (jengelh@localhost) by linux01.gwdg.de (8.13.3/8.13.3/Submit) with ESMTP id k0U9l8DF014187; Mon, 30 Jan 2006 10:47:09 +0100 Date: Mon, 30 Jan 2006 10:47:07 +0100 (MET) From: Jan Engelhardt To: Nathan Scott cc: Linux Kernel Mailing List , linux-xfs@oss.sgi.com Subject: Re: reinitializing quota on xfs In-Reply-To: <20060130201908.A8865130@wobbly.melbourne.sgi.com> Message-ID: References: <20060130201908.A8865130@wobbly.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-archive-position: 7269 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: jengelh@linux01.gwdg.de Precedence: bulk X-list: linux-xfs Content-Length: 766 Lines: 26 >> Hi, >> >> for some strange reason, `quota -v` showed an impossible number in the >> inodes (files) field, something that resembled 2^64 - n, n={1..100}. I do > >It would be really good if we could get a test case for this; it >gets reported once in a blue moon, so there does seem to be some >latent issue there... > I'll try figure out a testcase. >> not know how it happened, but I wanted to reinitialize the quota. Though, >> how does one do that with XFS? (Since it's different from the vfsv0 quota >> architecture.) > >See xfs_quota(8) from recent versions of xfsprogs, or in older >ones theres doco in /usr/share/doc/xfsprogs*/README.quota. I can't find it in xfsprogs-2.7.11/man/man8/xfs_admin.8 ... or it's too well hidden. Jan Engelhardt -- From owner-linux-xfs@oss.sgi.com Mon Jan 30 13:37:56 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 13:38:00 -0800 (PST) Received: from mx2.tippett.com (mx2.tippett.com [64.81.248.66]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0ULbtm2030256 for ; Mon, 30 Jan 2006 13:37:55 -0800 Received: from hermes.tippett.com (hermes.tippett.com [192.168.3.20]) by mx2.tippett.com (8.12.8/8.12.8) with ESMTP id k0UJvoRm025387 for ; Mon, 30 Jan 2006 11:57:50 -0800 Received: from [192.168.3.62] (gangsta.tippett.com [192.168.3.62]) by hermes.tippett.com (SGI-8.12.5/8.12.5) with ESMTP id k0UKLLEu2663073 for ; Mon, 30 Jan 2006 12:21:21 -0800 (PST) Message-ID: <43DE74E7.6070306@tippett.com> Date: Mon, 30 Jan 2006 12:19:51 -0800 From: Christian Rice Reply-To: xian@tippett.com Organization: Tippett Studio User-Agent: Mozilla Thunderbird 1.0.7 (X11/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: disabling write cache on SATA drives Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (mx2.tippett.com [192.168.12.2]); Mon, 30 Jan 2006 11:57:50 -0800 (PST) X-archive-position: 7270 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: xian@tippett.com Precedence: bulk X-list: linux-xfs Content-Length: 921 Lines: 26 We all know that disabling write cache on drives with no battery backup is a good thing, and we all know how to do it on your average IDE drive (hdparm -W0 /dev/hda). But what about on SATA disks? I've found sdparm, which has settings for disabling write cache on SCSI disks (and supposedly SATA disks that use the SCSI device (eg, /dev/sda). It simply doesn't work, though: [root@sqld xian]# sdparm --set WCE=1 /dev/sda /dev/sda: ATA Maxtor 7Y250M0 YAR5 change_mode_page: failed setting page: Caching (SBC) [root@sqld xian]# uname -r 2.6.14-1.1656_FC4smp Of course I'm using XFS... The sdparm web page suggests some SCSI commands will be better implemented in kernel 2.6.15. The only other thing I might try here is to recompile a 64-bit version of sdparm, as I downloaded/installed version .96 i386, but this system is a dual-proc Opteron running 64-bit FC4. Anyone have any other ideas? From owner-linux-xfs@oss.sgi.com Mon Jan 30 16:37:25 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 16:37:27 -0800 (PST) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0V0bPm2011644 for ; Mon, 30 Jan 2006 16:37:25 -0800 Received: from doufu (doufu.siksai.co.uk [82.133.8.9]) by smtp.nildram.co.uk (Postfix) with ESMTP id 43A1D257D94 for ; Mon, 30 Jan 2006 23:34:54 +0000 (GMT) Received: from xiao.siksai.co.uk ([82.133.8.12] ident=rhowe) by doufu with smtp (Exim 4.50) id 1F3iXw-0007gK-UJ for linux-xfs@oss.sgi.com; Mon, 30 Jan 2006 23:34:57 +0000 Received: by xiao.siksai.co.uk (sSMTP sendmail emulation); Mon, 30 Jan 2006 23:34:56 +0000 From: "Russell Howe" Date: Mon, 30 Jan 2006 23:34:56 +0000 To: linux-xfs@oss.sgi.com Subject: Re: disabling write cache on SATA drives Message-ID: <20060130233456.GA11770@xiao.rsnet> Mail-Followup-To: linux-xfs@oss.sgi.com References: <43DE74E7.6070306@tippett.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43DE74E7.6070306@tippett.com> User-Agent: Mutt/1.5.11 X-archive-position: 7271 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: rhowe@siksai.co.uk Precedence: bulk X-list: linux-xfs Content-Length: 445 Lines: 13 On Mon, Jan 30, 2006 at 12:19:51PM -0800, Christian Rice wrote: > We all know that disabling write cache on drives with no battery backup > is a good thing, and we all know how to do it on your average IDE drive > (hdparm -W0 /dev/hda). > > But what about on SATA disks? Is blktool the New(tm) way to do this? -- Russell Howe | Why be just another cog in the machine, rhowe@siksai.co.uk | when you can be the spanner in the works? From owner-linux-xfs@oss.sgi.com Mon Jan 30 16:50:51 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 16:50:56 -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 k0V0onm2012519 for ; Mon, 30 Jan 2006 16:50:50 -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 LAA10972; Tue, 31 Jan 2006 11:51:33 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16346) id 873C8494E42E; Tue, 31 Jan 2006 11:51:31 +1100 (EST) To: sgi.bugs.xfs@engr.sgi.com, linux-xfs@oss.sgi.com Subject: TAKE 948858 - Remove xfs.ko dependency on exportfs.ko Message-Id: <20060131005131.873C8494E42E@chook.melbourne.sgi.com> Date: Tue, 31 Jan 2006 11:51:31 +1100 (EST) From: dgc@sgi.com (David Chinner) X-archive-position: 7272 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: 873 Lines: 21 XFS needlessly depends on exportfs.ko due to the use of find_exported_dentry(). XFS does not need to use this symbol as it is provided by a vector through the superblock export operations when the filesystem is exported by NFS. The fix is to call that vector instead of using the exported symbol directly. Date: Tue Jan 31 11:49:00 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/dgc/isms/2.6.x-xfs Inspected by: tes,felixb The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:25062a fs/xfs/linux-2.6/xfs_export.c - 1.5 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_export.c.diff?r1=text&tr1=1.5&r2=text&tr2=1.4&f=h - remove exportfs.ko dependency by calling the find_exported_dentry export op vector rather than directly calling find_exported_dentry(). From owner-linux-xfs@oss.sgi.com Mon Jan 30 19:03:42 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 19:03:43 -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 k0V33em2025308 for ; Mon, 30 Jan 2006 19:03:41 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA14000; Tue, 31 Jan 2006 14:04:42 +1100 Received: from frodo.melbourne.sgi.com (root@frodo.melbourne.sgi.com [134.14.55.153]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0V34okt8848526; Tue, 31 Jan 2006 14:04:52 +1100 (EST) Received: from frodo.melbourne.sgi.com (nathans@localhost [127.0.0.1]) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) with ESMTP id k0V32NdU001598; Tue, 31 Jan 2006 14:02:24 +1100 Received: (from nathans@localhost) by frodo.melbourne.sgi.com (8.12.9/8.12.9/Debian-3) id k0V32KtQ001596; Tue, 31 Jan 2006 14:02:20 +1100 Date: Tue, 31 Jan 2006 14:02:20 +1100 From: Nathan Scott To: Jakub Bogusz Cc: linux-xfs@oss.sgi.com Subject: Re: Polish translation for xfsprogs and update for attr Message-ID: <20060131030219.GA1587@frodo> References: <20060121213132.GA22501@fngna.oyu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060121213132.GA22501@fngna.oyu> User-Agent: Mutt/1.5.3i X-archive-position: 7274 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: 384 Lines: 16 On Sat, Jan 21, 2006 at 10:31:32PM +0100, Jakub Bogusz wrote: > Hello, > > I made Polish translation for xfsprogs package, it's available at > ... > I've also updated pl.po for attr 2.4.28 - patch attached > (attr-pl.po-update.patch). > BTW: attr.pot included in attr-2.4.28 package is outdated too. Thanks Jakub, all applied, should show up in CVS overnight. cheers. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 30 19:02:27 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 19:02:28 -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 k0V32Pm2025094 for ; Mon, 30 Jan 2006 19:02:26 -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 OAA13991; Tue, 31 Jan 2006 14:03:24 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 066BD494E42E; Tue, 31 Jan 2006 14:03:23 +1100 (EST) To: linux-xfs@oss.sgi.com Cc: qboosh@pld-linux.org Subject: TAKE 907752 - Polish translations Message-Id: <20060131030323.066BD494E42E@chook.melbourne.sgi.com> Date: Tue, 31 Jan 2006 14:03:23 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7273 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: 2780 Lines: 62 Initial xfsprogs Polish translation, thanks to Jakub Bogusz . Date: Tue Jan 31 13:42:37 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: Jakub Bogusz The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25066a xfsprogs/po/pl.po - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/po/pl.po xfsprogs/VERSION - 1.144 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/VERSION.diff?r1=text&tr1=1.144&r2=text&tr2=1.143&f=h xfsprogs/doc/CHANGES - 1.190 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.190&r2=text&tr2=1.189&f=h xfsprogs/debian/changelog - 1.130 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/debian/changelog.diff?r1=text&tr1=1.130&r2=text&tr2=1.129&f=h xfsprogs/po/Makefile - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/po/Makefile.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfsprogs/quota/util.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/quota/util.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h Rebuild the xfsprogs.pot file for translations. Date: Tue Jan 31 13:59:22 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: Jakub Bogusz The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25067a xfsprogs/po/xfsprogs.pot - 1.11 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/po/xfsprogs.pot.diff?r1=text&tr1=1.11&r2=text&tr2=1.10&f=h Updated Polish translation for attr package, thanks to Jakub Bogusz . Date: Tue Jan 31 14:02:39 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: Jakub Bogusz The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25068a attr/VERSION - 1.59 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.59&r2=text&tr2=1.58&f=h attr/doc/CHANGES - 1.67 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.67&r2=text&tr2=1.66&f=h attr/debian/changelog - 1.60 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/changelog.diff?r1=text&tr1=1.60&r2=text&tr2=1.59&f=h attr/po/attr.pot - 1.4 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/po/attr.pot.diff?r1=text&tr1=1.4&r2=text&tr2=1.3&f=h attr/po/pl.po - 1.3 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/po/pl.po.diff?r1=text&tr1=1.3&r2=text&tr2=1.2&f=h From owner-linux-xfs@oss.sgi.com Mon Jan 30 20:44:41 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 20:44:43 -0800 (PST) Received: from ishtar.tlinx.org (ishtar.tlinx.org [64.81.245.74]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0V4ifm2002134 for ; Mon, 30 Jan 2006 20:44:41 -0800 Received: from [192.168.3.20] (shiva [192.168.3.20]) by ishtar.tlinx.org (8.13.3/8.12.10/SuSE Linux 0.7) with ESMTP id k0V3JNv6007737; Mon, 30 Jan 2006 19:19:24 -0800 Message-ID: <43DED73B.7060902@tlinx.org> Date: Mon, 30 Jan 2006 19:19:23 -0800 From: "L. A. Walsh" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Linux-Kernel CC: Linux-Xfs Subject: Compile warnings in XFS, kernel 2.6.15.1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7275 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: lkml@tlinx.org Precedence: bulk X-list: linux-xfs Content-Length: 1269 Lines: 33 Are these warnings anything to worry about? CC fs/xfs/xfs_bmap.o LD fs/udf/udf.o LD fs/udf/built-in.o CC fs/dnotify.o CC fs/xfs/xfs_bmap_btree.o fs/xfs/xfs_bmap.c: In function `xfs_bmap_search_extents': fs/xfs/xfs_bmap.c:3590: warning: long long unsigned int format, different type arg (arg 5) CC fs/xfs/xfs_btree.o CC fs/xfs/xfs_buf_item.o CC fs/xfs/xfs_iget.o CC fs/xfs/xfs_inode.o CC fs/xfs/xfs_inode_item.o CC fs/xfs/xfs_iocore.o CC fs/xfs/xfs_iomap.o CC fs/xfs/xfs_itable.o fs/xfs/xfs_iomap.c: In function `xfs_iomap_write_direct': fs/xfs/xfs_iomap.c:488: warning: long long unsigned int format, different type arg (arg 5) fs/xfs/xfs_iomap.c: In function `xfs_iomap_write_delay': fs/xfs/xfs_iomap.c:591: warning: long long unsigned int format, different type arg (arg 5) fs/xfs/xfs_iomap.c:697: warning: long long unsigned int format, different type arg (arg 5) fs/xfs/xfs_iomap.c: In function `xfs_iomap_write_allocate': fs/xfs/xfs_iomap.c:834: warning: long long unsigned int format, different type arg (arg 5) fs/xfs/xfs_iomap.c: In function `xfs_iomap_write_unwritten': fs/xfs/xfs_iomap.c:941: warning: long long unsigned int format, different type arg (arg 5) From owner-linux-xfs@oss.sgi.com Mon Jan 30 20:52:07 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 20:52:09 -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 k0V4q5m2002743 for ; Mon, 30 Jan 2006 20:52:06 -0800 Received: from wobbly.melbourne.sgi.com (wobbly.melbourne.sgi.com [134.14.55.135]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16214; Tue, 31 Jan 2006 15:52:58 +1100 Received: from wobbly.melbourne.sgi.com (localhost [127.0.0.1]) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id k0V4r8kt8879889; Tue, 31 Jan 2006 15:53:09 +1100 (EST) Received: (from nathans@localhost) by wobbly.melbourne.sgi.com (SGI-8.12.5/8.12.5/Submit) id k0V4r66g8894171; Tue, 31 Jan 2006 15:53:06 +1100 (EST) Date: Tue, 31 Jan 2006 15:53:06 +1100 From: Nathan Scott To: "L. A. Walsh" Cc: Linux-Kernel , Linux-Xfs Subject: Re: Compile warnings in XFS, kernel 2.6.15.1 Message-ID: <20060131155305.A8865604@wobbly.melbourne.sgi.com> References: <43DED73B.7060902@tlinx.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <43DED73B.7060902@tlinx.org>; from lkml@tlinx.org on Mon, Jan 30, 2006 at 07:19:23PM -0800 X-archive-position: 7276 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: 125 Lines: 8 On Mon, Jan 30, 2006 at 07:19:23PM -0800, L. A. Walsh wrote: > Are these warnings anything to worry about? No. -- Nathan From owner-linux-xfs@oss.sgi.com Mon Jan 30 22:10:09 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Mon, 30 Jan 2006 22:10:10 -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 k0V6A7m2014272 for ; Mon, 30 Jan 2006 22:10:08 -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 RAA17627 for ; Tue, 31 Jan 2006 17:11:05 +1100 Received: by chook.melbourne.sgi.com (Postfix, from userid 16302) id 8A6AE494E42E; Tue, 31 Jan 2006 17:11:03 +1100 (EST) To: linux-xfs@oss.sgi.com Subject: TAKE 907752 - attr - 'tis the season for translations Message-Id: <20060131061103.8A6AE494E42E@chook.melbourne.sgi.com> Date: Tue, 31 Jan 2006 17:11:03 +1100 (EST) From: nathans@sgi.com (Nathan Scott) X-archive-position: 7277 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: 879 Lines: 21 Add Swedish translation for attr package, thanks to Daniel Nylander . Date: Tue Jan 31 17:09:47 AEDT 2006 Workarea: chook.melbourne.sgi.com:/build/nathans/xfs-cmds Inspected by: yeager@lidkoping.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:25071a attr/po/sv.po - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/po/sv.po attr/doc/CHANGES - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h attr/debian/changelog - 1.61 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/debian/changelog.diff?r1=text&tr1=1.61&r2=text&tr2=1.60&f=h attr/po/Makefile - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/po/Makefile.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h From owner-linux-xfs@oss.sgi.com Tue Jan 31 14:02:11 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Jan 2006 14:02:14 -0800 (PST) Received: from bycast.com (bycast.com [207.61.255.252]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k0VM2Am2027035 for ; Tue, 31 Jan 2006 14:02:10 -0800 Received: from [192.168.110.101] (account mmontour [192.168.110.101] verified) by bycast.com (CommuniGate Pro SMTP 4.3.9) with ESMTPA id 423289 for linux-xfs@oss.sgi.com; Tue, 31 Jan 2006 13:03:07 -0800 Message-ID: <43DFD08C.7060803@bycast.com> Date: Tue, 31 Jan 2006 13:03:08 -0800 From: Mike Montour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050921 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-xfs@oss.sgi.com Subject: Build failure with linux-2.6-xfs CVS (no member named i_sem) X-Enigmail-Version: 0.90.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-archive-position: 7279 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: mmontour@bycast.com Precedence: bulk X-list: linux-xfs Content-Length: 2147 Lines: 52 When attempting to build the current linux-2.6-xfs CVS tree, I get the following error: fs/xfs/linux-2.6/xfs_lrw.c: In function `xfs_read': fs/xfs/linux-2.6/xfs_lrw.c:257: error: structure has no member named `i_sem' fs/xfs/linux-2.6/xfs_lrw.c:286: error: structure has no member named `i_sem' fs/xfs/linux-2.6/xfs_lrw.c: In function `xfs_write': fs/xfs/linux-2.6/xfs_lrw.c:636: error: structure has no member named `i_sem' fs/xfs/linux-2.6/xfs_lrw.c:694: warning: implicit declaration of function `inode_update_time' fs/xfs/linux-2.6/xfs_lrw.c:753: error: structure has no member named `i_sem' fs/xfs/linux-2.6/xfs_lrw.c:798: error: structure has no member named `i_sem' fs/xfs/linux-2.6/xfs_lrw.c:805: error: structure has no member named `i_sem' fs/xfs/linux-2.6/xfs_lrw.c:911: error: structure has no member named `i_sem' fs/xfs/linux-2.6/xfs_lrw.c:923: error: structure has no member named `i_sem' make[2]: *** [fs/xfs/linux-2.6/xfs_lrw.o] Error 1 make[1]: *** [fs/xfs] Error 2 make: *** [fs] Error 2 Prior to this, there are many warnings like: CC fs/xfs/linux-2.6/xfs_stats.o In file included from fs/xfs/linux-2.6/xfs_linux.h:49, from fs/xfs/xfs.h:23, from fs/xfs/linux-2.6/xfs_stats.c:18: fs/xfs/linux-2.6/mutex.h:33:1: warning: "mutex_init" redefined In file included from include/linux/mutex.h:74, from include/linux/fs.h:219, from include/linux/mm.h:16, from fs/xfs/linux-2.6/kmem.h:23, from fs/xfs/linux-2.6/xfs_linux.h:45, from fs/xfs/xfs.h:23, from fs/xfs/linux-2.6/xfs_stats.c:18: include/linux/mutex-debug.h:14:1: warning: this is the location of the previous definition Compiler is gcc 3.3.3. Config items: $ grep CONFIG_XFS .config CONFIG_XFS_FS=y CONFIG_XFS_EXPORT=y # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_DMAPI is not set # CONFIG_XFS_SECURITY is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_XFS_RT is not set # CONFIG_XFS_DEBUG is not set # CONFIG_XFS_TRACE is not set Is this a known issue, and/or is there an ETA for a fix? (just asking - it's not urgent for me) From owner-linux-xfs@oss.sgi.com Tue Jan 31 17:16:38 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Jan 2006 17:16:42 -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 k111Gcm2025036 for ; Tue, 31 Jan 2006 17:16:38 -0800 Received: from internal-mail-relay1.corp.sgi.com (internal-mail-relay1.corp.sgi.com [198.149.32.52]) by omx1.americas.sgi.com (8.12.10/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k111HdOX021366 for ; Tue, 31 Jan 2006 19:17:39 -0600 Received: from omx2.sgi.com ([198.149.32.25]) by internal-mail-relay1.corp.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k111LOo3100384292 for ; Tue, 31 Jan 2006 17:21:24 -0800 (PST) Received: from imr2.americas.sgi.com (imr2.americas.sgi.com [198.149.16.18]) by omx2.sgi.com (8.12.11/8.12.9/linux-outbound_gateway-1.1) with ESMTP id k113Ji7o007318 for ; Tue, 31 Jan 2006 19:19:45 -0800 Received: from daisy-e236.americas.sgi.com (daisy-e236.americas.sgi.com [128.162.236.214]) by imr2.americas.sgi.com (8.12.9/8.12.10/SGI_generic_relay-1.2) with ESMTP id k111Y6a511987901; Tue, 31 Jan 2006 17:34:06 -0800 (PST) Received: from naboo.americas.sgi.com (naboo.americas.sgi.com [128.162.233.73]) by daisy-e236.americas.sgi.com (8.12.9/SGI-server-1.8) with ESMTP id k111HaQq350740; Tue, 31 Jan 2006 19:17:37 -0600 (CST) Subject: Re: Build failure with linux-2.6-xfs CVS (no member named i_sem) From: Russell Cattelan To: Mike Montour Cc: linux-xfs@oss.sgi.com In-Reply-To: <43DFD08C.7060803@bycast.com> References: <43DFD08C.7060803@bycast.com> Content-Type: text/plain Date: Tue, 31 Jan 2006 19:17:36 -0600 Message-Id: <1138756656.22367.6.camel@naboo.americas.sgi.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1-1mdk Content-Transfer-Encoding: 7bit X-archive-position: 7280 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: cattelan@thebarn.com Precedence: bulk X-list: linux-xfs Content-Length: 2641 Lines: 67 Hmm sorry about that, there was mix up in the script that pushes the cvs trees out to oss. Internally the kernel tree and the fs/xfs tree are separate and such are pushed out with 2 different rsync's. the xfs-linux directory was being updated but the 2.6.x-xfs/fs/xfs directory was not. Anyways should be all good now. -Russell On Tue, 2006-01-31 at 13:03 -0800, Mike Montour wrote: > When attempting to build the current linux-2.6-xfs CVS tree, I get the > following error: > > fs/xfs/linux-2.6/xfs_lrw.c: In function `xfs_read': > fs/xfs/linux-2.6/xfs_lrw.c:257: error: structure has no member named `i_sem' > fs/xfs/linux-2.6/xfs_lrw.c:286: error: structure has no member named `i_sem' > fs/xfs/linux-2.6/xfs_lrw.c: In function `xfs_write': > fs/xfs/linux-2.6/xfs_lrw.c:636: error: structure has no member named `i_sem' > fs/xfs/linux-2.6/xfs_lrw.c:694: warning: implicit declaration of > function `inode_update_time' > fs/xfs/linux-2.6/xfs_lrw.c:753: error: structure has no member named `i_sem' > fs/xfs/linux-2.6/xfs_lrw.c:798: error: structure has no member named `i_sem' > fs/xfs/linux-2.6/xfs_lrw.c:805: error: structure has no member named `i_sem' > fs/xfs/linux-2.6/xfs_lrw.c:911: error: structure has no member named `i_sem' > fs/xfs/linux-2.6/xfs_lrw.c:923: error: structure has no member named `i_sem' > make[2]: *** [fs/xfs/linux-2.6/xfs_lrw.o] Error 1 > make[1]: *** [fs/xfs] Error 2 > make: *** [fs] Error 2 > > Prior to this, there are many warnings like: > > CC fs/xfs/linux-2.6/xfs_stats.o > In file included from fs/xfs/linux-2.6/xfs_linux.h:49, > from fs/xfs/xfs.h:23, > from fs/xfs/linux-2.6/xfs_stats.c:18: > fs/xfs/linux-2.6/mutex.h:33:1: warning: "mutex_init" redefined > In file included from include/linux/mutex.h:74, > from include/linux/fs.h:219, > from include/linux/mm.h:16, > from fs/xfs/linux-2.6/kmem.h:23, > from fs/xfs/linux-2.6/xfs_linux.h:45, > from fs/xfs/xfs.h:23, > from fs/xfs/linux-2.6/xfs_stats.c:18: > include/linux/mutex-debug.h:14:1: warning: this is the location of the > previous definition > > Compiler is gcc 3.3.3. Config items: > > $ grep CONFIG_XFS .config > CONFIG_XFS_FS=y > CONFIG_XFS_EXPORT=y > # CONFIG_XFS_QUOTA is not set > # CONFIG_XFS_DMAPI is not set > # CONFIG_XFS_SECURITY is not set > # CONFIG_XFS_POSIX_ACL is not set > # CONFIG_XFS_RT is not set > # CONFIG_XFS_DEBUG is not set > # CONFIG_XFS_TRACE is not set > > Is this a known issue, and/or is there an ETA for a fix? (just asking - > it's not urgent for me) > From owner-linux-xfs@oss.sgi.com Tue Jan 31 17:25:25 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Jan 2006 17:25:27 -0800 (PST) Received: from gatekeeper.jupiter.com (gatekeeper.jupiter.com [192.77.175.1]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k111POm2025879 for ; Tue, 31 Jan 2006 17:25:24 -0800 Received: (from smap@localhost) by gatekeeper.jupiter.com (8.11.6/8.11.6) id k110Opf09814 for ; Tue, 31 Jan 2006 16:24:52 -0800 X-Authentication-Warning: gatekeeper.jupiter.com: smap set sender to using -f Received: from metis.jupiter.com(192.77.175.233) by gatekeeper.jupiter.com via smap (V2.1+anti-relay+anti-spam) id xma009799; Tue, 31 Jan 06 16:24:32 -0800 Received: from [192.77.175.138] (eng8.jupiter.com [192.77.175.138]) by jupiter.com (8.11.6/8.8.7) with ESMTP id k110OQU08721; Tue, 31 Jan 2006 16:24:26 -0800 Message-ID: <43DFFFBA.1030404@jupiter.com> Date: Tue, 31 Jan 2006 16:24:26 -0800 From: John Klingler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "L. A. Walsh" CC: Linux-Kernel , Linux-Xfs Subject: Re: Compile warnings in XFS, kernel 2.6.15.1 References: <43DED73B.7060902@tlinx.org> In-Reply-To: <43DED73B.7060902@tlinx.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 7281 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: john@jupiter.com Precedence: bulk X-list: linux-xfs Content-Length: 2066 Lines: 52 The 2.6.11.1 source doesn't line up with your line numbers so I can't say. You'll have to see whether it's stuffing a 64 bit number into a 32 bit number or vice versa and see if that will cause problems. I don't get those error messages when I compile the kernel so maybe someone put a cast in or fixed something. There are still plenty of warnings about uninitialized variable and so on which I would feel more comfortable not seeing. 111 the last time. John L. A. Walsh wrote: > Are these warnings anything to worry about? > > CC fs/xfs/xfs_bmap.o > LD fs/udf/udf.o > LD fs/udf/built-in.o > CC fs/dnotify.o > CC fs/xfs/xfs_bmap_btree.o > fs/xfs/xfs_bmap.c: In function `xfs_bmap_search_extents': > fs/xfs/xfs_bmap.c:3590: warning: long long unsigned int format, > different type arg (arg 5) > CC fs/xfs/xfs_btree.o > CC fs/xfs/xfs_buf_item.o > CC fs/xfs/xfs_iget.o > CC fs/xfs/xfs_inode.o > CC fs/xfs/xfs_inode_item.o > CC fs/xfs/xfs_iocore.o > CC fs/xfs/xfs_iomap.o > CC fs/xfs/xfs_itable.o > fs/xfs/xfs_iomap.c: In function `xfs_iomap_write_direct': > fs/xfs/xfs_iomap.c:488: warning: long long unsigned int format, > different type arg (arg 5) > fs/xfs/xfs_iomap.c: In function `xfs_iomap_write_delay': > fs/xfs/xfs_iomap.c:591: warning: long long unsigned int format, > different type arg (arg 5) > fs/xfs/xfs_iomap.c:697: warning: long long unsigned int format, > different type arg (arg 5) > fs/xfs/xfs_iomap.c: In function `xfs_iomap_write_allocate': > fs/xfs/xfs_iomap.c:834: warning: long long unsigned int format, > different type arg (arg 5) > fs/xfs/xfs_iomap.c: In function `xfs_iomap_write_unwritten': > fs/xfs/xfs_iomap.c:941: warning: long long unsigned int format, > different type arg (arg 5) > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > From owner-linux-xfs@oss.sgi.com Tue Jan 31 20:00:55 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Jan 2006 20:01:00 -0800 (PST) Received: from mail.sessys.com (24-151-19-179.dhcp.nwtn.ct.charter.com [24.151.19.179] (may be forged)) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k1140sm2000730 for ; Tue, 31 Jan 2006 20:00:54 -0800 Received: from mail.sessys.com (mail.sessys.com [192.168.0.2]) by mail.sessys.com (8.13.4/8.13.4-SES) with ESMTP id k1141rBQ016936; Tue, 31 Jan 2006 23:01:53 -0500 Date: Tue, 31 Jan 2006 23:01:53 -0500 (EST) From: "Sean P. Elble" To: Jon Lewis cc: linux-xfs@oss.sgi.com Subject: Re: Problems With 2.4 XFS-NFS CVS Tree/Linux 2.6.15.1 Client In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7282 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: elbles@sessys.com Precedence: bulk X-list: linux-xfs Content-Length: 2194 Lines: 44 Jon, Thanks for a reply. Doing a Google search for the problem caused your name to pop up, but that was it as far as related items were concerned. I was hoping it was a problem that had been fixed since then, but apparently not. All updates seem to be to the 2.6 tree, with the 2.4 tree basically in a state of neglect as far as SGI is concerned. As far as solving the problem, I *tried* to upgrade the 2.4 system to a 2.6 kernel, but that didn't go as planned, with the system going failing sometime during reboot, and causing file system problems. Since I was stupid and did this on a system that is 600 miles away physically, it'll be that way until I go home next time. (The server was actually the main file server at my house, and being a college student, it's hard to take a 1200 mile roundtrip in a weekend. :-)) I do appreciate the reply: it's good to know someone else is running into the same problems. -Sean Elble On Tue, 31 Jan 2006, Jon Lewis wrote: > On Mon, 23 Jan 2006, Sean P. Elble wrote: > >> I have 2 servers setup, one is strictly a file server with a 100 GB drive >> formatted with XFS (with the operating system residing on another drive >> formatted as ext2), exporting shares via NFS from both the XFS partition >> and the ext2 partitions. The ext2 partitions export fine, and can be read >> fine on the "client" (really, the server that does most of the work, which >> is running the 2.6.15.1 kernel), but there are major issues with the XFS >> partition. It seems to export fine, and I can run an ls at the top of the >> NFS mount, but nothing else works, and I mean nothing else. What follows is >> the output of the mount, pwd, and ls commands on the client: > > I didn't see any reply to this, but just wanted to let you know I ran into > exactly the same problem (and posted here about it) not too long ago (couple > months?). Has anyone figured this out yet? > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From owner-linux-xfs@oss.sgi.com Tue Jan 31 21:08:21 2006 Received: with ECARTIS (v1.0.0; list linux-xfs); Tue, 31 Jan 2006 21:08:26 -0800 (PST) Received: from soloth.lewis.org (soloth.lewis.org [69.28.69.2]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id k1158Km2008136 for ; Tue, 31 Jan 2006 21:08:21 -0800 Received: from soloth.lewis.org (localhost.localdomain [127.0.0.1]) by soloth.lewis.org (8.12.11/8.12.11) with ESMTP id k113tIiu024677; Tue, 31 Jan 2006 22:55:18 -0500 Received: from localhost (jlewis@localhost) by soloth.lewis.org (8.12.11/8.12.11/Submit) with ESMTP id k113tI4m024673; Tue, 31 Jan 2006 22:55:18 -0500 X-Authentication-Warning: soloth.lewis.org: jlewis owned process doing -bs Date: Tue, 31 Jan 2006 22:55:17 -0500 (EST) From: Jon Lewis To: "Sean P. Elble" cc: linux-xfs@oss.sgi.com Subject: Re: Problems With 2.4 XFS-NFS CVS Tree/Linux 2.6.15.1 Client In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-archive-position: 7283 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: jlewis@lewis.org Precedence: bulk X-list: linux-xfs Content-Length: 1188 Lines: 22 On Mon, 23 Jan 2006, Sean P. Elble wrote: > I have 2 servers setup, one is strictly a file server with a 100 GB drive > formatted with XFS (with the operating system residing on another drive > formatted as ext2), exporting shares via NFS from both the XFS partition and > the ext2 partitions. The ext2 partitions export fine, and can be read fine on > the "client" (really, the server that does most of the work, which is running > the 2.6.15.1 kernel), but there are major issues with the XFS partition. It > seems to export fine, and I can run an ls at the top of the NFS mount, but > nothing else works, and I mean nothing else. What follows is the output of > the mount, pwd, and ls commands on the client: I didn't see any reply to this, but just wanted to let you know I ran into exactly the same problem (and posted here about it) not too long ago (couple months?). Has anyone figured this out yet? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________