From owner-xfs@oss.sgi.com Sun Jun 1 00:34:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 00:34:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m517Yp0u009710 for ; Sun, 1 Jun 2008 00:34:52 -0700 X-ASG-Debug-ID: 1212305743-280602670000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from yw-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 753A1C348C8 for ; Sun, 1 Jun 2008 00:35:43 -0700 (PDT) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.155]) by cuda.sgi.com with ESMTP id L2tMDiGEC9vYOpxl for ; Sun, 01 Jun 2008 00:35:43 -0700 (PDT) Received: by yw-out-1718.google.com with SMTP id 5so212602ywm.32 for ; Sun, 01 Jun 2008 00:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=pJ9d5vQYMHwboJWXlX8xsZh0y5cXOgNC9M3wyhqz7bM=; b=eR2SFSUGRU8pIN4OQFzildDUMSvnmfk6zYT+w5SBWfuQVTMV8XWpq72eGC76v3UrZFITtthHe9H7yHB65Q24MigseleumQw54DK3JiwHU0zv7PmVax8GpaOKIlETsuJPdknavmywmZfvX3enskkkAXu0tZ0Uw/rHo8TzfcHrPFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ULCTjpeirYXX9ljkOv/B9XJvwQR2XZ2A9In/DMQf1PvfrnmfZUu/aOXAhrND67XEqvARHBgznvWxVLEctDVTEFdDZyVTWBwdoxuwYuuxK6ZgyQqSGx7HJLMJ7PjKMurDwT9cKtcnfq590dKHDBjw6RnSVxVtDLJstdnLpq0QtQU= Received: by 10.151.48.20 with SMTP id a20mr3659789ybk.111.1212305743152; Sun, 01 Jun 2008 00:35:43 -0700 (PDT) Received: from Ahoora.local ( [70.19.190.113]) by mx.google.com with ESMTPS id 9sm2619492ywf.9.2008.06.01.00.35.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Jun 2008 00:35:42 -0700 (PDT) Message-ID: <48425148.1080105@gmail.com> Date: Sun, 01 Jun 2008 03:35:36 -0400 From: Hamid User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Stefan Smietanowski CC: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <483EE5BD.8020407@sandeen.net> <3607657a0805291255i59fd006fi9d6836cf528d19a6@mail.gmail.com> <483F0BC3.2050901@sandeen.net> <3607657a0805291400h3c50165lea6fbea919deed0f@mail.gmail.com> <483F1AED.3010808@sandeen.net> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> In-Reply-To: <48409981.1050405@stesmi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: yw-out-1718.google.com[74.125.46.155] X-Barracuda-Start-Time: 1212305744 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52029 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16211 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs > I think you have the terminology a little mixed up. > > If you mount a something without supplying -o loop "mount" will assume > the filesystem resides in a DEVICE. > > If you mount a something WHILE supplying -o loop you tell "mount" that > it should mount it using a loop device. Note device here, it's trickery > really as what it does is that "mount" will FIRST create a new device > node "/dev/loop0" for example and then it will mount from that device > node. > Thanks Stefan, Now it makes real sense. I guess I am back to my original question: What does 'SB validate failed' indicate and what it really means to my case ? fdisk reports the structure of the Jaz disk as: $ sudo fdisk -ul jaz7.img Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders Units = sectors of 1 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 8: jaz7.img1 3072 2091007 2087936 a SGI xfs 9: jaz7.img2 0 3071 3072 0 SGI volhdr 11: jaz7.img3 0 2091007 2091008 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- 0: sgilabel sector 3 size 512 I went ahead and tried to mount Partition 8 from image using the offset and loop options of the mount command: $ sudo mount -t xfs -o loop,offset=$((512*3072)) jaz7-partition.img /mnt mount: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so And system log says: XFS: bad magic number XFS: SB validate failed So I am guessing I have one of these 3 cases: 1- Bad partition table, good file system 2- Good partition table, corrupt file system 3- Or both gone south!!! I checked the man pages of 'vh' on Irix. It seems that the volhdr partition is 'usually' 2 megabytes but the disk in question has 3072*512 bytes ? Can this be a sign of corruption ? So where would you start looking at if you wanted to fix this problem ? Partition table or the file system ? From owner-xfs@oss.sgi.com Sun Jun 1 02:44:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 02:44:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m519ilF4015130 for ; Sun, 1 Jun 2008 02:44:47 -0700 X-ASG-Debug-ID: 1212313539-4b6602700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3D71F1D889D for ; Sun, 1 Jun 2008 02:45:39 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id oE1GTadybxOot5ce for ; Sun, 01 Jun 2008 02:45:39 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 2132E1C000235; Sun, 1 Jun 2008 05:45:39 -0400 (EDT) Date: Sun, 1 Jun 2008 05:45:39 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1212313540 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0098 1.0000 -1.9573 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.96 X-Barracuda-Spam-Status: No, SCORE=-1.96 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52036 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16212 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and it appears I have hit the limit, if I were able to get the maximum speed of all drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 MiB/s (currently running badblocks on all drives).. I am testing some drives for someone and was curious to see how far one can push the disks/backplane to their theoretical limit. dstat output: ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 1 12 0 83 3 2| - 0 | 0 0 | 0 0 | 13k 23k 1 11 0 84 2 2| 774M 0 |2100B 7373B| 0 0 | 13k 23k 1 12 0 83 3 2| 774M 0 | 0 0 | 0 0 | 13k 23k 1 11 0 82 4 2| 774M 0 |2030B 5178B| 0 0 | 13k 23k 1 11 0 83 4 2| 774M 0 | 0 0 | 0 0 | 13k 23k 1 11 0 83 3 2| 774M 0 |2264B 6225B| 0 0 | 13k 23k vmstat 1 output: ~$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 12 124 3841772 8 13012 0 0 12595 163880 379 352 0 31 37 32 2 12 124 3841772 8 12992 0 0 791744 8 12796 23033 1 18 0 82 0 12 124 3841772 8 12992 0 0 792192 0 12677 22918 1 15 0 84 0 12 124 3841772 8 12992 0 0 792960 0 12894 22929 1 15 0 84 When I was writing to all of the drives it was maxing out around ~650 MiB/s. I also have 2 raptors on a PCI card (as I ran out of PCI-e cards) and: When I read from 1 of the raptors (w/ dd/example shown below) the speed drops: 1 13 0 79 5 3| 764M 0 |2240B 7105B| 0 0 | 12k 21k 1 13 0 80 5 2| 764M 0 | 0 0 | 0 0 | 12k 21k 1 11 0 82 5 2| 764M 0 |2170B 5446B| 0 0 | 12k 21k 1 12 0 81 5 2| 762M 0 | 0 0 | 0 0 | 12k 21k Does/has anyone done this with server intel board/would greater speeds be achievable? Also, how does AMD fair in this regard? Has anyone run similar tests? For instance if you have 12 disks in your host you could: dd if=/dev/disk1 of=/dev/null bs=1M dd if=/dev/disk2 of=/dev/null bs=1M What rate(s) do you get? Justin. From owner-xfs@oss.sgi.com Sun Jun 1 03:45:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 03:45:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51AjZCe018056 for ; Sun, 1 Jun 2008 03:45:35 -0700 X-ASG-Debug-ID: 1212317187-220901230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from proxy2.bredband.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BB83E1D8903 for ; Sun, 1 Jun 2008 03:46:27 -0700 (PDT) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by cuda.sgi.com with ESMTP id jchEmKpSFwASjCja for ; Sun, 01 Jun 2008 03:46:27 -0700 (PDT) Received: from ironport2.bredband.com (195.54.101.122) by proxy2.bredband.net (7.3.127) id 4811833300B18985 for xfs@oss.sgi.com; Sun, 1 Jun 2008 12:46:26 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aro3AHsbQkjVctjQPGdsb2JhbACBVYcIiSQBAQEBLQGZRg Received: from c-d0d872d5.06-15-73746f44.cust.bredbandsbolaget.se (HELO DeepSpaceNine.stesmi.com) ([213.114.216.208]) by ironport2.bredband.com with ESMTP; 01 Jun 2008 12:46:11 +0200 Received: from [127.0.0.1] (voyager.stesmi.com [192.168.1.11]) by DeepSpaceNine.stesmi.com (8.12.11/8.12.11) with ESMTP id m51Ak52S025531; Sun, 1 Jun 2008 12:46:10 +0200 Message-ID: <48427DEE.40400@stesmi.com> Date: Sun, 01 Jun 2008 12:46:06 +0200 From: Stefan Smietanowski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hamid CC: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <483EE5BD.8020407@sandeen.net> <3607657a0805291255i59fd006fi9d6836cf528d19a6@mail.gmail.com> <483F0BC3.2050901@sandeen.net> <3607657a0805291400h3c50165lea6fbea919deed0f@mail.gmail.com> <483F1AED.3010808@sandeen.net> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> In-Reply-To: <48425148.1080105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.7; VAE 6.29.0.5; VDF 6.29.0.100 X-Barracuda-Connect: proxy2.bredband.net[195.54.101.72] X-Barracuda-Start-Time: 1212317188 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52040 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16213 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Hamid wrote: > >> I think you have the terminology a little mixed up. >> >> If you mount a something without supplying -o loop "mount" will assume >> the filesystem resides in a DEVICE. >> >> If you mount a something WHILE supplying -o loop you tell "mount" that >> it should mount it using a loop device. Note device here, it's trickery >> really as what it does is that "mount" will FIRST create a new device >> node "/dev/loop0" for example and then it will mount from that device >> node. >> > Thanks Stefan, Now it makes real sense. > > I guess I am back to my original question: > What does 'SB validate failed' indicate and what it really means to my > case ? > > fdisk reports the structure of the Jaz disk as: > > $ sudo fdisk -ul jaz7.img > > Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders > Units = sectors of 1 * 512 bytes > > ----- partitions ----- > Pt# Device Info Start End Sectors Id System > 8: jaz7.img1 3072 2091007 2087936 a SGI xfs > 9: jaz7.img2 0 3071 3072 0 SGI volhdr > 11: jaz7.img3 0 2091007 2091008 6 SGI volume > ----- Bootinfo ----- > Bootfile: /unix > ----- Directory Entries ----- > 0: sgilabel sector 3 size 512 > > I went ahead and tried to mount Partition 8 from image using the offset > and loop options of the mount command: > > $ sudo mount -t xfs -o loop,offset=$((512*3072)) jaz7-partition.img /mnt > mount: wrong fs type, bad option, bad superblock on /dev/loop1, > missing codepage or helper program, or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > And system log says: > > XFS: bad magic number > XFS: SB validate failed > > So I am guessing I have one of these 3 cases: > 1- Bad partition table, good file system > 2- Good partition table, corrupt file system > 3- Or both gone south!!! > > I checked the man pages of 'vh' on Irix. It seems that the volhdr > partition is 'usually' 2 megabytes but the disk in question has 3072*512 > bytes ? > Can this be a sign of corruption ? > > So where would you start looking at if you wanted to fix this problem ? > Partition table or the file system ? Personally I would hexdump the beginning of the disk looking for the xfs magic of the partition and then try to use that offset in mount. One way is : od -t c jaz7.img | grep X | head Look for X F S B, may be split on two lines for you. This is what my disk looks like but of course, it's on a DOS partition: 0077000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \0 ` \0 Then you have the offset (OCTAL!!) on the left, convert it to decimal, feed that to mount and see if it mounts. Also check if it's the same offset as the partition table is telling you or not. // Stefan From owner-xfs@oss.sgi.com Sun Jun 1 04:00:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 04:00:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51B0HYF019354 for ; Sun, 1 Jun 2008 04:00:18 -0700 X-ASG-Debug-ID: 1212318070-21fd01e40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D2D391D87B2 for ; Sun, 1 Jun 2008 04:01:10 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id 4xB5N9iONjjThQPW for ; Sun, 01 Jun 2008 04:01:10 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id F18BF1C00027A; Sun, 1 Jun 2008 07:01:09 -0400 (EDT) Date: Sun, 1 Jun 2008 07:01:09 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1212318070 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52042 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16214 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 1 Jun 2008, Justin Piszcz wrote: > I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and it > appears I have hit the limit, if I were able to get the maximum speed of all > drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 MiB/s > (currently running badblocks on all drives).. Small correction, they are 7200.11 Seagate Desktop Drives (ST31000340AS), not enterprise drives: http://www.seagate.com/ww/v/index.jsp?vgnextoid=0732f141e7f43110VgnVCM100000f5ee0a0aRCRD http://www.newegg.com/Product/Product.aspx?Item=N82E16822148274 From owner-xfs@oss.sgi.com Sun Jun 1 04:25:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 04:25:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,J_BACKHAIR_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51BPJMg025841 for ; Sun, 1 Jun 2008 04:25:19 -0700 X-ASG-Debug-ID: 1212319570-505402b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BD3ECC350E4 for ; Sun, 1 Jun 2008 04:26:10 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id TE43MHIAPR9a0CWz for ; Sun, 01 Jun 2008 04:26:10 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id C701F1C00027A; Sun, 1 Jun 2008 07:26:09 -0400 (EDT) Date: Sun, 1 Jun 2008 07:26:09 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1212319571 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52041 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16215 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 1 Jun 2008, Justin Piszcz wrote: > > On Sun, 1 Jun 2008, Justin Piszcz wrote: > >> I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and it >> appears I have hit the limit, if I were able to get the maximum speed of >> all drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 MiB/s >> (currently running badblocks on all drives).. > > Small correction, they are 7200.11 Seagate Desktop Drives (ST31000340AS), not > enterprise drives: > > http://www.seagate.com/ww/v/index.jsp?vgnextoid=0732f141e7f43110VgnVCM100000f5ee0a0aRCRD > http://www.newegg.com/Product/Product.aspx?Item=N82E16822148274 > > http://www.intel.com/products/chipsets/g965/diagram.jpg Basically it appears I am hammering the southbridge as for this board the PCI-e (x1) slots also traverse through the southbridge. 6_SATA -> G965 ICH8 3_PCI-e -> G965 ICH8 From which has to ship that data across the DMI (2GB) link to the northbridge. If one utilized a 12, 16 or 24 port raid card (but used SW RAID) on the x16 slot on the northbridge itself, would this barrier exist as the: GMCH<->CPU is (8.5GB/s)..? Also on the X38 and X48 the speed increases slightly: http://www.intel.com/products/chipsets/X38/X38_Block_Diagram.jpg (10.6GB/s) http://www.intel.com/products/chipsets/x48/x48_block_diagram.jpg (12.8GB/s) If one asks why would one need such speed? Example: LTO-4 drives can write at 120 MiB/s each: http://en.wikipedia.org/wiki/Linear_Tape-Open It is then therefore imperative one could sustain this rate to possibly multiple(!) tape drives on a single system. Justin. From owner-xfs@oss.sgi.com Sun Jun 1 05:19:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 05:19:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,J_BACKHAIR_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51CJob1029156 for ; Sun, 1 Jun 2008 05:19:51 -0700 X-ASG-Debug-ID: 1212322841-7dc400ef0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from 1wt.eu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A393E1D8D12 for ; Sun, 1 Jun 2008 05:20:42 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by cuda.sgi.com with ESMTP id GvC7vzq2VcSscgqj for ; Sun, 01 Jun 2008 05:20:42 -0700 (PDT) Date: Sun, 1 Jun 2008 14:20:33 +0200 From: Willy Tarreau To: Justin Piszcz Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Message-ID: <20080601122033.GE5609@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Barracuda-Connect: 1wt.eu[62.212.114.60] X-Barracuda-Start-Time: 1212322843 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52047 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16216 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: w@1wt.eu Precedence: bulk X-list: xfs On Sun, Jun 01, 2008 at 07:26:09AM -0400, Justin Piszcz wrote: > > > On Sun, 1 Jun 2008, Justin Piszcz wrote: > > > > >On Sun, 1 Jun 2008, Justin Piszcz wrote: > > > >>I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and > >>it appears I have hit the limit, if I were able to get the maximum speed > >>of all drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 > >>MiB/s (currently running badblocks on all drives).. > > > >Small correction, they are 7200.11 Seagate Desktop Drives (ST31000340AS), > >not enterprise drives: > > > >http://www.seagate.com/ww/v/index.jsp?vgnextoid=0732f141e7f43110VgnVCM100000f5ee0a0aRCRD > >http://www.newegg.com/Product/Product.aspx?Item=N82E16822148274 > > > > > > http://www.intel.com/products/chipsets/g965/diagram.jpg > > Basically it appears I am hammering the southbridge as for this board the > PCI-e (x1) slots also traverse through the southbridge. > > 6_SATA -> G965 ICH8 > 3_PCI-e -> G965 ICH8 > > >From which has to ship that data across the DMI (2GB) link to the > northbridge. > > If one utilized a 12, 16 or 24 port raid card (but used SW RAID) on the > x16 slot on the northbridge itself, would this barrier exist as the: > GMCH<->CPU is (8.5GB/s)..? > > Also on the X38 and X48 the speed increases slightly: > http://www.intel.com/products/chipsets/X38/X38_Block_Diagram.jpg (10.6GB/s) > http://www.intel.com/products/chipsets/x48/x48_block_diagram.jpg (12.8GB/s) > > If one asks why would one need such speed? It looks like graphic games are pushing the technologies to their limits, which is good for us. I have bought X38 motherboards for 10 Gbps experimentations, and this chipset is perfectly capable of feeding two Myri10GE NICs (20 Gbps total). This is 2.5 GB/s, not counting overhead. So I/O bandwidth is a premium requirement today. Other chipsets I have tested (945 and 965) were very poor (about 4.7 and 6.5 Gbps respectively if my memory serves me right). Willy From owner-xfs@oss.sgi.com Sun Jun 1 06:54:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 06:54:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51DslS3001342 for ; Sun, 1 Jun 2008 06:54:47 -0700 X-ASG-Debug-ID: 1212328536-29cf02eb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server515.appriver.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C042912285F6 for ; Sun, 1 Jun 2008 06:55:36 -0700 (PDT) Received: from server515.appriver.com (server515i.exghost.com [72.32.253.75]) by cuda.sgi.com with ESMTP id clOzJVfS1QXdw6JK for ; Sun, 01 Jun 2008 06:55:36 -0700 (PDT) Received: by server515.appriver.com (CommuniGate Pro PIPE 5.2.0) with PIPE id 37042371; Sun, 01 Jun 2008 08:55:31 -0500 Received: from FE1.exchange.rackspace.com ([72.32.49.5] verified) by server515.appriver.com (CommuniGate Pro SMTP 5.2.0) with ESMTP id 37042367; Sun, 01 Jun 2008 08:55:30 -0500 Received: from 34093-C3-EVS3.exchange.rackspace.com ([192.168.1.161]) by FE1.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Jun 2008 08:55:35 -0500 Received: from 192.168.1.88 ([192.168.1.88]) by 34093-C3-EVS3.exchange.rackspace.com ([192.168.1.78]) with Microsoft Exchange Server HTTP-DAV ; Sun, 1 Jun 2008 13:52:48 +0000 To: "Justin Piszcz" , , , Reply-To: Message-ID: <13c501c8c3ee$c6a31318$330ef40a@exchange.rackspace.com> X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? From: "David Lethe" Thread-Topic: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Thread-Index: AcjD7sai6rpNKVABQ6i5nGsqH2f0tA== Date: Sun, 1 Jun 2008 8:52:00 -0500 MIME-Version: 1.0 X-Mailer: VersaMail(R) v. 3.5.4, Copyright (c) 2001-2006 Palm, Inc. X-Sender: David@santools.com X-Priority: 3 Importance: Normal Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Jun 2008 13:55:35.0041 (UTC) FILETIME=[2A10E710:01C8C3EF] X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Primary: david@santools.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: david@santools.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: PRIVATE->PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.5 X-Note-Reverse-DNS: fe1.exchange.rackspace.com X-Note-WHTLIST: david@santools.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 81 82 139 X-Note: Mail Class: ALLOWEDSENDER X-Barracuda-Connect: server515i.exghost.com[72.32.253.75] X-Barracuda-Start-Time: 1212328538 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.36 X-Barracuda-Spam-Status: No, SCORE=-0.36 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MSGID_DOLLARS X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52053 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.66 MSGID_DOLLARS Message-Id has pattern used in spam X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16217 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@santools.com Precedence: bulk X-list: xfs -----Original Message----- From: "Justin Piszcz" Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Date: Sun Jun 1, 2008 6:02 am Size: 793 bytes To: "linux-kernel@vger.kernel.org" ; "linux-raid@vger.kernel.org" ; "xfs@oss.sgi.com" On Sun, 1 Jun 2008, Justin Piszcz wrote: > I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and it > appears I have hit the limit, if I were able to get the maximum speed of all > drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 MiB/s > (currently running badblocks on all drives).. Small correction, they are 7200.11 Seagate Desktop Drives (ST31000340AS), not enterprise drives: http://www.seagate.com/ww/v/index.jsp?vgnextoid=0732f141e7f43110VgnVCM100000f5ee0a0aRCRD http://www.newegg.com/Product/Product.aspx?Item=N82E16822148274 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From owner-xfs@oss.sgi.com Sun Jun 1 13:27:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 13:27:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51KRZqj029204 for ; Sun, 1 Jun 2008 13:27:36 -0700 X-ASG-Debug-ID: 1212352106-666902cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9094179151B for ; Sun, 1 Jun 2008 13:28:27 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by cuda.sgi.com with ESMTP id 0bxMG9S2G6W8vMz8 for ; Sun, 01 Jun 2008 13:28:27 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so619237fgb.8 for ; Sun, 01 Jun 2008 13:28:26 -0700 (PDT) Received: by 10.86.82.16 with SMTP id f16mr1520486fgb.9.1212352106065; Sun, 01 Jun 2008 13:28:26 -0700 (PDT) Received: from Roman-NB ( [89.18.196.252]) by mx.google.com with ESMTPS id d4sm2718640fga.8.2008.06.01.13.28.24 (version=SSLv3 cipher=OTHER); Sun, 01 Jun 2008 13:28:24 -0700 (PDT) Date: Sun, 1 Jun 2008 23:28:16 +0300 From: Roman Kravchenko Organization: A Technologies X-Priority: 3 (Normal) Message-ID: <1562332443.20080601232816@atech.lv> To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs write locks Subject: xfs write locks MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.156] X-Barracuda-Start-Time: 1212352108 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0927 1.0000 -1.4363 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.44 X-Barracuda-Spam-Status: No, SCORE=-1.44 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52079 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m51KRaqj029207 X-archive-position: 16218 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: roman@atech.lv Precedence: bulk X-list: xfs Hello Xfs, Not sure if i have to report it this way... but anyway, at least it will be informative. I have problems with XFS file system with quota support. It sometimes freeze on write operations to filesystem. It's rare, freeze ocurring after a week or two of normal opetaion. I experience it since 2.6.23 series kernel and unable to track it down to get more detailed info... It's possible that it related to locking, as filesystem is still accesible for read operations. But I unable to recover additional info and just recently recompiled kernel with debug info to track it down. so far the only info I get is this INFO warning on boot: ============================================= [ INFO: possible recursive locking detected ] 2.6.25.4-g6dbg #1 --------------------------------------------- mysqld/1883 is trying to acquire lock: (&list->qh_lock){--..}, at: [] xfs_qm_dqget+0x288/0x370 but task is already holding lock: (&list->qh_lock){--..}, at: [] xfs_qm_dqget+0xbd/0x370 other info that might help us debug this: 3 locks held by mysqld/1883: #0: (&type->i_mutex_dir_key#2){--..}, at: [] open_namei+0xf1/0x5f0 #1: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x8f/0xd0 #2: (&list->qh_lock){--..}, at: [] xfs_qm_dqget+0xbd/0x370 stack backtrace: Pid: 1883, comm: mysqld Not tainted 2.6.25.4-g6dbg #1 [] __lock_acquire+0xe5d/0x1080 [] __lock_acquire+0x376/0x1080 [] lock_acquire+0x87/0xb0 [] xfs_qm_dqget+0x288/0x370 [] mutex_lock_nested+0x9e/0x280 [] xfs_qm_dqget+0x288/0x370 [] xfs_qm_dqget+0x288/0x370 [] xfs_qm_dqget+0x288/0x370 [] xfs_qm_dqattach_one+0xd2/0x1a0 [] xfs_qm_dqattach+0x1a2/0x1d0 [] xfs_qm_vop_dqalloc+0x248/0x300 [] xfs_create+0xa9/0x490 [] native_sched_clock+0x7b/0xd0 [] xfs_vn_mknod+0x159/0x1a0 [] vfs_create+0xc9/0x120 [] open_namei+0x550/0x5f0 [] do_filp_open+0x2e/0x60 [] _spin_unlock+0x14/0x20 [] get_unused_fd_flags+0xc5/0xe0 [] do_sys_open+0x4c/0xe0 [] sys_open+0x2c/0x40 [] syscall_call+0x7/0xb ======================= If there is any additional info that might help you, I'm gladly provide it to you. -- Best regards, Roman Kravchenko A Technologies From owner-xfs@oss.sgi.com Sun Jun 1 18:58:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 18:58:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m521wMjs017814 for ; Sun, 1 Jun 2008 18:58:23 -0700 X-ASG-Debug-ID: 1212371954-4072025a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5DA2912BB839 for ; Sun, 1 Jun 2008 18:59:14 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id 2XWhVBzrG6kwWuqE for ; Sun, 01 Jun 2008 18:59:14 -0700 (PDT) Received: from ppp121-44-83-140.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.83.140]) by ipmail04.adl2.internode.on.net with ESMTP; 02 Jun 2008 11:28:41 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K2zJn-0002Bq-S4; Mon, 02 Jun 2008 11:58:39 +1000 Date: Mon, 2 Jun 2008 11:58:39 +1000 From: Dave Chinner To: Tom Spink Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [RFC PATCH 0/2] On-demand Filesystem Initialisation Subject: Re: [RFC PATCH 0/2] On-demand Filesystem Initialisation Message-ID: <20080602015831.GB2428@disturbed> Mail-Followup-To: Tom Spink , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com References: <1212331915-22856-1-git-send-email-tspink@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1212331915-22856-1-git-send-email-tspink@gmail.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1212371956 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52101 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16219 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Sun, Jun 01, 2008 at 03:51:53PM +0100, Tom Spink wrote: > > (resend to include CCs) What cc's? Still no xfs cc on it. I added it to this reply.... > This (short) patch series is another RFC for the patch that introduces on-demand > filesystem initialisation. In addition to the original infrastructure > implementation (with clean-ups), it changes XFS to use this new infrastructure. > > I wrote a toy filesystem (testfs) to simulate scheduling/allocation delays and > to torture the mount/unmount cycles. I didn't manage to deadlock the system > in my tests. XFS also works as expected aswell, in that the global threads > are not created until an XFS filesystem is mounted for the first time. When the > last XFS filesystem is unmounted, the threads go away. > > Please let me know what you think! Why even bother? This is why we have /modular/ kernels - if you're not using XFS then don't load it and you won't see those pesky threads. That'll save on a bunch of memory as well because the xfs module ain't small (>480k on i386).... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 1 19:08:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 19:08:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5227uTd018505 for ; Sun, 1 Jun 2008 19:08:00 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20016; Mon, 2 Jun 2008 12:08:42 +1000 Message-ID: <4843562A.9030503@sgi.com> Date: Mon, 02 Jun 2008 12:08:42 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Spam Magnet CC: Eric Sandeen , xfs@oss.sgi.com Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <483EE5BD.8020407@sandeen.net> <3607657a0805291255i59fd006fi9d6836cf528d19a6@mail.gmail.com> <483F0BC3.2050901@sandeen.net> <3607657a0805291400h3c50165lea6fbea919deed0f@mail.gmail.com> <483F1AED.3010808@sandeen.net> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> In-Reply-To: <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16220 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Spam Magnet wrote: >> As Eric said. >> We chose the ondisk format to have the byte ordering of IRIX so >> it should not be a problem. However, parts of the log code in Linux >> does not do the necessary endian conversion (due to lack of info at >> the relevant points - it only knows as blobs of data) and so you >> need the log to be clean. i.e. byte ordering problem just for the log. >> > > Thanks for this info, it's good to have 1 less problem to worry about :) > >> OOI, as Eric asked, how were you able to mount it all of a sudden? >> > > I am not sure, as I said, to narrow down the problem I am experiencing > with other disks, I decided to format an empty, healthy disk under Irix and > try to mount it under Linux. The first try was not successful but the > second was. > > Right now I am making an image of the good/healthy disk using dd to > see if I can mount that > image under Linux. (It's not fun to copy 2GB disks through a > USB1.1-SCSI adapter :) :-) If the fs is not too full then xfs_copy would be good I suppose as it won't copy freespace. --Tim From owner-xfs@oss.sgi.com Sun Jun 1 22:40:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 22:40:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m525eJcR010012 for ; Sun, 1 Jun 2008 22:40:20 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23428 for ; Mon, 2 Jun 2008 15:41:11 +1000 Date: Mon, 02 Jun 2008 15:42:55 +1000 To: "xfs@oss.sgi.com" Subject: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id m525eMcR010015 X-archive-position: 16221 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs In particular, this patch fixes a problem in the xfs_dir2_remove and xfs_dir2_replace paths which internally can call a lookup function which will use args->cmpresult which is uninitialised. -- Index: 2.6.x-xfs/fs/xfs/xfs_dir2.c =================================================================== --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2.c +++ 2.6.x-xfs/fs/xfs/xfs_dir2.c @@ -213,6 +213,7 @@ xfs_dir_createname( if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) return rval; XFS_STATS_INC(xs_dir_create); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; @@ -297,7 +298,6 @@ xfs_dir_lookup( args.op_flags = XFS_DA_OP_OKNOENT; if (ci_name) args.op_flags |= XFS_DA_OP_CILOOKUP; - args.cmpresult = XFS_CMP_DIFFERENT; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_lookup(&args); @@ -342,6 +342,7 @@ xfs_dir_removename( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_remove); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; @@ -353,7 +354,6 @@ xfs_dir_removename( args.total = total; args.whichfork = XFS_DATA_FORK; args.trans = tp; - args.op_flags = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_removename(&args); @@ -425,6 +425,7 @@ xfs_dir_replace( if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) return rval; + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; @@ -436,7 +437,6 @@ xfs_dir_replace( args.total = total; args.whichfork = XFS_DATA_FORK; args.trans = tp; - args.op_flags = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_replace(&args); From owner-xfs@oss.sgi.com Sun Jun 1 22:49:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 22:49:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_47, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m525naOp010606 for ; Sun, 1 Jun 2008 22:49:36 -0700 X-ASG-Debug-ID: 1212385828-05f103290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6146E1B9B370; Sun, 1 Jun 2008 22:50:28 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id iYGtC207vq20oayH; Sun, 01 Jun 2008 22:50:28 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K32w8-0000yq-H4; Mon, 02 Jun 2008 05:50:28 +0000 Date: Mon, 2 Jun 2008 01:50:28 -0400 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c Subject: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c Message-ID: <20080602055028.GA1629@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212385829 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16222 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 02, 2008 at 03:42:55PM +1000, Barry Naujok wrote: > In particular, this patch fixes a problem in the xfs_dir2_remove and > xfs_dir2_replace paths which internally can call a lookup function > which will use args->cmpresult which is uninitialised. > Index: 2.6.x-xfs/fs/xfs/xfs_dir2.c > =================================================================== > --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2.c > +++ 2.6.x-xfs/fs/xfs/xfs_dir2.c > @@ -213,6 +213,7 @@ xfs_dir_createname( > if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) > return rval; > XFS_STATS_INC(xs_dir_create); > + memset(&args, 0, sizeof(xfs_da_args_t)); > > args.name = name->name; > args.namelen = name->len; Doing these memsets looks good. Stylisticly I'd rather put them directly in front of the intialization for the actually used args fields. From owner-xfs@oss.sgi.com Sun Jun 1 23:05:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 23:05:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5265nwL011526 for ; Sun, 1 Jun 2008 23:05:51 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24162; Mon, 2 Jun 2008 16:06:33 +1000 To: "Christoph Hellwig" Subject: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20080602055028.GA1629@infradead.org> Date: Mon, 02 Jun 2008 16:08:23 +1000 Message-ID: In-Reply-To: <20080602055028.GA1629@infradead.org> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id m5265rwL011529 X-archive-position: 16223 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Mon, 02 Jun 2008 15:50:28 +1000, Christoph Hellwig wrote: > On Mon, Jun 02, 2008 at 03:42:55PM +1000, Barry Naujok wrote: >> In particular, this patch fixes a problem in the xfs_dir2_remove and >> xfs_dir2_replace paths which internally can call a lookup function >> which will use args->cmpresult which is uninitialised. > >> Index: 2.6.x-xfs/fs/xfs/xfs_dir2.c >> =================================================================== >> --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2.c >> +++ 2.6.x-xfs/fs/xfs/xfs_dir2.c >> @@ -213,6 +213,7 @@ xfs_dir_createname( >> if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) >> return rval; >> XFS_STATS_INC(xs_dir_create); >> + memset(&args, 0, sizeof(xfs_da_args_t)); >> >> args.name = name->name; >> args.namelen = name->len; > > Doing these memsets looks good. Stylisticly I'd rather put them > directly in front of the intialization for the actually used args > fields. I agree, so here's the alternative patch which makes them all consistent: Index: 2.6.x-xfs/fs/xfs/xfs_dir2.c =================================================================== --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2.c +++ 2.6.x-xfs/fs/xfs/xfs_dir2.c @@ -214,6 +214,7 @@ xfs_dir_createname( return rval; XFS_STATS_INC(xs_dir_create); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); @@ -286,8 +287,8 @@ xfs_dir_lookup( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_lookup); - memset(&args, 0, sizeof(xfs_da_args_t)); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); @@ -297,7 +298,6 @@ xfs_dir_lookup( args.op_flags = XFS_DA_OP_OKNOENT; if (ci_name) args.op_flags |= XFS_DA_OP_CILOOKUP; - args.cmpresult = XFS_CMP_DIFFERENT; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_lookup(&args); @@ -343,6 +343,7 @@ xfs_dir_removename( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_remove); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); @@ -353,7 +354,6 @@ xfs_dir_removename( args.total = total; args.whichfork = XFS_DATA_FORK; args.trans = tp; - args.op_flags = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_removename(&args); @@ -426,6 +426,7 @@ xfs_dir_replace( if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) return rval; + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); @@ -436,7 +437,6 @@ xfs_dir_replace( args.total = total; args.whichfork = XFS_DATA_FORK; args.trans = tp; - args.op_flags = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_replace(&args); @@ -472,8 +472,8 @@ xfs_dir_canenter( return 0; ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); - memset(&args, 0, sizeof(xfs_da_args_t)); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); From owner-xfs@oss.sgi.com Sun Jun 1 23:08:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 23:08:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m52682rh011882 for ; Sun, 1 Jun 2008 23:08:02 -0700 X-ASG-Debug-ID: 1212386935-05e403ba0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3EF2A1B9B6CD; Sun, 1 Jun 2008 23:08:55 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id I47Y3vnrBKmczeUn; Sun, 01 Jun 2008 23:08:55 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K33Dz-0004yT-Ck; Mon, 02 Jun 2008 06:08:55 +0000 Date: Mon, 2 Jun 2008 02:08:55 -0400 From: Christoph Hellwig To: Barry Naujok Cc: Christoph Hellwig , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c Subject: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c Message-ID: <20080602060855.GA25939@infradead.org> References: <20080602055028.GA1629@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212386936 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16224 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 02, 2008 at 04:08:23PM +1000, Barry Naujok wrote: > I agree, so here's the alternative patch which makes them all > consistent: Looks good. From owner-xfs@oss.sgi.com Mon Jun 2 06:38:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jun 2008 06:39:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m52DcqsW029194 for ; Mon, 2 Jun 2008 06:38:53 -0700 X-ASG-Debug-ID: 1212413985-1f7f002b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5C6021B9D2C7 for ; Mon, 2 Jun 2008 06:39:45 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.249]) by cuda.sgi.com with ESMTP id fY6lHI58AGLiqU88 for ; Mon, 02 Jun 2008 06:39:45 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so815302rvb.32 for ; Mon, 02 Jun 2008 06:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=n8oHevPOb1/PzCYnoPCrrBmg2/gf8fGv06tlLX1nXf4=; b=XLyGAu56dMlDY5FyjlMvgYIrtCEJYQIU+/WxZ59X7CURB34mMOp11k9IqXNBzKv8cAR6y4XFLf+1hOyXCh/1sZiBApf5BzmM7H7v6Rc14Jb5yEoJ+rmuU8iC664qjgKqNJNU5RXYvES9uZcwYx19mWzqyXZQs+LWJve8hP4R8lE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z0WyMe+xk0SovtBvuY6D1d+CNYCCLsyIfAMtJ9WvNAAtIIW+0kib0wwAbXkwvDhKHv8E3tDsGQEl8IitfyFXwoq+XIUG6acbvlksPzu/fGiQoCy52F/IAlEFoM2ntxL4lJbO8+APG43kQ5B3ZFKaDWo4mE6CiKcSSQZo7QKcwTU= Received: by 10.141.13.16 with SMTP id q16mr4923585rvi.99.1212413985383; Mon, 02 Jun 2008 06:39:45 -0700 (PDT) Received: by 10.140.173.6 with HTTP; Mon, 2 Jun 2008 06:39:40 -0700 (PDT) Message-ID: <7b9198260806020639n7679035s270c0ce3575a894b@mail.gmail.com> Date: Mon, 2 Jun 2008 14:39:40 +0100 From: "Tom Spink" To: "Tom Spink" , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [RFC PATCH 0/2] On-demand Filesystem Initialisation Subject: Re: [RFC PATCH 0/2] On-demand Filesystem Initialisation In-Reply-To: <20080602015831.GB2428@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1212331915-22856-1-git-send-email-tspink@gmail.com> <20080602015831.GB2428@disturbed> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.249] X-Barracuda-Start-Time: 1212413986 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2804 1.0000 -0.4338 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.43 X-Barracuda-Spam-Status: No, SCORE=-0.43 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52148 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16225 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tspink@gmail.com Precedence: bulk X-list: xfs 2008/6/2 Dave Chinner : > On Sun, Jun 01, 2008 at 03:51:53PM +0100, Tom Spink wrote: >> >> (resend to include CCs) > > What cc's? Still no xfs cc on it. I added it to this reply.... > >> This (short) patch series is another RFC for the patch that introduces on-demand >> filesystem initialisation. In addition to the original infrastructure >> implementation (with clean-ups), it changes XFS to use this new infrastructure. >> >> I wrote a toy filesystem (testfs) to simulate scheduling/allocation delays and >> to torture the mount/unmount cycles. I didn't manage to deadlock the system >> in my tests. XFS also works as expected aswell, in that the global threads >> are not created until an XFS filesystem is mounted for the first time. When the >> last XFS filesystem is unmounted, the threads go away. >> >> Please let me know what you think! > > Why even bother? This is why we have /modular/ kernels - if you're > not using XFS then don't load it and you won't see those pesky > threads. That'll save on a bunch of memory as well because the xfs > module ain't small (>480k on i386).... Yeah, absolutely. But if the filesystem is built-in, you can't unload it. > Cheers, > > Dave. Thanks for taking a look, anyway! -- Tom Spink From owner-xfs@oss.sgi.com Mon Jun 2 17:15:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jun 2008 17:15:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m530Fips025383 for ; Mon, 2 Jun 2008 17:15:44 -0700 X-ASG-Debug-ID: 1212452195-0ad902cc0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from seznam.cz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 737F81DC81A for ; Mon, 2 Jun 2008 17:16:36 -0700 (PDT) Received: from seznam.cz (ds87-230-58-90.dedicated.hosteurope.de [87.230.58.90]) by cuda.sgi.com with ESMTP id s6UG6RCSXQeTtODO for ; Mon, 02 Jun 2008 17:16:36 -0700 (PDT) Reply-To: lanislav.novak@seznam.cz From: Karikatury.eu@oss.sgi.com To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Mohamed cartoons - Praha; Skandalni! Mohamed jako pedofil. Foto, Video, link reportaz; svoboda slova je zakladni hodnota! Subject: Mohamed cartoons - Praha; Skandalni! Mohamed jako pedofil. Foto, Video, link reportaz; svoboda slova je zakladni hodnota! Date: 03 Jun 2008 02:16:59 +0200 Message-ID: <20080603021658.BB5AE0FFD3DCA8F9@from.header.has.no.domain> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ds87-230-58-90.dedicated.hosteurope.de[87.230.58.90] X-Barracuda-Start-Time: 1212452197 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5530 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.85 X-Barracuda-Spam-Status: No, SCORE=0.85 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MANY_EXCLAMATIONS, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MANY_EXCLAMATIONS Subject has many exclamations 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16226 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Karikatury.eu@oss.sgi.com Precedence: bulk X-list: xfs Keywords: mohamed cartoons Rough cartoon: http://www.karikatury.eu/karikatura-mohamed-vrah-pedofil.jpg Czech version. -------- Dobry den, dne 31.5.2008 byly po Praze hromadne vylepovany karikatury mohameda. viz zpravy: http://www.novinky.cz/clanek/141314-v-praze-se-objevily-karikatury-s-mohamedem.html http://zpravy.idnes.cz/karikatury-proroka-mohameda-se-objevily-i-v-praze-fvg-/praha.asp?c=A080531_195031_praha_jan www.karikatury.eu (foto, karikatury, + filmy ke stazeni zdarma) Jako naprosto nehorazna reakce na tzv. "danske karikatury" bylo v roce 2006 zabito mnoho lidi a spachano mnoho teroru ze strany muslimu. Evropska unie, misto aby podporila severske staty, jimz byly niceny ambasady, se omluvila muslimskemu svetu! Je dulezite podotknout, ze svoboda slova je nevyslovnekrat dulezitejsi nez jakekoliv nabozenstvi... alespon v Evrope. V moderni sekularni spolecnosti je chovani muslimu (u vetsiny zatim pouze postoje a nazory) neakceptovatelne. Konflikt ohledne karikatur (a vy se na ne nyni mate moznost podivat -a posoudit zdali je akceptovatelne ze muslimsky svet vola po vyhlazeni Danska a pacha teror kvuli par obrazkum) ... ukazuje na stret civilizaci. Predevsim islam ma "krvave hranice", a jedna se o nabozenstvi, ktere dosud neprekonalo stredoveky koncept. Spousta problemu vznikla diky velkoryse imigracni politice zapadnich evropskych zemi (ktera byla vzhledek ke stavu na pracovnim trhu proklamovana za nutnou:(, jejiz predstavitele pokladali imigranty z rizikovych oblasti (tam kde jsou spolecnosti ovladane islamem) jako za rovnocene napriklad pristehovalcum z Ciny / Indie / Vietnamu. Nasledkem toho je fakt, ze drtiva vetsina teroristickych utoku za poslednich 15 let byla zpusobena temito muslimskymi imigranty. Experti, jez se zabyvaji bezpecnosti vi, ze muslimske minority predstavuji zasadni bezpecnostni riziko. Celkova idea podpory imigrace, predevsim muslimu, byla spatna - mnoho pristehovalcu (zejmena z druhe generace) se citi vykoreneni ze sve kultury a zaroven se nestotoznuji se zapadnim zivotem > I utoky na WTC byly zpusobeny rekruty z vyse nastineneho prostredi. Presto politici neuznali svou chybu! Naopak, tehdejsi pojeti imigrace, jez zpusobilo soucasny stav, stale pokracuje. Misto, aby politicke reprezentace uznaly, ze muslimske minority prinaseji bezpecnostni riziko (s tim jak rostou-se rizika zvetsuji!), tak dochazi k erozi svobody vetsinove spolecnosti. Kdo cestuje letadlem, tak si uvedomuje zprisneni kontrol a bezpecnostnich podminek za posledni roky. Kamery na kazdem rohu je podobna zalezitost. A v posledni dobe je patrny stale vetsi natlak na prispusobovani se muslimskym minoritam. Predevsim v otazce karikatur. Je zde duvod - strach z reakce muslimu. Ovsem pokud se muslimu musime obavat, pak je tu problem, ze?! A ten problem je predevsim v zemich kam se pristehovaly extremne velke muslimske minority (jako napriklad Holansko - kde byl napriklad zabyt filmar jen proto ze muslim proti nemu vedl "dzihad"), nebo ne? Ne tak docela. I ceska vlada planuje prijimat spousty imigrantu - A NEHODLA ZAUJMOUT SELEKTIVNI PRISTUP! STOP IMIGRACI, alespon te muslimske, dokud u islamu - podobne jako kdysi u ostatnich nabozenstvi - nepomine stredovek. Stop erozi nasich univerzalnich svobod. Islam ... vime ze toto nabozensti vynucuje "svou vuli" na uzemi jez si podmanilo (napr. Darfur). Je treba, abychom my, Evropane - kdyz politicka reprezentace nas strach o bezpecnost a nase hodnoty a svobodu nerespektuje - ukazali, ze zde jsme v SEKULARNI SVOBODNE SPOLECNOSTI. Pokud muslimove pokladaji islamska pravidla za nadrazenejsi nasim (nedavno) samozrejmym hodnotam a pravidlum - pak tu nemaji co delat! Nebo je alespon nutne zastavit priliv novych imigrantu z techto oblasti - nad cimz ma kazdy stat plnou suverenitu. Praktikujme svoji svobodu! (Kdo vi jak bude Evropa vypadat za 15 let pokud zde bude posilovat vliv nebezpecneho islamu). Podivejte se na fotografie z terenu - vylepy po Praze na webu jez doporucujeme shlednout. Mame 6 brigadnic (ktere nemaji radi islam kvuli stavu zenskych prav pod islamem) ktere budou nadale lepit karikatury po CR ....a hledame dalsi spolupracovniky/spolupracovnice jez budou vylepovat karikatury/reklamy i v ostatnich zemich EU. Nejedna se o provokaci, ale o upozorneni na problem. Tento email je castecne siren jako mass mail a castecne ho prijemci preposilaji dal. Pokud Vam tento problem neni lhostejny, preposilejte dal. www.karikatury.eu - prohlednete si karikatury, fotografie z terenu (nase vylepy po Praze) a spoustu Filmu a vice... Izabela From owner-xfs@oss.sgi.com Mon Jun 2 18:07:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jun 2008 18:07:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5317lHC028933 for ; Mon, 2 Jun 2008 18:07:49 -0700 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 LAA16986; Tue, 3 Jun 2008 11:08:36 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id A9BDB58C4C3F; Tue, 3 Jun 2008 11:08:36 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 982421 - xfs_repair: Doesn't work with 16KB filesystem blocksize. Message-Id: <20080603010836.A9BDB58C4C3F@chook.melbourne.sgi.com> Date: Tue, 3 Jun 2008 11:08:36 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16227 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Fix up inode cluster I/O size in repair for >8KB block size filesystems Date: Tue Jun 3 11:07:54 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31267a xfsprogs/repair/xfs_repair.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/xfs_repair.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h xfsprogs/repair/prefetch.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/prefetch.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h - Fix up inode cluster I/O size in repair for >8KB block size filesystems From owner-xfs@oss.sgi.com Mon Jun 2 18:47:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jun 2008 18:47:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m531lrof031651 for ; Mon, 2 Jun 2008 18:47:54 -0700 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 LAA17821; Tue, 3 Jun 2008 11:48:42 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id C552F58C4C3F; Tue, 3 Jun 2008 11:48:42 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 982606 - Strange unlink behaviour Message-Id: <20080603014842.C552F58C4C3F@chook.melbourne.sgi.com> Date: Tue, 3 Jun 2008 11:48:42 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16228 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Zero uninitialised xfs_da_args structure in xfs_dir2.c Fixes a problem in the xfs_dir2_remove and xfs_dir2_replace paths which intenally call directory format specific lookup funtions that assume args->cmpresult is zeroed. Date: Tue Jun 3 11:47:47 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31268a fs/xfs/xfs_dir2.c - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2.c.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h - Zero uninitialised xfs_da_args structures From owner-xfs@oss.sgi.com Tue Jun 3 00:59:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 00:59:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m537xZwI029253 for ; Tue, 3 Jun 2008 00:59:35 -0700 X-ASG-Debug-ID: 1212480027-1fb502350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D3D251DD5B3 for ; Tue, 3 Jun 2008 01:00:27 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id uHpVlzzAGewAgWtn for ; Tue, 03 Jun 2008 01:00:27 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5380JOc019801 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 10:00:20 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5380JUv019799 for xfs@oss.sgi.com; Tue, 3 Jun 2008 10:00:19 +0200 Date: Tue, 3 Jun 2008 10:00:19 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] fix mount option parsing in remount Subject: Re: [PATCH] fix mount option parsing in remount Message-ID: <20080603080019.GB19608@lst.de> References: <20080518153539.GA5218@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080518153539.GA5218@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212480028 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52221 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16230 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs ping? silently ignoring wrong options causes a lot of confusion for users, and the patch sould simple enough. Anyone take 10 minutes to review it and check it in? On Sun, May 18, 2008 at 05:35:39PM +0200, Christoph Hellwig wrote: > Remount currently happily accept any option thrown at it, although the > only filesystem specific option it actually handles is barrier/nobarrier. > And it actually doesn't handle these correctly either because it only > uses the value it parsed when we're doing a ro->rw transition. In > addition to that there's also a bad bug in xfs_parseargs which doesn't > touch the actual option in the mount point except for a single one, > XFS_MOUNT_SMALL_INUMS and thus forced any filesystem that's every > remounted in some way to not support 64bit inodes with no way to recover > unless unmounted. > > This patch changes xfs_fs_remount to use it's own linux/parser.h based > options parse instead of xfs_parseargs and reject all options except > for barrier/nobarrier and to the right thing in general. Eventually > I'd like to have a single big option table used for mount aswell but > that can wait for a while. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2008-05-18 15:22:23.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-05-18 15:59:32.000000000 +0200 > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > static struct quotactl_ops xfs_quotactl_operations; > static struct super_operations xfs_super_operations; > @@ -1255,6 +1256,19 @@ xfs_fs_statfs( > return 0; > } > > +/* > + * Eventually we should extend this table and use it for mount, too. > + */ > +enum { > + Opt_barrier, Opt_nobarrier, Opt_err > +}; > + > +static match_table_t tokens = { > + {Opt_barrier, "barrier"}, > + {Opt_nobarrier, "nobarrier"}, > + {Opt_err, NULL} > +}; > + > STATIC int > xfs_fs_remount( > struct super_block *sb, > @@ -1262,36 +1276,54 @@ xfs_fs_remount( > char *options) > { > struct xfs_mount *mp = XFS_M(sb); > - struct xfs_mount_args *args; > - int error; > + substring_t args[MAX_OPT_ARGS]; > + char *p; > > - args = xfs_args_allocate(sb, 0); > - if (!args) > - return -ENOMEM; > + while ((p = strsep(&options, ",")) != NULL) { > + int token; > > - error = xfs_parseargs(mp, options, args, 1); > - if (error) > - goto out_free_args; > + if (!*p) > + continue; > > - if (!(*flags & MS_RDONLY)) { /* rw/ro -> rw */ > - if (mp->m_flags & XFS_MOUNT_RDONLY) > - mp->m_flags &= ~XFS_MOUNT_RDONLY; > - if (args->flags & XFSMNT_BARRIER) { > + token = match_token(p, tokens, args); > + switch (token) { > + case Opt_barrier: > mp->m_flags |= XFS_MOUNT_BARRIER; > - xfs_mountfs_check_barriers(mp); > - } else { > + > + /* > + * Test if barriers are actually working if we can, > + * else delay this check until the filesystem is > + * marked writeable. > + */ > + if (!(mp->m_flags & XFS_MOUNT_RDONLY)) > + xfs_mountfs_check_barriers(mp); > + break; > + case Opt_nobarrier: > mp->m_flags &= ~XFS_MOUNT_BARRIER; > + break; > + default: > + printk(KERN_INFO > + "XFS: mount option \"%s\" not support for remount\n", p); > + return -EINVAL; > } > - } else if (!(mp->m_flags & XFS_MOUNT_RDONLY)) { /* rw -> ro */ > + } > + > + /* rw/ro -> rw */ > + if ((mp->m_flags & XFS_MOUNT_RDONLY) && !(*flags & MS_RDONLY)) { > + mp->m_flags &= ~XFS_MOUNT_RDONLY; > + if (mp->m_flags & XFS_MOUNT_BARRIER) > + xfs_mountfs_check_barriers(mp); > + } > + > + /* rw -> ro */ > + if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & MS_RDONLY)) { > xfs_filestream_flush(mp); > xfs_sync(mp, SYNC_DATA_QUIESCE); > xfs_attr_quiesce(mp); > mp->m_flags |= XFS_MOUNT_RDONLY; > } > > - out_free_args: > - kfree(args); > - return -error; > + return 0; > } > > /* ---end quoted text--- From owner-xfs@oss.sgi.com Tue Jun 3 00:58:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 00:58:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m537wCmG028995 for ; Tue, 3 Jun 2008 00:58:14 -0700 X-ASG-Debug-ID: 1212479944-3793021c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F1A3E176C257 for ; Tue, 3 Jun 2008 00:59:04 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id I72cZVicCpxh43vY for ; Tue, 03 Jun 2008 00:59:04 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m537wuOc019720 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 09:58:56 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m537wu8M019718 for xfs@oss.sgi.com; Tue, 3 Jun 2008 09:58:56 +0200 Date: Tue, 3 Jun 2008 09:58:55 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] scale down 074 on lower end machines Subject: Re: [PATCH] scale down 074 on lower end machines Message-ID: <20080603075855.GA19608@lst.de> References: <20080515173913.GA11494@lst.de> <20080521081552.GB2398@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080521081552.GB2398@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212479946 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52221 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16229 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs ping^2 On Wed, May 21, 2008 at 10:15:52AM +0200, Christoph Hellwig wrote: > ping? > > On Thu, May 15, 2008 at 07:39:13PM +0200, Christoph Hellwig wrote: > > 074 takes ages to complete on my kvm test VM, but scaling it back to the > > level used on IRIX makes it complete in slightly under 10 minutes. > > > > I'm not sure if checking for UP vs SMP is the right way to go into slow > > mode, but I couldn't think of anything better. > > > > > > Signed-off-by: Christoph Hellwig > > > > Index: xfstests/074 > > =================================================================== > > RCS file: /cvs/xfs-cmds/xfstests/074,v > > retrieving revision 1.7 > > diff -u -p -r1.7 074 > > --- xfstests/074 9 Nov 2005 02:49:08 -0000 1.7 > > +++ xfstests/074 15 May 2008 17:37:03 -0000 > > @@ -120,10 +120,17 @@ if [ $HOSTOS == "IRIX" ]; then > > param_type="IRIX nondebug" > > fi > > elif [ $HOSTOS == "Linux" ]; then > > - numloops=10 > > - numfiles=5 > > - numchildren=3 > > - param_type="Linux" > > + if uname -a | grep -q SMP; then > > + numloops=10 > > + numfiles=5 > > + numchildren=3 > > + param_type="Linux SMP" > > + else > > + numloops=2 > > + numfiles=3 > > + numchildren=3 > > + param_type="Linux UP" > > + fi > > else > > numloops=1 > > numfiles=1 > ---end quoted text--- ---end quoted text--- From owner-xfs@oss.sgi.com Tue Jun 3 04:39:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 04:39:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53BdAnU016084 for ; Tue, 3 Jun 2008 04:39:11 -0700 X-ASG-Debug-ID: 1212493203-755101a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 692051DE2F8 for ; Tue, 3 Jun 2008 04:40:03 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id jTq5FFMzks6vWkAf for ; Tue, 03 Jun 2008 04:40:03 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m53BdtOc002844 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 13:39:55 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m53BdtEt002842 for xfs@oss.sgi.com; Tue, 3 Jun 2008 13:39:55 +0200 Date: Tue, 3 Jun 2008 13:39:55 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] factor out inode has attrs check Subject: [PATCH] factor out inode has attrs check Message-ID: <20080603113955.GA2703@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212493204 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52235 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16231 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Note that xfs_attr_fetch did the check twice while keeping the inode locked and we can just remove the superflous check. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:32:06.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 @@ -111,6 +111,17 @@ xfs_attr_name_to_xname( return 0; } +STATIC int +xfs_inode_hasattr( + struct xfs_inode *ip) +{ + if (!XFS_IFORK_Q(ip) || + (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && + ip->i_d.di_anextents == 0)) + return 0; + return 1; +} + /*======================================================================== * Overall external interface routines. *========================================================================*/ @@ -122,10 +133,8 @@ xfs_attr_fetch(xfs_inode_t *ip, struct x xfs_da_args_t args; int error; - if ((XFS_IFORK_Q(ip) == 0) || - (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - ip->i_d.di_anextents == 0)) - return(ENOATTR); + if (!xfs_inode_hasattr(ip)) + return ENOATTR; /* * Fill in the arg structure for this request. @@ -143,11 +152,7 @@ xfs_attr_fetch(xfs_inode_t *ip, struct x /* * Decide on what work routines to call based on the inode size. */ - if (XFS_IFORK_Q(ip) == 0 || - (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - ip->i_d.di_anextents == 0)) { - error = XFS_ERROR(ENOATTR); - } else if (ip->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { + if (ip->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { error = xfs_attr_shortform_getvalue(&args); } else if (xfs_bmap_one_block(ip, XFS_ATTR_FORK)) { error = xfs_attr_leaf_get(&args); @@ -523,9 +528,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, str /* * Decide on what work routines to call based on the inode size. */ - if (XFS_IFORK_Q(dp) == 0 || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp)) { error = XFS_ERROR(ENOATTR); goto out; } @@ -595,11 +598,9 @@ xfs_attr_remove( return error; xfs_ilock(dp, XFS_ILOCK_SHARED); - if (XFS_IFORK_Q(dp) == 0 || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp)) { xfs_iunlock(dp, XFS_ILOCK_SHARED); - return(XFS_ERROR(ENOATTR)); + return XFS_ERROR(ENOATTR); } xfs_iunlock(dp, XFS_ILOCK_SHARED); @@ -615,9 +616,7 @@ xfs_attr_list_int(xfs_attr_list_context_ /* * Decide on what work routines to call based on the inode size. */ - if (XFS_IFORK_Q(dp) == 0 || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp)) { error = 0; } else if (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { error = xfs_attr_shortform_list(context); @@ -810,12 +809,10 @@ xfs_attr_inactive(xfs_inode_t *dp) ASSERT(! XFS_NOT_DQATTACHED(mp, dp)); xfs_ilock(dp, XFS_ILOCK_SHARED); - if ((XFS_IFORK_Q(dp) == 0) || - (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp) || + dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { xfs_iunlock(dp, XFS_ILOCK_SHARED); - return(0); + return 0; } xfs_iunlock(dp, XFS_ILOCK_SHARED); @@ -848,10 +845,8 @@ xfs_attr_inactive(xfs_inode_t *dp) /* * Decide on what work routines to call based on the inode size. */ - if ((XFS_IFORK_Q(dp) == 0) || - (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp) || + dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { error = 0; goto out; } From owner-xfs@oss.sgi.com Tue Jun 3 04:48:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 04:48:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53Bm43T016939 for ; Tue, 3 Jun 2008 04:48:04 -0700 X-ASG-Debug-ID: 1212493736-608802d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB9901DE1C7 for ; Tue, 3 Jun 2008 04:48:56 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id C8bfQEZg1Qee0TMr for ; Tue, 03 Jun 2008 04:48:56 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m53BmmOc003407 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 13:48:48 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m53BmmbL003405 for xfs@oss.sgi.com; Tue, 3 Jun 2008 13:48:48 +0200 Date: Tue, 3 Jun 2008 13:48:48 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] dmapi: use ->put_listen callback directly Subject: [PATCH 2/2] dmapi: use ->put_listen callback directly Message-ID: <20080603114848.GC2703@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212493737 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_MJ615 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_MJ615 Custom Rule MJ615 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16233 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Rewrite xfs_dm_getall_dmattr to directly call xfs_list_attr_int in fill the userspace buffer directly from the listent. Doing the direct put means the need for the large kernel space buffer is gone, there is only one btree traversal needed and thus the list vs get race is fixed. By doing the proper put_user/copy_to_user the direct userspace memory derference is fixed, too and the code is a lot simpler and easier to understand. This patch passes xfsqa but I don't really trust it much vs dmapi, so please review carefully. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2008-06-01 14:45:20.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-06-03 12:00:22.000000000 +0200 @@ -2092,149 +2092,136 @@ xfs_dm_get_region( } +#define DM_GETALL_DMATTR_ALIGN (sizeof(int) - 1) + STATIC int -xfs_dm_getall_dmattr( - struct inode *inode, - dm_right_t right, - size_t buflen, - void __user *bufp, - size_t __user *rlenp) +xfs_dm_put_listent( + xfs_attr_list_context_t *context, + int flags, + char *name, + int namelen, + int valuelen, + char *value) { - attrlist_cursor_kern_t cursor; - attrlist_t *attrlist; - dm_attrlist_t __user *ulist; - int *last_link; - int alignment; - int total_size; - int list_size = 8192; /* should be big enough */ - int error; + dm_attrlist_t __user *ulist; + int size_needed; - /* Returns negative errors to DMAPI */ + ASSERT(context->count >= 0); - if (right < DM_RIGHT_SHARED) - return(-EACCES); + /* + * Skip over all non-DMAPI attributes. If the attribute name is too + * long, we assume it is non-DMAPI even if it starts with the correct + * prefix. + */ + if (!(flags & XFS_ATTR_ROOT)) + return 0; + if (namelen > DM_ATTR_NAME_SIZE) + return 0; + if (strncmp(name, dmattr_prefix, DMATTR_PREFIXLEN)) + return 0; - /* Verify that the user gave us a buffer that is 4-byte aligned, lock - it down, and work directly within that buffer. As a side-effect, - values of buflen < sizeof(int) return EINVAL. - */ + size_needed = sizeof(dm_attrlist_t) + valuelen; + size_needed = (size_needed + DM_GETALL_DMATTR_ALIGN) & + ~DM_GETALL_DMATTR_ALIGN; - alignment = sizeof(int) - 1; - if ((((__psint_t)bufp & alignment) != 0) || - !access_ok(VERIFY_WRITE, bufp, buflen)) { - return(-EFAULT); + /* + * We have a valid DMAPI attribute to return. If it won't fit in the + * user's buffer, we still need to keep track of the number of bytes + * for the user's next call. + */ + context->count += size_needed; + if (context->count > context->bufsize) { + context->seen_enough = 1; + return 1; + } + + ulist = (dm_attrlist_t __user __force *) + (context->alist + context->count); + + if (copy_to_user(ulist->al_name.an_chars, name, namelen) || + clear_user(ulist->al_name.an_chars + namelen, + DM_ATTR_NAME_SIZE - namelen) || + put_user(sizeof(dm_attrlist_t), &ulist->al_data.vd_offset) || + put_user(valuelen, &ulist->al_data.vd_length) || + put_user(size_needed, &ulist->_link) || + copy_to_user(ulist + 1, value, valuelen)) { + context->count = -1; + return 1; } - buflen &= ~alignment; /* round down the alignment */ - /* Initialize all the structures and variables for the main loop. */ + context->last_link = &ulist->_link; + return 0; +} - memset(&cursor, 0, sizeof(cursor)); - attrlist = (attrlist_t *)kmem_alloc(list_size, KM_SLEEP); - total_size = 0; - ulist = (dm_attrlist_t *)bufp; - last_link = NULL; - - /* Use vop_attr_list to get the names of DMAPI attributes, and use - vop_attr_get to get their values. There is a risk here that the - DMAPI attributes could change between the vop_attr_list and - vop_attr_get calls. If we can detect it, we return EIO to notify - the user. - */ +STATIC int +xfs_dm_getall_dmattr( + struct inode *inode, + dm_right_t right, + size_t buflen, + void __user *bufp, + size_t __user *rlenp) +{ + xfs_attr_list_context_t context; + attrlist_cursor_kern_t cursor = { 0, }; + int error; - do { - int i; + if (right < DM_RIGHT_SHARED) + return -EACCES; - /* Get a buffer full of attribute names. If there aren't any - more or if we encounter an error, then finish up. - */ + /* verify that the user gave us a buffer that is 4-byte aligned */ + if ((unsigned long)bufp & DM_GETALL_DMATTR_ALIGN) + return -EFAULT; - error = xfs_attr_list(XFS_I(inode), (char *)attrlist, list_size, - ATTR_ROOT, &cursor); - DM_EA_XLATE_ERR(error); + /* round down the alignment */ + buflen &= ~DM_GETALL_DMATTR_ALIGN; - if (error || attrlist->al_count == 0) - break; + memset(&context, 0, sizeof(context)); + context.dp = XFS_I(inode); + context.cursor = &cursor; + context.resynch = 1; + context.flags = ATTR_ROOT; + /* alist is just a cookie */ + context.alist = (char * __force)bufp; + context.bufsize = buflen; + context.put_value = 1; + context.put_listent = xfs_dm_put_listent; - for (i = 0; i < attrlist->al_count; i++) { - attrlist_ent_t *entry; - char *user_name; - int size_needed; - int value_len; - - /* Skip over all non-DMAPI attributes. If the - attribute name is too long, we assume it is - non-DMAPI even if it starts with the correct - prefix. - */ - - entry = ATTR_ENTRY(attrlist, i); - if (strncmp(entry->a_name, dmattr_prefix, DMATTR_PREFIXLEN)) - continue; - user_name = &entry->a_name[DMATTR_PREFIXLEN]; - if (strlen(user_name) > DM_ATTR_NAME_SIZE) - continue; - - /* We have a valid DMAPI attribute to return. If it - won't fit in the user's buffer, we still need to - keep track of the number of bytes for the user's - next call. - */ - - - size_needed = sizeof(*ulist) + entry->a_valuelen; - size_needed = (size_needed + alignment) & ~alignment; - - total_size += size_needed; - if (total_size > buflen) - continue; - - /* Start by filling in all the fields in the - dm_attrlist_t structure. - */ - - strncpy((char *)ulist->al_name.an_chars, user_name, - DM_ATTR_NAME_SIZE); - ulist->al_data.vd_offset = sizeof(*ulist); - ulist->al_data.vd_length = entry->a_valuelen; - ulist->_link = size_needed; - last_link = &ulist->_link; - - /* Next read the attribute's value into its correct - location after the dm_attrlist structure. Any sort - of error indicates that the data is moving under us, - so we return EIO to let the user know. - */ - - value_len = entry->a_valuelen; - - error = xfs_attr_get(XFS_I(inode), entry->a_name, - (void *)(ulist + 1), &value_len, - ATTR_ROOT); - DM_EA_XLATE_ERR(error); - - if (error || value_len != entry->a_valuelen) { - error = EIO; - break; - } + error = -xfs_attr_list_int(&context); + ASSERT(error <= 0); - ulist = (dm_attrlist_t *)((char *)ulist + ulist->_link); - } - } while (!error && attrlist->al_more); - if (last_link) - *last_link = 0; - - if (!error && total_size > buflen) - error = E2BIG; - if (!error || error == E2BIG) { - if (put_user(total_size, rlenp)) - error = EFAULT; + /* + * Count smaller zero means the iterator got an EFAULT. + * + * XXX(hch): we badly need a better way to deal with this, including + * passing and actual errno value back from the iterator. + */ + if (context.count < 0) + return -EFAULT; + + /* + * Terminate the list if we were successfull. + */ + if (context.last_link && put_user(0, context.last_link)) + return -EFAULT; + + if (!error) { + /* + * We still need to copy the count member to userspace in the + * case where there was not enough buffer space for the request. + * + * The ABI defines a count bigger as the passed in buffer length + * as indicator for requiring to call again with a bigger buffer. + */ + if (context.count > buflen) + error = -E2BIG; + + if (put_user(context.count, rlenp)) + error = -EFAULT; } - kmem_free(attrlist); - return(-error); /* Return negative error to DMAPI */ + return error; } - /* ARGSUSED */ STATIC int xfs_dm_getall_inherit( Index: linux-2.6-xfs/fs/xfs/xfs_attr.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-03 09:56:25.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-03 11:45:11.000000000 +0200 @@ -119,6 +119,7 @@ typedef struct xfs_attr_list_context { int put_value; /* T/F: need value for listent */ put_listent_func_t put_listent; /* list output fmt function */ int index; /* index into output buffer */ + int __user *last_link; /* list terminator */ } xfs_attr_list_context_t; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-03 12:01:08.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-03 12:01:13.000000000 +0200 @@ -262,7 +262,7 @@ EXPORT_SYMBOL(xfs_attr_get); EXPORT_SYMBOL(xfs_attr_set); EXPORT_SYMBOL(xfs_fsync); EXPORT_SYMBOL(xfs_attr_remove); -EXPORT_SYMBOL(xfs_attr_list); +EXPORT_SYMBOL(xfs_attr_list_int); EXPORT_SYMBOL(xfs_readdir); EXPORT_SYMBOL(xfs_setsize_buftarg); EXPORT_SYMBOL(xfs_syncsub); From owner-xfs@oss.sgi.com Tue Jun 3 04:47:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 04:47:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53BlteS016877 for ; Tue, 3 Jun 2008 04:47:55 -0700 X-ASG-Debug-ID: 1212493726-0a3801650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1887D1DE1C5 for ; Tue, 3 Jun 2008 04:48:46 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id m8SHHxb9PBy1TqFr for ; Tue, 03 Jun 2008 04:48:46 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m53BmcOc003392 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 13:48:38 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m53BmcoA003390 for xfs@oss.sgi.com; Tue, 3 Jun 2008 13:48:38 +0200 Date: Tue, 3 Jun 2008 13:48:38 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] simplify xfs_vn_listxattr Subject: [PATCH 1/2] simplify xfs_vn_listxattr Message-ID: <20080603114837.GB2703@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212493728 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16232 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs This patch switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. The changes to the lowleve attr code are: - the put_listent callback now gets the ondisk flags passed and performce the namespace lookup and check aswell as the check for the right attribute root itself - xfs_attr_list_int is made non-static for use by other callers than xfs_attr_list and now performs the inode locking and tracing itself The changes to the xfs_attr_list path are: - all checks for now uneeded ATTR_KERN flags are gone, and only the IRIX interface is supported for this code path - xfs_attr_put_listent is simplified by not needing to lookup the namespace but rather compare the integer flags directly. The changes to xfs_vn_listxattr are: - now directly calls xfs_attr_list_int with it's own put_listent callbacks - attr namespace prefix are now looked up by simple helpers, struct attrnames is gone. Other changes: - struct xfs_attr_list_context is moved from xfs_attr_leaf.h into xfs_attr.h. It's not realted to the leaf format at all and xfs_attr.h contains the interface to the attr code which it is part of now. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:44:07.000000000 +0200 @@ -16,8 +16,6 @@ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#include - #include "xfs.h" #include "xfs_fs.h" #include "xfs_types.h" @@ -607,12 +605,20 @@ xfs_attr_remove( return xfs_attr_remove_int(dp, &xname, flags); } -STATIC int +int xfs_attr_list_int(xfs_attr_list_context_t *context) { int error; xfs_inode_t *dp = context->dp; + XFS_STATS_INC(xs_attr_list); + + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) + return EIO; + + xfs_ilock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall start", context); + /* * Decide on what work routines to call based on the inode size. */ @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ } else { error = xfs_attr_node_list(context); } + + xfs_iunlock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall end", context); + return error; } @@ -634,6 +644,18 @@ xfs_attr_list_int(xfs_attr_list_context_ ((ATTR_ENTBASESIZE + (namelen) + 1 + sizeof(u_int32_t)-1) \ & ~(sizeof(u_int32_t)-1)) +STATIC int +xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) +{ + if (((arg_flags & ATTR_SECURE) == 0) != + ((ondisk_flags & XFS_ATTR_SECURE) == 0)) + return 0; + if (((arg_flags & ATTR_ROOT) == 0) != + ((ondisk_flags & XFS_ATTR_ROOT) == 0)) + return 0; + return 1; +} + /* * Format an attribute and copy it out to the user's buffer. * Take care to check values and protect against them changing later, @@ -641,74 +663,43 @@ xfs_attr_list_int(xfs_attr_list_context_ */ /*ARGSUSED*/ STATIC int -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, char *name, int namelen, int valuelen, char *value) { + struct attrlist *alist = (struct attrlist *)context->alist; attrlist_ent_t *aep; int arraytop; ASSERT(!(context->flags & ATTR_KERNOVAL)); ASSERT(context->count >= 0); ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); - ASSERT(context->firstu >= sizeof(*context->alist)); + ASSERT(context->firstu >= sizeof(*alist)); ASSERT(context->firstu <= context->bufsize); - arraytop = sizeof(*context->alist) + - context->count * sizeof(context->alist->al_offset[0]); + if (xfs_attr_namesp_match_overrides(context->flags, flags)) + return 0; + + arraytop = sizeof(*alist) + + context->count * sizeof(alist->al_offset[0]); context->firstu -= ATTR_ENTSIZE(namelen); if (context->firstu < arraytop) { xfs_attr_trace_l_c("buffer full", context); - context->alist->al_more = 1; + alist->al_more = 1; context->seen_enough = 1; return 1; } - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); + aep = (attrlist_ent_t *)&context->alist[context->firstu]; aep->a_valuelen = valuelen; memcpy(aep->a_name, name, namelen); - aep->a_name[ namelen ] = 0; - context->alist->al_offset[ context->count++ ] = context->firstu; - context->alist->al_count = context->count; + aep->a_name[namelen] = 0; + alist->al_offset[context->count++] = context->firstu; + alist->al_count = context->count; xfs_attr_trace_l_c("add", context); return 0; } -STATIC int -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - char *offset; - int arraytop; - - ASSERT(context->count >= 0); - - arraytop = context->count + namesp->attr_namelen + namelen + 1; - if (arraytop > context->firstu) { - context->count = -1; /* insufficient space */ - return 1; - } - offset = (char *)context->alist + context->count; - strncpy(offset, namesp->attr_name, namesp->attr_namelen); - offset += namesp->attr_namelen; - strncpy(offset, name, namelen); /* real name */ - offset += namelen; - *offset = '\0'; - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - -/*ARGSUSED*/ -STATIC int -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - /* * Generate a list of extended attribute names and optionally * also value lengths. Positive return value follows the XFS @@ -725,10 +716,9 @@ xfs_attr_list( attrlist_cursor_kern_t *cursor) { xfs_attr_list_context_t context; + struct attrlist *alist; int error; - XFS_STATS_INC(xs_attr_list); - /* * Validate the cursor. */ @@ -749,52 +739,21 @@ xfs_attr_list( /* * Initialize the output buffer. */ + memset(&context, 0, sizeof(context)); context.dp = dp; context.cursor = cursor; - context.count = 0; - context.dupcnt = 0; context.resynch = 1; context.flags = flags; - context.seen_enough = 0; - context.alist = (attrlist_t *)buffer; - context.put_value = 0; - - if (flags & ATTR_KERNAMELS) { - context.bufsize = bufsize; - context.firstu = context.bufsize; - if (flags & ATTR_KERNOVAL) - context.put_listent = xfs_attr_kern_list_sizes; - else - context.put_listent = xfs_attr_kern_list; - } else { - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ - context.firstu = context.bufsize; - context.alist->al_count = 0; - context.alist->al_more = 0; - context.alist->al_offset[0] = context.bufsize; - context.put_listent = xfs_attr_put_listent; - } - - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) - return EIO; + context.alist = buffer; + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ + context.firstu = context.bufsize; + context.put_listent = xfs_attr_put_listent; - xfs_ilock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall start", &context); + alist = (struct attrlist *)context.alist; + alist->al_offset[0] = context.bufsize; error = xfs_attr_list_int(&context); - - xfs_iunlock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall end", &context); - - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { - /* must return negated buffer size or the error */ - if (context.count < 0) - error = XFS_ERROR(ERANGE); - else - error = -context.count; - } else - ASSERT(error >= 0); - + ASSERT(error >= 0); return error; } @@ -2357,12 +2316,7 @@ xfs_attr_trace_enter(int type, char *whe (void *)((__psunsigned_t)context->bufsize), (void *)((__psunsigned_t)context->count), (void *)((__psunsigned_t)context->firstu), - (void *)((__psunsigned_t) - (((context->count > 0) && - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) - ? (ATTR_ENTRY(context->alist, - context->count-1)->a_valuelen) - : 0)), + NULL, (void *)((__psunsigned_t)context->dupcnt), (void *)((__psunsigned_t)context->flags), (void *)a13, (void *)a14, (void *)a15); Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:44:07.000000000 +0200 @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att * Namespace helper routines *========================================================================*/ -STATIC_INLINE attrnames_t * -xfs_attr_flags_namesp(int flags) -{ - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); -} - /* * If namespace bits don't match return 0. * If all match then return 1. @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); } -/* - * If namespace bits don't match and we don't have an override for it - * then return 0. - * If all match or are overridable then return 1. - */ -STATIC_INLINE int -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) -{ - if (((arg_flags & ATTR_SECURE) == 0) != - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && - !(arg_flags & ATTR_KERNORMALS)) - return 0; - if (((arg_flags & ATTR_ROOT) == 0) != - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && - !(arg_flags & ATTR_KERNROOTLS)) - return 0; - return 1; -} - /*======================================================================== * External routines when attribute fork size < XFS_LITINO(mp). @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co (XFS_ISRESET_CURSOR(cursor) && (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { - attrnames_t *namesp; - - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } - namesp = xfs_attr_flags_namesp(sfe->flags); error = context->put_listent(context, - namesp, + sfe->flags, (char *)sfe->nameval, (int)sfe->namelen, (int)sfe->valuelen, @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co kmem_free(sbuf); return XFS_ERROR(EFSCORRUPTED); } - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } + sbp->entno = i; sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); sbp->name = (char *)sfe->nameval; @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co * Loop putting entries into the user buffer. */ for ( ; i < nsbuf; i++, sbp++) { - attrnames_t *namesp; - - namesp = xfs_attr_flags_namesp(sbp->flags); - if (cursor->hashval != sbp->hash) { cursor->hashval = sbp->hash; cursor->offset = 0; } error = context->put_listent(context, - namesp, + sbp->flags, sbp->name, sbp->namelen, sbp->valuelen, @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, */ retval = 0; for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { - attrnames_t *namesp; - if (be32_to_cpu(entry->hashval) != cursor->hashval) { cursor->hashval = be32_to_cpu(entry->hashval); cursor->offset = 0; @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (entry->flags & XFS_ATTR_INCOMPLETE) continue; /* skip incomplete entries */ - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) - continue; - - namesp = xfs_attr_flags_namesp(entry->flags); if (entry->flags & XFS_ATTR_LOCAL) { xfs_attr_leaf_name_local_t *name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_loc->nameval, (int)name_loc->namelen, be16_to_cpu(name_loc->valuelen), @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (retval) return retval; retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, (char*)args.value); kmem_free(args.value); - } - else { + } else { retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:44:07.000000000 +0200 @@ -30,7 +30,6 @@ struct attrlist; struct attrlist_cursor_kern; -struct attrnames; struct xfs_dabuf; struct xfs_da_args; struct xfs_da_state; @@ -204,33 +203,6 @@ static inline int xfs_attr_leaf_entsize_ return (((bsize) >> 1) + ((bsize) >> 2)); } - -/*======================================================================== - * Structure used to pass context around among the routines. - *========================================================================*/ - - -struct xfs_attr_list_context; - -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, - char *, int, int, char *); - -typedef struct xfs_attr_list_context { - struct xfs_inode *dp; /* inode */ - struct attrlist_cursor_kern *cursor; /* position in list */ - struct attrlist *alist; /* output buffer */ - int seen_enough; /* T/F: seen enough of list? */ - int count; /* num used entries */ - int dupcnt; /* count dup hashvals seen */ - int bufsize; /* total buffer size */ - int firstu; /* first used byte in buffer */ - int flags; /* from VOP call */ - int resynch; /* T/F: resynch with cursor */ - int put_value; /* T/F: need value for listent */ - put_listent_func_t put_listent; /* list output fmt function */ - int index; /* index into output buffer */ -} xfs_attr_list_context_t; - /* * Used to keep a list of "remote value" extents when unlinking an inode. */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:44:07.000000000 +0200 @@ -17,7 +17,11 @@ */ #include "xfs.h" +#include "xfs_da_btree.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" #include "xfs_attr.h" +#include "xfs_attr_leaf.h" #include "xfs_acl.h" #include "xfs_vnodeops.h" @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, return __xfs_xattr_set(inode, name, value, size, flags, 0); } -struct attrnames attr_user = { - .attr_name = "user.", - .attr_namelen = sizeof("user.") - 1, -}; - static struct xattr_handler xfs_xattr_user_handler = { .prefix = XATTR_USER_PREFIX, .get = xfs_xattr_user_get, @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); } -struct attrnames attr_trusted = { - .attr_name = "trusted.", - .attr_namelen = sizeof("trusted.") - 1, -}; - static struct xattr_handler xfs_xattr_trusted_handler = { .prefix = XATTR_TRUSTED_PREFIX, .get = xfs_xattr_trusted_get, @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); } -struct attrnames attr_secure = { - .attr_name = "security.", - .attr_namelen = sizeof("security.") - 1, -}; - static struct xattr_handler xfs_xattr_security_handler = { .prefix = XATTR_SECURITY_PREFIX, .get = xfs_xattr_secure_get, @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers NULL }; +static unsigned int xfs_attr_prefix_len(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return sizeof("security"); + else if (flags & XFS_ATTR_ROOT) + return sizeof("trusted"); + else + return sizeof("user"); +} + +static const char *xfs_attr_prefix(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return xfs_xattr_security_handler.prefix; + else if (flags & XFS_ATTR_ROOT) + return xfs_xattr_trusted_handler.prefix; + else + return xfs_xattr_user_handler.prefix; +} + +static int +xfs_attr_kern_list(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + unsigned int prefix_len = xfs_attr_prefix_len(flags); + char *offset; + int arraytop; + + ASSERT(context->count >= 0); + + /* + * Only show root namespace entries if we are actually allowed to + * see them. + */ + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) + return 0; + + arraytop = context->count + prefix_len + namelen + 1; + if (arraytop > context->firstu) { + context->count = -1; /* insufficient space */ + return 1; + } + offset = (char *)context->alist + context->count; + strncpy(offset, xfs_attr_prefix(flags), prefix_len); + offset += prefix_len; + strncpy(offset, name, namelen); /* real name */ + offset += namelen; + *offset = '\0'; + context->count += prefix_len + namelen + 1; + return 0; +} + +static int +xfs_attr_kern_list_sizes(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + context->count += xfs_attr_prefix_len(flags) + namelen + 1; + return 0; +} + static int list_one_attr(const char *name, const size_t len, void *data, size_t size, ssize_t *result) @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si ssize_t xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) { + struct xfs_attr_list_context context; + struct attrlist_cursor_kern cursor = { 0 }; struct inode *inode = dentry->d_inode; - struct xfs_inode *ip = XFS_I(inode); - attrlist_cursor_kern_t cursor = { 0 }; - int error, xflags; - ssize_t result; - - xflags = ATTR_KERNAMELS; - if (!size) - xflags |= ATTR_KERNOVAL; - - if (capable(CAP_SYS_ADMIN)) - xflags |= ATTR_KERNFULLS; - else - xflags |= ATTR_KERNORMALS; - + int error; /* * First read the regular on-disk attributes. */ - result = -xfs_attr_list(ip, data, size, xflags, &cursor); - if (result < 0) - return result; + memset(&context, 0, sizeof(context)); + context.dp = XFS_I(inode); + context.cursor = &cursor; + context.resynch = 1; + context.alist = data; + context.bufsize = size; + context.firstu = context.bufsize; + + if (size) + context.put_listent = xfs_attr_kern_list; + else + context.put_listent = xfs_attr_kern_list_sizes; + + xfs_attr_list_int(&context); + if (context.count < 0) + return -ERANGE; /* * Then add the two synthetic ACL attributes. @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_access(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_default(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } - return result; + return context.count; } Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-01 14:44:07.000000000 +0200 @@ -341,8 +341,7 @@ xfs_acl_iaccess( /* If the file has no ACL return -1. */ rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, - ATTR_ROOT | ATTR_KERNACCESS)) { + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { _ACL_FREE(acl); return -1; } Index: linux-2.6-xfs/fs/xfs/xfs_attr.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-01 14:44:07.000000000 +0200 @@ -18,9 +18,11 @@ #ifndef __XFS_ATTR_H__ #define __XFS_ATTR_H__ +struct xfs_inode; +struct xfs_da_args; +struct xfs_attr_list_context; + /* - * xfs_attr.h - * * Large attribute lists are structured around Btrees where all the data * elements are in the leaf nodes. Attribute names are hashed into an int, * then that int is used as the index into the Btree. Since the hashval @@ -35,17 +37,6 @@ * External interfaces *========================================================================*/ -struct cred; -struct xfs_attr_list_context; - -typedef struct attrnames { - char * attr_name; - unsigned int attr_namelen; -} attrnames_t; - -extern struct attrnames attr_user; -extern struct attrnames attr_secure; -extern struct attrnames attr_trusted; #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ - -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) /* * The maximum size (into the kernel or returned from the kernel) of an @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { /*======================================================================== - * Function prototypes for the kernel. + * Structure used to pass context around among the routines. *========================================================================*/ -struct xfs_inode; -struct attrlist_cursor_kern; -struct xfs_da_args; + +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, + char *, int, int, char *); + +typedef struct xfs_attr_list_context { + struct xfs_inode *dp; /* inode */ + struct attrlist_cursor_kern *cursor; /* position in list */ + char *alist; /* output buffer */ + int seen_enough; /* T/F: seen enough of list? */ + int count; /* num used entries */ + int dupcnt; /* count dup hashvals seen */ + int bufsize; /* total buffer size */ + int firstu; /* first used byte in buffer */ + int flags; /* from VOP call */ + int resynch; /* T/F: resynch with cursor */ + int put_value; /* T/F: need value for listent */ + put_listent_func_t put_listent; /* list output fmt function */ + int index; /* index into output buffer */ +} xfs_attr_list_context_t; + + +/*======================================================================== + * Function prototypes for the kernel. + *========================================================================*/ /* * Overall external interface routines. */ int xfs_attr_inactive(struct xfs_inode *dp); - -int xfs_attr_shortform_getvalue(struct xfs_da_args *); int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); int xfs_attr_rmtval_get(struct xfs_da_args *args); +int xfs_attr_list_int(struct xfs_attr_list_context *); #endif /* __XFS_ATTR_H__ */ From owner-xfs@oss.sgi.com Tue Jun 3 05:50:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 05:50:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53Colxk020710 for ; Tue, 3 Jun 2008 05:50:48 -0700 X-ASG-Debug-ID: 1212497500-01b301fa0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A911B12BEE71 for ; Tue, 3 Jun 2008 05:51:41 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id cbQG5x0qlxxoDpWh for ; Tue, 03 Jun 2008 05:51:41 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id D5D68A9C521; Tue, 3 Jun 2008 07:51:39 -0500 (CDT) Message-ID: <48453E5D.8050301@sandeen.net> Date: Tue, 03 Jun 2008 07:51:41 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] fix mount option parsing in remount Subject: Re: [PATCH] fix mount option parsing in remount References: <20080518153539.GA5218@lst.de> In-Reply-To: <20080518153539.GA5218@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212497501 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52241 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16234 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Christoph Hellwig wrote: > Remount currently happily accept any option thrown at it, although the > only filesystem specific option it actually handles is barrier/nobarrier. > And it actually doesn't handle these correctly either because it only > uses the value it parsed when we're doing a ro->rw transition. In > addition to that there's also a bad bug in xfs_parseargs which doesn't > touch the actual option in the mount point except for a single one, > XFS_MOUNT_SMALL_INUMS and thus forced any filesystem that's every > remounted in some way to not support 64bit inodes with no way to recover > unless unmounted. > > This patch changes xfs_fs_remount to use it's own linux/parser.h based > options parse instead of xfs_parseargs and reject all options except > for barrier/nobarrier and to the right thing in general. Eventually > I'd like to have a single big option table used for mount aswell but > that can wait for a while. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2008-05-18 15:22:23.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-05-18 15:59:32.000000000 +0200 > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > static struct quotactl_ops xfs_quotactl_operations; > static struct super_operations xfs_super_operations; > @@ -1255,6 +1256,19 @@ xfs_fs_statfs( > return 0; > } > > +/* > + * Eventually we should extend this table and use it for mount, too. Maybe expand this a little: /* * Today only the barrier/nobarrier xfs mount options are handled * on remount. This table should be expanded to cover all options, * and used for the initial mount path, too. */ ... I'd also like this for the mount path because for example: mount -t xfs -o barrier=0 /dev/blah /mnt/foo works... but does not turn off barriers. So as a first step/example this looks ok but I'd sure like to see it extended soon. Maybe when I'm bored... :) -Eric > + */ > +enum { > + Opt_barrier, Opt_nobarrier, Opt_err > +}; > + > +static match_table_t tokens = { > + {Opt_barrier, "barrier"}, > + {Opt_nobarrier, "nobarrier"}, > + {Opt_err, NULL} > +}; > + > STATIC int > xfs_fs_remount( > struct super_block *sb, > @@ -1262,36 +1276,54 @@ xfs_fs_remount( > char *options) > { > struct xfs_mount *mp = XFS_M(sb); > - struct xfs_mount_args *args; > - int error; > + substring_t args[MAX_OPT_ARGS]; > + char *p; > > - args = xfs_args_allocate(sb, 0); > - if (!args) > - return -ENOMEM; > + while ((p = strsep(&options, ",")) != NULL) { > + int token; > > - error = xfs_parseargs(mp, options, args, 1); > - if (error) > - goto out_free_args; > + if (!*p) > + continue; > > - if (!(*flags & MS_RDONLY)) { /* rw/ro -> rw */ > - if (mp->m_flags & XFS_MOUNT_RDONLY) > - mp->m_flags &= ~XFS_MOUNT_RDONLY; > - if (args->flags & XFSMNT_BARRIER) { > + token = match_token(p, tokens, args); > + switch (token) { > + case Opt_barrier: > mp->m_flags |= XFS_MOUNT_BARRIER; > - xfs_mountfs_check_barriers(mp); > - } else { > + > + /* > + * Test if barriers are actually working if we can, > + * else delay this check until the filesystem is > + * marked writeable. > + */ > + if (!(mp->m_flags & XFS_MOUNT_RDONLY)) > + xfs_mountfs_check_barriers(mp); > + break; > + case Opt_nobarrier: > mp->m_flags &= ~XFS_MOUNT_BARRIER; > + break; > + default: > + printk(KERN_INFO > + "XFS: mount option \"%s\" not support for remount\n", p); > + return -EINVAL; > } > - } else if (!(mp->m_flags & XFS_MOUNT_RDONLY)) { /* rw -> ro */ > + } > + > + /* rw/ro -> rw */ > + if ((mp->m_flags & XFS_MOUNT_RDONLY) && !(*flags & MS_RDONLY)) { > + mp->m_flags &= ~XFS_MOUNT_RDONLY; > + if (mp->m_flags & XFS_MOUNT_BARRIER) > + xfs_mountfs_check_barriers(mp); > + } > + > + /* rw -> ro */ > + if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & MS_RDONLY)) { > xfs_filestream_flush(mp); > xfs_sync(mp, SYNC_DATA_QUIESCE); > xfs_attr_quiesce(mp); > mp->m_flags |= XFS_MOUNT_RDONLY; > } > > - out_free_args: > - kfree(args); > - return -error; > + return 0; > } > > /* > > From owner-xfs@oss.sgi.com Tue Jun 3 06:04:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 06:04:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53D4n2h021751 for ; Tue, 3 Jun 2008 06:04:49 -0700 X-ASG-Debug-ID: 1212498342-67d701560000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 85E571DDDAA for ; Tue, 3 Jun 2008 06:05:42 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id BffiYCscHIWAQevg for ; Tue, 03 Jun 2008 06:05:42 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m53D5YOc009055 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 Jun 2008 15:05:34 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m53D5Yd0009053; Tue, 3 Jun 2008 15:05:34 +0200 Date: Tue, 3 Jun 2008 15:05:34 +0200 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] fix mount option parsing in remount Subject: Re: [PATCH] fix mount option parsing in remount Message-ID: <20080603130534.GA8694@lst.de> References: <20080518153539.GA5218@lst.de> <48453E5D.8050301@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48453E5D.8050301@sandeen.net> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212498343 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52242 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16235 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Tue, Jun 03, 2008 at 07:51:41AM -0500, Eric Sandeen wrote: > Maybe expand this a little: > > /* > * Today only the barrier/nobarrier xfs mount options are handled > * on remount. This table should be expanded to cover all options, > * and used for the initial mount path, too. > */ > > ... I'd also like this for the mount path because for example: > > mount -t xfs -o barrier=0 /dev/blah /mnt/foo > > works... but does not turn off barriers. > > So as a first step/example this looks ok but I'd sure like to see it > extended soon. Maybe when I'm bored... :) Doh. But yeah, mount path should be switched over soon. I alredy posted the patches to kill the xfs_mount_args gunk which have been on the list for a while and happily ignored, and switching to the parser.h helper ontop of that is quite easy. I just want to wait a little bit so that any problems with the previous patch are shaked out before the new one gets added. From owner-xfs@oss.sgi.com Tue Jun 3 08:34:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 08:34:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53FYCkE001300 for ; Tue, 3 Jun 2008 08:34:14 -0700 X-ASG-Debug-ID: 1212507304-6b3900d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2AB9411AA347 for ; Tue, 3 Jun 2008 08:35:04 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.123]) by cuda.sgi.com with ESMTP id ybzLf1Lu54ChGxB5 for ; Tue, 03 Jun 2008 08:35:04 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta01.mail.rr.com with ESMTP id <20080603153503.JZVQ17285.hrndva-omta01.mail.rr.com@tomslinux.homelinux.org> for ; Tue, 3 Jun 2008 15:35:03 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m53FYoY0026675 for ; Tue, 3 Jun 2008 10:34:50 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m53FYmbW026674; Tue, 3 Jun 2008 10:34:48 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.226.57 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Tue, 3 Jun 2008 10:34:48 -0500 (CDT) Message-ID: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> Date: Tue, 3 Jun 2008 10:34:48 -0500 (CDT) X-ASG-Orig-Subj: Questions for article Subject: Questions for article To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.123] X-Barracuda-Start-Time: 1212507305 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0009 1.0000 -2.0153 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52251 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_SA074b URI: Custom Rule SA074b X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16236 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs I am writing an article to answer Henry Newman's at http://www.enterprisestorageforum.com/sans/features/article.php/3749926. I've already been bugging folks on the ext4 mailing list and one of them mentioned I should also send some of the same questions to this list. Please let me know if I may do so. Thanks! Tom King From owner-xfs@oss.sgi.com Tue Jun 3 10:35:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 10:35:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53HZYwY007445 for ; Tue, 3 Jun 2008 10:35:35 -0700 X-ASG-Debug-ID: 1212514587-0c6f02a10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CFFC31E0E82 for ; Tue, 3 Jun 2008 10:36:27 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.241]) by cuda.sgi.com with ESMTP id gjwYZNpeknfED3Wz for ; Tue, 03 Jun 2008 10:36:27 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so1341120rvb.32 for ; Tue, 03 Jun 2008 10:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VFmrDnzXs0qDxYTyPcIOhYjHhJmwsIxURReKYTq+stY=; b=YBiNzwA3uwaLBnyj03w57My+jz+SwX2zOlnq5TLQoUzazjErs0phDWk6wl16Q8Fi11jYa8sHMNGDIUcFqmZ0VcfQKxT/HgLS/aKwM8VA9912WG/8Xi2QuAVMn+nzFWMggjvO2Gd1UVfMEx7FCC5Ko/Vi1KFV2IGG0H0E4Q9ZmP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hj69/78IcJtFuzjQSAl9w+/sWDhg8C3OzIsTtyxamn1glWyK6vzuVCloYT/H/NboESp9b6yMwaA1BfxxOeKWSDHV2wV5HmmGenb3X93dR30OLdOcLy00NAObbgkVx6B7dwDVoU/gbQmQroNdwyPrYmQvbQrgPCrp8z0NZHE42Ts= Received: by 10.141.162.9 with SMTP id p9mr6007783rvo.68.1212514586946; Tue, 03 Jun 2008 10:36:26 -0700 (PDT) Received: by 10.141.43.7 with HTTP; Tue, 3 Jun 2008 10:36:26 -0700 (PDT) Message-ID: <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> Date: Tue, 3 Jun 2008 13:36:26 -0400 From: "Spam Magnet" To: "Stefan Smietanowski" X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed Cc: "Timothy Shimmin" , "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <48427DEE.40400@stesmi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <483F1AED.3010808@sandeen.net> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.241] X-Barracuda-Start-Time: 1212514587 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0071 1.0000 -1.9746 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.71 X-Barracuda-Spam-Status: No, SCORE=-1.71 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=PORN_URL_SEX X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52259 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.26 PORN_URL_SEX URI: URL uses words/phrases which indicate porn (sex) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16237 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs On Sun, Jun 1, 2008 at 6:46 AM, Stefan Smietanowski wrote: > One way is : od -t c jaz7.img | grep X | head > > Look for X F S B, may be split on two lines for you. > > This is what my disk looks like but of course, it's on a DOS > partition: > > 0077000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \0 ` \0 > I couldn't find any XFS by using the full dump of the disk: $ od -t c jaz7.img | grep X | head 0040000 353 > 220 ( j 0 X ] I H C \0 002 001 \0 0040240 003 303 H 367 363 001 F 374 021 N 376 Z X 273 \0 \a 0040560 023 Y Z X r \t @ u 001 B 003 ^ \v 342 314 303 1041040 5 0 E X E ! \0 K - H 1141360 031 \0 t \b P \r 362 \t . \0 265 P X \f 026 z 1141400 # 001 353 \n X 034 022 020 D 001 I 016 X 034 @ 023 (The healthy disk image also doesn't have any XFS but it has: 'S f x' (capital s)) 50.exe at offset 1041040 made me check the image file using a Windows utility called : UFS Explorer. (www.ufsexplorer.com) They claim that they can recover XFS partitions. To my surprise that software recognized the image as a FAT16 file system containing only one single file called "50.exe" I am more inclined to believe 'fdisk' rather than UFS Explorer: Most likely the original format that Iomega had shipped the Jaz disk with was a FAT16 and then somebody in our lab had decided to format it to xfs. I am beginning to feel that I will need to recover my data manually, one file at a time :( (It's really frustrating that I can see all my beautiful file names through hexdump but can't access them). So is there a preferred way of hard disk/partition recovery for XFS file system ? And if I end up doing that, where can I get more info about the underwork of xfs ? thank you all for your patience and help. From owner-xfs@oss.sgi.com Tue Jun 3 10:55:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 10:55:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53HtEGW008764 for ; Tue, 3 Jun 2008 10:55:15 -0700 X-ASG-Debug-ID: 1212515768-14dd00190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DDBF211AD100 for ; Tue, 3 Jun 2008 10:56:08 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.243]) by cuda.sgi.com with ESMTP id qjiQYInvLVS8vFyC for ; Tue, 03 Jun 2008 10:56:08 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so1350769rvb.32 for ; Tue, 03 Jun 2008 10:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5Ce0dd9ZVgxZmhgrQFPqWpz1dEcMcCkplkHdJUZMc1A=; b=X7efzWKbWIHY234ck+y3RDM0+qak/33HV1Djp0TAIC7jkzigZ9WGXqS910EaKJwdtIx+oJj8DXTTvRwZin6FCAFbqiSoh4awOqLBz1OxBS+KDJMFtNkajT1p8/swK3xjUMO1B/8MnNP5bxbWxrFH9SeEVm1XrcKqyCZZVc+OWgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Je+fPW/A8Ky9FL5rUC/IzSTmfEXGl6dv+dDAvj+ggKbMCd67YdAaY5hbyqv0R92IblhO7XMSM7W5pt33+G5TUwgz46ushi1m6FsKVhEDKKJrNQSPeSs+v4kC7OaSgg3X6cl0uAYWSjKWzy/Sm9J7jX1bWmNguxS1EgUpO/o4uRg= Received: by 10.141.141.3 with SMTP id t3mr6015542rvn.226.1212515768121; Tue, 03 Jun 2008 10:56:08 -0700 (PDT) Received: by 10.141.43.7 with HTTP; Tue, 3 Jun 2008 10:56:08 -0700 (PDT) Message-ID: <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> Date: Tue, 3 Jun 2008 13:56:08 -0400 From: "Spam Magnet" To: "Stefan Smietanowski" X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed Cc: "Timothy Shimmin" , "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.243] X-Barracuda-Start-Time: 1212515768 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52261 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16238 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs > (The healthy disk image also doesn't have any XFS but it has: 'S f x' > (capital s)) Correcting my mistake: The healthy image file does have the X F S B at 10000000 (octal) as fdisk had reported: Pt# Device Info Start End Sectors Id System 8: 2gb-ubuntu.img1 4096 3915599 3911504 a SGI xfs 4096*512=2097152 (10000000 octal): $ od -t c 2gb-ubuntu.img | grep 10000000 10000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \a u 350 I tried to see if I can find do the same thing for jaz7.img: Pt# Device Info Start End Sectors Id System 8: jaz7.img1 3072 2091007 2087936 a SGI xfs $ od -t c jaz7.img | grep 6000000 6000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 I guess all those zeros are not good signs. From owner-xfs@oss.sgi.com Tue Jun 3 11:43:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 11:43:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53IhQEa010702 for ; Tue, 3 Jun 2008 11:43:26 -0700 X-ASG-Debug-ID: 1212518658-304800e10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from atlantis.cc.ndsu.NoDak.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8D4F611AD440 for ; Tue, 3 Jun 2008 11:44:18 -0700 (PDT) Received: from atlantis.cc.ndsu.NoDak.edu (atlantis.cc.ndsu.NoDak.edu [134.129.99.37]) by cuda.sgi.com with ESMTP id lZDqv4SpsKrmBiqC for ; Tue, 03 Jun 2008 11:44:18 -0700 (PDT) Received: from atlantis.cc.ndsu.NoDak.edu (localhost.localdomain [127.0.0.1]) by atlantis.cc.ndsu.NoDak.edu (8.14.2/8.14.2) with ESMTP id m53IiIGe026717; Tue, 3 Jun 2008 13:44:18 -0500 Received: (from bmesich@localhost) by atlantis.cc.ndsu.NoDak.edu (8.14.2/8.14.1/Submit) id m53IiHft026716; Tue, 3 Jun 2008 13:44:17 -0500 Date: Tue, 3 Jun 2008 13:44:17 -0500 From: Bryan Mesich To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Message-ID: <20080603184417.GA23450@atlantis.cc.ndsu.NoDak.edu> Reply-To: Bryan Mesich Mail-Followup-To: Bryan Mesich , linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Fedora Release 8 User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: atlantis.cc.ndsu.NoDak.edu[134.129.99.37] X-Barracuda-Start-Time: 1212518659 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52265 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16239 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bryan.mesich@ndsu.edu Precedence: bulk X-list: xfs On Sun, Jun 01, 2008 at 05:45:39AM -0400, Justin Piszcz wrote: > I am testing some drives for someone and was curious to see how far one can > push the disks/backplane to their theoretical limit. This testing would indeed only suggest theoretical limits. In a production environment, I think a person would be hard pressed to reproduce these numbers. > Does/has anyone done this with server intel board/would greater speeds be > achievable? Nope, but your post inspired me to give it a try. My setup is as follows: Kernel: linux 2.6.25.3-18 (Fedora 9) Motherboard: Intel SE7520BD2-DDR2 SATA Controller: (2) 8 port 3Ware 9550SX Disks (12) 750GB Seagate ST3750640NS Disks sd[a-h] are plugged into the first 3Ware controller while sd[i-l] are plugged into the second controller. Both 3Ware cards are plugged onto PCIX 100 slots. The disks are being exported as "single disk" and write caching has been disabled. The OS is loaded on sd[a-d] (small 10GB partitions mirrored). For my first test, I ran dd on a single disk: dd if=/dev/sde of=/dev/null bs=1M dstat -D sde ----total-cpu-usage---- --dsk/sde-- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 7 53 40 0 0| 78M 0 | 526B 420B| 0 0 |1263 2559 0 8 53 38 0 0| 79M 0 | 574B 420B| 0 0 |1262 2529 0 7 54 39 0 0| 78M 0 | 390B 420B| 0 0 |1262 2576 0 7 54 39 0 0| 76M 0 | 284B 420B| 0 0 |1216 2450 0 8 54 38 0 0| 76M 0 | 376B 420B| 0 0 |1236 2489 0 9 54 36 0 0| 79M 0 | 397B 420B| 0 0 |1265 2537 0 9 54 37 0 0| 77M 0 | 344B 510B| 0 0 |1262 2872 0 8 54 38 0 0| 75M 0 | 637B 420B| 0 0 |1214 2992 0 8 53 38 0 0| 78M 0 | 422B 420B| 0 0 |1279 3179 And for a write: dd if=/dev/zero of=/dev/sde bs=1M dstat -D sde ----total-cpu-usage---- --dsk/sde-- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 7 2 90 0 0| 0 73M| 637B 420B| 0 0 | 614 166 0 7 0 93 0 0| 0 73M| 344B 420B| 0 0 | 586 105 0 7 0 93 0 0| 0 75M| 344B 420B| 0 0 | 629 177 0 7 0 93 0 0| 0 74M| 344B 420B| 0 0 | 600 103 0 7 0 93 0 0| 0 73M| 875B 420B| 0 0 | 612 219 0 8 0 92 0 0| 0 68M| 595B 420B| 0 0 | 546 374 0 8 5 86 0 0| 0 76M| 132B 420B| 0 0 | 632 453 0 9 0 91 0 0| 0 74M| 799B 420B| 0 0 | 596 421 0 8 0 92 0 0| 0 74M| 693B 420B| 0 0 | 624 436 For my next test, I ran dd on 8 disks (sd[e-l]). These are non-system disks (OS is installed on sd[a-d) and they are split between the 3Ware controllers. Here are my results: dd if=/dev/sd[e-l] of=/dev/null bs=1M dstat ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 91 0 0 1 8| 397M 0 | 811B 306B| 0 0 |6194 6654 0 91 0 0 1 7| 420M 0 | 158B 322B| 0 0 |6596 7097 1 91 0 0 1 8| 415M 0 | 324B 322B| 0 0 |6406 6839 1 91 0 0 1 8| 413M 0 | 316B 436B| 0 0 |6464 6941 0 90 0 0 2 8| 419M 0 | 66B 306B| 0 0 |6588 7121 1 91 0 0 2 7| 412M 0 | 461B 322B| 0 0 |6449 6916 0 91 0 0 1 7| 415M 0 | 665B 436B| 0 0 |6535 7044 0 92 0 0 1 7| 418M 0 | 299B 306B| 0 0 |6555 7028 0 90 0 0 1 8| 412M 0 | 192B 436B| 0 0 |6496 7014 And for write: dd if=/dev/zero of=/dev/sd[e-l] bs=1M dstat ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 86 0 0 1 12| 0 399M| 370B 306B| 0 0 |3520 855 0 87 0 0 1 12| 0 407M| 310B 322B| 0 0 |3506 813 1 87 0 0 1 12| 0 413M| 218B 322B| 0 0 |3568 827 0 87 0 0 0 12| 0 425M| 278B 322B| 0 0 |3641 785 0 87 0 0 1 12| 0 430M| 310B 322B| 0 0 |3658 845 0 86 0 0 1 14| 0 421M| 218B 322B| 0 0 |3605 756 1 85 0 0 1 14| 0 417M| 627B 322B| 0 0 |3579 984 0 84 0 0 1 14| 0 420M| 224B 436B| 0 0 |3548 1006 0 86 0 0 1 13| 0 433M| 310B 306B| 0 0 |3679 836 It seems that I'm running into a wall around 420-430M. Assuming the disks can push 75M, 8 disks should push 600M together. This is obviously not the case. According to Intel's Tech Specifications: http://download.intel.com/support/motherboards/server/se7520bd2/sb/se7520bd2_server_board_tps_r23.pdf I think the IO contention (in my case) is due to the PXH. All and all, when it comes down to moving IO in reality, these tests are pretty much useless in my opinion. Filesystem overhead and other operations limit the amount of IO that can be serviced by the PCI bus and/or the block devices (although it's interesting to see if the theoretical speeds are possible). For example, the box I used in the above example will be used as a fibre channel target server. Below is a performance print out of a running fibre target with the same hardware as tested above: mayacli> show performance controller=fc1 read/sec write/sec IOPS 16k 844k 141 52k 548k 62 1m 344k 64 52k 132k 26 0 208k 27 12k 396k 42 168k 356k 64 32k 76k 16 952k 248k 124 860k 264k 132 1m 544k 165 1m 280k 166 900k 344k 105 340k 284k 60 1m 280k 125 1m 340k 138 764k 592k 118 1m 448k 127 2m 356k 276 2m 480k 174 2m 8m 144 540k 376k 89 324k 380k 77 4k 348k 71 This particular fibre target is providing storage to 8 initiators, 4 of which are busy IMAP mail servers. Granted this isn't the busiest time of the year for us, but were not comming even close to the numbers mentioned in the above example. As always, corrections to my above bable are appreciated and welcomed :-) Bryan From owner-xfs@oss.sgi.com Tue Jun 3 11:58:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 11:58:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53IwttN011563 for ; Tue, 3 Jun 2008 11:58:57 -0700 X-ASG-Debug-ID: 1212519587-676a013e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from proxy1.bredband.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E51571E1DA8 for ; Tue, 3 Jun 2008 11:59:48 -0700 (PDT) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by cuda.sgi.com with ESMTP id LpIsorcByKRrT1xz for ; Tue, 03 Jun 2008 11:59:48 -0700 (PDT) Received: from ironport2.bredband.com (195.54.101.122) by proxy1.bredband.net (7.3.127) id 4811823A00C16855 for xfs@oss.sgi.com; Tue, 3 Jun 2008 20:59:47 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4+AF0xRUjVctjQPGdsb2JhbACBVYcOiRcBAQEBLQGfAA Received: from c-d0d872d5.06-15-73746f44.cust.bredbandsbolaget.se (HELO DeepSpaceNine.stesmi.com) ([213.114.216.208]) by ironport2.bredband.com with ESMTP; 03 Jun 2008 20:59:47 +0200 Received: from [127.0.0.1] (voyager.stesmi.com [192.168.1.11]) by DeepSpaceNine.stesmi.com (8.12.11/8.12.11) with ESMTP id m53IxiTV029635; Tue, 3 Jun 2008 20:59:46 +0200 Message-ID: <4845949F.7080209@stesmi.com> Date: Tue, 03 Jun 2008 20:59:43 +0200 From: Stefan Smietanowski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Spam Magnet CC: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> In-Reply-To: <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.7; VAE 6.29.0.5; VDF 6.29.0.100 X-Barracuda-Connect: proxy1.bredband.net[195.54.101.71] X-Barracuda-Start-Time: 1212519589 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52266 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16240 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Spam Magnet wrote: >> (The healthy disk image also doesn't have any XFS but it has: 'S f x' >> (capital s)) > > Correcting my mistake: > > The healthy image file does have the X F S B at 10000000 (octal) as > fdisk had reported: > Pt# Device Info Start End Sectors Id System > 8: 2gb-ubuntu.img1 4096 3915599 3911504 a SGI xfs > > 4096*512=2097152 (10000000 octal): > $ od -t c 2gb-ubuntu.img | grep 10000000 > 10000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \a u 350 > > I tried to see if I can find do the same thing for jaz7.img: > Pt# Device Info Start End Sectors Id System > 8: jaz7.img1 3072 2091007 2087936 a SGI xfs > > $ od -t c jaz7.img | grep 6000000 > 6000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > > I guess all those zeros are not good signs. Wait a moment. Aren't jaz sectors 2k each? Try at 3072*2048 instead. // Stefan From owner-xfs@oss.sgi.com Tue Jun 3 12:38:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 12:38:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53JcEOZ018185 for ; Tue, 3 Jun 2008 12:38:14 -0700 X-ASG-Debug-ID: 1212521947-5e8302a60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 27FEC1E36C5 for ; Tue, 3 Jun 2008 12:39:07 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.246]) by cuda.sgi.com with ESMTP id nPZSRfwSFEoHrC3M for ; Tue, 03 Jun 2008 12:39:07 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so1381117rvb.32 for ; Tue, 03 Jun 2008 12:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cLI6zuruZDJ1bZ0knTuyZuET80CIehI57K9n5NIxzJ8=; b=WeVtSBb4+QpHFurCgPkUAPK3UVa6b8r+urcZrpiXBYkHA/HhaVpJX+TaUPmvz27x4Ej5Elb/2apaQRhavBgv7bYOxTjlrSK3muDPKfHrediBcbOzlbJv783bkyHSVd4dIba0yCksgTtJjHf4dypsYz4X3aZiEwWzedrOW3lWVl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vIt96G7drocUocYPYGQwHp9ogUHLxVib04JsdauB32XQbnTefVvn6i2F2uGI+yh4w0wS0L+KsmdMeOcj7wdPfE5dIKOwPycZblM4ctkRY/rew58DzwKBEPkw6wxC7U9V73naaNY5839ldZeuqUJ0ifHe6SAwvNxRide5lwZpIm0= Received: by 10.140.125.1 with SMTP id x1mr6101052rvc.287.1212521947444; Tue, 03 Jun 2008 12:39:07 -0700 (PDT) Received: by 10.141.43.7 with HTTP; Tue, 3 Jun 2008 12:39:07 -0700 (PDT) Message-ID: <3607657a0806031239l6d788868u2f5654efcabf4abc@mail.gmail.com> Date: Tue, 3 Jun 2008 15:39:07 -0400 From: "Spam Magnet" To: "Stefan Smietanowski" X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed Cc: "Timothy Shimmin" , "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <4845949F.7080209@stesmi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> <4845949F.7080209@stesmi.com> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.246] X-Barracuda-Start-Time: 1212521948 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52267 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16241 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs On Tue, Jun 3, 2008 at 2:59 PM, Stefan Smietanowski wrote: > Spam Magnet wrote: >>> >>> (The healthy disk image also doesn't have any XFS but it has: 'S f x' >>> (capital s)) >> >> Correcting my mistake: >> >> The healthy image file does have the X F S B at 10000000 (octal) as >> fdisk had reported: >> Pt# Device Info Start End Sectors Id System >> 8: 2gb-ubuntu.img1 4096 3915599 3911504 a SGI xfs >> >> 4096*512=2097152 (10000000 octal): >> $ od -t c 2gb-ubuntu.img | grep 10000000 >> 10000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \a u 350 >> >> I tried to see if I can find do the same thing for jaz7.img: >> Pt# Device Info Start End Sectors Id System >> 8: jaz7.img1 3072 2091007 2087936 a SGI xfs >> >> $ od -t c jaz7.img | grep 6000000 >> 6000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 >> >> I guess all those zeros are not good signs. > > Wait a moment. Aren't jaz sectors 2k each? > > Try at 3072*2048 instead. > > // Stefan > I think they are but I used -u option of fdisk: $ fdisk -ul jaz7.img Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders Units = sectors of 1 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 8: jaz7.img1 3072 2091007 2087936 a SGI xfs 9: jaz7.img2 0 3071 3072 0 SGI volhdr 11: jaz7.img3 0 2091007 2091008 6 SGI volume which lists partitions in sector units. As oppose to: $ fdisk -l jaz7.img Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders Units = cylinders of 16065 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 8: jaz7.img1 1 130 2087936 a SGI xfs 9: jaz7.img2 0 0 3072 0 SGI volhdr 11: jaz7.img3 0 130 2091008 6 SGI volume From owner-xfs@oss.sgi.com Tue Jun 3 12:41:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 12:41:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53JfKn2018629 for ; Tue, 3 Jun 2008 12:41:21 -0700 X-ASG-Debug-ID: 1212522134-15b302560000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 788D913B8B21 for ; Tue, 3 Jun 2008 12:42:14 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id djthj7gceXvMrDdB for ; Tue, 03 Jun 2008 12:42:14 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id C77C81C000263; Tue, 3 Jun 2008 15:42:13 -0400 (EDT) Date: Tue, 3 Jun 2008 15:42:13 -0400 (EDT) From: Justin Piszcz To: Thomas King cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article In-Reply-To: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> Message-ID: References: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1212522134 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_SA074b URI: Custom Rule SA074b X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16242 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Tue, 3 Jun 2008, Thomas King wrote: > I am writing an article to answer Henry Newman's at > http://www.enterprisestorageforum.com/sans/features/article.php/3749926. I've > already been bugging folks on the ext4 mailing list and one of them mentioned I > should also send some of the same questions to this list. Please let me know if > I may do so. > > Thanks! > Tom King > > What are the questions? Justin. From owner-xfs@oss.sgi.com Tue Jun 3 13:23:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 13:23:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53KN4qM020961 for ; Tue, 3 Jun 2008 13:23:06 -0700 X-ASG-Debug-ID: 1212524637-0bf303db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from proxy1.bredband.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 839BE17760AC for ; Tue, 3 Jun 2008 13:23:58 -0700 (PDT) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by cuda.sgi.com with ESMTP id S01N5b4WNy7iErQ7 for ; Tue, 03 Jun 2008 13:23:58 -0700 (PDT) Received: from ironport.bredband.com (195.54.101.120) by proxy1.bredband.net (7.3.127) id 4811823A00C1C351 for xfs@oss.sgi.com; Tue, 3 Jun 2008 22:23:57 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4+AMdERUjVctjQPGdsb2JhbACBVYcOiRcBAQEBLQGeeA Received: from c-d0d872d5.06-15-73746f44.cust.bredbandsbolaget.se (HELO DeepSpaceNine.stesmi.com) ([213.114.216.208]) by ironport1.bredband.com with ESMTP; 03 Jun 2008 22:23:57 +0200 Received: from [127.0.0.1] (voyager.stesmi.com [192.168.1.11]) by DeepSpaceNine.stesmi.com (8.12.11/8.12.11) with ESMTP id m53KNqGO004083; Tue, 3 Jun 2008 22:23:56 +0200 Message-ID: <4845A857.3090905@stesmi.com> Date: Tue, 03 Jun 2008 22:23:51 +0200 From: Stefan Smietanowski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Spam Magnet CC: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> <4845949F.7080209@stesmi.com> <3607657a0806031239l6d788868u2f5654efcabf4abc@mail.gmail.com> In-Reply-To: <3607657a0806031239l6d788868u2f5654efcabf4abc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.7; VAE 6.29.0.5; VDF 6.29.0.100 X-Barracuda-Connect: proxy1.bredband.net[195.54.101.71] X-Barracuda-Start-Time: 1212524638 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52272 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16243 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Spam Magnet wrote: > On Tue, Jun 3, 2008 at 2:59 PM, Stefan Smietanowski wrote: >> Spam Magnet wrote: >>>> (The healthy disk image also doesn't have any XFS but it has: 'S f x' >>>> (capital s)) >>> Correcting my mistake: >>> >>> The healthy image file does have the X F S B at 10000000 (octal) as >>> fdisk had reported: >>> Pt# Device Info Start End Sectors Id System >>> 8: 2gb-ubuntu.img1 4096 3915599 3911504 a SGI xfs >>> >>> 4096*512=2097152 (10000000 octal): >>> $ od -t c 2gb-ubuntu.img | grep 10000000 >>> 10000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \a u 350 >>> >>> I tried to see if I can find do the same thing for jaz7.img: >>> Pt# Device Info Start End Sectors Id System >>> 8: jaz7.img1 3072 2091007 2087936 a SGI xfs >>> >>> $ od -t c jaz7.img | grep 6000000 >>> 6000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 >>> >>> I guess all those zeros are not good signs. >> Wait a moment. Aren't jaz sectors 2k each? >> >> Try at 3072*2048 instead. >> >> // Stefan >> > > I think they are but I used -u option of fdisk: > $ fdisk -ul jaz7.img > Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders > Units = sectors of 1 * 512 bytes > ----- partitions ----- > Pt# Device Info Start End Sectors Id System > 8: jaz7.img1 3072 2091007 2087936 a SGI xfs > 9: jaz7.img2 0 3071 3072 0 SGI volhdr > 11: jaz7.img3 0 2091007 2091008 6 SGI volume > > which lists partitions in sector units. As oppose to: > > $ fdisk -l jaz7.img > > Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders > Units = cylinders of 16065 * 512 bytes > > ----- partitions ----- > Pt# Device Info Start End Sectors Id System > 8: jaz7.img1 1 130 2087936 a SGI xfs > 9: jaz7.img2 0 0 3072 0 SGI volhdr > 11: jaz7.img3 0 130 2091008 6 SGI volume I'd give it a shot regardless as I don't remember if the sector size is actually IN the partition table and if it's NOT then it'll show the native blocksize of the device, which is 512bytes! Just try it, what do you have to lose? I mean do the od .. Worst case you get garbage or zeroes. // Stefan From owner-xfs@oss.sgi.com Tue Jun 3 13:34:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 13:34:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53KY4vv021652 for ; Tue, 3 Jun 2008 13:34:07 -0700 X-ASG-Debug-ID: 1212525298-1556037e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6512717764A4; Tue, 3 Jun 2008 13:34:58 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id RSTXw7UarIhTgKgy; Tue, 03 Jun 2008 13:34:58 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K3dDd-00042x-Qh; Tue, 03 Jun 2008 20:34:57 +0000 Date: Tue, 3 Jun 2008 16:34:57 -0400 From: Christoph Hellwig To: Barry Naujok , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: xfs_reno #2 Subject: Re: REVIEW: xfs_reno #2 Message-ID: <20080603203457.GA6018@infradead.org> References: <1204819835.4002.36.camel@tecra.thekeening.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1204819835.4002.36.camel@tecra.thekeening.homeunix.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212525298 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52272 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16244 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs What happened to xfs xfs_reno patch? While the swapino functionality would be nice to have I can't think of a reason to not have the current code in xfsprogs. From owner-xfs@oss.sgi.com Tue Jun 3 13:48:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 13:48:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53KmAJY022638 for ; Tue, 3 Jun 2008 13:48:11 -0700 X-ASG-Debug-ID: 1212526140-673903bf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FA781E3A69 for ; Tue, 3 Jun 2008 13:49:04 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by cuda.sgi.com with ESMTP id TGikzCV7qZVEFSWc for ; Tue, 03 Jun 2008 13:49:04 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta06.mail.rr.com with ESMTP id <20080603204900.FOKT9231.hrndva-omta06.mail.rr.com@tomslinux.homelinux.org> for ; Tue, 3 Jun 2008 20:49:00 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m53Kmnem029499 for ; Tue, 3 Jun 2008 15:48:50 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m53Kmn1m029498; Tue, 3 Jun 2008 15:48:49 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.226.57 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Tue, 3 Jun 2008 15:48:49 -0500 (CDT) Message-ID: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> Date: Tue, 3 Jun 2008 15:48:49 -0500 (CDT) X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.124] X-Barracuda-Start-Time: 1212526144 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b, BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52274 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_SA074b URI: Custom Rule SA074b 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16245 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs > > > On Tue, 3 Jun 2008, Thomas King wrote: > >> I am writing an article to answer Henry Newman's at >> http://www.enterprisestorageforum.com/sans/features/article.php/3749926. I've >> already been bugging folks on the ext4 mailing list and one of them mentioned >> I >> should also send some of the same questions to this list. Please let me know >> if >> I may do so. >> >> Thanks! >> Tom King >> >> > > What are the questions? > > Justin. For the most part, XFS is used for massive filesystems (hundreds of petabytes) successfully in Linux (among other OS's). However, Mr. Newman still believes there are details that he believes XFS doesn't include or Linux limits (such as page sizes in x86 limiting block sizes). With that preface, here are some questions: -Is XFS fully RAID aware inthat it aligns metadata with RAID stripes? Some of the information I see states XFS can get geometry information from LVM and MD, but what about hardware RAID? -Does XFS take advantage of T10 DIF (block protection?)? -Does/Will XFS support NFS v4.1? -Concerning the block-size limit, will this eventually be a thing of the past? Mr. Newman's contention is massive filesystems should have much larger block sizes, but he also contends that OSD is the eventual answer instead of using block allocation. -Is there anything else y'all would like folks to understand about XFS and massive implementations? Thanks! Tom King From owner-xfs@oss.sgi.com Tue Jun 3 15:03:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 15:03:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53M3Baj026254 for ; Tue, 3 Jun 2008 15:03:11 -0700 X-ASG-Debug-ID: 1212530644-69f402980000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rgminet01.oracle.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 425901776F3D for ; Tue, 3 Jun 2008 15:04:04 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by cuda.sgi.com with ESMTP id aF0HUKrDMgHcRnZx for ; Tue, 03 Jun 2008 15:04:04 -0700 (PDT) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m53M43AQ013963; Tue, 3 Jun 2008 16:04:03 -0600 Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m53GAtpL024439; Tue, 3 Jun 2008 16:04:01 -0600 Received: from groovelator.mkp.net by acsmt359.oracle.com with ESMTP id 10021603691212530445; Tue, 03 Jun 2008 17:00:45 -0500 To: Thomas King Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article From: "Martin K. Petersen" Organization: Oracle References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> Date: Tue, 03 Jun 2008 18:00:42 -0400 In-Reply-To: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> (Thomas King's message of "Tue\, 3 Jun 2008 15\:48\:49 -0500 \(CDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Barracuda-Connect: rgminet01.oracle.com[148.87.113.118] X-Barracuda-Start-Time: 1212530645 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52278 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16246 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: martin.petersen@oracle.com Precedence: bulk X-list: xfs >>>>> "Thomas" == Thomas King writes: Thomas> -Is XFS fully RAID aware inthat it aligns metadata with RAID Thomas> stripes? Some of the information I see states XFS can get Thomas> geometry information from LVM and MD, but what about hardware Thomas> RAID? The stuff that queries MD/LVM for stripe unit/stripe size has been in XFS for a while[1]. For hardware RAID there is no non-proprietary way to obtain the information from the device. So whoever runs mkfs on a hardware RAID device must manually specify the geometry using the sunit and swidth parameters. That capability has been there since the dawn of time. Note that in the upcoming version of SBC-3 (SCSI Block Commands) finally features a VPD page that the array firmware can fill out to let the operating system know about stripe size, etc. I have been working on a patch that extracts this information and presents it to the block layer in a generic fashion. But so far I have not seen a single array that implements said VPD page. IOW, there hasn't been much motivation to finish that work. Also, SBC-3 is work in progress. The standard has not been ratified yet so things could change before it is released. I doubt they are going to change the block limits VPD, but who knows? Thomas> -Does XFS take advantage of T10 DIF (block protection?)? As I mentioned earlier today, filesystems do not need to be explicitly DIF-aware. I/Os submitted by XFS will be protected if the kernel does DIF. The DIF support has not been accepted upstream yet. Working on that. But in any case DIF-capable hardware is not generally available. [1] http://www.linux.sgi.com/archives/xfs/2001-03/msg00435.html -- Martin K. Petersen Oracle Linux Engineering From owner-xfs@oss.sgi.com Tue Jun 3 15:13:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 15:13:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53MDqE2026923 for ; Tue, 3 Jun 2008 15:13:52 -0700 X-ASG-Debug-ID: 1212531283-27be01350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 812921E45B5 for ; Tue, 3 Jun 2008 15:14:43 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id vFcgoE8gmW1xGNDq for ; Tue, 03 Jun 2008 15:14:43 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id CF79498FF72; Tue, 3 Jun 2008 17:14:42 -0500 (CDT) Message-ID: <4845C254.6050104@sandeen.net> Date: Tue, 03 Jun 2008 17:14:44 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas King CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> In-Reply-To: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212531285 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52278 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16247 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Thomas King wrote: > -Concerning the block-size limit, will this eventually be a thing of the past? > Mr. Newman's contention is massive filesystems should have much larger block > sizes, but he also contends that OSD is the eventual answer instead of using > block allocation. Just to reiterate what I already put on the ext4 list... :) ftp://ftp.kernel.org/pub/linux/kernel/people/christoph/largeblocksize/4/patches/ http://kerneltrap.org/Linux/Large_Blocksize_Performance Not sure where those patches are headed. It's also not clear to me that this is really a critical feature for large filesystems; space allocation is not done block by block per se in xfs, as Mr. Newman seems (?) to imply (?) The block granularity is there throughout the fs but I'm not sure how much it matters in practice. Dave...? OSDs may have their place, we'll see. It's pretty new stuff (unless you count Lustre, I guess, but I thought he didn't want to talk lustre...) I don't think this relates to a linux shortcoming in any way (or to xfs...), it's awfully new stuff that just about nobody really has in production. > -Is there anything else y'all would like folks to understand about XFS and > massive implementations? I already pointed him at the xfs_repair paper, since he seems concerned about fsck (and pointed out that yes, xfs_repair really *DOES* check all filesystem data and does not simply replay the log...) http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf Maybe some of the folks on the list with said massive implementations can speak up too. :) -Eric From owner-xfs@oss.sgi.com Tue Jun 3 15:18:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 15:18:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53MId3r027572 for ; Tue, 3 Jun 2008 15:18:40 -0700 X-ASG-Debug-ID: 1212531564-100c015b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CA4C01776CE2 for ; Tue, 3 Jun 2008 15:19:24 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by cuda.sgi.com with ESMTP id PADvXBcUObZYw7eC for ; Tue, 03 Jun 2008 15:19:24 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta06.mail.rr.com with ESMTP id <20080603221924.IMPN9231.hrndva-omta06.mail.rr.com@tomslinux.homelinux.org>; Tue, 3 Jun 2008 22:19:24 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m53MJE1k030286; Tue, 3 Jun 2008 17:19:14 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m53MJDd3030285; Tue, 3 Jun 2008 17:19:13 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.255.56 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Tue, 3 Jun 2008 17:19:13 -0500 (CDT) Message-ID: <59654.143.166.255.56.1212531553.squirrel@tomslinux.homelinux.org> In-Reply-To: <4845C254.6050104@sandeen.net> References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> <4845C254.6050104@sandeen.net> Date: Tue, 3 Jun 2008 17:19:13 -0500 (CDT) X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article To: "Eric Sandeen" Cc: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.124] X-Barracuda-Start-Time: 1212531564 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0176 1.0000 -1.9067 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.91 X-Barracuda-Spam-Status: No, SCORE=-1.91 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52280 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16248 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs > Thomas King wrote: > >> -Concerning the block-size limit, will this eventually be a thing of the past? >> Mr. Newman's contention is massive filesystems should have much larger block >> sizes, but he also contends that OSD is the eventual answer instead of using >> block allocation. > > Just to reiterate what I already put on the ext4 list... :) > > ftp://ftp.kernel.org/pub/linux/kernel/people/christoph/largeblocksize/4/patches/ > http://kerneltrap.org/Linux/Large_Blocksize_Performance > > Not sure where those patches are headed. > > It's also not clear to me that this is really a critical feature for > large filesystems; space allocation is not done block by block per se in > xfs, as Mr. Newman seems (?) to imply (?) The block granularity is > there throughout the fs but I'm not sure how much it matters in > practice. Dave...? > > OSDs may have their place, we'll see. It's pretty new stuff (unless you > count Lustre, I guess, but I thought he didn't want to talk lustre...) > I don't think this relates to a linux shortcoming in any way (or to > xfs...), it's awfully new stuff that just about nobody really has in > production. > >> -Is there anything else y'all would like folks to understand about XFS and >> massive implementations? > > I already pointed him at the xfs_repair paper, since he seems concerned > about fsck (and pointed out that yes, xfs_repair really *DOES* check all > filesystem data and does not simply replay the log...) > > http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf > > Maybe some of the folks on the list with said massive implementations > can speak up too. :) > > -Eric > Both you and Andreas gave me some excellent information on both lists, and thank you all for your patience. I appreciate everyone piping in. Like you say, if there is anyone with massive implementations that wishes to add, please do so. Thanks! Tom King From owner-xfs@oss.sgi.com Tue Jun 3 17:32:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 17:32:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m540WPtF005785 for ; Tue, 3 Jun 2008 17:32:25 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8220A3040C7; Tue, 3 Jun 2008 17:33:16 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m540XCjm1722453; Wed, 4 Jun 2008 10:33:13 +1000 (AEST) From: Niv Sardi To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] scale down 074 on lower end machines References: <20080515173913.GA11494@lst.de> Date: Wed, 04 Jun 2008 10:33:17 +1000 In-Reply-To: <20080515173913.GA11494@lst.de> (Christoph Hellwig's message of "Thu, 15 May 2008 19:39:13 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16249 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig writes: > 074 takes ages to complete on my kvm test VM, but scaling it back to the > level used on IRIX makes it complete in slightly under 10 minutes. > > I'm not sure if checking for UP vs SMP is the right way to go into slow > mode, but I couldn't think of anything better. Looks good enough for now. -- Niv Sardi From owner-xfs@oss.sgi.com Tue Jun 3 17:56:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 17:56:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m540uLSY006936 for ; Tue, 3 Jun 2008 17:56:21 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8021A3040C8; Tue, 3 Jun 2008 17:57:13 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m540v8jm1723566; Wed, 4 Jun 2008 10:57:09 +1000 (AEST) From: Niv Sardi To: Gary Lowell Cc: markgw@sgi.com, xfs@oss.sgi.com Subject: Re: DMAPI JFS bug fixes References: <483C78E2.4090000@sonic.net> <483C8227.6090408@sgi.com> <4FC34C16-F0FA-49C5-88CC-83EEF616C218@sonic.net> Date: Wed, 04 Jun 2008 10:57:13 +1000 In-Reply-To: <4FC34C16-F0FA-49C5-88CC-83EEF616C218@sonic.net> (Gary Lowell's message of "Thu, 29 May 2008 19:16:01 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16250 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Gary Lowell writes: > On May 27, 2008, at 2:50 PM, Mark Goodwin wrote: >> Gary Lowell wrote: >>> Hi - >>> The JFS version of DMAPI had a handful of bug fixes that don't seem >>> to be in the current tree. I couldn't find anything in the list >>> archive about them. Would there be any interest in applying those >>> fixes or is DMAPI pretty much dead ? >> >> no it's not dead :) >> >>> If there is interest, I've got a patch. >> >> yes please post it here, with due reference to the original author(s). >> >> Thanks > > Great. I'll double check that they still work with TOT and post them. And i thought JFS was dead =) any patch would do, I've been looking around and couldn't really find a repository of the JFS/DMAPI changes. did you find anything like that ? Cheers, -- Niv Sardi From owner-xfs@oss.sgi.com Tue Jun 3 17:59:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 17:59:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SUBJ_ALL_CAPS autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m540x6v1007375 for ; Tue, 3 Jun 2008 17:59:07 -0700 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 KAA15319; Wed, 4 Jun 2008 10:59:54 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16403) id 0D43558C4C3F; Wed, 4 Jun 2008 10:59:53 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 907752 - Message-Id: <20080604005954.0D43558C4C3F@chook.melbourne.sgi.com> Date: Wed, 4 Jun 2008 10:59:53 +1000 (EST) From: xaiki@sgi.com (Niv Sardi-Altivanik) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16251 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs 074 takes ages to complete on my kvm test VM, but scaling it back to the level used on IRIX makes it complete in slightly under 10 minutes. I'm not sure if checking for UP vs SMP is the right way to go into slow mode, but I couldn't think of anything better. Signed-off-by: Christoph Hellwig Date: Wed Jun 4 10:59:31 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/xaiki/isms/xfs-cmds Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31272a xfstests/074 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/074.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h From owner-xfs@oss.sgi.com Tue Jun 3 19:38:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 19:38:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m542cTCB012203 for ; Tue, 3 Jun 2008 19:38:29 -0700 X-ASG-Debug-ID: 1212547162-148501190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 08ED21777FA0 for ; Tue, 3 Jun 2008 19:39:22 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id mcRUuB5PNLdglfde for ; Tue, 03 Jun 2008 19:39:22 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id CA657A9C51C; Tue, 3 Jun 2008 21:39:21 -0500 (CDT) Message-ID: <4846005B.6090907@sandeen.net> Date: Tue, 03 Jun 2008 21:39:23 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Niv Sardi CC: Gary Lowell , markgw@sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: DMAPI JFS bug fixes Subject: Re: DMAPI JFS bug fixes References: <483C78E2.4090000@sonic.net> <483C8227.6090408@sgi.com> <4FC34C16-F0FA-49C5-88CC-83EEF616C218@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212547163 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52296 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16252 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Niv Sardi wrote: > Gary Lowell writes: >> On May 27, 2008, at 2:50 PM, Mark Goodwin wrote: >>> Gary Lowell wrote: >>>> Hi - >>>> The JFS version of DMAPI had a handful of bug fixes that don't seem >>>> to be in the current tree. I couldn't find anything in the list >>>> archive about them. Would there be any interest in applying those >>>> fixes or is DMAPI pretty much dead ? >>> no it's not dead :) >>> >>>> If there is interest, I've got a patch. >>> yes please post it here, with due reference to the original author(s). >>> >>> Thanks >> Great. I'll double check that they still work with TOT and post them. > > And i thought JFS was dead =) > > any patch would do, I've been looking around and couldn't really find a > repository of the JFS/DMAPI changes. did you find anything like that ? didja google for "jfs dmapi? ;) http://jfs.sourceforge.net/project/pub/dmapi/ sorting out fixes from that looks like fun though. -Eric From owner-xfs@oss.sgi.com Tue Jun 3 22:28:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 22:28:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m545S8nO027912 for ; Tue, 3 Jun 2008 22:28:10 -0700 X-ASG-Debug-ID: 1212557341-383303720000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4AE181E58F5 for ; Tue, 3 Jun 2008 22:29:01 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id K2ESYV9IJsD7wagW for ; Tue, 03 Jun 2008 22:29:01 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K3lYR-0001hs-5X; Wed, 04 Jun 2008 05:28:59 +0000 Date: Wed, 4 Jun 2008 01:28:59 -0400 From: Christoph Hellwig To: Eric Sandeen Cc: Thomas King , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article Message-ID: <20080604052859.GA6509@infradead.org> References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> <4845C254.6050104@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4845C254.6050104@sandeen.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212557342 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52308 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16253 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 03, 2008 at 05:14:44PM -0500, Eric Sandeen wrote: > It's also not clear to me that this is really a critical feature for > large filesystems; space allocation is not done block by block per se in > xfs, as Mr. Newman seems (?) to imply (?) The block granularity is > there throughout the fs but I'm not sure how much it matters in > practice. Dave...? For streaming I/O workloads it doesn't matter anymore, see Dave's 2006 OLS talk. The direct to bio I/O path mitigates any blocksize impact. From owner-xfs@oss.sgi.com Tue Jun 3 22:31:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 22:31:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m545V3sa028337 for ; Tue, 3 Jun 2008 22:31:03 -0700 X-ASG-Debug-ID: 1212557516-157c03e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9EF8417784AA for ; Tue, 3 Jun 2008 22:31:57 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id L5IiSXBDGB1O5ee8 for ; Tue, 03 Jun 2008 22:31:57 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K3lbI-00028l-Ti; Wed, 04 Jun 2008 05:31:56 +0000 Date: Wed, 4 Jun 2008 01:31:56 -0400 From: Christoph Hellwig To: Thomas King Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article Message-ID: <20080604053156.GB6509@infradead.org> References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212557517 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52308 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16254 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 03, 2008 at 03:48:49PM -0500, Thomas King wrote: > For the most part, XFS is used for massive filesystems (hundreds of petabytes) I think undreds of petabytes is not something we commonly see today :) hundreds of TB is more reasonable. > -Does/Will XFS support NFS v4.1? I suspect he means support for PNFS. PNFS is just like CXFS over sunrpc, so for anyone whoe cares adding an XFS layout driver shouldn't be a problem, and not actually require changes to the disk format or low-level XFS code. Note that I think pnfs a really good idea. From owner-xfs@oss.sgi.com Tue Jun 3 23:10:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 23:10:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m546AOYV030334 for ; Tue, 3 Jun 2008 23:10:24 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 5FAF4908A3; Tue, 3 Jun 2008 23:11:12 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m546B5jm1728280; Wed, 4 Jun 2008 16:11:05 +1000 (AEST) From: Niv Sardi To: Eric Sandeen Cc: Gary Lowell , markgw@sgi.com, xfs@oss.sgi.com Subject: Re: DMAPI JFS bug fixes References: <483C78E2.4090000@sonic.net> <483C8227.6090408@sgi.com> <4FC34C16-F0FA-49C5-88CC-83EEF616C218@sonic.net> <4846005B.6090907@sandeen.net> Date: Wed, 04 Jun 2008 16:11:09 +1000 In-Reply-To: <4846005B.6090907@sandeen.net> (Eric Sandeen's message of "Tue, 03 Jun 2008 21:39:23 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16255 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Eric Sandeen writes: > Niv Sardi wrote: >> Gary Lowell writes: >>> On May 27, 2008, at 2:50 PM, Mark Goodwin wrote: >>>> Gary Lowell wrote: >>>>> Hi - >>>>> The JFS version of DMAPI had a handful of bug fixes that don't seem >>>>> to be in the current tree. I couldn't find anything in the list >>>>> archive about them. Would there be any interest in applying those >>>>> fixes or is DMAPI pretty much dead ? >>>> no it's not dead :) >>>> >>>>> If there is interest, I've got a patch. >>>> yes please post it here, with due reference to the original author(s). >>>> >>>> Thanks >>> Great. I'll double check that they still work with TOT and post them. >> >> And i thought JFS was dead =) >> >> any patch would do, I've been looking around and couldn't really find a >> repository of the JFS/DMAPI changes. did you find anything like that ? ^^^^^^^^^^ > didja google for "jfs dmapi? ;) > > http://jfs.sourceforge.net/project/pub/dmapi/ > > sorting out fixes from that looks like fun though. That's exactly why the key word here was repository, I really didn't think I'd bother to even look at a website that still had frames in 2008 =) Cheers, -- Niv Sardi From owner-xfs@oss.sgi.com Wed Jun 4 02:08:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 02:08:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5498iAg015204 for ; Wed, 4 Jun 2008 02:08:46 -0700 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 TAA24601; Wed, 4 Jun 2008 19:09:34 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 8A91458C4C3F; Wed, 4 Jun 2008 19:09:34 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE - mkfs/xfs_growfs with ASCII CI support with incorrect output Message-Id: <20080604090934.8A91458C4C3F@chook.melbourne.sgi.com> Date: Wed, 4 Jun 2008 19:09:34 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16256 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Fix up incorrect mkfs/growfs output for ascii-ci mode Date: Wed Jun 4 19:08:53 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: donaldd@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31275a xfsprogs/mkfs/xfs_mkfs.c - 1.91 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.91&r2=text&tr2=1.90&f=h - Fix up incorrect mkfs output for ascii-ci mode and update usage xfsprogs/growfs/xfs_growfs.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/xfs_growfs.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h - Fix up incorrect growfs output for ascii-ci mode From owner-xfs@oss.sgi.com Wed Jun 4 06:54:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 06:54:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54DsDid004839 for ; Wed, 4 Jun 2008 06:54:14 -0700 X-ASG-Debug-ID: 1212587705-357203760000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from villon.fh-worms.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC048177ADC0 for ; Wed, 4 Jun 2008 06:55:06 -0700 (PDT) Received: from villon.fh-worms.de (ns.fh-worms.de [143.93.160.9]) by cuda.sgi.com with ESMTP id TEGd3kn6aeXW3Cvo for ; Wed, 04 Jun 2008 06:55:06 -0700 (PDT) Received: from sapserv.fh-worms.de (sapserv.fh-worms.de [143.93.160.2]) by villon.fh-worms.de (8.14.3/8.14.2) with ESMTP id m54Dt4aX009820 for ; Wed, 4 Jun 2008 15:55:04 +0200 (CEST) Received: from 84.169.34.1 (SquirrelMail authenticated user inf769) by webmailer.fh-worms.de with HTTP; Wed, 4 Jun 2008 15:55:04 +0200 (CEST) Message-ID: <8efbf9761cbff87b03e5326866cd914d.squirrel@webmailer.fh-worms.de> Date: Wed, 4 Jun 2008 15:55:04 +0200 (CEST) X-ASG-Orig-Subj: vfs dmapi handle generation problem Subject: vfs dmapi handle generation problem From: Tim =?iso-8859-1?Q?J=F6dicke?= To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (villon.fh-worms.de [0.0.0.0]); Wed, 04 Jun 2008 15:55:05 +0200 (CEST) X-Barracuda-Connect: ns.fh-worms.de[143.93.160.9] X-Barracuda-Start-Time: 1212587706 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52342 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16257 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tim.joedicke@fh-worms.de Precedence: bulk X-list: xfs hi, i have a question about the dmapi support for xfs. in detail, it's about the method "xfs_dm_inode_to_fh()". i tried to swap out this function to vfs code and this is what it looks like now: int vfs_dm_inode_to_fh(struct inode *ip, dm_fid_t *dmfid, dm_fsid_t *dmfsid) { dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); dmfid->dm_fid_pad = 0; memcpy(&dmfid->dm_fid_ino, &ip->i_ino, sizeof(dmfid->dm_fid_ino)); dmfid->dm_fid_gen = ip->i_generation; *dmfsid = 11; // need generation system return 0; } don't be bothered by the fsid. ;) i use to have exactly one filesystem registered und every time the fsid is used, it's 11. ;) the problem is, that the generated handle is wrong. dm_handle_is_valid() says, that the handle is valid, but i cannot set a disposition e.g. if i get a handle via dm_path_to_fshandle() or dm_path_to_handle() (says the handle is bad). on the other hand, if i set a global disposition, receive the mount event and get the fshandle from the message, the handle seems to be correct? maybe you can give ma a hint? is something wrong with dm_inode_to_fh()? thanks in advance, tim From owner-xfs@oss.sgi.com Wed Jun 4 07:15:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 07:15:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54EFQSB006430 for ; Wed, 4 Jun 2008 07:15:27 -0700 X-ASG-Debug-ID: 1212588980-071401520000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EA6B111B6DD9 for ; Wed, 4 Jun 2008 07:16:20 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by cuda.sgi.com with ESMTP id jMAKCBr285WWYzAQ for ; Wed, 04 Jun 2008 07:16:20 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta02.mail.rr.com with ESMTP id <20080604141612.OLHD25858.hrndva-omta02.mail.rr.com@tomslinux.homelinux.org>; Wed, 4 Jun 2008 14:16:12 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m54EG3kB006007; Wed, 4 Jun 2008 09:16:03 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m54EG2uG006006; Wed, 4 Jun 2008 09:16:02 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.226.42 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Wed, 4 Jun 2008 09:16:02 -0500 (CDT) Message-ID: <32954.143.166.226.42.1212588962.squirrel@tomslinux.homelinux.org> In-Reply-To: <20080604053156.GB6509@infradead.org> References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> <20080604053156.GB6509@infradead.org> Date: Wed, 4 Jun 2008 09:16:02 -0500 (CDT) X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article To: "Christoph Hellwig" Cc: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.122] X-Barracuda-Start-Time: 1212588980 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52343 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16258 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs > On Tue, Jun 03, 2008 at 03:48:49PM -0500, Thomas King wrote: >> For the most part, XFS is used for massive filesystems (hundreds of petabytes) > > I think undreds of petabytes is not something we commonly see today :) > hundreds of TB is more reasonable. If I'm going to answer his two articles, he's speaking in the context of massive filesystems. True, hundreds of petabytes are not common but that's the environment he's talking about. From what I'm seeing from XFS, BTRFS, ext4, and HAMMER, Linux filesystems are going to easily keep up with the current trend. For the massive filesystems Henry speaks of, XFS has some new features I don't think he's aware of and needs to come out in this answer. Tom King From owner-xfs@oss.sgi.com Wed Jun 4 07:51:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 07:51:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54EpHsN008069 for ; Wed, 4 Jun 2008 07:51:18 -0700 X-ASG-Debug-ID: 1212591130-3a5402a80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EF11B177B77B for ; Wed, 4 Jun 2008 07:52:10 -0700 (PDT) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by cuda.sgi.com with ESMTP id kvRwmqgUpzW34sHk for ; Wed, 04 Jun 2008 07:52:10 -0700 (PDT) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id ED53E17F521; Wed, 4 Jun 2008 16:52:09 +0200 (CEST) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by smtp8-g19.free.fr (Postfix) with ESMTP id 9ED1E17F55C; Wed, 4 Jun 2008 16:52:09 +0200 (CEST) Date: Wed, 4 Jun 2008 16:52:14 +0200 From: Emmanuel Florac To: Thomas King Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article Message-ID: <20080604165214.31dceeaa@harpe.intellique.com> In-Reply-To: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> References: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> Organization: Intellique X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Barracuda-Connect: smtp8-g19.free.fr[212.27.42.65] X-Barracuda-Start-Time: 1212591131 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52346 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_SA074b URI: Custom Rule SA074b X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m54EpJsN008071 X-archive-position: 16259 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: eflorac@intellique.com Precedence: bulk X-list: xfs Le Tue, 3 Jun 2008 10:34:48 -0500 (CDT) Thomas King écrivait: > I am writing an article to answer Henry Newman's at > http://www.enterprisestorageforum.com/sans/features/article.php/3749926. > I've already been bugging folks on the ext4 mailing list and one of > them mentioned I should also send some of the same questions to this > list. Please let me know if I may do so. Seems like a good idea. This guy doesn't even mention XFS, while it's more or less the only viable option for big filesystems (more than 8TB). I currently use 30, 40TB XFS filesystems that work just fine. I've already compared all filesystems : XFS works great for big filesystems. JFS works well too, however it lacks a defragmenting utility which is quite a problem for big filesystems with lots of write activity. reiserfs 3.6 simply breaks over 4TB; mkfs.ext3 is so slow than it's a problem from the start, then the performance is abysmal. -- ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 4 08:05:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 08:05:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54F5tOQ009142 for ; Wed, 4 Jun 2008 08:05:55 -0700 X-ASG-Debug-ID: 1212592008-593a003e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 69D3F11B76DD for ; Wed, 4 Jun 2008 08:06:49 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 2miyFXGNzRNsP3BK for ; Wed, 04 Jun 2008 08:06:49 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id CBC8C98FE36; Wed, 4 Jun 2008 10:06:47 -0500 (CDT) Message-ID: <4846AF87.8010307@sandeen.net> Date: Wed, 04 Jun 2008 10:06:47 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas King CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> <20080604053156.GB6509@infradead.org> <32954.143.166.226.42.1212588962.squirrel@tomslinux.homelinux.org> In-Reply-To: <32954.143.166.226.42.1212588962.squirrel@tomslinux.homelinux.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212592009 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52347 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16260 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Thomas King wrote: >> On Tue, Jun 03, 2008 at 03:48:49PM -0500, Thomas King wrote: >>> For the most part, XFS is used for massive filesystems (hundreds of petabytes) >> I think undreds of petabytes is not something we commonly see today :) >> hundreds of TB is more reasonable. > > If I'm going to answer his two articles, he's speaking in the context of massive > filesystems. True, hundreds of petabytes are not common but that's the > environment he's talking about. > > From what I'm seeing from XFS, BTRFS, ext4, and HAMMER, Linux filesystems are > going to easily keep up with the current trend. For the massive filesystems > Henry speaks of, XFS has some new features I don't think he's aware of and needs > to come out in this answer. > > Tom King One thing I would be careful of is not to fall into the trap of letting Linux filesystems get bashed over things that *nobody* really has today. Stuff like PNFS, OSD, DIF etc are bleeding-edge for almost *everybody* Petabyte filesystems are hard. For *everybody* And hundred-petabyte filesystems aren't just uncommon, they don't exist AFAIK. -Eric From owner-xfs@oss.sgi.com Wed Jun 4 08:15:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 08:16:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_15, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54FFw9R010400 for ; Wed, 4 Jun 2008 08:15:59 -0700 X-ASG-Debug-ID: 1212592612-7a3100e40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C8E051B9E6F4 for ; Wed, 4 Jun 2008 08:16:52 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 6LKn1d013GhRNjhY for ; Wed, 04 Jun 2008 08:16:52 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K3ujL-0002XM-PK; Wed, 04 Jun 2008 15:16:51 +0000 Date: Wed, 4 Jun 2008 11:16:51 -0400 From: Christoph Hellwig To: Tim J?dicke Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: vfs dmapi handle generation problem Subject: Re: vfs dmapi handle generation problem Message-ID: <20080604151651.GA16376@infradead.org> References: <8efbf9761cbff87b03e5326866cd914d.squirrel@webmailer.fh-worms.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8efbf9761cbff87b03e5326866cd914d.squirrel@webmailer.fh-worms.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212592612 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52346 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16261 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Jun 04, 2008 at 03:55:04PM +0200, Tim J?dicke wrote: > int > vfs_dm_inode_to_fh(struct inode *ip, dm_fid_t *dmfid, dm_fsid_t *dmfsid) > { > dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); > dmfid->dm_fid_pad = 0; > memcpy(&dmfid->dm_fid_ino, &ip->i_ino, sizeof(dmfid->dm_fid_ino)); > dmfid->dm_fid_gen = ip->i_generation; > > *dmfsid = 11; // need generation system > > return 0; i_ino in struct inode is unsigned long. If you run the above code on a 32bit system you'll get crap in the upper half of dm_fid_ino. Try: int vfs_dm_inode_to_fh(struct inode *ip, dm_fid_t *dmfid, dm_fsid_t *dmfsid) { dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); dmfid->dm_fid_pad = 0; dmfid->dm_fid_ino = ip->i_ino; dmfid->dm_fid_gen = ip->i_generation; *dmfsid = 11; // need generation system return 0; } instead. If you actually want to support 64bit inode numbers on 32bit systems you'll have to query for it with vfs_getattr, though. From owner-xfs@oss.sgi.com Wed Jun 4 22:37:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:37:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m555beIg020214 for ; Wed, 4 Jun 2008 22:37:40 -0700 X-ASG-Debug-ID: 1212644313-12b003020000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4846111C29AA for ; Wed, 4 Jun 2008 22:38:33 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id C1bNEs8roKcbkaRS for ; Wed, 04 Jun 2008 22:38:33 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4A0A8A9C502; Thu, 5 Jun 2008 00:38:30 -0500 (CDT) Message-ID: <48477BD6.2020909@sandeen.net> Date: Thu, 05 Jun 2008 00:38:30 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Timothy Shimmin CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> In-Reply-To: <4820609C.9090306@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212644314 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52405 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16262 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > Timothy Shimmin wrote: >> David Chinner wrote: >>> On Fri, May 02, 2008 at 03:55:45PM -0500, Eric Sandeen wrote: >>>> Eric Sandeen wrote: >>>>> Eric Sandeen wrote: >>>>>> This should fix the longstanding issues with xfs and old ABI >>>>>> arm boxes, which lead to various asserts and xfs shutdowns, >>>>>> and for which an (incorrect) patch has been floating around >>>>>> for years. (Said patch made ARM internally consistent, but >>>>>> altered the normal xfs on-disk format such that it looked >>>>>> corrupted on other architectures): >>>>>> http://lists.arm.linux.org.uk/lurker/message/20040311.002034.5ecf21a2.html >>>>> ping again... >>>> ping #3... >>> Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. is it EVER going to get checked in? -Eric >>> Looks like if I don't pick it up then nobody is going to answer. >>> I'll run it through my ia64 and x86_64 test boxes and if it's ok >>> then I'll commit it. >>> >> As it only defines __arch_pack for __arm__, >> I literally can't see how on earth it won't pass for ia64 and x86-64, >> though I realise (I guess) we need to test to be sure :) >> >> So Eric tested this on qemu-arm with success. >> And there was a little debate over whether ARM-EABI would work >> currently in XFS, >> with Luca Olivetti saying in one kernel he has success and in another >> he doesn't. And Andre Draszik saying that for ARM-EABI it wouldn't >> work. > > The patch should only affect behavior on *old* abi: > > +#if defined(__arm__) && !defined(__ARM_EABI__) > > it is the only one with the unique alignment that matters here. > > There *is* still another issue on some arm chips related to processor > cache flushing; I didn't see the problem in qemu because it the emulator > does not have this behavior. > > But, it's a separate issue from the structure alignment this patch > addresses. > > One thing at a time. :) > > Thanks, > > -Eric > >> That aside, Eric has tried out on ARM without EABI (old ABI) and has had success, >> so it is at least useful for this case. >> I don't see us doing any arm testing for this ourselves :) >> >> --Tim >> > > From owner-xfs@oss.sgi.com Wed Jun 4 22:45:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:45:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m555jc7U021030 for ; Wed, 4 Jun 2008 22:45:39 -0700 Received: from [134.14.55.13] (dhcp13.melbourne.sgi.com [134.14.55.13]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19412; Thu, 5 Jun 2008 15:46:23 +1000 Message-ID: <48477DA3.8090602@sgi.com> Date: Thu, 05 Jun 2008 15:46:11 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Eric Sandeen CC: Timothy Shimmin , xfs-oss Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> In-Reply-To: <48477BD6.2020909@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16263 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Eric Sandeen wrote: >> Timothy Shimmin wrote: >>> David Chinner wrote: >>>> On Fri, May 02, 2008 at 03:55:45PM -0500, Eric Sandeen wrote: >>>>> Eric Sandeen wrote: >>>>>> Eric Sandeen wrote: >>>>>>> This should fix the longstanding issues with xfs and old ABI >>>>>>> arm boxes, which lead to various asserts and xfs shutdowns, >>>>>>> and for which an (incorrect) patch has been floating around >>>>>>> for years. (Said patch made ARM internally consistent, but >>>>>>> altered the normal xfs on-disk format such that it looked >>>>>>> corrupted on other architectures): >>>>>>> http://lists.arm.linux.org.uk/lurker/message/20040311.002034.5ecf21a2.html >>>>>> ping again... >>>>> ping #3... >>>> > > Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. > is it EVER going to get checked in? Please take it in Tim, that nasty CORRUPTION word caught my attention :) Cheers > > -Eric > >>>> Looks like if I don't pick it up then nobody is going to answer. >>>> I'll run it through my ia64 and x86_64 test boxes and if it's ok >>>> then I'll commit it. >>>> >>> As it only defines __arch_pack for __arm__, >>> I literally can't see how on earth it won't pass for ia64 and x86-64, >>> though I realise (I guess) we need to test to be sure :) >>> >>> So Eric tested this on qemu-arm with success. >>> And there was a little debate over whether ARM-EABI would work >>> currently in XFS, >>> with Luca Olivetti saying in one kernel he has success and in another >>> he doesn't. And Andre Draszik saying that for ARM-EABI it wouldn't >>> work. >> The patch should only affect behavior on *old* abi: >> >> +#if defined(__arm__) && !defined(__ARM_EABI__) >> >> it is the only one with the unique alignment that matters here. >> >> There *is* still another issue on some arm chips related to processor >> cache flushing; I didn't see the problem in qemu because it the emulator >> does not have this behavior. >> >> But, it's a separate issue from the structure alignment this patch >> addresses. >> >> One thing at a time. :) >> >> Thanks, >> >> -Eric >> >>> That aside, Eric has tried out on ARM without EABI (old ABI) and has had success, >>> so it is at least useful for this case. >>> I don't see us doing any arm testing for this ourselves :) >>> >>> --Tim >>> >> > > -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 4 22:48:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:48:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m555mFSN021516 for ; Wed, 4 Jun 2008 22:48:15 -0700 X-ASG-Debug-ID: 1212644949-16f201c40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 982CA1783482 for ; Wed, 4 Jun 2008 22:49:09 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 1zXtNRrfd0iKX51a for ; Wed, 04 Jun 2008 22:49:09 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 09F9AA9BF4C; Thu, 5 Jun 2008 00:49:09 -0500 (CDT) Message-ID: <48477E54.9090309@sandeen.net> Date: Thu, 05 Jun 2008 00:49:08 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <48477DA3.8090602@sgi.com> In-Reply-To: <48477DA3.8090602@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212644949 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16264 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Goodwin wrote: > > Eric Sandeen wrote: >> Eric Sandeen wrote: >>> Timothy Shimmin wrote: >>>> David Chinner wrote: >>>>> On Fri, May 02, 2008 at 03:55:45PM -0500, Eric Sandeen wrote: >>>>>> Eric Sandeen wrote: >>>>>>> Eric Sandeen wrote: >>>>>>>> This should fix the longstanding issues with xfs and old ABI >>>>>>>> arm boxes, which lead to various asserts and xfs shutdowns, >>>>>>>> and for which an (incorrect) patch has been floating around >>>>>>>> for years. (Said patch made ARM internally consistent, but >>>>>>>> altered the normal xfs on-disk format such that it looked >>>>>>>> corrupted on other architectures): >>>>>>>> http://lists.arm.linux.org.uk/lurker/message/20040311.002034.5ecf21a2.html >>>>>>> ping again... >>>>>> ping #3... >>>>> >> Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. >> is it EVER going to get checked in? > > Please take it in Tim, that nasty CORRUPTION word caught my attention :) > > Cheers heh, thanks Mark. Even though it's only CORRUPTION ON ARM I guess the shouting worked. :) Seriously though if you guys have any problems with it please let me know but I don't want it to just get dropped. -Eric From owner-xfs@oss.sgi.com Wed Jun 4 22:48:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:48:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m555mlZo021648 for ; Wed, 4 Jun 2008 22:48:48 -0700 X-ASG-Debug-ID: 1212644980-12ca01e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from QMTA10.westchester.pa.mail.comcast.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C4EF8178330A for ; Wed, 4 Jun 2008 22:49:41 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by cuda.sgi.com with ESMTP id 505stXBNRw37Ckrv for ; Wed, 04 Jun 2008 22:49:41 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA10.westchester.pa.mail.comcast.net with comcast id a5ng1Z00B1GhbT85A00F00; Thu, 05 Jun 2008 05:49:40 +0000 Received: from stupidest.org ([67.169.95.103]) by OMTA07.westchester.pa.mail.comcast.net with comcast id a5pf1Z0072DpGEz3T00000; Thu, 05 Jun 2008 05:49:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=9gEKhqqyuJkA:10 a=8jcOJXanYWoA:10 a=-14rhKMkA-efwZynJ-cA:9 a=7l0rikYvuLYaqCxl0P_gDbbJ2e0A:4 a=LY0hPdMaydYA:10 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 032C52824F77; Wed, 4 Jun 2008 22:49:38 -0700 (PDT) Date: Wed, 4 Jun 2008 22:49:38 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Message-ID: <20080605054938.GA17690@puku.stupidest.org> References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48477BD6.2020909@sandeen.net> X-Barracuda-Connect: qmta10.westchester.pa.mail.comcast.net[76.96.62.17] X-Barracuda-Start-Time: 1212644981 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52406 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16265 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs On Thu, Jun 05, 2008 at 12:38:30AM -0500, Eric Sandeen wrote: > Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. [...] > >> As it only defines __arch_pack for __arm__, __arch_pack is a horrible name and not very intuitive, what's wrong with __on_disk or something else? From owner-xfs@oss.sgi.com Wed Jun 4 22:51:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:51:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m555pIee022245 for ; Wed, 4 Jun 2008 22:51:19 -0700 X-ASG-Debug-ID: 1212645133-26ee03cf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8543A1EBE89 for ; Wed, 4 Jun 2008 22:52:13 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id MUHnp6DoiwI7GJqb for ; Wed, 04 Jun 2008 22:52:13 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id BBFFCA9C504; Thu, 5 Jun 2008 00:52:12 -0500 (CDT) Message-ID: <48477F0C.80000@sandeen.net> Date: Thu, 05 Jun 2008 00:52:12 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Chris Wedgwood CC: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <20080605054938.GA17690@puku.stupidest.org> In-Reply-To: <20080605054938.GA17690@puku.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212645133 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52406 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16266 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris Wedgwood wrote: > On Thu, Jun 05, 2008 at 12:38:30AM -0500, Eric Sandeen wrote: > >> Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. > > [...] > >>>> As it only defines __arch_pack for __arm__, > > __arch_pack is a horrible name and not very intuitive, what's wrong > with __on_disk or something else? > because __on_disk implies that it's on disk. __arch_pack means that it's packed on some arches. Not the same thing. If anyone wants to change the name to __purple_ponies or whatever that's fine, but the intent is to pack these 3(?) and only these 3 structs on this arch and only this arch, at least for now. 'til Jeff gets his all-singing all-dancing no-regression gcc annotation in place anyway. -Eric From owner-xfs@oss.sgi.com Wed Jun 4 23:02:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 23:02:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5562023023095 for ; Wed, 4 Jun 2008 23:02:01 -0700 Received: from [134.14.55.13] (dhcp13.melbourne.sgi.com [134.14.55.13]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19840; Thu, 5 Jun 2008 16:02:41 +1000 Message-ID: <48478175.9060009@sgi.com> Date: Thu, 05 Jun 2008 16:02:29 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Eric Sandeen CC: Timothy Shimmin , xfs-oss Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <48477DA3.8090602@sgi.com> <48477E54.9090309@sandeen.net> In-Reply-To: <48477E54.9090309@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16267 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > > heh, thanks Mark. Even though it's only CORRUPTION ON ARM I guess the > shouting worked. :) Well, we're dealing with apparent insidious corruption after failed btree AG allocations (which aren't supposed to fail). This seems to stem from the fixes for the ENOSPC deadlock bugs (two years ago, see below). you and Nathan probably remember this ..? Timothy Shimmin wrote: > Okay some history in xfs-dev archives on this bug... > plenty of reading here :) > Reverse chronological order with initial report from > guy at NEC: > > May 2006 > Review thread b/w Nathan and Ying Ping: > http://ils.corp.sgi.com/Archives/xfs-dev/200605/msg00128.html > > April 2006 > Thread - dgc, Ying, nathan > http://ils.corp.sgi.com/Archives/xfs-dev/200604/msg00005.html > > March 2006 - 2 threads > http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00002.html > http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00140.html > > Feb 2006 > http://ils.corp.sgi.com/Archives/xfs-dev/200602/msg00062.html > Initial report and suggested test case by Asano Masahiro - NEC > (fwd'ed by Eric). > Plenty of commentary by Asano. > Thread - including comments by Steve Lord: > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/13268 -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 4 23:04:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 23:04:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5564GPF023482 for ; Wed, 4 Jun 2008 23:04:17 -0700 Received: from [134.14.55.13] (dhcp13.melbourne.sgi.com [134.14.55.13]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19922; Thu, 5 Jun 2008 16:04:59 +1000 Message-ID: <48478200.7080308@sgi.com> Date: Thu, 05 Jun 2008 16:04:48 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: markgw@sgi.com CC: Eric Sandeen , Timothy Shimmin , xfs-oss Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <48477DA3.8090602@sgi.com> <48477E54.9090309@sandeen.net> <48478175.9060009@sgi.com> In-Reply-To: <48478175.9060009@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16268 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Just realized you can't read the ils threads. But you can read this one: http://thread.gmane.org/gmane.comp.file-systems.xfs.general/13268 -- Mark Mark Goodwin wrote: > > > Eric Sandeen wrote: >> >> heh, thanks Mark. Even though it's only CORRUPTION ON ARM I guess the >> shouting worked. :) > > Well, we're dealing with apparent insidious corruption after > failed btree AG allocations (which aren't supposed to fail). > This seems to stem from the fixes for the ENOSPC deadlock bugs > (two years ago, see below). you and Nathan probably remember > this ..? > > Timothy Shimmin wrote: >> Okay some history in xfs-dev archives on this bug... >> plenty of reading here :) >> Reverse chronological order with initial report from >> guy at NEC: >> >> May 2006 >> Review thread b/w Nathan and Ying Ping: >> http://ils.corp.sgi.com/Archives/xfs-dev/200605/msg00128.html >> >> April 2006 >> Thread - dgc, Ying, nathan >> http://ils.corp.sgi.com/Archives/xfs-dev/200604/msg00005.html >> >> March 2006 - 2 threads >> http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00002.html >> http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00140.html >> >> Feb 2006 >> http://ils.corp.sgi.com/Archives/xfs-dev/200602/msg00062.html >> Initial report and suggested test case by Asano Masahiro - NEC >> (fwd'ed by Eric). >> Plenty of commentary by Asano. >> Thread - including comments by Steve Lord: >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/13268 > -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 4 23:05:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 23:05:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m55659g9023631 for ; Wed, 4 Jun 2008 23:05:09 -0700 X-ASG-Debug-ID: 1212645962-1d7903c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3A60211C4D73 for ; Wed, 4 Jun 2008 23:06:02 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id wXB2eHWLCmYCm7qX for ; Wed, 04 Jun 2008 23:06:02 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 39A3998FF76; Thu, 5 Jun 2008 01:06:02 -0500 (CDT) Message-ID: <48478249.8060301@sandeen.net> Date: Thu, 05 Jun 2008 01:06:01 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <48477DA3.8090602@sgi.com> <48477E54.9090309@sandeen.net> <48478175.9060009@sgi.com> In-Reply-To: <48478175.9060009@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212645963 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52407 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16269 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Goodwin wrote: > > Eric Sandeen wrote: >> heh, thanks Mark. Even though it's only CORRUPTION ON ARM I guess the >> shouting worked. :) > > Well, we're dealing with apparent insidious corruption after > failed btree AG allocations (which aren't supposed to fail). > This seems to stem from the fixes for the ENOSPC deadlock bugs > (two years ago, see below). you and Nathan probably remember > this ..? nah it's easier to hit than that. Just run xfs-qa on arm with old abi and you'll hit it plenty quickly. there are other calculations around that assume no padding. Even if it doesn't look corrupted on arm, the filesystem isn't portable. -Eric > Timothy Shimmin wrote: >> Okay some history in xfs-dev archives on this bug... >> plenty of reading here :) >> Reverse chronological order with initial report from >> guy at NEC: >> >> May 2006 >> Review thread b/w Nathan and Ying Ping: >> http://ils.corp.sgi.com/Archives/xfs-dev/200605/msg00128.html >> >> April 2006 >> Thread - dgc, Ying, nathan >> http://ils.corp.sgi.com/Archives/xfs-dev/200604/msg00005.html >> >> March 2006 - 2 threads >> http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00002.html >> http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00140.html >> >> Feb 2006 >> http://ils.corp.sgi.com/Archives/xfs-dev/200602/msg00062.html >> Initial report and suggested test case by Asano Masahiro - NEC >> (fwd'ed by Eric). >> Plenty of commentary by Asano. >> Thread - including comments by Steve Lord: >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/13268 > From owner-xfs@oss.sgi.com Wed Jun 4 23:33:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 23:33:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m556XPn4025936 for ; Wed, 4 Jun 2008 23:33:25 -0700 X-ASG-Debug-ID: 1212647658-691200680000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A248D11C599F for ; Wed, 4 Jun 2008 23:34:19 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id bdePHPLbQgrYZhp7 for ; Wed, 04 Jun 2008 23:34:19 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id AEE7A994A37; Thu, 5 Jun 2008 01:34:18 -0500 (CDT) Message-ID: <484788E9.8050800@sandeen.net> Date: Thu, 05 Jun 2008 01:34:17 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Chris Wedgwood CC: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <20080605054938.GA17690@puku.stupidest.org> In-Reply-To: <20080605054938.GA17690@puku.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212647659 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52407 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16270 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris Wedgwood wrote: > On Thu, Jun 05, 2008 at 12:38:30AM -0500, Eric Sandeen wrote: > >> Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. > > [...] > >>>> As it only defines __arch_pack for __arm__, > > __arch_pack is a horrible name and not very intuitive, what's wrong > with __on_disk or something else? > > seriously, if you don't like the name or the style of the fix that's fine, we can fix that up, but I went to enough trouble to track down the issue and test the fix it seems worth actually... fixing it. If you want to __on_disk annotate everything and only pack it on arm OABI that might be less hacky. cw almost convinced me of this. I was just going for "least invasive" here. -Eric From owner-xfs@oss.sgi.com Thu Jun 5 00:30:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 00:30:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m557UDNn005115 for ; Thu, 5 Jun 2008 00:30:15 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA21689; Thu, 5 Jun 2008 17:30:58 +1000 Message-ID: <48479632.4080406@sgi.com> Date: Thu, 05 Jun 2008 17:30:58 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] factor out inode has attrs check References: <20080603113955.GA2703@lst.de> In-Reply-To: <20080603113955.GA2703@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16271 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Looks good. I'll run thru qa and check in. So there are a couple of cases where XFS_DINODE_FMT_LOCAL is used in xfs_attr_inactive() as well as the noattr check. Okay, that's because the EAs would be in shortform so we don't have to do anything for inactive here (the inode inactive will suffice). Apart from that they are all replacements (callouts) except for the superfluous check Christoph mentioned. Cool. --Tim Christoph Hellwig wrote: > Note that xfs_attr_fetch did the check twice while keeping the inode > locked and we can just remove the superflous check. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_attr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:32:06.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 > @@ -111,6 +111,17 @@ xfs_attr_name_to_xname( > return 0; > } > > +STATIC int > +xfs_inode_hasattr( > + struct xfs_inode *ip) > +{ > + if (!XFS_IFORK_Q(ip) || > + (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > + ip->i_d.di_anextents == 0)) > + return 0; > + return 1; > +} > + > /*======================================================================== > * Overall external interface routines. > *========================================================================*/ > @@ -122,10 +133,8 @@ xfs_attr_fetch(xfs_inode_t *ip, struct x > xfs_da_args_t args; > int error; > > - if ((XFS_IFORK_Q(ip) == 0) || > - (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - ip->i_d.di_anextents == 0)) > - return(ENOATTR); > + if (!xfs_inode_hasattr(ip)) > + return ENOATTR; > > /* > * Fill in the arg structure for this request. > @@ -143,11 +152,7 @@ xfs_attr_fetch(xfs_inode_t *ip, struct x > /* > * Decide on what work routines to call based on the inode size. > */ > - if (XFS_IFORK_Q(ip) == 0 || > - (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - ip->i_d.di_anextents == 0)) { > - error = XFS_ERROR(ENOATTR); > - } else if (ip->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > + if (ip->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > error = xfs_attr_shortform_getvalue(&args); > } else if (xfs_bmap_one_block(ip, XFS_ATTR_FORK)) { > error = xfs_attr_leaf_get(&args); > @@ -523,9 +528,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, str > /* > * Decide on what work routines to call based on the inode size. > */ > - if (XFS_IFORK_Q(dp) == 0 || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp)) { > error = XFS_ERROR(ENOATTR); > goto out; > } > @@ -595,11 +598,9 @@ xfs_attr_remove( > return error; > > xfs_ilock(dp, XFS_ILOCK_SHARED); > - if (XFS_IFORK_Q(dp) == 0 || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp)) { > xfs_iunlock(dp, XFS_ILOCK_SHARED); > - return(XFS_ERROR(ENOATTR)); > + return XFS_ERROR(ENOATTR); > } > xfs_iunlock(dp, XFS_ILOCK_SHARED); > > @@ -615,9 +616,7 @@ xfs_attr_list_int(xfs_attr_list_context_ > /* > * Decide on what work routines to call based on the inode size. > */ > - if (XFS_IFORK_Q(dp) == 0 || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp)) { > error = 0; > } else if (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > error = xfs_attr_shortform_list(context); > @@ -810,12 +809,10 @@ xfs_attr_inactive(xfs_inode_t *dp) > ASSERT(! XFS_NOT_DQATTACHED(mp, dp)); > > xfs_ilock(dp, XFS_ILOCK_SHARED); > - if ((XFS_IFORK_Q(dp) == 0) || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp) || > + dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > xfs_iunlock(dp, XFS_ILOCK_SHARED); > - return(0); > + return 0; > } > xfs_iunlock(dp, XFS_ILOCK_SHARED); > > @@ -848,10 +845,8 @@ xfs_attr_inactive(xfs_inode_t *dp) > /* > * Decide on what work routines to call based on the inode size. > */ > - if ((XFS_IFORK_Q(dp) == 0) || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp) || > + dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > error = 0; > goto out; > } > From owner-xfs@oss.sgi.com Thu Jun 5 00:58:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 00:58:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m557wFIg007925 for ; Thu, 5 Jun 2008 00:58:19 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA22026; Thu, 5 Jun 2008 17:58:58 +1000 Message-ID: <48479CC2.8000605@sgi.com> Date: Thu, 05 Jun 2008 17:58:58 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr References: <20080603114837.GB2703@lst.de> In-Reply-To: <20080603114837.GB2703@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16272 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Looks reasonable. Will run thru qa etc. -Tim. ----- Notes as walk thru patch...(prob. already mentioned by hch preamble:) xfs_attr.c * move stats/shutdown/lock/trace from xfs_attr_list into xfs_attr_list_int * xfs_attr_put_listent -> adds in a xfs_attr_namesp_match_overrides() check -> use alist for context->alist * remove xfs_attr_kern_list and xfs_attr_kern_list_sizes from xfs_attr.c * xfs_attr_list -> remove the conditional context setup code for put_listent callbacks -> KERNOVAL and KERNAMELS code removed from xfs_attr_list xfs_attr_leaf.c * call the put_listent function with the flags instead of the namespace * remove calls to xfs_attr_namesp_match_overrides() in the listing functions as we are now using flags instead of namespaces xfs_attr_leaf.h * move context def out as hch said - good idea xfs_xattr.c * xfs_attr_kern_list and xfs_attr_kern_list_sizes have moved here * xfs_vn_listxattr -> remove ATTR_KERN flags and setup put_listent function depending if want sizes or not -> replace result with context.count xfs_acl.c * removes ATTR_KERNACCESS flag from fetch call the rest of the KERN macros removed are LS ones -> TODO: need to look up references to KERNACCESS -> Okay, looks like it hasn't been used for a while So we remove: -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ Q: how do we get away with this? * ATTR_KERNAMELS is used for the top level EA list interface with linux, so if we do the call high enough then it isn't needed * ATTR_KERNORMALS will include secure namespace even if don't have namespace match * ATTR_KERNROOTLS will include root namespace even if don't have namespace match That we don't need these anymore shows how wacky that they were :-) * KERNACCESS unused for a while by the looks of it --Tim Christoph Hellwig wrote: > This patch switches xfs_vn_listxattr to set it's put_listent callback > directly and not go through xfs_attr_list. > > The changes to the lowleve attr code are: > > - the put_listent callback now gets the ondisk flags passed and > performce the namespace lookup and check aswell as the check > for the right attribute root itself > - xfs_attr_list_int is made non-static for use by other callers > than xfs_attr_list and now performs the inode locking and tracing > itself > > The changes to the xfs_attr_list path are: > > - all checks for now uneeded ATTR_KERN flags are gone, and only > the IRIX interface is supported for this code path > - xfs_attr_put_listent is simplified by not needing to lookup > the namespace but rather compare the integer flags directly. > > The changes to xfs_vn_listxattr are: > > - now directly calls xfs_attr_list_int with it's own put_listent > callbacks > - attr namespace prefix are now looked up by simple helpers, > struct attrnames is gone. > > Other changes: > > - struct xfs_attr_list_context is moved from xfs_attr_leaf.h into > xfs_attr.h. It's not realted to the leaf format at all and > xfs_attr.h contains the interface to the attr code which it is > part of now. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_attr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:44:07.000000000 +0200 > @@ -16,8 +16,6 @@ > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > */ > > -#include > - > #include "xfs.h" > #include "xfs_fs.h" > #include "xfs_types.h" > @@ -607,12 +605,20 @@ xfs_attr_remove( > return xfs_attr_remove_int(dp, &xname, flags); > } > > -STATIC int > +int > xfs_attr_list_int(xfs_attr_list_context_t *context) > { > int error; > xfs_inode_t *dp = context->dp; > > + XFS_STATS_INC(xs_attr_list); > + > + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > + return EIO; > + > + xfs_ilock(dp, XFS_ILOCK_SHARED); > + xfs_attr_trace_l_c("syscall start", context); > + > /* > * Decide on what work routines to call based on the inode size. > */ > @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ > } else { > error = xfs_attr_node_list(context); > } > + > + xfs_iunlock(dp, XFS_ILOCK_SHARED); > + xfs_attr_trace_l_c("syscall end", context); > + > return error; > } > > @@ -634,6 +644,18 @@ xfs_attr_list_int(xfs_attr_list_context_ > ((ATTR_ENTBASESIZE + (namelen) + 1 + sizeof(u_int32_t)-1) \ > & ~(sizeof(u_int32_t)-1)) > > +STATIC int > +xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) > +{ > + if (((arg_flags & ATTR_SECURE) == 0) != > + ((ondisk_flags & XFS_ATTR_SECURE) == 0)) > + return 0; > + if (((arg_flags & ATTR_ROOT) == 0) != > + ((ondisk_flags & XFS_ATTR_ROOT) == 0)) > + return 0; > + return 1; > +} > + > /* > * Format an attribute and copy it out to the user's buffer. > * Take care to check values and protect against them changing later, > @@ -641,74 +663,43 @@ xfs_attr_list_int(xfs_attr_list_context_ > */ > /*ARGSUSED*/ > STATIC int > -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, > +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, > char *name, int namelen, > int valuelen, char *value) > { > + struct attrlist *alist = (struct attrlist *)context->alist; > attrlist_ent_t *aep; > int arraytop; > > ASSERT(!(context->flags & ATTR_KERNOVAL)); > ASSERT(context->count >= 0); > ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); > - ASSERT(context->firstu >= sizeof(*context->alist)); > + ASSERT(context->firstu >= sizeof(*alist)); > ASSERT(context->firstu <= context->bufsize); > > - arraytop = sizeof(*context->alist) + > - context->count * sizeof(context->alist->al_offset[0]); > + if (xfs_attr_namesp_match_overrides(context->flags, flags)) > + return 0; > + > + arraytop = sizeof(*alist) + > + context->count * sizeof(alist->al_offset[0]); > context->firstu -= ATTR_ENTSIZE(namelen); > if (context->firstu < arraytop) { > xfs_attr_trace_l_c("buffer full", context); > - context->alist->al_more = 1; > + alist->al_more = 1; > context->seen_enough = 1; > return 1; > } > > - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); > + aep = (attrlist_ent_t *)&context->alist[context->firstu]; > aep->a_valuelen = valuelen; > memcpy(aep->a_name, name, namelen); > - aep->a_name[ namelen ] = 0; > - context->alist->al_offset[ context->count++ ] = context->firstu; > - context->alist->al_count = context->count; > + aep->a_name[namelen] = 0; > + alist->al_offset[context->count++] = context->firstu; > + alist->al_count = context->count; > xfs_attr_trace_l_c("add", context); > return 0; > } > > -STATIC int > -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, > - char *name, int namelen, > - int valuelen, char *value) > -{ > - char *offset; > - int arraytop; > - > - ASSERT(context->count >= 0); > - > - arraytop = context->count + namesp->attr_namelen + namelen + 1; > - if (arraytop > context->firstu) { > - context->count = -1; /* insufficient space */ > - return 1; > - } > - offset = (char *)context->alist + context->count; > - strncpy(offset, namesp->attr_name, namesp->attr_namelen); > - offset += namesp->attr_namelen; > - strncpy(offset, name, namelen); /* real name */ > - offset += namelen; > - *offset = '\0'; > - context->count += namesp->attr_namelen + namelen + 1; > - return 0; > -} > - > -/*ARGSUSED*/ > -STATIC int > -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, > - char *name, int namelen, > - int valuelen, char *value) > -{ > - context->count += namesp->attr_namelen + namelen + 1; > - return 0; > -} > - > /* > * Generate a list of extended attribute names and optionally > * also value lengths. Positive return value follows the XFS > @@ -725,10 +716,9 @@ xfs_attr_list( > attrlist_cursor_kern_t *cursor) > { > xfs_attr_list_context_t context; > + struct attrlist *alist; > int error; > > - XFS_STATS_INC(xs_attr_list); > - > /* > * Validate the cursor. > */ > @@ -749,52 +739,21 @@ xfs_attr_list( > /* > * Initialize the output buffer. > */ > + memset(&context, 0, sizeof(context)); > context.dp = dp; > context.cursor = cursor; > - context.count = 0; > - context.dupcnt = 0; > context.resynch = 1; > context.flags = flags; > - context.seen_enough = 0; > - context.alist = (attrlist_t *)buffer; > - context.put_value = 0; > - > - if (flags & ATTR_KERNAMELS) { > - context.bufsize = bufsize; > - context.firstu = context.bufsize; > - if (flags & ATTR_KERNOVAL) > - context.put_listent = xfs_attr_kern_list_sizes; > - else > - context.put_listent = xfs_attr_kern_list; > - } else { > - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ > - context.firstu = context.bufsize; > - context.alist->al_count = 0; > - context.alist->al_more = 0; > - context.alist->al_offset[0] = context.bufsize; > - context.put_listent = xfs_attr_put_listent; > - } > - > - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > - return EIO; > + context.alist = buffer; > + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ > + context.firstu = context.bufsize; > + context.put_listent = xfs_attr_put_listent; > > - xfs_ilock(dp, XFS_ILOCK_SHARED); > - xfs_attr_trace_l_c("syscall start", &context); > + alist = (struct attrlist *)context.alist; > + alist->al_offset[0] = context.bufsize; > > error = xfs_attr_list_int(&context); > - > - xfs_iunlock(dp, XFS_ILOCK_SHARED); > - xfs_attr_trace_l_c("syscall end", &context); > - > - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { > - /* must return negated buffer size or the error */ > - if (context.count < 0) > - error = XFS_ERROR(ERANGE); > - else > - error = -context.count; > - } else > - ASSERT(error >= 0); > - > + ASSERT(error >= 0); > return error; > } > > @@ -2357,12 +2316,7 @@ xfs_attr_trace_enter(int type, char *whe > (void *)((__psunsigned_t)context->bufsize), > (void *)((__psunsigned_t)context->count), > (void *)((__psunsigned_t)context->firstu), > - (void *)((__psunsigned_t) > - (((context->count > 0) && > - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) > - ? (ATTR_ENTRY(context->alist, > - context->count-1)->a_valuelen) > - : 0)), > + NULL, > (void *)((__psunsigned_t)context->dupcnt), > (void *)((__psunsigned_t)context->flags), > (void *)a13, (void *)a14, (void *)a15); > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:44:07.000000000 +0200 > @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att > * Namespace helper routines > *========================================================================*/ > > -STATIC_INLINE attrnames_t * > -xfs_attr_flags_namesp(int flags) > -{ > - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: > - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); > -} > - > /* > * If namespace bits don't match return 0. > * If all match then return 1. > @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int > return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); > } > > -/* > - * If namespace bits don't match and we don't have an override for it > - * then return 0. > - * If all match or are overridable then return 1. > - */ > -STATIC_INLINE int > -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) > -{ > - if (((arg_flags & ATTR_SECURE) == 0) != > - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && > - !(arg_flags & ATTR_KERNORMALS)) > - return 0; > - if (((arg_flags & ATTR_ROOT) == 0) != > - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && > - !(arg_flags & ATTR_KERNROOTLS)) > - return 0; > - return 1; > -} > - > > /*======================================================================== > * External routines when attribute fork size < XFS_LITINO(mp). > @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co > (XFS_ISRESET_CURSOR(cursor) && > (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { > for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { > - attrnames_t *namesp; > - > - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { > - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); > - continue; > - } > - namesp = xfs_attr_flags_namesp(sfe->flags); > error = context->put_listent(context, > - namesp, > + sfe->flags, > (char *)sfe->nameval, > (int)sfe->namelen, > (int)sfe->valuelen, > @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co > kmem_free(sbuf); > return XFS_ERROR(EFSCORRUPTED); > } > - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { > - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); > - continue; > - } > + > sbp->entno = i; > sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); > sbp->name = (char *)sfe->nameval; > @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co > * Loop putting entries into the user buffer. > */ > for ( ; i < nsbuf; i++, sbp++) { > - attrnames_t *namesp; > - > - namesp = xfs_attr_flags_namesp(sbp->flags); > - > if (cursor->hashval != sbp->hash) { > cursor->hashval = sbp->hash; > cursor->offset = 0; > } > error = context->put_listent(context, > - namesp, > + sbp->flags, > sbp->name, > sbp->namelen, > sbp->valuelen, > @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > */ > retval = 0; > for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { > - attrnames_t *namesp; > - > if (be32_to_cpu(entry->hashval) != cursor->hashval) { > cursor->hashval = be32_to_cpu(entry->hashval); > cursor->offset = 0; > @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > > if (entry->flags & XFS_ATTR_INCOMPLETE) > continue; /* skip incomplete entries */ > - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) > - continue; > - > - namesp = xfs_attr_flags_namesp(entry->flags); > > if (entry->flags & XFS_ATTR_LOCAL) { > xfs_attr_leaf_name_local_t *name_loc = > XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); > > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_loc->nameval, > (int)name_loc->namelen, > be16_to_cpu(name_loc->valuelen), > @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > if (retval) > return retval; > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_rmt->name, > (int)name_rmt->namelen, > valuelen, > (char*)args.value); > kmem_free(args.value); > - } > - else { > + } else { > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_rmt->name, > (int)name_rmt->namelen, > valuelen, > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:44:07.000000000 +0200 > @@ -30,7 +30,6 @@ > > struct attrlist; > struct attrlist_cursor_kern; > -struct attrnames; > struct xfs_dabuf; > struct xfs_da_args; > struct xfs_da_state; > @@ -204,33 +203,6 @@ static inline int xfs_attr_leaf_entsize_ > return (((bsize) >> 1) + ((bsize) >> 2)); > } > > - > -/*======================================================================== > - * Structure used to pass context around among the routines. > - *========================================================================*/ > - > - > -struct xfs_attr_list_context; > - > -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, > - char *, int, int, char *); > - > -typedef struct xfs_attr_list_context { > - struct xfs_inode *dp; /* inode */ > - struct attrlist_cursor_kern *cursor; /* position in list */ > - struct attrlist *alist; /* output buffer */ > - int seen_enough; /* T/F: seen enough of list? */ > - int count; /* num used entries */ > - int dupcnt; /* count dup hashvals seen */ > - int bufsize; /* total buffer size */ > - int firstu; /* first used byte in buffer */ > - int flags; /* from VOP call */ > - int resynch; /* T/F: resynch with cursor */ > - int put_value; /* T/F: need value for listent */ > - put_listent_func_t put_listent; /* list output fmt function */ > - int index; /* index into output buffer */ > -} xfs_attr_list_context_t; > - > /* > * Used to keep a list of "remote value" extents when unlinking an inode. > */ > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:44:07.000000000 +0200 > @@ -17,7 +17,11 @@ > */ > > #include "xfs.h" > +#include "xfs_da_btree.h" > +#include "xfs_bmap_btree.h" > +#include "xfs_inode.h" > #include "xfs_attr.h" > +#include "xfs_attr_leaf.h" > #include "xfs_acl.h" > #include "xfs_vnodeops.h" > > @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, > return __xfs_xattr_set(inode, name, value, size, flags, 0); > } > > -struct attrnames attr_user = { > - .attr_name = "user.", > - .attr_namelen = sizeof("user.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_user_handler = { > .prefix = XATTR_USER_PREFIX, > .get = xfs_xattr_user_get, > @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod > return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); > } > > -struct attrnames attr_trusted = { > - .attr_name = "trusted.", > - .attr_namelen = sizeof("trusted.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_trusted_handler = { > .prefix = XATTR_TRUSTED_PREFIX, > .get = xfs_xattr_trusted_get, > @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode > return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); > } > > -struct attrnames attr_secure = { > - .attr_name = "security.", > - .attr_namelen = sizeof("security.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_security_handler = { > .prefix = XATTR_SECURITY_PREFIX, > .get = xfs_xattr_secure_get, > @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers > NULL > }; > > +static unsigned int xfs_attr_prefix_len(int flags) > +{ > + if (flags & XFS_ATTR_SECURE) > + return sizeof("security"); > + else if (flags & XFS_ATTR_ROOT) > + return sizeof("trusted"); > + else > + return sizeof("user"); > +} > + > +static const char *xfs_attr_prefix(int flags) > +{ > + if (flags & XFS_ATTR_SECURE) > + return xfs_xattr_security_handler.prefix; > + else if (flags & XFS_ATTR_ROOT) > + return xfs_xattr_trusted_handler.prefix; > + else > + return xfs_xattr_user_handler.prefix; > +} > + > +static int > +xfs_attr_kern_list(struct xfs_attr_list_context *context, int flags, > + char *name, int namelen, int valuelen, char *value) > +{ > + unsigned int prefix_len = xfs_attr_prefix_len(flags); > + char *offset; > + int arraytop; > + > + ASSERT(context->count >= 0); > + > + /* > + * Only show root namespace entries if we are actually allowed to > + * see them. > + */ > + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) > + return 0; > + > + arraytop = context->count + prefix_len + namelen + 1; > + if (arraytop > context->firstu) { > + context->count = -1; /* insufficient space */ > + return 1; > + } > + offset = (char *)context->alist + context->count; > + strncpy(offset, xfs_attr_prefix(flags), prefix_len); > + offset += prefix_len; > + strncpy(offset, name, namelen); /* real name */ > + offset += namelen; > + *offset = '\0'; > + context->count += prefix_len + namelen + 1; > + return 0; > +} > + > +static int > +xfs_attr_kern_list_sizes(struct xfs_attr_list_context *context, int flags, > + char *name, int namelen, int valuelen, char *value) > +{ > + context->count += xfs_attr_prefix_len(flags) + namelen + 1; > + return 0; > +} > + > static int > list_one_attr(const char *name, const size_t len, void *data, > size_t size, ssize_t *result) > @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si > ssize_t > xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) > { > + struct xfs_attr_list_context context; > + struct attrlist_cursor_kern cursor = { 0 }; > struct inode *inode = dentry->d_inode; > - struct xfs_inode *ip = XFS_I(inode); > - attrlist_cursor_kern_t cursor = { 0 }; > - int error, xflags; > - ssize_t result; > - > - xflags = ATTR_KERNAMELS; > - if (!size) > - xflags |= ATTR_KERNOVAL; > - > - if (capable(CAP_SYS_ADMIN)) > - xflags |= ATTR_KERNFULLS; > - else > - xflags |= ATTR_KERNORMALS; > - > + int error; > > /* > * First read the regular on-disk attributes. > */ > - result = -xfs_attr_list(ip, data, size, xflags, &cursor); > - if (result < 0) > - return result; > + memset(&context, 0, sizeof(context)); > + context.dp = XFS_I(inode); > + context.cursor = &cursor; > + context.resynch = 1; > + context.alist = data; > + context.bufsize = size; > + context.firstu = context.bufsize; > + > + if (size) > + context.put_listent = xfs_attr_kern_list; > + else > + context.put_listent = xfs_attr_kern_list_sizes; > + > + xfs_attr_list_int(&context); > + if (context.count < 0) > + return -ERANGE; > > /* > * Then add the two synthetic ACL attributes. > @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_access(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_ACCESS, > strlen(POSIX_ACL_XATTR_ACCESS) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_default(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, > strlen(POSIX_ACL_XATTR_DEFAULT) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > > - return result; > + return context.count; > } > Index: linux-2.6-xfs/fs/xfs/xfs_acl.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-01 14:44:07.000000000 +0200 > @@ -341,8 +341,7 @@ xfs_acl_iaccess( > > /* If the file has no ACL return -1. */ > rval = sizeof(xfs_acl_t); > - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, > - ATTR_ROOT | ATTR_KERNACCESS)) { > + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { > _ACL_FREE(acl); > return -1; > } > Index: linux-2.6-xfs/fs/xfs/xfs_attr.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-01 14:44:07.000000000 +0200 > @@ -18,9 +18,11 @@ > #ifndef __XFS_ATTR_H__ > #define __XFS_ATTR_H__ > > +struct xfs_inode; > +struct xfs_da_args; > +struct xfs_attr_list_context; > + > /* > - * xfs_attr.h > - * > * Large attribute lists are structured around Btrees where all the data > * elements are in the leaf nodes. Attribute names are hashed into an int, > * then that int is used as the index into the Btree. Since the hashval > @@ -35,17 +37,6 @@ > * External interfaces > *========================================================================*/ > > -struct cred; > -struct xfs_attr_list_context; > - > -typedef struct attrnames { > - char * attr_name; > - unsigned int attr_namelen; > -} attrnames_t; > - > -extern struct attrnames attr_user; > -extern struct attrnames attr_secure; > -extern struct attrnames attr_trusted; > > #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ > #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ > @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; > #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ > #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ > > -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ > #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ > #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ > -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ > - > -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ > -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ > -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) > > /* > * The maximum size (into the kernel or returned from the kernel) of an > @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { > > > /*======================================================================== > - * Function prototypes for the kernel. > + * Structure used to pass context around among the routines. > *========================================================================*/ > > -struct xfs_inode; > -struct attrlist_cursor_kern; > -struct xfs_da_args; > + > +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, > + char *, int, int, char *); > + > +typedef struct xfs_attr_list_context { > + struct xfs_inode *dp; /* inode */ > + struct attrlist_cursor_kern *cursor; /* position in list */ > + char *alist; /* output buffer */ > + int seen_enough; /* T/F: seen enough of list? */ > + int count; /* num used entries */ > + int dupcnt; /* count dup hashvals seen */ > + int bufsize; /* total buffer size */ > + int firstu; /* first used byte in buffer */ > + int flags; /* from VOP call */ > + int resynch; /* T/F: resynch with cursor */ > + int put_value; /* T/F: need value for listent */ > + put_listent_func_t put_listent; /* list output fmt function */ > + int index; /* index into output buffer */ > +} xfs_attr_list_context_t; > + > + > +/*======================================================================== > + * Function prototypes for the kernel. > + *========================================================================*/ > > /* > * Overall external interface routines. > */ > int xfs_attr_inactive(struct xfs_inode *dp); > - > -int xfs_attr_shortform_getvalue(struct xfs_da_args *); > int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); > int xfs_attr_rmtval_get(struct xfs_da_args *args); > +int xfs_attr_list_int(struct xfs_attr_list_context *); > > #endif /* __XFS_ATTR_H__ */ > From owner-xfs@oss.sgi.com Thu Jun 5 09:15:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 09:15:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m55GFOkw021215 for ; Thu, 5 Jun 2008 09:15:24 -0700 X-ASG-Debug-ID: 1212682578-237e018c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8DF1E1EF9C8 for ; Thu, 5 Jun 2008 09:16:18 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.242]) by cuda.sgi.com with ESMTP id lOFMmqf1U2nVrM6M for ; Thu, 05 Jun 2008 09:16:18 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so621401rvb.32 for ; Thu, 05 Jun 2008 09:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1nvA+sW+LduydZAVQSuoPB1jqpguEjXfT+bRaNSsuhs=; b=p3lH35u7GQJU+qcw0JEsTP6s2yXLQxnI3Ecu3o1snY3euxXMSCJMcnQRkbElSPguWo f3NMuBKbv2W5Tqhx699Q9Eqv8Q2YEPtnuPkYkgZUegLrXdB3A7TnnVFvWLdtpx0ZUsxw NV1kY9PaRijJbsI2vRjUxChCgz8+uNh26tJvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=yF8pY0LhdWwt/hnVoKbJ+pv7iCJ44yDc/JdG18wx0mQmRco6oUW3iHplljxDTGpVDP 3twNFTjeV/VAm8FNPrI3MfvijZct5NPNrf54OZ+48xhHkexGk1D3gRz5Ws6m82ycByE/ cSIBEioUG+ntwqIm8+IdkjmI4ltQT2OwuO4v0= Received: by 10.141.129.14 with SMTP id g14mr1040209rvn.56.1212682577936; Thu, 05 Jun 2008 09:16:17 -0700 (PDT) Received: by 10.141.43.7 with HTTP; Thu, 5 Jun 2008 09:16:17 -0700 (PDT) Message-ID: <3607657a0806050916rd26b4f4tee83305644e66416@mail.gmail.com> Date: Thu, 5 Jun 2008 12:16:17 -0400 From: "Spam Magnet" To: "Stefan Smietanowski" X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed Cc: "Timothy Shimmin" , "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <4845A857.3090905@stesmi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> <4845949F.7080209@stesmi.com> <3607657a0806031239l6d788868u2f5654efcabf4abc@mail.gmail.com> <4845A857.3090905@stesmi.com> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.242] X-Barracuda-Start-Time: 1212682578 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52446 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16273 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs On Tue, Jun 3, 2008 at 4:23 PM, Stefan Smietanowski wrote: >> I think they are but I used -u option of fdisk: >> $ fdisk -ul jaz7.img >> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders >> Units = sectors of 1 * 512 bytes >> ----- partitions ----- >> Pt# Device Info Start End Sectors Id System >> 8: jaz7.img1 3072 2091007 2087936 a SGI xfs >> 9: jaz7.img2 0 3071 3072 0 SGI volhdr >> 11: jaz7.img3 0 2091007 2091008 6 SGI volume >> >> which lists partitions in sector units. As oppose to: >> >> $ fdisk -l jaz7.img >> >> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders >> Units = cylinders of 16065 * 512 bytes >> >> ----- partitions ----- >> Pt# Device Info Start End Sectors Id System >> 8: jaz7.img1 1 130 2087936 a SGI xfs >> 9: jaz7.img2 0 0 3072 0 SGI volhdr >> 11: jaz7.img3 0 130 2091008 6 SGI volume > > I'd give it a shot regardless as I don't remember if the sector size is > actually IN the partition table and if it's NOT then it'll show the > native blocksize of the device, which is 512bytes! > > Just try it, what do you have to lose? I mean do the od .. > Worst case you get garbage or zeroes. 3072*2048=6,291,456 (30000000 octal) $ od -t c jaz7.img | grep 30000000 30000000 377 377 367 371 \0 \0 0 365 \0 \0 ? y \0 \0 004 016 130000000 201 244 \0 001 \0 \0 \0 \0 \0 \0 006 201 B 373 306 307 So I guess that didn't work either :( From owner-xfs@oss.sgi.com Thu Jun 5 21:40:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 21:40:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m564eZ8V017276 for ; Thu, 5 Jun 2008 21:40:38 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA15868; Fri, 6 Jun 2008 14:41:12 +1000 Message-ID: <4848BFE8.6000205@sgi.com> Date: Fri, 06 Jun 2008 14:41:12 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr References: <20080603114837.GB2703@lst.de> In-Reply-To: <20080603114837.GB2703@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16274 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > > /* > * Then add the two synthetic ACL attributes. > @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_access(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_ACCESS, > strlen(POSIX_ACL_XATTR_ACCESS) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_default(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, > strlen(POSIX_ACL_XATTR_DEFAULT) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) Need to fix param type. re: static int list_one_attr(const char *name, const size_t len, void *data, size_t size, ssize_t *result) typedef struct xfs_attr_list_context { struct xfs_inode *dp; /* inode */ struct attrlist_cursor_kern *cursor; /* position in list */ char *alist; /* output buffer */ int seen_enough; /* T/F: seen enough of list? */ int count; /* num used entries */ => mismatch type on &context.count (int) and list_one_attr's result param (ssize_t => long) --Tim From owner-xfs@oss.sgi.com Thu Jun 5 22:08:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 22:08:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5658Bmr019276 for ; Thu, 5 Jun 2008 22:08:13 -0700 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 PAA16369; Fri, 6 Jun 2008 15:08:58 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 56FB758C4C3F; Fri, 6 Jun 2008 15:08:58 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 982930 - fix dir2 shortform structures on ARM old ABI Message-Id: <20080606050858.56FB758C4C3F@chook.melbourne.sgi.com> Date: Fri, 6 Jun 2008 15:08:58 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16275 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Pack some shortform dir2 structures for the ARM old ABI architecture. Finally put this in for Eric and the users of this arch. From Eric initially... This should fix the longstanding issues with xfs and old ABI arm boxes, which lead to various asserts and xfs shutdowns, and for which an (incorrect) patch has been floating around for years. I've verified this patch by comparing the on-disk structure layouts using pahole from the dwarves package, as well as running through a bit of xfsqa under qemu-arm, modified so that the check/repair phase after each test actually executes check/repair from the x86 host, on the filesystem populated by the arm emulator. Thus far it all looks good. There are 2 other structures with extra padding at the end, but they don't seem to cause trouble. I suppose they could be packed as well: xfs_dir2_data_unused_t and xfs_dir2_sf_t. Note that userspace needs a similar treatment, and any filesystems which were running with the previous rogue "fix" will now see corruption (either in the kernel, or during xfs_repair) with this fix properly in place; it may be worth teaching xfs_repair to identify and fix that specific issue. Signed-off-by: Eric Sandeen Date: Fri Jun 6 15:07:06 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31280a fs/xfs/xfs_dir2_sf.h - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h - Fix up some dir2 shortform structures for ARM using packing fs/xfs/linux-2.6/xfs_linux.h - 1.167 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.167&r2=text&tr2=1.166&f=h - setup __arch_pack for packing for ARM old ABI From owner-xfs@oss.sgi.com Thu Jun 5 22:16:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 22:16:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m565GqOp020200 for ; Thu, 5 Jun 2008 22:16:53 -0700 X-ASG-Debug-ID: 1212729466-61e8011f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BF1881FAC74 for ; Thu, 5 Jun 2008 22:17:47 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id 1tyQIL7Q5giYX6Zs for ; Thu, 05 Jun 2008 22:17:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIZjSEh5LFOM/2dsb2JhbACwGg X-IronPort-AV: E=Sophos;i="4.27,599,1204464600"; d="scan'208";a="127927529" Received: from ppp121-44-83-140.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.83.140]) by ipmail04.adl2.internode.on.net with ESMTP; 06 Jun 2008 14:47:44 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K4UKe-0002pt-Fz; Fri, 06 Jun 2008 15:17:44 +1000 Date: Fri, 6 Jun 2008 15:17:44 +1000 From: Dave Chinner To: Tim Shimmin Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 982930 - fix dir2 shortform structures on ARM old ABI Subject: Re: TAKE 982930 - fix dir2 shortform structures on ARM old ABI Message-ID: <20080606051744.GN10720@disturbed> Mail-Followup-To: Tim Shimmin , xfs@oss.sgi.com References: <20080606050858.56FB758C4C3F@chook.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080606050858.56FB758C4C3F@chook.melbourne.sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1212729467 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52497 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16276 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 06, 2008 at 03:08:58PM +1000, Tim Shimmin wrote: > Pack some shortform dir2 structures for the ARM old ABI architecture. > > Finally put this in for Eric and the users of this arch. Don't forget the matching userspace patch ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 5 22:43:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 22:43:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m565h3Z4021975 for ; Thu, 5 Jun 2008 22:43:03 -0700 X-ASG-Debug-ID: 1212731036-606502670000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E59F01FAD1B; Thu, 5 Jun 2008 22:43:56 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id VriOWPdB0f1OvzJ3; Thu, 05 Jun 2008 22:43:56 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m565hlOc029947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 6 Jun 2008 07:43:48 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m565hl0J029945; Fri, 6 Jun 2008 07:43:47 +0200 Date: Fri, 6 Jun 2008 07:43:47 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] simplify xfs_vn_listxattr Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr Message-ID: <20080606054347.GA29902@lst.de> References: <20080603114837.GB2703@lst.de> <4848BFE8.6000205@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4848BFE8.6000205@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212731037 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52497 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16277 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 06, 2008 at 02:41:12PM +1000, Timothy Shimmin wrote: > Need to fix param type. > > re: > > static int > list_one_attr(const char *name, const size_t len, void *data, > size_t size, ssize_t *result) > > typedef struct xfs_attr_list_context { > struct xfs_inode *dp; /* inode */ > struct attrlist_cursor_kern *cursor; /* position in list */ > char *alist; /* output buffer */ > int seen_enough; /* T/F: seen enough of list? */ > int count; /* num used entries */ > > => mismatch type on &context.count (int) and list_one_attr's result > param (ssize_t => long) Yes, didn't see that on my 32-bit machine :) count should probably be ssize_t. From owner-xfs@oss.sgi.com Fri Jun 6 06:34:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 06 Jun 2008 06:34:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m56DYM72001056 for ; Fri, 6 Jun 2008 06:34:23 -0700 X-ASG-Debug-ID: 1212759315-402502430000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from noire.bucharest.roedu.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C1FE7795692 for ; Fri, 6 Jun 2008 06:35:15 -0700 (PDT) Received: from noire.bucharest.roedu.net (noire.Bucharest.roedu.net [141.85.128.18]) by cuda.sgi.com with ESMTP id 53rrYf3nH5R9medZ for ; Fri, 06 Jun 2008 06:35:15 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (noire.bucharest.roedu.net [141.85.128.18]) (authenticated bits=0) by noire.bucharest.roedu.net (8.12.10/8.12.10) with ESMTP id m56CZSke018730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jun 2008 15:35:28 +0300 From: dizzy To: xfs@oss.sgi.com X-ASG-Orig-Subj: readdir() ordering guarantees on XFS Subject: readdir() ordering guarantees on XFS Date: Fri, 6 Jun 2008 16:34:13 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806061634.13990.dizzy@roedu.net> X-Barracuda-Connect: noire.Bucharest.roedu.net[141.85.128.18] X-Barracuda-Start-Time: 1212759316 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52528 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16278 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: xfs Hello POSIX leaves unspecified the order of getting the entries with readdir(). This is normal since different filesystems may implement their own techniques to organize entries in a directory (linear, hash, various search trees, etc). But if I can makes sure that several Linux machines will have the same FS (ie XFS), mount options and same kernels can assume that traversing the same file hierarchy structure (that is a file structure with the exact same directories and files as names, structure, attributes, except maybe "ctime" which we can't really control in Linux) can I expect that traversing using readdir() will give me the entries in the exact same order? Or are there any other conditions that I have to check for that would guarantee it? (such as, for a linear directory aproach one has to have created the directory entries in the same order on all the machines to expect same order on readdir()). Currently, we workaround this issue by reading all the directory entries, sorting them and traversing the entries in the sorted order. This however has been proven to slow the traversal (depth first traversal) operation about 30% than doing it in the order received from readdir() (I even had the test code read the whole directory contents, sort them in memory but still have it traverse in the order readdir() reported and it is 30% faster than traversing in the sorted order). Any idea? Thanks! PS: please Cc: me as I'm not subscribed to the list, thank you -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST From owner-xfs@oss.sgi.com Fri Jun 6 07:15:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 06 Jun 2008 07:15:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m56EF0cU004339 for ; Fri, 6 Jun 2008 07:15:00 -0700 X-ASG-Debug-ID: 1212761754-3780018f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F1F96C38D5A for ; Fri, 6 Jun 2008 07:15:54 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 8p5BrqQpSJFIIQZE for ; Fri, 06 Jun 2008 07:15:54 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 3EB5BA9C502; Fri, 6 Jun 2008 09:15:53 -0500 (CDT) Message-ID: <48494698.9080704@sandeen.net> Date: Fri, 06 Jun 2008 09:15:52 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs-oss CC: Barry Naujok X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <47E1D3C3.1050000@sandeen.net> In-Reply-To: <47E1D3C3.1050000@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212761754 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52532 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16279 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > Here's the userspace side. > Just a reminder after Dave's reminder. :) -Eric > -Eric > > > Index: xfs-cmds/xfsprogs/include/platform_defs.h.in > =================================================================== > --- xfs-cmds.orig/xfsprogs/include/platform_defs.h.in > +++ xfs-cmds/xfsprogs/include/platform_defs.h.in > @@ -147,4 +147,11 @@ typedef unsigned long long __psunsigned_ > | (minor&IRIX_DEV_MAXMIN))) > #define IRIX_DEV_TO_KDEVT(dev) makedev(IRIX_DEV_MAJOR(dev),IRIX_DEV_MINOR(dev)) > > +/* ARM old ABI has some weird alignment/padding */ > +#if defined(__arm__) && !defined(__ARM_EABI__) > +#define __arch_pack __attribute__((packed)) > +#else > +#define __arch_pack > +#endif > + > #endif /* __XFS_PLATFORM_DEFS_H__ */ > Index: xfs-cmds/xfsprogs/include/xfs_dir2_sf.h > =================================================================== > --- xfs-cmds.orig/xfsprogs/include/xfs_dir2_sf.h > +++ xfs-cmds/xfsprogs/include/xfs_dir2_sf.h > @@ -62,7 +62,7 @@ typedef union { > * Normalized offset (in a data block) of the entry, really xfs_dir2_data_off_t. > * Only need 16 bits, this is the byte offset into the single block form. > */ > -typedef struct { __uint8_t i[2]; } xfs_dir2_sf_off_t; > +typedef struct { __uint8_t i[2]; } __arch_pack xfs_dir2_sf_off_t; > > /* > * The parent directory has a dedicated field, and the self-pointer must > @@ -76,14 +76,14 @@ typedef struct xfs_dir2_sf_hdr { > __uint8_t count; /* count of entries */ > __uint8_t i8count; /* count of 8-byte inode #s */ > xfs_dir2_inou_t parent; /* parent dir inode number */ > -} xfs_dir2_sf_hdr_t; > +} __arch_pack xfs_dir2_sf_hdr_t; > > typedef struct xfs_dir2_sf_entry { > __uint8_t namelen; /* actual name length */ > xfs_dir2_sf_off_t offset; /* saved offset */ > __uint8_t name[1]; /* name, variable size */ > xfs_dir2_inou_t inumber; /* inode number, var. offset */ > -} xfs_dir2_sf_entry_t; > +} __arch_pack xfs_dir2_sf_entry_t; > > typedef struct xfs_dir2_sf { > xfs_dir2_sf_hdr_t hdr; /* shortform header */ > > > > > From owner-xfs@oss.sgi.com Fri Jun 6 11:32:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 06 Jun 2008 11:32:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m56IWQWF025675 for ; Fri, 6 Jun 2008 11:32:26 -0700 X-ASG-Debug-ID: 1212777199-425202d10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from defout.telus.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 378D417921B4 for ; Fri, 6 Jun 2008 11:33:19 -0700 (PDT) Received: from defout.telus.net (defout.telus.net [199.185.220.240]) by cuda.sgi.com with ESMTP id KuLPhha9m071OQmF for ; Fri, 06 Jun 2008 11:33:19 -0700 (PDT) Received: from priv-edtnaa04.telusplanet.net ([216.232.71.140]) by priv-edtnes25.telusplanet.net (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20080606183258.QPM16573.priv-edtnes25.telusplanet.net@priv-edtnaa04.telusplanet.net> for ; Fri, 6 Jun 2008 12:32:58 -0600 Received: from mail.zymeworks.com (s216-232-71-140.bc.hsia.telus.net [216.232.71.140]) by priv-edtnaa04.telusplanet.net (BorderWare MXtreme Infinity Mail Firewall) with ESMTP id D3G198CHK8 for ; Fri, 6 Jun 2008 12:33:18 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by mail.zymeworks.com (Postfix) with ESMTP id 4FD60756D2D for ; Fri, 6 Jun 2008 11:33:18 -0700 (PDT) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at zymeworks.com Received: from mail.zymeworks.com ([127.0.0.1]) by localhost (barista.lan.zymeworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elqEHuWEccG6 for ; Fri, 6 Jun 2008 11:33:17 -0700 (PDT) Received: from zubrowka.lan.zymeworks.com (zubrowka.lan.zymeworks.com [10.3.3.16]) by mail.zymeworks.com (Postfix) with ESMTP id DC29D756D22 for ; Fri, 6 Jun 2008 11:33:17 -0700 (PDT) Message-Id: From: Kamil Kisiel To: xfs@oss.sgi.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) X-ASG-Orig-Subj: XFS and block-level snapshots Subject: XFS and block-level snapshots Date: Fri, 6 Jun 2008 11:33:17 -0700 X-Mailer: Apple Mail (2.919.2) X-Barracuda-Connect: defout.telus.net[199.185.220.240] X-Barracuda-Start-Time: 1212777200 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52549 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16280 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kamil@zymeworks.com Precedence: bulk X-list: xfs Hello, I had a question about XFS integrity and performing block-level snapshots. We currently have a 2TB (but growing soon..) volume mounted by a Linux host with kernel 2.6.23 over iSCSI from our SAN. Our SAN unit has the capability to perform block-level snapshots, which is done at regular intervals. I know that it is recommended to perform an xfs_freeze before performing a snapshot. However, the control of the snapshots is independent from the OS, which currently has no knowledge of their occurrence. I'm curious as to the repercussions of this. I understand that in all likelyhood, the integrity of files which are currently being written will not be preserved. However, even with an xfs_freeze this is not guaranteed, as an application may require additional disk transactions to maintain the file in a valid state (it is not necessarily atomic, depending on the application). As far as metadata transactions are concerned, the journal should make these atomic, so there should not be any problem there? Basically, I'd like to know what is the worst that could happen, and why an xfs_freeze is necessary in this scenario. ____________ Kamil Kisiel HPC Systems Engineer, Zymeworks Inc. 201-1401 West Broadway, Vancouver, BC, V6H 1H6, Canada Tel: (604) 678-1388 ext. 135 Fax: (604) 737-7077 www.zymeworks.com From owner-xfs@oss.sgi.com Sat Jun 7 16:02:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 07 Jun 2008 16:02:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m57N21R7031052 for ; Sat, 7 Jun 2008 16:02:03 -0700 X-ASG-Debug-ID: 1212879775-47cf01bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DAFC1C4F4F2 for ; Sat, 7 Jun 2008 16:02:55 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id RsNjyUSUWOwLgSPF for ; Sat, 07 Jun 2008 16:02:55 -0700 (PDT) Received: (qmail 9474 invoked from network); 7 Jun 2008 23:02:54 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Jun 2008 23:02:54 -0000 Message-ID: <484B15A3.4030505@sauce.co.nz> Date: Sun, 08 Jun 2008 11:11:31 +1200 From: Richard Scobie 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: xfs@oss.sgi.com X-ASG-Orig-Subj: Filestreams Subject: Filestreams Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1212879776 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0041 1.0000 -1.9945 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.99 X-Barracuda-Spam-Status: No, SCORE=-1.99 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52662 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16281 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Is my understanding of filestreams correct, in that files written to a particular filestreams enabled directory are all allocated to 1 ag as long as the filestreams timeout is not exceeded - which I believe is 30s? In other words, if I copy 100 files into a directory, (cp -a dir_containing_100_files dest_dir), wait 60 seconds and do (cp -a dir_containing_100_different_files dest_dir), each directory and contents in dest_dir will be stored in a single, different ag? Also, would it be possible for the filestreams parameter to be added to man pages/kernel docs? Thanks, Richard From owner-xfs@oss.sgi.com Sun Jun 8 20:30:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jun 2008 20:30:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m593UsUp010343 for ; Sun, 8 Jun 2008 20:30:54 -0700 X-ASG-Debug-ID: 1212982309-688502960000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D212AC565FE for ; Sun, 8 Jun 2008 20:31:49 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id FbRvyiIC497OGmcW for ; Sun, 08 Jun 2008 20:31:49 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E9A17A9BF46; Sun, 8 Jun 2008 22:31:46 -0500 (CDT) Message-ID: <484CA425.3080606@sandeen.net> Date: Sun, 08 Jun 2008 22:31:49 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Richard Scobie CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams Subject: Re: Filestreams References: <484B15A3.4030505@sauce.co.nz> In-Reply-To: <484B15A3.4030505@sauce.co.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212982309 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52775 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16282 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Richard Scobie wrote: > Is my understanding of filestreams correct, in that files written to a > particular filestreams enabled directory are all allocated to 1 ag as > long as the filestreams timeout is not exceeded - which I believe is 30s? > > In other words, if I copy 100 files into a directory, (cp -a > dir_containing_100_files dest_dir), wait 60 seconds and do (cp -a > dir_containing_100_different_files dest_dir), each directory and > contents in dest_dir will be stored in a single, different ag? > > Also, would it be possible for the filestreams parameter to be added to > man pages/kernel docs? Yes please :) I was just noticing last week that there is no documentation anywhere on this feature .... -Eric > Thanks, > > Richard > > From owner-xfs@oss.sgi.com Mon Jun 9 08:00:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 08:00:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_05,J_CHICKENPOX_210, MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m59F09O1026558 for ; Mon, 9 Jun 2008 08:00:10 -0700 X-ASG-Debug-ID: 1213023663-1f41027a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server515.appriver.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DDFA7C58DC8 for ; Mon, 9 Jun 2008 08:01:03 -0700 (PDT) Received: from server515.appriver.com (server515d.exghost.com [72.32.253.78]) by cuda.sgi.com with ESMTP id CH1yGFQfOjeM7iCl for ; Mon, 09 Jun 2008 08:01:03 -0700 (PDT) Received: by server515.appriver.com (CommuniGate Pro PIPE 5.2.0) with PIPE id 40013683; Mon, 09 Jun 2008 10:00:55 -0500 Received: from FE1.exchange.rackspace.com ([72.32.49.5] verified) by server515.appriver.com (CommuniGate Pro SMTP 5.2.0) with ESMTP id 40013576; Mon, 09 Jun 2008 10:00:53 -0500 Received: from 34093-C3-EVS3.exchange.rackspace.com ([192.168.1.161]) by FE1.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 10:00:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-ASG-Orig-Subj: RE: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Subject: RE: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Date: Mon, 9 Jun 2008 09:56:14 -0500 Message-ID: In-Reply-To: <20080609142717.GB24950@rap.rap.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Thread-Index: AcjKPO3cniFd2lezSOGBLh6Tu+5cDgAAFrqA References: <8CA981CB5C2B4D6-E68-18E2@MBLK-M14.sysops.aol.com> <20080609142717.GB24950@rap.rap.dk> From: "David Lethe" To: =?iso-8859-1?Q?Keld_J=F8rn_Simonsen?= Cc: , , , , , , X-OriginalArrivalTime: 09 Jun 2008 15:00:58.0795 (UTC) FILETIME=[A01C3FB0:01C8CA41] X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Primary: david@santools.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: david@santools.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.5 X-Note-Reverse-DNS: fe1.exchange.rackspace.com X-Note-WHTLIST: david@santools.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 81 82 148 X-Note: Mail Class: ALLOWEDSENDER X-Barracuda-Connect: server515d.exghost.com[72.32.253.78] X-Barracuda-Start-Time: 1213023664 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.75 X-Barracuda-Spam-Status: No, SCORE=-1.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52821 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m59F0AO1026563 X-archive-position: 16283 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@santools.com Precedence: bulk X-list: xfs -----Original Message----- From: Keld Jørn Simonsen [mailto:keld@dkuug.dk] Sent: Monday, June 09, 2008 9:27 AM To: David Lethe Cc: thomas62186218@aol.com; dan.j.williams@gmail.com; jpiszcz@lucidpixels.com; linux-kernel@vger.kernel.org; linux-raid@vger.kernel.org; xfs@oss.sgi.com; ap@solarrain.com Subject: Re: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors On Mon, Jun 09, 2008 at 08:41:18AM -0500, David Lethe wrote: > For faster random I/O: > * Decrease chunk size > * Migrate files that have higher random I/O to a RAID1 set, using disks > with the lowest access time/latency > * If possible, use the /dev/shm file system > * Determine I/O size of apps that produce most of the random I/O, and > make sure that md+filesystem matches. If most random I/O is 32KB, then > don't waste bandwidth by making md read 256KB at a time, or making it > read 2x16KB I/Os. Also don't build md sets like 4-drive RAID5, (Do a > 5-drive RAID5 set), because non-parity data isn't a multiple of 2. A > 10-drive RAID5 set with heavy random I/O is also profoundly wrong > because you are just removing the opportunity to have all of those heads > processing random I/O. > * If you only have one partition on a md set, then partition it into a > few file systems. This may provide greater opportunity for caching I/Os. > * Experiment with different file systems, and optimize accordingly. > * Turn of journaling, or at least move journals to RAID1 devices. > * Add RAM and try to increase buffer cache in attempt to improve cache > hit percentage (this works up to a point) > * Buy a small SSD and migrate files that get pounded with random I/O to > that device. (Make sure you don't get a flash SSD, but a DRAM based SSD > that satisfies random I/O in nanoseconds instead of millisecs). They are > expensive, but the appropriate device. This is how companies such as > Google & Ebay manage to get things done. > The biggest thing to remember about random I/O, is that they are > expensive, so just step back and think about ways to minimize the I/O > requests to disk in the first place, and/or to spread the I/O across > multiple raidsets that can work independently to satisfy your load. All > suggestions above will not work for everybody. You must understand the > nature of the bottleneck. For faster random IO I would suggest to use raid10,f2 for the random reading, it performs like raid0, something like more than double the speed of a normal single-drive file system. For random writes raid10,f2 performs like most other mirrorred raids, given that data needs to be written twice. Try and see if you can gat any HW raids to match that performance. best regards keld -------------------------------------------------------------------------------- Keld: That is counter-intuitive. The issue is random IOPs, not throughput. I do not understand how a RAID10 would provide more IOs per sec than RAID1. Or, since you are using RAID10, then how could RAID10 serve more random I/Os then a pair of RAID1 filesystems? RAID0 dictates that each disk will supply half of the data you want per application I/O request. At least with RAID1, then each disk can get all the data you want with a single request, and dual-porting/load balancing will allow both disks to work independently of each other on reads so the disk with the least amount of load at any time can work on the request. That is why RAID1 can be faster than JBOD. Granted writes are handled differently, but with any RAID0 implementation you still have to write Half of the data to each disk requiring 2 I/Os + journaling & housekeeping. David From owner-xfs@oss.sgi.com Mon Jun 9 16:14:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 16:14:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m59NEXIX014612 for ; Mon, 9 Jun 2008 16:14:34 -0700 X-ASG-Debug-ID: 1213053327-163701be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rap.rap.dk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6B628209C79 for ; Mon, 9 Jun 2008 16:15:28 -0700 (PDT) Received: from rap.rap.dk (213.237.47.228.adsl.vbr.worldonline.dk [213.237.47.228]) by cuda.sgi.com with ESMTP id G1yVpgj8JMWGBnAU for ; Mon, 09 Jun 2008 16:15:28 -0700 (PDT) Received: by rap.rap.dk (Postfix, from userid 500) id 0923D64754; Tue, 10 Jun 2008 01:15:26 +0200 (CEST) Date: Tue, 10 Jun 2008 01:15:26 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: David Lethe Cc: thomas62186218@aol.com, dan.j.williams@gmail.com, jpiszcz@lucidpixels.com, linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com, ap@solarrain.com X-ASG-Orig-Subj: Re: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Subject: Re: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Message-ID: <20080609231526.GA6404@rap.rap.dk> References: <8CA981CB5C2B4D6-E68-18E2@MBLK-M14.sysops.aol.com> <20080609142717.GB24950@rap.rap.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.11 X-Barracuda-Connect: 213.237.47.228.adsl.vbr.worldonline.dk[213.237.47.228] X-Barracuda-Start-Time: 1213053329 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.65 X-Barracuda-Spam-Status: No, SCORE=-1.65 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52852 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16284 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: keld@dkuug.dk Precedence: bulk X-list: xfs On Mon, Jun 09, 2008 at 09:56:14AM -0500, David Lethe wrote: > > > From: Keld Jørn Simonsen [mailto:keld@dkuug.dk] > Sent: Monday, June 09, 2008 9:27 AM > To: David Lethe > Cc: thomas62186218@aol.com; dan.j.williams@gmail.com; jpiszcz@lucidpixels.com; linux-kernel@vger.kernel.org; linux-raid@vger.kernel.org; xfs@oss.sgi.com; ap@solarrain.com > Subject: Re: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors > > For faster random IO I would suggest to use raid10,f2 for the random > reading, it performs like raid0, something like more than double the > speed of a normal single-drive file system. For random writes raid10,f2 > performs like most other mirrorred raids, given that data needs to be > written twice. > > Try and see if you can gat any HW raids to match that performance. > > best regards > keld > > -------------------------------------------------------------------------------- > Keld: > That is counter-intuitive. The issue is random IOPs, not throughput. That probably depends on your use. I run Linux mirrors, and for that purpose thruputi of random IO, especially reading, is key. For data bases it is probably something else, probably IOP. here I also think that Linux MD raid has good performance. Once again I think my pet RAID type, raid10,f2 has something to offer, especially with lower random seek rates, as the track span is shorter, and on the outer, faster tracks. And other uses may have other bottlenecks. In general I think that thruput is an important figure, as it shows how fast a system can process a given amount of data. Areas where this may count include web servers, file servers, print servers, ordinary workstations. I actually think those 2 measures for random IO: IO thruput, and IO transactions per second, for read and write, are the two most important measures. For the IO transacions per second I agree that your suggestions are good advice. I would like to have good benchmarking tools for this, and also I would like figures on how Linux MD compares to different HW RAID. > I do not > understand how a RAID10 would provide more IOs per sec than RAID1. Or, since > you are using RAID10, then how could RAID10 serve more random I/Os then a pair > of RAID1 filesystems? In theory you are right. The MD implementation of RAID1 does not seem to handle random seeks so well, AFAIK. Then the seeks are confined with raid10,f2 to less than half of the disk arm movement, taht does speed things up a little. > RAID0 dictates that each disk will supply half > of the data you want per application I/O request. At least with RAID1, then each > disk can get all the data you want with a single request, and dual-porting/load balancing > will allow both disks to work independently of each other on reads so the disk with > the least amount of load at any time can work on the request. That is why RAID1 can be > faster than JBOD. > > Granted writes are handled differently, but with any RAID0 implementation you still have to write > Half of the data to each disk requiring 2 I/Os + journaling & housekeeping. yes, indeed. best regards keld From owner-xfs@oss.sgi.com Mon Jun 9 18:48:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 18:49:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5A1mr3e001523 for ; Mon, 9 Jun 2008 18:48:55 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11522; Tue, 10 Jun 2008 11:49:39 +1000 Message-ID: <484DDDB3.70000@sgi.com> Date: Tue, 10 Jun 2008 11:49:39 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Eric Sandeen , Richard Scobie CC: xfs@oss.sgi.com Subject: Re: Filestreams References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> In-Reply-To: <484CA425.3080606@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16285 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Richard Scobie wrote: >> Is my understanding of filestreams correct, in that files written to a >> particular filestreams enabled directory are all allocated to 1 ag as >> long as the filestreams timeout is not exceeded - which I believe is 30s? >> >> In other words, if I copy 100 files into a directory, (cp -a >> dir_containing_100_files dest_dir), wait 60 seconds and do (cp -a >> dir_containing_100_different_files dest_dir), each directory and >> contents in dest_dir will be stored in a single, different ag? >> >> Also, would it be possible for the filestreams parameter to be added to >> man pages/kernel docs? > > Yes please :) I was just noticing last week that there is no > documentation anywhere on this feature .... > > -Eric > >> Thanks, >> >> Richard >> >> > Sounds a reasonable idea :) BTW, Sam Vaughan wrote some tutorial notes on the allocator and in particular filestreams which I've pasted below: (I thought it might be here: http://oss.sgi.com/projects/xfs/training/ but I can't see it in the allocator lab and slides). ------------------------------------------------------------------------- Filestreams Allocator A certain class of applications such as those doing film scanner video ingest will write many large files to a directory in sequence. It's important for playback performance that these files end up allocated next to each other on disk, since consecutive data is retrieved optimally by hardware RAID read-ahead. XFS's standard allocator starts out doing the right thing as far as file allocation is concerned. Even if multiple streams are being written simultaneously, their files will be placed separately and contiguously on disk. The problem is that once an allocation group fills up, a new one must be chosen and there's no longer a parent directory in a unique AG to use as an AG "owner". Without a way to reserve the new AG for the original directory's use, all the files being allocated by all the streams will start getting placed in the same AGs as each other. The result is that consecutive frames in one directory are placed on disk with frames from other directories interleaved between them, which is a worst-case layout for playback performance. When reading back the frames in directory A, hardware RAID read-ahead will cache data from frames in directory B which is counterproductive. Create a file system with a small AG size to demonstrate: sles10:~ sjv: sudo mkfs.xfs -d agsize=64m /dev/sdb7 > /dev/null sles10:~ sjv: sudo mount /dev/sdb7 /test sles10:~ sjv: sudo chmod 777 /test sles10:~ sjv: cd /test sles10:/test sjv: Create ten 10MB files concurrently in two directories: sles10:/test sjv: mkdir a b sles10:/test sjv: for dir in a b; do > for file in `seq 0 9`; do > xfs_mkfile 10m $dir/$file > done & > done; wait 2>/dev/null [1] 30904 [2] 30905 sles10:/test sjv: ls -lid * */* 131 drwxr-xr-x 2 sjv users 86 2006-10-20 13:48 a 132 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/0 133 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/1 134 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/2 135 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/3 136 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/4 137 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/5 138 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/6 139 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/7 140 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/8 141 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/9 262272 drwxr-xr-x 2 sjv users 86 2006-10-20 13:48 b 262273 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/0 262274 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/1 262275 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/2 262276 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/3 262277 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/4 262278 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/5 262279 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/6 262280 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/7 262281 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/8 262282 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/9 sles10:/test sjv: Note that all the inodes are in the same AGs as each other. What about the file data? Use xfs_bmap -v to examine the extents: sles10:/test sjv: for file in `seq 0 9`; do > bmap_a=`xfs_bmap -v a/$file | tail -1` > bmap_b=`xfs_bmap -v b/$file | tail -1` > ag_a=`echo $bmap_a | awk '{print $4}'` > ag_b=`echo $bmap_b | awk '{print $4}'` > br_a=`echo $bmap_a | awk '{printf "%-18s", $3}'` > br_b=`echo $bmap_b | awk '{printf "%-18s", $3}'` > echo a/$file: $ag_a "$br_a" b/$file: $ag_b "$br_b" > done a/0: 0 96..20575 b/0: 1 131168..151647 a/1: 0 20576..41055 b/1: 1 151648..172127 a/2: 0 41056..61535 b/2: 1 172128..192607 a/3: 0 61536..82015 b/3: 1 192608..213087 a/4: 0 82016..102495 b/4: 1 213088..233567 a/5: 0 102496..122975 b/5: 1 233568..254047 a/6: 2 299600..300111 b/6: 2 262208..275007 a/7: 2 338016..338527 b/7: 2 312400..312911 a/8: 2 344672..361567 b/8: 3 393280..401983 a/9: 2 361568..382047 b/9: 3 401984..421951 sles10:/test sjv: The middle column is the AG number and the right column is the block range. Note how the extents for files in both directories get placed on top of each other in AG 2. Something to note in the results is that even though the file extents have worked their way up into AGs 2 and 3, the inode numbers show that the file inodes are all in the same AGs as their parent directory, i.e. AGs 0 and 1. Why is this? To understand, it's important to consider the order in which events are occurring. The two bash processes writing files are calling xfs_mkfile, which starts by opening a file with the O_CREAT flag. At this point, XFS has no idea how large the file's data is going to be, so it dutifully creates a new inode for the file in the same AG as the parent directory. The call returns successfully and the system continues with its tasks. When XFS is asked write the file data a short time later, a new AG must be found for it because the AG the inode is in is full. The result is a violation of the original goal to keep file data close to its inode on disk. In practice, because inodes are allocated in clusters on disk, a process that's reading back a stream is likely to cache all the inodes it needs with just one or two reads, so the disk seeking involved won't be as bad as it first seems. On the other hand, the extent data placement seen in the xfs_bmap -v output is a problem. Once the data extents spilled into AG 2, both processes were given allocations there on a first-come-first-served basis. This destroyed the neatly contiguous allocation pattern for the files and will certainly degrade read performance later on. To address this issue, a new allocation algorithm was added to XFS that associates a parent directory with an AG until a preset inactivity timeout elapses. The new algorithm is called the Filestreams allocator and it is enabled in one of two ways. Either the filesystem is mounted with the -o filestreams option, or the filestreams chattr flag is applied to a directory to indicate that all allocations beneath that point in the directory hierarchy should use the filestreams allocator. With the filestreams allocator enabled, the above test produces results that look like this: a/0: 0 96..20575 b/0: 1 131168..151647 a/1: 0 20576..41055 b/1: 1 151648..172127 a/2: 0 41056..61535 b/2: 1 172128..192607 a/3: 0 61536..82015 b/3: 1 192608..213087 a/4: 0 82016..102495 b/4: 1 213088..233567 a/5: 0 102496..122975 b/5: 1 233568..254047 a/6: 2 272456..273479 b/6: 3 393280..410271 a/7: 2 290904..300119 b/7: 3 410272..426655 a/8: 2 300632..321111 b/8: 3 426656..441503 a/9: 2 329304..343639 b/9: 3 441504..459935 Once the process writing files to the first directory starts using AG 2, that AG is no longer considered available so the other process skips it and moves to AG 3. --------------------------------- From owner-xfs@oss.sgi.com Mon Jun 9 19:04:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 19:04:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A24ApF003235 for ; Mon, 9 Jun 2008 19:04:11 -0700 X-ASG-Debug-ID: 1213063503-2bdb03b40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3DCC5C4FDB0 for ; Mon, 9 Jun 2008 19:05:03 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id vD5pLCe2Uom2ku3u for ; Mon, 09 Jun 2008 19:05:03 -0700 (PDT) Received: (qmail 19519 invoked from network); 10 Jun 2008 02:05:01 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Jun 2008 02:05:01 -0000 Message-ID: <484DE36A.2090903@sauce.co.nz> Date: Tue, 10 Jun 2008 14:14:02 +1200 From: Richard Scobie 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: Timothy Shimmin CC: Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams Subject: Re: Filestreams References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> In-Reply-To: <484DDDB3.70000@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1213063505 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52865 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16286 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Timothy Shimmin wrote: > BTW, Sam Vaughan wrote some tutorial notes on the allocator and in particular > filestreams which I've pasted below: Thanks Timothy, much appreciated. Regards, Richard From owner-xfs@oss.sgi.com Mon Jun 9 20:50:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 20:50:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_26 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A3oSBe018960 for ; Mon, 9 Jun 2008 20:50:30 -0700 X-ASG-Debug-ID: 1213069883-174901020000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 70B1D20A6EC for ; Mon, 9 Jun 2008 20:51:23 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id 8SjssLJ1o3WLvZ1w for ; Mon, 09 Jun 2008 20:51:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEhxTUh5LFOM/2dsb2JhbACwMw X-IronPort-AV: E=Sophos;i="4.27,615,1204464600"; d="scan'208";a="130250911" Received: from ppp121-44-83-140.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.83.140]) by ipmail04.adl2.internode.on.net with ESMTP; 10 Jun 2008 13:21:20 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K5utD-0003co-2R; Tue, 10 Jun 2008 13:51:19 +1000 Date: Tue, 10 Jun 2008 13:51:19 +1000 From: Dave Chinner To: Kamil Kisiel Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and block-level snapshots Subject: Re: XFS and block-level snapshots Message-ID: <20080610035119.GY10720@disturbed> Mail-Followup-To: Kamil Kisiel , xfs@oss.sgi.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1213069884 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4774 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16287 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 06, 2008 at 11:33:17AM -0700, Kamil Kisiel wrote: > Hello, > > I had a question about XFS integrity and performing block-level > snapshots. > > We currently have a 2TB (but growing soon..) volume mounted by a Linux > host with kernel 2.6.23 over iSCSI from our SAN. Our SAN unit has the > capability to perform block-level snapshots, which is done at regular > intervals. > > I know that it is recommended to perform an xfs_freeze before performing > a snapshot. However, the control of the snapshots is independent from the > OS, which currently has no knowledge of their occurrence. I'm curious as > to the repercussions of this. I understand that in all likelyhood, the > integrity of files which are currently being written will not be > preserved. However, even with an xfs_freeze this is not guaranteed, as an > application may require additional disk transactions to maintain the file > in a valid state (it is not necessarily atomic, depending on the > application). That's from an application POV, not a filesystem POV. When you freeze the filesystem all the data and metadata is guaranteed to be consistent on disk. If your application requires further guarantees of atomicity, then it needs to call xfs_freeze at a time that the application can guarantee that it'sstate in the filesystem is consistent. i.e. not a filesystem problem. > As far as metadata transactions are concerned, the journal should > make these atomic, so there should not be any problem there? Sure, asssuming that at the time the snapshot is taken that the sum of the journal contents, the filesystem metadata on disk and the data on disk = a consistent filesystem image. Which, of course, will never happen when you randomly snapshot a busy filesystem as it's a constantly moving target. e.g. say that while the log is being snapshotted by the block device it wraps (i.e. the head moves from the end to the start) and metadata I/O completes so the tail moves forward. now you have a snapshot with the old tail in it and you've lost the transactions at the head of the log. i.e. the journal is no longer consistent with what is on disk in the snapshot. This can happen for data vs metadata, metadata vs metadata and metadata vs log. IOWs, if you don't freeze before you snapshot, your snapshot if full of nasty little inconsistencies just waiting to trip you over.... > Basically, I'd like to know what is the worst that could happen, and why > an xfs_freeze is necessary in this scenario. Worst case? Silent data corruption in the snapshot. Metadata corruption in the snapshot leading to filesystem shutdowns and system panics. Choose your poison - they're all bad. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Mon Jun 9 20:55:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 20:55:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A3t1in019648 for ; Mon, 9 Jun 2008 20:55:05 -0700 X-ASG-Debug-ID: 1213070155-27bc00850000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 42BFA17A497D for ; Mon, 9 Jun 2008 20:55:55 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id aqZtYbTE8GsHSMzd for ; Mon, 09 Jun 2008 20:55:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEhxTUh5LFOM/2dsb2JhbACwMw X-IronPort-AV: E=Sophos;i="4.27,615,1204464600"; d="scan'208";a="130253736" Received: from ppp121-44-83-140.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.83.140]) by ipmail04.adl2.internode.on.net with ESMTP; 10 Jun 2008 13:25:48 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K5uxX-0003ie-Cn; Tue, 10 Jun 2008 13:55:47 +1000 Date: Tue, 10 Jun 2008 13:55:47 +1000 From: Dave Chinner To: dizzy Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: readdir() ordering guarantees on XFS Subject: Re: readdir() ordering guarantees on XFS Message-ID: <20080610035547.GZ10720@disturbed> Mail-Followup-To: dizzy , xfs@oss.sgi.com References: <200806061634.13990.dizzy@roedu.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806061634.13990.dizzy@roedu.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1213070157 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16288 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 06, 2008 at 04:34:13PM +0300, dizzy wrote: > Hello > > POSIX leaves unspecified the order of getting the entries with readdir(). This > is normal since different filesystems may implement their own techniques to > organize entries in a directory (linear, hash, various search trees, etc). > > But if I can makes sure that several Linux machines will have the same FS (ie > XFS), mount options and same kernels can assume that traversing the same file > hierarchy structure (that is a file structure with the exact same directories > and files as names, structure, attributes, except maybe "ctime" which we > can't really control in Linux) can I expect that traversing using readdir() > will give me the entries in the exact same order? No. For speed I suggest sorting the inode stat() calls in ascending inode number order before issuing them. Also, perhaps you should look at: http://oss.oracle.com/~mason/acp/ To see if you can use similar techniques to speed directory traversal. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 10 01:19:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 01:19:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A8JZde021178 for ; Tue, 10 Jun 2008 01:19:37 -0700 X-ASG-Debug-ID: 1213086029-6e7b02d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from noire.bucharest.roedu.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DA91617A50D9 for ; Tue, 10 Jun 2008 01:20:30 -0700 (PDT) Received: from noire.bucharest.roedu.net (noire.Bucharest.roedu.net [141.85.128.18]) by cuda.sgi.com with ESMTP id lpOH5nNvvsteBNn7 for ; Tue, 10 Jun 2008 01:20:30 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (noire.bucharest.roedu.net [141.85.128.18]) (authenticated bits=0) by noire.bucharest.roedu.net (8.12.10/8.12.10) with ESMTP id m5A7KVke027013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2008 10:20:32 +0300 From: dizzy To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: readdir() ordering guarantees on XFS Subject: Re: readdir() ordering guarantees on XFS Date: Tue, 10 Jun 2008 11:20:27 +0300 User-Agent: KMail/1.9.9 References: <200806061634.13990.dizzy@roedu.net> <20080610035547.GZ10720@disturbed> In-Reply-To: <20080610035547.GZ10720@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806101120.27473.dizzy@roedu.net> X-Barracuda-Connect: noire.Bucharest.roedu.net[141.85.128.18] X-Barracuda-Start-Time: 1213086030 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52892 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16289 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: xfs On Tuesday 10 June 2008 06:55:47 Dave Chinner wrote: > On Fri, Jun 06, 2008 at 04:34:13PM +0300, dizzy wrote: > > Hello > > > > POSIX leaves unspecified the order of getting the entries with readdir(). > > This is normal since different filesystems may implement their own > > techniques to organize entries in a directory (linear, hash, various > > search trees, etc). > > > > But if I can makes sure that several Linux machines will have the same FS > > (ie XFS), mount options and same kernels can assume that traversing the > > same file hierarchy structure (that is a file structure with the exact > > same directories and files as names, structure, attributes, except maybe > > "ctime" which we can't really control in Linux) can I expect that > > traversing using readdir() will give me the entries in the exact same > > order? > > No. For speed I suggest sorting the inode stat() calls in ascending > inode number order before issuing them. But this does not solve the main requirement, that is the files traversed on the multiple Linux machines have to be sent in the same order (not sure if I have specified this in the original mesage, sorry if not). For now I'm sorting them lexicographically which is pretty slow. Sorting them by inode would not give them in the same order. > Also, perhaps you should > look at: > > http://oss.oracle.com/~mason/acp/ > > To see if you can use similar techniques to speed directory > traversal. Funny that you mention acp. We have benchmarked simple "tar" reading and "acp" reading of directory structures and on XFS "tar" reading is faster (but not on ext3), here are some results (reading a linux kernel tree after a flush of the cache by "tar"-ing a huge ammount of data, double the memory size): - xfs: acp: 1m32s, tar: 1m12s - ext3: acp: 0m1.5s, tar: 0m2.8s Although in the test ext3 seems to be much faster than XFS overall in reading, it isn't so in writing so we will stick with XFS as it's fast enough for reading and fast for writing. Anyway that is another topic. We still have that ordering issues tho from the original message :) -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST From owner-xfs@oss.sgi.com Tue Jun 10 02:44:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 02:44:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A9iHxm030278 for ; Tue, 10 Jun 2008 02:44:17 -0700 X-ASG-Debug-ID: 1213091112-5dd701b30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from noire.bucharest.roedu.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3602C67F73 for ; Tue, 10 Jun 2008 02:45:12 -0700 (PDT) Received: from noire.bucharest.roedu.net (noire.Bucharest.roedu.net [141.85.128.18]) by cuda.sgi.com with ESMTP id pWTraRRQU9Z3Xu8w for ; Tue, 10 Jun 2008 02:45:12 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (noire.bucharest.roedu.net [141.85.128.18]) (authenticated bits=0) by noire.bucharest.roedu.net (8.12.10/8.12.10) with ESMTP id m5A8jFke009342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2008 11:45:15 +0300 From: dizzy To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS directory entries sort order Subject: XFS directory entries sort order Date: Tue, 10 Jun 2008 12:45:09 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806101245.09950.dizzy@roedu.net> X-Barracuda-Connect: noire.Bucharest.roedu.net[141.85.128.18] X-Barracuda-Start-Time: 1213091113 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52897 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16290 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: xfs Hello Can someone tell me (in English or C :) ) the algorithm of the sorting order of the entries in an XFS directory as I would get them with a readdir() (or shell "find" command)? I am trying to figure it out by reading linux/fs/xfs/xfs_dir2*.c code but I don't seem to be doing much progress and I was hoping maybe someone that knows these details can help. Thank you! -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST From owner-xfs@oss.sgi.com Tue Jun 10 04:25:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 04:25:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ABPjjd012875 for ; Tue, 10 Jun 2008 04:25:45 -0700 X-ASG-Debug-ID: 1213097200-371f00c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 81846C69100 for ; Tue, 10 Jun 2008 04:26:40 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by cuda.sgi.com with ESMTP id SH34tlRalyuGMQZH for ; Tue, 10 Jun 2008 04:26:40 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1857399fgb.8 for ; Tue, 10 Jun 2008 04:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=c8CT0UDvCgdQe2uE1zFiCwyWqEJCDNeCKY8lOu4dedk=; b=Sfoqidgn/YONSybSWUWg1SoKNo6C/POizQNms8qnZc0EsBtEKlBoTv2GAP+JqUopaf Qz8EyFeHsoacWoc+JB6wr9L1FNGmvmMR+MQ+NgjKvO/zlUlWj58xjocoXldvA8RlivI4 tdMT53Nhloaq09cvatcNtTygFs84wh04kSI1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=UMGvmp/KlEfUwV1VlgBOxUrL01ilX8Y5NvE3KSeAy4kNapA7vS4WZwTA8MEcmLRS3t d7Ugba3dIpA+obD5CEHgybV5Jg2nOo5c75C5F8fX3LRFJJMgMYsnpZES/0b2tB1861aQ UWDtC3WjzcxWVU8PUXj3Yb5GQ9GOLsUyZ9PVI= Received: by 10.86.33.10 with SMTP id g10mr5563673fgg.15.1213097199844; Tue, 10 Jun 2008 04:26:39 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Tue, 10 Jun 2008 04:26:39 -0700 (PDT) Message-ID: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> Date: Tue, 10 Jun 2008 13:26:39 +0200 From: "Oliver Pinter" To: xfs@oss.sgi.com X-ASG-Orig-Subj: [XFS] oss.sgi Subject: [XFS] oss.sgi MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.155] X-Barracuda-Start-Time: 1213097201 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3604 1.0000 -0.1170 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.12 X-Barracuda-Spam-Status: No, SCORE=-0.12 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52903 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16291 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs Hi All! is the http://oss.sgi.com/projects/xfs/ site up to date? -- Thanks, Oliver From owner-xfs@oss.sgi.com Tue Jun 10 04:28:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 04:28:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_05,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ABSKZv013347 for ; Tue, 10 Jun 2008 04:28:20 -0700 X-ASG-Debug-ID: 1213097354-372100d50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.brightcove.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 43BC9C69123 for ; Tue, 10 Jun 2008 04:29:14 -0700 (PDT) Received: from mail.brightcove.com (mail.brightcove.com [38.113.27.188]) by cuda.sgi.com with ESMTP id 0eJF0xAb65aWKsV0 for ; Tue, 10 Jun 2008 04:29:14 -0700 (PDT) Received: from bcmail1.VIDMARK.LOCAL ([172.20.0.82]) by bcmail1.VIDMARK.LOCAL ([172.20.0.82]) with mapi; Tue, 10 Jun 2008 07:28:26 -0400 From: Lance Reed To: "'xfs@oss.sgi.com'" Date: Tue, 10 Jun 2008 07:28:21 -0400 X-ASG-Orig-Subj: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Topic: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Index: AcjK7RZXurwt0fiMRzmZ5Ha/4SFKNw== Message-ID: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Barracuda-Connect: mail.brightcove.com[38.113.27.188] X-Barracuda-Start-Time: 1213097355 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52903 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2719 X-archive-position: 16292 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lreed@brightcove.com Precedence: bulk X-list: xfs So I am having trouble fixing a corrupted <16 TB file system on a 32bit Linux system: The problem is that xfs_repair dies due to xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory: I found the below post, but the links are dead. I tried upping the system RAM to 12 GB, but the problem still exists, which I assume is the per process limit of 1-4 GB. So I am looking for advice on how to fix a large 32bit filesystem. I see options about running on a 64bit host. Can I do this with a newer version of xfs and kernel? We have many hosts that run 64bit Linux (2.6.18-8.1.15.el5 x86_64) and updated xfs progs. Is it possible to mount the existing LVM volumes on a new 64bit host with a newer OS and xfs progs and not risk losing data. Os details for old and possible new host below: Thanks in advance for any possible ideas. Really, THANKS! Lance Basic Os details: (Problem host used to mount XFS filesystem). CentOS release 4.4 (Final) 2.6.9-42.ELsmp i686 i686 i386 GNU/Linux XFS info: xfsprogs-2.8.11-1.c4 xfsdump-2.2.42-1.c4 kernel-module-xfs-2.6.9-42.ELsmp-0.1-3 Possible new host.: CentOS release 5 (Final) 2.6.18-8.1.15.el5 x86_64 xfsprogs-2.9.4-1.el5.centos xfsdump-2.2.46-1.el5.centos kmod-xfs-0.4-1.2.6.18_8.1.15.el5 Previous posts on list: #> I had 2GB RAM and a 300GB swap partition and was monitoring #> memory consumption with "top": it never went over 3BG before #> failing. # #The default 3GiB address space limit per process on a 32 bit #system is rather well documented, for a summary: # # http://WWW.sabi.co.UK/Notes/#060821c # #Let's mention this classic entry again: # # http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html # # <> > Your filesystem (8TiB) may simply bee too large for your # > > system to be able to repair. Try mounting it on a 64bit # > > system with more RAM in it and repairing it from there. # # Now that linux supports larger than 2TiB filesystems on 32 # bit systems, this is true for Linux as well.> # #A previous entry in the same thread might help too: # # http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00037.html # # <> I try xfs_check and xfs_ncheck (and more progs) with # > +200GB swap, but no different! less than 1 second and get # > out of memory. # # Swap won't help if you're running an ia32 (32bit) kernel - # you have a per-process memory limit of 1-4GiB (depending on # kernel and config). The amount of physical memory and swap # does not change this limitation.> # #Trying hard to avoid looking at what is a great time saving strategy! :-) # [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jun 10 05:07:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 05:07:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AC7G2w017195 for ; Tue, 10 Jun 2008 05:07:16 -0700 X-ASG-Debug-ID: 1213099691-616900920000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.brightcove.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0E77FC691D6 for ; Tue, 10 Jun 2008 05:08:11 -0700 (PDT) Received: from mail.brightcove.com (mail.brightcove.com [38.113.27.188]) by cuda.sgi.com with ESMTP id xpIJJCqajwpZdrZF for ; Tue, 10 Jun 2008 05:08:11 -0700 (PDT) Received: from bcmail1.VIDMARK.LOCAL ([172.20.0.82]) by bcmail1.VIDMARK.LOCAL ([172.20.0.82]) with mapi; Tue, 10 Jun 2008 08:07:24 -0400 From: Lance Reed To: Tru Huynh CC: "'xfs@oss.sgi.com'" Date: Tue, 10 Jun 2008 08:07:18 -0400 X-ASG-Orig-Subj: RE: Probems with xfs_repair on large filesystem and 32bit OS. Subject: RE: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Topic: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Index: AcjK8BpEbyrQwFoVQUScuQkoxlP36QAAdlbQ Message-ID: <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> References: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> <20080610115038.GD3005@sillage.bis.pasteur.fr> In-Reply-To: <20080610115038.GD3005@sillage.bis.pasteur.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Barracuda-Connect: mail.brightcove.com[38.113.27.188] X-Barracuda-Start-Time: 1213099692 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0004 1.0000 -2.0181 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52907 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m5AC7G2w017197 X-archive-position: 16293 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lreed@brightcove.com Precedence: bulk X-list: xfs SO, I take it from what you say that that I can running any newer version of xfs progs and a 64bit host (fiber attached, easy to do this), and run xfs_repair on the 32bit XFS volumes without fear of data corruption? Is this because XFS is not version specific, and xfs_repair will honor the 32bit file data structures? Again thanks so much for your response! Lance -----Original Message----- From: Tru Huynh [mailto:tru@pasteur.fr] Sent: Tuesday, June 10, 2008 7:51 AM To: Lance Reed Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. On Tue, Jun 10, 2008 at 07:28:21AM -0400, Lance Reed wrote: > So I am having trouble fixing a corrupted <16 TB file system on a 32bit Linux > system: > > > The problem is that xfs_repair dies due to xfs_repair: libxfs_initbuf can't > memalign 4096 bytes: Cannot allocate memory: > > I found the below post, but the links are dead. > > I tried upping the system RAM to 12 GB, but the problem still exists, which I > assume is the per process limit of 1-4 GB. you are on a 32 bits OS, so I would say are hitting a hard limit per process. > > So I am looking for advice on how to fix a large 32bit filesystem. I see > options about running on a 64bit host. Can I do this with a newer version of > xfs and kernel? We have many hosts that run 64bit Linux (2.6.18-8.1.15.el5 > x86_64) and updated xfs progs. Is it possible to mount the existing LVM > volumes on a new 64bit host with a newer OS and xfs progs and not risk losing > data. Os details for old and possible new host below: > My 0.2 cents. - you can install a x86_64 CentOS-4 machine and fix it from there or - you can install a x86_64 CentOS-5 machine and fix it from there or - upgrade to the **development** versions for CentOS-4 i386 at https://projects.centos.org/trac/xfs/ http://people.centos.org/tru/XFS/centos-4/RPMS/i386/xfsprogs-2.9.8-2.c4.i686.rpm http://people.centos.org/tru/XFS/centos-4/RPMS/i386/xfsdump-2.2.48-1.c4.i686.rpm and the right kmod-xfs http://people.centos.org/tru/XFS/centos-4/RPMS/i386/ > CentOS release 4.4 (Final) you should be running 4.6 > 2.6.9-42.ELsmp i686 i686 i386 GNU/Linux and 2.6.9-67.0.7.ELsmp... > > Possible new host.: > > CentOS release 5 (Final) > 2.6.18-8.1.15.el5 x86_64 2.6.18-53.1.21.el5 > xfsprogs-2.9.4-1.el5.centos > xfsdump-2.2.46-1.el5.centos or http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/xfsprogs-2.9.8-1.c5.x86_64.rpm http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/xfsdump-2.2.48-1.c5.x86_64.rpm > kmod-xfs-0.4-1.2.6.18_8.1.15.el5 or http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/kmod-xfs-0.4-2.2.6.18_53.1.21.el5.x86_64.rpm Cheers, Tru -- Dr Tru Huynh | http://www.pasteur.fr/recherche/unites/Binfs/ mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France From owner-xfs@oss.sgi.com Tue Jun 10 05:23:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 05:23:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ACNQ1d019409 for ; Tue, 10 Jun 2008 05:23:27 -0700 X-ASG-Debug-ID: 1213100660-5229004e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AF87020C68C for ; Tue, 10 Jun 2008 05:24:20 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id aE7zdBXRwknMMGGR for ; Tue, 10 Jun 2008 05:24:20 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K62tg-0006UW-FJ; Tue, 10 Jun 2008 12:24:20 +0000 Date: Tue, 10 Jun 2008 08:24:20 -0400 From: Christoph Hellwig To: Oliver Pinter Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [XFS] oss.sgi Subject: Re: [XFS] oss.sgi Message-ID: <20080610122420.GA15871@infradead.org> References: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213100662 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52907 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16294 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 10, 2008 at 01:26:39PM +0200, Oliver Pinter wrote: > Hi All! > > is the http://oss.sgi.com/projects/xfs/ site up to date? More or less. It could have a few more recent news items or reference to presentations from the last few month, but I can't find anything grossly out of date. From owner-xfs@oss.sgi.com Tue Jun 10 05:27:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 05:27:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ACRHUo020022 for ; Tue, 10 Jun 2008 05:27:17 -0700 X-ASG-Debug-ID: 1213100892-617c00ed0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 40AA612C28E6 for ; Tue, 10 Jun 2008 05:28:13 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id c7ekYpbaXtIzM2BS for ; Tue, 10 Jun 2008 05:28:13 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K62xP-0005E2-8z; Tue, 10 Jun 2008 12:28:11 +0000 Date: Tue, 10 Jun 2008 08:28:11 -0400 From: Christoph Hellwig To: Lance Reed Cc: Tru Huynh , "'xfs@oss.sgi.com'" X-ASG-Orig-Subj: Re: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. Message-ID: <20080610122811.GB15871@infradead.org> References: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> <20080610115038.GD3005@sillage.bis.pasteur.fr> <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213100893 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52907 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16295 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 10, 2008 at 08:07:18AM -0400, Lance Reed wrote: > SO, I take it from what you say that that I can running any newer version of xfs progs and a 64bit host (fiber attached, easy to do this), and run xfs_repair on the 32bit XFS volumes without fear of data corruption? > Is this because XFS is not version specific, and xfs_repair will honor the 32bit file data structures? Yes, this is fine. All the actual filesystem structures are endian and 32/64bit clean. The log needs to be in the same endianess and had 32bit vs 64bit problems on x86 for a while, but it needs to be recovered before you run xfs_repair anyway. From owner-xfs@oss.sgi.com Tue Jun 10 05:50:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 05:50:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ACoMEF022342 for ; Tue, 10 Jun 2008 05:50:23 -0700 X-ASG-Debug-ID: 1213102278-35a3016f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.brightcove.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1BA0020C8CF for ; Tue, 10 Jun 2008 05:51:18 -0700 (PDT) Received: from mail.brightcove.com (mail.brightcove.com [38.113.27.188]) by cuda.sgi.com with ESMTP id 2iWsyY3SnOafLbtb for ; Tue, 10 Jun 2008 05:51:18 -0700 (PDT) Received: from bcmail1.VIDMARK.LOCAL ([172.20.0.82]) by bcmail1.VIDMARK.LOCAL ([172.20.0.82]) with mapi; Tue, 10 Jun 2008 08:50:31 -0400 From: Lance Reed To: "'hch@infradead.org'" CC: "'xfs@oss.sgi.com'" Date: Tue, 10 Jun 2008 08:50:30 -0400 X-ASG-Orig-Subj: Re: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Topic: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Index: AcjK9Vdp/jYCbGDUQgm9f8hNJxZjSQAAzizr Message-ID: <6A32BC807C106440B7E23208F280DDAF01D3FC9317@bcmail1.VIDMARK.LOCAL> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Barracuda-Connect: mail.brightcove.com[38.113.27.188] X-Barracuda-Start-Time: 1213102279 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52910 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id m5ACoNEF022344 X-archive-position: 16296 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lreed@brightcove.com Precedence: bulk X-list: xfs Thanks! Yes the log died and was zeroed already with xfs_repair already. So I plan to put a 64bit head on the volumes and leave it that way. I asuume I need to still keep it under 16 tb since the fs datastuctures are 32bit? Thanks again for the help!!! ----- Original Message ----- From: Christoph Hellwig To: Lance Reed Cc: Tru Huynh ; 'xfs@oss.sgi.com' Sent: Tue Jun 10 08:28:11 2008 Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. On Tue, Jun 10, 2008 at 08:07:18AM -0400, Lance Reed wrote: > SO, I take it from what you say that that I can running any newer version of xfs progs and a 64bit host (fiber attached, easy to do this), and run xfs_repair on the 32bit XFS volumes without fear of data corruption? > Is this because XFS is not version specific, and xfs_repair will honor the 32bit file data structures? Yes, this is fine. All the actual filesystem structures are endian and 32/64bit clean. The log needs to be in the same endianess and had 32bit vs 64bit problems on x86 for a while, but it needs to be recovered before you run xfs_repair anyway. From owner-xfs@oss.sgi.com Tue Jun 10 06:00:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 06:00:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AD0pqZ023458 for ; Tue, 10 Jun 2008 06:00:51 -0700 X-ASG-Debug-ID: 1213102907-371f02cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AFB4912C2C81 for ; Tue, 10 Jun 2008 06:01:47 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id qmZgat7lH9VnDIv7 for ; Tue, 10 Jun 2008 06:01:47 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K63Tu-0007Og-VH; Tue, 10 Jun 2008 13:01:46 +0000 Date: Tue, 10 Jun 2008 09:01:46 -0400 From: "'hch@infradead.org'" To: Lance Reed Cc: "'hch@infradead.org'" , "'xfs@oss.sgi.com'" X-ASG-Orig-Subj: Re: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. Message-ID: <20080610130146.GA21510@infradead.org> References: <6A32BC807C106440B7E23208F280DDAF01D3FC9317@bcmail1.VIDMARK.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A32BC807C106440B7E23208F280DDAF01D3FC9317@bcmail1.VIDMARK.LOCAL> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213102907 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52909 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16297 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 10, 2008 at 08:50:30AM -0400, Lance Reed wrote: > Thanks! > > Yes the log died and was zeroed already with xfs_repair already. > > So I plan to put a 64bit head on the volumes and leave it that way. > > I asuume I need to still keep it under 16 tb since the fs datastuctures are 32bit? > All XFS data structures (which matter for this) are 64bit. But the pagecache size in 32bit x86 systems is indeeed limited, so a larger filesystem won't work there. From owner-xfs@oss.sgi.com Tue Jun 10 07:06:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 07:06:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AE6WPx029541 for ; Tue, 10 Jun 2008 07:06:32 -0700 X-ASG-Debug-ID: 1213106846-0c34037c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 828BD17A6D9C for ; Tue, 10 Jun 2008 07:07:26 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by cuda.sgi.com with ESMTP id ZdQtKGEJarxIcn5B for ; Tue, 10 Jun 2008 07:07:26 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta02.mail.rr.com with ESMTP id <20080610140725.ODII25858.hrndva-omta02.mail.rr.com@tomslinux.homelinux.org> for ; Tue, 10 Jun 2008 14:07:25 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m5AE7Gqa007632 for ; Tue, 10 Jun 2008 09:07:16 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m5AE7FVc007631; Tue, 10 Jun 2008 09:07:15 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.226.41 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Tue, 10 Jun 2008 09:07:15 -0500 (CDT) Message-ID: <9856.143.166.226.41.1213106835.squirrel@tomslinux.homelinux.org> Date: Tue, 10 Jun 2008 09:07:15 -0500 (CDT) X-ASG-Orig-Subj: Filesystem article up, thank you all! Subject: Filesystem article up, thank you all! To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.125] X-Barracuda-Start-Time: 1213106847 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0029 1.0000 -2.0020 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52906 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16298 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs Folks, My article answering Henry Newman is up. If you wish to clarify or correct anything in the article, please do so in the comments. http://lxer.com/module/newswire/view/103802/index.html Thanks! Tom King ------- "Concern for man and his fate must always form the chief interest of all technical endeavors. Never forget this in the midst of your diagrams and equations." --Albert Einstein From owner-xfs@oss.sgi.com Tue Jun 10 10:06:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 10:06:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AH6Xbf016506 for ; Tue, 10 Jun 2008 10:06:33 -0700 X-ASG-Debug-ID: 1213117648-782a01ac0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out03.alice-dsl.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 457CA17A805C for ; Tue, 10 Jun 2008 10:07:28 -0700 (PDT) Received: from smtp-out03.alice-dsl.net (smtp-out03.alice-dsl.net [88.44.63.5]) by cuda.sgi.com with ESMTP id 6E01QiUtE2J8cFHM for ; Tue, 10 Jun 2008 10:07:28 -0700 (PDT) Received: from out.alice-dsl.de ([192.168.125.59]) by smtp-out03.alice-dsl.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 19:00:15 +0200 Received: from basil.firstfloor.org ([92.224.155.196]) by out.alice-dsl.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 19:00:15 +0200 Received: by basil.firstfloor.org (Postfix, from userid 1000) id ACC851B4212; Tue, 10 Jun 2008 19:07:26 +0200 (CEST) To: Christoph Hellwig Cc: Lance Reed , Tru Huynh , "'xfs@oss.sgi.com'" X-ASG-Orig-Subj: Re: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. From: Andi Kleen References: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> <20080610115038.GD3005@sillage.bis.pasteur.fr> <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> <20080610122811.GB15871@infradead.org> Date: Tue, 10 Jun 2008 19:07:26 +0200 In-Reply-To: <20080610122811.GB15871@infradead.org> (Christoph Hellwig's message of "Tue, 10 Jun 2008 08:28:11 -0400") Message-ID: <87tzg1p6b5.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 10 Jun 2008 17:00:15.0939 (UTC) FILETIME=[74838130:01C8CB1B] X-Barracuda-Connect: smtp-out03.alice-dsl.net[88.44.63.5] X-Barracuda-Start-Time: 1213117649 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52926 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16299 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs Christoph Hellwig writes: > On Tue, Jun 10, 2008 at 08:07:18AM -0400, Lance Reed wrote: >> SO, I take it from what you say that that I can running any newer version of xfs progs and a 64bit host (fiber attached, easy to do this), and run xfs_repair on the 32bit XFS volumes without fear of data corruption? >> Is this because XFS is not version specific, and xfs_repair will honor the 32bit file data structures? > > Yes, this is fine. All the actual filesystem structures are endian and > 32/64bit clean. The log needs to be in the same endianess and had 32bit > vs 64bit problems on x86 for a while, but it needs to be recovered > before you run xfs_repair anyway. Actually there used to be some bugs in old versions where 32bit couldn't replay 64bit logs or vice versa. Probably all fixed in uptodate kernels. -Andi From owner-xfs@oss.sgi.com Tue Jun 10 10:19:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 10:19:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AHJ6Vg018375 for ; Tue, 10 Jun 2008 10:19:06 -0700 X-ASG-Debug-ID: 1213118401-676e02c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out04.alice-dsl.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B1E1120F15D for ; Tue, 10 Jun 2008 10:20:01 -0700 (PDT) Received: from smtp-out04.alice-dsl.net (smtp-out04.alice-dsl.net [88.44.63.6]) by cuda.sgi.com with ESMTP id 64lEEdH9NjCVy1Tq for ; Tue, 10 Jun 2008 10:20:01 -0700 (PDT) Received: from out.alice-dsl.de ([192.168.125.59]) by smtp-out04.alice-dsl.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 19:12:49 +0200 Received: from basil.firstfloor.org ([92.224.155.196]) by out.alice-dsl.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 19:12:49 +0200 Received: by basil.firstfloor.org (Postfix, from userid 1000) id 114471B4212; Tue, 10 Jun 2008 19:20:00 +0200 (CEST) To: dizzy Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS directory entries sort order Subject: Re: XFS directory entries sort order From: Andi Kleen References: <200806101245.09950.dizzy@roedu.net> Date: Tue, 10 Jun 2008 19:20:00 +0200 In-Reply-To: <200806101245.09950.dizzy@roedu.net> (dizzy@roedu.net's message of "Tue, 10 Jun 2008 12:45:09 +0300") Message-ID: <87prqpp5q7.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 10 Jun 2008 17:12:49.0141 (UTC) FILETIME=[35750250:01C8CB1D] X-Barracuda-Connect: smtp-out04.alice-dsl.net[88.44.63.6] X-Barracuda-Start-Time: 1213118402 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52928 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16300 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs dizzy writes: > Can someone tell me (in English or C :) ) the algorithm of the sorting order > of the entries in an XFS directory as I would get them with a readdir() (or > shell "find" command)? > > I am trying to figure it out by reading linux/fs/xfs/xfs_dir2*.c code but I > don't seem to be doing much progress and I was hoping maybe someone that > knows these details can help. I believe it computes a hash over the name and then sorts by the hash numerical value. At least the b*tree large directories do, small inline directories might be different (XFS uses different algorithms for different directory sizes) The hash function is in xfs_da_btree.c:xfs_da_hashname() With the recent case insensitive support there are also differences on the file systems which have that enabled. Also better don't rely on it never changing. -Andi From owner-xfs@oss.sgi.com Tue Jun 10 14:50:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 14:50:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ALo9CR015415 for ; Tue, 10 Jun 2008 14:50:09 -0700 X-ASG-Debug-ID: 1213134663-107e02a80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 51D2117A9D07 for ; Tue, 10 Jun 2008 14:51:04 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by cuda.sgi.com with ESMTP id 2ZQJ2RjM4iULdLJO for ; Tue, 10 Jun 2008 14:51:04 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so2023873fgb.8 for ; Tue, 10 Jun 2008 14:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=MEc7igpX47EZI1Zx5rvYsSq+dUJOPfZslPLmO9bPEIk=; b=A3SMENUshAlebLMjEXx0kykbU/2GIbwZWxrdIGw8NtAq/8kQAVbRVv7/TBdj3jpl0f 6P2jukjRqXvuZ0/0VWBCOZpVT89Bdi+Aw65RyUyj8VlCdwkDtdC4YTrdXnonwBP6sltJ +9NIa+ysVRdOayKo8SVojneYn1S/AN+eK9xGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aBsD4f6YQH77/lAU73eXPvzyzP3hD/ctlu6eu+P0Hd86I4iPywG0gA/JFo+VDZyP5F eLEP/A15Bj62EOMb9mUfRu4JlxSXyXs7fWHguCsENPzCtuhUhTAZn6tEam13blRtO+39 wn5dfSmyTrHfJhVTqmjo2Ahx8fKEnhsvAuf6I= Received: by 10.86.80.5 with SMTP id d5mr6334369fgb.19.1213134663461; Tue, 10 Jun 2008 14:51:03 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Tue, 10 Jun 2008 14:51:03 -0700 (PDT) Message-ID: <6101e8c40806101451tb160ed8rc0ba2739cafee84f@mail.gmail.com> Date: Tue, 10 Jun 2008 23:51:03 +0200 From: "Oliver Pinter" To: "Christoph Hellwig" X-ASG-Orig-Subj: Re: [XFS] oss.sgi Subject: Re: [XFS] oss.sgi Cc: xfs@oss.sgi.com In-Reply-To: <20080610122420.GA15871@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> <20080610122420.GA15871@infradead.org> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.154] X-Barracuda-Start-Time: 1213134665 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0031 1.0000 -2.0009 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52946 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16301 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs hi! thanks the info On 6/10/08, Christoph Hellwig wrote: > On Tue, Jun 10, 2008 at 01:26:39PM +0200, Oliver Pinter wrote: >> Hi All! >> >> is the http://oss.sgi.com/projects/xfs/ site up to date? > > More or less. It could have a few more recent news items or reference > to presentations from the last few month, but I can't find anything > grossly out of date. > > -- Thanks, Oliver From owner-xfs@oss.sgi.com Tue Jun 10 15:24:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 15:24:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,J_CHICKENPOX_33, J_CHICKENPOX_45,J_CHICKENPOX_48,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AMOqTp019254 for ; Tue, 10 Jun 2008 15:24:53 -0700 X-ASG-Debug-ID: 1213136747-107403640000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ueb.org.br (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 02F9F17AA1DE for ; Tue, 10 Jun 2008 15:25:47 -0700 (PDT) Received: from ueb.org.br (ns1.ueb.org.br [200.165.164.250]) by cuda.sgi.com with ESMTP id eELH4rCOMCs00JgE for ; Tue, 10 Jun 2008 15:25:47 -0700 (PDT) Received: from ueb.org.br (localhost.server.ueb.org.br [127.0.0.1]) by ueb.org.br (8.14.0/8.14.0) with ESMTP id m5AMQY8x048307 for ; Tue, 10 Jun 2008 19:26:35 -0300 (BRT) Received: (from www@localhost) by ueb.org.br (8.14.0/8.14.0/Submit) id m5AMQY0k048305; Tue, 10 Jun 2008 19:26:34 -0300 (BRT) Date: Tue, 10 Jun 2008 19:26:34 -0300 (BRT) Message-Id: <200806102226.m5AMQY0k048305@ueb.org.br> To: xfs@oss.sgi.com X-ASG-Orig-Subj: PROPERTIES. Subject: PROPERTIES. From: Samuel Juna Reply-To: as568agl@yahoo.com.hk MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ueb.org.br [0.0.0.0]); Tue, 10 Jun 2008 19:26:35 -0300 (BRT) X-Barracuda-Connect: ns1.ueb.org.br[200.165.164.250] X-Barracuda-Start-Time: 1213136749 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6699 1.0000 1.1518 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.15 X-Barracuda-Spam-Status: No, SCORE=1.15 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52948 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16302 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: as568agl@yahoo.com.hk Precedence: bulk X-list: xfs Good Day, I wish to introduce myself to you.I am Samuel Juna a top Sudanese Goverment official who opposed the war in Dafur in my country Sudan.Due to my oppostion to the war,the goverment of my country has been persecuting me.Consequently my wife,children and I managed to enter a red cross airplane that was evacuating foreigners and we are presently in Cape Town,South Africa. We wish to invest in properties in your country with your assistance and cooperation.If you are in a good position to help my family, please send an e-mail to the e-mail address below indicating your desire to help my family invest this funds in your country. best regards, Hope to meet you soon. God bless, Samuel Juna Email:as568agl@yahoo.com.hk From owner-xfs@oss.sgi.com Tue Jun 10 15:51:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 15:51:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AMpA5g021415 for ; Tue, 10 Jun 2008 15:51:10 -0700 X-ASG-Debug-ID: 1213138326-081b01290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B9D33212879 for ; Tue, 10 Jun 2008 15:52:06 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 31KbFTaNyyE09Aua for ; Tue, 10 Jun 2008 15:52:06 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A5B27A9BF4F; Tue, 10 Jun 2008 17:52:04 -0500 (CDT) Message-ID: <484F0594.1010406@sandeen.net> Date: Tue, 10 Jun 2008 17:52:04 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [XFS] oss.sgi Subject: Re: [XFS] oss.sgi References: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> <20080610122420.GA15871@infradead.org> <6101e8c40806101451tb160ed8rc0ba2739cafee84f@mail.gmail.com> In-Reply-To: <6101e8c40806101451tb160ed8rc0ba2739cafee84f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213138326 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52950 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16303 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > hi! > > thanks the info > > On 6/10/08, Christoph Hellwig wrote: >> On Tue, Jun 10, 2008 at 01:26:39PM +0200, Oliver Pinter wrote: >>> Hi All! >>> >>> is the http://oss.sgi.com/projects/xfs/ site up to date? >> More or less. It could have a few more recent news items or reference >> to presentations from the last few month, but I can't find anything >> grossly out of date. Is there any info in particular that you wondered about? :) -Eric From owner-xfs@oss.sgi.com Tue Jun 10 15:59:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 15:59:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AMx9kF022396 for ; Tue, 10 Jun 2008 15:59:10 -0700 X-ASG-Debug-ID: 1213138803-18c8004d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E4FFEC7154D for ; Tue, 10 Jun 2008 16:00:03 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id lorknRtkVkyDQh5h for ; Tue, 10 Jun 2008 16:00:03 -0700 (PDT) Received: (qmail 26322 invoked from network); 10 Jun 2008 23:00:02 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Jun 2008 23:00:02 -0000 Message-ID: <484F0998.90306@sauce.co.nz> Date: Wed, 11 Jun 2008 11:09:12 +1200 From: Richard Scobie 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: Timothy Shimmin CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> In-Reply-To: <484DDDB3.70000@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1213138805 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3269 1.0000 -0.2385 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.24 X-Barracuda-Spam-Status: No, SCORE=-0.24 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52947 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16304 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Timothy Shimmin wrote: > BTW, Sam Vaughan wrote some tutorial notes on the allocator and in particular > filestreams which I've pasted below: > (I thought it might be here: > http://oss.sgi.com/projects/xfs/training/ but I can't see it > in the allocator lab and slides). I did actually find an entry for filestreams in slide 6. While there I also found the information on 64bit inodes. My filesystem is 9.6TB and could well end up with a large quantity of 1-15MB files stored and the statement: "Operating system interfaces and legacy software products often mandate the use of 32 bit inode numbers even on systems that support 64 bit inode numbers." makes me wonder how common this still is in practice - the slide was written in 2006)? My initial preference would be to go with 64 bit inodes for performance reasons, but as one cannot revert the fs back to 32 bit inodes once committed, I am somewhat hesitant. Or am I worrying unecessarily about the negative impact of 32 bit inodes, given 9.6TB full of 1 to 15MB files? Regards, Richard From owner-xfs@oss.sgi.com Tue Jun 10 16:52:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 16:52:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5ANqSA2031776 for ; Tue, 10 Jun 2008 16:52:29 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07971; Wed, 11 Jun 2008 09:53:14 +1000 Date: Wed, 11 Jun 2008 09:53:40 +1000 To: "Andi Kleen" , dizzy Subject: Re: XFS directory entries sort order From: "Barry Naujok" Organization: SGI Cc: xfs@oss.sgi.com Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200806101245.09950.dizzy@roedu.net> <87prqpp5q7.fsf@basil.nowhere.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <87prqpp5q7.fsf@basil.nowhere.org> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16305 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 11 Jun 2008 03:20:00 +1000, Andi Kleen wrote: > dizzy writes: > >> Can someone tell me (in English or C :) ) the algorithm of the sorting >> order >> of the entries in an XFS directory as I would get them with a readdir() >> (or >> shell "find" command)? >> >> I am trying to figure it out by reading linux/fs/xfs/xfs_dir2*.c code >> but I >> don't seem to be doing much progress and I was hoping maybe someone that >> knows these details can help. > > I believe it computes a hash over the name and then sorts by the hash > numerical value. At least the b*tree large directories do, small inline > directories might be different (XFS uses different algorithms for > different directory sizes) readdir order is not dependant on the hashes. The order depends on the order of files being created, unlinked and the length of the filenames being unlinked/created. > The hash function is in xfs_da_btree.c:xfs_da_hashname() > > With the recent case insensitive support there are also differences > on the file systems which have that enabled. > > Also better don't rely on it never changing. Yes :) Barry. From owner-xfs@oss.sgi.com Tue Jun 10 16:58:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 16:58:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ANw4tK032557 for ; Tue, 10 Jun 2008 16:58:05 -0700 X-ASG-Debug-ID: 1213142340-6be102a30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from one.firstfloor.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC46A17AA72A for ; Tue, 10 Jun 2008 16:59:00 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by cuda.sgi.com with ESMTP id 2mmiEkuIBPW3O0QC for ; Tue, 10 Jun 2008 16:59:00 -0700 (PDT) Received: from [92.224.154.155] (g224154155.adsl.alicedsl.de [92.224.154.155]) by one.firstfloor.org (Postfix) with ESMTP id CF8E618900BD; Wed, 11 Jun 2008 02:09:01 +0200 (CEST) Message-ID: <484F1541.7010203@firstfloor.org> Date: Wed, 11 Jun 2008 01:58:57 +0200 From: Andi Kleen User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Barry Naujok CC: dizzy , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS directory entries sort order Subject: Re: XFS directory entries sort order References: <200806101245.09950.dizzy@roedu.net> <87prqpp5q7.fsf@basil.nowhere.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: one.firstfloor.org[213.235.205.2] X-Barracuda-Start-Time: 1213142340 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0002 1.0000 -2.0199 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52954 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16306 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs > readdir order is not dependant on the hashes. The order depends on the > order of files being created, unlinked and the length of the filenames > being unlinked/created. Thanks for the correction. It's a long time that I read that source so it probably got confused with some other fs. -Andi From owner-xfs@oss.sgi.com Tue Jun 10 17:00:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 17:00:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5B003Fn000620 for ; Tue, 10 Jun 2008 17:00:05 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08232; Wed, 11 Jun 2008 10:00:40 +1000 Date: Wed, 11 Jun 2008 10:01:08 +1000 To: "Lance Reed" , "Tru Huynh" Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. From: "Barry Naujok" Organization: SGI Cc: "'xfs@oss.sgi.com'" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> <20080610115038.GD3005@sillage.bis.pasteur.fr> <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16307 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Tue, 10 Jun 2008 22:07:18 +1000, Lance Reed wrote: > SO, I take it from what you say that that I can running any newer > version of xfs progs and a 64bit host (fiber attached, easy to do this), > and run xfs_repair on the 32bit XFS volumes without fear of data > corruption? > Is this because XFS is not version specific, and xfs_repair will honor > the 32bit file data structures? > > Again thanks so much for your response! As Christoph said, you can run 64-bit kernel/xfsprogs on a filesystem used in a 32-bit kernel without problems. You'll also find that xfsprogs 2.9.4 and later is more memory optimised than the 2.8.x series. It may even work on your filesystem in 32-bit mode. I can't guarantee that though as you never actually specified the size of your filesystem and how many inodes are on it. I can repair a 9TB filesystem on a 2GB machine without using swap. > Lance > -----Original Message----- > From: Tru Huynh [mailto:tru@pasteur.fr] > Sent: Tuesday, June 10, 2008 7:51 AM > To: Lance Reed > Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. > > On Tue, Jun 10, 2008 at 07:28:21AM -0400, Lance Reed wrote: >> So I am having trouble fixing a corrupted <16 TB file system on a 32bit >> Linux >> system: >> >> >> The problem is that xfs_repair dies due to xfs_repair: libxfs_initbuf >> can't >> memalign 4096 bytes: Cannot allocate memory: >> >> I found the below post, but the links are dead. >> >> I tried upping the system RAM to 12 GB, but the problem still exists, >> which I >> assume is the per process limit of 1-4 GB. > you are on a 32 bits OS, so I would say are hitting a hard limit per > process. >> >> So I am looking for advice on how to fix a large 32bit filesystem. I >> see >> options about running on a 64bit host. Can I do this with a newer >> version of >> xfs and kernel? We have many hosts that run 64bit Linux >> (2.6.18-8.1.15.el5 >> x86_64) and updated xfs progs. Is it possible to mount the existing LVM >> volumes on a new 64bit host with a newer OS and xfs progs and not risk >> losing >> data. Os details for old and possible new host below: >> > My 0.2 cents. > - you can install a x86_64 CentOS-4 machine and fix it from there > or > - you can install a x86_64 CentOS-5 machine and fix it from there > or > - upgrade to the **development** versions for CentOS-4 i386 at > https://projects.centos.org/trac/xfs/ > > http://people.centos.org/tru/XFS/centos-4/RPMS/i386/xfsprogs-2.9.8-2.c4.i686.rpm > http://people.centos.org/tru/XFS/centos-4/RPMS/i386/xfsdump-2.2.48-1.c4.i686.rpm > and the right kmod-xfs > http://people.centos.org/tru/XFS/centos-4/RPMS/i386/ > >> CentOS release 4.4 (Final) > you should be running 4.6 >> 2.6.9-42.ELsmp i686 i686 i386 GNU/Linux > and 2.6.9-67.0.7.ELsmp... >> >> Possible new host.: >> >> CentOS release 5 (Final) >> 2.6.18-8.1.15.el5 x86_64 > 2.6.18-53.1.21.el5 > >> xfsprogs-2.9.4-1.el5.centos >> xfsdump-2.2.46-1.el5.centos > or > http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/xfsprogs-2.9.8-1.c5.x86_64.rpm > http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/xfsdump-2.2.48-1.c5.x86_64.rpm > >> kmod-xfs-0.4-1.2.6.18_8.1.15.el5 > or > http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/kmod-xfs-0.4-2.2.6.18_53.1.21.el5.x86_64.rpm > > Cheers, > > Tru > -- > Dr Tru Huynh | http://www.pasteur.fr/recherche/unites/Binfs/ > mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 > Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France > > From owner-xfs@oss.sgi.com Tue Jun 10 17:04:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 17:04:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5B044UC001254 for ; Tue, 10 Jun 2008 17:04:05 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08287; Wed, 11 Jun 2008 10:04:27 +1000 Date: Wed, 11 Jun 2008 10:04:56 +1000 To: "Andi Kleen" Subject: Re: XFS directory entries sort order From: "Barry Naujok" Organization: SGI Cc: dizzy , xfs@oss.sgi.com Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200806101245.09950.dizzy@roedu.net> <87prqpp5q7.fsf@basil.nowhere.org> <484F1541.7010203@firstfloor.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <484F1541.7010203@firstfloor.org> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16308 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 11 Jun 2008 09:58:57 +1000, Andi Kleen wrote: > >> readdir order is not dependant on the hashes. The order depends on the >> order of files being created, unlinked and the length of the filenames >> being unlinked/created. > > Thanks for the correction. It's a long time that I read that source > so it probably got confused with some other fs. If I read the code correctly, in node-form directories, it will try and use the same data block that other names with the same hash are located in. Barry. From owner-xfs@oss.sgi.com Tue Jun 10 17:38:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 17:38:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5B0csfV004922 for ; Tue, 10 Jun 2008 17:38:54 -0700 X-ASG-Debug-ID: 1213144788-1401035e0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bnc02.aitai.ne.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 2A108213103 for ; Tue, 10 Jun 2008 17:39:49 -0700 (PDT) Received: from bnc02.aitai.ne.jp (bnc02.aitai.ne.jp [211.1.192.125]) by cuda.sgi.com with SMTP id uRnF473y4u0kxadX for ; Tue, 10 Jun 2008 17:39:49 -0700 (PDT) Received: (qmail 642 invoked from network); 11 Jun 2008 09:39:48 +0900 Received: from unknown (HELO mira1.aitai.ne.jp) (211.1.194.32) by bnc02.aitai.ne.jp with SMTP; 11 Jun 2008 09:39:48 +0900 Received: from localhost (localhost) by mira1.aitai.ne.jp (MOS 3.8.4-GA) with internal id DKV43907; Wed, 11 Jun 2008 09:39:48 +0900 (JST) Date: Wed, 11 Jun 2008 09:39:48 +0900 (JST) From: Mail Delivery Subsystem Message-Id: <200806110039.DKV43907@mira1.aitai.ne.jp> To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="DKV43907.1213144788/mira1.aitai.ne.jp" X-ASG-Orig-Subj: Returned mail: User unknown (from [211.1.194.36]) Subject: Returned mail: User unknown (from [211.1.194.36]) Auto-Submitted: auto-generated (failure) X-DSN-Mirapoint-Virus: VIRUSDELETED; host=mira1.aitai.ne.jp; attachment=[2.1.2]; virus=Mal/Iframe-E X-Barracuda-Connect: bnc02.aitai.ne.jp[211.1.192.125] X-Barracuda-Start-Time: 1213144790 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4998 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52956 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16309 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@mira1.aitai.ne.jp Precedence: bulk X-list: xfs This is a MIME-encapsulated message --DKV43907.1213144788/mira1.aitai.ne.jp The original message was received at Wed, 11 Jun 2008 09:39:45 +0900 (JST) from p5165-ipbfp1901tokaisakaetozai.aichi.ocn.ne.jp [118.5.118.165] ----- The following addresses had permanent delivery errors ----- ----- Transcript of session is unavailable ----- --DKV43907.1213144788/mira1.aitai.ne.jp Content-Type: message/delivery-status Reporting-MTA: dns; mira1.aitai.ne.jp Arrival-Date: Wed, 11 Jun 2008 09:39:45 +0900 (JST) Final-Recipient: RFC822; m-bell@hm.aitai.ne.jp Action: failed Status: 5.1.1 Remote-MTA: DNS; [211.1.194.36] Diagnostic-Code: SMTP; 550 User unknown Last-Attempt-Date: Wed, 11 Jun 2008 09:39:48 +0900 (JST) --DKV43907.1213144788/mira1.aitai.ne.jp Content-Type: message/rfc822 Received: from hm.aitai.ne.jp (p5165-ipbfp1901tokaisakaetozai.aichi.ocn.ne.jp [118.5.118.165]) by mira1.aitai.ne.jp (MOS 3.8.4-GA) with ESMTP id DKV43792; Wed, 11 Jun 2008 09:39:44 +0900 (JST) Message-Id: <200806110039.DKV43792@mira1.aitai.ne.jp> From: linux-xfs@oss.sgi.com To: m-bell@hm.aitai.ne.jp Subject: Mail Delivery (failure m-bell@hm.aitai.ne.jp) Date: Wed, 11 Jun 2008 09:39:43 +0900 X-Priority: 3 X-MSMail-Priority: Normal X-matriXscan-RefId: str=0001.0A150202.484F1ED1.0021,ss=1,fgs=0 X-matriXscan: Uncategorized X-matriXscan-Action: Approve X-Mirapoint-Virus: VIRUSDELETED; host=mira1.aitai.ne.jp; attachment=[2.1.2]; virus=Mal/Iframe-E X-Mirapoint-Virus: VIRUSDELETED; host=mira1.aitai.ne.jp; attachment=[2.2]; virus=W32/Netsky-P --DKV43907.1213144788/mira1.aitai.ne.jp-- From owner-xfs@oss.sgi.com Tue Jun 10 18:40:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 18:40:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5B1dvnF009773 for ; Tue, 10 Jun 2008 18:39:59 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09999; Wed, 11 Jun 2008 11:39:35 +1000 Message-ID: <484F2CD7.9070506@sgi.com> Date: Wed, 11 Jun 2008 11:39:35 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Richard Scobie CC: xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> In-Reply-To: <484F0998.90306@sauce.co.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16310 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Hi Richard, Richard Scobie wrote: > Timothy Shimmin wrote: > >> BTW, Sam Vaughan wrote some tutorial notes on the allocator and in >> particular >> filestreams which I've pasted below: >> (I thought it might be here: >> http://oss.sgi.com/projects/xfs/training/ but I can't see it >> in the allocator lab and slides). > > I did actually find an entry for filestreams in slide 6. > Yes, so did I but on a quick scan it didn't have the same detail. > While there I also found the information on 64bit inodes. > > My filesystem is 9.6TB and could well end up with a large quantity of > 1-15MB files stored and the statement: > > "Operating system interfaces and legacy software products often mandate > the use of 32 bit inode numbers even on systems that support 64 bit > inode numbers." > > makes me wonder how common this still is in practice - the slide was > written in 2006)? > > My initial preference would be to go with 64 bit inodes for performance > reasons, but as one cannot revert the fs back to 32 bit inodes once > committed, I am somewhat hesitant. > > Or am I worrying unecessarily about the negative impact of 32 bit > inodes, given 9.6TB full of 1 to 15MB files? > Ah, the 32 bit inode versus 64 bit inode question :) I don't have any definitive answers and I'm sure there will be people on the list with their opinions and experiences. So just some thoughts... Firstly, XFS' current support for 32 bit inode numbers was added as an afterthought I think primarily at the time on IRIX for 32 bit backup clients such as Legato Networker. It is only a compatibility thing with performance downsides. So the question then becomes (1)what exactly is the compatibility matrix and (2)under what conditions are there performance problems and by how much. The other thing (3) is then a conversion tool for moving back from 64 bit inodes to 32 bit inodes if you have a compat problem. (3) There is a conversion tool called xfs_reno on IRIX. Barry has ported and modified it for Linux but I believe has not checked it in and has some outstanding Agami review points to address. Ideally, it would be nicer if we had more kernel support (as suggested by Dave (dgc)) for swapping all the inode's metadata (instead of just extents as we currently do). So in other words, it is not there yet and there is the question of whether we should update the kernel first (or maybe the tool should go in anyway for use on older kernels). (1) It would be nice to know what the state of the apps really are. There is also the question of interaction with CXFS and NFS. Greg Banks has a compat matrix for NFS. It looks like the main things is to get something half recent - linux 2.6, nfs v3, apps which use 64 bit sys calls (eg. stat64) etc... Would need to do investigating. There is also the possibility of other 32bit/64bit mapping schemes for xfs but I won't go there. --Tim From owner-xfs@oss.sgi.com Tue Jun 10 19:37:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 19:37:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5B2bqX3013882 for ; Tue, 10 Jun 2008 19:37:53 -0700 X-ASG-Debug-ID: 1213151928-1d4b02ec0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5EB92C71EF7 for ; Tue, 10 Jun 2008 19:38:48 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id ihnpGwtIc2SZhG8E for ; Tue, 10 Jun 2008 19:38:48 -0700 (PDT) Received: (qmail 28542 invoked from network); 11 Jun 2008 02:38:47 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Jun 2008 02:38:47 -0000 Message-ID: <484F3CDF.10001@sauce.co.nz> Date: Wed, 11 Jun 2008 14:47:59 +1200 From: Richard Scobie 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: Timothy Shimmin CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> In-Reply-To: <484F2CD7.9070506@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1213151929 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0926 1.0000 -1.4373 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.44 X-Barracuda-Spam-Status: No, SCORE=-1.44 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52965 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16311 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Hi Timothy, Timothy Shimmin wrote: > Ah, the 32 bit inode versus 64 bit inode question :) > I don't have any definitive answers and I'm sure there will be people > on the list with their opinions and experiences. > So just some thoughts... On balance, I'm thinking the best compromise might be to stay 32 bit and bump the inode size to 2048 bytes. Regards, Richard From owner-xfs@oss.sgi.com Tue Jun 10 20:22:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 20:22:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5B3MTIq021756 for ; Tue, 10 Jun 2008 20:22:29 -0700 X-ASG-Debug-ID: 1213154604-6a0000740000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6AE1CC72178 for ; Tue, 10 Jun 2008 20:23:24 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id BXoZFVwiygw0UIVM for ; Tue, 10 Jun 2008 20:23:24 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E023198FF73; Tue, 10 Jun 2008 22:23:22 -0500 (CDT) Message-ID: <484F452A.8090909@sandeen.net> Date: Tue, 10 Jun 2008 22:23:22 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Timothy Shimmin CC: Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> In-Reply-To: <484F2CD7.9070506@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213154605 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52965 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16312 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Timothy Shimmin wrote: > (1) It would be nice to know what the state of the apps really are. > There is also the question of interaction with CXFS and NFS. > Greg Banks has a compat matrix for NFS. It looks like the main > things is to get something half recent - linux 2.6, nfs v3, > apps which use 64 bit sys calls (eg. stat64) etc... > Would need to do investigating. Greg has a tool to scan binaries... some day I'm going to run it over the fedora universe, I'll get back to you... someday. -Eric From owner-xfs@oss.sgi.com Thu Jun 12 06:51:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 06:52:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CDpv7u021111 for ; Thu, 12 Jun 2008 06:51:57 -0700 X-ASG-Debug-ID: 1213278773-6997021b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 75A231BA1A82 for ; Thu, 12 Jun 2008 06:52:53 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id WrPzMXgrj03c8LBa for ; Thu, 12 Jun 2008 06:52:53 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4F44298534E; Thu, 12 Jun 2008 08:52:52 -0500 (CDT) Message-ID: <48512A34.1020604@sandeen.net> Date: Thu, 12 Jun 2008 08:52:52 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Timothy Shimmin CC: Richard Scobie , xfs@oss.sgi.com, Greg Banks X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> In-Reply-To: <484F452A.8090909@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213278773 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53093 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16313 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > Timothy Shimmin wrote: > >> (1) It would be nice to know what the state of the apps really are. >> There is also the question of interaction with CXFS and NFS. >> Greg Banks has a compat matrix for NFS. It looks like the main >> things is to get something half recent - linux 2.6, nfs v3, >> apps which use 64 bit sys calls (eg. stat64) etc... >> Would need to do investigating. > > Greg has a tool to scan binaries... some day I'm going to run it over > the fedora universe, I'll get back to you... someday. someday didn't take too long :) but it ain't pretty. I installed all fedora packages under a directory and ran greg's tool over: /sbin /usr/sbin /bin /usr/bin /usr/kerberos/bin/ /usr/kerberos/sbin/ Aggregate results: 4070 29.1% are scripts (shell, perl, whatever) 6598 47.2% don't use any stat() family calls at all 1829 13.1% use 32-bit stat() family interfaces only 1312 9.4% use 64-bit stat64() family interfaces only 180 1.3% use both 32-bit and 64-bit stat() family interfaces list of packages, sorted by the semi-lame "number of files in package which call a 32-bit stat variant" metric: http://sandeen.fedorapeople.org/stat32-ers I'm going to see if I can't leverage Fedora to clean some of this up. -Eric From owner-xfs@oss.sgi.com Thu Jun 12 07:49:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 07:49:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CEnKPS024593 for ; Thu, 12 Jun 2008 07:49:20 -0700 X-ASG-Debug-ID: 1213282215-213c00490000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8CDC917B7C9C for ; Thu, 12 Jun 2008 07:50:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by cuda.sgi.com with ESMTP id MSVub9SeUQjQvj4Y for ; Thu, 12 Jun 2008 07:50:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so2637289fgb.8 for ; Thu, 12 Jun 2008 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=GfUONjySnFi11nMrYDy3Ep9zONrqzX5WJPCC74dmosg=; b=B9dv37GzCLfLMuw/5sG8bch00kgHcZNzy65xuq4PYkfOkjQ/lVJ49KcrkdYc1xd4OP W8/icahuAvpaTgcZV1BNO1F7VFS3N4a89QvktMwp77+gyBVaL04BKvk/nx+ohmAtJUGv TOkntrHTZ05bxPAGaF/iB7KIO8TCYrsUP5anY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=S4h4nnkeyWlMwswxER88kCocTE3FeP8Zsv41UmOsHhLNC+8AC5BBoLYDvKkNn8G0bK GXwGPWDUskdx9aQAI4xaSnoRplzcK6JdQn/DDSpkiV3HAI4sSc1/KcHxYKoLWtlZexf+ KulUUaYKSjd/jjDmAle6JxWVZMFG/OWK1VCtk= Received: by 10.86.25.17 with SMTP id 17mr2391889fgy.50.1213282214095; Thu, 12 Jun 2008 07:50:14 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Thu, 12 Jun 2008 07:50:14 -0700 (PDT) Message-ID: <6101e8c40806120750r46f92c64tb4ac27d91163c07d@mail.gmail.com> Date: Thu, 12 Jun 2008 16:50:14 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: [XFS] oss.sgi Subject: Re: [XFS] oss.sgi Cc: "Christoph Hellwig" , xfs@oss.sgi.com In-Reply-To: <484F0594.1010406@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> <20080610122420.GA15871@infradead.org> <6101e8c40806101451tb160ed8rc0ba2739cafee84f@mail.gmail.com> <484F0594.1010406@sandeen.net> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.159] X-Barracuda-Start-Time: 1213282216 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3292 1.0000 -0.2296 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.23 X-Barracuda-Spam-Status: No, SCORE=-0.23 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53097 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16314 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs nothing strange, only that how much developed. I observe it otherwise in lkml or in git-logs ;) On 6/11/08, Eric Sandeen wrote: > Oliver Pinter wrote: >> hi! >> >> thanks the info >> >> On 6/10/08, Christoph Hellwig wrote: >>> On Tue, Jun 10, 2008 at 01:26:39PM +0200, Oliver Pinter wrote: >>>> Hi All! >>>> >>>> is the http://oss.sgi.com/projects/xfs/ site up to date? >>> More or less. It could have a few more recent news items or reference >>> to presentations from the last few month, but I can't find anything >>> grossly out of date. > > Is there any info in particular that you wondered about? :) > > -Eric > -- Thanks, Oliver From owner-xfs@oss.sgi.com Thu Jun 12 09:53:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 09:53:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CGrTnJ005405 for ; Thu, 12 Jun 2008 09:53:29 -0700 X-ASG-Debug-ID: 1213289665-65ed03c40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0D39E21EE0C for ; Thu, 12 Jun 2008 09:54:25 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.123]) by cuda.sgi.com with ESMTP id vAesacvkSc2e7Jgg for ; Thu, 12 Jun 2008 09:54:25 -0700 (PDT) Received: from www.structurenet.com ([74.68.50.165]) by hrndva-omta03.mail.rr.com with ESMTP id <20080612165424.OOUT29933.hrndva-omta03.mail.rr.com@www.structurenet.com> for ; Thu, 12 Jun 2008 16:54:24 +0000 Received: from 38.117.134.222 (proxying for unknown) (SquirrelMail authenticated user bshi) by www.structurenet.com with HTTP; Thu, 12 Jun 2008 12:54:24 -0400 (EDT) Message-ID: <37328.38.117.134.222.1213289664.squirrel@www.structurenet.com> In-Reply-To: <9E397A467F4DB34884A1FD0D5D27CF43018903F96E@msxaoa4.twosigma.com> References: <9E397A467F4DB34884A1FD0D5D27CF43018903F96E@msxaoa4.twosigma.com> Date: Thu, 12 Jun 2008 12:54:24 -0400 (EDT) X-ASG-Orig-Subj: Re: several messages Subject: Re: several messages From: "Benjamin L. Shi" To: xfs@oss.sgi.com Reply-To: bshi@structurenet.com User-Agent: SquirrelMail/1.4.6-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.123] X-Barracuda-Start-Time: 1213289666 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4909 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53105 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16315 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bshi@structurenet.com Precedence: bulk X-list: xfs Index: fs/xfs/xfs_iomap.c =================================================================== RCS file: /src/linux/2.6.18/fs/xfs/xfs_iomap.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- fs/xfs/xfs_iomap.c 29 Sep 2006 13:45:19 -0000 1.1.1.1 +++ fs/xfs/xfs_iomap.c 12 Jun 2008 15:59:10 -0000 1.2 @@ -706,11 +706,24 @@ * then we must have run out of space - flush delalloc, and retry.. */ if (nimaps == 0) { + if ((mp->m_flags & XFS_MOUNT_FULL) != 0) { + if (mp->m_sb.sb_fdblocks < 500) { + // printk("full again %llu\n", + // mp->m_sb.sb_fdblocks); + return XFS_ERROR(ENOSPC); + } else { + // printk("not full again %llu\n", + // mp->m_sb.sb_fdblocks); + mp->m_flags &= ~XFS_MOUNT_FULL; + } + } xfs_iomap_enter_trace(XFS_IOMAP_WRITE_NOSPACE, io, offset, count); - if (xfs_flush_space(ip, &fsynced, &ioflag)) + if (xfs_flush_space(ip, &fsynced, &ioflag)) { + mp->m_flags |= XFS_MOUNT_FULL; + //printk("set full %llu\n", mp->m_sb.sb_fdblocks); return XFS_ERROR(ENOSPC); - + } error = 0; goto retry; } Index: fs/xfs/xfs_mount.h =================================================================== RCS file: /src/linux/2.6.18/fs/xfs/xfs_mount.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- fs/xfs/xfs_mount.h 29 Sep 2006 13:45:19 -0000 1.1.1.1 +++ fs/xfs/xfs_mount.h 12 Jun 2008 15:59:10 -0000 1.2 @@ -459,6 +459,7 @@ * I/O size in stat() */ #define XFS_MOUNT_NO_PERCPU_SB (1ULL << 23) /* don't use per-cpu superblock counters */ +#define XFS_MOUNT_FULL (1ULL << 24) /* > > On Fri, 6 Oct 2006, David Chinner wrote: > >>> The backtrace looked like this: >>> >>> ... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev >>> xfs_file_writev >>> xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks >>> xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space >>> xfs_flush_device >>> schedule_timeout_uninterruptible. >> >> Ahhh, this gets hit on the ->prepare_write path >> (xfs_iomap_write_delay()), > > Yes. > >> not the allocate path (xfs_iomap_write_allocate()). Sorry - I got myself >> (and probably everyone else) confused there which why I suspected sync >> writes - they trigger the allocate path in the write call. I don't think >> 2.6.18 will change anything. >> >> FWIW, I don't think we can avoid this sleep when we first hit ENOSPC >> conditions, but perhaps once we are certain of the ENOSPC status >> we can tag the filesystem with this state (say an xfs_mount flag) >> and only clear that tag when something is freed. We could then >> use the tag to avoid continually trying extremely hard to allocate >> space when we know there is none available.... > > Yes! That's what I was trying to suggest << OLE Object: Picture (Device > Independent Bitmap) >> . Thank you. > > Is that hard to do? > From owner-xfs@oss.sgi.com Thu Jun 12 10:08:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 10:08:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, KB_DATE_CONTAINS_TAB autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CH8DU1006716 for ; Thu, 12 Jun 2008 10:08:14 -0700 X-ASG-Debug-ID: 1213290545-0fe702910000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp3.poczta.onet.pl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DEF6421F065 for ; Thu, 12 Jun 2008 10:09:06 -0700 (PDT) Received: from smtp3.poczta.onet.pl (smtp3.poczta.onet.pl [213.180.130.29]) by cuda.sgi.com with ESMTP id 5cDj4ExCN99Yj3FA for ; Thu, 12 Jun 2008 10:09:06 -0700 (PDT) Received: from rudy.mif.pg.gda.pl ([153.19.42.16]:34410 "EHLO orion.wszechswiat.org" rhost-flags-OK-OK-OK-FAIL) by ps3.test.onet.pl with ESMTPSA id S184555754AbYFLRJD4bzAh (ORCPT ); Thu, 12 Jun 2008 19:09:03 +0200 Message-ID: <485157D2.5050906@op.pl> Date: Thu, 12 Jun 2008 19:07:30 +0200 From: Bogdan User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Does XFS support sharing blocks? Subject: Does XFS support sharing blocks? X-Enigmail-Version: 0.95.6 OpenPGP: url=http://rudy.mif.pg.gda.pl/~bogdro/bogdan_publiczny.asc Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp3.poczta.onet.pl[213.180.130.29] X-Barracuda-Start-Time: 1213290546 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4983 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53105 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16316 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bogdandr@op.pl Precedence: bulk X-list: xfs Hello. I have a question: does the XFS filesystem support sharing blocks between objects (files, symlinks, fifos, ...). I mean, can 2 distinct objects have their data inside one physical block? If not, what is the "offset" field for in xfs_db output: xfs_db> inode 19331 xfs_db> bmap -d data offset 0 startblock 1212 (0/1212) count 1 flag 0 -- Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS) Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32 www.JabberPL.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft From owner-xfs@oss.sgi.com Thu Jun 12 13:15:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 13:15:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CKFMSD024730 for ; Thu, 12 Jun 2008 13:15:51 -0700 X-ASG-Debug-ID: 1213301778-7f2a02190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C410ECA056D for ; Thu, 12 Jun 2008 13:16:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id v4Fcv4D4YOgl6xnt for ; Thu, 12 Jun 2008 13:16:19 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5CKGG7N004573; Thu, 12 Jun 2008 16:16:16 -0400 Received: from file.rdu.redhat.com (file.rdu.redhat.com [10.11.255.147]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5CKGFnC002079; Thu, 12 Jun 2008 16:16:15 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by file.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id m5CKGFBL006639; Thu, 12 Jun 2008 16:16:15 -0400 Message-ID: <4851840F.6060404@sandeen.net> Date: Thu, 12 Jun 2008 15:16:15 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Bogdan CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Does XFS support sharing blocks? Subject: Re: Does XFS support sharing blocks? References: <485157D2.5050906@op.pl> In-Reply-To: <485157D2.5050906@op.pl> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1213301779 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16317 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Bogdan wrote: > Hello. > > I have a question: does the XFS filesystem support sharing blocks > between objects (files, symlinks, fifos, ...). I mean, can 2 distinct > objects have their data inside one physical block? If not, what is the > "offset" field for in xfs_db output: > > xfs_db> inode 19331 > xfs_db> bmap -d > data offset 0 startblock 1212 (0/1212) count 1 flag 0 it's simply the block number in the file. You have a 1 block file, it's first (and only) block is at physical block 1212 (block 1212 in AG 0) -Eric From owner-xfs@oss.sgi.com Thu Jun 12 15:19:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 15:19:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CMJd7p030755 for ; Thu, 12 Jun 2008 15:19:39 -0700 X-ASG-Debug-ID: 1213309234-6c67034e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2D124C898AD for ; Thu, 12 Jun 2008 15:20:34 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id gFi9ZmKwJ9lXWcM2 for ; Thu, 12 Jun 2008 15:20:34 -0700 (PDT) Received: (qmail 10972 invoked from network); 12 Jun 2008 22:20:31 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jun 2008 22:20:31 -0000 Message-ID: <4851A36B.6030404@sauce.co.nz> Date: Fri, 13 Jun 2008 10:30:03 +1200 From: Richard Scobie 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: xfs@oss.sgi.com X-ASG-Orig-Subj: mkfs.xfs man page Subject: mkfs.xfs man page Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1213309236 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3555 1.0000 -0.1337 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.13 X-Barracuda-Spam-Status: No, SCORE=-0.13 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16318 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs The latest xfsprogs, 2.9.8-1 makes no mention of the "-d unwritten" option in the mkfs.xfs man page. Not sure if this is by design or not. Regards, Richard From owner-xfs@oss.sgi.com Thu Jun 12 15:26:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 15:26:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CMQGbl031300 for ; Thu, 12 Jun 2008 15:26:17 -0700 X-ASG-Debug-ID: 1213309631-067200680000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-vbr13.xs4all.nl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DD1892247B4 for ; Thu, 12 Jun 2008 15:27:11 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by cuda.sgi.com with ESMTP id catjtT6wkQ6RhTkS for ; Thu, 12 Jun 2008 15:27:11 -0700 (PDT) Received: from [192.168.1.129] (a82-95-163-142.adsl.xs4all.nl [82.95.163.142]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id m5CMR9XU081056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 00:27:09 +0200 (CEST) (envelope-from mikevs@xs4all.net) X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c From: Miquel van Smoorenburg To: Oliver Pinter Cc: lists@ku-gbr.de, linux-kernel@vger.kernel.org, Christoph Hellwig , xfs@oss.sgi.com, xfs-masters@oss.sgi.com, mikevs@xs4all.net In-Reply-To: <6101e8c40806120733m3c8647ccy149eb237e2c6d027@mail.gmail.com> References: <20080612123031.21594jyk6rjc1lfk@imp.ku-gbr.de> <6101e8c40806120733m3c8647ccy149eb237e2c6d027@mail.gmail.com> Content-Type: text/plain Date: Fri, 13 Jun 2008 00:27:09 +0200 Message-Id: <1213309629.29745.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by XS4ALL Virus Scanner X-Barracuda-Connect: smtp-vbr13.xs4all.nl[194.109.24.33] X-Barracuda-Start-Time: 1213309632 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53127 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16319 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikevs@xs4all.net Precedence: bulk X-list: xfs On Thu, 2008-06-12 at 16:33 +0200, Oliver Pinter wrote: > add CC's > > On 6/12/08, lists@ku-gbr.de wrote: > > Hi! > > > > Today morning my server at home bailed out two times (reboot between): > > Jun 12 07:23:40 zappa > > Jun 12 07:23:40 zappa xfs_force_shutdown(sda7,0x8) called from line > > 1164 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff802f4d8a > > Jun 12 07:23:40 zappa Filesystem "sda7": Corruption of in-memory data > > detected. Shutting down filesystem: sda7 > > Jun 12 07:23:40 zappa Please umount the filesystem, and rectify the > > problem(s) Hmm, interesting. I'm seeing the same thing on one of my servers since I upgraded from 2.6.ancient (14 or so) to 2.6.25, while XFS otherwise has been very stable for me over the years: Linux transit5.news.xs4all.nl 2.6.25.6 #1 SMP Wed Jun 11 10:59:10 CEST 2008 x86_64 GNU/Linux Filesystem "sda4": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xffffffff880f1315 Pid: 3402, comm: diablo Not tainted 2.6.25.6 #1 Call Trace: [] :xfs:xfs_create+0x1e5/0x520 [] :xfs:xfs_trans_cancel+0x126/0x150 [] :xfs:xfs_create+0x1e5/0x520 [] :xfs:xfs_vn_mknod+0x1d9/0x320 [] vfs_create+0xac/0xf0 [] open_namei+0x61d/0x6c0 [] autoremove_wake_function+0x0/0x30 [] do_filp_open+0x1c/0x50 [] get_unused_fd_flags+0x79/0x120 [] do_sys_open+0x5a/0xf0 [] system_call_after_swapgs+0x7b/0x80 xfs_force_shutdown(sda4,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff880ea4bf Filesystem "sda4": Corruption of in-memory data detected. Shutting down filesystem: sda4 Please umount the filesystem, and rectify the problem(s) After a reboot, xfs_repair didn't find anything wrong with the fs. It has happened 3 times over the last few days already. FS is on a local SCSI raid (dpt_i2o), not SATA. Mike. From owner-xfs@oss.sgi.com Thu Jun 12 15:30:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 15:31:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CMUu8Y031826 for ; Thu, 12 Jun 2008 15:30:56 -0700 X-ASG-Debug-ID: 1213309913-1cf001bc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6DCF117BA8D6 for ; Thu, 12 Jun 2008 15:31:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id oUkZDMN0HUDcjNCW for ; Thu, 12 Jun 2008 15:31:53 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5CMVqFB017233; Thu, 12 Jun 2008 18:31:52 -0400 Received: from file.rdu.redhat.com (file.rdu.redhat.com [10.11.255.147]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5CMVphn011121; Thu, 12 Jun 2008 18:31:51 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by file.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id m5CMVp9p001563; Thu, 12 Jun 2008 18:31:51 -0400 Message-ID: <4851A3D6.809@sandeen.net> Date: Thu, 12 Jun 2008 17:31:50 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Richard Scobie CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mkfs.xfs man page Subject: Re: mkfs.xfs man page References: <4851A36B.6030404@sauce.co.nz> In-Reply-To: <4851A36B.6030404@sauce.co.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1213309913 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16320 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Richard Scobie wrote: > The latest xfsprogs, 2.9.8-1 makes no mention of the "-d unwritten" > option in the mkfs.xfs man page. > > Not sure if this is by design or not. > > Regards, > > Richard It is intentional: http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/mkfs.xfs.8#rev1.30 Thanks, -Eric From owner-xfs@oss.sgi.com Thu Jun 12 18:31:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 18:31:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D1VaTF012934 for ; Thu, 12 Jun 2008 18:31:36 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay1.corp.sgi.com (Postfix) with ESMTP id D14678F80C0; Thu, 12 Jun 2008 18:32:29 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D1WGjm1929339; Fri, 13 Jun 2008 11:32:21 +1000 (AEST) Message-ID: <4851CD32.7080106@melbourne.sgi.com> Date: Fri, 13 Jun 2008 11:28:18 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> In-Reply-To: <48512A34.1020604@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16321 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Eric Sandeen wrote: > >> Timothy Shimmin wrote: >> >> >>> (1) It would be nice to know what the state of the apps really are. >>> There is also the question of interaction with CXFS and NFS. >>> Greg Banks has a compat matrix for NFS. It looks like the main >>> things is to get something half recent - linux 2.6, nfs v3, >>> apps which use 64 bit sys calls (eg. stat64) etc... >>> Would need to do investigating. >>> >> Greg has a tool to scan binaries... some day I'm going to run it over >> the fedora universe, I'll get back to you... someday. >> > > someday didn't take too long :) Cool, thanks for the data Eric. > but it ain't pretty. > > I installed all fedora packages under a directory and ran greg's tool over: > > /sbin /usr/sbin /bin /usr/bin /usr/kerberos/bin/ /usr/kerberos/sbin/ > > Aggregate results: > > 4070 29.1% are scripts (shell, perl, whatever) > 6598 47.2% don't use any stat() family calls at all > 1829 13.1% use 32-bit stat() family interfaces only > 1312 9.4% use 64-bit stat64() family interfaces only > 180 1.3% use both 32-bit and 64-bit stat() family interfaces > Ouch. That's over two thousand executables to patch, rebuild, and ship. > list of packages, sorted by the semi-lame "number of files in package > which call a 32-bit stat variant" metric: > > http://sandeen.fedorapeople.org/stat32-ers > > I'm going to see if I can't leverage Fedora to clean some of this up. > > -Eric > Good luck with that. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. From owner-xfs@oss.sgi.com Thu Jun 12 20:05:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:05:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3595H017479 for ; Thu, 12 Jun 2008 20:05:09 -0700 X-ASG-Debug-ID: 1213326365-76e1036f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 84FB517BB82D for ; Thu, 12 Jun 2008 20:06:05 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 2HqD5gTVXznzLWCx for ; Thu, 12 Jun 2008 20:06:05 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 968AAA9BF45; Thu, 12 Jun 2008 22:06:04 -0500 (CDT) Message-ID: <4851E41C.6050108@sandeen.net> Date: Thu, 12 Jun 2008 22:06:04 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Greg Banks CC: Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> In-Reply-To: <4851CD32.7080106@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213326365 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0208 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53144 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16322 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Greg Banks wrote: > Eric Sandeen wrote: > Cool, thanks for the data Eric. > >> but it ain't pretty. >> >> I installed all fedora packages under a directory and ran greg's tool over: >> >> /sbin /usr/sbin /bin /usr/bin /usr/kerberos/bin/ /usr/kerberos/sbin/ >> >> Aggregate results: >> >> 4070 29.1% are scripts (shell, perl, whatever) >> 6598 47.2% don't use any stat() family calls at all >> 1829 13.1% use 32-bit stat() family interfaces only >> 1312 9.4% use 64-bit stat64() family interfaces only >> 180 1.3% use both 32-bit and 64-bit stat() family interfaces >> > Ouch. That's over two thousand executables to patch, rebuild, and ship. >> list of packages, sorted by the semi-lame "number of files in package >> which call a 32-bit stat variant" metric: >> >> http://sandeen.fedorapeople.org/stat32-ers And about 900 packages... >> I'm going to see if I can't leverage Fedora to clean some of this up. >> >> -Eric >> > Good luck with that. Heh :) At first I was just going to correlate with st_ino users to cut it down, but then I learned that glibc will actually give you an EOVERFLOW if, say st_ino overflows, even if you were only going to check st_mode. :( So pretty much everything needs fixing. (FWIW I gathered statfs/statvfs calls, too...) -Eric From owner-xfs@oss.sgi.com Thu Jun 12 20:19:33 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:19:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D3JUUa023007 for ; Thu, 12 Jun 2008 20:19:31 -0700 Received: from [134.14.55.22] (dhcp22.melbourne.sgi.com [134.14.55.22]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11274; Fri, 13 Jun 2008 13:20:20 +1000 Message-ID: <4851E774.2070401@sgi.com> Date: Fri, 13 Jun 2008 13:20:20 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Greg Banks CC: Eric Sandeen , Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> In-Reply-To: <4851CD32.7080106@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16323 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Greg Banks wrote: > Eric Sandeen wrote: >> 4070 29.1% are scripts (shell, perl, whatever) >> 6598 47.2% don't use any stat() family calls at all >> 1829 13.1% use 32-bit stat() family interfaces only >> 1312 9.4% use 64-bit stat64() family interfaces only >> 180 1.3% use both 32-bit and 64-bit stat() family interfaces >> > Ouch. That's over two thousand executables to patch, rebuild, and ship. >> list of packages, sorted by the semi-lame "number of files in package >> which call a 32-bit stat variant" metric: >> >> http://sandeen.fedorapeople.org/stat32-ers struct dirent has an embedded ino_t too, so for completeness we should also be looking for readdir(), readdir64(), getdirentries(), getdirentries64(), etc. >> I'm going to see if I can't leverage Fedora to clean some of this up. >> >> -Eric >> > Good luck with that. Yes good luck :) (and the plan for statically linked apps? ...) Cheers -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Thu Jun 12 20:27:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:27:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3RjQn023668 for ; Thu, 12 Jun 2008 20:27:46 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 46EB29088C; Thu, 12 Jun 2008 20:28:38 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D3SSjm1952859; Fri, 13 Jun 2008 13:28:32 +1000 (AEST) Message-ID: <4851E86E.6030203@melbourne.sgi.com> Date: Fri, 13 Jun 2008 13:24:30 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E41C.6050108@sandeen.net> In-Reply-To: <4851E41C.6050108@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16324 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > > Heh :) At first I was just going to correlate with st_ino users to cut > it down, but then I learned that glibc will actually give you an > EOVERFLOW if, say st_ino overflows, even if you were only going to check > st_mode. :( So pretty much everything needs fixing. > Of course. There's no way for the app to tell glibc that the app doesn't care about st_ino, so glibc must assume that glibc needs to return an accurate st_ino. The alternative is to return the lower 32 bits of st_ino, thus causing silent subtle failures in the very small number of applications which actually do something with st_ino. This is what glibc used to do back when I first started tracking the issue. > (FWIW I gathered statfs/statvfs calls, too...) > > Yes. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. From owner-xfs@oss.sgi.com Thu Jun 12 20:43:43 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:43:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3hheT024452 for ; Thu, 12 Jun 2008 20:43:43 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 2E0849088C; Thu, 12 Jun 2008 20:44:39 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D3iQjm1940596; Fri, 13 Jun 2008 13:44:28 +1000 (AEST) Message-ID: <4851EC2D.6010504@melbourne.sgi.com> Date: Fri, 13 Jun 2008 13:40:29 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: markgw@sgi.com CC: Eric Sandeen , Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> In-Reply-To: <4851E774.2070401@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16325 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs Mark Goodwin wrote: > > > Greg Banks wrote: >> Eric Sandeen wrote: >>> 4070 29.1% are scripts (shell, perl, whatever) >>> 6598 47.2% don't use any stat() family calls at all >>> 1829 13.1% use 32-bit stat() family interfaces only >>> 1312 9.4% use 64-bit stat64() family interfaces only >>> 180 1.3% use both 32-bit and 64-bit stat() family interfaces >>> >> Ouch. That's over two thousand executables to patch, rebuild, and ship. >>> list of packages, sorted by the semi-lame "number of files in package >>> which call a 32-bit stat variant" metric: >>> >>> http://sandeen.fedorapeople.org/stat32-ers > > struct dirent has an embedded ino_t too, so for completeness we should > also > be looking for readdir(), readdir64(), getdirentries(), > getdirentries64(), etc. Good point. Looking in the code, it seems the getdents common code in glibc will fail with EOVERFLOW if the inode number gets truncated during 64b-32b translation, just like the stat() family. I'll need to improve the scanning tool :-) > >>> I'm going to see if I can't leverage Fedora to clean some of this up. >>> >>> -Eric >>> >> Good luck with that. > > Yes good luck :) > (and the plan for statically linked apps? ...) Perhaps Fedora could enable the glibc magic for issuing warnings at link time when those symbols are used, like what happens today if you use the old unsafe gets() function: gnb@inara 1058> gcc -o fmeh x.c /tmp/ccQhxIIo.o: In function `main': x.c:(.text+0x18): warning: the `gets' function is dangerous and should not be used. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. From owner-xfs@oss.sgi.com Thu Jun 12 20:44:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:44:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3iG0R024640 for ; Thu, 12 Jun 2008 20:44:16 -0700 X-ASG-Debug-ID: 1213328712-39c601d50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F38C3C9CEF5 for ; Thu, 12 Jun 2008 20:45:12 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id VlblGYitsfNF5oOf for ; Thu, 12 Jun 2008 20:45:12 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id D1DF2A9C502; Thu, 12 Jun 2008 22:45:11 -0500 (CDT) Message-ID: <4851ED48.90103@sandeen.net> Date: Thu, 12 Jun 2008 22:45:12 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Greg Banks , Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> In-Reply-To: <4851E774.2070401@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213328712 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0190 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53147 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16326 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Goodwin wrote: > struct dirent has an embedded ino_t too, so for completeness we should also > be looking for readdir(), readdir64(), getdirentries(), > getdirentries64(), etc. *sigh* >>> I'm going to see if I can't leverage Fedora to clean some of this up. >>> >>> -Eric >>> >> Good luck with that. > > Yes good luck :) > (and the plan for statically linked apps? ...) I plan to encourage fedora to keep discouraging them ;) -Eric From owner-xfs@oss.sgi.com Thu Jun 12 20:46:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:46:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3k3sX025191 for ; Thu, 12 Jun 2008 20:46:03 -0700 X-ASG-Debug-ID: 1213328819-2cdd01e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E1B9722535C for ; Thu, 12 Jun 2008 20:46:59 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 7JrKy4o2hjiICQXo for ; Thu, 12 Jun 2008 20:46:59 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 1372CA9C502; Thu, 12 Jun 2008 22:46:59 -0500 (CDT) Message-ID: <4851EDB3.1010601@sandeen.net> Date: Thu, 12 Jun 2008 22:46:59 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Greg Banks CC: markgw@sgi.com, Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> <4851EC2D.6010504@melbourne.sgi.com> In-Reply-To: <4851EC2D.6010504@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213328819 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0006 1.0000 -2.0170 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53148 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16327 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Greg Banks wrote: >> (and the plan for statically linked apps? ...) > > Perhaps Fedora could enable the glibc magic for issuing warnings at link > time when those symbols are used, like what happens today if you use the > old unsafe gets() function: > > gnb@inara 1058> gcc -o fmeh x.c > /tmp/ccQhxIIo.o: In function `main': > x.c:(.text+0x18): warning: the `gets' function is dangerous and should not be used. It wouldn't help the automated builds (nobody'd see it) but for normal user compilations that might be an option... -Eric From owner-xfs@oss.sgi.com Thu Jun 12 21:00:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 21:00:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D40foY026016 for ; Thu, 12 Jun 2008 21:00:41 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 9F71C9089F; Thu, 12 Jun 2008 21:01:34 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D41Mjm1957704; Fri, 13 Jun 2008 14:01:27 +1000 (AEST) Message-ID: <4851F024.7020508@melbourne.sgi.com> Date: Fri, 13 Jun 2008 13:57:24 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: markgw@sgi.com, Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> <4851EC2D.6010504@melbourne.sgi.com> <4851EDB3.1010601@sandeen.net> In-Reply-To: <4851EDB3.1010601@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16328 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Greg Banks wrote: > > >>> (and the plan for statically linked apps? ...) >>> >> Perhaps Fedora could enable the glibc magic for issuing warnings at link >> time when those symbols are used, like what happens today if you use the >> old unsafe gets() function: >> >> gnb@inara 1058> gcc -o fmeh x.c >> /tmp/ccQhxIIo.o: In function `main': >> x.c:(.text+0x18): warning: the `gets' function is dangerous and should not be used. >> > > > It wouldn't help the automated builds (nobody'd see it) Hmm. I don't see a way in glibc to upgrade that warning to an error to make those builds fail, at least in glibc 2.4. > but for normal > user compilations that might be an option... > > Indeed. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. From owner-xfs@oss.sgi.com Thu Jun 12 21:09:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 21:09:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D492k4026552 for ; Thu, 12 Jun 2008 21:09:03 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12158; Fri, 13 Jun 2008 14:09:48 +1000 Message-ID: <4851F30C.4000108@sgi.com> Date: Fri, 13 Jun 2008 14:09:48 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr References: <20080603114837.GB2703@lst.de> In-Reply-To: <20080603114837.GB2703@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16329 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs This appears to break xfstests/063 (EA xfsdump test). Will look into it. --Tim Christoph Hellwig wrote: > This patch switches xfs_vn_listxattr to set it's put_listent callback > directly and not go through xfs_attr_list. > > The changes to the lowleve attr code are: > > - the put_listent callback now gets the ondisk flags passed and > performce the namespace lookup and check aswell as the check > for the right attribute root itself > - xfs_attr_list_int is made non-static for use by other callers > than xfs_attr_list and now performs the inode locking and tracing > itself > > The changes to the xfs_attr_list path are: > > - all checks for now uneeded ATTR_KERN flags are gone, and only > the IRIX interface is supported for this code path > - xfs_attr_put_listent is simplified by not needing to lookup > the namespace but rather compare the integer flags directly. > > The changes to xfs_vn_listxattr are: > > - now directly calls xfs_attr_list_int with it's own put_listent > callbacks > - attr namespace prefix are now looked up by simple helpers, > struct attrnames is gone. > > Other changes: > > - struct xfs_attr_list_context is moved from xfs_attr_leaf.h into > xfs_attr.h. It's not realted to the leaf format at all and > xfs_attr.h contains the interface to the attr code which it is > part of now. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_attr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:44:07.000000000 +0200 > @@ -16,8 +16,6 @@ > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > */ > > -#include > - > #include "xfs.h" > #include "xfs_fs.h" > #include "xfs_types.h" > @@ -607,12 +605,20 @@ xfs_attr_remove( > return xfs_attr_remove_int(dp, &xname, flags); > } > > -STATIC int > +int > xfs_attr_list_int(xfs_attr_list_context_t *context) > { > int error; > xfs_inode_t *dp = context->dp; > > + XFS_STATS_INC(xs_attr_list); > + > + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > + return EIO; > + > + xfs_ilock(dp, XFS_ILOCK_SHARED); > + xfs_attr_trace_l_c("syscall start", context); > + > /* > * Decide on what work routines to call based on the inode size. > */ > @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ > } else { > error = xfs_attr_node_list(context); > } > + > + xfs_iunlock(dp, XFS_ILOCK_SHARED); > + xfs_attr_trace_l_c("syscall end", context); > + > return error; > } > > @@ -634,6 +644,18 @@ xfs_attr_list_int(xfs_attr_list_context_ > ((ATTR_ENTBASESIZE + (namelen) + 1 + sizeof(u_int32_t)-1) \ > & ~(sizeof(u_int32_t)-1)) > > +STATIC int > +xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) > +{ > + if (((arg_flags & ATTR_SECURE) == 0) != > + ((ondisk_flags & XFS_ATTR_SECURE) == 0)) > + return 0; > + if (((arg_flags & ATTR_ROOT) == 0) != > + ((ondisk_flags & XFS_ATTR_ROOT) == 0)) > + return 0; > + return 1; > +} > + > /* > * Format an attribute and copy it out to the user's buffer. > * Take care to check values and protect against them changing later, > @@ -641,74 +663,43 @@ xfs_attr_list_int(xfs_attr_list_context_ > */ > /*ARGSUSED*/ > STATIC int > -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, > +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, > char *name, int namelen, > int valuelen, char *value) > { > + struct attrlist *alist = (struct attrlist *)context->alist; > attrlist_ent_t *aep; > int arraytop; > > ASSERT(!(context->flags & ATTR_KERNOVAL)); > ASSERT(context->count >= 0); > ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); > - ASSERT(context->firstu >= sizeof(*context->alist)); > + ASSERT(context->firstu >= sizeof(*alist)); > ASSERT(context->firstu <= context->bufsize); > > - arraytop = sizeof(*context->alist) + > - context->count * sizeof(context->alist->al_offset[0]); > + if (xfs_attr_namesp_match_overrides(context->flags, flags)) > + return 0; > + > + arraytop = sizeof(*alist) + > + context->count * sizeof(alist->al_offset[0]); > context->firstu -= ATTR_ENTSIZE(namelen); > if (context->firstu < arraytop) { > xfs_attr_trace_l_c("buffer full", context); > - context->alist->al_more = 1; > + alist->al_more = 1; > context->seen_enough = 1; > return 1; > } > > - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); > + aep = (attrlist_ent_t *)&context->alist[context->firstu]; > aep->a_valuelen = valuelen; > memcpy(aep->a_name, name, namelen); > - aep->a_name[ namelen ] = 0; > - context->alist->al_offset[ context->count++ ] = context->firstu; > - context->alist->al_count = context->count; > + aep->a_name[namelen] = 0; > + alist->al_offset[context->count++] = context->firstu; > + alist->al_count = context->count; > xfs_attr_trace_l_c("add", context); > return 0; > } > > -STATIC int > -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, > - char *name, int namelen, > - int valuelen, char *value) > -{ > - char *offset; > - int arraytop; > - > - ASSERT(context->count >= 0); > - > - arraytop = context->count + namesp->attr_namelen + namelen + 1; > - if (arraytop > context->firstu) { > - context->count = -1; /* insufficient space */ > - return 1; > - } > - offset = (char *)context->alist + context->count; > - strncpy(offset, namesp->attr_name, namesp->attr_namelen); > - offset += namesp->attr_namelen; > - strncpy(offset, name, namelen); /* real name */ > - offset += namelen; > - *offset = '\0'; > - context->count += namesp->attr_namelen + namelen + 1; > - return 0; > -} > - > -/*ARGSUSED*/ > -STATIC int > -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, > - char *name, int namelen, > - int valuelen, char *value) > -{ > - context->count += namesp->attr_namelen + namelen + 1; > - return 0; > -} > - > /* > * Generate a list of extended attribute names and optionally > * also value lengths. Positive return value follows the XFS > @@ -725,10 +716,9 @@ xfs_attr_list( > attrlist_cursor_kern_t *cursor) > { > xfs_attr_list_context_t context; > + struct attrlist *alist; > int error; > > - XFS_STATS_INC(xs_attr_list); > - > /* > * Validate the cursor. > */ > @@ -749,52 +739,21 @@ xfs_attr_list( > /* > * Initialize the output buffer. > */ > + memset(&context, 0, sizeof(context)); > context.dp = dp; > context.cursor = cursor; > - context.count = 0; > - context.dupcnt = 0; > context.resynch = 1; > context.flags = flags; > - context.seen_enough = 0; > - context.alist = (attrlist_t *)buffer; > - context.put_value = 0; > - > - if (flags & ATTR_KERNAMELS) { > - context.bufsize = bufsize; > - context.firstu = context.bufsize; > - if (flags & ATTR_KERNOVAL) > - context.put_listent = xfs_attr_kern_list_sizes; > - else > - context.put_listent = xfs_attr_kern_list; > - } else { > - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ > - context.firstu = context.bufsize; > - context.alist->al_count = 0; > - context.alist->al_more = 0; > - context.alist->al_offset[0] = context.bufsize; > - context.put_listent = xfs_attr_put_listent; > - } > - > - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > - return EIO; > + context.alist = buffer; > + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ > + context.firstu = context.bufsize; > + context.put_listent = xfs_attr_put_listent; > > - xfs_ilock(dp, XFS_ILOCK_SHARED); > - xfs_attr_trace_l_c("syscall start", &context); > + alist = (struct attrlist *)context.alist; > + alist->al_offset[0] = context.bufsize; > > error = xfs_attr_list_int(&context); > - > - xfs_iunlock(dp, XFS_ILOCK_SHARED); > - xfs_attr_trace_l_c("syscall end", &context); > - > - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { > - /* must return negated buffer size or the error */ > - if (context.count < 0) > - error = XFS_ERROR(ERANGE); > - else > - error = -context.count; > - } else > - ASSERT(error >= 0); > - > + ASSERT(error >= 0); > return error; > } > > @@ -2357,12 +2316,7 @@ xfs_attr_trace_enter(int type, char *whe > (void *)((__psunsigned_t)context->bufsize), > (void *)((__psunsigned_t)context->count), > (void *)((__psunsigned_t)context->firstu), > - (void *)((__psunsigned_t) > - (((context->count > 0) && > - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) > - ? (ATTR_ENTRY(context->alist, > - context->count-1)->a_valuelen) > - : 0)), > + NULL, > (void *)((__psunsigned_t)context->dupcnt), > (void *)((__psunsigned_t)context->flags), > (void *)a13, (void *)a14, (void *)a15); > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:44:07.000000000 +0200 > @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att > * Namespace helper routines > *========================================================================*/ > > -STATIC_INLINE attrnames_t * > -xfs_attr_flags_namesp(int flags) > -{ > - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: > - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); > -} > - > /* > * If namespace bits don't match return 0. > * If all match then return 1. > @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int > return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); > } > > -/* > - * If namespace bits don't match and we don't have an override for it > - * then return 0. > - * If all match or are overridable then return 1. > - */ > -STATIC_INLINE int > -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) > -{ > - if (((arg_flags & ATTR_SECURE) == 0) != > - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && > - !(arg_flags & ATTR_KERNORMALS)) > - return 0; > - if (((arg_flags & ATTR_ROOT) == 0) != > - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && > - !(arg_flags & ATTR_KERNROOTLS)) > - return 0; > - return 1; > -} > - > > /*======================================================================== > * External routines when attribute fork size < XFS_LITINO(mp). > @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co > (XFS_ISRESET_CURSOR(cursor) && > (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { > for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { > - attrnames_t *namesp; > - > - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { > - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); > - continue; > - } > - namesp = xfs_attr_flags_namesp(sfe->flags); > error = context->put_listent(context, > - namesp, > + sfe->flags, > (char *)sfe->nameval, > (int)sfe->namelen, > (int)sfe->valuelen, > @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co > kmem_free(sbuf); > return XFS_ERROR(EFSCORRUPTED); > } > - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { > - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); > - continue; > - } > + > sbp->entno = i; > sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); > sbp->name = (char *)sfe->nameval; > @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co > * Loop putting entries into the user buffer. > */ > for ( ; i < nsbuf; i++, sbp++) { > - attrnames_t *namesp; > - > - namesp = xfs_attr_flags_namesp(sbp->flags); > - > if (cursor->hashval != sbp->hash) { > cursor->hashval = sbp->hash; > cursor->offset = 0; > } > error = context->put_listent(context, > - namesp, > + sbp->flags, > sbp->name, > sbp->namelen, > sbp->valuelen, > @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > */ > retval = 0; > for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { > - attrnames_t *namesp; > - > if (be32_to_cpu(entry->hashval) != cursor->hashval) { > cursor->hashval = be32_to_cpu(entry->hashval); > cursor->offset = 0; > @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > > if (entry->flags & XFS_ATTR_INCOMPLETE) > continue; /* skip incomplete entries */ > - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) > - continue; > - > - namesp = xfs_attr_flags_namesp(entry->flags); > > if (entry->flags & XFS_ATTR_LOCAL) { > xfs_attr_leaf_name_local_t *name_loc = > XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); > > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_loc->nameval, > (int)name_loc->namelen, > be16_to_cpu(name_loc->valuelen), > @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > if (retval) > return retval; > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_rmt->name, > (int)name_rmt->namelen, > valuelen, > (char*)args.value); > kmem_free(args.value); > - } > - else { > + } else { > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_rmt->name, > (int)name_rmt->namelen, > valuelen, > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:44:07.000000000 +0200 > @@ -30,7 +30,6 @@ > > struct attrlist; > struct attrlist_cursor_kern; > -struct attrnames; > struct xfs_dabuf; > struct xfs_da_args; > struct xfs_da_state; > @@ -204,33 +203,6 @@ static inline int xfs_attr_leaf_entsize_ > return (((bsize) >> 1) + ((bsize) >> 2)); > } > > - > -/*======================================================================== > - * Structure used to pass context around among the routines. > - *========================================================================*/ > - > - > -struct xfs_attr_list_context; > - > -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, > - char *, int, int, char *); > - > -typedef struct xfs_attr_list_context { > - struct xfs_inode *dp; /* inode */ > - struct attrlist_cursor_kern *cursor; /* position in list */ > - struct attrlist *alist; /* output buffer */ > - int seen_enough; /* T/F: seen enough of list? */ > - int count; /* num used entries */ > - int dupcnt; /* count dup hashvals seen */ > - int bufsize; /* total buffer size */ > - int firstu; /* first used byte in buffer */ > - int flags; /* from VOP call */ > - int resynch; /* T/F: resynch with cursor */ > - int put_value; /* T/F: need value for listent */ > - put_listent_func_t put_listent; /* list output fmt function */ > - int index; /* index into output buffer */ > -} xfs_attr_list_context_t; > - > /* > * Used to keep a list of "remote value" extents when unlinking an inode. > */ > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:44:07.000000000 +0200 > @@ -17,7 +17,11 @@ > */ > > #include "xfs.h" > +#include "xfs_da_btree.h" > +#include "xfs_bmap_btree.h" > +#include "xfs_inode.h" > #include "xfs_attr.h" > +#include "xfs_attr_leaf.h" > #include "xfs_acl.h" > #include "xfs_vnodeops.h" > > @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, > return __xfs_xattr_set(inode, name, value, size, flags, 0); > } > > -struct attrnames attr_user = { > - .attr_name = "user.", > - .attr_namelen = sizeof("user.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_user_handler = { > .prefix = XATTR_USER_PREFIX, > .get = xfs_xattr_user_get, > @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod > return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); > } > > -struct attrnames attr_trusted = { > - .attr_name = "trusted.", > - .attr_namelen = sizeof("trusted.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_trusted_handler = { > .prefix = XATTR_TRUSTED_PREFIX, > .get = xfs_xattr_trusted_get, > @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode > return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); > } > > -struct attrnames attr_secure = { > - .attr_name = "security.", > - .attr_namelen = sizeof("security.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_security_handler = { > .prefix = XATTR_SECURITY_PREFIX, > .get = xfs_xattr_secure_get, > @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers > NULL > }; > > +static unsigned int xfs_attr_prefix_len(int flags) > +{ > + if (flags & XFS_ATTR_SECURE) > + return sizeof("security"); > + else if (flags & XFS_ATTR_ROOT) > + return sizeof("trusted"); > + else > + return sizeof("user"); > +} > + > +static const char *xfs_attr_prefix(int flags) > +{ > + if (flags & XFS_ATTR_SECURE) > + return xfs_xattr_security_handler.prefix; > + else if (flags & XFS_ATTR_ROOT) > + return xfs_xattr_trusted_handler.prefix; > + else > + return xfs_xattr_user_handler.prefix; > +} > + > +static int > +xfs_attr_kern_list(struct xfs_attr_list_context *context, int flags, > + char *name, int namelen, int valuelen, char *value) > +{ > + unsigned int prefix_len = xfs_attr_prefix_len(flags); > + char *offset; > + int arraytop; > + > + ASSERT(context->count >= 0); > + > + /* > + * Only show root namespace entries if we are actually allowed to > + * see them. > + */ > + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) > + return 0; > + > + arraytop = context->count + prefix_len + namelen + 1; > + if (arraytop > context->firstu) { > + context->count = -1; /* insufficient space */ > + return 1; > + } > + offset = (char *)context->alist + context->count; > + strncpy(offset, xfs_attr_prefix(flags), prefix_len); > + offset += prefix_len; > + strncpy(offset, name, namelen); /* real name */ > + offset += namelen; > + *offset = '\0'; > + context->count += prefix_len + namelen + 1; > + return 0; > +} > + > +static int > +xfs_attr_kern_list_sizes(struct xfs_attr_list_context *context, int flags, > + char *name, int namelen, int valuelen, char *value) > +{ > + context->count += xfs_attr_prefix_len(flags) + namelen + 1; > + return 0; > +} > + > static int > list_one_attr(const char *name, const size_t len, void *data, > size_t size, ssize_t *result) > @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si > ssize_t > xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) > { > + struct xfs_attr_list_context context; > + struct attrlist_cursor_kern cursor = { 0 }; > struct inode *inode = dentry->d_inode; > - struct xfs_inode *ip = XFS_I(inode); > - attrlist_cursor_kern_t cursor = { 0 }; > - int error, xflags; > - ssize_t result; > - > - xflags = ATTR_KERNAMELS; > - if (!size) > - xflags |= ATTR_KERNOVAL; > - > - if (capable(CAP_SYS_ADMIN)) > - xflags |= ATTR_KERNFULLS; > - else > - xflags |= ATTR_KERNORMALS; > - > + int error; > > /* > * First read the regular on-disk attributes. > */ > - result = -xfs_attr_list(ip, data, size, xflags, &cursor); > - if (result < 0) > - return result; > + memset(&context, 0, sizeof(context)); > + context.dp = XFS_I(inode); > + context.cursor = &cursor; > + context.resynch = 1; > + context.alist = data; > + context.bufsize = size; > + context.firstu = context.bufsize; > + > + if (size) > + context.put_listent = xfs_attr_kern_list; > + else > + context.put_listent = xfs_attr_kern_list_sizes; > + > + xfs_attr_list_int(&context); > + if (context.count < 0) > + return -ERANGE; > > /* > * Then add the two synthetic ACL attributes. > @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_access(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_ACCESS, > strlen(POSIX_ACL_XATTR_ACCESS) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_default(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, > strlen(POSIX_ACL_XATTR_DEFAULT) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > > - return result; > + return context.count; > } > Index: linux-2.6-xfs/fs/xfs/xfs_acl.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-01 14:44:07.000000000 +0200 > @@ -341,8 +341,7 @@ xfs_acl_iaccess( > > /* If the file has no ACL return -1. */ > rval = sizeof(xfs_acl_t); > - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, > - ATTR_ROOT | ATTR_KERNACCESS)) { > + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { > _ACL_FREE(acl); > return -1; > } > Index: linux-2.6-xfs/fs/xfs/xfs_attr.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-01 14:44:07.000000000 +0200 > @@ -18,9 +18,11 @@ > #ifndef __XFS_ATTR_H__ > #define __XFS_ATTR_H__ > > +struct xfs_inode; > +struct xfs_da_args; > +struct xfs_attr_list_context; > + > /* > - * xfs_attr.h > - * > * Large attribute lists are structured around Btrees where all the data > * elements are in the leaf nodes. Attribute names are hashed into an int, > * then that int is used as the index into the Btree. Since the hashval > @@ -35,17 +37,6 @@ > * External interfaces > *========================================================================*/ > > -struct cred; > -struct xfs_attr_list_context; > - > -typedef struct attrnames { > - char * attr_name; > - unsigned int attr_namelen; > -} attrnames_t; > - > -extern struct attrnames attr_user; > -extern struct attrnames attr_secure; > -extern struct attrnames attr_trusted; > > #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ > #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ > @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; > #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ > #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ > > -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ > #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ > #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ > -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ > - > -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ > -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ > -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) > > /* > * The maximum size (into the kernel or returned from the kernel) of an > @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { > > > /*======================================================================== > - * Function prototypes for the kernel. > + * Structure used to pass context around among the routines. > *========================================================================*/ > > -struct xfs_inode; > -struct attrlist_cursor_kern; > -struct xfs_da_args; > + > +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, > + char *, int, int, char *); > + > +typedef struct xfs_attr_list_context { > + struct xfs_inode *dp; /* inode */ > + struct attrlist_cursor_kern *cursor; /* position in list */ > + char *alist; /* output buffer */ > + int seen_enough; /* T/F: seen enough of list? */ > + int count; /* num used entries */ > + int dupcnt; /* count dup hashvals seen */ > + int bufsize; /* total buffer size */ > + int firstu; /* first used byte in buffer */ > + int flags; /* from VOP call */ > + int resynch; /* T/F: resynch with cursor */ > + int put_value; /* T/F: need value for listent */ > + put_listent_func_t put_listent; /* list output fmt function */ > + int index; /* index into output buffer */ > +} xfs_attr_list_context_t; > + > + > +/*======================================================================== > + * Function prototypes for the kernel. > + *========================================================================*/ > > /* > * Overall external interface routines. > */ > int xfs_attr_inactive(struct xfs_inode *dp); > - > -int xfs_attr_shortform_getvalue(struct xfs_da_args *); > int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); > int xfs_attr_rmtval_get(struct xfs_da_args *args); > +int xfs_attr_list_int(struct xfs_attr_list_context *); > > #endif /* __XFS_ATTR_H__ */ > From owner-xfs@oss.sgi.com Thu Jun 12 22:38:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 22:38:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D5cKKj030781 for ; Thu, 12 Jun 2008 22:38:20 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay1.corp.sgi.com (Postfix) with ESMTP id C86598F80A5; Thu, 12 Jun 2008 22:39:12 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D5cvjm1916646; Fri, 13 Jun 2008 15:39:01 +1000 (AEST) Message-ID: <48520704.8050903@melbourne.sgi.com> Date: Fri, 13 Jun 2008 15:35:00 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: markgw@sgi.com, Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> <4851EC2D.6010504@melbourne.sgi.com> In-Reply-To: <4851EC2D.6010504@melbourne.sgi.com> Content-Type: multipart/mixed; boundary="------------020704050307000508040701" X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16330 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------020704050307000508040701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greg Banks wrote: > Mark Goodwin wrote: > >> Greg Banks wrote: >> >>> Eric Sandeen wrote: >>> >>>> 4070 29.1% are scripts (shell, perl, whatever) >>>> 6598 47.2% don't use any stat() family calls at all >>>> 1829 13.1% use 32-bit stat() family interfaces only >>>> 1312 9.4% use 64-bit stat64() family interfaces only >>>> 180 1.3% use both 32-bit and 64-bit stat() family interfaces >>>> >>>> >>> Ouch. That's over two thousand executables to patch, rebuild, and ship. >>> >>>> list of packages, sorted by the semi-lame "number of files in package >>>> which call a 32-bit stat variant" metric: >>>> >>>> http://sandeen.fedorapeople.org/stat32-ers >>>> >> struct dirent has an embedded ino_t too, so for completeness we should >> also >> be looking for readdir(), readdir64(), getdirentries(), >> getdirentries64(), etc. >> > Good point. Looking in the code, it seems the getdents common code in > glibc will fail with EOVERFLOW if the inode number gets truncated during > 64b-32b translation, just like the stat() family. Experiment confirms this behaviour, using a small wrapper program around opendir/readdir/closedir: heave:~/stat64/mnt # ../myls64 idx d_ino d_off d_type d_name --- ---------------- ----- ------ ------ 0 0000000000000080 4 0 . 1 0000000000000080 6 0 .. 2 0000000000000083 8 0 d0 3 0000000080000080 10 0 d1 4 0000000100000080 12 0 d2 5 0000000180000080 14 0 d3 6 0000000200000080 16 0 d4 7 0000000280000080 18 0 d5 8 0000000300000080 20 0 d6 9 0000000380000080 22 0 d7 10 0000000400000080 24 0 d8 11 0000000480000080 26 0 d9 12 0000000500000080 28 0 d10 13 0000000580000080 30 0 d11 14 0000000600000080 32 0 d12 15 0000000680000080 34 0 d13 16 0000000700000080 36 0 d14 17 0000000780000080 38 0 d15 18 0000000800000080 40 0 d16 19 0000000880000080 42 0 d17 20 0000000900000080 44 0 d18 21 0000000980000080 46 0 d19 22 0000000a00000080 48 0 d20 23 0000000a80000080 50 0 d21 24 0000000b00000080 52 0 d22 25 0000000b80000080 54 0 d23 26 0000000c00000080 56 0 d24 27 0000000c80000080 58 0 d25 28 0000000d00000080 60 0 d26 29 0000000d80000080 62 0 d27 30 0000000e00000080 64 0 d28 31 0000000e80000080 66 0 d29 32 0000000f00000080 68 0 d30 33 0000000f80000080 70 0 d31 34 0000001000080080 72 0 d32 35 0000001080000080 74 0 d33 36 0000001100000080 76 0 d34 37 0000001180000080 78 0 d35 38 0000001200000080 80 0 d36 39 0000001280000080 82 0 d37 40 0000001300000080 84 0 d38 41 0000001380000080 86 0 d39 42 0000001400000080 88 0 d40 43 0000001480000080 90 0 d41 44 0000001500000080 92 0 d42 45 0000001580000080 94 0 d43 46 0000001600000080 96 0 d44 47 0000001680000080 98 0 d45 48 0000001700000080 100 0 d46 49 0000001780000080 102 0 d47 50 0000001800000080 104 0 d48 51 0000001880000080 106 0 d49 52 0000001900000080 108 0 d50 53 0000001980000080 110 0 d51 54 0000001a00000080 112 0 d52 55 0000001a80000080 114 0 d53 56 0000001b00000080 116 0 d54 57 0000001b80000080 118 0 d55 58 0000001c00000080 120 0 d56 59 0000001c80000080 122 0 d57 60 0000001d00000080 124 0 d58 61 0000001d80000080 126 0 d59 62 0000001e00000080 128 0 d60 63 0000001e80000080 130 0 d61 64 0000001f00000080 132 0 d62 65 0000001f80000080 512 0 d63 heave:~/stat64/mnt # ../myls32 idx d_ino d_off d_type d_name --- ---------------- ----- ------ ------ 0 0000000000000080 4 0 . 1 0000000000000080 6 0 .. 2 0000000000000083 8 0 d0 3 0000000080000080 10 0 d1 .: Value too large for defined data type heave:~/stat64/mnt # strace -s1024 ../myls32 execve("../myls32", ["../myls32"], [/* 60 vars */]) = 0 [ Process PID=12640 runs in 32 bit mode. ] ... open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 ... write(1, "idx d_ino d_off d_type d_name\n", 41) = 41 write(1, "--- ---------------- ----- ------ ------\n", 41) = 41 getdents64(3, /* 66 entries */, 4096) = 1584 _llseek(3, 10, [10], SEEK_SET) = 0 write(1, " 0 0000000000000080 4 0 .\n", 36) = 36 write(1, " 1 0000000000000080 6 0 ..\n", 37) = 37 write(1, " 2 0000000000000083 8 0 d0\n", 37) = 37 write(1, " 3 0000000080000080 10 0 d1\n", 37) = 37 getdents64(3, /* 62 entries */, 4096) = 1488 ... write(4, ".: Value too large for defined data type\n", 41) = 41 ... close(3) = 0 exit_group(0) = ? Process 12640 detached I also confirmed that using readdir64() allows the 32b app to work. Of course, the glibc readdir() interface makes it extra hard for the caller to tell the difference between an error and a normal EOF. In both cases, NULL is returned. In the error case, errno is set. In the EOF case, errno is unchanged. In the success case, EOF is also unchanged. So to detect the error from readdir() the application writer needs to do something like: DIR *dir; struct direntry *de; ... errno = 0; while ((de = readdir(dir)) != NULL) { // handle entry errno = 0; } if (errno) { // handle error } Otherwise the directory traversal just finishes early with no error reported. I'll bet that's what all the apps do :-) > I'll need to improve > the scanning tool :-) Attached. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. --------------020704050307000508040701 Content-Type: application/x-perl; name="summarise-stat64-2.pl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="summarise-stat64-2.pl" #!/usr/bin/perl # # A Perl script for evaluating and summarising which executables in # the given directories depend on the old 32-bit stat() family APIs. # # Version 2: detects use of old 32-bit readdir() calls. # # Usage: summariese-stat64.pl directory [...] # # Copyright (c) 2007 Silicon Graphics, Inc. All Rights Reserved. # By Greg Banks # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # use strict; use warnings; my @pathnames; # file and directories to read, from the commandline my @results; # array of { path, used32, used64, not_exe, no_perm } hashes my $verbose = 0; sub usage { print STDERR "Usage: summarise-stat64 [--verbose] file_or_directory...\n"; exit 1; } # Parse arguments foreach my $a (@ARGV) { if ($a eq '--verbose' || $a eq '-v') { $verbose++; } elsif ($a =~ m/^-/) { usage; } else { push(@pathnames,$a); } } usage unless scalar(@pathnames); # Function to scan a file sub scan_file { my ($path) = @_; my $fh; my %res = ( path => $path, used32 => 0, used64 => 0, not_exe => 0, no_perm => 0, ); open $fh,'-|', "nm -uD \"$path\" 2>&1" or return; while (<$fh>) { chomp; if (m/File format not recognized/) { $res{not_exe} = 1; } elsif (m/Permission denied/) { $res{no_perm} = 1; } elsif (m/^\s+U __(|l|f)xstat$/) { $res{used32}++; } elsif (m/^\s+U __(|l|f)xstat64$/) { $res{used64}++; } elsif (m/^\s+U readdir$/) { $res{used32}++; } elsif (m/^\s+U readdir64$/) { $res{used64}++; } } close $fh; push(@results, \%res); } # Function to scan a directory sub scan_directory { my ($path) = @_; my $dh; return unless opendir($dh,$path); while (my $d = readdir $dh) { next if ($d =~ m/^\./); print "$path/$d\n" if $verbose > 2; scan_path("$path/$d"); } closedir $dh; } # Function to scan something that might be a file or a directory sub scan_path { my ($path) = @_; print "scan_path($path)\n" if $verbose > 2; if ( -d $path ) { scan_directory($path); } elsif ( -e $path ) { scan_file($path); } } # Scan files and directories specified in the commandline foreach my $path (@pathnames) { scan_path($path); } my @status_strings = ( "cannot be read (permission denied)", "are scripts (shell, perl, whatever)", "don't use any stat() or readdir() family calls at all", "use 32-bit stat() or readdir() family interfaces only", "use 64-bit stat64() or readdir() family interfaces only", "use both 32-bit and 64-bit stat() or readdir() family interfaces", ); sub STATUS_UNCLEAN { return 3 }; sub STATUS_MIXED { return 5 }; sub STATUS_MAX { return 5 }; sub status { my ($r) = @_; return 0 if ($r->{no_perm}); return 1 if ($r->{not_exe}); return 2 + ($r->{used64} ? 2 : 0) + ($r->{used32} ? 1 : 0); } # Function to generate a summary sub emit_summary { my @summ; my $total = 0; foreach my $r (@results) { my $s = status($r); $summ[$s] = 0 unless defined $summ[$s]; $summ[$s]++; $total++; printf "%s %s\n", $r->{path}, $status_strings[$s] if ($verbose && ($s == STATUS_UNCLEAN || $s == STATUS_MIXED)); } foreach my $s (0..STATUS_MAX) { next unless defined $summ[$s]; printf "%7d %4.1f%% %s\n", $summ[$s], (100.0 * $summ[$s] / $total), $status_strings[$s]; } } # Function to dump raw data sub emit_raw { foreach my $r (@results) { print "$r->{used32} $r->{used64} $r->{not_exe} $r->{no_perm} $r->{path}\n"; } } emit_raw if $verbose > 1; emit_summary; --------------020704050307000508040701-- From owner-xfs@oss.sgi.com Thu Jun 12 23:04:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 23:04:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D6427H031812 for ; Thu, 12 Jun 2008 23:04:08 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14191 for ; Fri, 13 Jun 2008 16:04:58 +1000 Date: Fri, 13 Jun 2008 16:06:57 +1000 To: "xfs@oss.sgi.com" Subject: [REVIEW] Invalidate dentry on unlink/rmdir if using CI mode From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16331 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Once of the interesting features of vfs_unlink/d_delete functionality is that if it's the only inode being referenced, it makes the dentry negative. CI doesn't work with negative dentries, so the following code invalidate the dentry in CI mode. -- --- a/fs/xfs/linux-2.6/xfs_iops.c +++ b/fs/xfs/linux-2.6/xfs_iops.c @@ -482,6 +482,8 @@ xfs_vn_unlink( if (likely(!error)) { xfs_validate_fields(dir); /* size needs update */ xfs_validate_fields(inode); + if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) + d_invalidate(dentry); } return -error; } @@ -538,6 +540,8 @@ xfs_vn_rmdir( if (likely(!error)) { xfs_validate_fields(inode); xfs_validate_fields(dir); + if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) + d_invalidate(dentry); } return -error; } From owner-xfs@oss.sgi.com Fri Jun 13 00:18:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 00:18:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D7IGlB005405 for ; Fri, 13 Jun 2008 00:18:17 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15442; Fri, 13 Jun 2008 17:19:09 +1000 Message-ID: <48522031.5060700@sgi.com> Date: Fri, 13 Jun 2008 17:22:25 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] fix extent corruption in xfs_iext_irec_compact_full() Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16332 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This function is used to compact the indirect extent list by moving extents from one page to the previous to fill them up. After we move some extents to an earlier page we need to shuffle the remaining extents to the start of the page. The actual bug here is the second argument to memmove() needs to index past the extents, that were copied to the previous page, and move the remaining extents. For pages that are already full (ie ext_avail == 0) the compaction code has no net effect so don't do it. Thanks to Dave Chinner for pointing out the bug. Lachlan --- fs/xfs/xfs_inode.c_1.504 2008-06-05 16:46:33.000000000 +1000 +++ fs/xfs/xfs_inode.c 2008-06-05 17:39:20.000000000 +1000 @@ -4541,31 +4541,35 @@ xfs_iext_irec_compact_full( ep_next = erp_next->er_extbuf; while (erp_idx < nlists - 1) { ext_avail = XFS_LINEAR_EXTS - erp->er_extcount; - ext_diff = MIN(ext_avail, erp_next->er_extcount); - memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); - erp->er_extcount += ext_diff; - erp_next->er_extcount -= ext_diff; - /* Remove next page */ - if (erp_next->er_extcount == 0) { - /* - * Free page before removing extent record - * so er_extoffs don't get modified in - * xfs_iext_irec_remove. - */ - kmem_free(erp_next->er_extbuf); - erp_next->er_extbuf = NULL; - xfs_iext_irec_remove(ifp, erp_idx + 1); - erp = &ifp->if_u1.if_ext_irec[erp_idx]; - nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; - /* Update next page */ - } else { - /* Move rest of page up to become next new page */ - memmove(erp_next->er_extbuf, ep_next, - erp_next->er_extcount * sizeof(xfs_bmbt_rec_t)); - ep_next = erp_next->er_extbuf; - memset(&ep_next[erp_next->er_extcount], 0, - (XFS_LINEAR_EXTS - erp_next->er_extcount) * - sizeof(xfs_bmbt_rec_t)); + if (ext_avail) { + ext_diff = MIN(ext_avail, erp_next->er_extcount); + memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); + erp->er_extcount += ext_diff; + erp_next->er_extcount -= ext_diff; + /* Remove next page */ + if (erp_next->er_extcount == 0) { + /* + * Free page before removing extent record + * so er_extoffs don't get modified in + * xfs_iext_irec_remove. + */ + kmem_free(erp_next->er_extbuf); + erp_next->er_extbuf = NULL; + xfs_iext_irec_remove(ifp, erp_idx + 1); + erp = &ifp->if_u1.if_ext_irec[erp_idx]; + nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; + /* Update next page */ + } else { + /* Move rest of page up to become next new page */ + memmove(erp_next->er_extbuf, &ep_next[ext_diff], + erp_next->er_extcount * + sizeof(xfs_bmbt_rec_t)); + ep_next = erp_next->er_extbuf; + memset(&ep_next[erp_next->er_extcount], 0, + (XFS_LINEAR_EXTS - + erp_next->er_extcount) * + sizeof(xfs_bmbt_rec_t)); + } } if (erp->er_extcount == XFS_LINEAR_EXTS) { erp_idx++; From owner-xfs@oss.sgi.com Fri Jun 13 00:34:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 00:34:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42, J_CHICKENPOX_43,J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46, J_CHICKENPOX_47,J_CHICKENPOX_48 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D7Y48Q010792 for ; Fri, 13 Jun 2008 00:34:06 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15705; Fri, 13 Jun 2008 17:34:56 +1000 Message-ID: <485223E4.6030404@sgi.com> Date: Fri, 13 Jun 2008 17:38:12 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] Prevent extent btree block allocation failures Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16333 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs When at ENOSPC conditions extent btree block allocations can fail and we have no error handling to undo partial btree operations. Prior to extent btree operations we reserve enough disk blocks somewhere in the filesystem to satisfy the operation but in some conditions we require the blocks to come from specific AGs and if those AGs are full the allocation fails. This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs for the space needed. Since we have reserved the space these allocations are now guaranteed to succeed. In order to search all AGs I had to revert a change made to xfs_alloc_vextent() that prevented a search from looking at AGs lower than the starting AG. This original change was made to prevent out of order AG locking when allocating multiple extents on data writeout but since we only allocate one extent at a time now this particular problem can't happen. Lachlan --- fs/xfs/xfs_alloc.c_1.193 2008-06-03 11:28:55.000000000 +1000 +++ fs/xfs/xfs_alloc.c 2008-06-02 18:40:47.000000000 +1000 @@ -2376,19 +2376,9 @@ xfs_alloc_vextent( if (args->agno == sagno && type == XFS_ALLOCTYPE_START_BNO) args->type = XFS_ALLOCTYPE_THIS_AG; - /* - * For the first allocation, we can try any AG to get - * space. However, if we already have allocated a - * block, we don't want to try AGs whose number is below - * sagno. Otherwise, we may end up with out-of-order - * locking of AGF, which might cause deadlock. - */ - if (++(args->agno) == mp->m_sb.sb_agcount) { - if (args->firstblock != NULLFSBLOCK) - args->agno = sagno; - else - args->agno = 0; - } + + if (++(args->agno) == mp->m_sb.sb_agcount) + args->agno = 0; /* * Reached the starting a.g., must either be done * or switch to non-trylock mode. --- fs/xfs/xfs_bmap.c_1.392 2008-06-03 12:20:14.000000000 +1000 +++ fs/xfs/xfs_bmap.c 2008-06-03 15:57:40.000000000 +1000 @@ -3445,16 +3452,10 @@ xfs_bmap_extents_to_btree( args.tp = tp; args.mp = mp; args.firstblock = *firstblock; - if (*firstblock == NULLFSBLOCK) { - args.type = XFS_ALLOCTYPE_START_BNO; + args.fsbno = *firstblock; + if (*firstblock == NULLFSBLOCK) args.fsbno = XFS_INO_TO_FSB(mp, ip->i_ino); - } else if (flist->xbf_low) { - args.type = XFS_ALLOCTYPE_START_BNO; - args.fsbno = *firstblock; - } else { - args.type = XFS_ALLOCTYPE_NEAR_BNO; - args.fsbno = *firstblock; - } + args.type = XFS_ALLOCTYPE_START_BNO; args.minlen = args.maxlen = args.prod = 1; args.total = args.minleft = args.alignment = args.mod = args.isfl = args.minalignslop = 0; @@ -3585,13 +3586,10 @@ xfs_bmap_local_to_extents( * Allocate a block. We know we need only one, since the * file currently fits in an inode. */ - if (*firstblock == NULLFSBLOCK) { + args.fsbno = *firstblock; + if (*firstblock == NULLFSBLOCK) args.fsbno = XFS_INO_TO_FSB(args.mp, ip->i_ino); - args.type = XFS_ALLOCTYPE_START_BNO; - } else { - args.fsbno = *firstblock; - args.type = XFS_ALLOCTYPE_NEAR_BNO; - } + args.type = XFS_ALLOCTYPE_START_BNO; args.total = total; args.mod = args.minleft = args.alignment = args.wasdel = args.isfl = args.minalignslop = 0; --- fs/xfs/xfs_bmap_btree.c_1.169 2008-06-03 11:28:56.000000000 +1000 +++ fs/xfs/xfs_bmap_btree.c 2008-06-06 14:48:14.000000000 +1000 @@ -1493,11 +1493,9 @@ xfs_bmbt_split( left = XFS_BUF_TO_BMBT_BLOCK(lbp); args.fsbno = cur->bc_private.b.firstblock; args.firstblock = args.fsbno; - if (args.fsbno == NULLFSBLOCK) { + if (args.fsbno == NULLFSBLOCK) args.fsbno = lbno; - args.type = XFS_ALLOCTYPE_START_BNO; - } else - args.type = XFS_ALLOCTYPE_NEAR_BNO; + args.type = XFS_ALLOCTYPE_START_BNO; args.mod = args.minleft = args.alignment = args.total = args.isfl = args.userdata = args.minalignslop = 0; args.minlen = args.maxlen = args.prod = 1; @@ -2253,9 +2251,8 @@ xfs_bmbt_newroot( } #endif args.fsbno = be64_to_cpu(*pp); - args.type = XFS_ALLOCTYPE_START_BNO; - } else - args.type = XFS_ALLOCTYPE_NEAR_BNO; + } + args.type = XFS_ALLOCTYPE_START_BNO; if ((error = xfs_alloc_vextent(&args))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; From owner-xfs@oss.sgi.com Fri Jun 13 03:25:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 03:25:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DAOxsW024926 for ; Fri, 13 Jun 2008 03:25:00 -0700 X-ASG-Debug-ID: 1213352755-2ab301c20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AAB5812C48FB; Fri, 13 Jun 2008 03:25:55 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id i8bCcioAKW8HWFeQ; Fri, 13 Jun 2008 03:25:55 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K76Tj-0002uZ-4G; Fri, 13 Jun 2008 10:25:55 +0000 Date: Fri, 13 Jun 2008 06:25:55 -0400 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Invalidate dentry on unlink/rmdir if using CI mode Subject: Re: [REVIEW] Invalidate dentry on unlink/rmdir if using CI mode Message-ID: <20080613102555.GA1700@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213352756 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53173 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16334 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 04:06:57PM +1000, Barry Naujok wrote: > Once of the interesting features of vfs_unlink/d_delete functionality > is that if it's the only inode being referenced, it makes the dentry > negative. CI doesn't work with negative dentries, so the following code > invalidate the dentry in CI mode. Please add a comment like this patch description near the the calls you added, otherwise ok. From owner-xfs@oss.sgi.com Fri Jun 13 06:22:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 06:22:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DDM9pf008133 for ; Fri, 13 Jun 2008 06:22:10 -0700 X-ASG-Debug-ID: 1213363384-5a9c033c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 04EFFCAA4AD; Fri, 13 Jun 2008 06:23:05 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id WYRrxDGnCZh5E7Oh; Fri, 13 Jun 2008 06:23:05 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K79FA-0007Lo-Gy; Fri, 13 Jun 2008 13:23:04 +0000 Date: Fri, 13 Jun 2008 09:23:04 -0400 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix extent corruption in xfs_iext_irec_compact_full() Subject: Re: [PATCH] fix extent corruption in xfs_iext_irec_compact_full() Message-ID: <20080613132304.GA28190@infradead.org> References: <48522031.5060700@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48522031.5060700@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213363386 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.02 X-Barracuda-Spam-Status: No, SCORE=-1.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC1_TG070 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53185 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.00 BSF_SC1_TG070 Custom Rule TG070 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16335 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 05:22:25PM +1000, Lachlan McIlroy wrote: > This function is used to compact the indirect extent list by moving > extents from one page to the previous to fill them up. After we > move some extents to an earlier page we need to shuffle the remaining > extents to the start of the page. The actual bug here is the second > argument to memmove() needs to index past the extents, that were copied > to the previous page, and move the remaining extents. For pages that > are already full (ie ext_avail == 0) the compaction code has no net > effect so don't do it. > > Thanks to Dave Chinner for pointing out the bug. Looks good but this function needs a lot more comments. Below is a version of the patch with some more comments describing what's going on that I came up with when trying to understand what this patch does in detail: Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2008-06-13 14:58:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2008-06-13 15:15:25.000000000 +0200 @@ -4532,39 +4532,63 @@ xfs_iext_irec_compact_full( int nlists; /* number of irec's (ex lists) */ ASSERT(ifp->if_flags & XFS_IFEXTIREC); + nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; erp = ifp->if_u1.if_ext_irec; ep = &erp->er_extbuf[erp->er_extcount]; erp_next = erp + 1; ep_next = erp_next->er_extbuf; + while (erp_idx < nlists - 1) { + /* + * Check how many extent records are available in this irec. + * If there is none skip the whole exercise. + */ ext_avail = XFS_LINEAR_EXTS - erp->er_extcount; - ext_diff = MIN(ext_avail, erp_next->er_extcount); - memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); - erp->er_extcount += ext_diff; - erp_next->er_extcount -= ext_diff; - /* Remove next page */ - if (erp_next->er_extcount == 0) { + if (ext_avail) { + + /* + * Copy over as many as possible extent records into + * the previous page. + */ + ext_diff = MIN(ext_avail, erp_next->er_extcount); + memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); + erp->er_extcount += ext_diff; + erp_next->er_extcount -= ext_diff; + /* - * Free page before removing extent record - * so er_extoffs don't get modified in - * xfs_iext_irec_remove. + * If the next irec is empty now we can simply + * remove it. */ - kmem_free(erp_next->er_extbuf); - erp_next->er_extbuf = NULL; - xfs_iext_irec_remove(ifp, erp_idx + 1); - erp = &ifp->if_u1.if_ext_irec[erp_idx]; - nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; - /* Update next page */ - } else { - /* Move rest of page up to become next new page */ - memmove(erp_next->er_extbuf, ep_next, - erp_next->er_extcount * sizeof(xfs_bmbt_rec_t)); - ep_next = erp_next->er_extbuf; - memset(&ep_next[erp_next->er_extcount], 0, - (XFS_LINEAR_EXTS - erp_next->er_extcount) * - sizeof(xfs_bmbt_rec_t)); + if (erp_next->er_extcount == 0) { + /* + * Free page before removing extent record + * so er_extoffs don't get modified in + * xfs_iext_irec_remove. + */ + kmem_free(erp_next->er_extbuf); + erp_next->er_extbuf = NULL; + xfs_iext_irec_remove(ifp, erp_idx + 1); + erp = &ifp->if_u1.if_ext_irec[erp_idx]; + nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; + + /* + * If the next irec is not empty move up the content + * that has not been copied to the previous page to + * the beggining of this one. + */ + } else { + memmove(erp_next->er_extbuf, &ep_next[ext_diff], + erp_next->er_extcount * + sizeof(xfs_bmbt_rec_t)); + ep_next = erp_next->er_extbuf; + memset(&ep_next[erp_next->er_extcount], 0, + (XFS_LINEAR_EXTS - + erp_next->er_extcount) * + sizeof(xfs_bmbt_rec_t)); + } } + if (erp->er_extcount == XFS_LINEAR_EXTS) { erp_idx++; if (erp_idx < nlists) From owner-xfs@oss.sgi.com Fri Jun 13 06:27:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 06:27:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DDRaB9008956 for ; Fri, 13 Jun 2008 06:27:36 -0700 X-ASG-Debug-ID: 1213363712-5acf03af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C0ADD12C4D0E for ; Fri, 13 Jun 2008 06:28:32 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 9IlivrV2v4mJm3KP for ; Fri, 13 Jun 2008 06:28:32 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 319E498FF6F; Fri, 13 Jun 2008 08:28:31 -0500 (CDT) Message-ID: <485275FF.2050909@sandeen.net> Date: Fri, 13 Jun 2008 08:28:31 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Greg Banks CC: markgw@sgi.com, Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> <4851EC2D.6010504@melbourne.sgi.com> <48520704.8050903@melbourne.sgi.com> In-Reply-To: <48520704.8050903@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213363712 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53185 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16336 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Greg Banks wrote: >> I'll need to improve >> the scanning tool :-) > Attached. > I had done something similar, except: --- summarise-stat64-2.pl.orig 2008-06-13 08:26:07.000000000 -0500 +++ summarise-stat64-2.pl 2008-06-13 08:26:24.000000000 -0500 @@ -93,11 +93,11 @@ { $res{used64}++; } - elsif (m/^\s+U readdir$/) + elsif (m/^\s+U readdir(|_r)$/) { $res{used32}++; } - elsif (m/^\s+U readdir64$/) + elsif (m/^\s+U readdir64(|_r)$/) { $res{used64}++; } (lazily whitespace-mangled, sorry) A new scan with my slightly different version of the tool yielded: 447 readdir32 908 stat32 38 statfs32 where the nr. is the nr. of packages with that particular 32-bit call. -Eric From owner-xfs@oss.sgi.com Fri Jun 13 06:43:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 06:43:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DDhN21010733 for ; Fri, 13 Jun 2008 06:43:23 -0700 X-ASG-Debug-ID: 1213364659-7d7d02ef0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1F77EC28C5F; Fri, 13 Jun 2008 06:44:19 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id UT5voo0emdHf732j; Fri, 13 Jun 2008 06:44:19 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K79Zi-0001Gk-GZ; Fri, 13 Jun 2008 13:44:18 +0000 Date: Fri, 13 Jun 2008 09:44:18 -0400 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080613134418.GA31720@infradead.org> References: <485223E4.6030404@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485223E4.6030404@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213364660 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53187 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16337 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: > This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), > xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs > for the space needed. Since we have reserved the space these allocations > are now guaranteed to succeed. This looks good and makes lot of sense to me. Please also add a comment to enum xfs_alloctype in xfs_alloc.h about the danger of the allocation types that never go out of the AG when used inside transactions. > In order to search all AGs I had to revert > a change made to xfs_alloc_vextent() that prevented a search from looking > at AGs lower than the starting AG. This original change was made to prevent > out of order AG locking when allocating multiple extents on data writeout > but since we only allocate one extent at a time now this particular problem > can't happen. This one also makes sense, but I have a very bad gut feeling about it. There's nothing preventing the same deadlock scenario from coming back when people modify the highlevel data allocator again. We really need some sort of assert to trigger early in that case to not got a nasty hard to trigger deadlock. > + if (++(args->agno) == mp->m_sb.sb_agcount) and while we're at it this should be if (++args->agno == mp->m_sb.sb_agcount) From owner-xfs@oss.sgi.com Fri Jun 13 08:56:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 08:56:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DFuEMd025238 for ; Fri, 13 Jun 2008 08:56:14 -0700 X-ASG-Debug-ID: 1213372630-541e022b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B635A2280F9 for ; Fri, 13 Jun 2008 08:57:10 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id DQT5mBxmzjf55JcR for ; Fri, 13 Jun 2008 08:57:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG81Ukh5LG+u/2dsb2JhbACuJA X-IronPort-AV: E=Sophos;i="4.27,639,1204464600"; d="scan'208";a="125714267" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 14 Jun 2008 01:27:09 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K7BeG-0006hS-Ci; Sat, 14 Jun 2008 01:57:08 +1000 Date: Sat, 14 Jun 2008 01:57:08 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080613155708.GG3700@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485223E4.6030404@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213372631 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53196 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16338 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: > When at ENOSPC conditions extent btree block allocations can fail and we > have no error handling to undo partial btree operations. Prior to extent > btree operations we reserve enough disk blocks somewhere in the filesystem > to satisfy the operation but in some conditions we require the blocks to > come from specific AGs and if those AGs are full the allocation fails. > > This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), > xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs > for the space needed. Since we have reserved the space these allocations > are now guaranteed to succeed. Sure, but we didn't reserve space for potential btree splits in a second AG as a result of this. That needs to be reserved in the transaction as well, which will blow out transaction reservations substantially as we'll need to add another 2 full AGF btree splits to every transaction that modifies the bmap btree. > In order to search all AGs I had to revert > a change made to xfs_alloc_vextent() that prevented a search from looking > at AGs lower than the starting AG. This original change was made to prevent > out of order AG locking when allocating multiple extents on data writeout > but since we only allocate one extent at a time now this particular problem > can't happen. You missed the fact that the AGF of modified AGs is already held locked in the transaction, hence the locking order within the transaction is wrong. Also, if we modify the free list in an AG the fail an allocation (e.g. can't do an exact allocation), we'll have multiple dirty and locked AGFs in the one allocation. Hence we still can have locking order violations if you remove that check and therefore deadlocks. This is not the solution to the problem. As I suggested (back when you first floated this idea as a fix for the problem several weeks ago) I think the bug is that we are not taking into account the number of blocks required for a bmbt split when selecting an AG to allocate from. All we take into account is the blocks required for the extent to be allocated and nothing else. If we take the blocks for a bmbt split into account then we'll never try to allocate an extent in an AG that we can't also allocate all the blocks for the bmbt split in at the same time. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Fri Jun 13 09:23:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 09:23:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DGNn8t028219 for ; Fri, 13 Jun 2008 09:23:50 -0700 X-ASG-Debug-ID: 1213374282-52df003d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7734F17BFEF6; Fri, 13 Jun 2008 09:24:42 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 3736AYHp4w0fpmaT; Fri, 13 Jun 2008 09:24:42 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5DGOXNW023148 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Jun 2008 18:24:34 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5DGOXZB023146; Fri, 13 Jun 2008 18:24:33 +0200 Date: Fri, 13 Jun 2008 18:24:33 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] simplify xfs_vn_listxattr Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr Message-ID: <20080613162433.GA23022@lst.de> References: <20080603114837.GB2703@lst.de> <4851F30C.4000108@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4851F30C.4000108@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213374284 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53198 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16339 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 02:09:48PM +1000, Timothy Shimmin wrote: > This appears to break xfstests/063 (EA xfsdump test). Indeed, I did some stupid last minute changes after running it through xfsqa. Here's the updated version which makes 063 happy again: Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-13 16:12:17.000000000 +0200 @@ -16,8 +16,6 @@ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#include - #include "xfs.h" #include "xfs_fs.h" #include "xfs_types.h" @@ -607,12 +605,20 @@ xfs_attr_remove( return xfs_attr_remove_int(dp, &xname, flags); } -STATIC int +int xfs_attr_list_int(xfs_attr_list_context_t *context) { int error; xfs_inode_t *dp = context->dp; + XFS_STATS_INC(xs_attr_list); + + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) + return EIO; + + xfs_ilock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall start", context); + /* * Decide on what work routines to call based on the inode size. */ @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ } else { error = xfs_attr_node_list(context); } + + xfs_iunlock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall end", context); + return error; } @@ -641,74 +651,50 @@ xfs_attr_list_int(xfs_attr_list_context_ */ /*ARGSUSED*/ STATIC int -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, char *name, int namelen, int valuelen, char *value) { + struct attrlist *alist = (struct attrlist *)context->alist; attrlist_ent_t *aep; int arraytop; ASSERT(!(context->flags & ATTR_KERNOVAL)); ASSERT(context->count >= 0); ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); - ASSERT(context->firstu >= sizeof(*context->alist)); + ASSERT(context->firstu >= sizeof(*alist)); ASSERT(context->firstu <= context->bufsize); - arraytop = sizeof(*context->alist) + - context->count * sizeof(context->alist->al_offset[0]); + /* + * Only list entries in the right namespace. + */ + if (((context->flags & ATTR_SECURE) == 0) != + ((flags & XFS_ATTR_SECURE) == 0)) + return 0; + if (((context->flags & ATTR_ROOT) == 0) != + ((flags & XFS_ATTR_ROOT) == 0)) + return 0; + + arraytop = sizeof(*alist) + + context->count * sizeof(alist->al_offset[0]); context->firstu -= ATTR_ENTSIZE(namelen); if (context->firstu < arraytop) { xfs_attr_trace_l_c("buffer full", context); - context->alist->al_more = 1; + alist->al_more = 1; context->seen_enough = 1; return 1; } - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); + aep = (attrlist_ent_t *)&context->alist[context->firstu]; aep->a_valuelen = valuelen; memcpy(aep->a_name, name, namelen); - aep->a_name[ namelen ] = 0; - context->alist->al_offset[ context->count++ ] = context->firstu; - context->alist->al_count = context->count; + aep->a_name[namelen] = 0; + alist->al_offset[context->count++] = context->firstu; + alist->al_count = context->count; xfs_attr_trace_l_c("add", context); return 0; } -STATIC int -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - char *offset; - int arraytop; - - ASSERT(context->count >= 0); - - arraytop = context->count + namesp->attr_namelen + namelen + 1; - if (arraytop > context->firstu) { - context->count = -1; /* insufficient space */ - return 1; - } - offset = (char *)context->alist + context->count; - strncpy(offset, namesp->attr_name, namesp->attr_namelen); - offset += namesp->attr_namelen; - strncpy(offset, name, namelen); /* real name */ - offset += namelen; - *offset = '\0'; - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - -/*ARGSUSED*/ -STATIC int -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - /* * Generate a list of extended attribute names and optionally * also value lengths. Positive return value follows the XFS @@ -725,10 +711,9 @@ xfs_attr_list( attrlist_cursor_kern_t *cursor) { xfs_attr_list_context_t context; + struct attrlist *alist; int error; - XFS_STATS_INC(xs_attr_list); - /* * Validate the cursor. */ @@ -749,52 +734,21 @@ xfs_attr_list( /* * Initialize the output buffer. */ + memset(&context, 0, sizeof(context)); context.dp = dp; context.cursor = cursor; - context.count = 0; - context.dupcnt = 0; context.resynch = 1; context.flags = flags; - context.seen_enough = 0; - context.alist = (attrlist_t *)buffer; - context.put_value = 0; - - if (flags & ATTR_KERNAMELS) { - context.bufsize = bufsize; - context.firstu = context.bufsize; - if (flags & ATTR_KERNOVAL) - context.put_listent = xfs_attr_kern_list_sizes; - else - context.put_listent = xfs_attr_kern_list; - } else { - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ - context.firstu = context.bufsize; - context.alist->al_count = 0; - context.alist->al_more = 0; - context.alist->al_offset[0] = context.bufsize; - context.put_listent = xfs_attr_put_listent; - } + context.alist = buffer; + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ + context.firstu = context.bufsize; + context.put_listent = xfs_attr_put_listent; - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) - return EIO; - - xfs_ilock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall start", &context); + alist = (struct attrlist *)context.alist; + alist->al_offset[0] = context.bufsize; error = xfs_attr_list_int(&context); - - xfs_iunlock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall end", &context); - - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { - /* must return negated buffer size or the error */ - if (context.count < 0) - error = XFS_ERROR(ERANGE); - else - error = -context.count; - } else - ASSERT(error >= 0); - + ASSERT(error >= 0); return error; } @@ -2357,12 +2311,7 @@ xfs_attr_trace_enter(int type, char *whe (void *)((__psunsigned_t)context->bufsize), (void *)((__psunsigned_t)context->count), (void *)((__psunsigned_t)context->firstu), - (void *)((__psunsigned_t) - (((context->count > 0) && - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) - ? (ATTR_ENTRY(context->alist, - context->count-1)->a_valuelen) - : 0)), + NULL, (void *)((__psunsigned_t)context->dupcnt), (void *)((__psunsigned_t)context->flags), (void *)a13, (void *)a14, (void *)a15); Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-13 16:07:40.000000000 +0200 @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att * Namespace helper routines *========================================================================*/ -STATIC_INLINE attrnames_t * -xfs_attr_flags_namesp(int flags) -{ - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); -} - /* * If namespace bits don't match return 0. * If all match then return 1. @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); } -/* - * If namespace bits don't match and we don't have an override for it - * then return 0. - * If all match or are overridable then return 1. - */ -STATIC_INLINE int -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) -{ - if (((arg_flags & ATTR_SECURE) == 0) != - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && - !(arg_flags & ATTR_KERNORMALS)) - return 0; - if (((arg_flags & ATTR_ROOT) == 0) != - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && - !(arg_flags & ATTR_KERNROOTLS)) - return 0; - return 1; -} - /*======================================================================== * External routines when attribute fork size < XFS_LITINO(mp). @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co (XFS_ISRESET_CURSOR(cursor) && (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { - attrnames_t *namesp; - - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } - namesp = xfs_attr_flags_namesp(sfe->flags); error = context->put_listent(context, - namesp, + sfe->flags, (char *)sfe->nameval, (int)sfe->namelen, (int)sfe->valuelen, @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co kmem_free(sbuf); return XFS_ERROR(EFSCORRUPTED); } - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } + sbp->entno = i; sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); sbp->name = (char *)sfe->nameval; @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co * Loop putting entries into the user buffer. */ for ( ; i < nsbuf; i++, sbp++) { - attrnames_t *namesp; - - namesp = xfs_attr_flags_namesp(sbp->flags); - if (cursor->hashval != sbp->hash) { cursor->hashval = sbp->hash; cursor->offset = 0; } error = context->put_listent(context, - namesp, + sbp->flags, sbp->name, sbp->namelen, sbp->valuelen, @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, */ retval = 0; for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { - attrnames_t *namesp; - if (be32_to_cpu(entry->hashval) != cursor->hashval) { cursor->hashval = be32_to_cpu(entry->hashval); cursor->offset = 0; @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (entry->flags & XFS_ATTR_INCOMPLETE) continue; /* skip incomplete entries */ - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) - continue; - - namesp = xfs_attr_flags_namesp(entry->flags); if (entry->flags & XFS_ATTR_LOCAL) { xfs_attr_leaf_name_local_t *name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_loc->nameval, (int)name_loc->namelen, be16_to_cpu(name_loc->valuelen), @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (retval) return retval; retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, (char*)args.value); kmem_free(args.value); - } - else { + } else { retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-13 16:07:40.000000000 +0200 @@ -30,7 +30,6 @@ struct attrlist; struct attrlist_cursor_kern; -struct attrnames; struct xfs_dabuf; struct xfs_da_args; struct xfs_da_state; @@ -204,33 +203,6 @@ static inline int xfs_attr_leaf_entsize_ return (((bsize) >> 1) + ((bsize) >> 2)); } - -/*======================================================================== - * Structure used to pass context around among the routines. - *========================================================================*/ - - -struct xfs_attr_list_context; - -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, - char *, int, int, char *); - -typedef struct xfs_attr_list_context { - struct xfs_inode *dp; /* inode */ - struct attrlist_cursor_kern *cursor; /* position in list */ - struct attrlist *alist; /* output buffer */ - int seen_enough; /* T/F: seen enough of list? */ - int count; /* num used entries */ - int dupcnt; /* count dup hashvals seen */ - int bufsize; /* total buffer size */ - int firstu; /* first used byte in buffer */ - int flags; /* from VOP call */ - int resynch; /* T/F: resynch with cursor */ - int put_value; /* T/F: need value for listent */ - put_listent_func_t put_listent; /* list output fmt function */ - int index; /* index into output buffer */ -} xfs_attr_list_context_t; - /* * Used to keep a list of "remote value" extents when unlinking an inode. */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-13 16:14:08.000000000 +0200 @@ -17,7 +17,11 @@ */ #include "xfs.h" +#include "xfs_da_btree.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" #include "xfs_attr.h" +#include "xfs_attr_leaf.h" #include "xfs_acl.h" #include "xfs_vnodeops.h" @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, return __xfs_xattr_set(inode, name, value, size, flags, 0); } -struct attrnames attr_user = { - .attr_name = "user.", - .attr_namelen = sizeof("user.") - 1, -}; - static struct xattr_handler xfs_xattr_user_handler = { .prefix = XATTR_USER_PREFIX, .get = xfs_xattr_user_get, @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); } -struct attrnames attr_trusted = { - .attr_name = "trusted.", - .attr_namelen = sizeof("trusted.") - 1, -}; - static struct xattr_handler xfs_xattr_trusted_handler = { .prefix = XATTR_TRUSTED_PREFIX, .get = xfs_xattr_trusted_get, @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); } -struct attrnames attr_secure = { - .attr_name = "security.", - .attr_namelen = sizeof("security.") - 1, -}; - static struct xattr_handler xfs_xattr_security_handler = { .prefix = XATTR_SECURITY_PREFIX, .get = xfs_xattr_secure_get, @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers NULL }; +static unsigned int xfs_xattr_prefix_len(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return sizeof("security"); + else if (flags & XFS_ATTR_ROOT) + return sizeof("trusted"); + else + return sizeof("user"); +} + +static const char *xfs_xattr_prefix(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return xfs_xattr_security_handler.prefix; + else if (flags & XFS_ATTR_ROOT) + return xfs_xattr_trusted_handler.prefix; + else + return xfs_xattr_user_handler.prefix; +} + +static int +xfs_xattr_put_listent(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + unsigned int prefix_len = xfs_xattr_prefix_len(flags); + char *offset; + int arraytop; + + ASSERT(context->count >= 0); + + /* + * Only show root namespace entries if we are actually allowed to + * see them. + */ + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) + return 0; + + arraytop = context->count + prefix_len + namelen + 1; + if (arraytop > context->firstu) { + context->count = -1; /* insufficient space */ + return 1; + } + offset = (char *)context->alist + context->count; + strncpy(offset, xfs_xattr_prefix(flags), prefix_len); + offset += prefix_len; + strncpy(offset, name, namelen); /* real name */ + offset += namelen; + *offset = '\0'; + context->count += prefix_len + namelen + 1; + return 0; +} + +static int +xfs_xattr_put_listent_sizes(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + context->count += xfs_xattr_prefix_len(flags) + namelen + 1; + return 0; +} + static int list_one_attr(const char *name, const size_t len, void *data, size_t size, ssize_t *result) @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si ssize_t xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) { + struct xfs_attr_list_context context; + struct attrlist_cursor_kern cursor = { 0 }; struct inode *inode = dentry->d_inode; - struct xfs_inode *ip = XFS_I(inode); - attrlist_cursor_kern_t cursor = { 0 }; - int error, xflags; - ssize_t result; - - xflags = ATTR_KERNAMELS; - if (!size) - xflags |= ATTR_KERNOVAL; - - if (capable(CAP_SYS_ADMIN)) - xflags |= ATTR_KERNFULLS; - else - xflags |= ATTR_KERNORMALS; - + int error; /* * First read the regular on-disk attributes. */ - result = -xfs_attr_list(ip, data, size, xflags, &cursor); - if (result < 0) - return result; + memset(&context, 0, sizeof(context)); + context.dp = XFS_I(inode); + context.cursor = &cursor; + context.resynch = 1; + context.alist = data; + context.bufsize = size; + context.firstu = context.bufsize; + + if (size) + context.put_listent = xfs_xattr_put_listent; + else + context.put_listent = xfs_xattr_put_listent_sizes; + + xfs_attr_list_int(&context); + if (context.count < 0) + return -ERANGE; /* * Then add the two synthetic ACL attributes. @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_access(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_default(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } - return result; + return context.count; } Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-13 16:07:40.000000000 +0200 @@ -341,8 +341,7 @@ xfs_acl_iaccess( /* If the file has no ACL return -1. */ rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, - ATTR_ROOT | ATTR_KERNACCESS)) { + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { _ACL_FREE(acl); return -1; } Index: linux-2.6-xfs/fs/xfs/xfs_attr.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-13 16:07:40.000000000 +0200 @@ -18,9 +18,11 @@ #ifndef __XFS_ATTR_H__ #define __XFS_ATTR_H__ +struct xfs_inode; +struct xfs_da_args; +struct xfs_attr_list_context; + /* - * xfs_attr.h - * * Large attribute lists are structured around Btrees where all the data * elements are in the leaf nodes. Attribute names are hashed into an int, * then that int is used as the index into the Btree. Since the hashval @@ -35,17 +37,6 @@ * External interfaces *========================================================================*/ -struct cred; -struct xfs_attr_list_context; - -typedef struct attrnames { - char * attr_name; - unsigned int attr_namelen; -} attrnames_t; - -extern struct attrnames attr_user; -extern struct attrnames attr_secure; -extern struct attrnames attr_trusted; #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ - -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) /* * The maximum size (into the kernel or returned from the kernel) of an @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { /*======================================================================== - * Function prototypes for the kernel. + * Structure used to pass context around among the routines. *========================================================================*/ -struct xfs_inode; -struct attrlist_cursor_kern; -struct xfs_da_args; + +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, + char *, int, int, char *); + +typedef struct xfs_attr_list_context { + struct xfs_inode *dp; /* inode */ + struct attrlist_cursor_kern *cursor; /* position in list */ + char *alist; /* output buffer */ + int seen_enough; /* T/F: seen enough of list? */ + int count; /* num used entries */ + int dupcnt; /* count dup hashvals seen */ + int bufsize; /* total buffer size */ + int firstu; /* first used byte in buffer */ + int flags; /* from VOP call */ + int resynch; /* T/F: resynch with cursor */ + int put_value; /* T/F: need value for listent */ + put_listent_func_t put_listent; /* list output fmt function */ + int index; /* index into output buffer */ +} xfs_attr_list_context_t; + + +/*======================================================================== + * Function prototypes for the kernel. + *========================================================================*/ /* * Overall external interface routines. */ int xfs_attr_inactive(struct xfs_inode *dp); - -int xfs_attr_shortform_getvalue(struct xfs_da_args *); int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); int xfs_attr_rmtval_get(struct xfs_da_args *args); +int xfs_attr_list_int(struct xfs_attr_list_context *); #endif /* __XFS_ATTR_H__ */ From owner-xfs@oss.sgi.com Sat Jun 14 01:23:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 01:23:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5E8NgAd008236 for ; Sat, 14 Jun 2008 01:23:42 -0700 X-ASG-Debug-ID: 1213431877-6385027c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fk-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5CB2322F5D9 for ; Sat, 14 Jun 2008 01:24:38 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by cuda.sgi.com with ESMTP id XipLm9DejwmluhGG for ; Sat, 14 Jun 2008 01:24:38 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 26so2841356fkx.4 for ; Sat, 14 Jun 2008 01:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=ZEL5Ikdbq6JBC389sUBbdsM3d9miERHvgZCN5o4iqYI=; b=tW75Mfau9uqF1UZTP5ZNH57KZwT4diM0YKppeyR1zTofxbWarEbYLuugYnZzgDy/IG upsYlLtxITf9sVT8aJzAVL1drWCpUW5chr2miZAlWLEWGZjKOQVhHIcl37lznFtJIZw1 F3WR3MlC4LNG/TmZSFEmheVNDjfT9Eh1KXk70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=nJccs43EvnCOSsZp95IT+9pm/cf4qmpUxYTU24gP3HMky/GjrMFdQ9dTfDX9EvHzYI qQy+/WmmNHZELkNUFoOkiAnpOQAHX17iinkqSFDmYmMwq+vICAfZ+y15pxWbcWATc6p9 peinfuA64j5HV9oZn/EfWJEKb5H98GPdqiS6U= Received: by 10.78.148.15 with SMTP id v15mr1569426hud.44.1213431877152; Sat, 14 Jun 2008 01:24:37 -0700 (PDT) Received: by 10.78.142.16 with HTTP; Sat, 14 Jun 2008 01:24:37 -0700 (PDT) Message-ID: <74d4a1e10806140124s3ed8dfa6x7e5ca656fea0e06e@mail.gmail.com> Date: Sat, 14 Jun 2008 10:24:37 +0200 From: "Paul Guermonprez" To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair aborting ... dir2.c:2133 Subject: xfs_repair aborting ... dir2.c:2133 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 00ae1e19c4a2582b X-Barracuda-Connect: fk-out-0910.google.com[209.85.128.191] X-Barracuda-Start-Time: 1213431879 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3466 1.0000 -0.1647 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.16 X-Barracuda-Spam-Status: No, SCORE=-0.16 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53259 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16340 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@guermonprez.eu Precedence: bulk X-list: xfs hello, i have a xfs dump i want to repair under linux ubuntu. the partition was created by a storage system ss4000-e. if i use version 2.9.4, i have a segfault and version 2.9.8, the proces is aborted with message : xfs_repair: dir2.c:2133: process_dir2: Assertion `(ino != mp->m_sb.sb_rootino && ino != *parent) || (ino == mp->m_sb.sb_rootino && (ino == *parent || need_root_dotdot == 1))' failed. Aborted i also tried to comment this test, but it returns a segfault just as version 2.9.4. note : i already restored 3 xfs dumps from the same machine, and everything went in the lost+found, partly with no name, no directory, partly with a directory structure and filenames as expected. before xfs_repair, the mounted fs was empty, not even the ".." for root ! thanks, paul. From owner-xfs@oss.sgi.com Sat Jun 14 06:48:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 06:48:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EDmuTB003642 for ; Sat, 14 Jun 2008 06:48:56 -0700 X-ASG-Debug-ID: 1213451393-7d0301bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from vms044pub.verizon.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1D6AB2308C5 for ; Sat, 14 Jun 2008 06:49:53 -0700 (PDT) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by cuda.sgi.com with ESMTP id v9Pt99S94NqZayk4 for ; Sat, 14 Jun 2008 06:49:53 -0700 (PDT) Received: from [192.168.1.106] ([71.170.186.252]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K2G00CO2H2TN1Y2@vms044.mailsrvcs.net> for xfs@oss.sgi.com; Sat, 14 Jun 2008 08:49:41 -0500 (CDT) Date: Sat, 14 Jun 2008 08:49:40 -0500 From: Dave Littell X-ASG-Orig-Subj: GRIO for Linux...please! Subject: GRIO for Linux...please! To: xfs@oss.sgi.com Message-id: <4853CC74.8040206@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Thunderbird 1.5 (X11/20060317) X-Barracuda-Connect: vms044pub.verizon.net[206.46.252.44] X-Barracuda-Start-Time: 1213451394 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5017 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53282 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16341 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: littelld@verizon.net Precedence: bulk X-list: xfs Hi all, Is there any plan (or even hope!) to have GRIO ported to Linux? XFS is an excellent filesystem in any case, but GRIO would put it head and shoulders above the competition. Thanks, Dave From owner-xfs@oss.sgi.com Sat Jun 14 07:05:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 07:05:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EE5jZg005094 for ; Sat, 14 Jun 2008 07:05:45 -0700 X-ASG-Debug-ID: 1213452397-018702c30000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from glqvs (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 72C6A231127; Sat, 14 Jun 2008 07:06:40 -0700 (PDT) Received: from glqvs (200-47-51-61.comsat.net.ar [200.47.51.61]) by cuda.sgi.com with ESMTP id HT5hSuSyys4srKtQ; Sat, 14 Jun 2008 07:06:40 -0700 (PDT) Message-ID: <1213452437.0756@eds.com> To: X-ASG-Orig-Subj: LuxuryWatches For Cheap, High Quality And Certified. LowPriceGuaranteed! fpgt he Subject: LuxuryWatches For Cheap, High Quality And Certified. LowPriceGuaranteed! fpgt he Date: Sat, 14 Jun 2008 07:07:17 -0700 In-Reply-To: X-Sender: From: "Annamaria Hertha" Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Barracuda-Connect: 200-47-51-61.comsat.net.ar[200.47.51.61] X-Barracuda-Start-Time: 1213452402 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53282 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16342 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: herthahc@eds.com Precedence: bulk X-list: xfs From owner-xfs@oss.sgi.com Sat Jun 14 08:17:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 08:17:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EFHCX4010836 for ; Sat, 14 Jun 2008 08:17:14 -0700 X-ASG-Debug-ID: 1213456686-5313007d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 07B6323183D; Sat, 14 Jun 2008 08:18:06 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id uudRLE18a48ZCxJb; Sat, 14 Jun 2008 08:18:06 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5EFHuNW011409 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 14 Jun 2008 17:17:56 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5EFHuwR011407; Sat, 14 Jun 2008 17:17:56 +0200 Date: Sat, 14 Jun 2008 17:17:56 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] simplify xfs_vn_listxattr Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr Message-ID: <20080614151756.GA11331@lst.de> References: <20080603114837.GB2703@lst.de> <4851F30C.4000108@sgi.com> <20080613162433.GA23022@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080613162433.GA23022@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213456688 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53286 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16343 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 06:24:33PM +0200, Christoph Hellwig wrote: > On Fri, Jun 13, 2008 at 02:09:48PM +1000, Timothy Shimmin wrote: > > This appears to break xfstests/063 (EA xfsdump test). > > Indeed, I did some stupid last minute changes after running it through > xfsqa. Here's the updated version which makes 063 happy again: Needs another update to fix a (harmless) warning: Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-14 17:14:30.000000000 +0200 @@ -16,8 +16,6 @@ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#include - #include "xfs.h" #include "xfs_fs.h" #include "xfs_types.h" @@ -607,12 +605,20 @@ xfs_attr_remove( return xfs_attr_remove_int(dp, &xname, flags); } -STATIC int +int xfs_attr_list_int(xfs_attr_list_context_t *context) { int error; xfs_inode_t *dp = context->dp; + XFS_STATS_INC(xs_attr_list); + + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) + return EIO; + + xfs_ilock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall start", context); + /* * Decide on what work routines to call based on the inode size. */ @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ } else { error = xfs_attr_node_list(context); } + + xfs_iunlock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall end", context); + return error; } @@ -641,74 +651,50 @@ xfs_attr_list_int(xfs_attr_list_context_ */ /*ARGSUSED*/ STATIC int -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, char *name, int namelen, int valuelen, char *value) { + struct attrlist *alist = (struct attrlist *)context->alist; attrlist_ent_t *aep; int arraytop; ASSERT(!(context->flags & ATTR_KERNOVAL)); ASSERT(context->count >= 0); ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); - ASSERT(context->firstu >= sizeof(*context->alist)); + ASSERT(context->firstu >= sizeof(*alist)); ASSERT(context->firstu <= context->bufsize); - arraytop = sizeof(*context->alist) + - context->count * sizeof(context->alist->al_offset[0]); + /* + * Only list entries in the right namespace. + */ + if (((context->flags & ATTR_SECURE) == 0) != + ((flags & XFS_ATTR_SECURE) == 0)) + return 0; + if (((context->flags & ATTR_ROOT) == 0) != + ((flags & XFS_ATTR_ROOT) == 0)) + return 0; + + arraytop = sizeof(*alist) + + context->count * sizeof(alist->al_offset[0]); context->firstu -= ATTR_ENTSIZE(namelen); if (context->firstu < arraytop) { xfs_attr_trace_l_c("buffer full", context); - context->alist->al_more = 1; + alist->al_more = 1; context->seen_enough = 1; return 1; } - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); + aep = (attrlist_ent_t *)&context->alist[context->firstu]; aep->a_valuelen = valuelen; memcpy(aep->a_name, name, namelen); - aep->a_name[ namelen ] = 0; - context->alist->al_offset[ context->count++ ] = context->firstu; - context->alist->al_count = context->count; + aep->a_name[namelen] = 0; + alist->al_offset[context->count++] = context->firstu; + alist->al_count = context->count; xfs_attr_trace_l_c("add", context); return 0; } -STATIC int -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - char *offset; - int arraytop; - - ASSERT(context->count >= 0); - - arraytop = context->count + namesp->attr_namelen + namelen + 1; - if (arraytop > context->firstu) { - context->count = -1; /* insufficient space */ - return 1; - } - offset = (char *)context->alist + context->count; - strncpy(offset, namesp->attr_name, namesp->attr_namelen); - offset += namesp->attr_namelen; - strncpy(offset, name, namelen); /* real name */ - offset += namelen; - *offset = '\0'; - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - -/*ARGSUSED*/ -STATIC int -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - /* * Generate a list of extended attribute names and optionally * also value lengths. Positive return value follows the XFS @@ -725,10 +711,9 @@ xfs_attr_list( attrlist_cursor_kern_t *cursor) { xfs_attr_list_context_t context; + struct attrlist *alist; int error; - XFS_STATS_INC(xs_attr_list); - /* * Validate the cursor. */ @@ -749,52 +734,23 @@ xfs_attr_list( /* * Initialize the output buffer. */ + memset(&context, 0, sizeof(context)); context.dp = dp; context.cursor = cursor; - context.count = 0; - context.dupcnt = 0; context.resynch = 1; context.flags = flags; - context.seen_enough = 0; - context.alist = (attrlist_t *)buffer; - context.put_value = 0; - - if (flags & ATTR_KERNAMELS) { - context.bufsize = bufsize; - context.firstu = context.bufsize; - if (flags & ATTR_KERNOVAL) - context.put_listent = xfs_attr_kern_list_sizes; - else - context.put_listent = xfs_attr_kern_list; - } else { - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ - context.firstu = context.bufsize; - context.alist->al_count = 0; - context.alist->al_more = 0; - context.alist->al_offset[0] = context.bufsize; - context.put_listent = xfs_attr_put_listent; - } - - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) - return EIO; - - xfs_ilock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall start", &context); + context.alist = buffer; + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ + context.firstu = context.bufsize; + context.put_listent = xfs_attr_put_listent; + + alist = (struct attrlist *)context.alist; + alist->al_count = 0; + alist->al_more = 0; + alist->al_offset[0] = context.bufsize; error = xfs_attr_list_int(&context); - - xfs_iunlock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall end", &context); - - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { - /* must return negated buffer size or the error */ - if (context.count < 0) - error = XFS_ERROR(ERANGE); - else - error = -context.count; - } else - ASSERT(error >= 0); - + ASSERT(error >= 0); return error; } @@ -2357,12 +2313,7 @@ xfs_attr_trace_enter(int type, char *whe (void *)((__psunsigned_t)context->bufsize), (void *)((__psunsigned_t)context->count), (void *)((__psunsigned_t)context->firstu), - (void *)((__psunsigned_t) - (((context->count > 0) && - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) - ? (ATTR_ENTRY(context->alist, - context->count-1)->a_valuelen) - : 0)), + NULL, (void *)((__psunsigned_t)context->dupcnt), (void *)((__psunsigned_t)context->flags), (void *)a13, (void *)a14, (void *)a15); Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-14 17:14:30.000000000 +0200 @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att * Namespace helper routines *========================================================================*/ -STATIC_INLINE attrnames_t * -xfs_attr_flags_namesp(int flags) -{ - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); -} - /* * If namespace bits don't match return 0. * If all match then return 1. @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); } -/* - * If namespace bits don't match and we don't have an override for it - * then return 0. - * If all match or are overridable then return 1. - */ -STATIC_INLINE int -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) -{ - if (((arg_flags & ATTR_SECURE) == 0) != - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && - !(arg_flags & ATTR_KERNORMALS)) - return 0; - if (((arg_flags & ATTR_ROOT) == 0) != - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && - !(arg_flags & ATTR_KERNROOTLS)) - return 0; - return 1; -} - /*======================================================================== * External routines when attribute fork size < XFS_LITINO(mp). @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co (XFS_ISRESET_CURSOR(cursor) && (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { - attrnames_t *namesp; - - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } - namesp = xfs_attr_flags_namesp(sfe->flags); error = context->put_listent(context, - namesp, + sfe->flags, (char *)sfe->nameval, (int)sfe->namelen, (int)sfe->valuelen, @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co kmem_free(sbuf); return XFS_ERROR(EFSCORRUPTED); } - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } + sbp->entno = i; sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); sbp->name = (char *)sfe->nameval; @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co * Loop putting entries into the user buffer. */ for ( ; i < nsbuf; i++, sbp++) { - attrnames_t *namesp; - - namesp = xfs_attr_flags_namesp(sbp->flags); - if (cursor->hashval != sbp->hash) { cursor->hashval = sbp->hash; cursor->offset = 0; } error = context->put_listent(context, - namesp, + sbp->flags, sbp->name, sbp->namelen, sbp->valuelen, @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, */ retval = 0; for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { - attrnames_t *namesp; - if (be32_to_cpu(entry->hashval) != cursor->hashval) { cursor->hashval = be32_to_cpu(entry->hashval); cursor->offset = 0; @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (entry->flags & XFS_ATTR_INCOMPLETE) continue; /* skip incomplete entries */ - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) - continue; - - namesp = xfs_attr_flags_namesp(entry->flags); if (entry->flags & XFS_ATTR_LOCAL) { xfs_attr_leaf_name_local_t *name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_loc->nameval, (int)name_loc->namelen, be16_to_cpu(name_loc->valuelen), @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (retval) return retval; retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, (char*)args.value); kmem_free(args.value); - } - else { + } else { retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-14 17:16:25.000000000 +0200 @@ -30,7 +30,7 @@ struct attrlist; struct attrlist_cursor_kern; -struct attrnames; +struct xfs_attr_list_context; struct xfs_dabuf; struct xfs_da_args; struct xfs_da_state; @@ -204,33 +204,6 @@ static inline int xfs_attr_leaf_entsize_ return (((bsize) >> 1) + ((bsize) >> 2)); } - -/*======================================================================== - * Structure used to pass context around among the routines. - *========================================================================*/ - - -struct xfs_attr_list_context; - -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, - char *, int, int, char *); - -typedef struct xfs_attr_list_context { - struct xfs_inode *dp; /* inode */ - struct attrlist_cursor_kern *cursor; /* position in list */ - struct attrlist *alist; /* output buffer */ - int seen_enough; /* T/F: seen enough of list? */ - int count; /* num used entries */ - int dupcnt; /* count dup hashvals seen */ - int bufsize; /* total buffer size */ - int firstu; /* first used byte in buffer */ - int flags; /* from VOP call */ - int resynch; /* T/F: resynch with cursor */ - int put_value; /* T/F: need value for listent */ - put_listent_func_t put_listent; /* list output fmt function */ - int index; /* index into output buffer */ -} xfs_attr_list_context_t; - /* * Used to keep a list of "remote value" extents when unlinking an inode. */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-14 17:14:30.000000000 +0200 @@ -17,7 +17,11 @@ */ #include "xfs.h" +#include "xfs_da_btree.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" #include "xfs_attr.h" +#include "xfs_attr_leaf.h" #include "xfs_acl.h" #include "xfs_vnodeops.h" @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, return __xfs_xattr_set(inode, name, value, size, flags, 0); } -struct attrnames attr_user = { - .attr_name = "user.", - .attr_namelen = sizeof("user.") - 1, -}; - static struct xattr_handler xfs_xattr_user_handler = { .prefix = XATTR_USER_PREFIX, .get = xfs_xattr_user_get, @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); } -struct attrnames attr_trusted = { - .attr_name = "trusted.", - .attr_namelen = sizeof("trusted.") - 1, -}; - static struct xattr_handler xfs_xattr_trusted_handler = { .prefix = XATTR_TRUSTED_PREFIX, .get = xfs_xattr_trusted_get, @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); } -struct attrnames attr_secure = { - .attr_name = "security.", - .attr_namelen = sizeof("security.") - 1, -}; - static struct xattr_handler xfs_xattr_security_handler = { .prefix = XATTR_SECURITY_PREFIX, .get = xfs_xattr_secure_get, @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers NULL }; +static unsigned int xfs_xattr_prefix_len(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return sizeof("security"); + else if (flags & XFS_ATTR_ROOT) + return sizeof("trusted"); + else + return sizeof("user"); +} + +static const char *xfs_xattr_prefix(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return xfs_xattr_security_handler.prefix; + else if (flags & XFS_ATTR_ROOT) + return xfs_xattr_trusted_handler.prefix; + else + return xfs_xattr_user_handler.prefix; +} + +static int +xfs_xattr_put_listent(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + unsigned int prefix_len = xfs_xattr_prefix_len(flags); + char *offset; + int arraytop; + + ASSERT(context->count >= 0); + + /* + * Only show root namespace entries if we are actually allowed to + * see them. + */ + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) + return 0; + + arraytop = context->count + prefix_len + namelen + 1; + if (arraytop > context->firstu) { + context->count = -1; /* insufficient space */ + return 1; + } + offset = (char *)context->alist + context->count; + strncpy(offset, xfs_xattr_prefix(flags), prefix_len); + offset += prefix_len; + strncpy(offset, name, namelen); /* real name */ + offset += namelen; + *offset = '\0'; + context->count += prefix_len + namelen + 1; + return 0; +} + +static int +xfs_xattr_put_listent_sizes(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + context->count += xfs_xattr_prefix_len(flags) + namelen + 1; + return 0; +} + static int list_one_attr(const char *name, const size_t len, void *data, size_t size, ssize_t *result) @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si ssize_t xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) { + struct xfs_attr_list_context context; + struct attrlist_cursor_kern cursor = { 0 }; struct inode *inode = dentry->d_inode; - struct xfs_inode *ip = XFS_I(inode); - attrlist_cursor_kern_t cursor = { 0 }; - int error, xflags; - ssize_t result; - - xflags = ATTR_KERNAMELS; - if (!size) - xflags |= ATTR_KERNOVAL; - - if (capable(CAP_SYS_ADMIN)) - xflags |= ATTR_KERNFULLS; - else - xflags |= ATTR_KERNORMALS; - + int error; /* * First read the regular on-disk attributes. */ - result = -xfs_attr_list(ip, data, size, xflags, &cursor); - if (result < 0) - return result; + memset(&context, 0, sizeof(context)); + context.dp = XFS_I(inode); + context.cursor = &cursor; + context.resynch = 1; + context.alist = data; + context.bufsize = size; + context.firstu = context.bufsize; + + if (size) + context.put_listent = xfs_xattr_put_listent; + else + context.put_listent = xfs_xattr_put_listent_sizes; + + xfs_attr_list_int(&context); + if (context.count < 0) + return -ERANGE; /* * Then add the two synthetic ACL attributes. @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_access(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_default(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } - return result; + return context.count; } Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-14 17:14:30.000000000 +0200 @@ -341,8 +341,7 @@ xfs_acl_iaccess( /* If the file has no ACL return -1. */ rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, - ATTR_ROOT | ATTR_KERNACCESS)) { + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { _ACL_FREE(acl); return -1; } Index: linux-2.6-xfs/fs/xfs/xfs_attr.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-14 17:14:30.000000000 +0200 @@ -18,9 +18,11 @@ #ifndef __XFS_ATTR_H__ #define __XFS_ATTR_H__ +struct xfs_inode; +struct xfs_da_args; +struct xfs_attr_list_context; + /* - * xfs_attr.h - * * Large attribute lists are structured around Btrees where all the data * elements are in the leaf nodes. Attribute names are hashed into an int, * then that int is used as the index into the Btree. Since the hashval @@ -35,17 +37,6 @@ * External interfaces *========================================================================*/ -struct cred; -struct xfs_attr_list_context; - -typedef struct attrnames { - char * attr_name; - unsigned int attr_namelen; -} attrnames_t; - -extern struct attrnames attr_user; -extern struct attrnames attr_secure; -extern struct attrnames attr_trusted; #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ - -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) /* * The maximum size (into the kernel or returned from the kernel) of an @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { /*======================================================================== - * Function prototypes for the kernel. + * Structure used to pass context around among the routines. *========================================================================*/ -struct xfs_inode; -struct attrlist_cursor_kern; -struct xfs_da_args; + +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, + char *, int, int, char *); + +typedef struct xfs_attr_list_context { + struct xfs_inode *dp; /* inode */ + struct attrlist_cursor_kern *cursor; /* position in list */ + char *alist; /* output buffer */ + int seen_enough; /* T/F: seen enough of list? */ + int count; /* num used entries */ + int dupcnt; /* count dup hashvals seen */ + int bufsize; /* total buffer size */ + int firstu; /* first used byte in buffer */ + int flags; /* from VOP call */ + int resynch; /* T/F: resynch with cursor */ + int put_value; /* T/F: need value for listent */ + put_listent_func_t put_listent; /* list output fmt function */ + int index; /* index into output buffer */ +} xfs_attr_list_context_t; + + +/*======================================================================== + * Function prototypes for the kernel. + *========================================================================*/ /* * Overall external interface routines. */ int xfs_attr_inactive(struct xfs_inode *dp); - -int xfs_attr_shortform_getvalue(struct xfs_da_args *); int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); int xfs_attr_rmtval_get(struct xfs_da_args *args); +int xfs_attr_list_int(struct xfs_attr_list_context *); #endif /* __XFS_ATTR_H__ */ From owner-xfs@oss.sgi.com Sat Jun 14 09:00:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:00:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_66,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EG0h1r018082 for ; Sat, 14 Jun 2008 09:00:44 -0700 X-ASG-Debug-ID: 1213459296-4161028d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4230F17C57F8 for ; Sat, 14 Jun 2008 09:01:37 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id nNPSFkytZew5W8OG for ; Sat, 14 Jun 2008 09:01:37 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5EG1RNW015501 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 14 Jun 2008 18:01:27 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5EG1RAq015499 for xfs@oss.sgi.com; Sat, 14 Jun 2008 18:01:27 +0200 Date: Sat, 14 Jun 2008 18:01:27 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] use generic posix ACL code, enable ACL caching Subject: [PATCH] use generic posix ACL code, enable ACL caching Message-ID: <20080614160127.GA15404@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213459298 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53288 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16344 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Switch XFS to use the generic ACL code and enable caching the ACL values in the XFS inode. Compared to the last post various bugs have been fixed and a locking strategy has been designed and implemented. This now passes XFSQA. You'll need my various attr-related patches applies before this one. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c 2008-06-14 15:53:35.000000000 +0200 @@ -0,0 +1,517 @@ +/* + * Copyright (C) 2008 Christoph Hellwig. + * Released under GPL v2. + */ +#include "xfs.h" +#include "xfs_acl.h" +#include "xfs_attr.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" +#include "xfs_vnodeops.h" +#include +#include + + +#define XFS_ACL_NOT_CACHED ((void *)-1) + +/* + * Locking scheme: + * - all ACL updates are protected by inode->i_mutex, which is taken before + * calling into this file. + * - access and updates to the ip->i_acl and ip->i_default_acl pointers are + * protected by inode->i_lock. + */ + +static struct posix_acl * +xfs_acl_from_disk(struct xfs_acl *aclp) +{ + struct posix_acl_entry *acl_e; + struct posix_acl *acl; + struct xfs_acl_entry *ace; + int count, i; + + count = be32_to_cpu(aclp->acl_cnt); + + acl = posix_acl_alloc(count, GFP_KERNEL); + if (!acl) + return ERR_PTR(-ENOMEM); + + for (i = 0; i < count; i++) { + acl_e = &acl->a_entries[i]; + ace = &aclp->acl_entry[i]; + + /* + * The tag is 32 bits on disk and 16 bits in core. + * + * Because every access to it goes through the core + * format first this is not a problem. + */ + acl_e->e_tag = be32_to_cpu(ace->ae_tag); + acl_e->e_perm = be16_to_cpu(ace->ae_perm); + + switch (acl_e->e_tag) { + case ACL_USER: + case ACL_GROUP: + acl_e->e_id = be32_to_cpu(ace->ae_id); + break; + case ACL_USER_OBJ: + case ACL_GROUP_OBJ: + case ACL_MASK: + case ACL_OTHER: + acl_e->e_id = ACL_UNDEFINED_ID; + break; + default: + goto fail; + } + } + return acl; + +fail: + posix_acl_release(acl); + return ERR_PTR(-EINVAL); +} + +static void +xfs_acl_to_disk(struct xfs_acl *aclp, const struct posix_acl *acl) +{ + const struct posix_acl_entry *acl_e; + struct xfs_acl_entry *ace; + int i; + + aclp->acl_cnt = cpu_to_be32(acl->a_count); + for (i = 0; i < acl->a_count; i++) { + ace = &aclp->acl_entry[i]; + acl_e = &acl->a_entries[i]; + + ace->ae_tag = cpu_to_be32(acl_e->e_tag); + ace->ae_id = cpu_to_be32(acl_e->e_id); + ace->ae_perm = cpu_to_be16(acl_e->e_perm); + } +} + +/* + * Update the cached ACL pointer in the inode. + * + * Because we don't hold any locks while reading/writing the attribute + * from/to disk another thread could have raced and updated the cached + * ACL value before us. In that case we release the previous cached value + * and update it with our new value. + */ +static void +xfs_update_cached_acl(struct inode *inode, struct posix_acl **p_acl, + struct posix_acl *acl) +{ + spin_lock(&inode->i_lock); + if (*p_acl && *p_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(*p_acl); + *p_acl = posix_acl_dup(acl); + spin_unlock(&inode->i_lock); +} + +struct posix_acl * +xfs_get_acl(struct inode *inode, int type) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl *acl = NULL, **p_acl; + struct xfs_acl *xfs_acl; + int len = sizeof(struct xfs_acl); + char *ea_name; + int error; + + switch (type) { + case ACL_TYPE_ACCESS: + ea_name = SGI_ACL_FILE; + p_acl = &ip->i_acl; + break; + case ACL_TYPE_DEFAULT: + ea_name = SGI_ACL_DEFAULT; + p_acl = &ip->i_default_acl; + break; + default: + return ERR_PTR(-EINVAL); + } + + spin_lock(&inode->i_lock); + if (*p_acl != XFS_ACL_NOT_CACHED) + acl = posix_acl_dup(*p_acl); + spin_unlock(&inode->i_lock); + + /* + * If we have a cached ACLs value just return it, not need to + * go out to the disk. + */ + if (acl) + return acl; + + xfs_acl = kzalloc(sizeof(struct xfs_acl), GFP_KERNEL); + if (!xfs_acl) + return ERR_PTR(-ENOMEM); + + error = -xfs_attr_get(ip, ea_name, (char *)xfs_acl, &len, ATTR_ROOT); + if (error) { + /* + * If the attribute doesn't exist make sure we have a negative + * cache entry, for any other error assume it is transient and + * leave the cache entry as XFS_ACL_NOT_CACHED. + */ + if (error == -ENOATTR) { + acl = NULL; + goto out_update_cache; + } + goto out; + } + + acl = xfs_acl_from_disk(xfs_acl); + if (IS_ERR(acl)) + goto out; + + out_update_cache: + xfs_update_cached_acl(inode, p_acl, acl); + out: + kfree(xfs_acl); + return acl; +} + +static int +xfs_set_acl(struct inode *inode, int type, struct posix_acl *acl) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl **p_acl; + char *ea_name; + int error; + + if (S_ISLNK(inode->i_mode)) + return -EOPNOTSUPP; + + switch (type) { + case ACL_TYPE_ACCESS: + ea_name = SGI_ACL_FILE; + p_acl = &ip->i_acl; + break; + case ACL_TYPE_DEFAULT: + if (!S_ISDIR(inode->i_mode)) + return acl ? -EACCES : 0; + ea_name = SGI_ACL_DEFAULT; + p_acl = &ip->i_default_acl; + break; + default: + return -EINVAL; + } + + if (acl) { + struct xfs_acl *xfs_acl; + int len; + + xfs_acl = kzalloc(sizeof(struct xfs_acl), GFP_KERNEL); + if (!xfs_acl) + return -ENOMEM; + + xfs_acl_to_disk(xfs_acl, acl); + len = sizeof(struct xfs_acl) - + (sizeof(struct xfs_acl_entry) * + (XFS_ACL_MAX_ENTRIES - acl->a_count)); + + error = -xfs_attr_set(ip, ea_name, (char *)xfs_acl, + len, ATTR_ROOT); + + kfree(xfs_acl); + } else { + /* + * A NULL ACL argument means we want to remove the ACL. + */ + error = -xfs_attr_remove(ip, ea_name, ATTR_ROOT); + + /* + * If the attribute didn't exist to start with that's fine. + */ + if (error == -ENOATTR) + error = 0; + } + + if (!error) + xfs_update_cached_acl(inode, p_acl, acl); + return error; +} + +static int +xfs_check_acl(struct inode *inode, int mask) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl *acl; + int error = -EAGAIN; + + xfs_itrace_entry(ip); + + /* + * If there is no attribute fork no ACL exists on this inode and + * we can skip the whole exercise. + */ + if (!XFS_IFORK_Q(ip)) + return -EAGAIN; + + acl = xfs_get_acl(inode, ACL_TYPE_ACCESS); + if (IS_ERR(acl)) + return PTR_ERR(acl); + if (acl) { + error = posix_acl_permission(inode, acl, mask); + posix_acl_release(acl); + } + + return error; +} + +int +xfs_vn_permission(struct inode *inode, int mask, struct nameidata *nd) +{ + return generic_permission(inode, mask, xfs_check_acl); +} + +static int +xfs_set_mode(struct inode *inode, mode_t mode) +{ + int error = 0; + + if (mode != inode->i_mode) { + struct bhv_vattr va; + + va.va_mask = XFS_AT_MODE; + va.va_mode = mode; + + error = -xfs_setattr(XFS_I(inode), &va, 0, sys_cred); + inode->i_mode = mode; + } + + return error; +} + +static int +xfs_acl_exists(struct inode *inode, char *name) +{ + int len = sizeof(struct xfs_acl); + + return (xfs_attr_get(XFS_I(inode), name, NULL, &len, + ATTR_ROOT|ATTR_KERNOVAL) == 0); +} + +int +posix_acl_access_exists(struct inode *inode) +{ + return xfs_acl_exists(inode, SGI_ACL_FILE); +} + +int +posix_acl_default_exists(struct inode *inode) +{ + if (!S_ISDIR(inode->i_mode)) + return 0; + return xfs_acl_exists(inode, SGI_ACL_DEFAULT); +} + +/* + * No need for i_mutex because the inode is not yet exposed to the VFS. + */ +int +xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl) +{ + struct posix_acl *clone; + mode_t mode; + int error = 0, inherit = 0; + + if (S_ISDIR(inode->i_mode)) { + error = xfs_set_acl(inode, ACL_TYPE_DEFAULT, default_acl); + if (error) + return error; + } + + clone = posix_acl_clone(default_acl, GFP_KERNEL); + if (!clone) + return -ENOMEM; + + mode = inode->i_mode; + error = posix_acl_create_masq(clone, &mode); + if (error < 0) + goto out_release_clone; + + /* + * If posix_acl_create_masq returns a positive value we need to + * inherit a permission that can't be represented using the Unix + * mode bits and we actually need to set an ACL. + */ + if (error > 0) + inherit = 1; + + error = xfs_set_mode(inode, mode); + if (error) + goto out_release_clone; + + if (inherit) + error = xfs_set_acl(inode, ACL_TYPE_ACCESS, clone); + + out_release_clone: + posix_acl_release(clone); + return error; +} + +int +xfs_acl_chmod(struct inode *inode) +{ + struct posix_acl *acl, *clone; + int error; + + if (S_ISLNK(inode->i_mode)) + return -EOPNOTSUPP; + + acl = xfs_get_acl(inode, ACL_TYPE_ACCESS); + if (IS_ERR(acl) || !acl) + return PTR_ERR(acl); + + clone = posix_acl_clone(acl, GFP_KERNEL); + posix_acl_release(acl); + if (!clone) + return -ENOMEM; + + error = posix_acl_chmod_masq(clone, inode->i_mode); + if (!error) + error = xfs_set_acl(inode, ACL_TYPE_ACCESS, clone); + + posix_acl_release(clone); + return error; +} + +void +xfs_inode_init_acls(struct xfs_inode *ip) +{ + /* + * No need for locking, inode is not live yet. + */ + ip->i_acl = XFS_ACL_NOT_CACHED; + ip->i_default_acl = XFS_ACL_NOT_CACHED; +} + +void +xfs_inode_clear_acls(struct xfs_inode *ip) +{ + /* + * No need for locking here, the inode is not live anymore + * and just about to be freed. + */ + if (ip->i_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(ip->i_acl); + if (ip->i_default_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(ip->i_default_acl); +} + + +/* + * System xattr handlers. + * + * Currently Posix ACLs are the only system namespace extended attribute + * handlers supported by XFS, so we just implement the handlers here. + * If we ever support other system extended attributes this will need + * some refactoring. + */ + +static int +xfs_decode_acl(const char *name) +{ + if (strcmp(name, "posix_acl_access") == 0) + return ACL_TYPE_ACCESS; + else if (strcmp(name, "posix_acl_default") == 0) + return ACL_TYPE_DEFAULT; + return -EINVAL; +} + +static int +xfs_xattr_system_get(struct inode *inode, const char *name, + void *value, size_t size) +{ + struct posix_acl *acl; + int type, error; + + type = xfs_decode_acl(name); + if (type < 0) + return type; + + acl = xfs_get_acl(inode, type); + if (IS_ERR(acl)) + return PTR_ERR(acl); + if (acl == NULL) + return -ENODATA; + + error = posix_acl_to_xattr(acl, value, size); + posix_acl_release(acl); + + return error; +} + +static int +xfs_xattr_system_set(struct inode *inode, const char *name, + const void *value, size_t size, int flags) +{ + struct posix_acl *acl = NULL; + int error = 0, type; + + type = xfs_decode_acl(name); + if (type < 0) + return type; + if (flags & XATTR_CREATE) + return -EINVAL; + if (type == ACL_TYPE_DEFAULT && !S_ISDIR(inode->i_mode)) + return value ? -EACCES : 0; + if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER)) + return -EPERM; + + if (!value) + goto set_acl; + + acl = posix_acl_from_xattr(value, size); + if (!acl) { + /* + * acl_set_file(3) may request that we set default ACLs with + * zero length -- defend (gracefully) against that here. + */ + goto out; + } + if (IS_ERR(acl)) { + error = PTR_ERR(acl); + goto out; + } + + error = posix_acl_valid(acl); + if (error) + goto out_release; + + error = -EINVAL; + if (acl->a_count > XFS_ACL_MAX_ENTRIES) + goto out_release; + + if (type == ACL_TYPE_ACCESS) { + mode_t mode = inode->i_mode; + error = posix_acl_equiv_mode(acl, &mode); + + if (error <= 0) { + posix_acl_release(acl); + acl = NULL; + + if (error < 0) + return error; + } + + error = xfs_set_mode(inode, mode); + if (error) + goto out_release; + } + + set_acl: + error = xfs_set_acl(inode, type, acl); + out_release: + posix_acl_release(acl); + out: + return error; +} + +struct xattr_handler xfs_xattr_system_handler = { + .prefix = XATTR_SYSTEM_PREFIX, + .get = xfs_xattr_system_get, + .set = xfs_xattr_system_set, +}; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-14 15:14:12.000000000 +0200 @@ -51,6 +51,7 @@ #include #include #include +#include #include #include @@ -259,9 +260,8 @@ xfs_vn_mknod( { struct inode *inode; struct xfs_inode *ip = NULL; - xfs_acl_t *default_acl = NULL; + struct posix_acl *default_acl = NULL; struct xfs_name name; - int (*test_default_acl)(struct inode *) = _ACL_DEFAULT_EXISTS; int error; /* @@ -271,21 +271,17 @@ xfs_vn_mknod( if (unlikely(!sysv_valid_dev(rdev) || MAJOR(rdev) & ~0x1ff)) return -EINVAL; - if (test_default_acl && test_default_acl(dir)) { - if (!_ACL_ALLOC(default_acl)) { - return -ENOMEM; - } - if (!_ACL_GET_DEFAULT(dir, default_acl)) { - _ACL_FREE(default_acl); - default_acl = NULL; - } + if (IS_POSIXACL(dir)) { + default_acl = xfs_get_acl(dir, ACL_TYPE_DEFAULT); + if (IS_ERR(default_acl)) + return -PTR_ERR(default_acl); + + if (!default_acl) + mode &= ~current->fs->umask; } xfs_dentry_to_name(&name, dentry); - if (IS_POSIXACL(dir) && !default_acl) - mode &= ~current->fs->umask; - switch (mode & S_IFMT) { case S_IFCHR: case S_IFBLK: @@ -313,11 +309,11 @@ xfs_vn_mknod( goto out_cleanup_inode; if (default_acl) { - error = _ACL_INHERIT(inode, mode, default_acl); + error = -xfs_inherit_acl(inode, default_acl); if (unlikely(error)) goto out_cleanup_inode; xfs_iflags_set(ip, XFS_IMODIFIED); - _ACL_FREE(default_acl); + posix_acl_release(default_acl); } @@ -327,8 +323,7 @@ xfs_vn_mknod( out_cleanup_inode: xfs_cleanup_inode(dir, inode, dentry); out_free_acl: - if (default_acl) - _ACL_FREE(default_acl); + posix_acl_release(default_acl); return -error; } @@ -550,38 +545,6 @@ xfs_vn_put_link( kfree(s); } -#ifdef CONFIG_XFS_POSIX_ACL -STATIC int -xfs_check_acl( - struct inode *inode, - int mask) -{ - struct xfs_inode *ip = XFS_I(inode); - int error; - - xfs_itrace_entry(ip); - - if (XFS_IFORK_Q(ip)) { - error = xfs_acl_iaccess(ip, mask, NULL); - if (error != -1) - return -error; - } - - return -EAGAIN; -} - -STATIC int -xfs_vn_permission( - struct inode *inode, - int mask, - struct nameidata *nd) -{ - return generic_permission(inode, mask, xfs_check_acl); -} -#else -#define xfs_vn_permission NULL -#endif - STATIC int xfs_vn_getattr( struct vfsmount *mnt, @@ -694,6 +657,9 @@ xfs_vn_setattr( error = xfs_setattr(XFS_I(inode), &vattr, flags, NULL); if (likely(!error)) vn_revalidate(vn_from_inode(inode)); + + if (!error && (attr->ia_valid & ATTR_MODE)) + error = -xfs_acl_chmod(inode); return -error; } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.h 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.h 2008-06-14 15:14:12.000000000 +0200 @@ -29,6 +29,12 @@ extern void xfs_ichgtime_fast(struct xfs extern void xfs_setup_inode(struct xfs_inode *); +#ifdef CONFIG_XFS_POSIX_ACL +int xfs_vn_permission(struct inode *inode, int mask, struct nameidata *nd); +#else +#define xfs_vn_permission NULL +#endif + #define xfs_vtoi(vp) \ ((struct xfs_inode *)vn_to_inode(vp)->i_private) Index: linux-2.6-xfs/fs/xfs/xfs_acl.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.h 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.h 2008-06-14 15:55:57.000000000 +0200 @@ -18,82 +18,85 @@ #ifndef __XFS_ACL_H__ #define __XFS_ACL_H__ -/* - * Access Control Lists - */ -typedef __uint16_t xfs_acl_perm_t; -typedef __int32_t xfs_acl_type_t; -typedef __int32_t xfs_acl_tag_t; -typedef __int32_t xfs_acl_id_t; +struct inode; +struct posix_acl; +struct xfs_inode; + #define XFS_ACL_MAX_ENTRIES 25 #define XFS_ACL_NOT_PRESENT (-1) -typedef struct xfs_acl_entry { - xfs_acl_tag_t ae_tag; - xfs_acl_id_t ae_id; - xfs_acl_perm_t ae_perm; -} xfs_acl_entry_t; - -typedef struct xfs_acl { - __int32_t acl_cnt; - xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES]; -} xfs_acl_t; +struct xfs_acl { + __be32 acl_cnt; + struct xfs_acl_entry { + __be32 ae_tag; + __be32 ae_id; + __be16 ae_perm; + } acl_entry[XFS_ACL_MAX_ENTRIES]; +}; /* On-disk XFS extended attribute names */ -#define SGI_ACL_FILE "SGI_ACL_FILE" -#define SGI_ACL_DEFAULT "SGI_ACL_DEFAULT" +#define SGI_ACL_FILE "SGI_ACL_FILE" +#define SGI_ACL_DEFAULT "SGI_ACL_DEFAULT" #define SGI_ACL_FILE_SIZE (sizeof(SGI_ACL_FILE)-1) #define SGI_ACL_DEFAULT_SIZE (sizeof(SGI_ACL_DEFAULT)-1) #ifdef CONFIG_XFS_POSIX_ACL -struct vattr; -struct xfs_inode; +struct posix_acl *xfs_get_acl(struct inode *inode, int type); +int xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl); +int xfs_acl_chmod(struct inode *inode); +void xfs_inode_init_acls(struct xfs_inode *ip); +void xfs_inode_clear_acls(struct xfs_inode *ip); +int posix_acl_access_exists(struct inode *inode); +int posix_acl_default_exists(struct inode *inode); -extern struct kmem_zone *xfs_acl_zone; -#define xfs_acl_zone_init(zone, name) \ - (zone) = kmem_zone_init(sizeof(xfs_acl_t), (name)) -#define xfs_acl_zone_destroy(zone) kmem_zone_destroy(zone) - -extern int xfs_acl_inherit(bhv_vnode_t *, mode_t mode, xfs_acl_t *); -extern int xfs_acl_iaccess(struct xfs_inode *, mode_t, cred_t *); -extern int xfs_acl_vtoacl(bhv_vnode_t *, xfs_acl_t *, xfs_acl_t *); -extern int xfs_acl_vhasacl_access(bhv_vnode_t *); -extern int xfs_acl_vhasacl_default(bhv_vnode_t *); -extern int xfs_acl_vset(bhv_vnode_t *, void *, size_t, int); -extern int xfs_acl_vget(bhv_vnode_t *, void *, size_t, int); -extern int xfs_acl_vremove(bhv_vnode_t *, int); - -#define _ACL_TYPE_ACCESS 1 -#define _ACL_TYPE_DEFAULT 2 -#define _ACL_PERM_INVALID(perm) ((perm) & ~(ACL_READ|ACL_WRITE|ACL_EXECUTE)) - -#define _ACL_INHERIT(c,m,d) (xfs_acl_inherit(c,m,d)) -#define _ACL_GET_ACCESS(pv,pa) (xfs_acl_vtoacl(pv,pa,NULL) == 0) -#define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd) == 0) -#define _ACL_ACCESS_EXISTS xfs_acl_vhasacl_access -#define _ACL_DEFAULT_EXISTS xfs_acl_vhasacl_default - -#define _ACL_ALLOC(a) ((a) = kmem_zone_alloc(xfs_acl_zone, KM_SLEEP)) -#define _ACL_FREE(a) ((a)? kmem_zone_free(xfs_acl_zone, (a)):(void)0) +extern struct xattr_handler xfs_xattr_system_handler; #else -#define xfs_acl_zone_init(zone,name) -#define xfs_acl_zone_destroy(zone) -#define xfs_acl_vset(v,p,sz,t) (-EOPNOTSUPP) -#define xfs_acl_vget(v,p,sz,t) (-EOPNOTSUPP) -#define xfs_acl_vremove(v,t) (-EOPNOTSUPP) -#define xfs_acl_vhasacl_access(v) (0) -#define xfs_acl_vhasacl_default(v) (0) -#define _ACL_ALLOC(a) (1) /* successfully allocate nothing */ -#define _ACL_FREE(a) ((void)0) -#define _ACL_INHERIT(c,m,d) (0) -#define _ACL_GET_ACCESS(pv,pa) (0) -#define _ACL_GET_DEFAULT(pv,pd) (0) -#define _ACL_ACCESS_EXISTS (NULL) -#define _ACL_DEFAULT_EXISTS (NULL) -#endif +static inline struct posix_acl * +xfs_get_acl(struct inode *inode, int type) +{ + BUG(); + return NULL; +} + +static inline int +xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl) +{ + BUG(); + return 0; +} + +static inline int +xfs_acl_chmod(struct inode *inode) +{ + return 0; +} + +static inline void +xfs_inode_init_acls(struct xfs_inode *ip) +{ +} + +static inline void +xfs_inode_clear_acls(struct xfs_inode *ip) +{ +} + +static inline int +posix_acl_access_exists(struct inode *inode) +{ + return 0; +} + +static inline int +posix_acl_default_exists(struct inode *inode) +{ + return 0; +} + +#endif /* CONFIG_XFS_POSIX_ACL */ #endif /* __XFS_ACL_H__ */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-14 15:14:12.000000000 +0200 @@ -50,7 +50,6 @@ #include "xfs_dir2_block.h" #include "xfs_dir2_node.h" #include "xfs_dir2_trace.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_attr_leaf.h" #include "xfs_inode_item.h" @@ -178,10 +177,6 @@ EXPORT_SYMBOL(uuid_table_remove); EXPORT_SYMBOL(vn_hold); EXPORT_SYMBOL(vn_revalidate); -#if defined(CONFIG_XFS_POSIX_ACL) -EXPORT_SYMBOL(xfs_acl_vtoacl); -EXPORT_SYMBOL(xfs_acl_inherit); -#endif EXPORT_SYMBOL(xfs_alloc_buftarg); EXPORT_SYMBOL(xfs_flush_buftarg); EXPORT_SYMBOL(xfs_free_buftarg); Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-14 15:03:47.000000000 +0200 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,881 +0,0 @@ -/* - * Copyright (c) 2001-2002,2005 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ -#include "xfs.h" -#include "xfs_fs.h" -#include "xfs_types.h" -#include "xfs_bit.h" -#include "xfs_inum.h" -#include "xfs_ag.h" -#include "xfs_dir2.h" -#include "xfs_bmap_btree.h" -#include "xfs_alloc_btree.h" -#include "xfs_ialloc_btree.h" -#include "xfs_dir2_sf.h" -#include "xfs_attr_sf.h" -#include "xfs_dinode.h" -#include "xfs_inode.h" -#include "xfs_btree.h" -#include "xfs_acl.h" -#include "xfs_attr.h" -#include "xfs_vnodeops.h" - -#include -#include - -STATIC int xfs_acl_setmode(bhv_vnode_t *, xfs_acl_t *, int *); -STATIC void xfs_acl_filter_mode(mode_t, xfs_acl_t *); -STATIC void xfs_acl_get_endian(xfs_acl_t *); -STATIC int xfs_acl_access(uid_t, gid_t, xfs_acl_t *, mode_t, cred_t *); -STATIC int xfs_acl_invalid(xfs_acl_t *); -STATIC void xfs_acl_sync_mode(mode_t, xfs_acl_t *); -STATIC void xfs_acl_get_attr(bhv_vnode_t *, xfs_acl_t *, int, int, int *); -STATIC void xfs_acl_set_attr(bhv_vnode_t *, xfs_acl_t *, int, int *); -STATIC int xfs_acl_allow_set(bhv_vnode_t *, int); - -kmem_zone_t *xfs_acl_zone; - - -/* - * Test for existence of access ACL attribute as efficiently as possible. - */ -int -xfs_acl_vhasacl_access( - bhv_vnode_t *vp) -{ - int error; - - xfs_acl_get_attr(vp, NULL, _ACL_TYPE_ACCESS, ATTR_KERNOVAL, &error); - return (error == 0); -} - -/* - * Test for existence of default ACL attribute as efficiently as possible. - */ -int -xfs_acl_vhasacl_default( - bhv_vnode_t *vp) -{ - int error; - - if (!S_ISDIR(vp->i_mode)) - return 0; - xfs_acl_get_attr(vp, NULL, _ACL_TYPE_DEFAULT, ATTR_KERNOVAL, &error); - return (error == 0); -} - -/* - * Convert from extended attribute representation to in-memory for XFS. - */ -STATIC int -posix_acl_xattr_to_xfs( - posix_acl_xattr_header *src, - size_t size, - xfs_acl_t *dest) -{ - posix_acl_xattr_entry *src_entry; - xfs_acl_entry_t *dest_entry; - int n; - - if (!src || !dest) - return EINVAL; - - if (size < sizeof(posix_acl_xattr_header)) - return EINVAL; - - if (src->a_version != cpu_to_le32(POSIX_ACL_XATTR_VERSION)) - return EOPNOTSUPP; - - memset(dest, 0, sizeof(xfs_acl_t)); - dest->acl_cnt = posix_acl_xattr_count(size); - if (dest->acl_cnt < 0 || dest->acl_cnt > XFS_ACL_MAX_ENTRIES) - return EINVAL; - - /* - * acl_set_file(3) may request that we set default ACLs with - * zero length -- defend (gracefully) against that here. - */ - if (!dest->acl_cnt) - return 0; - - src_entry = (posix_acl_xattr_entry *)((char *)src + sizeof(*src)); - dest_entry = &dest->acl_entry[0]; - - for (n = 0; n < dest->acl_cnt; n++, src_entry++, dest_entry++) { - dest_entry->ae_perm = le16_to_cpu(src_entry->e_perm); - if (_ACL_PERM_INVALID(dest_entry->ae_perm)) - return EINVAL; - dest_entry->ae_tag = le16_to_cpu(src_entry->e_tag); - switch(dest_entry->ae_tag) { - case ACL_USER: - case ACL_GROUP: - dest_entry->ae_id = le32_to_cpu(src_entry->e_id); - break; - case ACL_USER_OBJ: - case ACL_GROUP_OBJ: - case ACL_MASK: - case ACL_OTHER: - dest_entry->ae_id = ACL_UNDEFINED_ID; - break; - default: - return EINVAL; - } - } - if (xfs_acl_invalid(dest)) - return EINVAL; - - return 0; -} - -/* - * Comparison function called from xfs_sort(). - * Primary key is ae_tag, secondary key is ae_id. - */ -STATIC int -xfs_acl_entry_compare( - const void *va, - const void *vb) -{ - xfs_acl_entry_t *a = (xfs_acl_entry_t *)va, - *b = (xfs_acl_entry_t *)vb; - - if (a->ae_tag == b->ae_tag) - return (a->ae_id - b->ae_id); - return (a->ae_tag - b->ae_tag); -} - -/* - * Convert from in-memory XFS to extended attribute representation. - */ -STATIC int -posix_acl_xfs_to_xattr( - xfs_acl_t *src, - posix_acl_xattr_header *dest, - size_t size) -{ - int n; - size_t new_size = posix_acl_xattr_size(src->acl_cnt); - posix_acl_xattr_entry *dest_entry; - xfs_acl_entry_t *src_entry; - - if (size < new_size) - return -ERANGE; - - /* Need to sort src XFS ACL by */ - xfs_sort(src->acl_entry, src->acl_cnt, sizeof(src->acl_entry[0]), - xfs_acl_entry_compare); - - dest->a_version = cpu_to_le32(POSIX_ACL_XATTR_VERSION); - dest_entry = &dest->a_entries[0]; - src_entry = &src->acl_entry[0]; - for (n = 0; n < src->acl_cnt; n++, dest_entry++, src_entry++) { - dest_entry->e_perm = cpu_to_le16(src_entry->ae_perm); - if (_ACL_PERM_INVALID(src_entry->ae_perm)) - return -EINVAL; - dest_entry->e_tag = cpu_to_le16(src_entry->ae_tag); - switch (src_entry->ae_tag) { - case ACL_USER: - case ACL_GROUP: - dest_entry->e_id = cpu_to_le32(src_entry->ae_id); - break; - case ACL_USER_OBJ: - case ACL_GROUP_OBJ: - case ACL_MASK: - case ACL_OTHER: - dest_entry->e_id = cpu_to_le32(ACL_UNDEFINED_ID); - break; - default: - return -EINVAL; - } - } - return new_size; -} - -int -xfs_acl_vget( - bhv_vnode_t *vp, - void *acl, - size_t size, - int kind) -{ - int error; - xfs_acl_t *xfs_acl = NULL; - posix_acl_xattr_header *ext_acl = acl; - int flags = 0; - - VN_HOLD(vp); - if(size) { - if (!(_ACL_ALLOC(xfs_acl))) { - error = ENOMEM; - goto out; - } - memset(xfs_acl, 0, sizeof(xfs_acl_t)); - } else - flags = ATTR_KERNOVAL; - - xfs_acl_get_attr(vp, xfs_acl, kind, flags, &error); - if (error) - goto out; - - if (!size) { - error = -posix_acl_xattr_size(XFS_ACL_MAX_ENTRIES); - } else { - if (xfs_acl_invalid(xfs_acl)) { - error = EINVAL; - goto out; - } - if (kind == _ACL_TYPE_ACCESS) - xfs_acl_sync_mode(xfs_vtoi(vp)->i_d.di_mode, xfs_acl); - error = -posix_acl_xfs_to_xattr(xfs_acl, ext_acl, size); - } -out: - VN_RELE(vp); - if(xfs_acl) - _ACL_FREE(xfs_acl); - return -error; -} - -int -xfs_acl_vremove( - bhv_vnode_t *vp, - int kind) -{ - int error; - - VN_HOLD(vp); - error = xfs_acl_allow_set(vp, kind); - if (!error) { - error = xfs_attr_remove(xfs_vtoi(vp), - kind == _ACL_TYPE_DEFAULT? - SGI_ACL_DEFAULT: SGI_ACL_FILE, - ATTR_ROOT); - if (error == ENOATTR) - error = 0; /* 'scool */ - } - VN_RELE(vp); - return -error; -} - -int -xfs_acl_vset( - bhv_vnode_t *vp, - void *acl, - size_t size, - int kind) -{ - posix_acl_xattr_header *ext_acl = acl; - xfs_acl_t *xfs_acl; - int error; - int basicperms = 0; /* more than std unix perms? */ - - if (!acl) - return -EINVAL; - - if (!(_ACL_ALLOC(xfs_acl))) - return -ENOMEM; - - error = posix_acl_xattr_to_xfs(ext_acl, size, xfs_acl); - if (error) { - _ACL_FREE(xfs_acl); - return -error; - } - if (!xfs_acl->acl_cnt) { - _ACL_FREE(xfs_acl); - return 0; - } - - VN_HOLD(vp); - error = xfs_acl_allow_set(vp, kind); - - /* Incoming ACL exists, set file mode based on its value */ - if (!error && kind == _ACL_TYPE_ACCESS) - error = xfs_acl_setmode(vp, xfs_acl, &basicperms); - - if (error) - goto out; - - /* - * If we have more than std unix permissions, set up the actual attr. - * Otherwise, delete any existing attr. This prevents us from - * having actual attrs for permissions that can be stored in the - * standard permission bits. - */ - if (!basicperms) { - xfs_acl_set_attr(vp, xfs_acl, kind, &error); - } else { - error = -xfs_acl_vremove(vp, _ACL_TYPE_ACCESS); - } - -out: - VN_RELE(vp); - _ACL_FREE(xfs_acl); - return -error; -} - -int -xfs_acl_iaccess( - xfs_inode_t *ip, - mode_t mode, - cred_t *cr) -{ - xfs_acl_t *acl; - int rval; - struct xfs_name acl_name = {SGI_ACL_FILE, SGI_ACL_FILE_SIZE}; - - if (!(_ACL_ALLOC(acl))) - return -1; - - /* If the file has no ACL return -1. */ - rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { - _ACL_FREE(acl); - return -1; - } - xfs_acl_get_endian(acl); - - /* If the file has an empty ACL return -1. */ - if (acl->acl_cnt == XFS_ACL_NOT_PRESENT) { - _ACL_FREE(acl); - return -1; - } - - /* Synchronize ACL with mode bits */ - xfs_acl_sync_mode(ip->i_d.di_mode, acl); - - rval = xfs_acl_access(ip->i_d.di_uid, ip->i_d.di_gid, acl, mode, cr); - _ACL_FREE(acl); - return rval; -} - -STATIC int -xfs_acl_allow_set( - bhv_vnode_t *vp, - int kind) -{ - if (vp->i_flags & (S_IMMUTABLE|S_APPEND)) - return EPERM; - if (kind == _ACL_TYPE_DEFAULT && !S_ISDIR(vp->i_mode)) - return ENOTDIR; - if (vp->i_sb->s_flags & MS_RDONLY) - return EROFS; - if (xfs_vtoi(vp)->i_d.di_uid != current->fsuid && !capable(CAP_FOWNER)) - return EPERM; - return 0; -} - -/* - * Note: cr is only used here for the capability check if the ACL test fails. - * It is not used to find out the credentials uid or groups etc, as was - * done in IRIX. It is assumed that the uid and groups for the current - * thread are taken from "current" instead of the cr parameter. - */ -STATIC int -xfs_acl_access( - uid_t fuid, - gid_t fgid, - xfs_acl_t *fap, - mode_t md, - cred_t *cr) -{ - xfs_acl_entry_t matched; - int i, allows; - int maskallows = -1; /* true, but not 1, either */ - int seen_userobj = 0; - - matched.ae_tag = 0; /* Invalid type */ - matched.ae_perm = 0; - - for (i = 0; i < fap->acl_cnt; i++) { - /* - * Break out if we've got a user_obj entry or - * a user entry and the mask (and have processed USER_OBJ) - */ - if (matched.ae_tag == ACL_USER_OBJ) - break; - if (matched.ae_tag == ACL_USER) { - if (maskallows != -1 && seen_userobj) - break; - if (fap->acl_entry[i].ae_tag != ACL_MASK && - fap->acl_entry[i].ae_tag != ACL_USER_OBJ) - continue; - } - /* True if this entry allows the requested access */ - allows = ((fap->acl_entry[i].ae_perm & md) == md); - - switch (fap->acl_entry[i].ae_tag) { - case ACL_USER_OBJ: - seen_userobj = 1; - if (fuid != current->fsuid) - continue; - matched.ae_tag = ACL_USER_OBJ; - matched.ae_perm = allows; - break; - case ACL_USER: - if (fap->acl_entry[i].ae_id != current->fsuid) - continue; - matched.ae_tag = ACL_USER; - matched.ae_perm = allows; - break; - case ACL_GROUP_OBJ: - if ((matched.ae_tag == ACL_GROUP_OBJ || - matched.ae_tag == ACL_GROUP) && !allows) - continue; - if (!in_group_p(fgid)) - continue; - matched.ae_tag = ACL_GROUP_OBJ; - matched.ae_perm = allows; - break; - case ACL_GROUP: - if ((matched.ae_tag == ACL_GROUP_OBJ || - matched.ae_tag == ACL_GROUP) && !allows) - continue; - if (!in_group_p(fap->acl_entry[i].ae_id)) - continue; - matched.ae_tag = ACL_GROUP; - matched.ae_perm = allows; - break; - case ACL_MASK: - maskallows = allows; - break; - case ACL_OTHER: - if (matched.ae_tag != 0) - continue; - matched.ae_tag = ACL_OTHER; - matched.ae_perm = allows; - break; - } - } - /* - * First possibility is that no matched entry allows access. - * The capability to override DAC may exist, so check for it. - */ - switch (matched.ae_tag) { - case ACL_OTHER: - case ACL_USER_OBJ: - if (matched.ae_perm) - return 0; - break; - case ACL_USER: - case ACL_GROUP_OBJ: - case ACL_GROUP: - if (maskallows && matched.ae_perm) - return 0; - break; - case 0: - break; - } - - /* EACCES tells generic_permission to check for capability overrides */ - return EACCES; -} -EXPORT_SYMBOL(xfs_acl_access); - -/* - * ACL validity checker. - * This acl validation routine checks each ACL entry read in makes sense. - */ -STATIC int -xfs_acl_invalid( - xfs_acl_t *aclp) -{ - xfs_acl_entry_t *entry, *e; - int user = 0, group = 0, other = 0, mask = 0; - int mask_required = 0; - int i, j; - - if (!aclp) - goto acl_invalid; - - if (aclp->acl_cnt > XFS_ACL_MAX_ENTRIES) - goto acl_invalid; - - for (i = 0; i < aclp->acl_cnt; i++) { - entry = &aclp->acl_entry[i]; - switch (entry->ae_tag) { - case ACL_USER_OBJ: - if (user++) - goto acl_invalid; - break; - case ACL_GROUP_OBJ: - if (group++) - goto acl_invalid; - break; - case ACL_OTHER: - if (other++) - goto acl_invalid; - break; - case ACL_USER: - case ACL_GROUP: - for (j = i + 1; j < aclp->acl_cnt; j++) { - e = &aclp->acl_entry[j]; - if (e->ae_id == entry->ae_id && - e->ae_tag == entry->ae_tag) - goto acl_invalid; - } - mask_required++; - break; - case ACL_MASK: - if (mask++) - goto acl_invalid; - break; - default: - goto acl_invalid; - } - } - if (!user || !group || !other || (mask_required && !mask)) - goto acl_invalid; - else - return 0; -acl_invalid: - return EINVAL; -} - -/* - * Do ACL endian conversion. - */ -STATIC void -xfs_acl_get_endian( - xfs_acl_t *aclp) -{ - xfs_acl_entry_t *ace, *end; - - INT_SET(aclp->acl_cnt, ARCH_CONVERT, aclp->acl_cnt); - end = &aclp->acl_entry[0]+aclp->acl_cnt; - for (ace = &aclp->acl_entry[0]; ace < end; ace++) { - INT_SET(ace->ae_tag, ARCH_CONVERT, ace->ae_tag); - INT_SET(ace->ae_id, ARCH_CONVERT, ace->ae_id); - INT_SET(ace->ae_perm, ARCH_CONVERT, ace->ae_perm); - } -} - -/* - * Get the ACL from the EA and do endian conversion. - */ -STATIC void -xfs_acl_get_attr( - bhv_vnode_t *vp, - xfs_acl_t *aclp, - int kind, - int flags, - int *error) -{ - int len = sizeof(xfs_acl_t); - - ASSERT((flags & ATTR_KERNOVAL) ? (aclp == NULL) : 1); - flags |= ATTR_ROOT; - *error = xfs_attr_get(xfs_vtoi(vp), - kind == _ACL_TYPE_ACCESS ? - SGI_ACL_FILE : SGI_ACL_DEFAULT, - (char *)aclp, &len, flags); - if (*error || (flags & ATTR_KERNOVAL)) - return; - xfs_acl_get_endian(aclp); -} - -/* - * Set the EA with the ACL and do endian conversion. - */ -STATIC void -xfs_acl_set_attr( - bhv_vnode_t *vp, - xfs_acl_t *aclp, - int kind, - int *error) -{ - xfs_acl_entry_t *ace, *newace, *end; - xfs_acl_t *newacl; - int len; - - if (!(_ACL_ALLOC(newacl))) { - *error = ENOMEM; - return; - } - - len = sizeof(xfs_acl_t) - - (sizeof(xfs_acl_entry_t) * (XFS_ACL_MAX_ENTRIES - aclp->acl_cnt)); - end = &aclp->acl_entry[0]+aclp->acl_cnt; - for (ace = &aclp->acl_entry[0], newace = &newacl->acl_entry[0]; - ace < end; - ace++, newace++) { - INT_SET(newace->ae_tag, ARCH_CONVERT, ace->ae_tag); - INT_SET(newace->ae_id, ARCH_CONVERT, ace->ae_id); - INT_SET(newace->ae_perm, ARCH_CONVERT, ace->ae_perm); - } - INT_SET(newacl->acl_cnt, ARCH_CONVERT, aclp->acl_cnt); - *error = xfs_attr_set(xfs_vtoi(vp), - kind == _ACL_TYPE_ACCESS ? - SGI_ACL_FILE: SGI_ACL_DEFAULT, - (char *)newacl, len, ATTR_ROOT); - _ACL_FREE(newacl); -} - -int -xfs_acl_vtoacl( - bhv_vnode_t *vp, - xfs_acl_t *access_acl, - xfs_acl_t *default_acl) -{ - int error = 0; - - if (access_acl) { - /* - * Get the Access ACL and the mode. If either cannot - * be obtained for some reason, invalidate the access ACL. - */ - xfs_acl_get_attr(vp, access_acl, _ACL_TYPE_ACCESS, 0, &error); - if (error) - access_acl->acl_cnt = XFS_ACL_NOT_PRESENT; - else /* We have a good ACL and the file mode, synchronize. */ - xfs_acl_sync_mode(xfs_vtoi(vp)->i_d.di_mode, access_acl); - } - - if (default_acl) { - xfs_acl_get_attr(vp, default_acl, _ACL_TYPE_DEFAULT, 0, &error); - if (error) - default_acl->acl_cnt = XFS_ACL_NOT_PRESENT; - } - return error; -} - -/* - * This function retrieves the parent directory's acl, processes it - * and lets the child inherit the acl(s) that it should. - */ -int -xfs_acl_inherit( - bhv_vnode_t *vp, - mode_t mode, - xfs_acl_t *pdaclp) -{ - xfs_acl_t *cacl; - int error = 0; - int basicperms = 0; - - /* - * If the parent does not have a default ACL, or it's an - * invalid ACL, we're done. - */ - if (!vp) - return 0; - if (!pdaclp || xfs_acl_invalid(pdaclp)) - return 0; - - /* - * Copy the default ACL of the containing directory to - * the access ACL of the new file and use the mode that - * was passed in to set up the correct initial values for - * the u::,g::[m::], and o:: entries. This is what makes - * umask() "work" with ACL's. - */ - - if (!(_ACL_ALLOC(cacl))) - return ENOMEM; - - memcpy(cacl, pdaclp, sizeof(xfs_acl_t)); - xfs_acl_filter_mode(mode, cacl); - error = xfs_acl_setmode(vp, cacl, &basicperms); - if (error) - goto out_error; - - /* - * Set the Default and Access ACL on the file. The mode is already - * set on the file, so we don't need to worry about that. - * - * If the new file is a directory, its default ACL is a copy of - * the containing directory's default ACL. - */ - if (S_ISDIR(vp->i_mode)) - xfs_acl_set_attr(vp, pdaclp, _ACL_TYPE_DEFAULT, &error); - if (!error && !basicperms) - xfs_acl_set_attr(vp, cacl, _ACL_TYPE_ACCESS, &error); -out_error: - _ACL_FREE(cacl); - return error; -} - -/* - * Set up the correct mode on the file based on the supplied ACL. This - * makes sure that the mode on the file reflects the state of the - * u::,g::[m::], and o:: entries in the ACL. Since the mode is where - * the ACL is going to get the permissions for these entries, we must - * synchronize the mode whenever we set the ACL on a file. - */ -STATIC int -xfs_acl_setmode( - bhv_vnode_t *vp, - xfs_acl_t *acl, - int *basicperms) -{ - bhv_vattr_t va; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - int i, nomask = 1; - - *basicperms = 1; - - if (acl->acl_cnt == XFS_ACL_NOT_PRESENT) - return 0; - - /* - * Copy the u::, g::, o::, and m:: bits from the ACL into the - * mode. The m:: bits take precedence over the g:: bits. - */ - va.va_mask = XFS_AT_MODE; - va.va_mode = xfs_vtoi(vp)->i_d.di_mode; - va.va_mode &= ~(S_IRWXU|S_IRWXG|S_IRWXO); - ap = acl->acl_entry; - for (i = 0; i < acl->acl_cnt; ++i) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - va.va_mode |= ap->ae_perm << 6; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: /* more than just standard modes */ - nomask = 0; - va.va_mode |= ap->ae_perm << 3; - *basicperms = 0; - break; - case ACL_OTHER: - va.va_mode |= ap->ae_perm; - break; - default: /* more than just standard modes */ - *basicperms = 0; - break; - } - ap++; - } - - /* Set the group bits from ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - va.va_mode |= gap->ae_perm << 3; - - return xfs_setattr(xfs_vtoi(vp), &va, 0, sys_cred); -} - -/* - * The permissions for the special ACL entries (u::, g::[m::], o::) are - * actually stored in the file mode (if there is both a group and a mask, - * the group is stored in the ACL entry and the mask is stored on the file). - * This allows the mode to remain automatically in sync with the ACL without - * the need for a call-back to the ACL system at every point where the mode - * could change. This function takes the permissions from the specified mode - * and places it in the supplied ACL. - * - * This implementation draws its validity from the fact that, when the ACL - * was assigned, the mode was copied from the ACL. - * If the mode did not change, therefore, the mode remains exactly what was - * taken from the special ACL entries at assignment. - * If a subsequent chmod() was done, the POSIX spec says that the change in - * mode must cause an update to the ACL seen at user level and used for - * access checks. Before and after a mode change, therefore, the file mode - * most accurately reflects what the special ACL entries should permit/deny. - * - * CAVEAT: If someone sets the SGI_ACL_FILE attribute directly, - * the existing mode bits will override whatever is in the - * ACL. Similarly, if there is a pre-existing ACL that was - * never in sync with its mode (owing to a bug in 6.5 and - * before), it will now magically (or mystically) be - * synchronized. This could cause slight astonishment, but - * it is better than inconsistent permissions. - * - * The supplied ACL is a template that may contain any combination - * of special entries. These are treated as place holders when we fill - * out the ACL. This routine does not add or remove special entries, it - * simply unites each special entry with its associated set of permissions. - */ -STATIC void -xfs_acl_sync_mode( - mode_t mode, - xfs_acl_t *acl) -{ - int i, nomask = 1; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - - /* - * Set ACL entries. POSIX1003.1eD16 requires that the MASK - * be set instead of the GROUP entry, if there is a MASK. - */ - for (ap = acl->acl_entry, i = 0; i < acl->acl_cnt; ap++, i++) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - ap->ae_perm = (mode >> 6) & 0x7; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: - nomask = 0; - ap->ae_perm = (mode >> 3) & 0x7; - break; - case ACL_OTHER: - ap->ae_perm = mode & 0x7; - break; - default: - break; - } - } - /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm = (mode >> 3) & 0x7; -} - -/* - * When inheriting an Access ACL from a directory Default ACL, - * the ACL bits are set to the intersection of the ACL default - * permission bits and the file permission bits in mode. If there - * are no permission bits on the file then we must not give them - * the ACL. This is what what makes umask() work with ACLs. - */ -STATIC void -xfs_acl_filter_mode( - mode_t mode, - xfs_acl_t *acl) -{ - int i, nomask = 1; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - - /* - * Set ACL entries. POSIX1003.1eD16 requires that the MASK - * be merged with GROUP entry, if there is a MASK. - */ - for (ap = acl->acl_entry, i = 0; i < acl->acl_cnt; ap++, i++) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - ap->ae_perm &= (mode >> 6) & 0x7; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: - nomask = 0; - ap->ae_perm &= (mode >> 3) & 0x7; - break; - case ACL_OTHER: - ap->ae_perm &= mode & 0x7; - break; - default: - break; - } - } - /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm &= (mode >> 3) & 0x7; -} Index: linux-2.6-xfs/fs/xfs/Makefile =================================================================== --- linux-2.6-xfs.orig/fs/xfs/Makefile 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/Makefile 2008-06-14 15:14:12.000000000 +0200 @@ -29,7 +29,7 @@ obj-$(CONFIG_XFS_QUOTA) += quota/ obj-$(CONFIG_XFS_DMAPI) += dmapi/ xfs-$(CONFIG_XFS_RT) += xfs_rtalloc.o -xfs-$(CONFIG_XFS_POSIX_ACL) += xfs_acl.o +xfs-$(CONFIG_XFS_POSIX_ACL) += $(XFS_LINUX)/xfs_acl.o xfs-$(CONFIG_PROC_FS) += $(XFS_LINUX)/xfs_stats.o xfs-$(CONFIG_SYSCTL) += $(XFS_LINUX)/xfs_sysctl.o xfs-$(CONFIG_COMPAT) += $(XFS_LINUX)/xfs_ioctl32.o Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2008-06-14 15:56:37.000000000 +0200 @@ -816,6 +816,7 @@ xfs_iread( ip->i_mount = mp; atomic_set(&ip->i_iocount, 0); spin_lock_init(&ip->i_flags_lock); + xfs_inode_init_acls(ip); /* * Get pointer's to the on-disk inode and the buffer containing it. @@ -2668,6 +2669,8 @@ xfs_idestroy( } xfs_inode_item_destroy(ip); } + + xfs_inode_clear_acls(ip); kmem_zone_free(xfs_inode_zone, ip); } Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2008-06-14 15:14:12.000000000 +0200 @@ -18,6 +18,7 @@ #ifndef __XFS_INODE_H__ #define __XFS_INODE_H__ +struct posix_acl; struct xfs_dinode; struct xfs_dinode_core; @@ -239,6 +240,11 @@ typedef struct xfs_inode { xfs_fsize_t i_size; /* in-memory size */ xfs_fsize_t i_new_size; /* size when write completes */ atomic_t i_iocount; /* outstanding I/O count */ + +#ifdef CONFIG_XFS_POSIX_ACL + struct posix_acl *i_acl; + struct posix_acl *i_default_acl; +#endif /* Trace buffers per inode. */ #ifdef XFS_INODE_TRACE struct ktrace *i_trace; /* general inode trace */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-14 15:14:12.000000000 +0200 @@ -29,70 +29,6 @@ #include -/* - * ACL handling. Should eventually be moved into xfs_acl.c - */ - -static int -xfs_decode_acl(const char *name) -{ - if (strcmp(name, "posix_acl_access") == 0) - return _ACL_TYPE_ACCESS; - else if (strcmp(name, "posix_acl_default") == 0) - return _ACL_TYPE_DEFAULT; - return -EINVAL; -} - -/* - * Get system extended attributes which at the moment only - * includes Posix ACLs. - */ -static int -xfs_xattr_system_get(struct inode *inode, const char *name, - void *buffer, size_t size) -{ - int acl; - - acl = xfs_decode_acl(name); - if (acl < 0) - return acl; - - return xfs_acl_vget(inode, buffer, size, acl); -} - -static int -xfs_xattr_system_set(struct inode *inode, const char *name, - const void *value, size_t size, int flags) -{ - int error, acl; - - acl = xfs_decode_acl(name); - if (acl < 0) - return acl; - if (flags & XATTR_CREATE) - return -EINVAL; - - if (!value) - return xfs_acl_vremove(inode, acl); - - error = xfs_acl_vset(inode, (void *)value, size, acl); - if (!error) - vn_revalidate(inode); - return error; -} - -static struct xattr_handler xfs_xattr_system_handler = { - .prefix = XATTR_SYSTEM_PREFIX, - .get = xfs_xattr_system_get, - .set = xfs_xattr_system_set, -}; - - -/* - * Real xattr handling. The only difference between the namespaces is - * a flag passed to the low-level attr code. - */ - static int __xfs_xattr_get(struct inode *inode, const char *name, void *value, size_t size, int xflags) @@ -202,7 +138,9 @@ struct xattr_handler *xfs_xattr_handlers &xfs_xattr_user_handler, &xfs_xattr_trusted_handler, &xfs_xattr_security_handler, +#ifdef CONFIG_XFS_POSIX_ACL &xfs_xattr_system_handler, +#endif NULL }; @@ -313,7 +251,7 @@ xfs_vn_listxattr(struct dentry *dentry, /* * Then add the two synthetic ACL attributes. */ - if (xfs_acl_vhasacl_access(inode)) { + if (posix_acl_access_exists(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, data, size, &context.count); @@ -321,7 +259,7 @@ xfs_vn_listxattr(struct dentry *dentry, return error; } - if (xfs_acl_vhasacl_default(inode)) { + if (posix_acl_default_exists(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, data, size, &context.count); Index: linux-2.6-xfs/fs/xfs/Kconfig =================================================================== --- linux-2.6-xfs.orig/fs/xfs/Kconfig 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/Kconfig 2008-06-14 15:14:12.000000000 +0200 @@ -51,6 +51,7 @@ config XFS_DMAPI config XFS_POSIX_ACL bool "XFS POSIX ACL support" depends on XFS_FS + select FS_POSIX_ACL help POSIX Access Control Lists (ACLs) support permissions for users and groups beyond the owner/group/world scheme. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-06-14 15:57:29.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_itable.h" #include "xfs_fsops.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_utils.h" @@ -1909,18 +1908,8 @@ xfs_init_zones(void) if (!xfs_ili_zone) goto out_destroy_inode_zone; -#ifdef CONFIG_XFS_POSIX_ACL - xfs_acl_zone = kmem_zone_init(sizeof(xfs_acl_t), "xfs_acl"); - if (!xfs_acl_zone) - goto out_destroy_ili_zone; -#endif - return 0; -#ifdef CONFIG_XFS_POSIX_ACL - out_destroy_ili_zone: -#endif - kmem_zone_destroy(xfs_ili_zone); out_destroy_inode_zone: kmem_zone_destroy(xfs_inode_zone); out_destroy_efi_zone: @@ -1956,9 +1945,6 @@ xfs_init_zones(void) STATIC void xfs_destroy_zones(void) { -#ifdef CONFIG_XFS_POSIX_ACL - kmem_zone_destroy(xfs_acl_zone); -#endif kmem_zone_destroy(xfs_ili_zone); kmem_zone_destroy(xfs_inode_zone); kmem_zone_destroy(xfs_efi_zone); Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-14 15:50:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-14 15:50:59.000000000 +0200 @@ -45,7 +45,6 @@ #include "xfs_error.h" #include "xfs_quota.h" #include "xfs_trans_space.h" -#include "xfs_acl.h" #include "xfs_rw.h" #include "xfs_vnodeops.h" Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2008-06-14 15:51:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2008-06-14 15:51:05.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/xfs_rw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rw.c 2008-06-14 15:51:32.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_rw.c 2008-06-14 15:51:34.000000000 +0200 @@ -41,7 +41,6 @@ #include "xfs_ialloc.h" #include "xfs_attr.h" #include "xfs_bmap.h" -#include "xfs_acl.h" #include "xfs_error.h" #include "xfs_buf_item.h" #include "xfs_rw.h" Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2008-06-14 15:51:37.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2008-06-14 15:51:39.000000000 +0200 @@ -47,7 +47,6 @@ #include "xfs_log_priv.h" #include "xfs_dir2_trace.h" #include "xfs_extfree_item.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_mru_cache.h" #include "xfs_filestream.h" Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2008-06-14 15:58:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-06-14 15:58:34.000000000 +0200 @@ -41,7 +41,6 @@ #include "xfs_itable.h" #include "xfs_bmap.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_attr_leaf.h" #include "xfs_inode_item.h" Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-14 15:57:35.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-14 15:57:36.000000000 +0200 @@ -40,7 +40,6 @@ #include "xfs_itable.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_bmap.h" #include "xfs_buf_item.h" Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2008-06-14 15:57:42.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2008-06-14 15:57:43.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_inode_item.h" #include "xfs_buf_item.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_dquot.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_dquot.c 2008-06-14 15:58:28.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_dquot.c 2008-06-14 15:58:30.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_dquot_item.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_dquot_item.c 2008-06-14 15:57:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_dquot_item.c 2008-06-14 15:57:58.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_priv.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c 2008-06-14 15:58:03.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c 2008-06-14 15:58:05.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_bmap.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_bhv.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_bhv.c 2008-06-14 15:58:21.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_bhv.c 2008-06-14 15:58:23.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_qm.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_stats.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_stats.c 2008-06-14 15:58:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_stats.c 2008-06-14 15:58:18.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_qm.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-14 15:57:49.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-14 15:57:51.000000000 +0200 @@ -45,7 +45,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_utils.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_trans_dquot.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_trans_dquot.c 2008-06-14 15:58:07.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_trans_dquot.c 2008-06-14 15:58:09.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_priv.h" From owner-xfs@oss.sgi.com Sat Jun 14 09:42:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:42:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EGgF21022296 for ; Sat, 14 Jun 2008 09:42:16 -0700 X-ASG-Debug-ID: 1213461792-0c0600e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CDBAFFCBBEB for ; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by cuda.sgi.com with ESMTP id WbGgx7b8YawjDiLv for ; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id j5so4037342wah.18 for ; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=JY4JJI2S44eRIC3hS+Mf8WmjJPwRU0fRX6sU+t9fif8=; b=etjZWf6jLqhEY6qDT8zlbRkT2TNyi4SZ+FRojMzxYXzRdrcK/Fop/k/xxiMqD8Ayv4 Hj1p2e4AaETrHcs3d+knJu04fmA5qotJ/ThudZhYhlc4I8Xp9Ghko6wRppPT6kc8wVT/ fTOd/DopWCCPqSFIjcXO0lVvGrnxflO8pVxjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=tDzGi7bo+KxkUlRvY4YoNspXOAhB6ZfJ80WpwS/fFIqDKpfqHT8CGqiIGi7udFpo04 C0xkJ7p2TDky6ewSp2QlHORIiIPWx/pK+Wp2dfmV1RglxCg9674Y1jDyLkCTMjpuKGwJ 2OqQ9pP/M3xYExJ09jzzRApcUJohyo6bvfDbw= Received: by 10.115.79.1 with SMTP id g1mr4505302wal.61.1213461792147; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) Received: by 10.114.183.7 with HTTP; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) Message-ID: Date: Sat, 14 Jun 2008 12:43:12 -0400 From: Simon To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair trouble Subject: xfs_repair trouble MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: cb84e5feed0b76d8 X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.179] X-Barracuda-Start-Time: 1213461792 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4781 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53289 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16345 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: simonjj@gmail.com Precedence: bulk X-list: xfs Hello all, I have a corrupted xfs filesystem on top of a RAID 5 (1TB in size). The RAID is still fully intact but the filesystem was damaged. When trying to repair the filesystem xfs_repair fails. I have tried various versions of xfs_repair, the latest stable (2.9.8) and the latest trunk (from CVS). I'd love to investigate and/or fix the issue further but I am a bit confused about some of my xfs_repair runs (both done with trunk). Could someone shed some light on where the problem could be, I'd be happy to continue digging if I would only know where roughly Run 1 ============================================ ./xfs_repair -P -m 170 /dev/evms/monster_evms ... more output ... bad hash table for directory inode 4842 (no data entry): rebuilding rebuilding directory inode 4842 entry ".." in directory inode 27930072 points to free inode 2013274702 bad hash table for directory inode 27930072 (no data entry): rebuilding rebuilding directory inode 27930072 bad hash table for directory inode 28776251 (no data entry): rebuilding rebuilding directory inode 28776251 fixing i8count in inode 29111010 xfs_repair: phase6.c:3411: shortform_dir2_entry_check: Assertion `bytes_deleted > 0' failed. Aborted ================================================= Exits with an Assert, it would be interesting to know why this Assert is there and what it means for bytes_deleted to be 0. Run 2 ============================================ ./xfs_repair -P -m 166 /dev/evms/monster_evms ... more output ... bad hash table for directory inode 2013274673 (no data entry): rebuilding rebuilding directory inode 2013274673 bad hash table for directory inode 2029477400 (no data entry): rebuilding rebuilding directory inode 2029477400 bad hash table for directory inode 2037825112 (no data entry): rebuilding rebuilding directory inode 2037825112 fatal error -- malloc failed in longform_dir2_entry_check (2585598792 bytes) ================================================= Exists with an malloc failed, even though I am using the -m option which I think was created to avoid exactly this scenario. Run 3 Run 3 ============================================ ./xfs_repair -P -m 200 /dev/evms/monster_evms ... more output ... - agno = 38 - agno = 39 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 4842 (no data entry): rebuilding rebuilding directory inode 4842 bad hash table for directory inode 28776251 (no data entry): rebuilding rebuilding directory inode 28776251 fixing i8count in inode 29111010 corrupt block 0 in directory inode 321685982: junking block Segmentation fault ================================================= Exists with a Seg Fault. I found this one interesting especially since it happens at the exact same inode as Run 1 All comments appreciated. Simon From owner-xfs@oss.sgi.com Sat Jun 14 09:50:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:50:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EGoWLO023236 for ; Sat, 14 Jun 2008 09:50:32 -0700 X-ASG-Debug-ID: 1213462289-0c0401940000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB4CC17C19B6 for ; Sat, 14 Jun 2008 09:51:29 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id SVAOuMySlMwL7B98 for ; Sat, 14 Jun 2008 09:51:29 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 56FAAAC6275; Sat, 14 Jun 2008 11:51:28 -0500 (CDT) Message-ID: <4853F70F.6010400@sandeen.net> Date: Sat, 14 Jun 2008 11:51:27 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Paul Guermonprez CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair aborting ... dir2.c:2133 Subject: Re: xfs_repair aborting ... dir2.c:2133 References: <74d4a1e10806140124s3ed8dfa6x7e5ca656fea0e06e@mail.gmail.com> In-Reply-To: <74d4a1e10806140124s3ed8dfa6x7e5ca656fea0e06e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213462289 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53291 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16346 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Paul Guermonprez wrote: > hello, > > i have a xfs dump i want to repair under linux ubuntu. > the partition was created by a storage system ss4000-e. Do you mean that you did xfsrestore on a previous dump and then tried to repair the resulting filesystem? Maybe the dump was corrupt? > if i use version 2.9.4, i have a segfault > and version 2.9.8, the proces is aborted with message : > xfs_repair: dir2.c:2133: process_dir2: Assertion `(ino != > mp->m_sb.sb_rootino && ino != *parent) || (ino == mp->m_sb.sb_rootino > && (ino == *parent || need_root_dotdot == 1))' failed. > Aborted If you are willing to provide an xfs_metadump image, Barry would probably look into it for you :) Did anything interesting go wrong before your fs got so mangled? > i also tried to comment this test, but it returns a segfault just as > version 2.9.4. > > note : > i already restored 3 xfs dumps from the same machine, and everything > went in the lost+found, partly with no name, no directory, partly with > a directory structure and filenames as expected. xfsrestore did this? that's pretty weird. -Eric > before xfs_repair, the mounted fs was empty, not even the ".." for root ! > > thanks, paul. > > From owner-xfs@oss.sgi.com Sat Jun 14 09:52:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:52:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EGqYWM023732 for ; Sat, 14 Jun 2008 09:52:34 -0700 X-ASG-Debug-ID: 1213462411-150500120000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 26A95CBA819 for ; Sat, 14 Jun 2008 09:53:31 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id yB5lX6i93NLE0QbC for ; Sat, 14 Jun 2008 09:53:31 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id D5E68AC6275; Sat, 14 Jun 2008 11:53:30 -0500 (CDT) Message-ID: <4853F78A.1060605@sandeen.net> Date: Sat, 14 Jun 2008 11:53:30 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Dave Littell CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: GRIO for Linux...please! Subject: Re: GRIO for Linux...please! References: <4853CC74.8040206@verizon.net> In-Reply-To: <4853CC74.8040206@verizon.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213462412 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0015 1.0000 -2.0113 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53290 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16347 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Dave Littell wrote: > Hi all, > > Is there any plan (or even hope!) to have GRIO ported to Linux? XFS is > an excellent filesystem in any case, but GRIO would put it head and > shoulders above the competition. GRIOV1 was a highly irix-specific beast... GRIOV2 was quite different, and available on linux but AFAIK there were never any plans to make it GPL. Doesn't hurt to ask I suppose. :) You do have the realtime subvolume on linux, though, which was originally a component of GRIOV1. -Eric > > Thanks, > Dave > > From owner-xfs@oss.sgi.com Sat Jun 14 09:55:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:55:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EGteVj024378 for ; Sat, 14 Jun 2008 09:55:40 -0700 X-ASG-Debug-ID: 1213462596-0c0501f40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ug-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0C2D117C5E6D for ; Sat, 14 Jun 2008 09:56:36 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by cuda.sgi.com with ESMTP id 5Xz6W58sT8FI4ju1 for ; Sat, 14 Jun 2008 09:56:36 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id m3so221502uge.20 for ; Sat, 14 Jun 2008 09:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=VNDcFKTOewML7SXRRQsnt4pfQhcNNoJsFX+d89obg08=; b=Zlat2JgBhyQWgPk3mXk26La13GMU6ZL9zNd/DzqoQ1QLkJRcLnBNC1RSWH2KjyijAg SYqvndxd2QOqVdZhGDDBekJKKZ/iPo2PEADBgTNig68W9bWGbvpcx1bYmln5x+DZtnWR rVXhs6t81m379k5MY6IErfdNw914+jNYKizpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=qNSm04+Y+hcS2XfM8DR7BzkAEtKMgiHFMZlMNgQnpGMzC9UHyv0WKSbkEWjzqP4YCb cyawWenjft5Sl30KahBfWkC0fmCnFVsKbwv4O2fQXzo1O/UnF1HIQaU2YsLX6byF9uYx SghCZLFNZrK6gSh7/L0nNVkp2Mx0B0xoAfyqU= Received: by 10.67.26.7 with SMTP id d7mr3116034ugj.22.1213462595450; Sat, 14 Jun 2008 09:56:35 -0700 (PDT) Received: by 10.66.218.1 with HTTP; Sat, 14 Jun 2008 09:56:34 -0700 (PDT) Message-ID: Date: Sat, 14 Jun 2008 12:56:34 -0400 From: "Simon J" To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair trouble Subject: xfs_repair trouble MIME-Version: 1.0 X-Barracuda-Connect: ug-out-1314.google.com[66.249.92.169] X-Barracuda-Start-Time: 1213462597 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.95 X-Barracuda-Spam-Status: No, SCORE=0.95 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53291 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 3011 X-archive-position: 16348 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: simonjj@gmail.com Precedence: bulk X-list: xfs Hello all, I have a corrupted xfs filesystem on top of a RAID 5 (1TB in size). The RAID is still fully intact but the filesystem was damaged. When trying to repair the filesystem xfs_repair fails. I have tried various versions of xfs_repair, the latest stable (2.9.8) and the latest trunk (from CVS). I'd love to investigate and/or fix the issue further but I am a bit confused about some of my xfs_repair runs (both done with trunk). Could someone shed some light on where the problem could be, I'd be happy to continue digging if I would only know where roughly Run 1 ============================================ ./xfs_repair -P -m 170 /dev/evms/monster_evms ... more output ... bad hash table for directory inode 4842 (no data entry): rebuilding rebuilding directory inode 4842 entry ".." in directory inode 27930072 points to free inode 2013274702 bad hash table for directory inode 27930072 (no data entry): rebuilding rebuilding directory inode 27930072 bad hash table for directory inode 28776251 (no data entry): rebuilding rebuilding directory inode 28776251 fixing i8count in inode 29111010 xfs_repair: phase6.c:3411: shortform_dir2_entry_check: Assertion `bytes_deleted > 0' failed. Aborted ================================================= Exits with an Assert, it would be interesting to know why this Assert is there and what it means for bytes_deleted to be 0. Run 2 ============================================ ./xfs_repair -P -m 166 /dev/evms/monster_evms ... more output ... bad hash table for directory inode 2013274673 (no data entry): rebuilding rebuilding directory inode 2013274673 bad hash table for directory inode 2029477400 (no data entry): rebuilding rebuilding directory inode 2029477400 bad hash table for directory inode 2037825112 (no data entry): rebuilding rebuilding directory inode 2037825112 fatal error -- malloc failed in longform_dir2_entry_check (2585598792 bytes) ================================================= Exists with an malloc failed, even though I am using the -m option which I think was created to avoid exactly this scenario. Run 3 Run 3 ============================================ ./xfs_repair -P -m 200 /dev/evms/monster_evms ... more output ... - agno = 38 - agno = 39 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 4842 (no data entry): rebuilding rebuilding directory inode 4842 bad hash table for directory inode 28776251 (no data entry): rebuilding rebuilding directory inode 28776251 fixing i8count in inode 29111010 corrupt block 0 in directory inode 321685982: junking block Segmentation fault ================================================= Exists with a Seg Fault. I found this one interesting especially since it happens at the exact same inode as Run 1 All comments appreciated. Simon [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Jun 14 10:54:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 10:54:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EHsNJf028363 for ; Sat, 14 Jun 2008 10:54:23 -0700 X-ASG-Debug-ID: 1213466118-2303037e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 46FD3230DE7 for ; Sat, 14 Jun 2008 10:55:19 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 9J6uMDAvZEstudwR for ; Sat, 14 Jun 2008 10:55:19 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5EHtANW021192 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 14 Jun 2008 19:55:10 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5EHtArm021190 for xfs@oss.sgi.com; Sat, 14 Jun 2008 19:55:10 +0200 Date: Sat, 14 Jun 2008 19:55:10 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH, RFC] fix XFSQA 145 / test_hole Subject: [PATCH, RFC] fix XFSQA 145 / test_hole Message-ID: <20080614175510.GA21014@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213466120 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_MJ615 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53295 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_MJ615 Custom Rule MJ615 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16349 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs There are two errors I see all the time in 145: - dm_probe_hole returns EINVAL for offsets close to the file size - dm_probe_hole wants EAGAIN for a probe at offset 1, length 0 The first error is a consequence of how the hole puching / probing works. It always rounds the requested offset up to the next block size and then checks if that rounded offset still fits into the file size. Just do the same rounding in the testcase to make sure we don't probe invalid offsets. The second error is very odd to me, as we never return AGAIN in the whole dm_probe_hole path. I've just commented it out. I've also re-enabled the E2BIG to past-EOF test that was uncommented before because it works perfectly fine now. Signed-off-by: Christoph Hellwig --- xfstests/145.out 19 Dec 2006 02:55:36 -0000 1.1 +++ xfstests/145.out 14 Jun 2008 17:49:49 -0000 @@ -16,13 +16,13 @@ Hole test beginning... Verified hole at 4096 (beginning errno subtests...) report on test for E2BIG in probe (from past EOF): test successful + report on test for E2BIG in probe (to past EOF): test successful report on test for EACCES in no-right probe: test successful report on test for success in SHARED probe: test successful. report on test for success in EXCL probe: test successful. report on test for EACCES in no-right punch: test successful report on test for EACCES in SHARED punch: test successful report on test for success in EXCL punch: test successful. - report on test for EAGAIN in punch: test successful report on test for EBADF in probe: test successful report on test for EBADF in punch: test successful report on test for EFAULT in probe (null handle): test successful --- xfstests/dmapi/src/suite2/src/test_hole.c 9 Nov 2005 02:50:19 -0000 1.8 +++ xfstests/dmapi/src/suite2/src/test_hole.c 14 Jun 2008 17:49:49 -0000 @@ -69,7 +69,7 @@ main( dm_sessid_t sid = DM_NO_SESSION; char *pathname = NULL; char *ls_path = NULL; - dm_off_t offset = 0; + dm_off_t offset = 0, end; dm_off_t ex_off = 0; dm_extent_t extent[20]; u_int nelem; @@ -162,10 +162,16 @@ main( exit(1); } + /* + * The kernel always rounds the offset up to the next block + * size, so we can only probes up to the previous to last block. + */ + end = (29604 / blocksize) * blocksize; + /* Check that dm_probe_hole returns an extent from the next * highest multiple of the block size, to the end of the file */ - for (offset = 0; offset < 29604; offset++) { + for (offset = 0; offset < end; offset++) { if (dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, offset, length, &roff, &rlen)) { fprintf(stdout, "dm_probe_hole failed on pass %lld (%s)\n", @@ -275,15 +281,10 @@ main( dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, 30000, length, &roff, &rlen)) /*---------------------------------------------------------*/ -#if 0 - PROBLEM: No error is produced. - off+len >= filesize should produce E2BIG... - ERRTEST(E2BIG, "probe (to past EOF)", dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, 15000, 150000, &roff, &rlen)) -#endif /*---------------------------------------------------------*/ SHAREDTEST("probe", hanp, hlen, test_token, dm_probe_hole(sid, hanp, hlen, test_token, @@ -292,10 +293,18 @@ main( EXCLTEST("punch", hanp, hlen, test_token, dm_punch_hole(sid, hanp, hlen, test_token, 0, 0)) /*---------------------------------------------------------*/ + /* + * No idea where that EAGAIN should come from, it's never + * returned from the kernel. + * + * -- hch + */ +#if 0 ERRTEST(EAGAIN, "punch", dm_punch_hole(sid, hanp, hlen, DM_NO_TOKEN, 1, length)) +#endif /*---------------------------------------------------------*/ if ((test_vp = handle_clone(hanp, hlen)) == NULL) { fprintf(stderr, From owner-xfs@oss.sgi.com Sat Jun 14 12:22:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 12:22:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EJM1hh005274 for ; Sat, 14 Jun 2008 12:22:01 -0700 X-ASG-Debug-ID: 1213471377-628d029c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6AD8E231D27 for ; Sat, 14 Jun 2008 12:22:57 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 5YsUq2Tuwm6pR1lI for ; Sat, 14 Jun 2008 12:22:57 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5EJMmNW025306 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 14 Jun 2008 21:22:49 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5EJMmrf025304 for xfs@oss.sgi.com; Sat, 14 Jun 2008 21:22:48 +0200 Date: Sat, 14 Jun 2008 21:22:48 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] fix XFSQA 144 Subject: [PATCH] fix XFSQA 144 Message-ID: <20080614192248.GA24329@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213471378 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0405 1.0000 -1.7598 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.76 X-Barracuda-Spam-Status: No, SCORE=-1.76 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53300 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16350 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Two really dumb bugs: - "foo & 0x3FFFFFFFFFFFF" doesn't cap at 1TB, but rather at more than two magnitudes larger than that. That gets us EFBIG with typical 32bit XFS setups. - the command array can easily overflow and thus let the test fail Signed-off-by: Christoph Hellwig Index: xfstests/dmapi/src/suite2/src/test_fileattr.c =================================================================== RCS file: /cvs/xfs-cmds/xfstests/dmapi/src/suite2/src/test_fileattr.c,v retrieving revision 1.12 diff -u -p -r1.12 test_fileattr.c --- xfstests/dmapi/src/suite2/src/test_fileattr.c 21 Sep 2007 04:15:06 -0000 1.12 +++ xfstests/dmapi/src/suite2/src/test_fileattr.c 14 Jun 2008 19:12:43 -0000 @@ -160,7 +160,7 @@ main( char *ls_path; char *pathname; char test_file[100]; - char command[100]; + char command[200]; int num_files=50; dm_stat_t *stat_arr; dm_stat_t dmstat; @@ -244,7 +244,7 @@ main( stat_arr[i].dt_uid=(uid_t)(rand()+rand()*0x10000); stat_arr[i].dt_gid=(gid_t)(rand()+rand()*0x10000); stat_arr[i].dt_mode=(mode_t)((rand()%4096)+32768); - stat_arr[i].dt_size=((dm_off_t)(rand()+rand()*0x10000)) & 0x3FFFFFFFFFFFF; /* 1 TB max */ + stat_arr[i].dt_size=((dm_off_t)(rand()+rand()*0x10000)) & 0x1FFFFFFFFFFULL; /* 1 TB max */ } /*-----------------------------------------------------*\ From owner-xfs@oss.sgi.com Sat Jun 14 12:40:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 12:40:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EJeKij006588 for ; Sat, 14 Jun 2008 12:40:20 -0700 X-ASG-Debug-ID: 1213472475-731402400000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CDB4417C6036 for ; Sat, 14 Jun 2008 12:41:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by cuda.sgi.com with ESMTP id 13ujCbF8xvgPbolB for ; Sat, 14 Jun 2008 12:41:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3169346fgb.8 for ; Sat, 14 Jun 2008 12:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=99LTjddslmi6iJqeZ7Ue89eIwkCR5SN2U+6qynDgKSs=; b=dYY2JREtcIl+n7ZupdQQn62jFjCIgBhmsHV/O2Txv8l3DBstgGnBaEqP8kipf9pZeb QthXRQIZLqqRJu/A5sFVo8msdiWJT/NHjVi/V15THc98TBYYs3d377LcWRIP54MEnIgB ungNFy4JNnT07o3ot+Sz6gPN7izX7DYk963YM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=nLCpnVJm1mpCNDdYlbj8h790xO/1aQA7AibVwCOBxyoM61arOJeMhmVY2YmUlE1cSQ tjhGJlN+vd59rDV4Iv01uEKzJuvP/fy1VCzFT9eifUYQRa3Ff2CuPSvQY2OM51jQbpm0 5g1qwrptsDDNnY5EF4AFPZ7HEPolQxCKJeBC8= Received: by 10.86.26.11 with SMTP id 11mr6238077fgz.23.1213472472996; Sat, 14 Jun 2008 12:41:12 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sat, 14 Jun 2008 12:41:12 -0700 (PDT) Message-ID: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> Date: Sat, 14 Jun 2008 21:41:12 +0200 From: "Oliver Pinter" To: "Chris Wright" , "Christoph Hellwig" , stable@kernel.org, xfs@oss.sgi.com, xfs-masters@oss.sgi.com X-ASG-Orig-Subj: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: "Miquel van Smoorenburg" , "Konstantin Kletschke" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.157] X-Barracuda-Start-Time: 1213472476 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0570 1.0000 -1.6558 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.66 X-Barracuda-Spam-Status: No, SCORE=-1.66 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53301 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16351 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg tainted with: nvidia and madwifi kernel: 2.6.25.6 + queue patches (queue head on aa8edcb997ff605bd1424630356866b78ef06cdc) -- Thanks, Oliver From owner-xfs@oss.sgi.com Sat Jun 14 18:52:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 18:52:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5F1qDbQ004043 for ; Sat, 14 Jun 2008 18:52:13 -0700 X-ASG-Debug-ID: 1213494789-0f6b036f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8A1AF23287C; Sat, 14 Jun 2008 18:53:09 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id V1S8rEViMW5fxyp8; Sat, 14 Jun 2008 18:53:09 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 92B15AC6275; Sat, 14 Jun 2008 20:53:08 -0500 (CDT) Message-ID: <48547604.9060700@sandeen.net> Date: Sat, 14 Jun 2008 20:53:08 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: Chris Wright , Christoph Hellwig , stable@kernel.org, xfs@oss.sgi.com, xfs-masters@oss.sgi.com, Miquel van Smoorenburg , Konstantin Kletschke X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> In-Reply-To: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213494790 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53327 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16352 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg > > tainted with: nvidia and madwifi > kernel: 2.6.25.6 + queue patches (queue head on > aa8edcb997ff605bd1424630356866b78ef06cdc) > What sort of remount were you doing? -Eric From owner-xfs@oss.sgi.com Sun Jun 15 05:37:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 05:37:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FCbcY0028359 for ; Sun, 15 Jun 2008 05:37:39 -0700 X-ASG-Debug-ID: 1213533514-2f5b012d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 06460233643 for ; Sun, 15 Jun 2008 05:38:35 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by cuda.sgi.com with ESMTP id c8D3JaqCihCRm8PH for ; Sun, 15 Jun 2008 05:38:35 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3236610fgb.8 for ; Sun, 15 Jun 2008 05:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ANZCvqDyR3wj4ODXTP2FkJsqjt4TEpYtUTp7IJ6dU5M=; b=gBUHgb47uO8IWbKJJVbvboxoRPoHbexyPzNgVh1TKOiCnBOWoNaxfO5DhU2SVWVq+G pZ82pOApy0/D0N64x9bI46nhgPQOPb1+/V3Q4Eyjkgmoe4vXy1fcZPQLau5MmxZ9cFa0 RH5Plo2i0a4Z4tjg2Up8gQR+x5jGyuPmjHxpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=arml7M4rZDhYH3TxLZSiHq349l90Pzdj5LJKyZ5I1jgW9mmT71gFmAlliYc9xqbAeL NURKEu7WkIl6nH280k8UnQdSl2QBMzf5wT19SKghZ6WT3ZGZRrHik2JTXVb7IiPlSvHP uA6kS2V5Cvm1rAWivI5T1S1k/9fhq2B92hKpU= Received: by 10.86.27.9 with SMTP id a9mr6888083fga.57.1213533513023; Sun, 15 Jun 2008 05:38:33 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 05:38:33 -0700 (PDT) Message-ID: <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> Date: Sun, 15 Jun 2008 14:38:33 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: "Chris Wright" , "Christoph Hellwig" , stable@kernel.org, xfs@oss.sgi.com, xfs-masters@oss.sgi.com, "Miquel van Smoorenburg" , "Konstantin Kletschke" In-Reply-To: <48547604.9060700@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.158] X-Barracuda-Start-Time: 1213533516 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0208 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53368 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16353 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs this mistake shutdownkor comes out, remount launched because he panics, only Alt+Sysrq+foo works On 6/15/08, Eric Sandeen wrote: > Oliver Pinter wrote: >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg >> >> tainted with: nvidia and madwifi >> kernel: 2.6.25.6 + queue patches (queue head on >> aa8edcb997ff605bd1424630356866b78ef06cdc) >> > > What sort of remount were you doing? > > -Eric > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 08:57:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 08:57:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FFvEQ6011045 for ; Sun, 15 Jun 2008 08:57:14 -0700 X-ASG-Debug-ID: 1213545490-2a5302900000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 84A2417C7BF8 for ; Sun, 15 Jun 2008 08:58:10 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id QRvA93vk4GbV2p3H for ; Sun, 15 Jun 2008 08:58:10 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id AC12AAC626E; Sun, 15 Jun 2008 10:58:09 -0500 (CDT) Message-ID: <48553C11.2060606@sandeen.net> Date: Sun, 15 Jun 2008 10:58:09 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> In-Reply-To: <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213545491 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0006 1.0000 -2.0173 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16354 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > this mistake shutdownkor comes out, remount launched because he > panics, only Alt+Sysrq+foo works I'm not sure I follow. Assuming that : http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg is the first event of interest, it is hitting an assertion on the remount path: ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); in xfs_attr_quiesce. Are you saying something else happen before this? If so, what? -Eric > On 6/15/08, Eric Sandeen wrote: >> Oliver Pinter wrote: >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg >>> >>> tainted with: nvidia and madwifi >>> kernel: 2.6.25.6 + queue patches (queue head on >>> aa8edcb997ff605bd1424630356866b78ef06cdc) >>> >> What sort of remount were you doing? >> >> -Eric >> > > From owner-xfs@oss.sgi.com Sun Jun 15 09:08:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:08:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_72 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FG8Ghs011814 for ; Sun, 15 Jun 2008 09:08:16 -0700 X-ASG-Debug-ID: 1213546152-4b8f02d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 86027CBD058 for ; Sun, 15 Jun 2008 09:09:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by cuda.sgi.com with ESMTP id 04WICle1BBDffa8P for ; Sun, 15 Jun 2008 09:09:12 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3255420fgb.8 for ; Sun, 15 Jun 2008 09:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=O61G5oAAITA8C/GYW1KBnNl7t7SI4RhrzZkiasB7GKc=; b=VzWyqlVWyAj0f5hhPgKoJ0B+xNkXN37I7CeyIhS/HMMOgKZzcTnKw1MFByaeZg0nb8 Gk8Zr7/DZdApnKOzFkNanhk8GZyNPJvWezaQoWW8nxzKKgJ+MzChXRSa9fnWPei4GKd/ cjOz7KxnB/Z3lLqgIL7/rjfJ2ni28KFOLLlRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BZxoRb+lsPOSsHPqXwfdrE8TtvTZTDLSlT3gXxiFtAqQ671Q7OxWQ4J4gseSwcc4Cg TdqAktx96fgPb8Wcf5vJRGV81S2YOkZELdS7z4eG68tW45qzFZMEiI2h/v9bWQJyPyP9 qI3XBX/SAlfoUlsooXwWh7FHEL8SLkcRT1eos= Received: by 10.86.80.5 with SMTP id d5mr7048273fgb.26.1213546151843; Sun, 15 Jun 2008 09:09:11 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 09:09:11 -0700 (PDT) Message-ID: <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> Date: Sun, 15 Jun 2008 18:09:11 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: xfs@oss.sgi.com In-Reply-To: <48553C11.2060606@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.159] X-Barracuda-Start-Time: 1213546153 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4594 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16355 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs this is the debian way of the unmounting the root fs: do_stop () { [ "$VERBOSE" = no ] || log_action_begin_msg "Mounting root filesystem re ad-only" MOUNT_FORCE_OPT= [ "$(uname -s)" = "GNU/kFreeBSD" ] && MOUNT_FORCE_OPT=-f # This: # mount -n -o remount,ro / # will act on a bind mount of / if there is one. # See #339023 and the comment in checkroot.sh mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2>/de v/null \ || mount $MOUNT_FORCE_OPT -n -o remount,ro dummydev / 2>/de v/null \ || mount $MOUNT_FORCE_OPT -n -o remount,ro / ES=$? [ "$VERBOSE" = no ] || log_action_end_msg $ES } On 6/15/08, Eric Sandeen wrote: > Oliver Pinter wrote: >> this mistake shutdownkor comes out, remount launched because he >> panics, only Alt+Sysrq+foo works > > I'm not sure I follow. > > Assuming that : > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg > > is the first event of interest, it is hitting an assertion on the > remount path: > > ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); > > in xfs_attr_quiesce. > > Are you saying something else happen before this? If so, what? > > -Eric > >> On 6/15/08, Eric Sandeen wrote: >>> Oliver Pinter wrote: >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg >>>> >>>> tainted with: nvidia and madwifi >>>> kernel: 2.6.25.6 + queue patches (queue head on >>>> aa8edcb997ff605bd1424630356866b78ef06cdc) >>>> >>> What sort of remount were you doing? >>> >>> -Eric >>> >> >> > > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 09:11:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:11:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FGB64s012247 for ; Sun, 15 Jun 2008 09:11:06 -0700 X-ASG-Debug-ID: 1213546323-4b8e032e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1DA97CBE74B for ; Sun, 15 Jun 2008 09:12:03 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id wcl71DCUzuT0Gk8u for ; Sun, 15 Jun 2008 09:12:03 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 31D6BAC626E; Sun, 15 Jun 2008 11:12:03 -0500 (CDT) Message-ID: <48553F53.7000208@sandeen.net> Date: Sun, 15 Jun 2008 11:12:03 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> In-Reply-To: <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213546324 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0008 1.0000 -2.0158 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16356 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > this is the debian way of the unmounting the root fs: Ok we're slowly getting to useful information. So you were shutting down the system when the panic happened, correct? -Eric From owner-xfs@oss.sgi.com Sun Jun 15 09:13:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:13:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FGDNcC012643 for ; Sun, 15 Jun 2008 09:13:23 -0700 X-ASG-Debug-ID: 1213546459-4b8f03130000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC21ACBE775 for ; Sun, 15 Jun 2008 09:14:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by cuda.sgi.com with ESMTP id E83VlKtwfJDacqVt for ; Sun, 15 Jun 2008 09:14:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3255922fgb.8 for ; Sun, 15 Jun 2008 09:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0y3Z7nhgv9hyc0hv5IrNBL1xtV8TjLUoI2uyRc4Quuo=; b=SCaWtQlpDmxrtKZqUvsZBkikjrAjX2owJ4J8Db1ceMyANS0Nszgb5LVSRXQHXSusFA 2tVrly+ZtO3CiEjFAKJr+vjLR6lfSRvV2vlflpW6aIr+9nLY/vVFMOPcuHaL3X1u6udv 79lhAywJ7T/pZhwUihtcXbJgSuuXUF+2d//Lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=VLCZcaGA1DcS1twgTrGsSQENmGRpe+777VWfLBkP/OSu40M4zYEPyCZ+2ZMhOZzBaK 1smzp3mdUwsTV/cu6UN9Y6GBRic1am2dSWss14kTuUchdAXV5yjjhFz4ihK+7LY0vy/t mjsCFvccMV9GPYKjO9R9JcX6iPcUgcxgXWaRo= Received: by 10.86.80.17 with SMTP id d17mr7036271fgb.33.1213546458347; Sun, 15 Jun 2008 09:14:18 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 09:14:18 -0700 (PDT) Message-ID: <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> Date: Sun, 15 Jun 2008 18:14:18 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: xfs@oss.sgi.com In-Reply-To: <48553F53.7000208@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> <48553F53.7000208@sandeen.net> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.153] X-Barracuda-Start-Time: 1213546460 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4261 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16357 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs sorry, but I did not learn English, is going a little bit slowly in this manner. yeah, under poweroff (init 0) panics the system On 6/15/08, Eric Sandeen wrote: > Oliver Pinter wrote: >> this is the debian way of the unmounting the root fs: > > Ok we're slowly getting to useful information. > > So you were shutting down the system when the panic happened, correct? > > -Eric > > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 09:16:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:16:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FGG4vJ013290 for ; Sun, 15 Jun 2008 09:16:04 -0700 X-ASG-Debug-ID: 1213546621-5b4600a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ECFBF17C78F2 for ; Sun, 15 Jun 2008 09:17:01 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by cuda.sgi.com with ESMTP id ZAWD2GEgLkbW95tB for ; Sun, 15 Jun 2008 09:17:01 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3256188fgb.8 for ; Sun, 15 Jun 2008 09:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=t9hLDeMD/kNAqPcGg/Z25iUzA7LJIlk+CIZEittPQps=; b=rtvLQgmSzgOrRySt8xrmZeXwAq/mUAyq90D0n2bmD+lR/bHVE9mxWyEyL97cQFGz2v qrXNRPUv102m5vMCe4QIlZ8jIVUPNuQNTPufKrd9QUEXy9wsOoz+vT70Jzd7nqMRTHEn 9QK08p3sUOtl6CxI85GScnq29mNd/MOc7kuQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=OUpQUIrph5PhnFwEPZ4BdQa8UnB35L5TJL+uZ7nNQVX5qJiuE/bJzz9ZkSPm0d8Eic ej7TueprMk4gp1Ysc3W/SNV5CNoi5y6JFiCqt/hBQvINyeWu+EY6wULoG5W7fjJYpzx5 1iDLk1UuOO7+eyu8dzpR15pnKPRaFYe9G8uAA= Received: by 10.86.82.16 with SMTP id f16mr7076733fgb.9.1213546620801; Sun, 15 Jun 2008 09:17:00 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 09:17:00 -0700 (PDT) Message-ID: <6101e8c40806150917w5d17e31wd8b55e1d38da2411@mail.gmail.com> Date: Sun, 15 Jun 2008 18:17:00 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: xfs@oss.sgi.com In-Reply-To: <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> <48553F53.7000208@sandeen.net> <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.159] X-Barracuda-Start-Time: 1213546621 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1336 1.0000 -1.1949 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.19 X-Barracuda-Spam-Status: No, SCORE=-1.19 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16358 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs hmm, the system have two XFS partition the / (sda4) and /home (sda3) /dev/sda3 on /home type xfs (rw,noexec,nosuid,nodev) /dev/sda4 on / type xfs (rw) On 6/15/08, Oliver Pinter wrote: > sorry, but I did not learn English, is going a little bit slowly in this > manner. > > yeah, under poweroff (init 0) panics the system > > On 6/15/08, Eric Sandeen wrote: >> Oliver Pinter wrote: >>> this is the debian way of the unmounting the root fs: >> >> Ok we're slowly getting to useful information. >> >> So you were shutting down the system when the panic happened, correct? >> >> -Eric >> >> > > > -- > Thanks, > Oliver > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 09:26:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:26:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FGQfxf014041 for ; Sun, 15 Jun 2008 09:26:41 -0700 X-ASG-Debug-ID: 1213547257-7bef02070000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 69C98233D4A for ; Sun, 15 Jun 2008 09:27:38 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by cuda.sgi.com with ESMTP id M4tk6hjm9Y5BJp0D for ; Sun, 15 Jun 2008 09:27:38 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3257200fgb.8 for ; Sun, 15 Jun 2008 09:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=TERbNxAU+lrjyyW7PS4fn+wvHz4z2EJThby7hsLE2MU=; b=C91lzB9ROXbKw9txEdJpuB6k5Vby565kKPFdyrandhRe0je9QH8h/EZS/1+1GiJ/Ay U8kq7UdpdFFX/XVa+2/ZPJ7s6NvmschA2/OO+r6JOoz7MNpkhjQp8qD6OFUo4OEeCdng IfvbnEFPFxvQPrp17du8ji8cX+9BhqjiFP/Uc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=putUqgfcVh0fxIFGq37oWYyf/DfHxOH8+K4MpBv6vKe4xbPQjnv2bgEZ7Nh6sJGsHf J9ELvDzUAvF0rbQzqxFpjseRQ2BT7iQMQYKO73qD1vqpSgO6fVOG9vcg23JDFxgqhuEm I0Rgd4un7L5WJ4EsVjbc5mnbjryEqWk6t91j4= Received: by 10.86.31.19 with SMTP id e19mr6428856fge.42.1213547256602; Sun, 15 Jun 2008 09:27:36 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 09:27:36 -0700 (PDT) Message-ID: <6101e8c40806150927g7ec36ad7w92ad0c2eebd85437@mail.gmail.com> Date: Sun, 15 Jun 2008 18:27:36 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: xfs@oss.sgi.com In-Reply-To: <6101e8c40806150917w5d17e31wd8b55e1d38da2411@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> <48553F53.7000208@sandeen.net> <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> <6101e8c40806150917w5d17e31wd8b55e1d38da2411@mail.gmail.com> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.153] X-Barracuda-Start-Time: 1213547259 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3281 1.0000 -0.2338 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.23 X-Barracuda-Spam-Status: No, SCORE=-0.23 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16359 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs but now it was him that you say the antecedents apt-get update & upgrade and git-update-tree (is is a script, that updated 3 git tree (linux-2.6, linux-2.6.25.y and stable-queue)) , that is heavy disc i/o with much small files On 6/15/08, Oliver Pinter wrote: > hmm, the system have two XFS partition the / (sda4) and /home (sda3) > > /dev/sda3 on /home type xfs (rw,noexec,nosuid,nodev) > /dev/sda4 on / type xfs (rw) > > On 6/15/08, Oliver Pinter wrote: >> sorry, but I did not learn English, is going a little bit slowly in this >> manner. >> >> yeah, under poweroff (init 0) panics the system >> >> On 6/15/08, Eric Sandeen wrote: >>> Oliver Pinter wrote: >>>> this is the debian way of the unmounting the root fs: >>> >>> Ok we're slowly getting to useful information. >>> >>> So you were shutting down the system when the panic happened, correct? >>> >>> -Eric >>> >>> >> >> >> -- >> Thanks, >> Oliver >> > > > -- > Thanks, > Oliver > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 11:59:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 11:59:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FIxmFo023561 for ; Sun, 15 Jun 2008 11:59:48 -0700 X-ASG-Debug-ID: 1213556444-7605014c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fk-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A1E031BA1D98 for ; Sun, 15 Jun 2008 12:00:44 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by cuda.sgi.com with ESMTP id TrBxlp7oyZCTl4H0 for ; Sun, 15 Jun 2008 12:00:44 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 26so3471289fkx.4 for ; Sun, 15 Jun 2008 12:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=FoYlgcZh9oHfTPcg37yVSIelaz7Q7sbPvWmLfz70iwc=; b=xX9ISO4J3qRCjUCng8UplTvItSbAYMoUtNySJifb/B7DU4iWB4/vfyXL1HqRc5nO3B Jzfa/e+Ww3UnfcHa/4rzswtbCM+Pc3M/F9SSa9TaEsHxmVSKtkmv/blXXUNc/Bk/Z7sz /hFqzgO2+yDNcIyeVhDxMHgD6gnLfzoimi9Ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Aoyk9aLw7PR9nOrDxOhXdbijofSm8JrZU9ImXPzlSfOeQZ5HSzEmtsOSIpWpiXTMfh ta/cpvLX+Vd2DfdBAK5jKHC0i8RWlWyIwPz4wClAAErVYJH/FNT7pClp/7dYf/4PjPw/ QqSnLjZpf1sEGfvypBDBOak7F20xGFrog/ai4= Received: by 10.78.144.11 with SMTP id r11mr2271785hud.49.1213556443707; Sun, 15 Jun 2008 12:00:43 -0700 (PDT) Received: by 10.78.142.16 with HTTP; Sun, 15 Jun 2008 12:00:43 -0700 (PDT) Message-ID: <74d4a1e10806151200u4f00f0c5xa18e36ab5925ca77@mail.gmail.com> Date: Sun, 15 Jun 2008 21:00:43 +0200 From: "Paul Guermonprez" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: xfs_repair aborting ... dir2.c:2133 Subject: Re: xfs_repair aborting ... dir2.c:2133 Cc: xfs@oss.sgi.com In-Reply-To: <4853F70F.6010400@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <74d4a1e10806140124s3ed8dfa6x7e5ca656fea0e06e@mail.gmail.com> <4853F70F.6010400@sandeen.net> X-Google-Sender-Auth: 3a608eeb448819aa X-Barracuda-Connect: fk-out-0910.google.com[209.85.128.185] X-Barracuda-Start-Time: 1213556445 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4024 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53395 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16360 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@guermonprez.eu Precedence: bulk X-list: xfs hello, > Do you mean that you did xfsrestore on a previous dump and then tried to > repair the resulting filesystem? Maybe the dump was corrupt? i used dd to copy the xfs part of the original raid disk to my new disk. in this ss4000e box, xfs partitions are contained in a big partition "IPSTOR" (built on a raid linear) with a XML descriptor of start/end/... for logical partitions inside. so using regular tools was not a option as regular partitions are not seen. the dd step seems to work fine, but of course i could always try several times and see if the output is the same. the output seems like a regular xfs partition, xfs_repair then mounted as a loop and got what i was able to get from lost+found. > If you are willing to provide an xfs_metadump image, Barry would > probably look into it for you :) xfs_metadup has been running for more than 6 hours now (xfs_db at 100% on a recent desktop CPU) and still running. and all i have is a 230kb file, so i posted it here : http://dl.free.fr/nHuj52ETY/xfs_metadump.bz2 in theory the important part of the disk contains about 50 folders, with 50 tif files of 30Mo in each, plus other stuff. tried the lastest version, now using 400%, nice but same result. > Did anything interesting go wrong before your fs got so mangled? as i was using this box, i wasn't in contact with the filesystem, all i can say is that the raid is OK and the disk seem OK too. ( i know it's stupid to use such a box where everything is hidden won't do it again ! ) the last thing was probably a crach of the system, and impossibility to reboot the embedded OS of the thing with the drives in. > xfsrestore did this? that's pretty weird. xfs_repair did this. i used dd to copy the data but again i can't be totally sure of what kind of strange XFS version IPSTOR is using, perhaps it is not even standard ??? tried to contact them with no luck. in fact i am trying to exploit my miserable situation to write a rescue guide for this box, but this last xfs problem is blocking me, so thanks a lot for your help. thanks, paul. From owner-xfs@oss.sgi.com Sun Jun 15 18:10:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 18:10:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G1AiDd022583 for ; Sun, 15 Jun 2008 18:10:45 -0700 X-ASG-Debug-ID: 1213578700-532002fc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 246A81B33405 for ; Sun, 15 Jun 2008 18:11:40 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id erH60O8DUdzKk7Fb for ; Sun, 15 Jun 2008 18:11:40 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 1F51CAC626E; Sun, 15 Jun 2008 20:11:40 -0500 (CDT) Message-ID: <4855BDCB.3030103@sandeen.net> Date: Sun, 15 Jun 2008 20:11:39 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> <48553F53.7000208@sandeen.net> <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> In-Reply-To: <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213578702 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0113 1.0000 -1.9474 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.95 X-Barracuda-Spam-Status: No, SCORE=-1.95 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53419 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16361 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > sorry, but I did not learn English, is going a little bit slowly in this manner. That's, ok, it's just useful to know what you were doing when it panicked. I'm sure you speak english better than I speak you native language ;) > yeah, under poweroff (init 0) panics the system Hm, interesting. > but now it was him that you say the antecedents apt-get update & > upgrade and git-update-tree (is is a script, that updated 3 git tree > (linux-2.6, linux-2.6.25.y and stable-queue)) , that is heavy disc i/o > with much small files So, you had a lot of IO just before shutdown? -Eric > On 6/15/08, Eric Sandeen wrote: >> Oliver Pinter wrote: >>> this is the debian way of the unmounting the root fs: >> Ok we're slowly getting to useful information. >> >> So you were shutting down the system when the panic happened, correct? >> >> -Eric >> >> > > From owner-xfs@oss.sgi.com Sun Jun 15 19:04:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 19:04:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5G2431g026509 for ; Sun, 15 Jun 2008 19:04:05 -0700 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 MAA10436; Mon, 16 Jun 2008 12:04:50 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 0068258C4C3F; Mon, 16 Jun 2008 12:04:49 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 983102 - XFS case-insensitive: Assertion Failed: xfs_dir2_sf_lookup(args) == ENOENT Message-Id: <20080616020450.0068258C4C3F@chook.melbourne.sgi.com> Date: Mon, 16 Jun 2008 12:04:49 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16362 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs The vfs_unlink/d_delete functionality in the Linux VFS make the dentry negative if it is the only inode being referenced. Case-insensitive mode doesn't work with negative dentries, so if using CI-mode, invalidate the dentry on unlink/rmdir. Date: Mon Jun 16 12:04:04 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/2.6.x-xfs Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31308a fs/xfs/linux-2.6/xfs_iops.c - 1.289 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.289&r2=text&tr2=1.288&f=h - Invalidate dentry in unlink/rmdir if in CI mode From owner-xfs@oss.sgi.com Sun Jun 15 19:17:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 19:17:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5G2HH02027669 for ; Sun, 15 Jun 2008 19:17:19 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10702; Mon, 16 Jun 2008 12:18:07 +1000 Message-ID: <4855CE2D.70505@sgi.com> Date: Mon, 16 Jun 2008 12:21:33 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] Always reset btree cursor after an insert Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16363 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs After a btree insert operation a cursor can be invalid due to block splits and a maybe a new root block. We reset the cursor in xfs_bmbt_insert() in the cases where we think we need to but it isn't enough as we still see assertions. Just do what we do elsewhere and reset the cursor unconditionally. Lachlan --- fs/xfs/xfs_bmap.c_1.392 2008-06-03 12:20:14.000000000 +1000 +++ fs/xfs/xfs_bmap.c 2008-06-16 12:11:47.000000000 +1000 @@ -1745,11 +1745,17 @@ xfs_bmap_add_extent_unwritten_real( if ((error = xfs_bmbt_insert(cur, &i))) goto done; ASSERT(i == 1); - if ((error = xfs_bmbt_increment(cur, 0, &i))) + /* + * Reset the cursor, don't trust it after any insert + * operation. + */ + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, + new->br_startblock, new->br_blockcount, + &i))) goto done; - ASSERT(i == 1); + ASSERT(i == 0); /* new middle extent - newext */ - cur->bc_rec.b = *new; + cur->bc_rec.b.br_state = new->br_state; if ((error = xfs_bmbt_insert(cur, &i))) goto done; ASSERT(i == 1); From owner-xfs@oss.sgi.com Sun Jun 15 20:14:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 20:14:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5G3EaYY030761 for ; Sun, 15 Jun 2008 20:14:38 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11555; Mon, 16 Jun 2008 13:15:20 +1000 Message-ID: <4855DB96.9030208@sgi.com> Date: Mon, 16 Jun 2008 13:18:46 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs-dev , xfs-oss Subject: Re: [PATCH] fix extent corruption in xfs_iext_irec_compact_full() References: <48522031.5060700@sgi.com> <20080613132304.GA28190@infradead.org> In-Reply-To: <20080613132304.GA28190@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16364 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 13, 2008 at 05:22:25PM +1000, Lachlan McIlroy wrote: >> This function is used to compact the indirect extent list by moving >> extents from one page to the previous to fill them up. After we >> move some extents to an earlier page we need to shuffle the remaining >> extents to the start of the page. The actual bug here is the second >> argument to memmove() needs to index past the extents, that were copied >> to the previous page, and move the remaining extents. For pages that >> are already full (ie ext_avail == 0) the compaction code has no net >> effect so don't do it. >> >> Thanks to Dave Chinner for pointing out the bug. > > > Looks good but this function needs a lot more comments. Below is a > version of the patch with some more comments describing what's going > on that I came up with when trying to understand what this patch does > in detail: Thanks Christoph. > > > Index: linux-2.6-xfs/fs/xfs/xfs_inode.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2008-06-13 14:58:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2008-06-13 15:15:25.000000000 +0200 > @@ -4532,39 +4532,63 @@ xfs_iext_irec_compact_full( > int nlists; /* number of irec's (ex lists) */ > > ASSERT(ifp->if_flags & XFS_IFEXTIREC); > + > nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; > erp = ifp->if_u1.if_ext_irec; > ep = &erp->er_extbuf[erp->er_extcount]; > erp_next = erp + 1; > ep_next = erp_next->er_extbuf; > + > while (erp_idx < nlists - 1) { > + /* > + * Check how many extent records are available in this irec. > + * If there is none skip the whole exercise. > + */ > ext_avail = XFS_LINEAR_EXTS - erp->er_extcount; > - ext_diff = MIN(ext_avail, erp_next->er_extcount); > - memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); > - erp->er_extcount += ext_diff; > - erp_next->er_extcount -= ext_diff; > - /* Remove next page */ > - if (erp_next->er_extcount == 0) { > + if (ext_avail) { > + > + /* > + * Copy over as many as possible extent records into > + * the previous page. > + */ > + ext_diff = MIN(ext_avail, erp_next->er_extcount); > + memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); > + erp->er_extcount += ext_diff; > + erp_next->er_extcount -= ext_diff; > + > /* > - * Free page before removing extent record > - * so er_extoffs don't get modified in > - * xfs_iext_irec_remove. > + * If the next irec is empty now we can simply > + * remove it. > */ > - kmem_free(erp_next->er_extbuf); > - erp_next->er_extbuf = NULL; > - xfs_iext_irec_remove(ifp, erp_idx + 1); > - erp = &ifp->if_u1.if_ext_irec[erp_idx]; > - nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; > - /* Update next page */ > - } else { > - /* Move rest of page up to become next new page */ > - memmove(erp_next->er_extbuf, ep_next, > - erp_next->er_extcount * sizeof(xfs_bmbt_rec_t)); > - ep_next = erp_next->er_extbuf; > - memset(&ep_next[erp_next->er_extcount], 0, > - (XFS_LINEAR_EXTS - erp_next->er_extcount) * > - sizeof(xfs_bmbt_rec_t)); > + if (erp_next->er_extcount == 0) { > + /* > + * Free page before removing extent record > + * so er_extoffs don't get modified in > + * xfs_iext_irec_remove. > + */ > + kmem_free(erp_next->er_extbuf); > + erp_next->er_extbuf = NULL; > + xfs_iext_irec_remove(ifp, erp_idx + 1); > + erp = &ifp->if_u1.if_ext_irec[erp_idx]; > + nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; > + > + /* > + * If the next irec is not empty move up the content > + * that has not been copied to the previous page to > + * the beggining of this one. > + */ > + } else { > + memmove(erp_next->er_extbuf, &ep_next[ext_diff], > + erp_next->er_extcount * > + sizeof(xfs_bmbt_rec_t)); > + ep_next = erp_next->er_extbuf; > + memset(&ep_next[erp_next->er_extcount], 0, > + (XFS_LINEAR_EXTS - > + erp_next->er_extcount) * > + sizeof(xfs_bmbt_rec_t)); > + } > } > + > if (erp->er_extcount == XFS_LINEAR_EXTS) { > erp_idx++; > if (erp_idx < nlists) > From owner-xfs@oss.sgi.com Sun Jun 15 20:53:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 20:53:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G3rfeW005076 for ; Sun, 15 Jun 2008 20:53:41 -0700 X-ASG-Debug-ID: 1213588475-18df01810000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 0636E17C849B for ; Sun, 15 Jun 2008 20:54:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id uvWmRmhYY6vtEOFm for ; Sun, 15 Jun 2008 20:54:36 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA12325; Mon, 16 Jun 2008 13:54:27 +1000 Message-ID: <4855E4C0.4090309@sgi.com> Date: Mon, 16 Jun 2008 13:57:52 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613134418.GA31720@infradead.org> In-Reply-To: <20080613134418.GA31720@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213588479 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53429 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16365 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: >> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), >> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs >> for the space needed. Since we have reserved the space these allocations >> are now guaranteed to succeed. > > This looks good and makes lot of sense to me. Please also add a comment > to enum xfs_alloctype in xfs_alloc.h about the danger of the allocation > types that never go out of the AG when used inside transactions. The flags already have comments? Are you referring specifically to the fact we have reserved space somewhere in the filesystem but expect to find it in a single AG? > >> In order to search all AGs I had to revert >> a change made to xfs_alloc_vextent() that prevented a search from looking >> at AGs lower than the starting AG. This original change was made to prevent >> out of order AG locking when allocating multiple extents on data writeout >> but since we only allocate one extent at a time now this particular problem >> can't happen. > > This one also makes sense, but I have a very bad gut feeling about it. > There's nothing preventing the same deadlock scenario from coming back > when people modify the highlevel data allocator again. We really need > some sort of assert to trigger early in that case to not got a nasty > hard to trigger deadlock. Yes I agree. I was thinking about making the allocation of a second data extent in the same transaction a conditional try operation to avoid the deadlock. If a caller to the allocator provides room to return more than one extent then I don't think we have to return more than one - multiple extents in one transaction is just an optimisation. > >> + if (++(args->agno) == mp->m_sb.sb_agcount) > > and while we're at it this should be > > if (++args->agno == mp->m_sb.sb_agcount) Done, thanks. From owner-xfs@oss.sgi.com Sun Jun 15 21:44:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 21:44:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G4igVo008603 for ; Sun, 15 Jun 2008 21:44:42 -0700 X-ASG-Debug-ID: 1213591527-57a7006c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id D9488CC179B for ; Sun, 15 Jun 2008 21:45:37 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id sy57TCE3TJvK7KLw for ; Sun, 15 Jun 2008 21:45:37 -0700 (PDT) Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13485; Mon, 16 Jun 2008 14:45:23 +1000 To: Simon , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair trouble Subject: Re: xfs_repair trouble From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Date: Mon, 16 Jun 2008 14:47:04 +1000 Message-ID: In-Reply-To: User-Agent: Opera Mail/9.24 (Win32) X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213591539 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4158 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53434 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16366 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Sun, 15 Jun 2008 02:43:12 +1000, Simon wrote: > Hello all, > > > I have a corrupted xfs filesystem on top of a RAID 5 (1TB in size). > The RAID is still fully intact but the filesystem was damaged. When > trying to repair the filesystem xfs_repair fails. I have tried various > versions of xfs_repair, the latest stable (2.9.8) and the latest trunk > (from CVS). I'd love to investigate and/or fix the issue further but I > am a bit confused about some of my xfs_repair runs (both done with > trunk). > Could someone shed some light on where the problem could be, I'd be > happy to continue digging if I would only know where roughly Are you able to generate an xfs_metadump? If you can make that available, I should be able to find out the problem pretty easily. Regards, Barry. From owner-xfs@oss.sgi.com Sun Jun 15 21:51:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 21:51:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G4pTpk009428 for ; Sun, 15 Jun 2008 21:51:30 -0700 X-ASG-Debug-ID: 1213591944-22ae032d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 35B8F17C87A7 for ; Sun, 15 Jun 2008 21:52:25 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id hWPmPQ7MJ5DPm0bg for ; Sun, 15 Jun 2008 21:52:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALuLVUh5LG+u/2dsb2JhbACsEg X-IronPort-AV: E=Sophos;i="4.27,650,1204464600"; d="scan'208";a="127310636" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 16 Jun 2008 14:22:22 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K86hZ-0005GP-VS; Mon, 16 Jun 2008 14:52:21 +1000 Date: Mon, 16 Jun 2008 14:52:21 +1000 From: Dave Chinner To: Eric Sandeen Cc: Oliver Pinter , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Message-ID: <20080616045221.GJ3700@disturbed> Mail-Followup-To: Eric Sandeen , Oliver Pinter , xfs@oss.sgi.com References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48553C11.2060606@sandeen.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213591946 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1613 1.0000 -1.0380 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.04 X-Barracuda-Spam-Status: No, SCORE=-1.04 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53429 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16367 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Sun, Jun 15, 2008 at 10:58:09AM -0500, Eric Sandeen wrote: > Oliver Pinter wrote: > > this mistake shutdownkor comes out, remount launched because he > > panics, only Alt+Sysrq+foo works > > I'm not sure I follow. > > Assuming that : > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg > > is the first event of interest, it is hitting an assertion on the > remount path: > > ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); > > in xfs_attr_quiesce. That's caused by a race condition in the VFS w.r.t setting the MS_RDONLY flag. It should be fixed in 2.6.26. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 15 22:00:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 22:00:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G50uhW010362 for ; Sun, 15 Jun 2008 22:00:57 -0700 X-ASG-Debug-ID: 1213592513-189e01a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60820234D2A for ; Sun, 15 Jun 2008 22:01:53 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id n3AEG1ixUiPVIvo8 for ; Sun, 15 Jun 2008 22:01:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAECPVUh5LG+u/2dsb2JhbACsHA X-IronPort-AV: E=Sophos;i="4.27,650,1204464600"; d="scan'208";a="127318039" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 16 Jun 2008 14:31:52 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K86qk-0005SF-PN; Mon, 16 Jun 2008 15:01:50 +1000 Date: Mon, 16 Jun 2008 15:01:50 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert Message-ID: <20080616050150.GK3700@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <4855CE2D.70505@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4855CE2D.70505@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213592514 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53435 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16368 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 16, 2008 at 12:21:33PM +1000, Lachlan McIlroy wrote: > After a btree insert operation a cursor can be invalid due to block > splits and a maybe a new root block. We reset the cursor in > xfs_bmbt_insert() in the cases where we think we need to but it > isn't enough as we still see assertions. Just do what we do elsewhere > and reset the cursor unconditionally. Ok, so you should also kill the new code in the btree insert that revalidates the btree cursor. IIRC, this was the only place it was needed for.... > --- fs/xfs/xfs_bmap.c_1.392 2008-06-03 12:20:14.000000000 +1000 > +++ fs/xfs/xfs_bmap.c 2008-06-16 12:11:47.000000000 +1000 > @@ -1745,11 +1745,17 @@ xfs_bmap_add_extent_unwritten_real( > if ((error = xfs_bmbt_insert(cur, &i))) > goto done; > ASSERT(i == 1); > - if ((error = xfs_bmbt_increment(cur, 0, &i))) > + /* > + * Reset the cursor, don't trust it after any insert > + * operation. > + */ /* * reset the cursor to the position of the new extent we are about * to insert as we can't trust it after the previous insert */ > + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, > + new->br_startblock, new->br_blockcount, > + &i))) > goto done; error = xfs_bmbt_lookup_eq(cur, new->br_startoff, br_startblock, new->br_blockcount, &i); if (error) goto done; > - ASSERT(i == 1); > + ASSERT(i == 0); ASSERT? How about a WANT_CORRUPTED_GOTO()? > /* new middle extent - newext */ > - cur->bc_rec.b = *new; > + cur->bc_rec.b.br_state = new->br_state; > if ((error = xfs_bmbt_insert(cur, &i))) > goto done; > ASSERT(i == 1); Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 15 23:06:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:06:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G66t9a015146 for ; Sun, 15 Jun 2008 23:06:55 -0700 X-ASG-Debug-ID: 1213596469-2d4002450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 681E02350C7 for ; Sun, 15 Jun 2008 23:07:50 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id ociSLFtR0V60inVo for ; Sun, 15 Jun 2008 23:07:50 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15237; Mon, 16 Jun 2008 16:07:43 +1000 Message-ID: <485603FD.2080204@sgi.com> Date: Mon, 16 Jun 2008 16:11:09 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> In-Reply-To: <20080613155708.GG3700@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213596473 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53439 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16369 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: >> When at ENOSPC conditions extent btree block allocations can fail and we >> have no error handling to undo partial btree operations. Prior to extent >> btree operations we reserve enough disk blocks somewhere in the filesystem >> to satisfy the operation but in some conditions we require the blocks to >> come from specific AGs and if those AGs are full the allocation fails. >> >> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), >> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs >> for the space needed. Since we have reserved the space these allocations >> are now guaranteed to succeed. > > Sure, but we didn't reserve space for potential btree splits in a > second AG as a result of this. That needs to be reserved in the > transaction as well, which will blow out transaction reservations > substantially as we'll need to add another 2 full AGF btree splits to > every transaction that modifies the bmap btree. Right. And most of the time we wont need the space either so it's a real waste. > >> In order to search all AGs I had to revert >> a change made to xfs_alloc_vextent() that prevented a search from looking >> at AGs lower than the starting AG. This original change was made to prevent >> out of order AG locking when allocating multiple extents on data writeout >> but since we only allocate one extent at a time now this particular problem >> can't happen. > > You missed the fact that the AGF of modified AGs is already held > locked in the transaction, hence the locking order within the > transaction is wrong. Also, if we modify the free list in an AG > the fail an allocation (e.g. can't do an exact allocation), we'll > have multiple dirty and locked AGFs in the one allocation. Hence > we still can have locking order violations if you remove that check > and therefore deadlocks. I'm well aware of that particular deadlock involving the freelist - I hit it while testing. If you look closely at the code that deadlock can occur with or without the AG locking avoidance logic. This is because the rest of the transaction is unaware that an AG has been locked due to a freelist operation. > > This is not the solution to the problem. As I suggested (back when > you first floated this idea as a fix for the problem several weeks > ago) I think the bug is that we are not taking into account the > number of blocks required for a bmbt split when selecting an AG to > allocate from. All we take into account is the blocks required for > the extent to be allocated and nothing else. If we take the blocks > for a bmbt split into account then we'll never try to allocate an > extent in an AG that we can't also allocate all the blocks for the > bmbt split in at the same time. > I considered that approach (using the minleft field in xfs_alloc_arg_t) but it has it's problems too. When we reserve space for the btree operations it is done on the global filesystem counters, not a particular AG, so there is the possibility that not one AG has sufficent space to perform the allocation even though there is enough free space in the whole filesystem. Of course if we have enough space left in one AG and the AG is locked then the space we reserved doesn't matter anymore and it should all work. I'm worried with this approach that we could have delayed allocations and unwritten extents that need to be converted but we can't do it because we don't have the space we might need (but probably don't). From owner-xfs@oss.sgi.com Sun Jun 15 23:17:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:17:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G6Hsnm016391 for ; Sun, 15 Jun 2008 23:17:55 -0700 X-ASG-Debug-ID: 1213597129-113602320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3BB191BA25DF for ; Sun, 15 Jun 2008 23:18:49 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id m3rVx5Ea4o5wQF1C for ; Sun, 15 Jun 2008 23:18:49 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5G6IdNW005401 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2008 08:18:39 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5G6Idum005399 for xfs@oss.sgi.com; Mon, 16 Jun 2008 08:18:39 +0200 Date: Mon, 16 Jun 2008 08:18:39 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] merge xfs_rmdir into xfs_remove Subject: Re: [PATCH 1/2] merge xfs_rmdir into xfs_remove Message-ID: <20080616061839.GA5230@lst.de> References: <20080502105757.GB17870@lst.de> <20080521082548.GB3215@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080521082548.GB3215@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213597131 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53439 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16370 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Wed, May 21, 2008 at 10:25:48AM +0200, Christoph Hellwig wrote: > On Fri, May 02, 2008 at 12:57:57PM +0200, Christoph Hellwig wrote: > > xfs_remove and xfs_rmdir are almost the same with a little more work > > performed in xfs_rmdir due to the . and .. entries. This patch merges > > xfs_rmdir into xfs_remove and performs these actions conditionally. > > > > Also clean up the error handling which was a nightmare in both versions > > before. > > Updated for the case-insensitive filename changes. And another update for the d_invalidate added on unlink/rmdir. Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-06-16 08:11:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-06-16 08:14:16.000000000 +0200 @@ -2116,13 +2116,6 @@ again: #endif } -#ifdef DEBUG -#define REMOVE_DEBUG_TRACE(x) {remove_which_error_return = (x);} -int remove_which_error_return = 0; -#else /* ! DEBUG */ -#define REMOVE_DEBUG_TRACE(x) -#endif /* ! DEBUG */ - int xfs_remove( xfs_inode_t *dp, @@ -2131,6 +2124,7 @@ xfs_remove( { xfs_mount_t *mp = dp->i_mount; xfs_trans_t *tp = NULL; + int is_dir = S_ISDIR(ip->i_d.di_mode); int error = 0; xfs_bmap_free_t free_list; xfs_fsblock_t first_block; @@ -2138,8 +2132,11 @@ xfs_remove( int committed; int link_zero; uint resblks; + uint trans; + uint log_count; xfs_itrace_entry(dp); + xfs_itrace_entry(ip); if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); @@ -2152,19 +2149,25 @@ xfs_remove( return error; } - xfs_itrace_entry(ip); - xfs_itrace_ref(ip); - error = XFS_QM_DQATTACH(mp, dp, 0); - if (!error) - error = XFS_QM_DQATTACH(mp, ip, 0); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); + if (error) + goto std_return; + + error = XFS_QM_DQATTACH(mp, ip, 0); + if (error) goto std_return; + + if (is_dir) { + trans = XFS_TRANS_RMDIR; + log_count = XFS_DEFAULT_LOG_COUNT; + } else { + trans = XFS_TRANS_REMOVE; + log_count = XFS_REMOVE_LOG_COUNT; } - tp = xfs_trans_alloc(mp, XFS_TRANS_REMOVE); + tp = xfs_trans_alloc(mp, trans); cancel_flags = XFS_TRANS_RELEASE_LOG_RES; + /* * We try to get the real space reservation first, * allowing for directory btree deletion(s) implying @@ -2176,25 +2179,21 @@ xfs_remove( */ resblks = XFS_REMOVE_SPACE_RES(mp); error = xfs_trans_reserve(tp, resblks, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_REMOVE_LOG_COUNT); + XFS_TRANS_PERM_LOG_RES, log_count); if (error == ENOSPC) { resblks = 0; error = xfs_trans_reserve(tp, 0, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_REMOVE_LOG_COUNT); + XFS_TRANS_PERM_LOG_RES, log_count); } if (error) { ASSERT(error != ENOSPC); - REMOVE_DEBUG_TRACE(__LINE__); - xfs_trans_cancel(tp, 0); - return error; + cancel_flags = 0; + goto out_trans_cancel; } error = xfs_lock_dir_and_entry(dp, ip); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - xfs_trans_cancel(tp, cancel_flags); - goto std_return; - } + if (error) + goto out_trans_cancel; /* * At this point, we've gotten both the directory and the entry @@ -2207,6 +2206,21 @@ xfs_remove( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); /* + * If we're removing a directory perform some additional validation. + */ + if (is_dir) { + ASSERT(ip->i_d.di_nlink >= 2); + if (ip->i_d.di_nlink != 2) { + error = XFS_ERROR(ENOTEMPTY); + goto out_trans_cancel; + } + if (!xfs_dir_isempty(ip)) { + error = XFS_ERROR(ENOTEMPTY); + goto out_trans_cancel; + } + } + + /* * Entry must exist since we did a lookup in xfs_lock_dir_and_entry. */ XFS_BMAP_INIT(&free_list, &first_block); @@ -2214,39 +2228,64 @@ xfs_remove( &first_block, &free_list, resblks); if (error) { ASSERT(error != ENOENT); - REMOVE_DEBUG_TRACE(__LINE__); - goto error1; + goto out_bmap_cancel; } xfs_ichgtime(dp, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); + /* + * Bump the in memory generation count on the parent + * directory so that other can know that it has changed. + */ dp->i_gen++; xfs_trans_log_inode(tp, dp, XFS_ILOG_CORE); - error = xfs_droplink(tp, ip); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - goto error1; + if (is_dir) { + /* + * Drop the link from ip's "..". + */ + error = xfs_droplink(tp, dp); + if (error) + goto out_bmap_cancel; + + /* + * Drop the link from dp to ip. + */ + error = xfs_droplink(tp, ip); + if (error) + goto out_bmap_cancel; + } else { + /* + * When removing a non-directory we need to log the parent + * inode here for the i_gen update. For a directory this is + * done implicitly by the xfs_droplink call for the ".." entry. + */ + xfs_trans_log_inode(tp, dp, XFS_ILOG_CORE); } - /* Determine if this is the last link while + /* + * Drop the "." link from ip to self. + */ + error = xfs_droplink(tp, ip); + if (error) + goto out_bmap_cancel; + + /* + * Determine if this is the last link while * we are in the transaction. */ - link_zero = (ip)->i_d.di_nlink==0; + link_zero = (ip->i_d.di_nlink == 0); /* * If this is a synchronous mount, make sure that the * remove transaction goes to disk before returning to * the user. */ - if (mp->m_flags & (XFS_MOUNT_WSYNC|XFS_MOUNT_DIRSYNC)) { + if (mp->m_flags & (XFS_MOUNT_WSYNC|XFS_MOUNT_DIRSYNC)) xfs_trans_set_sync(tp); - } error = xfs_bmap_finish(&tp, &free_list, &committed); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - goto error_rele; - } + if (error) + goto out_bmap_cancel; error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (error) @@ -2258,39 +2297,27 @@ xfs_remove( * will get killed on last close in xfs_close() so we don't * have to worry about that. */ - if (link_zero && xfs_inode_is_filestream(ip)) + if (!is_dir && link_zero && xfs_inode_is_filestream(ip)) xfs_filestream_deassociate(ip); xfs_itrace_exit(ip); + xfs_itrace_exit(dp); -/* Fall through to std_return with error = 0 */ std_return: if (DM_EVENT_ENABLED(dp, DM_EVENT_POSTREMOVE)) { - (void) XFS_SEND_NAMESP(mp, DM_EVENT_POSTREMOVE, - dp, DM_RIGHT_NULL, - NULL, DM_RIGHT_NULL, - name->name, NULL, ip->i_d.di_mode, error, 0); + XFS_SEND_NAMESP(mp, DM_EVENT_POSTREMOVE, dp, DM_RIGHT_NULL, + NULL, DM_RIGHT_NULL, name->name, NULL, + ip->i_d.di_mode, error, 0); } + return error; - error1: + out_bmap_cancel: xfs_bmap_cancel(&free_list); cancel_flags |= XFS_TRANS_ABORT; + out_trans_cancel: xfs_trans_cancel(tp, cancel_flags); goto std_return; - - error_rele: - /* - * In this case make sure to not release the inode until after - * the current transaction is aborted. Releasing it beforehand - * can cause us to go to xfs_inactive and start a recursive - * transaction which can easily deadlock with the current one. - */ - xfs_bmap_cancel(&free_list); - cancel_flags |= XFS_TRANS_ABORT; - xfs_trans_cancel(tp, cancel_flags); - - goto std_return; } int @@ -2656,186 +2683,6 @@ std_return: } int -xfs_rmdir( - xfs_inode_t *dp, - struct xfs_name *name, - xfs_inode_t *cdp) -{ - xfs_mount_t *mp = dp->i_mount; - xfs_trans_t *tp; - int error; - xfs_bmap_free_t free_list; - xfs_fsblock_t first_block; - int cancel_flags; - int committed; - int last_cdp_link; - uint resblks; - - xfs_itrace_entry(dp); - - if (XFS_FORCED_SHUTDOWN(mp)) - return XFS_ERROR(EIO); - - if (DM_EVENT_ENABLED(dp, DM_EVENT_REMOVE)) { - error = XFS_SEND_NAMESP(mp, DM_EVENT_REMOVE, - dp, DM_RIGHT_NULL, - NULL, DM_RIGHT_NULL, name->name, - NULL, cdp->i_d.di_mode, 0, 0); - if (error) - return XFS_ERROR(error); - } - - /* - * Get the dquots for the inodes. - */ - error = XFS_QM_DQATTACH(mp, dp, 0); - if (!error) - error = XFS_QM_DQATTACH(mp, cdp, 0); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - goto std_return; - } - - tp = xfs_trans_alloc(mp, XFS_TRANS_RMDIR); - cancel_flags = XFS_TRANS_RELEASE_LOG_RES; - /* - * We try to get the real space reservation first, - * allowing for directory btree deletion(s) implying - * possible bmap insert(s). If we can't get the space - * reservation then we use 0 instead, and avoid the bmap - * btree insert(s) in the directory code by, if the bmap - * insert tries to happen, instead trimming the LAST - * block from the directory. - */ - resblks = XFS_REMOVE_SPACE_RES(mp); - error = xfs_trans_reserve(tp, resblks, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_DEFAULT_LOG_COUNT); - if (error == ENOSPC) { - resblks = 0; - error = xfs_trans_reserve(tp, 0, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_DEFAULT_LOG_COUNT); - } - if (error) { - ASSERT(error != ENOSPC); - cancel_flags = 0; - goto error_return; - } - XFS_BMAP_INIT(&free_list, &first_block); - - /* - * Now lock the child directory inode and the parent directory - * inode in the proper order. This will take care of validating - * that the directory entry for the child directory inode has - * not changed while we were obtaining a log reservation. - */ - error = xfs_lock_dir_and_entry(dp, cdp); - if (error) { - xfs_trans_cancel(tp, cancel_flags); - goto std_return; - } - - IHOLD(dp); - xfs_trans_ijoin(tp, dp, XFS_ILOCK_EXCL); - - IHOLD(cdp); - xfs_trans_ijoin(tp, cdp, XFS_ILOCK_EXCL); - - ASSERT(cdp->i_d.di_nlink >= 2); - if (cdp->i_d.di_nlink != 2) { - error = XFS_ERROR(ENOTEMPTY); - goto error_return; - } - if (!xfs_dir_isempty(cdp)) { - error = XFS_ERROR(ENOTEMPTY); - goto error_return; - } - - error = xfs_dir_removename(tp, dp, name, cdp->i_ino, - &first_block, &free_list, resblks); - if (error) - goto error1; - - xfs_ichgtime(dp, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); - - /* - * Bump the in memory generation count on the parent - * directory so that other can know that it has changed. - */ - dp->i_gen++; - - /* - * Drop the link from cdp's "..". - */ - error = xfs_droplink(tp, dp); - if (error) { - goto error1; - } - - /* - * Drop the link from dp to cdp. - */ - error = xfs_droplink(tp, cdp); - if (error) { - goto error1; - } - - /* - * Drop the "." link from cdp to self. - */ - error = xfs_droplink(tp, cdp); - if (error) { - goto error1; - } - - /* Determine these before committing transaction */ - last_cdp_link = (cdp)->i_d.di_nlink==0; - - /* - * If this is a synchronous mount, make sure that the - * rmdir transaction goes to disk before returning to - * the user. - */ - if (mp->m_flags & (XFS_MOUNT_WSYNC|XFS_MOUNT_DIRSYNC)) { - xfs_trans_set_sync(tp); - } - - error = xfs_bmap_finish (&tp, &free_list, &committed); - if (error) { - xfs_bmap_cancel(&free_list); - xfs_trans_cancel(tp, (XFS_TRANS_RELEASE_LOG_RES | - XFS_TRANS_ABORT)); - goto std_return; - } - - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); - if (error) { - goto std_return; - } - - - /* Fall through to std_return with error = 0 or the errno - * from xfs_trans_commit. */ - std_return: - if (DM_EVENT_ENABLED(dp, DM_EVENT_POSTREMOVE)) { - (void) XFS_SEND_NAMESP(mp, DM_EVENT_POSTREMOVE, - dp, DM_RIGHT_NULL, - NULL, DM_RIGHT_NULL, - name->name, NULL, cdp->i_d.di_mode, - error, 0); - } - return error; - - error1: - xfs_bmap_cancel(&free_list); - cancel_flags |= XFS_TRANS_ABORT; - /* FALLTHROUGH */ - - error_return: - xfs_trans_cancel(tp, cancel_flags); - goto std_return; -} - -int xfs_symlink( xfs_inode_t *dp, struct xfs_name *link_name, Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-16 08:14:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-16 08:15:00.000000000 +0200 @@ -252,8 +252,7 @@ STATIC void xfs_cleanup_inode( struct inode *dir, struct inode *inode, - struct dentry *dentry, - int mode) + struct dentry *dentry) { struct xfs_name teardown; @@ -264,10 +263,7 @@ xfs_cleanup_inode( */ xfs_dentry_to_name(&teardown, dentry); - if (S_ISDIR(mode)) - xfs_rmdir(XFS_I(dir), &teardown, XFS_I(inode)); - else - xfs_remove(XFS_I(dir), &teardown, XFS_I(inode)); + xfs_remove(XFS_I(dir), &teardown, XFS_I(inode)); iput(inode); } @@ -349,7 +345,7 @@ xfs_vn_mknod( return -error; out_cleanup_inode: - xfs_cleanup_inode(dir, inode, dentry, mode); + xfs_cleanup_inode(dir, inode, dentry); out_free_acl: if (default_acl) _ACL_FREE(default_acl); @@ -525,38 +521,12 @@ xfs_vn_symlink( return 0; out_cleanup_inode: - xfs_cleanup_inode(dir, inode, dentry, 0); + xfs_cleanup_inode(dir, inode, dentry); out: return -error; } STATIC int -xfs_vn_rmdir( - struct inode *dir, - struct dentry *dentry) -{ - struct inode *inode = dentry->d_inode; - struct xfs_name name; - int error; - - xfs_dentry_to_name(&name, dentry); - - error = xfs_rmdir(XFS_I(dir), &name, XFS_I(inode)); - if (likely(!error)) { - xfs_validate_fields(inode); - xfs_validate_fields(dir); - /* - * With rmdir, the VFS makes the dentry "negative": no inode, - * but still hashed. This is incompatible with case-insensitive - * mode, so invalidate (unhash) the dentry in CI-mode. - */ - if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) - d_invalidate(dentry); - } - return -error; -} - -STATIC int xfs_vn_rename( struct inode *odir, struct dentry *odentry, @@ -850,7 +820,13 @@ static const struct inode_operations xfs .unlink = xfs_vn_unlink, .symlink = xfs_vn_symlink, .mkdir = xfs_vn_mkdir, - .rmdir = xfs_vn_rmdir, + /* + * Yes, XFS uses the same method for rmdir and unlink. + * + * There are some subtile differences deeper in the code, + * but we use S_ISDIR to check for those. + */ + .rmdir = xfs_vn_unlink, .mknod = xfs_vn_mknod, .rename = xfs_vn_rename, .permission = xfs_vn_permission, @@ -869,7 +845,13 @@ static const struct inode_operations xfs .unlink = xfs_vn_unlink, .symlink = xfs_vn_symlink, .mkdir = xfs_vn_mkdir, - .rmdir = xfs_vn_rmdir, + /* + * Yes, XFS uses the same method for rmdir and unlink. + * + * There are some subtile differences deeper in the code, + * but we use S_ISDIR to check for those. + */ + .rmdir = xfs_vn_unlink, .mknod = xfs_vn_mknod, .rename = xfs_vn_rename, .permission = xfs_vn_permission, Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2008-06-16 08:11:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2008-06-16 08:14:16.000000000 +0200 @@ -31,8 +31,6 @@ int xfs_link(struct xfs_inode *tdp, stru struct xfs_name *target_name); int xfs_mkdir(struct xfs_inode *dp, struct xfs_name *dir_name, mode_t mode, struct xfs_inode **ipp, struct cred *credp); -int xfs_rmdir(struct xfs_inode *dp, struct xfs_name *name, - struct xfs_inode *cdp); int xfs_readdir(struct xfs_inode *dp, void *dirent, size_t bufsize, xfs_off_t *offset, filldir_t filldir); int xfs_symlink(struct xfs_inode *dp, struct xfs_name *link_name, From owner-xfs@oss.sgi.com Sun Jun 15 23:24:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:24:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G6OPgC017137 for ; Sun, 15 Jun 2008 23:24:25 -0700 X-ASG-Debug-ID: 1213597521-57ab01c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 49D24CC1D62 for ; Sun, 15 Jun 2008 23:25:22 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id BXy3T3Z0g7qyuTOr for ; Sun, 15 Jun 2008 23:25:22 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5G6PDNW005930 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2008 08:25:13 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5G6PD6G005927 for xfs@oss.sgi.com; Mon, 16 Jun 2008 08:25:13 +0200 Date: Mon, 16 Jun 2008 08:25:13 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] don't update i_size for directories and special files Subject: Re: [PATCH] don't update i_size for directories and special files Message-ID: <20080616062513.GA5842@lst.de> References: <20080518130707.GB28501@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080518130707.GB28501@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213597523 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53440 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16371 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Sun, May 18, 2008 at 03:07:07PM +0200, Christoph Hellwig wrote: > The core kernel uses vfs_getattr to look at the inode size and similar > attributes, so there is no need to keep i_size uptodate for directories > or special files. This means we can remove xfs_validate_fields because > the I/O path already keeps i_size uptodate for regular files. > Updated for the d_invalidate added on unlink/rmdir. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-16 08:15:00.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-16 08:20:56.000000000 +0200 @@ -188,23 +188,6 @@ xfs_ichgtime_fast( mark_inode_dirty_sync(inode); } - -/* - * Pull the link count and size up from the xfs inode to the linux inode - */ -STATIC void -xfs_validate_fields( - struct inode *inode) -{ - struct xfs_inode *ip = XFS_I(inode); - loff_t size; - - /* we're under i_sem so i_size can't change under us */ - size = XFS_ISIZE(ip); - if (i_size_read(inode) != size) - i_size_write(inode, size); -} - /* * Hook in SELinux. This is not quite correct yet, what we really need * here (as we do for default ACLs) is a mechanism by which creation of @@ -338,10 +321,7 @@ xfs_vn_mknod( } - if (S_ISDIR(mode)) - xfs_validate_fields(inode); d_instantiate(dentry, inode); - xfs_validate_fields(dir); return -error; out_cleanup_inode: @@ -457,7 +437,6 @@ xfs_vn_link( } xfs_iflags_set(XFS_I(dir), XFS_IMODIFIED); - xfs_validate_fields(inode); d_instantiate(dentry, inode); return 0; } @@ -467,26 +446,23 @@ xfs_vn_unlink( struct inode *dir, struct dentry *dentry) { - struct inode *inode; struct xfs_name name; int error; - inode = dentry->d_inode; xfs_dentry_to_name(&name, dentry); - error = xfs_remove(XFS_I(dir), &name, XFS_I(inode)); - if (likely(!error)) { - xfs_validate_fields(dir); /* size needs update */ - xfs_validate_fields(inode); - /* - * With unlink, the VFS makes the dentry "negative": no inode, - * but still hashed. This is incompatible with case-insensitive - * mode, so invalidate (unhash) the dentry in CI-mode. - */ - if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) - d_invalidate(dentry); - } - return -error; + error = -xfs_remove(XFS_I(dir), &name, XFS_I(dentry->d_inode)); + if (error) + return error; + + /* + * With unlink, the VFS makes the dentry "negative": no inode, + * but still hashed. This is incompatible with case-insensitive + * mode, so invalidate (unhash) the dentry in CI-mode. + */ + if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) + d_invalidate(dentry); + return 0; } STATIC int @@ -516,8 +492,6 @@ xfs_vn_symlink( goto out_cleanup_inode; d_instantiate(dentry, inode); - xfs_validate_fields(dir); - xfs_validate_fields(inode); return 0; out_cleanup_inode: @@ -536,22 +510,13 @@ xfs_vn_rename( struct inode *new_inode = ndentry->d_inode; struct xfs_name oname; struct xfs_name nname; - int error; xfs_dentry_to_name(&oname, odentry); xfs_dentry_to_name(&nname, ndentry); - error = xfs_rename(XFS_I(odir), &oname, XFS_I(odentry->d_inode), + return -xfs_rename(XFS_I(odir), &oname, XFS_I(odentry->d_inode), XFS_I(ndir), &nname, new_inode ? XFS_I(new_inode) : NULL); - if (likely(!error)) { - if (new_inode) - xfs_validate_fields(new_inode); - xfs_validate_fields(odir); - if (ndir != odir) - xfs_validate_fields(ndir); - } - return -error; } /* From owner-xfs@oss.sgi.com Sun Jun 15 23:25:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:25:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G6Pk6Q017540 for ; Sun, 15 Jun 2008 23:25:46 -0700 X-ASG-Debug-ID: 1213597602-708400750000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2F961235148 for ; Sun, 15 Jun 2008 23:26:43 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id YiiCHG0b4qDDgmkZ for ; Sun, 15 Jun 2008 23:26:43 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5G6QYNW006023 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2008 08:26:34 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5G6QYep006021 for xfs@oss.sgi.com; Mon, 16 Jun 2008 08:26:34 +0200 Date: Mon, 16 Jun 2008 08:26:34 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] kill XFS_PURGE_INODE Subject: [PATCH] kill XFS_PURGE_INODE Message-ID: <20080616062634.GA5971@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213597604 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53440 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16372 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Just a useless alias for IRELE. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c 2008-06-05 20:21:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c 2008-06-05 20:22:37.000000000 +0200 @@ -444,11 +444,11 @@ xfs_qm_unmount_quotas( } } if (uqp) { - XFS_PURGE_INODE(uqp); + IRELE(uqp); mp->m_quotainfo->qi_uquotaip = NULL; } if (gqp) { - XFS_PURGE_INODE(gqp); + IRELE(gqp); mp->m_quotainfo->qi_gquotaip = NULL; } out: @@ -1239,11 +1239,11 @@ xfs_qm_destroy_quotainfo( xfs_qm_list_destroy(&qi->qi_dqlist); if (qi->qi_uquotaip) { - XFS_PURGE_INODE(qi->qi_uquotaip); + IRELE(qi->qi_uquotaip); qi->qi_uquotaip = NULL; /* paranoia */ } if (qi->qi_gquotaip) { - XFS_PURGE_INODE(qi->qi_gquotaip); + IRELE(qi->qi_gquotaip); qi->qi_gquotaip = NULL; } mutex_destroy(&qi->qi_quotaofflock); @@ -1393,7 +1393,7 @@ xfs_qm_qino_alloc( * locked exclusively and joined to the transaction already. */ ASSERT(xfs_isilocked(*ip, XFS_ILOCK_EXCL)); - VN_HOLD(XFS_ITOV((*ip))); + IHOLD(*ip); /* * Make the changes in the superblock, and log those too. Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2008-05-23 09:31:39.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-05 20:21:09.000000000 +0200 @@ -362,11 +362,11 @@ xfs_qm_scall_quotaoff( * if we don't need them anymore. */ if ((dqtype & XFS_QMOPT_UQUOTA) && XFS_QI_UQIP(mp)) { - XFS_PURGE_INODE(XFS_QI_UQIP(mp)); + IRELE(XFS_QI_UQIP(mp)); XFS_QI_UQIP(mp) = NULL; } if ((dqtype & (XFS_QMOPT_GQUOTA|XFS_QMOPT_PQUOTA)) && XFS_QI_GQIP(mp)) { - XFS_PURGE_INODE(XFS_QI_GQIP(mp)); + IRELE(XFS_QI_GQIP(mp)); XFS_QI_GQIP(mp) = NULL; } out_error: Index: linux-2.6-xfs/fs/xfs/quota/xfs_quota_priv.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_quota_priv.h 2008-05-23 09:31:39.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_quota_priv.h 2008-06-05 20:21:09.000000000 +0200 @@ -158,9 +158,6 @@ for ((dqp) = (qlist)->qh_next; (dqp) != #define XFS_IS_SUSER_DQUOT(dqp) \ (!((dqp)->q_core.d_id)) -#define XFS_PURGE_INODE(ip) \ - IRELE(ip); - #define DQFLAGTO_TYPESTR(d) (((d)->dq_flags & XFS_DQ_USER) ? "USR" : \ (((d)->dq_flags & XFS_DQ_GROUP) ? "GRP" : \ (((d)->dq_flags & XFS_DQ_PROJ) ? "PRJ":"???"))) From owner-xfs@oss.sgi.com Sun Jun 15 23:36:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:37:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G6axf3018635 for ; Sun, 15 Jun 2008 23:36:59 -0700 X-ASG-Debug-ID: 1213598274-627800230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 25BCC1BA27EC for ; Sun, 15 Jun 2008 23:37:55 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id nSZmtqJacC1QCxSp for ; Sun, 15 Jun 2008 23:37:55 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15918; Mon, 16 Jun 2008 16:37:49 +1000 Message-ID: <48560B0B.3060204@sgi.com> Date: Mon, 16 Jun 2008 16:41:15 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert References: <4855CE2D.70505@sgi.com> <20080616050150.GK3700@disturbed> In-Reply-To: <20080616050150.GK3700@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213598277 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4211 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53441 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16373 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Mon, Jun 16, 2008 at 12:21:33PM +1000, Lachlan McIlroy wrote: >> After a btree insert operation a cursor can be invalid due to block >> splits and a maybe a new root block. We reset the cursor in >> xfs_bmbt_insert() in the cases where we think we need to but it >> isn't enough as we still see assertions. Just do what we do elsewhere >> and reset the cursor unconditionally. > > Ok, so you should also kill the new code in the btree insert that > revalidates the btree cursor. IIRC, this was the only place it was > needed for.... That was the plan. > >> --- fs/xfs/xfs_bmap.c_1.392 2008-06-03 12:20:14.000000000 +1000 >> +++ fs/xfs/xfs_bmap.c 2008-06-16 12:11:47.000000000 +1000 >> @@ -1745,11 +1745,17 @@ xfs_bmap_add_extent_unwritten_real( >> if ((error = xfs_bmbt_insert(cur, &i))) >> goto done; >> ASSERT(i == 1); >> - if ((error = xfs_bmbt_increment(cur, 0, &i))) >> + /* >> + * Reset the cursor, don't trust it after any insert >> + * operation. >> + */ > > /* > * reset the cursor to the position of the new extent we are about > * to insert as we can't trust it after the previous insert > */ Fair enough. > >> + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, >> + new->br_startblock, new->br_blockcount, >> + &i))) >> goto done; > > > error = xfs_bmbt_lookup_eq(cur, new->br_startoff, > br_startblock, new->br_blockcount, &i); > if (error) > goto done; > >> - ASSERT(i == 1); >> + ASSERT(i == 0); > > ASSERT? How about a WANT_CORRUPTED_GOTO()? I was just being consistent with the rest of the code. If you think this ASSERT should be changed then what about all of them? > >> /* new middle extent - newext */ >> - cur->bc_rec.b = *new; >> + cur->bc_rec.b.br_state = new->br_state; >> if ((error = xfs_bmbt_insert(cur, &i))) >> goto done; >> ASSERT(i == 1); > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Mon Jun 16 02:11:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 02:11:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_51, NORMAL_HTTP_TO_IP,UPPERCASE_50_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G9BCBf005409 for ; Mon, 16 Jun 2008 02:11:12 -0700 X-ASG-Debug-ID: 1213607526-48c902b90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bay0-omc2-s23.bay0.hotmail.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D628B11D3097 for ; Mon, 16 Jun 2008 02:12:06 -0700 (PDT) Received: from bay0-omc2-s23.bay0.hotmail.com (bay0-omc2-s23.bay0.hotmail.com [65.54.246.159]) by cuda.sgi.com with ESMTP id lObAfXGa95sokLQq for ; Mon, 16 Jun 2008 02:12:06 -0700 (PDT) Received: from hotmail.com ([65.54.174.78]) by bay0-omc2-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 02:12:06 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Jun 2008 02:12:05 -0700 Message-ID: Received: from 85.32.103.134 by BAY103-DAV6.phx.gbl with DAV; Mon, 16 Jun 2008 09:12:03 +0000 X-Originating-IP: [85.32.103.134] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: Cc: X-ASG-Orig-Subj: XFS: 2.6.26-rc6 link count mismatch for inode Subject: XFS: 2.6.26-rc6 link count mismatch for inode Date: Mon, 16 Jun 2008 11:11:31 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 16 Jun 2008 09:12:05.0938 (UTC) FILETIME=[0C0C0120:01C8CF91] X-Barracuda-Connect: bay0-omc2-s23.bay0.hotmail.com[65.54.246.159] X-Barracuda-Start-Time: 1213607526 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.93 X-Barracuda-Spam-Status: No, SCORE=-0.93 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, MSGID_FROM_MTA_HEADER, NORMAL_HTTP_TO_IP, UPPERCASE_50_75 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53442 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.59 UPPERCASE_50_75 message body is 50-75% uppercase 0.50 BSF_RULE7568M Custom Rule 7568M 0.00 MSGID_FROM_MTA_HEADER Message-Id was added by a relay X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16374 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Hi Folk, I was tring to compile firefox 3.0rc3 and while I was erasing a previous /tmp/mozilla tree, I started a new tar xjf mozilla-blabla. After a while linux 2.6.26-rc6 was unresponsive: I have unplugged the power cable. No problem at startup, but: root@Venus:/tmp# rm -r mozilla/ rm: cannot remove `mozilla//netwerk/build/.deps': No such file or directory rm: cannot remove `mozilla//netwerk/resources/content/CVS': No such file or directory root@Venus:/tmp/mozilla/netwerk# rm -r build rm: cannot remove `build/.deps': No such file or directory root@Venus:/tmp/mozilla/netwerk# cd build/ root@Venus:/tmp/mozilla/netwerk/build# rm -r .deps rm: cannot remove `.deps': No such file or directory root@Venus:/tmp/mozilla/netwerk/build# ls -fl /bin/ls: cannot access .deps: No such file or directory total 0 drwxr-xr-x 3 root root 18 2008-06-16 10:03 ./ drwxr-xr-x 4 root root 34 2008-06-16 10:03 ../ ?????????? ? ? ? ? ? .deps so, I have checked the filesystem with: xfs_check /dev/sda2: bad format 1 for inode 70353 type 0 bad format 2 for inode 98831 type 0 agi unlinked bucket 13 is 10573 in ag 0 (inode=10573) agi unlinked bucket 6 is 1309318 in ag 1 (inode=18086534) agi unlinked bucket 7 is 1309319 in ag 1 (inode=18086535) agi unlinked bucket 40 is 471720 in ag 2 (inode=34026152) bad format 1 for inode 85450805 type 0 bad format 2 for inode 85450806 type 0 bad format 2 for inode 85450807 type 0 bad format 2 for inode 85450808 type 0 bad format 2 for inode 85450809 type 0 block 0/6279 type unknown not expected block 0/6280 type unknown not expected block 0/6281 type unknown not expected block 0/6282 type unknown not expected block 0/6283 type unknown not expected block 0/6284 type unknown not expected block 0/6285 type unknown not expected block 5/97840 type unknown not expected block 5/97841 type unknown not expected block 5/97842 type unknown not expected block 5/97843 type unknown not expected link count mismatch for inode 70353 (name ?), nlink 0, counted 1 allocated inode 98831 has 0 link count allocated inode 10573 has 0 link count allocated inode 18086534 has 0 link count allocated inode 18086535 has 0 link count link count mismatch for inode 19893187 (name ?), nlink 3, counted 2 allocated inode 34026152 has 0 link count link count mismatch for inode 67179727 (name ?), nlink 3, counted 2 link count mismatch for inode 85450805 (name ?), nlink 0, counted 1 allocated inode 85450806 has 0 link count allocated inode 85450807 has 0 link count allocated inode 85450808 has 0 link count allocated inode 85450809 has 0 link count I have not run xfs_repair. If anyone need ssh access to the box just drop me a message. Metadump available at: http://80.204.235.230/metadump.bin.bz2 and xfs_check verbose: http://80.204.235.230/xfs_check_log.bz2 Linux Venus 2.6.26-rc6 #1 SMP PREEMPT Fri Jun 13 13:01:19 CEST 2008 i686 Intel(R ) Core(TM)2 Duo CPU T8100 @ 2.10GHz GenuineIntel GNU/Linux Gnu C 4.2.3 Gnu make 3.81 binutils 2.17.50.0.17.20070615 util-linux 2.13.1 mount 2.13.1 module-init-tools 3.4 e2fsprogs 1.40.8 xfsprogs 2.9.7 pcmciautils 014 PPP 2.4.4 Linux C Library 2.7 Dynamic linker (ldd) 2.7 Linux C++ Library 6.0.9 Procps 3.2.7 Net-tools 1.60 Kbd 1.12 oprofile 0.9.2 Sh-utils 6.9 Modules Loaded ext2 snd_seq_oss snd_seq_device snd_seq_midi_event snd_se q snd_pcm_oss snd_mixer_oss snd_hda_intel snd_pcm snd_timer snd soundcore snd_pa ge_alloc pcmcia crc32 yenta_socket rsrc_nonstatic pcmcia_core battery ac ppp_syn ctty ppp_deflate zlib_deflate zlib_inflate ppp_async crc_ccitt bsd_comp ppp_gene ric slhc intel_agp ohci_hcd option usbserial usbcore tg3 psmouse # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc6 # Fri Jun 13 13:13:53 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y # CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_CLASSIC_RCU=y # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CPU=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_P6_NOP=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_FAMILY=6 CONFIG_X86_DEBUGCTLMSR=y CONFIG_HPET_TIMER=y CONFIG_DMI=y # CONFIG_IOMMU_HELPER is not set CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y # CONFIG_PREEMPT_RCU is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_X86_PAT is not set # CONFIG_EFI is not set # CONFIG_IRQBALANCE is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_SCHED_HRTICK is not set # CONFIG_KEXEC is not set CONFIG_PHYSICAL_START=0x100000 CONFIG_PHYSICAL_ALIGN=0x200000 # CONFIG_COMPAT_VDSO is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SUSPEND is not set # CONFIG_HIBERNATION is not set CONFIG_ACPI=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y # CONFIG_ACPI_SYSFS_POWER is not set # CONFIG_ACPI_PROC_EVENT is not set CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_SBS=m # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # CONFIG_CPU_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set # CONFIG_PCI_GOOLPC is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY is not set # CONFIG_HT_IRQ is not set CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # CONFIG_OLPC is not set CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m # CONFIG_PCMCIA_IOCTL is not set CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m CONFIG_I82092=m CONFIG_PCCARD_NONSTATIC=m # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_NET_KEY=m CONFIG_INET=y # CONFIG_IP_MULTICAST is not set CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m # # IP: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV4=m # CONFIG_NF_CONNTRACK_PROC_COMPAT is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_UDPLITE=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # # CONFIG_NET_SCH_CBQ is not set CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RR=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m # CONFIG_NET_CLS_RSVP6 is not set CONFIG_NET_CLS_FLOW=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m # CONFIG_NET_ACT_SIMP is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_SCH_FIFO=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_FIB_RULES=y # # Wireless # # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT is not set # CONFIG_MAC80211 is not set # CONFIG_IEEE80211 is not set # CONFIG_RFKILL is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y # CONFIG_PREVENT_FIRMWARE_BUILD is not set # CONFIG_FW_LOADER is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y CONFIG_IDE=m # CONFIG_BLK_DEV_IDE is not set # CONFIG_BLK_DEV_HD_ONLY is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_LOWLEVEL is not set # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y # CONFIG_SATA_PMP is not set CONFIG_SATA_AHCI=y # CONFIG_SATA_SIL24 is not set CONFIG_ATA_SFF=y # CONFIG_SATA_SVW is not set CONFIG_ATA_PIIX=y # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set # CONFIG_PATA_ACPI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_PCMCIA is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_SCH is not set # CONFIG_MD is not set # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # # An alternative FireWire stack is available with EXPERIMENTAL=y # # CONFIG_IEEE1394 is not set # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set CONFIG_IFB=m CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m # CONFIG_VETH is not set # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set # CONFIG_NET_ETHERNET is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_E1000E is not set # CONFIG_E1000E_ENABLED is not set # CONFIG_IGB is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=m CONFIG_BNX2=m # CONFIG_QLA3XXX is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # CONFIG_IWLWIFI_LEDS is not set # # USB Network Adapters # # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_USBNET is not set # CONFIG_NET_PCMCIA is not set # CONFIG_WAN is not set # CONFIG_FDDI is not set CONFIG_PPP=m CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m # CONFIG_SLIP is not set CONFIG_SLHC=m # CONFIG_NET_FC is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_WISTRON_BTNS is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_UINPUT is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_DEVKMEM is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # # CONFIG_SERIAL_8250 is not set CONFIG_FIX_EARLYCON_MEM=y # # Non-8250 serial port support # # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_HW_RANDOM is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_GEN_RTC is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_IPWIRELESS is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set CONFIG_DEVPORT=y # CONFIG_I2C is not set # CONFIG_SPI is not set # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set CONFIG_THERMAL=m # CONFIG_WATCHDOG is not set # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # # Multimedia devices # # # Multimedia core support # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_VIDEO_MEDIA is not set # # Multimedia drivers # # CONFIG_DAB is not set # # Graphics support # CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_I915=m # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set # CONFIG_FB is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set # CONFIG_VIDEO_SELECT is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_DYNAMIC_MINORS is not set # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # PCI devices # # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AW2 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_OXYGEN is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5530 is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set # CONFIG_SND_HDA_CODEC_REALTEK is not set CONFIG_SND_HDA_CODEC_ANALOG=y # CONFIG_SND_HDA_CODEC_SIGMATEL is not set # CONFIG_SND_HDA_CODEC_VIA is not set # CONFIG_SND_HDA_CODEC_ATIHDMI is not set # CONFIG_SND_HDA_CODEC_CONEXANT is not set # CONFIG_SND_HDA_CODEC_CMEDIA is not set # CONFIG_SND_HDA_CODEC_SI3054 is not set CONFIG_SND_HDA_GENERIC=y # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_HIFIER is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SIS7019 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VIRTUOSO is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # CONFIG_SND_USB_CAIAQ is not set # # PCMCIA devices # # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_PDAUDIOCF is not set # # System on Chip audio support # # CONFIG_SND_SOC is not set # # ALSA SoC audio for Freescale SOCs # # # SoC Audio for the Texas Instruments OMAP # # # Open Sound System # # CONFIG_SOUND_PRIME is not set CONFIG_HID_SUPPORT=y CONFIG_HID=m # CONFIG_HID_DEBUG is not set # CONFIG_HIDRAW is not set # # USB Input Devices # CONFIG_USB_HID=m # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_ISP116X_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # CONFIG_USB_ACM=m # CONFIG_USB_PRINTER is not set # CONFIG_USB_WDM is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_MON is not set # # USB port drivers # CONFIG_USB_SERIAL=m # CONFIG_USB_EZUSB is not set # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_AIRCABLE is not set CONFIG_USB_SERIAL_AIRPRIME=m # CONFIG_USB_SERIAL_ARK3116 is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_CH341 is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_CP2101 is not set # CONFIG_USB_SERIAL_CYPRESS_M8 is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_FUNSOFT is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_GARMIN is not set # CONFIG_USB_SERIAL_IPW is not set # CONFIG_USB_SERIAL_IUU is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_MOS7720 is not set # CONFIG_USB_SERIAL_MOS7840 is not set # CONFIG_USB_SERIAL_MOTOROLA is not set # CONFIG_USB_SERIAL_NAVMAN is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_OTI6858 is not set # CONFIG_USB_SERIAL_SPCP8X5 is not set # CONFIG_USB_SERIAL_HP4X is not set # CONFIG_USB_SERIAL_SAFE is not set CONFIG_USB_SERIAL_SIERRAWIRELESS=m # CONFIG_USB_SERIAL_TI is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set CONFIG_USB_SERIAL_OPTION=m # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_SERIAL_DEBUG is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_GADGET is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set # CONFIG_RTC_CLASS is not set # CONFIG_DMADEVICES is not set # CONFIG_UIO is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_DMIID is not set # CONFIG_ISCSI_IBFT_FIND is not set # # File systems # CONFIG_EXT2_FS=m # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set # CONFIG_EXT3_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=y # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_XFS_RT is not set # CONFIG_OCFS2_FS is not set # CONFIG_DNOTIFY is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set CONFIG_FUSE_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m # CONFIG_MSDOS_FS is not set CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y # CONFIG_PROC_KCORE is not set CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y # CONFIG_TMPFS is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_HFSPLUS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m # CONFIG_SMB_FS is not set CONFIG_CIFS=m CONFIG_CIFS_STATS=y CONFIG_CIFS_STATS2=y CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=m CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FRAME_WARN=1024 # CONFIG_MAGIC_SYSRQ is not set # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_KERNEL is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_LATENCYTOP is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_NONPROMISC_DEVMEM is not set CONFIG_EARLY_PRINTK=y # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=m CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=m CONFIG_CRYPTO_MANAGER=m # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_AUTHENC=m # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=m # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set # CONFIG_CRYPTO_ECB is not set # CONFIG_CRYPTO_PCBC is not set # # Hash modes # CONFIG_CRYPTO_HMAC=m # # Digest # # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=m # CONFIG_CRYPTO_MICHAEL_MIC is not set CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set CONFIG_CRYPTO_BLOWFISH=m # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_DES=m # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SEED is not set CONFIG_CRYPTO_SERPENT=m # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TWOFISH is not set CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_586=m # # Compression # CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_LZO=m # CONFIG_CRYPTO_HW is not set CONFIG_HAVE_KVM=y # CONFIG_VIRTUALIZATION is not set # # Library routines # CONFIG_BITREVERSE=m CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_CRC_CCITT=m # CONFIG_CRC16 is not set CONFIG_CRC_ITU_T=m CONFIG_CRC32=m # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_LZO_COMPRESS=m CONFIG_LZO_DECOMPRESS=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y From owner-xfs@oss.sgi.com Mon Jun 16 03:00:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 03:00:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GA0RhP011056 for ; Mon, 16 Jun 2008 03:00:28 -0700 X-ASG-Debug-ID: 1213610485-48dc03e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DE520122E66E for ; Mon, 16 Jun 2008 03:01:25 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id ONKgY6BlPxr9QMLp for ; Mon, 16 Jun 2008 03:01:25 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K8BWc-0002ib-S2; Mon, 16 Jun 2008 10:01:22 +0000 Date: Mon, 16 Jun 2008 06:01:22 -0400 From: Christoph Hellwig To: Eric Sandeen , Oliver Pinter , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Message-ID: <20080616100122.GA1360@infradead.org> References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <20080616045221.GJ3700@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080616045221.GJ3700@disturbed> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213610485 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53442 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16375 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 16, 2008 at 02:52:21PM +1000, Dave Chinner wrote: > > is the first event of interest, it is hitting an assertion on the > > remount path: > > > > ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); > > > > in xfs_attr_quiesce. > > That's caused by a race condition in the VFS w.r.t setting the MS_RDONLY > flag. It should be fixed in 2.6.26. I was claiming it would be fixed in 2.6.26 but unfortunately the part of the the per-mount r/o patches that fixes various bits in remount isn't there yet. From owner-xfs@oss.sgi.com Mon Jun 16 03:13:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 03:13:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GADOEZ012030 for ; Mon, 16 Jun 2008 03:13:25 -0700 X-ASG-Debug-ID: 1213611260-7e0a00fe0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 46702CC1E1E for ; Mon, 16 Jun 2008 03:14:21 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id gJsPylyidb6Y5vx5 for ; Mon, 16 Jun 2008 03:14:21 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5GAECNW017988 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2008 12:14:12 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5GAECGt017986 for xfs@oss.sgi.com; Mon, 16 Jun 2008 12:14:12 +0200 Date: Mon, 16 Jun 2008 12:14:12 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] kill INDUCE_IO_ERROR Subject: Re: [PATCH] kill INDUCE_IO_ERROR Message-ID: <20080616101412.GA17939@lst.de> References: <20080523062323.GA32637@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080523062323.GA32637@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213611262 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53452 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16376 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, May 23, 2008 at 08:23:23AM +0200, Christoph Hellwig wrote: > All the error injection is already enabled through ifdef DEBUG, so kill > the never set second cpp symbol to activate it without the rest of the > debugging infrastructure. Can I get a review on this absolutely trivial patch? > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_error.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_error.c 2008-05-22 18:55:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_error.c 2008-05-22 18:55:16.000000000 +0200 > @@ -58,9 +58,6 @@ xfs_error_trap(int e) > } > return e; > } > -#endif > - > -#if (defined(DEBUG) || defined(INDUCE_IO_ERROR)) > > int xfs_etest[XFS_NUM_INJECT_ERROR]; > int64_t xfs_etest_fsid[XFS_NUM_INJECT_ERROR]; > @@ -154,7 +151,7 @@ xfs_errortag_clearall(xfs_mount_t *mp, i > > return 0; > } > -#endif /* DEBUG || INDUCE_IO_ERROR */ > +#endif /* DEBUG */ > > static void > xfs_fs_vcmn_err(int level, xfs_mount_t *mp, char *fmt, va_list ap) > Index: linux-2.6-xfs/fs/xfs/xfs_error.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_error.h 2008-05-22 18:55:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_error.h 2008-05-22 18:55:16.000000000 +0200 > @@ -125,22 +125,14 @@ extern void xfs_corruption_error(char *t > #define XFS_RANDOM_DIOWRITE_IOERR (XFS_RANDOM_DEFAULT/10) > #define XFS_RANDOM_BMAPIFORMAT XFS_RANDOM_DEFAULT > > -#if (defined(DEBUG) || defined(INDUCE_IO_ERROR)) > +#ifdef DEBUG > extern int xfs_error_test(int, int *, char *, int, char *, unsigned long); > > #define XFS_NUM_INJECT_ERROR 10 > - > -#ifdef __ANSI_CPP__ > -#define XFS_TEST_ERROR(expr, mp, tag, rf) \ > - ((expr) || \ > - xfs_error_test((tag), (mp)->m_fixedfsid, #expr, __LINE__, __FILE__, \ > - (rf))) > -#else > #define XFS_TEST_ERROR(expr, mp, tag, rf) \ > ((expr) || \ > xfs_error_test((tag), (mp)->m_fixedfsid, "expr", __LINE__, __FILE__, \ > (rf))) > -#endif /* __ANSI_CPP__ */ > > extern int xfs_errortag_add(int error_tag, xfs_mount_t *mp); > extern int xfs_errortag_clearall(xfs_mount_t *mp, int loud); > @@ -148,7 +140,7 @@ extern int xfs_errortag_clearall(xfs_mou > #define XFS_TEST_ERROR(expr, mp, tag, rf) (expr) > #define xfs_errortag_add(tag, mp) (ENOSYS) > #define xfs_errortag_clearall(mp, loud) (ENOSYS) > -#endif /* (DEBUG || INDUCE_IO_ERROR) */ > +#endif /* DEBUG */ > > /* > * XFS panic tags -- allow a call to xfs_cmn_err() be turned into > Index: linux-2.6-xfs/fs/xfs/xfs_mount.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2008-05-22 18:55:05.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2008-05-23 08:11:46.000000000 +0200 > @@ -1322,7 +1322,7 @@ xfs_unmountfs(xfs_mount_t *mp) > if ((mp->m_flags & XFS_MOUNT_NOUUID) == 0) > uuid_table_remove(&mp->m_sb.sb_uuid); > > -#if defined(DEBUG) || defined(INDUCE_IO_ERROR) > +#if defined(DEBUG) > xfs_errortag_clearall(mp, 0); > #endif > xfs_mount_free(mp); ---end quoted text--- From owner-xfs@oss.sgi.com Mon Jun 16 08:49:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 08:49:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GFnKGD014531 for ; Mon, 16 Jun 2008 08:49:21 -0700 X-ASG-Debug-ID: 1213631416-6ea0009d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-vbr11.xs4all.nl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1954017CAE3C; Mon, 16 Jun 2008 08:50:17 -0700 (PDT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by cuda.sgi.com with ESMTP id ooqLaCyfech8VB4i; Mon, 16 Jun 2008 08:50:17 -0700 (PDT) Received: from [194.109.0.112] (n2o.xs4all.nl [194.109.0.112]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id m5GFo6sO048733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 17:50:08 +0200 (CEST) (envelope-from mikevs@xs4all.net) X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c From: Miquel van Smoorenburg To: Dave Chinner Cc: Oliver Pinter , lists@ku-gbr.de, linux-kernel@vger.kernel.org, Christoph Hellwig , xfs@oss.sgi.com, xfs-masters@oss.sgi.com, mikevs@xs4all.net In-Reply-To: <1213356518.8530.5.camel@n2o.xs4all.nl> References: <20080612123031.21594jyk6rjc1lfk@imp.ku-gbr.de> <6101e8c40806120733m3c8647ccy149eb237e2c6d027@mail.gmail.com> <1213309629.29745.8.camel@localhost.localdomain> <20080613030841.GC3700@disturbed> <1213356518.8530.5.camel@n2o.xs4all.nl> Content-Type: text/plain Organization: XS4ALL Internet B.V. Date: Mon, 16 Jun 2008 17:50:06 +0200 Message-Id: <1213631406.19372.15.camel@n2o.xs4all.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by XS4ALL Virus Scanner X-Barracuda-Connect: smtp-vbr11.xs4all.nl[194.109.24.31] X-Barracuda-Start-Time: 1213631418 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53471 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16377 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikevs@xs4all.net Precedence: bulk X-list: xfs On Fri, 2008-06-13 at 13:28 +0200, Miquel van Smoorenburg wrote: > On Fri, 2008-06-13 at 13:08 +1000, Dave Chinner wrote: > > On Fri, Jun 13, 2008 at 12:27:09AM +0200, Miquel van Smoorenburg wrote: > > > > Linux transit5.news.xs4all.nl 2.6.25.6 #1 SMP Wed Jun 11 10:59:10 CEST > > > 2008 x86_64 GNU/Linux > > > > > > Filesystem "sda4": XFS internal error xfs_trans_cancel at line 1163 of > > > file fs/xfs/xfs_trans.c. Caller 0xffffffff880f1315 > > > Pid: 3402, comm: diablo Not tainted 2.6.25.6 #1 > > > > This commit in 2.6.26 will probably fix it. > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=75de2a91c98a6f486f261c1367fe59f5583e15a3 > > "At ENOSPC, we can get a filesystem shutdown due to a cancelling a dirty > transaction in xfs_mkdir or xfs_create." > > But The filesystem is only used for 35%. It might have hit 100% somewhere in > the recent past though (a few reboots ago). > I've applied the patch to 2.6.25.6 just in case, I'll let it run over > the weekend to see what happens. Well, the box has been up for 3 days now. When this problem first appeared it only stayed up for a day max, so I'm reasonably positive it's fixed. The patch applies cleanly to 2.6.25.6 - perhaps it should go into -stable. Thanks, Mike. From owner-xfs@oss.sgi.com Mon Jun 16 10:09:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 10:09:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GH9RcM019787 for ; Mon, 16 Jun 2008 10:09:28 -0700 X-ASG-Debug-ID: 1213636224-240e00420000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BAF7C239DBA for ; Mon, 16 Jun 2008 10:10:24 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id qcLAOuRWQcdzQNZN for ; Mon, 16 Jun 2008 10:10:24 -0700 (PDT) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m5GHA08Z017894 for ; Mon, 16 Jun 2008 10:10:00 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m5GHA02H014936 for ; Mon, 16 Jun 2008 10:10:00 -0700 Received: from dchinner-64.agami.com ([10.123.4.83]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 10:10:23 -0700 From: Dave Chinner To: lachlan@sgi.com X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Date: Mon, 16 Jun 2008 10:10:22 -0700 User-Agent: KMail/1.8.2 Cc: xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> In-Reply-To: <485603FD.2080204@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806161010.22476.dchinner@agami.com> X-OriginalArrivalTime: 16 Jun 2008 17:10:23.0211 (UTC) FILETIME=[DCF45BB0:01C8CFD3] X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1213636224 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_GENERIC_NO_PTR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53476 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_GENERIC_NO_PTR Delivered to trusted network by host with generic-looking RDNS - indicates no PTR record X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16378 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: > Dave Chinner wrote: > > On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: > >> When at ENOSPC conditions extent btree block allocations can fail and we > >> have no error handling to undo partial btree operations. Prior to extent > >> btree operations we reserve enough disk blocks somewhere in the filesystem > >> to satisfy the operation but in some conditions we require the blocks to > >> come from specific AGs and if those AGs are full the allocation fails. > >> > >> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), > >> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs > >> for the space needed. Since we have reserved the space these allocations > >> are now guaranteed to succeed. > > > > Sure, but we didn't reserve space for potential btree splits in a > > second AG as a result of this. That needs to be reserved in the > > transaction as well, which will blow out transaction reservations > > substantially as we'll need to add another 2 full AGF btree splits to > > every transaction that modifies the bmap btree. > > Right. And most of the time we wont need the space either so it's a > real waste. Waste, yes, but still needed otherwise transaction overruns and log space deadlocks could occur.... > >> In order to search all AGs I had to revert > >> a change made to xfs_alloc_vextent() that prevented a search from looking > >> at AGs lower than the starting AG. This original change was made to prevent > >> out of order AG locking when allocating multiple extents on data writeout > >> but since we only allocate one extent at a time now this particular problem > >> can't happen. > > > > You missed the fact that the AGF of modified AGs is already held > > locked in the transaction, hence the locking order within the > > transaction is wrong. Also, if we modify the free list in an AG > > the fail an allocation (e.g. can't do an exact allocation), we'll > > have multiple dirty and locked AGFs in the one allocation. Hence > > we still can have locking order violations if you remove that check > > and therefore deadlocks. > > I'm well aware of that particular deadlock involving the freelist - I > hit it while testing. If you look closely at the code that deadlock > can occur with or without the AG locking avoidance logic. This is > because the rest of the transaction is unaware that an AG has been > locked due to a freelist operation. Yes, which is why you need to prevent freelist modifications occurring when you can't allocate anything out of the AG. > > This is not the solution to the problem. As I suggested (back when > > you first floated this idea as a fix for the problem several weeks > > ago) I think the bug is that we are not taking into account the > > number of blocks required for a bmbt split when selecting an AG to > > allocate from. All we take into account is the blocks required for > > the extent to be allocated and nothing else. If we take the blocks > > for a bmbt split into account then we'll never try to allocate an > > extent in an AG that we can't also allocate all the blocks for the > > bmbt split in at the same time. > > I considered that approach (using the minleft field in xfs_alloc_arg_t) > but it has it's problems too. When we reserve space for the btree > operations it is done on the global filesystem counters, not a > particular AG, so there is the possibility that not one AG has sufficent > space to perform the allocation even though there is enough free space > in the whole filesystem. Yes, we had that problem with the ENOSPC deadlock fixes in that we always needed at least 4 blocks per AG available for a extent free to succeed. Hence we have the XFS_ALLOC_SET_ASIDE() value for determining if the filesystem is out of space, not a count of zero free blocks. In this case, this macro can be extended to guarantee that our aggregate block usage never goes below the threshold that would prevent each AG from holding enough blocks for a worst case allocation to succeed..... > Of course if we have enough space left in one > AG and the AG is locked then the space we reserved doesn't matter anymore > and it should all work. Yes. > I'm worried with this approach that we could have delayed allocations and > unwritten extents that need to be converted but we can't do it because we > don't have the space we might need (but probably don't). Delayed allocation is the issue - unwritten extent conversion failure will simply return an error and leave the extent unwritten. With delayed allocation, we can oversubscribe a given AG but we can always try a different AG. If we get to the situation that we don't have enough space in any AG then we are screwed. However, by ensuring we can sustain a worst-case split within any AG we can avoid this situation completely. Cheers, Dave. From owner-xfs@oss.sgi.com Mon Jun 16 10:13:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 10:13:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GHD8nd020313 for ; Mon, 16 Jun 2008 10:13:08 -0700 X-ASG-Debug-ID: 1213636445-7f8c02ae0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7A10BCC72AE for ; Mon, 16 Jun 2008 10:14:05 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id sO79sz6ONKwvwmPh for ; Mon, 16 Jun 2008 10:14:05 -0700 (PDT) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m5GHDg8Z018049 for ; Mon, 16 Jun 2008 10:13:42 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m5GHDgrb015226 for ; Mon, 16 Jun 2008 10:13:42 -0700 Received: from dchinner-64.agami.com ([10.123.4.83]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 10:14:05 -0700 From: Dave Chinner To: lachlan@sgi.com X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert Date: Mon, 16 Jun 2008 10:14:04 -0700 User-Agent: KMail/1.8.2 Cc: xfs-dev , xfs-oss References: <4855CE2D.70505@sgi.com> <20080616050150.GK3700@disturbed> <48560B0B.3060204@sgi.com> In-Reply-To: <48560B0B.3060204@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806161014.04407.dchinner@agami.com> X-OriginalArrivalTime: 16 Jun 2008 17:14:05.0322 (UTC) FILETIME=[6157CEA0:01C8CFD4] X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1213636446 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0472 1.0000 -1.7177 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.62 X-Barracuda-Spam-Status: No, SCORE=-1.62 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_GENERIC_NO_PTR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53467 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_GENERIC_NO_PTR Delivered to trusted network by host with generic-looking RDNS - indicates no PTR record X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16379 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Sunday 15 June 2008 11:41 pm, Lachlan McIlroy wrote: > Dave Chinner wrote: > > On Mon, Jun 16, 2008 at 12:21:33PM +1000, Lachlan McIlroy wrote: > >> After a btree insert operation a cursor can be invalid due to block > >> splits and a maybe a new root block. We reset the cursor in > >> xfs_bmbt_insert() in the cases where we think we need to but it > >> isn't enough as we still see assertions. Just do what we do elsewhere > >> and reset the cursor unconditionally. > > > > Ok, so you should also kill the new code in the btree insert that > > revalidates the btree cursor. IIRC, this was the only place it was > > needed for.... > > That was the plan. Cool. Please include it in the next version of the patch. > >> + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, > >> + new->br_startblock, new->br_blockcount, > >> + &i))) > >> goto done; > > > > > > error = xfs_bmbt_lookup_eq(cur, new->br_startoff, > > br_startblock, new->br_blockcount, &i); > > if (error) > > goto done; > > > >> - ASSERT(i == 1); > >> + ASSERT(i == 0); > > > > ASSERT? How about a WANT_CORRUPTED_GOTO()? > > I was just being consistent with the rest of the code. If you think this > ASSERT should be changed then what about all of them? Well, the ASSERT means silent failure on a production system. Given that failure here indicates a corrupt btree, then we really should be treating it as such. i.e. shut down the filesystem. This might have saved us a whole heap of trouble tracking down these problems as a shutdown here would have pointed us right at the source of the problem... Cheers, Dave. From owner-xfs@oss.sgi.com Mon Jun 16 10:14:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 10:14:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GHEF9m020730 for ; Mon, 16 Jun 2008 10:14:15 -0700 X-ASG-Debug-ID: 1213636513-2581003c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D7130239F0F for ; Mon, 16 Jun 2008 10:15:13 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id mUvCeC4VRAxsGXmp for ; Mon, 16 Jun 2008 10:15:13 -0700 (PDT) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m5GHEo8Z018114 for ; Mon, 16 Jun 2008 10:14:50 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m5GHEone015257 for ; Mon, 16 Jun 2008 10:14:50 -0700 Received: from dchinner-64.agami.com ([10.123.4.83]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 10:15:13 -0700 From: Dave Chinner To: Christoph Hellwig X-ASG-Orig-Subj: Re: [PATCH] kill XFS_PURGE_INODE Subject: Re: [PATCH] kill XFS_PURGE_INODE Date: Mon, 16 Jun 2008 10:15:12 -0700 User-Agent: KMail/1.8.2 Cc: xfs@oss.sgi.com References: <20080616062634.GA5971@lst.de> In-Reply-To: <20080616062634.GA5971@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806161015.12363.dchinner@agami.com> X-OriginalArrivalTime: 16 Jun 2008 17:15:13.0057 (UTC) FILETIME=[89B75910:01C8CFD4] X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1213636513 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2034 1.0000 -0.8098 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.71 X-Barracuda-Spam-Status: No, SCORE=-0.71 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_GENERIC_NO_PTR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53476 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_GENERIC_NO_PTR Delivered to trusted network by host with generic-looking RDNS - indicates no PTR record X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16380 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Sunday 15 June 2008 11:26 pm, Christoph Hellwig wrote: > Just a useless alias for IRELE. Looks sane. Cheers, Dave. From owner-xfs@oss.sgi.com Mon Jun 16 18:20:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 18:20:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H1K3SL028564 for ; Mon, 16 Jun 2008 18:20:04 -0700 X-ASG-Debug-ID: 1213665658-2e7901190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id B310417CEB76 for ; Mon, 16 Jun 2008 18:20:59 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id 3VShDinxdeHJh20o for ; Mon, 16 Jun 2008 18:20:59 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08519; Tue, 17 Jun 2008 11:20:48 +1000 Message-ID: <48571241.20806@sgi.com> Date: Tue, 17 Jun 2008 11:24:17 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Dave Chinner CC: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert References: <4855CE2D.70505@sgi.com> <20080616050150.GK3700@disturbed> <48560B0B.3060204@sgi.com> <200806161014.04407.dchinner@agami.com> In-Reply-To: <200806161014.04407.dchinner@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213665661 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0206 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53511 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16381 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Sunday 15 June 2008 11:41 pm, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Mon, Jun 16, 2008 at 12:21:33PM +1000, Lachlan McIlroy wrote: >>>> After a btree insert operation a cursor can be invalid due to block >>>> splits and a maybe a new root block. We reset the cursor in >>>> xfs_bmbt_insert() in the cases where we think we need to but it >>>> isn't enough as we still see assertions. Just do what we do elsewhere >>>> and reset the cursor unconditionally. >>> Ok, so you should also kill the new code in the btree insert that >>> revalidates the btree cursor. IIRC, this was the only place it was >>> needed for.... >> That was the plan. > > Cool. Please include it in the next version of the patch. > >>>> + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, >>>> + new->br_startblock, new->br_blockcount, >>>> + &i))) >>>> goto done; >>> >>> error = xfs_bmbt_lookup_eq(cur, new->br_startoff, >>> br_startblock, new->br_blockcount, &i); >>> if (error) >>> goto done; >>> >>>> - ASSERT(i == 1); >>>> + ASSERT(i == 0); >>> ASSERT? How about a WANT_CORRUPTED_GOTO()? >> I was just being consistent with the rest of the code. If you think this >> ASSERT should be changed then what about all of them? > > Well, the ASSERT means silent failure on a production system. > Given that failure here indicates a corrupt btree, then we really > should be treating it as such. i.e. shut down the filesystem. This > might have saved us a whole heap of trouble tracking down these > problems as a shutdown here would have pointed us right at the > source of the problem... > Dave, what I was asking is what about the rest of the ASSERTs in this file - should we change them too? There's a lot of them. After this change they are all equally likely to trigger so if it makes sense to change one then the same argument applies to all of them. From owner-xfs@oss.sgi.com Mon Jun 16 18:54:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 18:54:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H1sYI5030352 for ; Mon, 16 Jun 2008 18:54:34 -0700 X-ASG-Debug-ID: 1213667726-4fa000220000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 4AA8523A0AD for ; Mon, 16 Jun 2008 18:55:26 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id zRmCF7qjQa3RX3xt for ; Mon, 16 Jun 2008 18:55:26 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09126; Tue, 17 Jun 2008 11:55:18 +1000 Message-ID: <48571A57.5090901@sgi.com> Date: Tue, 17 Jun 2008 11:58:47 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Dave Chinner CC: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> In-Reply-To: <200806161010.22476.dchinner@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213667732 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53513 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16382 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: >>>> When at ENOSPC conditions extent btree block allocations can fail and we >>>> have no error handling to undo partial btree operations. Prior to extent >>>> btree operations we reserve enough disk blocks somewhere in the filesystem >>>> to satisfy the operation but in some conditions we require the blocks to >>>> come from specific AGs and if those AGs are full the allocation fails. >>>> >>>> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), >>>> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs >>>> for the space needed. Since we have reserved the space these allocations >>>> are now guaranteed to succeed. >>> Sure, but we didn't reserve space for potential btree splits in a >>> second AG as a result of this. That needs to be reserved in the >>> transaction as well, which will blow out transaction reservations >>> substantially as we'll need to add another 2 full AGF btree splits to >>> every transaction that modifies the bmap btree. >> Right. And most of the time we wont need the space either so it's a >> real waste. > > Waste, yes, but still needed otherwise transaction overruns and log space > deadlocks could occur.... > >>>> In order to search all AGs I had to revert >>>> a change made to xfs_alloc_vextent() that prevented a search from looking >>>> at AGs lower than the starting AG. This original change was made to prevent >>>> out of order AG locking when allocating multiple extents on data writeout >>>> but since we only allocate one extent at a time now this particular problem >>>> can't happen. >>> You missed the fact that the AGF of modified AGs is already held >>> locked in the transaction, hence the locking order within the >>> transaction is wrong. Also, if we modify the free list in an AG >>> the fail an allocation (e.g. can't do an exact allocation), we'll >>> have multiple dirty and locked AGFs in the one allocation. Hence >>> we still can have locking order violations if you remove that check >>> and therefore deadlocks. >> I'm well aware of that particular deadlock involving the freelist - I >> hit it while testing. If you look closely at the code that deadlock >> can occur with or without the AG locking avoidance logic. This is >> because the rest of the transaction is unaware that an AG has been >> locked due to a freelist operation. > > Yes, which is why you need to prevent freelist modifications occurring > when you can't allocate anything out of the AG. That sounds reasonable but it isn't consistent with the deadlock I saw. One of the threads that was deadlocked had tried to allocate a data extent in AG3 but didn't find the space. It had modified, and hence locked, AG3 due to modifying the freelist but since it didn't get the space it needed it had to go on to another AG. So before we even allocated the data extent (and before we tried to modify the btree, etc) we had an AG locked. The deadlock avoidance code in xfs_alloc_vextent() didn't know this because it only checks for a previous allocation. It makes sense that we should avoid modifying the freelist if there isn't enough space for the allocation so the puzzle is why didn't the code do that? > >>> This is not the solution to the problem. As I suggested (back when >>> you first floated this idea as a fix for the problem several weeks >>> ago) I think the bug is that we are not taking into account the >>> number of blocks required for a bmbt split when selecting an AG to >>> allocate from. All we take into account is the blocks required for >>> the extent to be allocated and nothing else. If we take the blocks >>> for a bmbt split into account then we'll never try to allocate an >>> extent in an AG that we can't also allocate all the blocks for the >>> bmbt split in at the same time. >> I considered that approach (using the minleft field in xfs_alloc_arg_t) >> but it has it's problems too. When we reserve space for the btree >> operations it is done on the global filesystem counters, not a >> particular AG, so there is the possibility that not one AG has sufficent >> space to perform the allocation even though there is enough free space >> in the whole filesystem. > > Yes, we had that problem with the ENOSPC deadlock fixes in that we always > needed at least 4 blocks per AG available for a extent free to succeed. > Hence we have the XFS_ALLOC_SET_ASIDE() value for determining if the > filesystem is out of space, not a count of zero free blocks. Those 4 blocks are for one extent free operation, right? What if we have multiple threads all trying to do the same thing (in the same AG)? > > In this case, this macro can be extended to guarantee that our aggregate > block usage never goes below the threshold that would prevent each AG from > holding enough blocks for a worst case allocation to succeed..... > >> Of course if we have enough space left in one >> AG and the AG is locked then the space we reserved doesn't matter anymore >> and it should all work. > > Yes. > >> I'm worried with this approach that we could have delayed allocations and >> unwritten extents that need to be converted but we can't do it because we >> don't have the space we might need (but probably don't). > > Delayed allocation is the issue - unwritten extent conversion failure will > simply return an error and leave the extent unwritten. That's still a problem though - if we can't convert unwritten extents then we can't clean dirty pages and we wont be able to unmount the filesystem. > > With delayed allocation, we can oversubscribe a given AG but we can > always try a different AG. If we get to the situation that we don't have > enough space in any AG then we are screwed. However, by ensuring we can > sustain a worst-case split within any AG we can avoid this situation > completely. > > Cheers, > > Dave. > From owner-xfs@oss.sgi.com Mon Jun 16 22:20:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 22:20:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H5Kish013730 for ; Mon, 16 Jun 2008 22:20:45 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id DC7DE30408C; Mon, 16 Jun 2008 22:21:38 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5H5LZjm2070622; Tue, 17 Jun 2008 15:21:36 +1000 (AEST) From: Niv Sardi To: lachlan@sgi.com Cc: xfs-dev , xfs-oss Subject: Re: [PATCH] Remove infinite loop from xfsidbg_xaildump References: <4856195F.9030809@sgi.com> Date: Tue, 17 Jun 2008 15:21:24 +1000 In-Reply-To: <4856195F.9030809@sgi.com> (Lachlan McIlroy's message of "Mon, 16 Jun 2008 17:42:23 +1000") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16383 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs looks good, -- Niv Sardi From owner-xfs@oss.sgi.com Mon Jun 16 22:42:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 22:42:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H5gigk015379 for ; Mon, 16 Jun 2008 22:42:44 -0700 X-ASG-Debug-ID: 1213681420-314b02f20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 54C2C23C906 for ; Mon, 16 Jun 2008 22:43:41 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id FtWaaEhkJqU2EC16 for ; Mon, 16 Jun 2008 22:43:41 -0700 (PDT) Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail04.adl2.internode.on.net with ESMTP; 17 Jun 2008 15:11:53 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K8TvV-00027X-Ob; Tue, 17 Jun 2008 15:40:17 +1000 Date: Tue, 17 Jun 2008 15:40:17 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: Dave Chinner , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert Message-ID: <20080617054017.GO3700@disturbed> Mail-Followup-To: Lachlan McIlroy , Dave Chinner , xfs-dev , xfs-oss References: <4855CE2D.70505@sgi.com> <20080616050150.GK3700@disturbed> <48560B0B.3060204@sgi.com> <200806161014.04407.dchinner@agami.com> <48571241.20806@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48571241.20806@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1213681422 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0204 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53524 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16384 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Tue, Jun 17, 2008 at 11:24:17AM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: >> On Sunday 15 June 2008 11:41 pm, Lachlan McIlroy wrote: >>>> ASSERT? How about a WANT_CORRUPTED_GOTO()? >>> I was just being consistent with the rest of the code. If you think this >>> ASSERT should be changed then what about all of them? >> >> Well, the ASSERT means silent failure on a production system. >> Given that failure here indicates a corrupt btree, then we really >> should be treating it as such. i.e. shut down the filesystem. This >> might have saved us a whole heap of trouble tracking down these >> problems as a shutdown here would have pointed us right at the >> source of the problem... > > Dave, what I was asking is what about the rest of the ASSERTs in > this file - should we change them too? There's a lot of them. > After this change they are all equally likely to trigger so if > it makes sense to change one then the same argument applies to > all of them. In the past we've only changed the bits of the code that have been needed for debugging problems. e.g. there's WANT_CORRUPTED throughout the alloc code, but only some bits of the bmbt code and almost none in the inobt. Really we should be consistent with our catching and handling of errors. IOWs, I'd say we probably should change them all, but it's going to touch lots of code. For the btree code, I'd say it should be done with the factoring (get them all in one go), but xfs_bmap.c code is separate and could be done separately. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 17 00:33:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 00:33:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H7X06r028418 for ; Tue, 17 Jun 2008 00:33:01 -0700 X-ASG-Debug-ID: 1213688038-60e702f60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34506.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id CAFEACD2914 for ; Tue, 17 Jun 2008 00:33:58 -0700 (PDT) Received: from web34506.mail.mud.yahoo.com (web34506.mail.mud.yahoo.com [66.163.178.172]) by cuda.sgi.com with SMTP id BMytHpoKSqocM4o8 for ; Tue, 17 Jun 2008 00:33:58 -0700 (PDT) Received: (qmail 19408 invoked by uid 60001); 17 Jun 2008 07:33:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=11bCm9abXFrwNb1K1xInDc2Ap6fhFIHyesRHe0Xsl7liayuykRpp7vtaPjWjbAc6bwjDMKUMl/wFyDZCsXCYUAQD+Qd6sBwQBbLm4moJYEbbvEOHF5RRh3G8mpyY08sqTeOOXbxaLlUWqM9fZ8rbwtYHY97E+9nF98+Wzt1iMwY=; Received: from [96.14.254.25] by web34506.mail.mud.yahoo.com via HTTP; Tue, 17 Jun 2008 00:33:57 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 17 Jun 2008 00:33:57 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: XFS mkfs/mount options Subject: XFS mkfs/mount options To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <881489.19090.qm@web34506.mail.mud.yahoo.com> X-Barracuda-Connect: web34506.mail.mud.yahoo.com[66.163.178.172] X-Barracuda-Start-Time: 1213688038 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53534 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16385 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs I have been doing some experiments with XFS on my "hot new desktop system," and I have turned up an interesting bit of info. (Note: My system is an AMD64 X2 2.5GHz running Linux.) When I mount an XFS volume (thus loading the xfs kernel module), the kernel spawns two CPU-bound threads for "xfslogd" and "xfsdatad". However, it appears that only one of each of these kernel processes is getting any load, as indicated by "ps ax": 3700 ? S< 0:00 [xfslogd/0] 3701 ? S< 0:19 [xfslogd/1] 3702 ? S< 0:00 [xfsdatad/0] 3703 ? D< 0:05 [xfsdatad/1] For each of these kernel threads, only those on CPU #2 are actually pulling notable load. Why is this? I understand that I may have overlooked some critical tidbit of info in the man pages, or perhaps I have not yet found something online that could explain a default limitation. If so, I would very much enjoy new information about using XFS on a desktop system. TYIA for your answer(s). -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Tue Jun 17 00:41:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 00:41:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H7fTsH029221 for ; Tue, 17 Jun 2008 00:41:30 -0700 X-ASG-Debug-ID: 1213688545-7480033d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6C18A17D8401 for ; Tue, 17 Jun 2008 00:42:26 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id q7fUAnvjSApHsb7F for ; Tue, 17 Jun 2008 00:42:26 -0700 (PDT) Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 17 Jun 2008 17:09:51 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K8VnB-0004VT-Vw; Tue, 17 Jun 2008 17:39:49 +1000 Date: Tue, 17 Jun 2008 17:39:49 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: Dave Chinner , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080617073949.GP3700@disturbed> Mail-Followup-To: Lachlan McIlroy , Dave Chinner , xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48571A57.5090901@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213688547 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53534 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16386 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Tue, Jun 17, 2008 at 11:58:47AM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: >> On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: >>> I'm well aware of that particular deadlock involving the freelist - I >>> hit it while testing. If you look closely at the code that deadlock >>> can occur with or without the AG locking avoidance logic. This is >>> because the rest of the transaction is unaware that an AG has been >>> locked due to a freelist operation. >> >> Yes, which is why you need to prevent freelist modifications occurring >> when you can't allocate anything out of the AG. > > That sounds reasonable but it isn't consistent with the deadlock I saw. > One of the threads that was deadlocked had tried to allocate a data extent > in AG3 but didn't find the space. It had modified, and hence locked, AG3 > due to modifying the freelist but since it didn't get the space it needed > it had to go on to another AG. That sounds like an exact allocation failure - there is enough space, a large enough extent but no free space at the exact block required. This is exactly the case that occurred with the inode allocation - and then allocation in the same AG failed because of alignment that wasn't taken into account by the first exact allocation attempt. Perhaps the minalignslop calculation in xfs_bmap_btalloc() is incorrect... > So before we even allocated the data extent > (and before we tried to modify the btree, etc) we had an AG locked. The > deadlock avoidance code in xfs_alloc_vextent() didn't know this because > it only checks for a previous allocation. It makes sense that we should > avoid modifying the freelist if there isn't enough space for the allocation > so the puzzle is why didn't the code do that? Good question, and I think that is one we need to answer. >>> I considered that approach (using the minleft field in xfs_alloc_arg_t) >>> but it has it's problems too. When we reserve space for the btree >>> operations it is done on the global filesystem counters, not a >>> particular AG, so there is the possibility that not one AG has sufficent >>> space to perform the allocation even though there is enough free space >>> in the whole filesystem. >> >> Yes, we had that problem with the ENOSPC deadlock fixes in that we always >> needed at least 4 blocks per AG available for a extent free to succeed. >> Hence we have the XFS_ALLOC_SET_ASIDE() value for determining if the >> filesystem is out of space, not a count of zero free blocks. > > Those 4 blocks are for one extent free operation, right? What if we have > multiple threads all trying to do the same thing (in the same AG)? If we have empty AGF btrees we need to allocate two new root blocks, and then we won't have to allocate any more btree blocks for the next 100+ extent free operations... For allocations, the first would succeed, the rest would have to search for another AG... >>> I'm worried with this approach that we could have delayed allocations and >>> unwritten extents that need to be converted but we can't do it because we >>> don't have the space we might need (but probably don't). >> >> Delayed allocation is the issue - unwritten extent conversion failure will >> simply return an error and leave the extent unwritten. > > That's still a problem though - if we can't convert unwritten extents then > we can't clean dirty pages and we wont be able to unmount the filesystem. There will be errors logged and the extents will remain unwritten. The filesystem should still be able to be unmounted. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 17 00:42:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 00:42:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H7gFee029377 for ; Tue, 17 Jun 2008 00:42:16 -0700 X-ASG-Debug-ID: 1213688590-748003490000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EFB4917D846B for ; Tue, 17 Jun 2008 00:43:11 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id JxDgt09AUHLegEWZ for ; Tue, 17 Jun 2008 00:43:11 -0700 (PDT) Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 17 Jun 2008 17:12:02 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K8VpG-0004Ye-4o; Tue, 17 Jun 2008 17:41:58 +1000 Date: Tue, 17 Jun 2008 17:41:58 +1000 From: Dave Chinner To: Mark Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options Message-ID: <20080617074158.GQ3700@disturbed> Mail-Followup-To: Mark , xfs@oss.sgi.com References: <881489.19090.qm@web34506.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <881489.19090.qm@web34506.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213688593 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4223 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53534 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16387 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Tue, Jun 17, 2008 at 12:33:57AM -0700, Mark wrote: > I have been doing some experiments with XFS on my "hot new desktop > system," and I have turned up an interesting bit of info. (Note: > My system is an AMD64 X2 2.5GHz running Linux.) > > When I mount an XFS volume (thus loading the xfs kernel module), > the kernel spawns two CPU-bound threads for "xfslogd" and > "xfsdatad". However, it appears that only one of each of these > kernel processes is getting any load, as indicated by "ps ax": > > 3700 ? S< 0:00 [xfslogd/0] > 3701 ? S< 0:19 [xfslogd/1] > 3702 ? S< 0:00 [xfsdatad/0] > 3703 ? D< 0:05 [xfsdatad/1] > > For each of these kernel threads, only those on CPU #2 are actually pulling notable load. Why is this? Because your disk interrupts are delivered to that CPU only. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 17 02:19:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 02:19:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H9JGZP003159 for ; Tue, 17 Jun 2008 02:19:17 -0700 X-ASG-Debug-ID: 1213694414-193c01f70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34501.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 0E05823D365 for ; Tue, 17 Jun 2008 02:20:14 -0700 (PDT) Received: from web34501.mail.mud.yahoo.com (web34501.mail.mud.yahoo.com [66.163.178.167]) by cuda.sgi.com with SMTP id PMHBnWPdZr5xk2r6 for ; Tue, 17 Jun 2008 02:20:14 -0700 (PDT) Received: (qmail 86430 invoked by uid 60001); 17 Jun 2008 09:20:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=TKPCWKe7G5eLA4FX+T+cVUF3xeqvWWnh9/X0DvVld/ML49yuii7Ug139Knr37OrSErk8ksfXu9DdaUzjKH1aUrzzzMzbIIldwXqeDD5Rsd6mQAJB+KpXg4cHynhCp5r7ygAZn6H3brsBoto2Iyx6PWMfhxZinrlrTbKv+GegkyI=; Received: from [96.14.203.219] by web34501.mail.mud.yahoo.com via HTTP; Tue, 17 Jun 2008 02:20:14 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 17 Jun 2008 02:20:14 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <153266.85236.qm@web34501.mail.mud.yahoo.com> X-Barracuda-Connect: web34501.mail.mud.yahoo.com[66.163.178.167] X-Barracuda-Start-Time: 1213694415 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53541 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16388 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs --- On Tue, 6/17/08, Dave Chinner wrote: > > For each of these kernel threads, only those on CPU #2 > are actually pulling notable load. Why is this? > > Because your disk interrupts are delivered to that CPU > only. Thank you! Tuning my IRQ delivery gave a noticeable speed-up. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Tue Jun 17 05:26:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 05:26:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5HCQnrD019247 for ; Tue, 17 Jun 2008 05:26:49 -0700 X-ASG-Debug-ID: 1213705666-5b6601100000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 612BF23DC9E for ; Tue, 17 Jun 2008 05:27:47 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id ydxWzOAcGQTnugUH for ; Tue, 17 Jun 2008 05:27:47 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id AB9242ED2D; Tue, 17 Jun 2008 08:27:46 -0400 (EDT) Date: Tue, 17 Jun 2008 08:27:46 -0400 (EDT) From: Justin Piszcz To: Mark cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options In-Reply-To: <153266.85236.qm@web34501.mail.mud.yahoo.com> Message-ID: References: <153266.85236.qm@web34501.mail.mud.yahoo.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1213705667 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53552 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16389 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs How did you tune your IRQ delivery? Justin. On Tue, 17 Jun 2008, Mark wrote: > --- On Tue, 6/17/08, Dave Chinner wrote: > >>> For each of these kernel threads, only those on CPU #2 >> are actually pulling notable load. Why is this? >> >> Because your disk interrupts are delivered to that CPU >> only. > > Thank you! Tuning my IRQ delivery gave a noticeable speed-up. > > -- > Mark > > "What better place to find oneself than > on the streets of one's home village?" > --Capt. Jean-Luc Picard, "Family" > > From owner-xfs@oss.sgi.com Tue Jun 17 07:04:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 07:04:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_50,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5HE4YWF025624 for ; Tue, 17 Jun 2008 07:04:35 -0700 X-ASG-Debug-ID: 1213711529-39fe00f40000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gw4.outgw.tn (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C562A17D95C2 for ; Tue, 17 Jun 2008 07:05:29 -0700 (PDT) Received: from gw4.outgw.tn (gw4.outgw.tn [193.95.97.184]) by cuda.sgi.com with ESMTP id vn8eo8Tw2nYf9U3D for ; Tue, 17 Jun 2008 07:05:29 -0700 (PDT) Received: from smtp.rnu.tn (smtp.rnu.tn [193.95.32.173]) by tounes-18.ati.tn (Postfix) with ESMTP id BFF78108810C for ; Tue, 17 Jun 2008 16:04:44 +0200 (CEST) Received: from localhost (rnu.tn [127.0.0.1]) by smtp.rnu.tn (Postfix) with ESMTP id B4F7DCB386 for ; Tue, 17 Jun 2008 15:42:17 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at rnu.tn Received: from smtp.rnu.tn ([127.0.0.1]) by localhost (smtp.rnu.tn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO-gmpYjIE9Y for ; Tue, 17 Jun 2008 15:42:17 +0200 (CEST) Received: from Khalil (unknown [41.229.115.3]) by smtp.rnu.tn (Postfix) with ESMTP id 2214DCB384 for ; Tue, 17 Jun 2008 15:42:17 +0200 (CEST) From: "E-MEDISYS 08" X-ASG-Orig-Subj: E-MEDISYS'08: Extended Paper submission deadline Subject: E-MEDISYS'08: Extended Paper submission deadline To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Date: Tue, 17 Jun 2008 16:07:43 +0200 Message-ID: <2008617.396160,672023472222222@enis.rnu.tn> X-Barracuda-Connect: gw4.outgw.tn[193.95.97.184] X-Barracuda-Start-Time: 1213711530 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5045 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.88 X-Barracuda-Spam-Status: No, SCORE=0.88 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, HTML_TAG_EXIST_TBODY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53557 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.13 HTML_TAG_EXIST_TBODY BODY: HTML has "tbody" tag 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 5607 X-archive-position: 16390 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: medsalim.bouhlel@enis.rnu.tn Precedence: bulk X-list: xfs =20 =20=20=20=20=20=20=20=20=20 Dear Colleagues=20 Apologies for any cross-postings=20 At the request of a number of potential contributors, the E-MEDISYS 2008 Or= ganizing Committee has decided to extend the deadline of paper submission t= o June 30th, 2008. The 2nd International Conference: E-Medical Systems E-MEDISYS 2008 is techn= ically co-sponsored by IEEE. It will be held from 29 to 31 October 2008 in = Sfax, Tunisia.=20 You can find more details in:=20 http://www.setit.rnu.tn/E-Medisys=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 The paper submission can be done on-line at=20 http://www.setit.rnu.tn/E-Medisys/submission=20 Your propositions are welcome (they can be made either in French or in Engl= ish).=20 Accepted Papers will be published in the Conference Proceedings, as a Book= Chapter with the ISBN: 978-9973-0-0124-5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TUNIS AIR, the Official carrier for the Conference, accords to the particip= ants and their accompaniers a reduction of 50% to the plane tickets.=20 We are waiting for seeing you in Tunisia in E-MEDISYS 2008.=20 Best Regards=20 Mohamed Salim BOUHLEL=20 General Co-Chair, E-MEDISYS 2008=20 Head of Research Unit: Sciences & Technologies of Image and Telecommunicati= ons=20 Higher Institute of Biotechnology of Sfax (Sfax University)=20 BP 261 3038 SFAX TUNISIA=20 GSM +216 20 200005=20 **********************************************************************=20 This email is sent out to all those on the E-MEDISYS 2008 database. If you = want to be removed from this database, please send an email to unsubscribe.= emedisys@gmail.com with subject Unsubscribe. ***************************************************************************= ** E-MEDISYS 2008 Second International Conference of E-Medical Systems Technically co-sponsored by IEEE=20 Sfax, Tunisia, October 29-31, 2008 http://www.setit.rnu.tn/E-medisys/ =20 =3D=3D E-MEDISYS 2008 PRESENTATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D E-Medisys is a new international conference, very innovative, on the topic = of the telemedicine. This conference was born out of collaboration of three teams of research di= vided between Sfax (Tunisia), Besan=E7on (France) and Fez (Morocco). E-Medisys, from its topic interdisciplinary, has the role to bring together= the researchers, and the industrialists, who are actors of the telemedicin= e as well from the medical point of view as from the data-processing point = of view. It is what makes a single event of it: the meeting of the actors who will = allow treating the telemedicine =93from beginning to end=94. This conferenc= e will be held in French and English. Papers will be selected by a mixed re= ading panel gathering of the specialists to re-elect in the field of the te= lemedicine. =3D=3D TOPICS=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The topics of this conference are voluntarily opened in order to support th= e participation of many teams (researchers, teachers, engineers, industrial= ists and students). A broad place will be reserved for the new ideas, with = not yet succeeded work, original work positioning clearly compared to what = exists. Here a non exhaustive list of the topics: Medical Information Management=20 Patient Information=20 Data Archiving=20 Information Systems=20 Data Bases Multimedia=20 Evaluation of the Information Systems of Health=20 Security=20 NTIC and Health Medical Imagery=20 Data-processing Applications for Medical Imagery=20 Segmentation, Rebuilding 3D=20 Computer Graphics=20 Signal Treatments=20 Image, Compression, Coding and Encoding Remote Telemedical Plateforms=20 Collaborative Work, Collaborative Virtual Environments=20 Remote Monitoring=20 Telediagnosis, Teleconsulting=20 E-health=20 Information Systems Integrated of Health for the Shared and Collaborative C= are Ergonomics of the Interfaces=20 Remote Human Computer Interfaces=20 Virtual Reality=20 Increased reality=20 Increased Reality Safety in Distributed Multimedia Applications Medical Systems Communicating=20 Wireless Adhoc Networks (MANET)=20 Personal Networks (PN), Personal Area=20 Networks (PAN), WIMAX=20 Ubiquity and Networks without Wire=20 Networks of Health=20 Sensor Networks: Patients Steady, Patient with Handicap=20 Mobile Care Patient, Mobility=20 Security in Networks =3D=3D IMPORTANT DATES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paper submission: June 30, 2008 Notification of acceptance: July 31, 2008 Final manuscript due: September 15, 2008 Main conference : October 29-31, 2008 =3D=3D CONFERENCE'S PLACE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Sfax is a city in Tunisia, located 270 km southeast of Tunis. The city is t= he capital of the south of Tunisia, and a Mediterranean port on the Gulf of= Gabes, it is an industrial and touristic center.=20 It is often described as Tunisia's Second city.=20 [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jun 17 10:28:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 10:28:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5HHSe7A009997 for ; Tue, 17 Jun 2008 10:28:40 -0700 X-ASG-Debug-ID: 1213723777-55e100270000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34508.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 6C3B923E7A8 for ; Tue, 17 Jun 2008 10:29:37 -0700 (PDT) Received: from web34508.mail.mud.yahoo.com (web34508.mail.mud.yahoo.com [66.163.178.174]) by cuda.sgi.com with SMTP id F1zgtmdrCaSDsZyu for ; Tue, 17 Jun 2008 10:29:37 -0700 (PDT) Received: (qmail 8593 invoked by uid 60001); 17 Jun 2008 17:29:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=1x95siqWzPS7I3mYhe5COl1BPfcNJx+PZvip1m+nJoa6WQRwYiePod3qXwvcc+g1Vm3sPqNTLdAIT0St43S2z0yCScjni/xc3SG1fg38itGtL4g8LlSz95WhHPcNGbh561oImQipxRfpgS6nmFtVTVqv+pB6xEBuyydHVtF/qlk=; Received: from [96.13.201.11] by web34508.mail.mud.yahoo.com via HTTP; Tue, 17 Jun 2008 10:29:37 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 17 Jun 2008 10:29:37 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <338502.8443.qm@web34508.mail.mud.yahoo.com> X-Barracuda-Connect: web34508.mail.mud.yahoo.com[66.163.178.174] X-Barracuda-Start-Time: 1213723778 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.28 X-Barracuda-Spam-Status: No, SCORE=0.28 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53574 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16391 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs --- On Tue, 6/17/08, Justin Piszcz wrote: > From: Justin Piszcz > Subject: Re: XFS mkfs/mount options > To: "Mark" > Cc: xfs@oss.sgi.com > Date: Tuesday, June 17, 2008, 5:27 AM > > How did you tune your IRQ delivery? Generically: echo X > /proc/irq/[IRQ#]/smp_affinity Where X is a 32-bit hexadecimal bitmask. My real procedure: First, I confirmed that both drives (sda and sdb) were triggering different interrupts on the same CPU. "cat /dev/sda > /dev/null &" for activity, followed by "cat /proc/interrupts" a few times. (NOT AS ROOT!) Interrupt 20 was triggering only on the second CPU. Killed the background task. Repeat, using "cat /dev/sdb > /dev/null &". Interrupt 21, also routing to the second CPU. Bottleneck likely confirmed. A short hunt in /usr/src/linux/Documentation turned up the smp_affinity files. Looking at /proc/irq/2[01]/smp_affinity shows that both contain "ffffffff", that is, use all available CPU's. To force the matter, I typed: echo 00000001 > /proc/irq/21/smp_affinity echo 00000002 > /proc/irq/20/smp_affinity I dropped privileges, then repeated the "cat /dev..." above for both drives, confirming that interrupts were indeed going to CPU0 for int21 and CPU1 for int20. Running a homebrewed multi-threading benchmark showed a possible speed-up for writes on XFS. I have not yet run "official" tests (Bonnie++ or my own) but will do so tonight. I expect the loss from cache-bouncing to be canceled out by the win from concurrent I/O. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Tue Jun 17 13:40:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 13:40:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5HKeSVr027334 for ; Tue, 17 Jun 2008 13:40:28 -0700 X-ASG-Debug-ID: 1213735285-761602300000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 756A1CD8DA0; Tue, 17 Jun 2008 13:41:25 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id y85k3T2vOkYytWXp; Tue, 17 Jun 2008 13:41:25 -0700 (PDT) Received: from [10.0.0.21] (DSL01.83.171.162.93.ip-pool.NEFkom.net [83.171.162.93]) by mail.lichtvoll.de (Postfix) with ESMTP id A61BD5AE11; Tue, 17 Jun 2008 22:38:17 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com, MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options Date: Tue, 17 Jun 2008 22:41:21 +0200 User-Agent: KMail/1.9.9 Cc: xfs@oss.sgi.com References: <338502.8443.qm@web34508.mail.mud.yahoo.com> (sfid-20080617_222310_564625_90C3CEF2) In-Reply-To: <338502.8443.qm@web34508.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806172241.22211.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1213735286 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2268 1.0000 -0.6896 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.41 X-Barracuda-Spam-Status: No, SCORE=-0.41 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53588 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16392 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Hi Mark, Am Dienstag 17 Juni 2008 schrieb Mark: > --- On Tue, 6/17/08, Justin Piszcz wrote: > > From: Justin Piszcz > > Subject: Re: XFS mkfs/mount options > > To: "Mark" > > Cc: xfs@oss.sgi.com > > Date: Tuesday, June 17, 2008, 5:27 AM > > > > How did you tune your IRQ delivery? > > Generically: > > echo X > /proc/irq/[IRQ#]/smp_affinity > > Where X is a 32-bit hexadecimal bitmask. > > My real procedure: [... longer procedure ...] We always use martin@shambala> apt-cache show irqbalance Package: irqbalance Priority: extra Section: utils Installed-Size: 64 Maintainer: Kyle McMartin Architecture: i386 Version: 0.55-2.1 Depends: debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.7-1), libglib2.0-0 (>= 2.12.0) Filename: pool/main/i/irqbalance/irqbalance_0.55-2.1_i386.deb Size: 17496 MD5sum: e4393d6ac2659e08f1bdecab2d94c1bf SHA1: 4b49deb3b522dec88c820bde78cfb6abb20365dd SHA256: 069104aff5561f09c8affcfe2aa9e144bed359a7c935c71c9968c78d1e8bf1b3 Description: Daemon to balance interrupts for SMP systems Daemon to balance interrupts across multiple CPUs, which can lead to better performance and IO balance on SMP systems. This package is especially useful on systems with multi-core processors, as interrupts will typically only be serviced by the first core. Tag: admin::hardware, admin::kernel, interface::commandline, interface::daemon, network::server, role::program for this kind of task or well the version in Debian Etch of it, the former is Lenny/Sid: Version: 0.12-7 Depends: libc6 (>= 2.3.6-6), debconf (>= 0.5) | debconf-2.0 Is there any need to fine-tune interrupts manually? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Jun 17 20:41:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 20:41:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I3fO1R030083 for ; Tue, 17 Jun 2008 20:41:25 -0700 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 NAA09556; Wed, 18 Jun 2008 13:42:16 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 7663558C4C3F; Wed, 18 Jun 2008 13:42:16 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 983394 - factor out has_attrs function Message-Id: <20080618034216.7663558C4C3F@chook.melbourne.sgi.com> Date: Wed, 18 Jun 2008 13:42:16 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16393 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Factor out code for whether inode has attributes or not. Signed-off-by: Christoph Hellwig Date: Wed Jun 18 13:41:05 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31323a fs/xfs/xfs_attr.c - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h - Factor out xfs_inode_hasattr. From owner-xfs@oss.sgi.com Tue Jun 17 21:02:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:02:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I42ejw031403 for ; Tue, 17 Jun 2008 21:02:41 -0700 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 OAA10051; Wed, 18 Jun 2008 14:03:34 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id A209958C4C3F; Wed, 18 Jun 2008 14:03:34 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 983395 - simplify xfs_vn_listxattr Message-Id: <20080618040334.A209958C4C3F@chook.melbourne.sgi.com> Date: Wed, 18 Jun 2008 14:03:34 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16394 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. Signed-off-by: Christoph Hellwig Date: Wed Jun 18 14:02:38 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31324a fs/xfs/xfs_acl.c - 1.74 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/xfs_attr_leaf.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/xfs_attr_leaf.c - 1.113 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/xfs_attr.c - 1.154 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.154&r2=text&tr2=1.153&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/xfs_attr.h - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/linux-2.6/xfs_xattr.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_xattr.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. From owner-xfs@oss.sgi.com Tue Jun 17 21:22:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:22:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I4Lq1I032751 for ; Tue, 17 Jun 2008 21:21:57 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10437; Wed, 18 Jun 2008 14:22:47 +1000 Message-ID: <48588E6B.3010006@sgi.com> Date: Wed, 18 Jun 2008 14:26:19 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: lachlan@sgi.com CC: xfs-dev , xfs-oss Subject: Re: [PATCH V2] make inode reclaim wait for log I/O to complete References: <48364E43.3030108@sgi.com> In-Reply-To: <48364E43.3030108@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16395 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs ping. Lachlan McIlroy wrote: > During a forced shutdown a xfs inode can be destroyed before log > I/O involving that inode is complete. We need to wait for the > inode to be unpinned before tearing it down. Version 2 cleans up > the code a bit by relying on xfs_iflush() to do the unpinning and > forced shutdown check. > > --- fs/xfs/xfs_inode.c_1.504 2008-05-23 11:19:21.000000000 +1000 > +++ fs/xfs/xfs_inode.c 2008-05-23 11:21:14.000000000 +1000 > @@ -3082,8 +3082,6 @@ xfs_iflush( > * flush lock and do nothing. > */ > if (xfs_inode_clean(ip)) { > - ASSERT((iip != NULL) ? > - !(iip->ili_item.li_flags & XFS_LI_IN_AIL) : 1); > xfs_ifunlock(ip); > return 0; > } > --- fs/xfs/xfs_vnodeops.c_1.760 2008-05-22 16:01:09.000000000 +1000 > +++ fs/xfs/xfs_vnodeops.c 2008-05-23 11:52:54.000000000 +1000 > @@ -3260,7 +3260,6 @@ xfs_finish_reclaim( > { > xfs_perag_t *pag = xfs_get_perag(ip->i_mount, ip->i_ino); > bhv_vnode_t *vp = XFS_ITOV_NULL(ip); > - int error; > > if (vp && VN_BAD(vp)) > goto reclaim; > @@ -3303,29 +3302,16 @@ xfs_finish_reclaim( > xfs_iflock(ip); > } > > - if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) { > - if (ip->i_update_core || > - ((ip->i_itemp != NULL) && > - (ip->i_itemp->ili_format.ilf_fields != 0))) { > - error = xfs_iflush(ip, sync_mode); > - /* > - * If we hit an error, typically because of filesystem > - * shutdown, we don't need to let vn_reclaim to know > - * because we're gonna reclaim the inode anyway. > - */ > - if (error) { > - xfs_iunlock(ip, XFS_ILOCK_EXCL); > - goto reclaim; > - } > - xfs_iflock(ip); /* synchronize with xfs_iflush_done */ > - } > - > - ASSERT(ip->i_update_core == 0); > - ASSERT(ip->i_itemp == NULL || > - ip->i_itemp->ili_format.ilf_fields == 0); > + /* > + * In the case of a forced shutdown we rely on xfs_iflush() to > + * wait for the inode to be unpinned before returning an error. > + */ > + if (xfs_iflush(ip, sync_mode) == 0) { > + /* synchronize with xfs_iflush_done */ > + xfs_iflock(ip); > + xfs_ifunlock(ip); > } > > - xfs_ifunlock(ip); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > > reclaim: > > > From owner-xfs@oss.sgi.com Tue Jun 17 21:29:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:29:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5I4TEk6000914 for ; Tue, 17 Jun 2008 21:29:14 -0700 X-ASG-Debug-ID: 1213763410-601503090000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 674182426A4 for ; Tue, 17 Jun 2008 21:30:11 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id MH9DsiCWiCc9piZS for ; Tue, 17 Jun 2008 21:30:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoGADgrWEh5LG+uWmdsb2JhbACSKwEdnFI X-IronPort-AV: E=Sophos;i="4.27,662,1204464600"; d="scan'208";a="128906682" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 18 Jun 2008 14:00:04 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K8pJ5-0004vU-0Y; Wed, 18 Jun 2008 14:30:03 +1000 Date: Wed, 18 Jun 2008 14:30:02 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH V2] make inode reclaim wait for log I/O to complete Subject: Re: [PATCH V2] make inode reclaim wait for log I/O to complete Message-ID: <20080618043002.GS3700@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <48364E43.3030108@sgi.com> <48588E6B.3010006@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48588E6B.3010006@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213763412 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0004 1.0000 -2.0181 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53609 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16396 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 02:26:19PM +1000, Lachlan McIlroy wrote: > ping. > > Lachlan McIlroy wrote: >> During a forced shutdown a xfs inode can be destroyed before log >> I/O involving that inode is complete. We need to wait for the >> inode to be unpinned before tearing it down. Version 2 cleans up >> the code a bit by relying on xfs_iflush() to do the unpinning and >> forced shutdown check. Sorry I missed this when you first posted it. This one looks ok. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 17 21:44:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:44:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I4iKlA002146 for ; Tue, 17 Jun 2008 21:44:23 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10990; Wed, 18 Jun 2008 14:45:11 +1000 Message-ID: <485892D7.4080000@sgi.com> Date: Wed, 18 Jun 2008 14:45:11 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] kill INDUCE_IO_ERROR References: <20080523062323.GA32637@lst.de> <20080616101412.GA17939@lst.de> In-Reply-To: <20080616101412.GA17939@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16397 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, May 23, 2008 at 08:23:23AM +0200, Christoph Hellwig wrote: >> All the error injection is already enabled through ifdef DEBUG, so kill >> the never set second cpp symbol to activate it without the rest of the >> debugging infrastructure. > > Can I get a review on this absolutely trivial patch? I'd like to keep INDUCE_IO_ERROR around so we have a way to introduce ioerrors in release builds during testing. We could add it to xfs.h with the commented out QUOTADEBUG so people know we still want to use it. Don >> >> Signed-off-by: Christoph Hellwig >> >> Index: linux-2.6-xfs/fs/xfs/xfs_error.c >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/xfs_error.c 2008-05-22 18:55:04.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/xfs_error.c 2008-05-22 18:55:16.000000000 +0200 >> @@ -58,9 +58,6 @@ xfs_error_trap(int e) >> } >> return e; >> } >> -#endif >> - >> -#if (defined(DEBUG) || defined(INDUCE_IO_ERROR)) >> >> int xfs_etest[XFS_NUM_INJECT_ERROR]; >> int64_t xfs_etest_fsid[XFS_NUM_INJECT_ERROR]; >> @@ -154,7 +151,7 @@ xfs_errortag_clearall(xfs_mount_t *mp, i >> >> return 0; >> } >> -#endif /* DEBUG || INDUCE_IO_ERROR */ >> +#endif /* DEBUG */ >> >> static void >> xfs_fs_vcmn_err(int level, xfs_mount_t *mp, char *fmt, va_list ap) >> Index: linux-2.6-xfs/fs/xfs/xfs_error.h >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/xfs_error.h 2008-05-22 18:55:04.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/xfs_error.h 2008-05-22 18:55:16.000000000 +0200 >> @@ -125,22 +125,14 @@ extern void xfs_corruption_error(char *t >> #define XFS_RANDOM_DIOWRITE_IOERR (XFS_RANDOM_DEFAULT/10) >> #define XFS_RANDOM_BMAPIFORMAT XFS_RANDOM_DEFAULT >> >> -#if (defined(DEBUG) || defined(INDUCE_IO_ERROR)) >> +#ifdef DEBUG >> extern int xfs_error_test(int, int *, char *, int, char *, unsigned long); >> >> #define XFS_NUM_INJECT_ERROR 10 >> - >> -#ifdef __ANSI_CPP__ >> -#define XFS_TEST_ERROR(expr, mp, tag, rf) \ >> - ((expr) || \ >> - xfs_error_test((tag), (mp)->m_fixedfsid, #expr, __LINE__, __FILE__, \ >> - (rf))) >> -#else >> #define XFS_TEST_ERROR(expr, mp, tag, rf) \ >> ((expr) || \ >> xfs_error_test((tag), (mp)->m_fixedfsid, "expr", __LINE__, __FILE__, \ >> (rf))) >> -#endif /* __ANSI_CPP__ */ >> >> extern int xfs_errortag_add(int error_tag, xfs_mount_t *mp); >> extern int xfs_errortag_clearall(xfs_mount_t *mp, int loud); >> @@ -148,7 +140,7 @@ extern int xfs_errortag_clearall(xfs_mou >> #define XFS_TEST_ERROR(expr, mp, tag, rf) (expr) >> #define xfs_errortag_add(tag, mp) (ENOSYS) >> #define xfs_errortag_clearall(mp, loud) (ENOSYS) >> -#endif /* (DEBUG || INDUCE_IO_ERROR) */ >> +#endif /* DEBUG */ >> >> /* >> * XFS panic tags -- allow a call to xfs_cmn_err() be turned into >> Index: linux-2.6-xfs/fs/xfs/xfs_mount.c >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2008-05-22 18:55:05.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2008-05-23 08:11:46.000000000 +0200 >> @@ -1322,7 +1322,7 @@ xfs_unmountfs(xfs_mount_t *mp) >> if ((mp->m_flags & XFS_MOUNT_NOUUID) == 0) >> uuid_table_remove(&mp->m_sb.sb_uuid); >> >> -#if defined(DEBUG) || defined(INDUCE_IO_ERROR) >> +#if defined(DEBUG) >> xfs_errortag_clearall(mp, 0); >> #endif >> xfs_mount_free(