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(