From owner-xfs@oss.sgi.com Sun Jun 1 00:34:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 00:34:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m517Yp0u009710 for ; Sun, 1 Jun 2008 00:34:52 -0700 X-ASG-Debug-ID: 1212305743-280602670000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from yw-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 753A1C348C8 for ; Sun, 1 Jun 2008 00:35:43 -0700 (PDT) Received: from yw-out-1718.google.com (yw-out-1718.google.com [74.125.46.155]) by cuda.sgi.com with ESMTP id L2tMDiGEC9vYOpxl for ; Sun, 01 Jun 2008 00:35:43 -0700 (PDT) Received: by yw-out-1718.google.com with SMTP id 5so212602ywm.32 for ; Sun, 01 Jun 2008 00:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=pJ9d5vQYMHwboJWXlX8xsZh0y5cXOgNC9M3wyhqz7bM=; b=eR2SFSUGRU8pIN4OQFzildDUMSvnmfk6zYT+w5SBWfuQVTMV8XWpq72eGC76v3UrZFITtthHe9H7yHB65Q24MigseleumQw54DK3JiwHU0zv7PmVax8GpaOKIlETsuJPdknavmywmZfvX3enskkkAXu0tZ0Uw/rHo8TzfcHrPFs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ULCTjpeirYXX9ljkOv/B9XJvwQR2XZ2A9In/DMQf1PvfrnmfZUu/aOXAhrND67XEqvARHBgznvWxVLEctDVTEFdDZyVTWBwdoxuwYuuxK6ZgyQqSGx7HJLMJ7PjKMurDwT9cKtcnfq590dKHDBjw6RnSVxVtDLJstdnLpq0QtQU= Received: by 10.151.48.20 with SMTP id a20mr3659789ybk.111.1212305743152; Sun, 01 Jun 2008 00:35:43 -0700 (PDT) Received: from Ahoora.local ( [70.19.190.113]) by mx.google.com with ESMTPS id 9sm2619492ywf.9.2008.06.01.00.35.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 01 Jun 2008 00:35:42 -0700 (PDT) Message-ID: <48425148.1080105@gmail.com> Date: Sun, 01 Jun 2008 03:35:36 -0400 From: Hamid User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Stefan Smietanowski CC: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <483EE5BD.8020407@sandeen.net> <3607657a0805291255i59fd006fi9d6836cf528d19a6@mail.gmail.com> <483F0BC3.2050901@sandeen.net> <3607657a0805291400h3c50165lea6fbea919deed0f@mail.gmail.com> <483F1AED.3010808@sandeen.net> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> In-Reply-To: <48409981.1050405@stesmi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: yw-out-1718.google.com[74.125.46.155] X-Barracuda-Start-Time: 1212305744 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52029 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16211 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs > I think you have the terminology a little mixed up. > > If you mount a something without supplying -o loop "mount" will assume > the filesystem resides in a DEVICE. > > If you mount a something WHILE supplying -o loop you tell "mount" that > it should mount it using a loop device. Note device here, it's trickery > really as what it does is that "mount" will FIRST create a new device > node "/dev/loop0" for example and then it will mount from that device > node. > Thanks Stefan, Now it makes real sense. I guess I am back to my original question: What does 'SB validate failed' indicate and what it really means to my case ? fdisk reports the structure of the Jaz disk as: $ sudo fdisk -ul jaz7.img Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders Units = sectors of 1 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 8: jaz7.img1 3072 2091007 2087936 a SGI xfs 9: jaz7.img2 0 3071 3072 0 SGI volhdr 11: jaz7.img3 0 2091007 2091008 6 SGI volume ----- Bootinfo ----- Bootfile: /unix ----- Directory Entries ----- 0: sgilabel sector 3 size 512 I went ahead and tried to mount Partition 8 from image using the offset and loop options of the mount command: $ sudo mount -t xfs -o loop,offset=$((512*3072)) jaz7-partition.img /mnt mount: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so And system log says: XFS: bad magic number XFS: SB validate failed So I am guessing I have one of these 3 cases: 1- Bad partition table, good file system 2- Good partition table, corrupt file system 3- Or both gone south!!! I checked the man pages of 'vh' on Irix. It seems that the volhdr partition is 'usually' 2 megabytes but the disk in question has 3072*512 bytes ? Can this be a sign of corruption ? So where would you start looking at if you wanted to fix this problem ? Partition table or the file system ? From owner-xfs@oss.sgi.com Sun Jun 1 02:44:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 02:44:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m519ilF4015130 for ; Sun, 1 Jun 2008 02:44:47 -0700 X-ASG-Debug-ID: 1212313539-4b6602700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3D71F1D889D for ; Sun, 1 Jun 2008 02:45:39 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id oE1GTadybxOot5ce for ; Sun, 01 Jun 2008 02:45:39 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 2132E1C000235; Sun, 1 Jun 2008 05:45:39 -0400 (EDT) Date: Sun, 1 Jun 2008 05:45:39 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1212313540 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0098 1.0000 -1.9573 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.96 X-Barracuda-Spam-Status: No, SCORE=-1.96 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52036 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16212 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and it appears I have hit the limit, if I were able to get the maximum speed of all drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 MiB/s (currently running badblocks on all drives).. I am testing some drives for someone and was curious to see how far one can push the disks/backplane to their theoretical limit. dstat output: ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 1 12 0 83 3 2| - 0 | 0 0 | 0 0 | 13k 23k 1 11 0 84 2 2| 774M 0 |2100B 7373B| 0 0 | 13k 23k 1 12 0 83 3 2| 774M 0 | 0 0 | 0 0 | 13k 23k 1 11 0 82 4 2| 774M 0 |2030B 5178B| 0 0 | 13k 23k 1 11 0 83 4 2| 774M 0 | 0 0 | 0 0 | 13k 23k 1 11 0 83 3 2| 774M 0 |2264B 6225B| 0 0 | 13k 23k vmstat 1 output: ~$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 0 12 124 3841772 8 13012 0 0 12595 163880 379 352 0 31 37 32 2 12 124 3841772 8 12992 0 0 791744 8 12796 23033 1 18 0 82 0 12 124 3841772 8 12992 0 0 792192 0 12677 22918 1 15 0 84 0 12 124 3841772 8 12992 0 0 792960 0 12894 22929 1 15 0 84 When I was writing to all of the drives it was maxing out around ~650 MiB/s. I also have 2 raptors on a PCI card (as I ran out of PCI-e cards) and: When I read from 1 of the raptors (w/ dd/example shown below) the speed drops: 1 13 0 79 5 3| 764M 0 |2240B 7105B| 0 0 | 12k 21k 1 13 0 80 5 2| 764M 0 | 0 0 | 0 0 | 12k 21k 1 11 0 82 5 2| 764M 0 |2170B 5446B| 0 0 | 12k 21k 1 12 0 81 5 2| 762M 0 | 0 0 | 0 0 | 12k 21k Does/has anyone done this with server intel board/would greater speeds be achievable? Also, how does AMD fair in this regard? Has anyone run similar tests? For instance if you have 12 disks in your host you could: dd if=/dev/disk1 of=/dev/null bs=1M dd if=/dev/disk2 of=/dev/null bs=1M What rate(s) do you get? Justin. From owner-xfs@oss.sgi.com Sun Jun 1 03:45:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 03:45:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51AjZCe018056 for ; Sun, 1 Jun 2008 03:45:35 -0700 X-ASG-Debug-ID: 1212317187-220901230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from proxy2.bredband.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BB83E1D8903 for ; Sun, 1 Jun 2008 03:46:27 -0700 (PDT) Received: from proxy2.bredband.net (proxy2.bredband.net [195.54.101.72]) by cuda.sgi.com with ESMTP id jchEmKpSFwASjCja for ; Sun, 01 Jun 2008 03:46:27 -0700 (PDT) Received: from ironport2.bredband.com (195.54.101.122) by proxy2.bredband.net (7.3.127) id 4811833300B18985 for xfs@oss.sgi.com; Sun, 1 Jun 2008 12:46:26 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aro3AHsbQkjVctjQPGdsb2JhbACBVYcIiSQBAQEBLQGZRg Received: from c-d0d872d5.06-15-73746f44.cust.bredbandsbolaget.se (HELO DeepSpaceNine.stesmi.com) ([213.114.216.208]) by ironport2.bredband.com with ESMTP; 01 Jun 2008 12:46:11 +0200 Received: from [127.0.0.1] (voyager.stesmi.com [192.168.1.11]) by DeepSpaceNine.stesmi.com (8.12.11/8.12.11) with ESMTP id m51Ak52S025531; Sun, 1 Jun 2008 12:46:10 +0200 Message-ID: <48427DEE.40400@stesmi.com> Date: Sun, 01 Jun 2008 12:46:06 +0200 From: Stefan Smietanowski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Hamid CC: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <483EE5BD.8020407@sandeen.net> <3607657a0805291255i59fd006fi9d6836cf528d19a6@mail.gmail.com> <483F0BC3.2050901@sandeen.net> <3607657a0805291400h3c50165lea6fbea919deed0f@mail.gmail.com> <483F1AED.3010808@sandeen.net> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> In-Reply-To: <48425148.1080105@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.7; VAE 6.29.0.5; VDF 6.29.0.100 X-Barracuda-Connect: proxy2.bredband.net[195.54.101.72] X-Barracuda-Start-Time: 1212317188 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52040 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16213 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Hamid wrote: > >> I think you have the terminology a little mixed up. >> >> If you mount a something without supplying -o loop "mount" will assume >> the filesystem resides in a DEVICE. >> >> If you mount a something WHILE supplying -o loop you tell "mount" that >> it should mount it using a loop device. Note device here, it's trickery >> really as what it does is that "mount" will FIRST create a new device >> node "/dev/loop0" for example and then it will mount from that device >> node. >> > Thanks Stefan, Now it makes real sense. > > I guess I am back to my original question: > What does 'SB validate failed' indicate and what it really means to my > case ? > > fdisk reports the structure of the Jaz disk as: > > $ sudo fdisk -ul jaz7.img > > Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders > Units = sectors of 1 * 512 bytes > > ----- partitions ----- > Pt# Device Info Start End Sectors Id System > 8: jaz7.img1 3072 2091007 2087936 a SGI xfs > 9: jaz7.img2 0 3071 3072 0 SGI volhdr > 11: jaz7.img3 0 2091007 2091008 6 SGI volume > ----- Bootinfo ----- > Bootfile: /unix > ----- Directory Entries ----- > 0: sgilabel sector 3 size 512 > > I went ahead and tried to mount Partition 8 from image using the offset > and loop options of the mount command: > > $ sudo mount -t xfs -o loop,offset=$((512*3072)) jaz7-partition.img /mnt > mount: wrong fs type, bad option, bad superblock on /dev/loop1, > missing codepage or helper program, or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > And system log says: > > XFS: bad magic number > XFS: SB validate failed > > So I am guessing I have one of these 3 cases: > 1- Bad partition table, good file system > 2- Good partition table, corrupt file system > 3- Or both gone south!!! > > I checked the man pages of 'vh' on Irix. It seems that the volhdr > partition is 'usually' 2 megabytes but the disk in question has 3072*512 > bytes ? > Can this be a sign of corruption ? > > So where would you start looking at if you wanted to fix this problem ? > Partition table or the file system ? Personally I would hexdump the beginning of the disk looking for the xfs magic of the partition and then try to use that offset in mount. One way is : od -t c jaz7.img | grep X | head Look for X F S B, may be split on two lines for you. This is what my disk looks like but of course, it's on a DOS partition: 0077000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \0 ` \0 Then you have the offset (OCTAL!!) on the left, convert it to decimal, feed that to mount and see if it mounts. Also check if it's the same offset as the partition table is telling you or not. // Stefan From owner-xfs@oss.sgi.com Sun Jun 1 04:00:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 04:00:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51B0HYF019354 for ; Sun, 1 Jun 2008 04:00:18 -0700 X-ASG-Debug-ID: 1212318070-21fd01e40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D2D391D87B2 for ; Sun, 1 Jun 2008 04:01:10 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id 4xB5N9iONjjThQPW for ; Sun, 01 Jun 2008 04:01:10 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id F18BF1C00027A; Sun, 1 Jun 2008 07:01:09 -0400 (EDT) Date: Sun, 1 Jun 2008 07:01:09 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1212318070 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52042 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16214 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 1 Jun 2008, Justin Piszcz wrote: > I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and it > appears I have hit the limit, if I were able to get the maximum speed of all > drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 MiB/s > (currently running badblocks on all drives).. Small correction, they are 7200.11 Seagate Desktop Drives (ST31000340AS), not enterprise drives: http://www.seagate.com/ww/v/index.jsp?vgnextoid=0732f141e7f43110VgnVCM100000f5ee0a0aRCRD http://www.newegg.com/Product/Product.aspx?Item=N82E16822148274 From owner-xfs@oss.sgi.com Sun Jun 1 04:25:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 04:25:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,J_BACKHAIR_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51BPJMg025841 for ; Sun, 1 Jun 2008 04:25:19 -0700 X-ASG-Debug-ID: 1212319570-505402b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BD3ECC350E4 for ; Sun, 1 Jun 2008 04:26:10 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id TE43MHIAPR9a0CWz for ; Sun, 01 Jun 2008 04:26:10 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id C701F1C00027A; Sun, 1 Jun 2008 07:26:09 -0400 (EDT) Date: Sun, 1 Jun 2008 07:26:09 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1212319571 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52041 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16215 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 1 Jun 2008, Justin Piszcz wrote: > > On Sun, 1 Jun 2008, Justin Piszcz wrote: > >> I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and it >> appears I have hit the limit, if I were able to get the maximum speed of >> all drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 MiB/s >> (currently running badblocks on all drives).. > > Small correction, they are 7200.11 Seagate Desktop Drives (ST31000340AS), not > enterprise drives: > > http://www.seagate.com/ww/v/index.jsp?vgnextoid=0732f141e7f43110VgnVCM100000f5ee0a0aRCRD > http://www.newegg.com/Product/Product.aspx?Item=N82E16822148274 > > http://www.intel.com/products/chipsets/g965/diagram.jpg Basically it appears I am hammering the southbridge as for this board the PCI-e (x1) slots also traverse through the southbridge. 6_SATA -> G965 ICH8 3_PCI-e -> G965 ICH8 From which has to ship that data across the DMI (2GB) link to the northbridge. If one utilized a 12, 16 or 24 port raid card (but used SW RAID) on the x16 slot on the northbridge itself, would this barrier exist as the: GMCH<->CPU is (8.5GB/s)..? Also on the X38 and X48 the speed increases slightly: http://www.intel.com/products/chipsets/X38/X38_Block_Diagram.jpg (10.6GB/s) http://www.intel.com/products/chipsets/x48/x48_block_diagram.jpg (12.8GB/s) If one asks why would one need such speed? Example: LTO-4 drives can write at 120 MiB/s each: http://en.wikipedia.org/wiki/Linear_Tape-Open It is then therefore imperative one could sustain this rate to possibly multiple(!) tape drives on a single system. Justin. From owner-xfs@oss.sgi.com Sun Jun 1 05:19:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 05:19:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_00,J_BACKHAIR_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51CJob1029156 for ; Sun, 1 Jun 2008 05:19:51 -0700 X-ASG-Debug-ID: 1212322841-7dc400ef0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from 1wt.eu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A393E1D8D12 for ; Sun, 1 Jun 2008 05:20:42 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by cuda.sgi.com with ESMTP id GvC7vzq2VcSscgqj for ; Sun, 01 Jun 2008 05:20:42 -0700 (PDT) Date: Sun, 1 Jun 2008 14:20:33 +0200 From: Willy Tarreau To: Justin Piszcz Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Message-ID: <20080601122033.GE5609@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 X-Barracuda-Connect: 1wt.eu[62.212.114.60] X-Barracuda-Start-Time: 1212322843 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52047 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16216 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: w@1wt.eu Precedence: bulk X-list: xfs On Sun, Jun 01, 2008 at 07:26:09AM -0400, Justin Piszcz wrote: > > > On Sun, 1 Jun 2008, Justin Piszcz wrote: > > > > >On Sun, 1 Jun 2008, Justin Piszcz wrote: > > > >>I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and > >>it appears I have hit the limit, if I were able to get the maximum speed > >>of all drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 > >>MiB/s (currently running badblocks on all drives).. > > > >Small correction, they are 7200.11 Seagate Desktop Drives (ST31000340AS), > >not enterprise drives: > > > >http://www.seagate.com/ww/v/index.jsp?vgnextoid=0732f141e7f43110VgnVCM100000f5ee0a0aRCRD > >http://www.newegg.com/Product/Product.aspx?Item=N82E16822148274 > > > > > > http://www.intel.com/products/chipsets/g965/diagram.jpg > > Basically it appears I am hammering the southbridge as for this board the > PCI-e (x1) slots also traverse through the southbridge. > > 6_SATA -> G965 ICH8 > 3_PCI-e -> G965 ICH8 > > >From which has to ship that data across the DMI (2GB) link to the > northbridge. > > If one utilized a 12, 16 or 24 port raid card (but used SW RAID) on the > x16 slot on the northbridge itself, would this barrier exist as the: > GMCH<->CPU is (8.5GB/s)..? > > Also on the X38 and X48 the speed increases slightly: > http://www.intel.com/products/chipsets/X38/X38_Block_Diagram.jpg (10.6GB/s) > http://www.intel.com/products/chipsets/x48/x48_block_diagram.jpg (12.8GB/s) > > If one asks why would one need such speed? It looks like graphic games are pushing the technologies to their limits, which is good for us. I have bought X38 motherboards for 10 Gbps experimentations, and this chipset is perfectly capable of feeding two Myri10GE NICs (20 Gbps total). This is 2.5 GB/s, not counting overhead. So I/O bandwidth is a premium requirement today. Other chipsets I have tested (945 and 965) were very poor (about 4.7 and 6.5 Gbps respectively if my memory serves me right). Willy From owner-xfs@oss.sgi.com Sun Jun 1 06:54:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 06:54:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51DslS3001342 for ; Sun, 1 Jun 2008 06:54:47 -0700 X-ASG-Debug-ID: 1212328536-29cf02eb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server515.appriver.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C042912285F6 for ; Sun, 1 Jun 2008 06:55:36 -0700 (PDT) Received: from server515.appriver.com (server515i.exghost.com [72.32.253.75]) by cuda.sgi.com with ESMTP id clOzJVfS1QXdw6JK for ; Sun, 01 Jun 2008 06:55:36 -0700 (PDT) Received: by server515.appriver.com (CommuniGate Pro PIPE 5.2.0) with PIPE id 37042371; Sun, 01 Jun 2008 08:55:31 -0500 Received: from FE1.exchange.rackspace.com ([72.32.49.5] verified) by server515.appriver.com (CommuniGate Pro SMTP 5.2.0) with ESMTP id 37042367; Sun, 01 Jun 2008 08:55:30 -0500 Received: from 34093-C3-EVS3.exchange.rackspace.com ([192.168.1.161]) by FE1.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Jun 2008 08:55:35 -0500 Received: from 192.168.1.88 ([192.168.1.88]) by 34093-C3-EVS3.exchange.rackspace.com ([192.168.1.78]) with Microsoft Exchange Server HTTP-DAV ; Sun, 1 Jun 2008 13:52:48 +0000 To: "Justin Piszcz" , , , Reply-To: Message-ID: <13c501c8c3ee$c6a31318$330ef40a@exchange.rackspace.com> X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? From: "David Lethe" Thread-Topic: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Thread-Index: AcjD7sai6rpNKVABQ6i5nGsqH2f0tA== Date: Sun, 1 Jun 2008 8:52:00 -0500 MIME-Version: 1.0 X-Mailer: VersaMail(R) v. 3.5.4, Copyright (c) 2001-2006 Palm, Inc. X-Sender: David@santools.com X-Priority: 3 Importance: Normal Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 01 Jun 2008 13:55:35.0041 (UTC) FILETIME=[2A10E710:01C8C3EF] X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Primary: david@santools.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: david@santools.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: PRIVATE->PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.5 X-Note-Reverse-DNS: fe1.exchange.rackspace.com X-Note-WHTLIST: david@santools.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 81 82 139 X-Note: Mail Class: ALLOWEDSENDER X-Barracuda-Connect: server515i.exghost.com[72.32.253.75] X-Barracuda-Start-Time: 1212328538 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.36 X-Barracuda-Spam-Status: No, SCORE=-0.36 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MSGID_DOLLARS X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52053 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.66 MSGID_DOLLARS Message-Id has pattern used in spam X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16217 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@santools.com Precedence: bulk X-list: xfs -----Original Message----- From: "Justin Piszcz" Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Date: Sun Jun 1, 2008 6:02 am Size: 793 bytes To: "linux-kernel@vger.kernel.org" ; "linux-raid@vger.kernel.org" ; "xfs@oss.sgi.com" On Sun, 1 Jun 2008, Justin Piszcz wrote: > I have 12 enterprise-class seagate 1TiB disks on a 965 desktop board and it > appears I have hit the limit, if I were able to get the maximum speed of all > drives, ~70MiB/avg * 12 = 840MiB/s but it seems to stop aound 774 MiB/s > (currently running badblocks on all drives).. Small correction, they are 7200.11 Seagate Desktop Drives (ST31000340AS), not enterprise drives: http://www.seagate.com/ww/v/index.jsp?vgnextoid=0732f141e7f43110VgnVCM100000f5ee0a0aRCRD http://www.newegg.com/Product/Product.aspx?Item=N82E16822148274 -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html From owner-xfs@oss.sgi.com Sun Jun 1 13:27:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 13:27:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m51KRZqj029204 for ; Sun, 1 Jun 2008 13:27:36 -0700 X-ASG-Debug-ID: 1212352106-666902cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9094179151B for ; Sun, 1 Jun 2008 13:28:27 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by cuda.sgi.com with ESMTP id 0bxMG9S2G6W8vMz8 for ; Sun, 01 Jun 2008 13:28:27 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so619237fgb.8 for ; Sun, 01 Jun 2008 13:28:26 -0700 (PDT) Received: by 10.86.82.16 with SMTP id f16mr1520486fgb.9.1212352106065; Sun, 01 Jun 2008 13:28:26 -0700 (PDT) Received: from Roman-NB ( [89.18.196.252]) by mx.google.com with ESMTPS id d4sm2718640fga.8.2008.06.01.13.28.24 (version=SSLv3 cipher=OTHER); Sun, 01 Jun 2008 13:28:24 -0700 (PDT) Date: Sun, 1 Jun 2008 23:28:16 +0300 From: Roman Kravchenko Organization: A Technologies X-Priority: 3 (Normal) Message-ID: <1562332443.20080601232816@atech.lv> To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs write locks Subject: xfs write locks MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.156] X-Barracuda-Start-Time: 1212352108 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0927 1.0000 -1.4363 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.44 X-Barracuda-Spam-Status: No, SCORE=-1.44 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52079 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m51KRaqj029207 X-archive-position: 16218 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: roman@atech.lv Precedence: bulk X-list: xfs Hello Xfs, Not sure if i have to report it this way... but anyway, at least it will be informative. I have problems with XFS file system with quota support. It sometimes freeze on write operations to filesystem. It's rare, freeze ocurring after a week or two of normal opetaion. I experience it since 2.6.23 series kernel and unable to track it down to get more detailed info... It's possible that it related to locking, as filesystem is still accesible for read operations. But I unable to recover additional info and just recently recompiled kernel with debug info to track it down. so far the only info I get is this INFO warning on boot: ============================================= [ INFO: possible recursive locking detected ] 2.6.25.4-g6dbg #1 --------------------------------------------- mysqld/1883 is trying to acquire lock: (&list->qh_lock){--..}, at: [] xfs_qm_dqget+0x288/0x370 but task is already holding lock: (&list->qh_lock){--..}, at: [] xfs_qm_dqget+0xbd/0x370 other info that might help us debug this: 3 locks held by mysqld/1883: #0: (&type->i_mutex_dir_key#2){--..}, at: [] open_namei+0xf1/0x5f0 #1: (&(&ip->i_lock)->mr_lock){----}, at: [] xfs_ilock+0x8f/0xd0 #2: (&list->qh_lock){--..}, at: [] xfs_qm_dqget+0xbd/0x370 stack backtrace: Pid: 1883, comm: mysqld Not tainted 2.6.25.4-g6dbg #1 [] __lock_acquire+0xe5d/0x1080 [] __lock_acquire+0x376/0x1080 [] lock_acquire+0x87/0xb0 [] xfs_qm_dqget+0x288/0x370 [] mutex_lock_nested+0x9e/0x280 [] xfs_qm_dqget+0x288/0x370 [] xfs_qm_dqget+0x288/0x370 [] xfs_qm_dqget+0x288/0x370 [] xfs_qm_dqattach_one+0xd2/0x1a0 [] xfs_qm_dqattach+0x1a2/0x1d0 [] xfs_qm_vop_dqalloc+0x248/0x300 [] xfs_create+0xa9/0x490 [] native_sched_clock+0x7b/0xd0 [] xfs_vn_mknod+0x159/0x1a0 [] vfs_create+0xc9/0x120 [] open_namei+0x550/0x5f0 [] do_filp_open+0x2e/0x60 [] _spin_unlock+0x14/0x20 [] get_unused_fd_flags+0xc5/0xe0 [] do_sys_open+0x4c/0xe0 [] sys_open+0x2c/0x40 [] syscall_call+0x7/0xb ======================= If there is any additional info that might help you, I'm gladly provide it to you. -- Best regards, Roman Kravchenko A Technologies From owner-xfs@oss.sgi.com Sun Jun 1 18:58:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 18:58:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m521wMjs017814 for ; Sun, 1 Jun 2008 18:58:23 -0700 X-ASG-Debug-ID: 1212371954-4072025a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5DA2912BB839 for ; Sun, 1 Jun 2008 18:59:14 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id 2XWhVBzrG6kwWuqE for ; Sun, 01 Jun 2008 18:59:14 -0700 (PDT) Received: from ppp121-44-83-140.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.83.140]) by ipmail04.adl2.internode.on.net with ESMTP; 02 Jun 2008 11:28:41 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K2zJn-0002Bq-S4; Mon, 02 Jun 2008 11:58:39 +1000 Date: Mon, 2 Jun 2008 11:58:39 +1000 From: Dave Chinner To: Tom Spink Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [RFC PATCH 0/2] On-demand Filesystem Initialisation Subject: Re: [RFC PATCH 0/2] On-demand Filesystem Initialisation Message-ID: <20080602015831.GB2428@disturbed> Mail-Followup-To: Tom Spink , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com References: <1212331915-22856-1-git-send-email-tspink@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1212331915-22856-1-git-send-email-tspink@gmail.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1212371956 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52101 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16219 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Sun, Jun 01, 2008 at 03:51:53PM +0100, Tom Spink wrote: > > (resend to include CCs) What cc's? Still no xfs cc on it. I added it to this reply.... > This (short) patch series is another RFC for the patch that introduces on-demand > filesystem initialisation. In addition to the original infrastructure > implementation (with clean-ups), it changes XFS to use this new infrastructure. > > I wrote a toy filesystem (testfs) to simulate scheduling/allocation delays and > to torture the mount/unmount cycles. I didn't manage to deadlock the system > in my tests. XFS also works as expected aswell, in that the global threads > are not created until an XFS filesystem is mounted for the first time. When the > last XFS filesystem is unmounted, the threads go away. > > Please let me know what you think! Why even bother? This is why we have /modular/ kernels - if you're not using XFS then don't load it and you won't see those pesky threads. That'll save on a bunch of memory as well because the xfs module ain't small (>480k on i386).... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 1 19:08:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 19:08:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5227uTd018505 for ; Sun, 1 Jun 2008 19:08:00 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA20016; Mon, 2 Jun 2008 12:08:42 +1000 Message-ID: <4843562A.9030503@sgi.com> Date: Mon, 02 Jun 2008 12:08:42 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Spam Magnet CC: Eric Sandeen , xfs@oss.sgi.com Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <483EE5BD.8020407@sandeen.net> <3607657a0805291255i59fd006fi9d6836cf528d19a6@mail.gmail.com> <483F0BC3.2050901@sandeen.net> <3607657a0805291400h3c50165lea6fbea919deed0f@mail.gmail.com> <483F1AED.3010808@sandeen.net> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> In-Reply-To: <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16220 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Spam Magnet wrote: >> As Eric said. >> We chose the ondisk format to have the byte ordering of IRIX so >> it should not be a problem. However, parts of the log code in Linux >> does not do the necessary endian conversion (due to lack of info at >> the relevant points - it only knows as blobs of data) and so you >> need the log to be clean. i.e. byte ordering problem just for the log. >> > > Thanks for this info, it's good to have 1 less problem to worry about :) > >> OOI, as Eric asked, how were you able to mount it all of a sudden? >> > > I am not sure, as I said, to narrow down the problem I am experiencing > with other disks, I decided to format an empty, healthy disk under Irix and > try to mount it under Linux. The first try was not successful but the > second was. > > Right now I am making an image of the good/healthy disk using dd to > see if I can mount that > image under Linux. (It's not fun to copy 2GB disks through a > USB1.1-SCSI adapter :) :-) If the fs is not too full then xfs_copy would be good I suppose as it won't copy freespace. --Tim From owner-xfs@oss.sgi.com Sun Jun 1 22:40:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 22:40:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m525eJcR010012 for ; Sun, 1 Jun 2008 22:40:20 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA23428 for ; Mon, 2 Jun 2008 15:41:11 +1000 Date: Mon, 02 Jun 2008 15:42:55 +1000 To: "xfs@oss.sgi.com" Subject: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id m525eMcR010015 X-archive-position: 16221 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs In particular, this patch fixes a problem in the xfs_dir2_remove and xfs_dir2_replace paths which internally can call a lookup function which will use args->cmpresult which is uninitialised. -- Index: 2.6.x-xfs/fs/xfs/xfs_dir2.c =================================================================== --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2.c +++ 2.6.x-xfs/fs/xfs/xfs_dir2.c @@ -213,6 +213,7 @@ xfs_dir_createname( if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) return rval; XFS_STATS_INC(xs_dir_create); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; @@ -297,7 +298,6 @@ xfs_dir_lookup( args.op_flags = XFS_DA_OP_OKNOENT; if (ci_name) args.op_flags |= XFS_DA_OP_CILOOKUP; - args.cmpresult = XFS_CMP_DIFFERENT; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_lookup(&args); @@ -342,6 +342,7 @@ xfs_dir_removename( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_remove); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; @@ -353,7 +354,6 @@ xfs_dir_removename( args.total = total; args.whichfork = XFS_DATA_FORK; args.trans = tp; - args.op_flags = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_removename(&args); @@ -425,6 +425,7 @@ xfs_dir_replace( if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) return rval; + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; @@ -436,7 +437,6 @@ xfs_dir_replace( args.total = total; args.whichfork = XFS_DATA_FORK; args.trans = tp; - args.op_flags = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_replace(&args); From owner-xfs@oss.sgi.com Sun Jun 1 22:49:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 22:49:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_47, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m525naOp010606 for ; Sun, 1 Jun 2008 22:49:36 -0700 X-ASG-Debug-ID: 1212385828-05f103290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6146E1B9B370; Sun, 1 Jun 2008 22:50:28 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id iYGtC207vq20oayH; Sun, 01 Jun 2008 22:50:28 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K32w8-0000yq-H4; Mon, 02 Jun 2008 05:50:28 +0000 Date: Mon, 2 Jun 2008 01:50:28 -0400 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c Subject: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c Message-ID: <20080602055028.GA1629@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212385829 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16222 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 02, 2008 at 03:42:55PM +1000, Barry Naujok wrote: > In particular, this patch fixes a problem in the xfs_dir2_remove and > xfs_dir2_replace paths which internally can call a lookup function > which will use args->cmpresult which is uninitialised. > Index: 2.6.x-xfs/fs/xfs/xfs_dir2.c > =================================================================== > --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2.c > +++ 2.6.x-xfs/fs/xfs/xfs_dir2.c > @@ -213,6 +213,7 @@ xfs_dir_createname( > if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) > return rval; > XFS_STATS_INC(xs_dir_create); > + memset(&args, 0, sizeof(xfs_da_args_t)); > > args.name = name->name; > args.namelen = name->len; Doing these memsets looks good. Stylisticly I'd rather put them directly in front of the intialization for the actually used args fields. From owner-xfs@oss.sgi.com Sun Jun 1 23:05:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 23:05:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5265nwL011526 for ; Sun, 1 Jun 2008 23:05:51 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA24162; Mon, 2 Jun 2008 16:06:33 +1000 To: "Christoph Hellwig" Subject: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c From: "Barry Naujok" Organization: SGI Cc: "xfs@oss.sgi.com" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <20080602055028.GA1629@infradead.org> Date: Mon, 02 Jun 2008 16:08:23 +1000 Message-ID: In-Reply-To: <20080602055028.GA1629@infradead.org> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from Quoted-Printable to 8bit by oss.sgi.com id m5265rwL011529 X-archive-position: 16223 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Mon, 02 Jun 2008 15:50:28 +1000, Christoph Hellwig wrote: > On Mon, Jun 02, 2008 at 03:42:55PM +1000, Barry Naujok wrote: >> In particular, this patch fixes a problem in the xfs_dir2_remove and >> xfs_dir2_replace paths which internally can call a lookup function >> which will use args->cmpresult which is uninitialised. > >> Index: 2.6.x-xfs/fs/xfs/xfs_dir2.c >> =================================================================== >> --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2.c >> +++ 2.6.x-xfs/fs/xfs/xfs_dir2.c >> @@ -213,6 +213,7 @@ xfs_dir_createname( >> if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) >> return rval; >> XFS_STATS_INC(xs_dir_create); >> + memset(&args, 0, sizeof(xfs_da_args_t)); >> >> args.name = name->name; >> args.namelen = name->len; > > Doing these memsets looks good. Stylisticly I'd rather put them > directly in front of the intialization for the actually used args > fields. I agree, so here's the alternative patch which makes them all consistent: Index: 2.6.x-xfs/fs/xfs/xfs_dir2.c =================================================================== --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2.c +++ 2.6.x-xfs/fs/xfs/xfs_dir2.c @@ -214,6 +214,7 @@ xfs_dir_createname( return rval; XFS_STATS_INC(xs_dir_create); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); @@ -286,8 +287,8 @@ xfs_dir_lookup( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_lookup); - memset(&args, 0, sizeof(xfs_da_args_t)); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); @@ -297,7 +298,6 @@ xfs_dir_lookup( args.op_flags = XFS_DA_OP_OKNOENT; if (ci_name) args.op_flags |= XFS_DA_OP_CILOOKUP; - args.cmpresult = XFS_CMP_DIFFERENT; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_lookup(&args); @@ -343,6 +343,7 @@ xfs_dir_removename( ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); XFS_STATS_INC(xs_dir_remove); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); @@ -353,7 +354,6 @@ xfs_dir_removename( args.total = total; args.whichfork = XFS_DATA_FORK; args.trans = tp; - args.op_flags = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_removename(&args); @@ -426,6 +426,7 @@ xfs_dir_replace( if ((rval = xfs_dir_ino_validate(tp->t_mountp, inum))) return rval; + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); @@ -436,7 +437,6 @@ xfs_dir_replace( args.total = total; args.whichfork = XFS_DATA_FORK; args.trans = tp; - args.op_flags = 0; if (dp->i_d.di_format == XFS_DINODE_FMT_LOCAL) rval = xfs_dir2_sf_replace(&args); @@ -472,8 +472,8 @@ xfs_dir_canenter( return 0; ASSERT((dp->i_d.di_mode & S_IFMT) == S_IFDIR); - memset(&args, 0, sizeof(xfs_da_args_t)); + memset(&args, 0, sizeof(xfs_da_args_t)); args.name = name->name; args.namelen = name->len; args.hashval = dp->i_mount->m_dirnameops->hashname(name); From owner-xfs@oss.sgi.com Sun Jun 1 23:08:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 01 Jun 2008 23:08:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m52682rh011882 for ; Sun, 1 Jun 2008 23:08:02 -0700 X-ASG-Debug-ID: 1212386935-05e403ba0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3EF2A1B9B6CD; Sun, 1 Jun 2008 23:08:55 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id I47Y3vnrBKmczeUn; Sun, 01 Jun 2008 23:08:55 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K33Dz-0004yT-Ck; Mon, 02 Jun 2008 06:08:55 +0000 Date: Mon, 2 Jun 2008 02:08:55 -0400 From: Christoph Hellwig To: Barry Naujok Cc: Christoph Hellwig , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c Subject: Re: REVIEW: Zero uninitialised xfs_da_args structure in xfs_dir2.c Message-ID: <20080602060855.GA25939@infradead.org> References: <20080602055028.GA1629@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212386936 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52118 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16224 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 02, 2008 at 04:08:23PM +1000, Barry Naujok wrote: > I agree, so here's the alternative patch which makes them all > consistent: Looks good. From owner-xfs@oss.sgi.com Mon Jun 2 06:38:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jun 2008 06:39:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m52DcqsW029194 for ; Mon, 2 Jun 2008 06:38:53 -0700 X-ASG-Debug-ID: 1212413985-1f7f002b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5C6021B9D2C7 for ; Mon, 2 Jun 2008 06:39:45 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.249]) by cuda.sgi.com with ESMTP id fY6lHI58AGLiqU88 for ; Mon, 02 Jun 2008 06:39:45 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so815302rvb.32 for ; Mon, 02 Jun 2008 06:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=n8oHevPOb1/PzCYnoPCrrBmg2/gf8fGv06tlLX1nXf4=; b=XLyGAu56dMlDY5FyjlMvgYIrtCEJYQIU+/WxZ59X7CURB34mMOp11k9IqXNBzKv8cAR6y4XFLf+1hOyXCh/1sZiBApf5BzmM7H7v6Rc14Jb5yEoJ+rmuU8iC664qjgKqNJNU5RXYvES9uZcwYx19mWzqyXZQs+LWJve8hP4R8lE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Z0WyMe+xk0SovtBvuY6D1d+CNYCCLsyIfAMtJ9WvNAAtIIW+0kib0wwAbXkwvDhKHv8E3tDsGQEl8IitfyFXwoq+XIUG6acbvlksPzu/fGiQoCy52F/IAlEFoM2ntxL4lJbO8+APG43kQ5B3ZFKaDWo4mE6CiKcSSQZo7QKcwTU= Received: by 10.141.13.16 with SMTP id q16mr4923585rvi.99.1212413985383; Mon, 02 Jun 2008 06:39:45 -0700 (PDT) Received: by 10.140.173.6 with HTTP; Mon, 2 Jun 2008 06:39:40 -0700 (PDT) Message-ID: <7b9198260806020639n7679035s270c0ce3575a894b@mail.gmail.com> Date: Mon, 2 Jun 2008 14:39:40 +0100 From: "Tom Spink" To: "Tom Spink" , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [RFC PATCH 0/2] On-demand Filesystem Initialisation Subject: Re: [RFC PATCH 0/2] On-demand Filesystem Initialisation In-Reply-To: <20080602015831.GB2428@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1212331915-22856-1-git-send-email-tspink@gmail.com> <20080602015831.GB2428@disturbed> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.249] X-Barracuda-Start-Time: 1212413986 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2804 1.0000 -0.4338 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.43 X-Barracuda-Spam-Status: No, SCORE=-0.43 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52148 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16225 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tspink@gmail.com Precedence: bulk X-list: xfs 2008/6/2 Dave Chinner : > On Sun, Jun 01, 2008 at 03:51:53PM +0100, Tom Spink wrote: >> >> (resend to include CCs) > > What cc's? Still no xfs cc on it. I added it to this reply.... > >> This (short) patch series is another RFC for the patch that introduces on-demand >> filesystem initialisation. In addition to the original infrastructure >> implementation (with clean-ups), it changes XFS to use this new infrastructure. >> >> I wrote a toy filesystem (testfs) to simulate scheduling/allocation delays and >> to torture the mount/unmount cycles. I didn't manage to deadlock the system >> in my tests. XFS also works as expected aswell, in that the global threads >> are not created until an XFS filesystem is mounted for the first time. When the >> last XFS filesystem is unmounted, the threads go away. >> >> Please let me know what you think! > > Why even bother? This is why we have /modular/ kernels - if you're > not using XFS then don't load it and you won't see those pesky > threads. That'll save on a bunch of memory as well because the xfs > module ain't small (>480k on i386).... Yeah, absolutely. But if the filesystem is built-in, you can't unload it. > Cheers, > > Dave. Thanks for taking a look, anyway! -- Tom Spink From owner-xfs@oss.sgi.com Mon Jun 2 17:15:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jun 2008 17:15:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m530Fips025383 for ; Mon, 2 Jun 2008 17:15:44 -0700 X-ASG-Debug-ID: 1212452195-0ad902cc0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from seznam.cz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 737F81DC81A for ; Mon, 2 Jun 2008 17:16:36 -0700 (PDT) Received: from seznam.cz (ds87-230-58-90.dedicated.hosteurope.de [87.230.58.90]) by cuda.sgi.com with ESMTP id s6UG6RCSXQeTtODO for ; Mon, 02 Jun 2008 17:16:36 -0700 (PDT) Reply-To: lanislav.novak@seznam.cz From: Karikatury.eu@oss.sgi.com To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Mohamed cartoons - Praha; Skandalni! Mohamed jako pedofil. Foto, Video, link reportaz; svoboda slova je zakladni hodnota! Subject: Mohamed cartoons - Praha; Skandalni! Mohamed jako pedofil. Foto, Video, link reportaz; svoboda slova je zakladni hodnota! Date: 03 Jun 2008 02:16:59 +0200 Message-ID: <20080603021658.BB5AE0FFD3DCA8F9@from.header.has.no.domain> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Barracuda-Connect: ds87-230-58-90.dedicated.hosteurope.de[87.230.58.90] X-Barracuda-Start-Time: 1212452197 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5530 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.85 X-Barracuda-Spam-Status: No, SCORE=0.85 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MANY_EXCLAMATIONS, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52190 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MANY_EXCLAMATIONS Subject has many exclamations 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16226 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Karikatury.eu@oss.sgi.com Precedence: bulk X-list: xfs Keywords: mohamed cartoons Rough cartoon: http://www.karikatury.eu/karikatura-mohamed-vrah-pedofil.jpg Czech version. -------- Dobry den, dne 31.5.2008 byly po Praze hromadne vylepovany karikatury mohameda. viz zpravy: http://www.novinky.cz/clanek/141314-v-praze-se-objevily-karikatury-s-mohamedem.html http://zpravy.idnes.cz/karikatury-proroka-mohameda-se-objevily-i-v-praze-fvg-/praha.asp?c=A080531_195031_praha_jan www.karikatury.eu (foto, karikatury, + filmy ke stazeni zdarma) Jako naprosto nehorazna reakce na tzv. "danske karikatury" bylo v roce 2006 zabito mnoho lidi a spachano mnoho teroru ze strany muslimu. Evropska unie, misto aby podporila severske staty, jimz byly niceny ambasady, se omluvila muslimskemu svetu! Je dulezite podotknout, ze svoboda slova je nevyslovnekrat dulezitejsi nez jakekoliv nabozenstvi... alespon v Evrope. V moderni sekularni spolecnosti je chovani muslimu (u vetsiny zatim pouze postoje a nazory) neakceptovatelne. Konflikt ohledne karikatur (a vy se na ne nyni mate moznost podivat -a posoudit zdali je akceptovatelne ze muslimsky svet vola po vyhlazeni Danska a pacha teror kvuli par obrazkum) ... ukazuje na stret civilizaci. Predevsim islam ma "krvave hranice", a jedna se o nabozenstvi, ktere dosud neprekonalo stredoveky koncept. Spousta problemu vznikla diky velkoryse imigracni politice zapadnich evropskych zemi (ktera byla vzhledek ke stavu na pracovnim trhu proklamovana za nutnou:(, jejiz predstavitele pokladali imigranty z rizikovych oblasti (tam kde jsou spolecnosti ovladane islamem) jako za rovnocene napriklad pristehovalcum z Ciny / Indie / Vietnamu. Nasledkem toho je fakt, ze drtiva vetsina teroristickych utoku za poslednich 15 let byla zpusobena temito muslimskymi imigranty. Experti, jez se zabyvaji bezpecnosti vi, ze muslimske minority predstavuji zasadni bezpecnostni riziko. Celkova idea podpory imigrace, predevsim muslimu, byla spatna - mnoho pristehovalcu (zejmena z druhe generace) se citi vykoreneni ze sve kultury a zaroven se nestotoznuji se zapadnim zivotem > I utoky na WTC byly zpusobeny rekruty z vyse nastineneho prostredi. Presto politici neuznali svou chybu! Naopak, tehdejsi pojeti imigrace, jez zpusobilo soucasny stav, stale pokracuje. Misto, aby politicke reprezentace uznaly, ze muslimske minority prinaseji bezpecnostni riziko (s tim jak rostou-se rizika zvetsuji!), tak dochazi k erozi svobody vetsinove spolecnosti. Kdo cestuje letadlem, tak si uvedomuje zprisneni kontrol a bezpecnostnich podminek za posledni roky. Kamery na kazdem rohu je podobna zalezitost. A v posledni dobe je patrny stale vetsi natlak na prispusobovani se muslimskym minoritam. Predevsim v otazce karikatur. Je zde duvod - strach z reakce muslimu. Ovsem pokud se muslimu musime obavat, pak je tu problem, ze?! A ten problem je predevsim v zemich kam se pristehovaly extremne velke muslimske minority (jako napriklad Holansko - kde byl napriklad zabyt filmar jen proto ze muslim proti nemu vedl "dzihad"), nebo ne? Ne tak docela. I ceska vlada planuje prijimat spousty imigrantu - A NEHODLA ZAUJMOUT SELEKTIVNI PRISTUP! STOP IMIGRACI, alespon te muslimske, dokud u islamu - podobne jako kdysi u ostatnich nabozenstvi - nepomine stredovek. Stop erozi nasich univerzalnich svobod. Islam ... vime ze toto nabozensti vynucuje "svou vuli" na uzemi jez si podmanilo (napr. Darfur). Je treba, abychom my, Evropane - kdyz politicka reprezentace nas strach o bezpecnost a nase hodnoty a svobodu nerespektuje - ukazali, ze zde jsme v SEKULARNI SVOBODNE SPOLECNOSTI. Pokud muslimove pokladaji islamska pravidla za nadrazenejsi nasim (nedavno) samozrejmym hodnotam a pravidlum - pak tu nemaji co delat! Nebo je alespon nutne zastavit priliv novych imigrantu z techto oblasti - nad cimz ma kazdy stat plnou suverenitu. Praktikujme svoji svobodu! (Kdo vi jak bude Evropa vypadat za 15 let pokud zde bude posilovat vliv nebezpecneho islamu). Podivejte se na fotografie z terenu - vylepy po Praze na webu jez doporucujeme shlednout. Mame 6 brigadnic (ktere nemaji radi islam kvuli stavu zenskych prav pod islamem) ktere budou nadale lepit karikatury po CR ....a hledame dalsi spolupracovniky/spolupracovnice jez budou vylepovat karikatury/reklamy i v ostatnich zemich EU. Nejedna se o provokaci, ale o upozorneni na problem. Tento email je castecne siren jako mass mail a castecne ho prijemci preposilaji dal. Pokud Vam tento problem neni lhostejny, preposilejte dal. www.karikatury.eu - prohlednete si karikatury, fotografie z terenu (nase vylepy po Praze) a spoustu Filmu a vice... Izabela From owner-xfs@oss.sgi.com Mon Jun 2 18:07:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jun 2008 18:07:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5317lHC028933 for ; Mon, 2 Jun 2008 18:07:49 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16986; Tue, 3 Jun 2008 11:08:36 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id A9BDB58C4C3F; Tue, 3 Jun 2008 11:08:36 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 982421 - xfs_repair: Doesn't work with 16KB filesystem blocksize. Message-Id: <20080603010836.A9BDB58C4C3F@chook.melbourne.sgi.com> Date: Tue, 3 Jun 2008 11:08:36 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16227 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Fix up inode cluster I/O size in repair for >8KB block size filesystems Date: Tue Jun 3 11:07:54 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31267a xfsprogs/repair/xfs_repair.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/xfs_repair.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h xfsprogs/repair/prefetch.c - 1.6 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/repair/prefetch.c.diff?r1=text&tr1=1.6&r2=text&tr2=1.5&f=h - Fix up inode cluster I/O size in repair for >8KB block size filesystems From owner-xfs@oss.sgi.com Mon Jun 2 18:47:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 02 Jun 2008 18:47:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m531lrof031651 for ; Mon, 2 Jun 2008 18:47:54 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA17821; Tue, 3 Jun 2008 11:48:42 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id C552F58C4C3F; Tue, 3 Jun 2008 11:48:42 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 982606 - Strange unlink behaviour Message-Id: <20080603014842.C552F58C4C3F@chook.melbourne.sgi.com> Date: Tue, 3 Jun 2008 11:48:42 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16228 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Zero uninitialised xfs_da_args structure in xfs_dir2.c Fixes a problem in the xfs_dir2_remove and xfs_dir2_replace paths which intenally call directory format specific lookup funtions that assume args->cmpresult is zeroed. Date: Tue Jun 3 11:47:47 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/2.6.x-xfs Inspected by: hch@infradead.org The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31268a fs/xfs/xfs_dir2.c - 1.69 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2.c.diff?r1=text&tr1=1.69&r2=text&tr2=1.68&f=h - Zero uninitialised xfs_da_args structures From owner-xfs@oss.sgi.com Tue Jun 3 00:59:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 00:59:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m537xZwI029253 for ; Tue, 3 Jun 2008 00:59:35 -0700 X-ASG-Debug-ID: 1212480027-1fb502350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D3D251DD5B3 for ; Tue, 3 Jun 2008 01:00:27 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id uHpVlzzAGewAgWtn for ; Tue, 03 Jun 2008 01:00:27 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5380JOc019801 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 10:00:20 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5380JUv019799 for xfs@oss.sgi.com; Tue, 3 Jun 2008 10:00:19 +0200 Date: Tue, 3 Jun 2008 10:00:19 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] fix mount option parsing in remount Subject: Re: [PATCH] fix mount option parsing in remount Message-ID: <20080603080019.GB19608@lst.de> References: <20080518153539.GA5218@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080518153539.GA5218@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212480028 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52221 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16230 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs ping? silently ignoring wrong options causes a lot of confusion for users, and the patch sould simple enough. Anyone take 10 minutes to review it and check it in? On Sun, May 18, 2008 at 05:35:39PM +0200, Christoph Hellwig wrote: > Remount currently happily accept any option thrown at it, although the > only filesystem specific option it actually handles is barrier/nobarrier. > And it actually doesn't handle these correctly either because it only > uses the value it parsed when we're doing a ro->rw transition. In > addition to that there's also a bad bug in xfs_parseargs which doesn't > touch the actual option in the mount point except for a single one, > XFS_MOUNT_SMALL_INUMS and thus forced any filesystem that's every > remounted in some way to not support 64bit inodes with no way to recover > unless unmounted. > > This patch changes xfs_fs_remount to use it's own linux/parser.h based > options parse instead of xfs_parseargs and reject all options except > for barrier/nobarrier and to the right thing in general. Eventually > I'd like to have a single big option table used for mount aswell but > that can wait for a while. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2008-05-18 15:22:23.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-05-18 15:59:32.000000000 +0200 > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > static struct quotactl_ops xfs_quotactl_operations; > static struct super_operations xfs_super_operations; > @@ -1255,6 +1256,19 @@ xfs_fs_statfs( > return 0; > } > > +/* > + * Eventually we should extend this table and use it for mount, too. > + */ > +enum { > + Opt_barrier, Opt_nobarrier, Opt_err > +}; > + > +static match_table_t tokens = { > + {Opt_barrier, "barrier"}, > + {Opt_nobarrier, "nobarrier"}, > + {Opt_err, NULL} > +}; > + > STATIC int > xfs_fs_remount( > struct super_block *sb, > @@ -1262,36 +1276,54 @@ xfs_fs_remount( > char *options) > { > struct xfs_mount *mp = XFS_M(sb); > - struct xfs_mount_args *args; > - int error; > + substring_t args[MAX_OPT_ARGS]; > + char *p; > > - args = xfs_args_allocate(sb, 0); > - if (!args) > - return -ENOMEM; > + while ((p = strsep(&options, ",")) != NULL) { > + int token; > > - error = xfs_parseargs(mp, options, args, 1); > - if (error) > - goto out_free_args; > + if (!*p) > + continue; > > - if (!(*flags & MS_RDONLY)) { /* rw/ro -> rw */ > - if (mp->m_flags & XFS_MOUNT_RDONLY) > - mp->m_flags &= ~XFS_MOUNT_RDONLY; > - if (args->flags & XFSMNT_BARRIER) { > + token = match_token(p, tokens, args); > + switch (token) { > + case Opt_barrier: > mp->m_flags |= XFS_MOUNT_BARRIER; > - xfs_mountfs_check_barriers(mp); > - } else { > + > + /* > + * Test if barriers are actually working if we can, > + * else delay this check until the filesystem is > + * marked writeable. > + */ > + if (!(mp->m_flags & XFS_MOUNT_RDONLY)) > + xfs_mountfs_check_barriers(mp); > + break; > + case Opt_nobarrier: > mp->m_flags &= ~XFS_MOUNT_BARRIER; > + break; > + default: > + printk(KERN_INFO > + "XFS: mount option \"%s\" not support for remount\n", p); > + return -EINVAL; > } > - } else if (!(mp->m_flags & XFS_MOUNT_RDONLY)) { /* rw -> ro */ > + } > + > + /* rw/ro -> rw */ > + if ((mp->m_flags & XFS_MOUNT_RDONLY) && !(*flags & MS_RDONLY)) { > + mp->m_flags &= ~XFS_MOUNT_RDONLY; > + if (mp->m_flags & XFS_MOUNT_BARRIER) > + xfs_mountfs_check_barriers(mp); > + } > + > + /* rw -> ro */ > + if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & MS_RDONLY)) { > xfs_filestream_flush(mp); > xfs_sync(mp, SYNC_DATA_QUIESCE); > xfs_attr_quiesce(mp); > mp->m_flags |= XFS_MOUNT_RDONLY; > } > > - out_free_args: > - kfree(args); > - return -error; > + return 0; > } > > /* ---end quoted text--- From owner-xfs@oss.sgi.com Tue Jun 3 00:58:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 00:58:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m537wCmG028995 for ; Tue, 3 Jun 2008 00:58:14 -0700 X-ASG-Debug-ID: 1212479944-3793021c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F1A3E176C257 for ; Tue, 3 Jun 2008 00:59:04 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id I72cZVicCpxh43vY for ; Tue, 03 Jun 2008 00:59:04 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m537wuOc019720 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 09:58:56 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m537wu8M019718 for xfs@oss.sgi.com; Tue, 3 Jun 2008 09:58:56 +0200 Date: Tue, 3 Jun 2008 09:58:55 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] scale down 074 on lower end machines Subject: Re: [PATCH] scale down 074 on lower end machines Message-ID: <20080603075855.GA19608@lst.de> References: <20080515173913.GA11494@lst.de> <20080521081552.GB2398@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080521081552.GB2398@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212479946 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52221 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16229 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs ping^2 On Wed, May 21, 2008 at 10:15:52AM +0200, Christoph Hellwig wrote: > ping? > > On Thu, May 15, 2008 at 07:39:13PM +0200, Christoph Hellwig wrote: > > 074 takes ages to complete on my kvm test VM, but scaling it back to the > > level used on IRIX makes it complete in slightly under 10 minutes. > > > > I'm not sure if checking for UP vs SMP is the right way to go into slow > > mode, but I couldn't think of anything better. > > > > > > Signed-off-by: Christoph Hellwig > > > > Index: xfstests/074 > > =================================================================== > > RCS file: /cvs/xfs-cmds/xfstests/074,v > > retrieving revision 1.7 > > diff -u -p -r1.7 074 > > --- xfstests/074 9 Nov 2005 02:49:08 -0000 1.7 > > +++ xfstests/074 15 May 2008 17:37:03 -0000 > > @@ -120,10 +120,17 @@ if [ $HOSTOS == "IRIX" ]; then > > param_type="IRIX nondebug" > > fi > > elif [ $HOSTOS == "Linux" ]; then > > - numloops=10 > > - numfiles=5 > > - numchildren=3 > > - param_type="Linux" > > + if uname -a | grep -q SMP; then > > + numloops=10 > > + numfiles=5 > > + numchildren=3 > > + param_type="Linux SMP" > > + else > > + numloops=2 > > + numfiles=3 > > + numchildren=3 > > + param_type="Linux UP" > > + fi > > else > > numloops=1 > > numfiles=1 > ---end quoted text--- ---end quoted text--- From owner-xfs@oss.sgi.com Tue Jun 3 04:39:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 04:39:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53BdAnU016084 for ; Tue, 3 Jun 2008 04:39:11 -0700 X-ASG-Debug-ID: 1212493203-755101a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 692051DE2F8 for ; Tue, 3 Jun 2008 04:40:03 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id jTq5FFMzks6vWkAf for ; Tue, 03 Jun 2008 04:40:03 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m53BdtOc002844 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 13:39:55 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m53BdtEt002842 for xfs@oss.sgi.com; Tue, 3 Jun 2008 13:39:55 +0200 Date: Tue, 3 Jun 2008 13:39:55 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] factor out inode has attrs check Subject: [PATCH] factor out inode has attrs check Message-ID: <20080603113955.GA2703@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212493204 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52235 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16231 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Note that xfs_attr_fetch did the check twice while keeping the inode locked and we can just remove the superflous check. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:32:06.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 @@ -111,6 +111,17 @@ xfs_attr_name_to_xname( return 0; } +STATIC int +xfs_inode_hasattr( + struct xfs_inode *ip) +{ + if (!XFS_IFORK_Q(ip) || + (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && + ip->i_d.di_anextents == 0)) + return 0; + return 1; +} + /*======================================================================== * Overall external interface routines. *========================================================================*/ @@ -122,10 +133,8 @@ xfs_attr_fetch(xfs_inode_t *ip, struct x xfs_da_args_t args; int error; - if ((XFS_IFORK_Q(ip) == 0) || - (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - ip->i_d.di_anextents == 0)) - return(ENOATTR); + if (!xfs_inode_hasattr(ip)) + return ENOATTR; /* * Fill in the arg structure for this request. @@ -143,11 +152,7 @@ xfs_attr_fetch(xfs_inode_t *ip, struct x /* * Decide on what work routines to call based on the inode size. */ - if (XFS_IFORK_Q(ip) == 0 || - (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - ip->i_d.di_anextents == 0)) { - error = XFS_ERROR(ENOATTR); - } else if (ip->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { + if (ip->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { error = xfs_attr_shortform_getvalue(&args); } else if (xfs_bmap_one_block(ip, XFS_ATTR_FORK)) { error = xfs_attr_leaf_get(&args); @@ -523,9 +528,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, str /* * Decide on what work routines to call based on the inode size. */ - if (XFS_IFORK_Q(dp) == 0 || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp)) { error = XFS_ERROR(ENOATTR); goto out; } @@ -595,11 +598,9 @@ xfs_attr_remove( return error; xfs_ilock(dp, XFS_ILOCK_SHARED); - if (XFS_IFORK_Q(dp) == 0 || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp)) { xfs_iunlock(dp, XFS_ILOCK_SHARED); - return(XFS_ERROR(ENOATTR)); + return XFS_ERROR(ENOATTR); } xfs_iunlock(dp, XFS_ILOCK_SHARED); @@ -615,9 +616,7 @@ xfs_attr_list_int(xfs_attr_list_context_ /* * Decide on what work routines to call based on the inode size. */ - if (XFS_IFORK_Q(dp) == 0 || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp)) { error = 0; } else if (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { error = xfs_attr_shortform_list(context); @@ -810,12 +809,10 @@ xfs_attr_inactive(xfs_inode_t *dp) ASSERT(! XFS_NOT_DQATTACHED(mp, dp)); xfs_ilock(dp, XFS_ILOCK_SHARED); - if ((XFS_IFORK_Q(dp) == 0) || - (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp) || + dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { xfs_iunlock(dp, XFS_ILOCK_SHARED); - return(0); + return 0; } xfs_iunlock(dp, XFS_ILOCK_SHARED); @@ -848,10 +845,8 @@ xfs_attr_inactive(xfs_inode_t *dp) /* * Decide on what work routines to call based on the inode size. */ - if ((XFS_IFORK_Q(dp) == 0) || - (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) || - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && - dp->i_d.di_anextents == 0)) { + if (!xfs_inode_hasattr(dp) || + dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { error = 0; goto out; } From owner-xfs@oss.sgi.com Tue Jun 3 04:48:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 04:48:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53Bm43T016939 for ; Tue, 3 Jun 2008 04:48:04 -0700 X-ASG-Debug-ID: 1212493736-608802d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB9901DE1C7 for ; Tue, 3 Jun 2008 04:48:56 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id C8bfQEZg1Qee0TMr for ; Tue, 03 Jun 2008 04:48:56 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m53BmmOc003407 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 13:48:48 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m53BmmbL003405 for xfs@oss.sgi.com; Tue, 3 Jun 2008 13:48:48 +0200 Date: Tue, 3 Jun 2008 13:48:48 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/2] dmapi: use ->put_listen callback directly Subject: [PATCH 2/2] dmapi: use ->put_listen callback directly Message-ID: <20080603114848.GC2703@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212493737 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_MJ615 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_MJ615 Custom Rule MJ615 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16233 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Rewrite xfs_dm_getall_dmattr to directly call xfs_list_attr_int in fill the userspace buffer directly from the listent. Doing the direct put means the need for the large kernel space buffer is gone, there is only one btree traversal needed and thus the list vs get race is fixed. By doing the proper put_user/copy_to_user the direct userspace memory derference is fixed, too and the code is a lot simpler and easier to understand. This patch passes xfsqa but I don't really trust it much vs dmapi, so please review carefully. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2008-06-01 14:45:20.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-06-03 12:00:22.000000000 +0200 @@ -2092,149 +2092,136 @@ xfs_dm_get_region( } +#define DM_GETALL_DMATTR_ALIGN (sizeof(int) - 1) + STATIC int -xfs_dm_getall_dmattr( - struct inode *inode, - dm_right_t right, - size_t buflen, - void __user *bufp, - size_t __user *rlenp) +xfs_dm_put_listent( + xfs_attr_list_context_t *context, + int flags, + char *name, + int namelen, + int valuelen, + char *value) { - attrlist_cursor_kern_t cursor; - attrlist_t *attrlist; - dm_attrlist_t __user *ulist; - int *last_link; - int alignment; - int total_size; - int list_size = 8192; /* should be big enough */ - int error; + dm_attrlist_t __user *ulist; + int size_needed; - /* Returns negative errors to DMAPI */ + ASSERT(context->count >= 0); - if (right < DM_RIGHT_SHARED) - return(-EACCES); + /* + * Skip over all non-DMAPI attributes. If the attribute name is too + * long, we assume it is non-DMAPI even if it starts with the correct + * prefix. + */ + if (!(flags & XFS_ATTR_ROOT)) + return 0; + if (namelen > DM_ATTR_NAME_SIZE) + return 0; + if (strncmp(name, dmattr_prefix, DMATTR_PREFIXLEN)) + return 0; - /* Verify that the user gave us a buffer that is 4-byte aligned, lock - it down, and work directly within that buffer. As a side-effect, - values of buflen < sizeof(int) return EINVAL. - */ + size_needed = sizeof(dm_attrlist_t) + valuelen; + size_needed = (size_needed + DM_GETALL_DMATTR_ALIGN) & + ~DM_GETALL_DMATTR_ALIGN; - alignment = sizeof(int) - 1; - if ((((__psint_t)bufp & alignment) != 0) || - !access_ok(VERIFY_WRITE, bufp, buflen)) { - return(-EFAULT); + /* + * We have a valid DMAPI attribute to return. If it won't fit in the + * user's buffer, we still need to keep track of the number of bytes + * for the user's next call. + */ + context->count += size_needed; + if (context->count > context->bufsize) { + context->seen_enough = 1; + return 1; + } + + ulist = (dm_attrlist_t __user __force *) + (context->alist + context->count); + + if (copy_to_user(ulist->al_name.an_chars, name, namelen) || + clear_user(ulist->al_name.an_chars + namelen, + DM_ATTR_NAME_SIZE - namelen) || + put_user(sizeof(dm_attrlist_t), &ulist->al_data.vd_offset) || + put_user(valuelen, &ulist->al_data.vd_length) || + put_user(size_needed, &ulist->_link) || + copy_to_user(ulist + 1, value, valuelen)) { + context->count = -1; + return 1; } - buflen &= ~alignment; /* round down the alignment */ - /* Initialize all the structures and variables for the main loop. */ + context->last_link = &ulist->_link; + return 0; +} - memset(&cursor, 0, sizeof(cursor)); - attrlist = (attrlist_t *)kmem_alloc(list_size, KM_SLEEP); - total_size = 0; - ulist = (dm_attrlist_t *)bufp; - last_link = NULL; - - /* Use vop_attr_list to get the names of DMAPI attributes, and use - vop_attr_get to get their values. There is a risk here that the - DMAPI attributes could change between the vop_attr_list and - vop_attr_get calls. If we can detect it, we return EIO to notify - the user. - */ +STATIC int +xfs_dm_getall_dmattr( + struct inode *inode, + dm_right_t right, + size_t buflen, + void __user *bufp, + size_t __user *rlenp) +{ + xfs_attr_list_context_t context; + attrlist_cursor_kern_t cursor = { 0, }; + int error; - do { - int i; + if (right < DM_RIGHT_SHARED) + return -EACCES; - /* Get a buffer full of attribute names. If there aren't any - more or if we encounter an error, then finish up. - */ + /* verify that the user gave us a buffer that is 4-byte aligned */ + if ((unsigned long)bufp & DM_GETALL_DMATTR_ALIGN) + return -EFAULT; - error = xfs_attr_list(XFS_I(inode), (char *)attrlist, list_size, - ATTR_ROOT, &cursor); - DM_EA_XLATE_ERR(error); + /* round down the alignment */ + buflen &= ~DM_GETALL_DMATTR_ALIGN; - if (error || attrlist->al_count == 0) - break; + memset(&context, 0, sizeof(context)); + context.dp = XFS_I(inode); + context.cursor = &cursor; + context.resynch = 1; + context.flags = ATTR_ROOT; + /* alist is just a cookie */ + context.alist = (char * __force)bufp; + context.bufsize = buflen; + context.put_value = 1; + context.put_listent = xfs_dm_put_listent; - for (i = 0; i < attrlist->al_count; i++) { - attrlist_ent_t *entry; - char *user_name; - int size_needed; - int value_len; - - /* Skip over all non-DMAPI attributes. If the - attribute name is too long, we assume it is - non-DMAPI even if it starts with the correct - prefix. - */ - - entry = ATTR_ENTRY(attrlist, i); - if (strncmp(entry->a_name, dmattr_prefix, DMATTR_PREFIXLEN)) - continue; - user_name = &entry->a_name[DMATTR_PREFIXLEN]; - if (strlen(user_name) > DM_ATTR_NAME_SIZE) - continue; - - /* We have a valid DMAPI attribute to return. If it - won't fit in the user's buffer, we still need to - keep track of the number of bytes for the user's - next call. - */ - - - size_needed = sizeof(*ulist) + entry->a_valuelen; - size_needed = (size_needed + alignment) & ~alignment; - - total_size += size_needed; - if (total_size > buflen) - continue; - - /* Start by filling in all the fields in the - dm_attrlist_t structure. - */ - - strncpy((char *)ulist->al_name.an_chars, user_name, - DM_ATTR_NAME_SIZE); - ulist->al_data.vd_offset = sizeof(*ulist); - ulist->al_data.vd_length = entry->a_valuelen; - ulist->_link = size_needed; - last_link = &ulist->_link; - - /* Next read the attribute's value into its correct - location after the dm_attrlist structure. Any sort - of error indicates that the data is moving under us, - so we return EIO to let the user know. - */ - - value_len = entry->a_valuelen; - - error = xfs_attr_get(XFS_I(inode), entry->a_name, - (void *)(ulist + 1), &value_len, - ATTR_ROOT); - DM_EA_XLATE_ERR(error); - - if (error || value_len != entry->a_valuelen) { - error = EIO; - break; - } + error = -xfs_attr_list_int(&context); + ASSERT(error <= 0); - ulist = (dm_attrlist_t *)((char *)ulist + ulist->_link); - } - } while (!error && attrlist->al_more); - if (last_link) - *last_link = 0; - - if (!error && total_size > buflen) - error = E2BIG; - if (!error || error == E2BIG) { - if (put_user(total_size, rlenp)) - error = EFAULT; + /* + * Count smaller zero means the iterator got an EFAULT. + * + * XXX(hch): we badly need a better way to deal with this, including + * passing and actual errno value back from the iterator. + */ + if (context.count < 0) + return -EFAULT; + + /* + * Terminate the list if we were successfull. + */ + if (context.last_link && put_user(0, context.last_link)) + return -EFAULT; + + if (!error) { + /* + * We still need to copy the count member to userspace in the + * case where there was not enough buffer space for the request. + * + * The ABI defines a count bigger as the passed in buffer length + * as indicator for requiring to call again with a bigger buffer. + */ + if (context.count > buflen) + error = -E2BIG; + + if (put_user(context.count, rlenp)) + error = -EFAULT; } - kmem_free(attrlist); - return(-error); /* Return negative error to DMAPI */ + return error; } - /* ARGSUSED */ STATIC int xfs_dm_getall_inherit( Index: linux-2.6-xfs/fs/xfs/xfs_attr.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-03 09:56:25.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-03 11:45:11.000000000 +0200 @@ -119,6 +119,7 @@ typedef struct xfs_attr_list_context { int put_value; /* T/F: need value for listent */ put_listent_func_t put_listent; /* list output fmt function */ int index; /* index into output buffer */ + int __user *last_link; /* list terminator */ } xfs_attr_list_context_t; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-03 12:01:08.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-03 12:01:13.000000000 +0200 @@ -262,7 +262,7 @@ EXPORT_SYMBOL(xfs_attr_get); EXPORT_SYMBOL(xfs_attr_set); EXPORT_SYMBOL(xfs_fsync); EXPORT_SYMBOL(xfs_attr_remove); -EXPORT_SYMBOL(xfs_attr_list); +EXPORT_SYMBOL(xfs_attr_list_int); EXPORT_SYMBOL(xfs_readdir); EXPORT_SYMBOL(xfs_setsize_buftarg); EXPORT_SYMBOL(xfs_syncsub); From owner-xfs@oss.sgi.com Tue Jun 3 04:47:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 04:47:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53BlteS016877 for ; Tue, 3 Jun 2008 04:47:55 -0700 X-ASG-Debug-ID: 1212493726-0a3801650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1887D1DE1C5 for ; Tue, 3 Jun 2008 04:48:46 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id m8SHHxb9PBy1TqFr for ; Tue, 03 Jun 2008 04:48:46 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m53BmcOc003392 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 3 Jun 2008 13:48:38 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m53BmcoA003390 for xfs@oss.sgi.com; Tue, 3 Jun 2008 13:48:38 +0200 Date: Tue, 3 Jun 2008 13:48:38 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/2] simplify xfs_vn_listxattr Subject: [PATCH 1/2] simplify xfs_vn_listxattr Message-ID: <20080603114837.GB2703@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212493728 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16232 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs This patch switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. The changes to the lowleve attr code are: - the put_listent callback now gets the ondisk flags passed and performce the namespace lookup and check aswell as the check for the right attribute root itself - xfs_attr_list_int is made non-static for use by other callers than xfs_attr_list and now performs the inode locking and tracing itself The changes to the xfs_attr_list path are: - all checks for now uneeded ATTR_KERN flags are gone, and only the IRIX interface is supported for this code path - xfs_attr_put_listent is simplified by not needing to lookup the namespace but rather compare the integer flags directly. The changes to xfs_vn_listxattr are: - now directly calls xfs_attr_list_int with it's own put_listent callbacks - attr namespace prefix are now looked up by simple helpers, struct attrnames is gone. Other changes: - struct xfs_attr_list_context is moved from xfs_attr_leaf.h into xfs_attr.h. It's not realted to the leaf format at all and xfs_attr.h contains the interface to the attr code which it is part of now. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:44:07.000000000 +0200 @@ -16,8 +16,6 @@ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#include - #include "xfs.h" #include "xfs_fs.h" #include "xfs_types.h" @@ -607,12 +605,20 @@ xfs_attr_remove( return xfs_attr_remove_int(dp, &xname, flags); } -STATIC int +int xfs_attr_list_int(xfs_attr_list_context_t *context) { int error; xfs_inode_t *dp = context->dp; + XFS_STATS_INC(xs_attr_list); + + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) + return EIO; + + xfs_ilock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall start", context); + /* * Decide on what work routines to call based on the inode size. */ @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ } else { error = xfs_attr_node_list(context); } + + xfs_iunlock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall end", context); + return error; } @@ -634,6 +644,18 @@ xfs_attr_list_int(xfs_attr_list_context_ ((ATTR_ENTBASESIZE + (namelen) + 1 + sizeof(u_int32_t)-1) \ & ~(sizeof(u_int32_t)-1)) +STATIC int +xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) +{ + if (((arg_flags & ATTR_SECURE) == 0) != + ((ondisk_flags & XFS_ATTR_SECURE) == 0)) + return 0; + if (((arg_flags & ATTR_ROOT) == 0) != + ((ondisk_flags & XFS_ATTR_ROOT) == 0)) + return 0; + return 1; +} + /* * Format an attribute and copy it out to the user's buffer. * Take care to check values and protect against them changing later, @@ -641,74 +663,43 @@ xfs_attr_list_int(xfs_attr_list_context_ */ /*ARGSUSED*/ STATIC int -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, char *name, int namelen, int valuelen, char *value) { + struct attrlist *alist = (struct attrlist *)context->alist; attrlist_ent_t *aep; int arraytop; ASSERT(!(context->flags & ATTR_KERNOVAL)); ASSERT(context->count >= 0); ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); - ASSERT(context->firstu >= sizeof(*context->alist)); + ASSERT(context->firstu >= sizeof(*alist)); ASSERT(context->firstu <= context->bufsize); - arraytop = sizeof(*context->alist) + - context->count * sizeof(context->alist->al_offset[0]); + if (xfs_attr_namesp_match_overrides(context->flags, flags)) + return 0; + + arraytop = sizeof(*alist) + + context->count * sizeof(alist->al_offset[0]); context->firstu -= ATTR_ENTSIZE(namelen); if (context->firstu < arraytop) { xfs_attr_trace_l_c("buffer full", context); - context->alist->al_more = 1; + alist->al_more = 1; context->seen_enough = 1; return 1; } - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); + aep = (attrlist_ent_t *)&context->alist[context->firstu]; aep->a_valuelen = valuelen; memcpy(aep->a_name, name, namelen); - aep->a_name[ namelen ] = 0; - context->alist->al_offset[ context->count++ ] = context->firstu; - context->alist->al_count = context->count; + aep->a_name[namelen] = 0; + alist->al_offset[context->count++] = context->firstu; + alist->al_count = context->count; xfs_attr_trace_l_c("add", context); return 0; } -STATIC int -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - char *offset; - int arraytop; - - ASSERT(context->count >= 0); - - arraytop = context->count + namesp->attr_namelen + namelen + 1; - if (arraytop > context->firstu) { - context->count = -1; /* insufficient space */ - return 1; - } - offset = (char *)context->alist + context->count; - strncpy(offset, namesp->attr_name, namesp->attr_namelen); - offset += namesp->attr_namelen; - strncpy(offset, name, namelen); /* real name */ - offset += namelen; - *offset = '\0'; - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - -/*ARGSUSED*/ -STATIC int -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - /* * Generate a list of extended attribute names and optionally * also value lengths. Positive return value follows the XFS @@ -725,10 +716,9 @@ xfs_attr_list( attrlist_cursor_kern_t *cursor) { xfs_attr_list_context_t context; + struct attrlist *alist; int error; - XFS_STATS_INC(xs_attr_list); - /* * Validate the cursor. */ @@ -749,52 +739,21 @@ xfs_attr_list( /* * Initialize the output buffer. */ + memset(&context, 0, sizeof(context)); context.dp = dp; context.cursor = cursor; - context.count = 0; - context.dupcnt = 0; context.resynch = 1; context.flags = flags; - context.seen_enough = 0; - context.alist = (attrlist_t *)buffer; - context.put_value = 0; - - if (flags & ATTR_KERNAMELS) { - context.bufsize = bufsize; - context.firstu = context.bufsize; - if (flags & ATTR_KERNOVAL) - context.put_listent = xfs_attr_kern_list_sizes; - else - context.put_listent = xfs_attr_kern_list; - } else { - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ - context.firstu = context.bufsize; - context.alist->al_count = 0; - context.alist->al_more = 0; - context.alist->al_offset[0] = context.bufsize; - context.put_listent = xfs_attr_put_listent; - } - - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) - return EIO; + context.alist = buffer; + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ + context.firstu = context.bufsize; + context.put_listent = xfs_attr_put_listent; - xfs_ilock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall start", &context); + alist = (struct attrlist *)context.alist; + alist->al_offset[0] = context.bufsize; error = xfs_attr_list_int(&context); - - xfs_iunlock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall end", &context); - - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { - /* must return negated buffer size or the error */ - if (context.count < 0) - error = XFS_ERROR(ERANGE); - else - error = -context.count; - } else - ASSERT(error >= 0); - + ASSERT(error >= 0); return error; } @@ -2357,12 +2316,7 @@ xfs_attr_trace_enter(int type, char *whe (void *)((__psunsigned_t)context->bufsize), (void *)((__psunsigned_t)context->count), (void *)((__psunsigned_t)context->firstu), - (void *)((__psunsigned_t) - (((context->count > 0) && - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) - ? (ATTR_ENTRY(context->alist, - context->count-1)->a_valuelen) - : 0)), + NULL, (void *)((__psunsigned_t)context->dupcnt), (void *)((__psunsigned_t)context->flags), (void *)a13, (void *)a14, (void *)a15); Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:44:07.000000000 +0200 @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att * Namespace helper routines *========================================================================*/ -STATIC_INLINE attrnames_t * -xfs_attr_flags_namesp(int flags) -{ - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); -} - /* * If namespace bits don't match return 0. * If all match then return 1. @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); } -/* - * If namespace bits don't match and we don't have an override for it - * then return 0. - * If all match or are overridable then return 1. - */ -STATIC_INLINE int -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) -{ - if (((arg_flags & ATTR_SECURE) == 0) != - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && - !(arg_flags & ATTR_KERNORMALS)) - return 0; - if (((arg_flags & ATTR_ROOT) == 0) != - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && - !(arg_flags & ATTR_KERNROOTLS)) - return 0; - return 1; -} - /*======================================================================== * External routines when attribute fork size < XFS_LITINO(mp). @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co (XFS_ISRESET_CURSOR(cursor) && (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { - attrnames_t *namesp; - - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } - namesp = xfs_attr_flags_namesp(sfe->flags); error = context->put_listent(context, - namesp, + sfe->flags, (char *)sfe->nameval, (int)sfe->namelen, (int)sfe->valuelen, @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co kmem_free(sbuf); return XFS_ERROR(EFSCORRUPTED); } - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } + sbp->entno = i; sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); sbp->name = (char *)sfe->nameval; @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co * Loop putting entries into the user buffer. */ for ( ; i < nsbuf; i++, sbp++) { - attrnames_t *namesp; - - namesp = xfs_attr_flags_namesp(sbp->flags); - if (cursor->hashval != sbp->hash) { cursor->hashval = sbp->hash; cursor->offset = 0; } error = context->put_listent(context, - namesp, + sbp->flags, sbp->name, sbp->namelen, sbp->valuelen, @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, */ retval = 0; for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { - attrnames_t *namesp; - if (be32_to_cpu(entry->hashval) != cursor->hashval) { cursor->hashval = be32_to_cpu(entry->hashval); cursor->offset = 0; @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (entry->flags & XFS_ATTR_INCOMPLETE) continue; /* skip incomplete entries */ - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) - continue; - - namesp = xfs_attr_flags_namesp(entry->flags); if (entry->flags & XFS_ATTR_LOCAL) { xfs_attr_leaf_name_local_t *name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_loc->nameval, (int)name_loc->namelen, be16_to_cpu(name_loc->valuelen), @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (retval) return retval; retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, (char*)args.value); kmem_free(args.value); - } - else { + } else { retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:44:07.000000000 +0200 @@ -30,7 +30,6 @@ struct attrlist; struct attrlist_cursor_kern; -struct attrnames; struct xfs_dabuf; struct xfs_da_args; struct xfs_da_state; @@ -204,33 +203,6 @@ static inline int xfs_attr_leaf_entsize_ return (((bsize) >> 1) + ((bsize) >> 2)); } - -/*======================================================================== - * Structure used to pass context around among the routines. - *========================================================================*/ - - -struct xfs_attr_list_context; - -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, - char *, int, int, char *); - -typedef struct xfs_attr_list_context { - struct xfs_inode *dp; /* inode */ - struct attrlist_cursor_kern *cursor; /* position in list */ - struct attrlist *alist; /* output buffer */ - int seen_enough; /* T/F: seen enough of list? */ - int count; /* num used entries */ - int dupcnt; /* count dup hashvals seen */ - int bufsize; /* total buffer size */ - int firstu; /* first used byte in buffer */ - int flags; /* from VOP call */ - int resynch; /* T/F: resynch with cursor */ - int put_value; /* T/F: need value for listent */ - put_listent_func_t put_listent; /* list output fmt function */ - int index; /* index into output buffer */ -} xfs_attr_list_context_t; - /* * Used to keep a list of "remote value" extents when unlinking an inode. */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:44:07.000000000 +0200 @@ -17,7 +17,11 @@ */ #include "xfs.h" +#include "xfs_da_btree.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" #include "xfs_attr.h" +#include "xfs_attr_leaf.h" #include "xfs_acl.h" #include "xfs_vnodeops.h" @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, return __xfs_xattr_set(inode, name, value, size, flags, 0); } -struct attrnames attr_user = { - .attr_name = "user.", - .attr_namelen = sizeof("user.") - 1, -}; - static struct xattr_handler xfs_xattr_user_handler = { .prefix = XATTR_USER_PREFIX, .get = xfs_xattr_user_get, @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); } -struct attrnames attr_trusted = { - .attr_name = "trusted.", - .attr_namelen = sizeof("trusted.") - 1, -}; - static struct xattr_handler xfs_xattr_trusted_handler = { .prefix = XATTR_TRUSTED_PREFIX, .get = xfs_xattr_trusted_get, @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); } -struct attrnames attr_secure = { - .attr_name = "security.", - .attr_namelen = sizeof("security.") - 1, -}; - static struct xattr_handler xfs_xattr_security_handler = { .prefix = XATTR_SECURITY_PREFIX, .get = xfs_xattr_secure_get, @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers NULL }; +static unsigned int xfs_attr_prefix_len(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return sizeof("security"); + else if (flags & XFS_ATTR_ROOT) + return sizeof("trusted"); + else + return sizeof("user"); +} + +static const char *xfs_attr_prefix(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return xfs_xattr_security_handler.prefix; + else if (flags & XFS_ATTR_ROOT) + return xfs_xattr_trusted_handler.prefix; + else + return xfs_xattr_user_handler.prefix; +} + +static int +xfs_attr_kern_list(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + unsigned int prefix_len = xfs_attr_prefix_len(flags); + char *offset; + int arraytop; + + ASSERT(context->count >= 0); + + /* + * Only show root namespace entries if we are actually allowed to + * see them. + */ + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) + return 0; + + arraytop = context->count + prefix_len + namelen + 1; + if (arraytop > context->firstu) { + context->count = -1; /* insufficient space */ + return 1; + } + offset = (char *)context->alist + context->count; + strncpy(offset, xfs_attr_prefix(flags), prefix_len); + offset += prefix_len; + strncpy(offset, name, namelen); /* real name */ + offset += namelen; + *offset = '\0'; + context->count += prefix_len + namelen + 1; + return 0; +} + +static int +xfs_attr_kern_list_sizes(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + context->count += xfs_attr_prefix_len(flags) + namelen + 1; + return 0; +} + static int list_one_attr(const char *name, const size_t len, void *data, size_t size, ssize_t *result) @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si ssize_t xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) { + struct xfs_attr_list_context context; + struct attrlist_cursor_kern cursor = { 0 }; struct inode *inode = dentry->d_inode; - struct xfs_inode *ip = XFS_I(inode); - attrlist_cursor_kern_t cursor = { 0 }; - int error, xflags; - ssize_t result; - - xflags = ATTR_KERNAMELS; - if (!size) - xflags |= ATTR_KERNOVAL; - - if (capable(CAP_SYS_ADMIN)) - xflags |= ATTR_KERNFULLS; - else - xflags |= ATTR_KERNORMALS; - + int error; /* * First read the regular on-disk attributes. */ - result = -xfs_attr_list(ip, data, size, xflags, &cursor); - if (result < 0) - return result; + memset(&context, 0, sizeof(context)); + context.dp = XFS_I(inode); + context.cursor = &cursor; + context.resynch = 1; + context.alist = data; + context.bufsize = size; + context.firstu = context.bufsize; + + if (size) + context.put_listent = xfs_attr_kern_list; + else + context.put_listent = xfs_attr_kern_list_sizes; + + xfs_attr_list_int(&context); + if (context.count < 0) + return -ERANGE; /* * Then add the two synthetic ACL attributes. @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_access(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_default(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } - return result; + return context.count; } Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-01 14:44:07.000000000 +0200 @@ -341,8 +341,7 @@ xfs_acl_iaccess( /* If the file has no ACL return -1. */ rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, - ATTR_ROOT | ATTR_KERNACCESS)) { + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { _ACL_FREE(acl); return -1; } Index: linux-2.6-xfs/fs/xfs/xfs_attr.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-01 14:31:40.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-01 14:44:07.000000000 +0200 @@ -18,9 +18,11 @@ #ifndef __XFS_ATTR_H__ #define __XFS_ATTR_H__ +struct xfs_inode; +struct xfs_da_args; +struct xfs_attr_list_context; + /* - * xfs_attr.h - * * Large attribute lists are structured around Btrees where all the data * elements are in the leaf nodes. Attribute names are hashed into an int, * then that int is used as the index into the Btree. Since the hashval @@ -35,17 +37,6 @@ * External interfaces *========================================================================*/ -struct cred; -struct xfs_attr_list_context; - -typedef struct attrnames { - char * attr_name; - unsigned int attr_namelen; -} attrnames_t; - -extern struct attrnames attr_user; -extern struct attrnames attr_secure; -extern struct attrnames attr_trusted; #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ - -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) /* * The maximum size (into the kernel or returned from the kernel) of an @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { /*======================================================================== - * Function prototypes for the kernel. + * Structure used to pass context around among the routines. *========================================================================*/ -struct xfs_inode; -struct attrlist_cursor_kern; -struct xfs_da_args; + +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, + char *, int, int, char *); + +typedef struct xfs_attr_list_context { + struct xfs_inode *dp; /* inode */ + struct attrlist_cursor_kern *cursor; /* position in list */ + char *alist; /* output buffer */ + int seen_enough; /* T/F: seen enough of list? */ + int count; /* num used entries */ + int dupcnt; /* count dup hashvals seen */ + int bufsize; /* total buffer size */ + int firstu; /* first used byte in buffer */ + int flags; /* from VOP call */ + int resynch; /* T/F: resynch with cursor */ + int put_value; /* T/F: need value for listent */ + put_listent_func_t put_listent; /* list output fmt function */ + int index; /* index into output buffer */ +} xfs_attr_list_context_t; + + +/*======================================================================== + * Function prototypes for the kernel. + *========================================================================*/ /* * Overall external interface routines. */ int xfs_attr_inactive(struct xfs_inode *dp); - -int xfs_attr_shortform_getvalue(struct xfs_da_args *); int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); int xfs_attr_rmtval_get(struct xfs_da_args *args); +int xfs_attr_list_int(struct xfs_attr_list_context *); #endif /* __XFS_ATTR_H__ */ From owner-xfs@oss.sgi.com Tue Jun 3 05:50:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 05:50:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53Colxk020710 for ; Tue, 3 Jun 2008 05:50:48 -0700 X-ASG-Debug-ID: 1212497500-01b301fa0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A911B12BEE71 for ; Tue, 3 Jun 2008 05:51:41 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id cbQG5x0qlxxoDpWh for ; Tue, 03 Jun 2008 05:51:41 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id D5D68A9C521; Tue, 3 Jun 2008 07:51:39 -0500 (CDT) Message-ID: <48453E5D.8050301@sandeen.net> Date: Tue, 03 Jun 2008 07:51:41 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] fix mount option parsing in remount Subject: Re: [PATCH] fix mount option parsing in remount References: <20080518153539.GA5218@lst.de> In-Reply-To: <20080518153539.GA5218@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212497501 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52241 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16234 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Christoph Hellwig wrote: > Remount currently happily accept any option thrown at it, although the > only filesystem specific option it actually handles is barrier/nobarrier. > And it actually doesn't handle these correctly either because it only > uses the value it parsed when we're doing a ro->rw transition. In > addition to that there's also a bad bug in xfs_parseargs which doesn't > touch the actual option in the mount point except for a single one, > XFS_MOUNT_SMALL_INUMS and thus forced any filesystem that's every > remounted in some way to not support 64bit inodes with no way to recover > unless unmounted. > > This patch changes xfs_fs_remount to use it's own linux/parser.h based > options parse instead of xfs_parseargs and reject all options except > for barrier/nobarrier and to the right thing in general. Eventually > I'd like to have a single big option table used for mount aswell but > that can wait for a while. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2008-05-18 15:22:23.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-05-18 15:59:32.000000000 +0200 > @@ -67,6 +67,7 @@ > #include > #include > #include > +#include > > static struct quotactl_ops xfs_quotactl_operations; > static struct super_operations xfs_super_operations; > @@ -1255,6 +1256,19 @@ xfs_fs_statfs( > return 0; > } > > +/* > + * Eventually we should extend this table and use it for mount, too. Maybe expand this a little: /* * Today only the barrier/nobarrier xfs mount options are handled * on remount. This table should be expanded to cover all options, * and used for the initial mount path, too. */ ... I'd also like this for the mount path because for example: mount -t xfs -o barrier=0 /dev/blah /mnt/foo works... but does not turn off barriers. So as a first step/example this looks ok but I'd sure like to see it extended soon. Maybe when I'm bored... :) -Eric > + */ > +enum { > + Opt_barrier, Opt_nobarrier, Opt_err > +}; > + > +static match_table_t tokens = { > + {Opt_barrier, "barrier"}, > + {Opt_nobarrier, "nobarrier"}, > + {Opt_err, NULL} > +}; > + > STATIC int > xfs_fs_remount( > struct super_block *sb, > @@ -1262,36 +1276,54 @@ xfs_fs_remount( > char *options) > { > struct xfs_mount *mp = XFS_M(sb); > - struct xfs_mount_args *args; > - int error; > + substring_t args[MAX_OPT_ARGS]; > + char *p; > > - args = xfs_args_allocate(sb, 0); > - if (!args) > - return -ENOMEM; > + while ((p = strsep(&options, ",")) != NULL) { > + int token; > > - error = xfs_parseargs(mp, options, args, 1); > - if (error) > - goto out_free_args; > + if (!*p) > + continue; > > - if (!(*flags & MS_RDONLY)) { /* rw/ro -> rw */ > - if (mp->m_flags & XFS_MOUNT_RDONLY) > - mp->m_flags &= ~XFS_MOUNT_RDONLY; > - if (args->flags & XFSMNT_BARRIER) { > + token = match_token(p, tokens, args); > + switch (token) { > + case Opt_barrier: > mp->m_flags |= XFS_MOUNT_BARRIER; > - xfs_mountfs_check_barriers(mp); > - } else { > + > + /* > + * Test if barriers are actually working if we can, > + * else delay this check until the filesystem is > + * marked writeable. > + */ > + if (!(mp->m_flags & XFS_MOUNT_RDONLY)) > + xfs_mountfs_check_barriers(mp); > + break; > + case Opt_nobarrier: > mp->m_flags &= ~XFS_MOUNT_BARRIER; > + break; > + default: > + printk(KERN_INFO > + "XFS: mount option \"%s\" not support for remount\n", p); > + return -EINVAL; > } > - } else if (!(mp->m_flags & XFS_MOUNT_RDONLY)) { /* rw -> ro */ > + } > + > + /* rw/ro -> rw */ > + if ((mp->m_flags & XFS_MOUNT_RDONLY) && !(*flags & MS_RDONLY)) { > + mp->m_flags &= ~XFS_MOUNT_RDONLY; > + if (mp->m_flags & XFS_MOUNT_BARRIER) > + xfs_mountfs_check_barriers(mp); > + } > + > + /* rw -> ro */ > + if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & MS_RDONLY)) { > xfs_filestream_flush(mp); > xfs_sync(mp, SYNC_DATA_QUIESCE); > xfs_attr_quiesce(mp); > mp->m_flags |= XFS_MOUNT_RDONLY; > } > > - out_free_args: > - kfree(args); > - return -error; > + return 0; > } > > /* > > From owner-xfs@oss.sgi.com Tue Jun 3 06:04:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 06:04:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53D4n2h021751 for ; Tue, 3 Jun 2008 06:04:49 -0700 X-ASG-Debug-ID: 1212498342-67d701560000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 85E571DDDAA for ; Tue, 3 Jun 2008 06:05:42 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id BffiYCscHIWAQevg for ; Tue, 03 Jun 2008 06:05:42 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m53D5YOc009055 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 3 Jun 2008 15:05:34 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m53D5Yd0009053; Tue, 3 Jun 2008 15:05:34 +0200 Date: Tue, 3 Jun 2008 15:05:34 +0200 From: Christoph Hellwig To: Eric Sandeen Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] fix mount option parsing in remount Subject: Re: [PATCH] fix mount option parsing in remount Message-ID: <20080603130534.GA8694@lst.de> References: <20080518153539.GA5218@lst.de> <48453E5D.8050301@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48453E5D.8050301@sandeen.net> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212498343 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52242 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16235 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Tue, Jun 03, 2008 at 07:51:41AM -0500, Eric Sandeen wrote: > Maybe expand this a little: > > /* > * Today only the barrier/nobarrier xfs mount options are handled > * on remount. This table should be expanded to cover all options, > * and used for the initial mount path, too. > */ > > ... I'd also like this for the mount path because for example: > > mount -t xfs -o barrier=0 /dev/blah /mnt/foo > > works... but does not turn off barriers. > > So as a first step/example this looks ok but I'd sure like to see it > extended soon. Maybe when I'm bored... :) Doh. But yeah, mount path should be switched over soon. I alredy posted the patches to kill the xfs_mount_args gunk which have been on the list for a while and happily ignored, and switching to the parser.h helper ontop of that is quite easy. I just want to wait a little bit so that any problems with the previous patch are shaked out before the new one gets added. From owner-xfs@oss.sgi.com Tue Jun 3 08:34:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 08:34:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53FYCkE001300 for ; Tue, 3 Jun 2008 08:34:14 -0700 X-ASG-Debug-ID: 1212507304-6b3900d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2AB9411AA347 for ; Tue, 3 Jun 2008 08:35:04 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.123]) by cuda.sgi.com with ESMTP id ybzLf1Lu54ChGxB5 for ; Tue, 03 Jun 2008 08:35:04 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta01.mail.rr.com with ESMTP id <20080603153503.JZVQ17285.hrndva-omta01.mail.rr.com@tomslinux.homelinux.org> for ; Tue, 3 Jun 2008 15:35:03 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m53FYoY0026675 for ; Tue, 3 Jun 2008 10:34:50 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m53FYmbW026674; Tue, 3 Jun 2008 10:34:48 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.226.57 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Tue, 3 Jun 2008 10:34:48 -0500 (CDT) Message-ID: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> Date: Tue, 3 Jun 2008 10:34:48 -0500 (CDT) X-ASG-Orig-Subj: Questions for article Subject: Questions for article To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.123] X-Barracuda-Start-Time: 1212507305 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0009 1.0000 -2.0153 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52251 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_SA074b URI: Custom Rule SA074b X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16236 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs I am writing an article to answer Henry Newman's at http://www.enterprisestorageforum.com/sans/features/article.php/3749926. I've already been bugging folks on the ext4 mailing list and one of them mentioned I should also send some of the same questions to this list. Please let me know if I may do so. Thanks! Tom King From owner-xfs@oss.sgi.com Tue Jun 3 10:35:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 10:35:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_05 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53HZYwY007445 for ; Tue, 3 Jun 2008 10:35:35 -0700 X-ASG-Debug-ID: 1212514587-0c6f02a10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CFFC31E0E82 for ; Tue, 3 Jun 2008 10:36:27 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.241]) by cuda.sgi.com with ESMTP id gjwYZNpeknfED3Wz for ; Tue, 03 Jun 2008 10:36:27 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so1341120rvb.32 for ; Tue, 03 Jun 2008 10:36:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=VFmrDnzXs0qDxYTyPcIOhYjHhJmwsIxURReKYTq+stY=; b=YBiNzwA3uwaLBnyj03w57My+jz+SwX2zOlnq5TLQoUzazjErs0phDWk6wl16Q8Fi11jYa8sHMNGDIUcFqmZ0VcfQKxT/HgLS/aKwM8VA9912WG/8Xi2QuAVMn+nzFWMggjvO2Gd1UVfMEx7FCC5Ko/Vi1KFV2IGG0H0E4Q9ZmP8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hj69/78IcJtFuzjQSAl9w+/sWDhg8C3OzIsTtyxamn1glWyK6vzuVCloYT/H/NboESp9b6yMwaA1BfxxOeKWSDHV2wV5HmmGenb3X93dR30OLdOcLy00NAObbgkVx6B7dwDVoU/gbQmQroNdwyPrYmQvbQrgPCrp8z0NZHE42Ts= Received: by 10.141.162.9 with SMTP id p9mr6007783rvo.68.1212514586946; Tue, 03 Jun 2008 10:36:26 -0700 (PDT) Received: by 10.141.43.7 with HTTP; Tue, 3 Jun 2008 10:36:26 -0700 (PDT) Message-ID: <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> Date: Tue, 3 Jun 2008 13:36:26 -0400 From: "Spam Magnet" To: "Stefan Smietanowski" X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed Cc: "Timothy Shimmin" , "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <48427DEE.40400@stesmi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <483F1AED.3010808@sandeen.net> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.241] X-Barracuda-Start-Time: 1212514587 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0071 1.0000 -1.9746 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.71 X-Barracuda-Spam-Status: No, SCORE=-1.71 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=PORN_URL_SEX X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52259 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.26 PORN_URL_SEX URI: URL uses words/phrases which indicate porn (sex) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16237 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs On Sun, Jun 1, 2008 at 6:46 AM, Stefan Smietanowski wrote: > One way is : od -t c jaz7.img | grep X | head > > Look for X F S B, may be split on two lines for you. > > This is what my disk looks like but of course, it's on a DOS > partition: > > 0077000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \0 ` \0 > I couldn't find any XFS by using the full dump of the disk: $ od -t c jaz7.img | grep X | head 0040000 353 > 220 ( j 0 X ] I H C \0 002 001 \0 0040240 003 303 H 367 363 001 F 374 021 N 376 Z X 273 \0 \a 0040560 023 Y Z X r \t @ u 001 B 003 ^ \v 342 314 303 1041040 5 0 E X E ! \0 K - H 1141360 031 \0 t \b P \r 362 \t . \0 265 P X \f 026 z 1141400 # 001 353 \n X 034 022 020 D 001 I 016 X 034 @ 023 (The healthy disk image also doesn't have any XFS but it has: 'S f x' (capital s)) 50.exe at offset 1041040 made me check the image file using a Windows utility called : UFS Explorer. (www.ufsexplorer.com) They claim that they can recover XFS partitions. To my surprise that software recognized the image as a FAT16 file system containing only one single file called "50.exe" I am more inclined to believe 'fdisk' rather than UFS Explorer: Most likely the original format that Iomega had shipped the Jaz disk with was a FAT16 and then somebody in our lab had decided to format it to xfs. I am beginning to feel that I will need to recover my data manually, one file at a time :( (It's really frustrating that I can see all my beautiful file names through hexdump but can't access them). So is there a preferred way of hard disk/partition recovery for XFS file system ? And if I end up doing that, where can I get more info about the underwork of xfs ? thank you all for your patience and help. From owner-xfs@oss.sgi.com Tue Jun 3 10:55:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 10:55:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53HtEGW008764 for ; Tue, 3 Jun 2008 10:55:15 -0700 X-ASG-Debug-ID: 1212515768-14dd00190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DDBF211AD100 for ; Tue, 3 Jun 2008 10:56:08 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.243]) by cuda.sgi.com with ESMTP id qjiQYInvLVS8vFyC for ; Tue, 03 Jun 2008 10:56:08 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so1350769rvb.32 for ; Tue, 03 Jun 2008 10:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=5Ce0dd9ZVgxZmhgrQFPqWpz1dEcMcCkplkHdJUZMc1A=; b=X7efzWKbWIHY234ck+y3RDM0+qak/33HV1Djp0TAIC7jkzigZ9WGXqS910EaKJwdtIx+oJj8DXTTvRwZin6FCAFbqiSoh4awOqLBz1OxBS+KDJMFtNkajT1p8/swK3xjUMO1B/8MnNP5bxbWxrFH9SeEVm1XrcKqyCZZVc+OWgw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Je+fPW/A8Ky9FL5rUC/IzSTmfEXGl6dv+dDAvj+ggKbMCd67YdAaY5hbyqv0R92IblhO7XMSM7W5pt33+G5TUwgz46ushi1m6FsKVhEDKKJrNQSPeSs+v4kC7OaSgg3X6cl0uAYWSjKWzy/Sm9J7jX1bWmNguxS1EgUpO/o4uRg= Received: by 10.141.141.3 with SMTP id t3mr6015542rvn.226.1212515768121; Tue, 03 Jun 2008 10:56:08 -0700 (PDT) Received: by 10.141.43.7 with HTTP; Tue, 3 Jun 2008 10:56:08 -0700 (PDT) Message-ID: <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> Date: Tue, 3 Jun 2008 13:56:08 -0400 From: "Spam Magnet" To: "Stefan Smietanowski" X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed Cc: "Timothy Shimmin" , "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.243] X-Barracuda-Start-Time: 1212515768 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52261 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16238 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs > (The healthy disk image also doesn't have any XFS but it has: 'S f x' > (capital s)) Correcting my mistake: The healthy image file does have the X F S B at 10000000 (octal) as fdisk had reported: Pt# Device Info Start End Sectors Id System 8: 2gb-ubuntu.img1 4096 3915599 3911504 a SGI xfs 4096*512=2097152 (10000000 octal): $ od -t c 2gb-ubuntu.img | grep 10000000 10000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \a u 350 I tried to see if I can find do the same thing for jaz7.img: Pt# Device Info Start End Sectors Id System 8: jaz7.img1 3072 2091007 2087936 a SGI xfs $ od -t c jaz7.img | grep 6000000 6000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 I guess all those zeros are not good signs. From owner-xfs@oss.sgi.com Tue Jun 3 11:43:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 11:43:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53IhQEa010702 for ; Tue, 3 Jun 2008 11:43:26 -0700 X-ASG-Debug-ID: 1212518658-304800e10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from atlantis.cc.ndsu.NoDak.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8D4F611AD440 for ; Tue, 3 Jun 2008 11:44:18 -0700 (PDT) Received: from atlantis.cc.ndsu.NoDak.edu (atlantis.cc.ndsu.NoDak.edu [134.129.99.37]) by cuda.sgi.com with ESMTP id lZDqv4SpsKrmBiqC for ; Tue, 03 Jun 2008 11:44:18 -0700 (PDT) Received: from atlantis.cc.ndsu.NoDak.edu (localhost.localdomain [127.0.0.1]) by atlantis.cc.ndsu.NoDak.edu (8.14.2/8.14.2) with ESMTP id m53IiIGe026717; Tue, 3 Jun 2008 13:44:18 -0500 Received: (from bmesich@localhost) by atlantis.cc.ndsu.NoDak.edu (8.14.2/8.14.1/Submit) id m53IiHft026716; Tue, 3 Jun 2008 13:44:17 -0500 Date: Tue, 3 Jun 2008 13:44:17 -0500 From: Bryan Mesich To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Subject: Re: Limits of the 965 chipset & 3 PCI-e cards/southbridge? ~774MiB/s peak for read, ~650MiB/s peak for write? Message-ID: <20080603184417.GA23450@atlantis.cc.ndsu.NoDak.edu> Reply-To: Bryan Mesich Mail-Followup-To: Bryan Mesich , linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Fedora Release 8 User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: atlantis.cc.ndsu.NoDak.edu[134.129.99.37] X-Barracuda-Start-Time: 1212518659 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52265 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16239 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bryan.mesich@ndsu.edu Precedence: bulk X-list: xfs On Sun, Jun 01, 2008 at 05:45:39AM -0400, Justin Piszcz wrote: > I am testing some drives for someone and was curious to see how far one can > push the disks/backplane to their theoretical limit. This testing would indeed only suggest theoretical limits. In a production environment, I think a person would be hard pressed to reproduce these numbers. > Does/has anyone done this with server intel board/would greater speeds be > achievable? Nope, but your post inspired me to give it a try. My setup is as follows: Kernel: linux 2.6.25.3-18 (Fedora 9) Motherboard: Intel SE7520BD2-DDR2 SATA Controller: (2) 8 port 3Ware 9550SX Disks (12) 750GB Seagate ST3750640NS Disks sd[a-h] are plugged into the first 3Ware controller while sd[i-l] are plugged into the second controller. Both 3Ware cards are plugged onto PCIX 100 slots. The disks are being exported as "single disk" and write caching has been disabled. The OS is loaded on sd[a-d] (small 10GB partitions mirrored). For my first test, I ran dd on a single disk: dd if=/dev/sde of=/dev/null bs=1M dstat -D sde ----total-cpu-usage---- --dsk/sde-- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 7 53 40 0 0| 78M 0 | 526B 420B| 0 0 |1263 2559 0 8 53 38 0 0| 79M 0 | 574B 420B| 0 0 |1262 2529 0 7 54 39 0 0| 78M 0 | 390B 420B| 0 0 |1262 2576 0 7 54 39 0 0| 76M 0 | 284B 420B| 0 0 |1216 2450 0 8 54 38 0 0| 76M 0 | 376B 420B| 0 0 |1236 2489 0 9 54 36 0 0| 79M 0 | 397B 420B| 0 0 |1265 2537 0 9 54 37 0 0| 77M 0 | 344B 510B| 0 0 |1262 2872 0 8 54 38 0 0| 75M 0 | 637B 420B| 0 0 |1214 2992 0 8 53 38 0 0| 78M 0 | 422B 420B| 0 0 |1279 3179 And for a write: dd if=/dev/zero of=/dev/sde bs=1M dstat -D sde ----total-cpu-usage---- --dsk/sde-- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 7 2 90 0 0| 0 73M| 637B 420B| 0 0 | 614 166 0 7 0 93 0 0| 0 73M| 344B 420B| 0 0 | 586 105 0 7 0 93 0 0| 0 75M| 344B 420B| 0 0 | 629 177 0 7 0 93 0 0| 0 74M| 344B 420B| 0 0 | 600 103 0 7 0 93 0 0| 0 73M| 875B 420B| 0 0 | 612 219 0 8 0 92 0 0| 0 68M| 595B 420B| 0 0 | 546 374 0 8 5 86 0 0| 0 76M| 132B 420B| 0 0 | 632 453 0 9 0 91 0 0| 0 74M| 799B 420B| 0 0 | 596 421 0 8 0 92 0 0| 0 74M| 693B 420B| 0 0 | 624 436 For my next test, I ran dd on 8 disks (sd[e-l]). These are non-system disks (OS is installed on sd[a-d) and they are split between the 3Ware controllers. Here are my results: dd if=/dev/sd[e-l] of=/dev/null bs=1M dstat ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 91 0 0 1 8| 397M 0 | 811B 306B| 0 0 |6194 6654 0 91 0 0 1 7| 420M 0 | 158B 322B| 0 0 |6596 7097 1 91 0 0 1 8| 415M 0 | 324B 322B| 0 0 |6406 6839 1 91 0 0 1 8| 413M 0 | 316B 436B| 0 0 |6464 6941 0 90 0 0 2 8| 419M 0 | 66B 306B| 0 0 |6588 7121 1 91 0 0 2 7| 412M 0 | 461B 322B| 0 0 |6449 6916 0 91 0 0 1 7| 415M 0 | 665B 436B| 0 0 |6535 7044 0 92 0 0 1 7| 418M 0 | 299B 306B| 0 0 |6555 7028 0 90 0 0 1 8| 412M 0 | 192B 436B| 0 0 |6496 7014 And for write: dd if=/dev/zero of=/dev/sd[e-l] bs=1M dstat ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai hiq siq| read writ| recv send| in out | int csw 0 86 0 0 1 12| 0 399M| 370B 306B| 0 0 |3520 855 0 87 0 0 1 12| 0 407M| 310B 322B| 0 0 |3506 813 1 87 0 0 1 12| 0 413M| 218B 322B| 0 0 |3568 827 0 87 0 0 0 12| 0 425M| 278B 322B| 0 0 |3641 785 0 87 0 0 1 12| 0 430M| 310B 322B| 0 0 |3658 845 0 86 0 0 1 14| 0 421M| 218B 322B| 0 0 |3605 756 1 85 0 0 1 14| 0 417M| 627B 322B| 0 0 |3579 984 0 84 0 0 1 14| 0 420M| 224B 436B| 0 0 |3548 1006 0 86 0 0 1 13| 0 433M| 310B 306B| 0 0 |3679 836 It seems that I'm running into a wall around 420-430M. Assuming the disks can push 75M, 8 disks should push 600M together. This is obviously not the case. According to Intel's Tech Specifications: http://download.intel.com/support/motherboards/server/se7520bd2/sb/se7520bd2_server_board_tps_r23.pdf I think the IO contention (in my case) is due to the PXH. All and all, when it comes down to moving IO in reality, these tests are pretty much useless in my opinion. Filesystem overhead and other operations limit the amount of IO that can be serviced by the PCI bus and/or the block devices (although it's interesting to see if the theoretical speeds are possible). For example, the box I used in the above example will be used as a fibre channel target server. Below is a performance print out of a running fibre target with the same hardware as tested above: mayacli> show performance controller=fc1 read/sec write/sec IOPS 16k 844k 141 52k 548k 62 1m 344k 64 52k 132k 26 0 208k 27 12k 396k 42 168k 356k 64 32k 76k 16 952k 248k 124 860k 264k 132 1m 544k 165 1m 280k 166 900k 344k 105 340k 284k 60 1m 280k 125 1m 340k 138 764k 592k 118 1m 448k 127 2m 356k 276 2m 480k 174 2m 8m 144 540k 376k 89 324k 380k 77 4k 348k 71 This particular fibre target is providing storage to 8 initiators, 4 of which are busy IMAP mail servers. Granted this isn't the busiest time of the year for us, but were not comming even close to the numbers mentioned in the above example. As always, corrections to my above bable are appreciated and welcomed :-) Bryan From owner-xfs@oss.sgi.com Tue Jun 3 11:58:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 11:58:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53IwttN011563 for ; Tue, 3 Jun 2008 11:58:57 -0700 X-ASG-Debug-ID: 1212519587-676a013e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from proxy1.bredband.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E51571E1DA8 for ; Tue, 3 Jun 2008 11:59:48 -0700 (PDT) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by cuda.sgi.com with ESMTP id LpIsorcByKRrT1xz for ; Tue, 03 Jun 2008 11:59:48 -0700 (PDT) Received: from ironport2.bredband.com (195.54.101.122) by proxy1.bredband.net (7.3.127) id 4811823A00C16855 for xfs@oss.sgi.com; Tue, 3 Jun 2008 20:59:47 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4+AF0xRUjVctjQPGdsb2JhbACBVYcOiRcBAQEBLQGfAA Received: from c-d0d872d5.06-15-73746f44.cust.bredbandsbolaget.se (HELO DeepSpaceNine.stesmi.com) ([213.114.216.208]) by ironport2.bredband.com with ESMTP; 03 Jun 2008 20:59:47 +0200 Received: from [127.0.0.1] (voyager.stesmi.com [192.168.1.11]) by DeepSpaceNine.stesmi.com (8.12.11/8.12.11) with ESMTP id m53IxiTV029635; Tue, 3 Jun 2008 20:59:46 +0200 Message-ID: <4845949F.7080209@stesmi.com> Date: Tue, 03 Jun 2008 20:59:43 +0200 From: Stefan Smietanowski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Spam Magnet CC: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <3607657a0805291446t79808c63l664780c1cbc3d871@mail.gmail.com> <483F907A.3020108@sgi.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> In-Reply-To: <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.7; VAE 6.29.0.5; VDF 6.29.0.100 X-Barracuda-Connect: proxy1.bredband.net[195.54.101.71] X-Barracuda-Start-Time: 1212519589 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52266 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16240 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Spam Magnet wrote: >> (The healthy disk image also doesn't have any XFS but it has: 'S f x' >> (capital s)) > > Correcting my mistake: > > The healthy image file does have the X F S B at 10000000 (octal) as > fdisk had reported: > Pt# Device Info Start End Sectors Id System > 8: 2gb-ubuntu.img1 4096 3915599 3911504 a SGI xfs > > 4096*512=2097152 (10000000 octal): > $ od -t c 2gb-ubuntu.img | grep 10000000 > 10000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \a u 350 > > I tried to see if I can find do the same thing for jaz7.img: > Pt# Device Info Start End Sectors Id System > 8: jaz7.img1 3072 2091007 2087936 a SGI xfs > > $ od -t c jaz7.img | grep 6000000 > 6000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 > > I guess all those zeros are not good signs. Wait a moment. Aren't jaz sectors 2k each? Try at 3072*2048 instead. // Stefan From owner-xfs@oss.sgi.com Tue Jun 3 12:38:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 12:38:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53JcEOZ018185 for ; Tue, 3 Jun 2008 12:38:14 -0700 X-ASG-Debug-ID: 1212521947-5e8302a60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 27FEC1E36C5 for ; Tue, 3 Jun 2008 12:39:07 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.246]) by cuda.sgi.com with ESMTP id nPZSRfwSFEoHrC3M for ; Tue, 03 Jun 2008 12:39:07 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so1381117rvb.32 for ; Tue, 03 Jun 2008 12:39:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=cLI6zuruZDJ1bZ0knTuyZuET80CIehI57K9n5NIxzJ8=; b=WeVtSBb4+QpHFurCgPkUAPK3UVa6b8r+urcZrpiXBYkHA/HhaVpJX+TaUPmvz27x4Ej5Elb/2apaQRhavBgv7bYOxTjlrSK3muDPKfHrediBcbOzlbJv783bkyHSVd4dIba0yCksgTtJjHf4dypsYz4X3aZiEwWzedrOW3lWVl8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=vIt96G7drocUocYPYGQwHp9ogUHLxVib04JsdauB32XQbnTefVvn6i2F2uGI+yh4w0wS0L+KsmdMeOcj7wdPfE5dIKOwPycZblM4ctkRY/rew58DzwKBEPkw6wxC7U9V73naaNY5839ldZeuqUJ0ifHe6SAwvNxRide5lwZpIm0= Received: by 10.140.125.1 with SMTP id x1mr6101052rvc.287.1212521947444; Tue, 03 Jun 2008 12:39:07 -0700 (PDT) Received: by 10.141.43.7 with HTTP; Tue, 3 Jun 2008 12:39:07 -0700 (PDT) Message-ID: <3607657a0806031239l6d788868u2f5654efcabf4abc@mail.gmail.com> Date: Tue, 3 Jun 2008 15:39:07 -0400 From: "Spam Magnet" To: "Stefan Smietanowski" X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed Cc: "Timothy Shimmin" , "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <4845949F.7080209@stesmi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> <4845949F.7080209@stesmi.com> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.246] X-Barracuda-Start-Time: 1212521948 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52267 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16241 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs On Tue, Jun 3, 2008 at 2:59 PM, Stefan Smietanowski wrote: > Spam Magnet wrote: >>> >>> (The healthy disk image also doesn't have any XFS but it has: 'S f x' >>> (capital s)) >> >> Correcting my mistake: >> >> The healthy image file does have the X F S B at 10000000 (octal) as >> fdisk had reported: >> Pt# Device Info Start End Sectors Id System >> 8: 2gb-ubuntu.img1 4096 3915599 3911504 a SGI xfs >> >> 4096*512=2097152 (10000000 octal): >> $ od -t c 2gb-ubuntu.img | grep 10000000 >> 10000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \a u 350 >> >> I tried to see if I can find do the same thing for jaz7.img: >> Pt# Device Info Start End Sectors Id System >> 8: jaz7.img1 3072 2091007 2087936 a SGI xfs >> >> $ od -t c jaz7.img | grep 6000000 >> 6000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 >> >> I guess all those zeros are not good signs. > > Wait a moment. Aren't jaz sectors 2k each? > > Try at 3072*2048 instead. > > // Stefan > I think they are but I used -u option of fdisk: $ fdisk -ul jaz7.img Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders Units = sectors of 1 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 8: jaz7.img1 3072 2091007 2087936 a SGI xfs 9: jaz7.img2 0 3071 3072 0 SGI volhdr 11: jaz7.img3 0 2091007 2091008 6 SGI volume which lists partitions in sector units. As oppose to: $ fdisk -l jaz7.img Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders Units = cylinders of 16065 * 512 bytes ----- partitions ----- Pt# Device Info Start End Sectors Id System 8: jaz7.img1 1 130 2087936 a SGI xfs 9: jaz7.img2 0 0 3072 0 SGI volhdr 11: jaz7.img3 0 130 2091008 6 SGI volume From owner-xfs@oss.sgi.com Tue Jun 3 12:41:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 12:41:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53JfKn2018629 for ; Tue, 3 Jun 2008 12:41:21 -0700 X-ASG-Debug-ID: 1212522134-15b302560000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 788D913B8B21 for ; Tue, 3 Jun 2008 12:42:14 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id djthj7gceXvMrDdB for ; Tue, 03 Jun 2008 12:42:14 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id C77C81C000263; Tue, 3 Jun 2008 15:42:13 -0400 (EDT) Date: Tue, 3 Jun 2008 15:42:13 -0400 (EDT) From: Justin Piszcz To: Thomas King cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article In-Reply-To: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> Message-ID: References: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1212522134 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_SA074b URI: Custom Rule SA074b X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16242 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Tue, 3 Jun 2008, Thomas King wrote: > I am writing an article to answer Henry Newman's at > http://www.enterprisestorageforum.com/sans/features/article.php/3749926. I've > already been bugging folks on the ext4 mailing list and one of them mentioned I > should also send some of the same questions to this list. Please let me know if > I may do so. > > Thanks! > Tom King > > What are the questions? Justin. From owner-xfs@oss.sgi.com Tue Jun 3 13:23:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 13:23:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53KN4qM020961 for ; Tue, 3 Jun 2008 13:23:06 -0700 X-ASG-Debug-ID: 1212524637-0bf303db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from proxy1.bredband.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 839BE17760AC for ; Tue, 3 Jun 2008 13:23:58 -0700 (PDT) Received: from proxy1.bredband.net (proxy1.bredband.net [195.54.101.71]) by cuda.sgi.com with ESMTP id S01N5b4WNy7iErQ7 for ; Tue, 03 Jun 2008 13:23:58 -0700 (PDT) Received: from ironport.bredband.com (195.54.101.120) by proxy1.bredband.net (7.3.127) id 4811823A00C1C351 for xfs@oss.sgi.com; Tue, 3 Jun 2008 22:23:57 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al4+AMdERUjVctjQPGdsb2JhbACBVYcOiRcBAQEBLQGeeA Received: from c-d0d872d5.06-15-73746f44.cust.bredbandsbolaget.se (HELO DeepSpaceNine.stesmi.com) ([213.114.216.208]) by ironport1.bredband.com with ESMTP; 03 Jun 2008 22:23:57 +0200 Received: from [127.0.0.1] (voyager.stesmi.com [192.168.1.11]) by DeepSpaceNine.stesmi.com (8.12.11/8.12.11) with ESMTP id m53KNqGO004083; Tue, 3 Jun 2008 22:23:56 +0200 Message-ID: <4845A857.3090905@stesmi.com> Date: Tue, 03 Jun 2008 22:23:51 +0200 From: Stefan Smietanowski User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Spam Magnet CC: Timothy Shimmin , Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <3607657a0805301019h4a49dc86ne8f1f019629a1c41@mail.gmail.com> <4840406F.50402@stesmi.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> <4845949F.7080209@stesmi.com> <3607657a0806031239l6d788868u2f5654efcabf4abc@mail.gmail.com> In-Reply-To: <3607657a0806031239l6d788868u2f5654efcabf4abc@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira Milter 1.0.7; VAE 6.29.0.5; VDF 6.29.0.100 X-Barracuda-Connect: proxy1.bredband.net[195.54.101.71] X-Barracuda-Start-Time: 1212524638 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52272 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16243 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: stesmi@stesmi.com Precedence: bulk X-list: xfs Spam Magnet wrote: > On Tue, Jun 3, 2008 at 2:59 PM, Stefan Smietanowski wrote: >> Spam Magnet wrote: >>>> (The healthy disk image also doesn't have any XFS but it has: 'S f x' >>>> (capital s)) >>> Correcting my mistake: >>> >>> The healthy image file does have the X F S B at 10000000 (octal) as >>> fdisk had reported: >>> Pt# Device Info Start End Sectors Id System >>> 8: 2gb-ubuntu.img1 4096 3915599 3911504 a SGI xfs >>> >>> 4096*512=2097152 (10000000 octal): >>> $ od -t c 2gb-ubuntu.img | grep 10000000 >>> 10000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 \0 \a u 350 >>> >>> I tried to see if I can find do the same thing for jaz7.img: >>> Pt# Device Info Start End Sectors Id System >>> 8: jaz7.img1 3072 2091007 2087936 a SGI xfs >>> >>> $ od -t c jaz7.img | grep 6000000 >>> 6000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 >>> >>> I guess all those zeros are not good signs. >> Wait a moment. Aren't jaz sectors 2k each? >> >> Try at 3072*2048 instead. >> >> // Stefan >> > > I think they are but I used -u option of fdisk: > $ fdisk -ul jaz7.img > Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders > Units = sectors of 1 * 512 bytes > ----- partitions ----- > Pt# Device Info Start End Sectors Id System > 8: jaz7.img1 3072 2091007 2087936 a SGI xfs > 9: jaz7.img2 0 3071 3072 0 SGI volhdr > 11: jaz7.img3 0 2091007 2091008 6 SGI volume > > which lists partitions in sector units. As oppose to: > > $ fdisk -l jaz7.img > > Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders > Units = cylinders of 16065 * 512 bytes > > ----- partitions ----- > Pt# Device Info Start End Sectors Id System > 8: jaz7.img1 1 130 2087936 a SGI xfs > 9: jaz7.img2 0 0 3072 0 SGI volhdr > 11: jaz7.img3 0 130 2091008 6 SGI volume I'd give it a shot regardless as I don't remember if the sector size is actually IN the partition table and if it's NOT then it'll show the native blocksize of the device, which is 512bytes! Just try it, what do you have to lose? I mean do the od .. Worst case you get garbage or zeroes. // Stefan From owner-xfs@oss.sgi.com Tue Jun 3 13:34:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 13:34:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53KY4vv021652 for ; Tue, 3 Jun 2008 13:34:07 -0700 X-ASG-Debug-ID: 1212525298-1556037e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6512717764A4; Tue, 3 Jun 2008 13:34:58 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id RSTXw7UarIhTgKgy; Tue, 03 Jun 2008 13:34:58 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K3dDd-00042x-Qh; Tue, 03 Jun 2008 20:34:57 +0000 Date: Tue, 3 Jun 2008 16:34:57 -0400 From: Christoph Hellwig To: Barry Naujok , "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: xfs_reno #2 Subject: Re: REVIEW: xfs_reno #2 Message-ID: <20080603203457.GA6018@infradead.org> References: <1204819835.4002.36.camel@tecra.thekeening.homeunix.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1204819835.4002.36.camel@tecra.thekeening.homeunix.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212525298 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52272 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16244 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs What happened to xfs xfs_reno patch? While the swapino functionality would be nice to have I can't think of a reason to not have the current code in xfsprogs. From owner-xfs@oss.sgi.com Tue Jun 3 13:48:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 13:48:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53KmAJY022638 for ; Tue, 3 Jun 2008 13:48:11 -0700 X-ASG-Debug-ID: 1212526140-673903bf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FA781E3A69 for ; Tue, 3 Jun 2008 13:49:04 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by cuda.sgi.com with ESMTP id TGikzCV7qZVEFSWc for ; Tue, 03 Jun 2008 13:49:04 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta06.mail.rr.com with ESMTP id <20080603204900.FOKT9231.hrndva-omta06.mail.rr.com@tomslinux.homelinux.org> for ; Tue, 3 Jun 2008 20:49:00 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m53Kmnem029499 for ; Tue, 3 Jun 2008 15:48:50 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m53Kmn1m029498; Tue, 3 Jun 2008 15:48:49 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.226.57 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Tue, 3 Jun 2008 15:48:49 -0500 (CDT) Message-ID: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> Date: Tue, 3 Jun 2008 15:48:49 -0500 (CDT) X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.124] X-Barracuda-Start-Time: 1212526144 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b, BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52274 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_SA074b URI: Custom Rule SA074b 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16245 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs > > > On Tue, 3 Jun 2008, Thomas King wrote: > >> I am writing an article to answer Henry Newman's at >> http://www.enterprisestorageforum.com/sans/features/article.php/3749926. I've >> already been bugging folks on the ext4 mailing list and one of them mentioned >> I >> should also send some of the same questions to this list. Please let me know >> if >> I may do so. >> >> Thanks! >> Tom King >> >> > > What are the questions? > > Justin. For the most part, XFS is used for massive filesystems (hundreds of petabytes) successfully in Linux (among other OS's). However, Mr. Newman still believes there are details that he believes XFS doesn't include or Linux limits (such as page sizes in x86 limiting block sizes). With that preface, here are some questions: -Is XFS fully RAID aware inthat it aligns metadata with RAID stripes? Some of the information I see states XFS can get geometry information from LVM and MD, but what about hardware RAID? -Does XFS take advantage of T10 DIF (block protection?)? -Does/Will XFS support NFS v4.1? -Concerning the block-size limit, will this eventually be a thing of the past? Mr. Newman's contention is massive filesystems should have much larger block sizes, but he also contends that OSD is the eventual answer instead of using block allocation. -Is there anything else y'all would like folks to understand about XFS and massive implementations? Thanks! Tom King From owner-xfs@oss.sgi.com Tue Jun 3 15:03:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 15:03:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53M3Baj026254 for ; Tue, 3 Jun 2008 15:03:11 -0700 X-ASG-Debug-ID: 1212530644-69f402980000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rgminet01.oracle.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 425901776F3D for ; Tue, 3 Jun 2008 15:04:04 -0700 (PDT) Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by cuda.sgi.com with ESMTP id aF0HUKrDMgHcRnZx for ; Tue, 03 Jun 2008 15:04:04 -0700 (PDT) Received: from agmgw2.us.oracle.com (agmgw2.us.oracle.com [152.68.180.213]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m53M43AQ013963; Tue, 3 Jun 2008 16:04:03 -0600 Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by agmgw2.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m53GAtpL024439; Tue, 3 Jun 2008 16:04:01 -0600 Received: from groovelator.mkp.net by acsmt359.oracle.com with ESMTP id 10021603691212530445; Tue, 03 Jun 2008 17:00:45 -0500 To: Thomas King Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article From: "Martin K. Petersen" Organization: Oracle References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> Date: Tue, 03 Jun 2008 18:00:42 -0400 In-Reply-To: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> (Thomas King's message of "Tue\, 3 Jun 2008 15\:48\:49 -0500 \(CDT\)") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Barracuda-Connect: rgminet01.oracle.com[148.87.113.118] X-Barracuda-Start-Time: 1212530645 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52278 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16246 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: martin.petersen@oracle.com Precedence: bulk X-list: xfs >>>>> "Thomas" == Thomas King writes: Thomas> -Is XFS fully RAID aware inthat it aligns metadata with RAID Thomas> stripes? Some of the information I see states XFS can get Thomas> geometry information from LVM and MD, but what about hardware Thomas> RAID? The stuff that queries MD/LVM for stripe unit/stripe size has been in XFS for a while[1]. For hardware RAID there is no non-proprietary way to obtain the information from the device. So whoever runs mkfs on a hardware RAID device must manually specify the geometry using the sunit and swidth parameters. That capability has been there since the dawn of time. Note that in the upcoming version of SBC-3 (SCSI Block Commands) finally features a VPD page that the array firmware can fill out to let the operating system know about stripe size, etc. I have been working on a patch that extracts this information and presents it to the block layer in a generic fashion. But so far I have not seen a single array that implements said VPD page. IOW, there hasn't been much motivation to finish that work. Also, SBC-3 is work in progress. The standard has not been ratified yet so things could change before it is released. I doubt they are going to change the block limits VPD, but who knows? Thomas> -Does XFS take advantage of T10 DIF (block protection?)? As I mentioned earlier today, filesystems do not need to be explicitly DIF-aware. I/Os submitted by XFS will be protected if the kernel does DIF. The DIF support has not been accepted upstream yet. Working on that. But in any case DIF-capable hardware is not generally available. [1] http://www.linux.sgi.com/archives/xfs/2001-03/msg00435.html -- Martin K. Petersen Oracle Linux Engineering From owner-xfs@oss.sgi.com Tue Jun 3 15:13:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 15:13:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53MDqE2026923 for ; Tue, 3 Jun 2008 15:13:52 -0700 X-ASG-Debug-ID: 1212531283-27be01350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 812921E45B5 for ; Tue, 3 Jun 2008 15:14:43 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id vFcgoE8gmW1xGNDq for ; Tue, 03 Jun 2008 15:14:43 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id CF79498FF72; Tue, 3 Jun 2008 17:14:42 -0500 (CDT) Message-ID: <4845C254.6050104@sandeen.net> Date: Tue, 03 Jun 2008 17:14:44 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas King CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> In-Reply-To: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212531285 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52278 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16247 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Thomas King wrote: > -Concerning the block-size limit, will this eventually be a thing of the past? > Mr. Newman's contention is massive filesystems should have much larger block > sizes, but he also contends that OSD is the eventual answer instead of using > block allocation. Just to reiterate what I already put on the ext4 list... :) ftp://ftp.kernel.org/pub/linux/kernel/people/christoph/largeblocksize/4/patches/ http://kerneltrap.org/Linux/Large_Blocksize_Performance Not sure where those patches are headed. It's also not clear to me that this is really a critical feature for large filesystems; space allocation is not done block by block per se in xfs, as Mr. Newman seems (?) to imply (?) The block granularity is there throughout the fs but I'm not sure how much it matters in practice. Dave...? OSDs may have their place, we'll see. It's pretty new stuff (unless you count Lustre, I guess, but I thought he didn't want to talk lustre...) I don't think this relates to a linux shortcoming in any way (or to xfs...), it's awfully new stuff that just about nobody really has in production. > -Is there anything else y'all would like folks to understand about XFS and > massive implementations? I already pointed him at the xfs_repair paper, since he seems concerned about fsck (and pointed out that yes, xfs_repair really *DOES* check all filesystem data and does not simply replay the log...) http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf Maybe some of the folks on the list with said massive implementations can speak up too. :) -Eric From owner-xfs@oss.sgi.com Tue Jun 3 15:18:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 15:18:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m53MId3r027572 for ; Tue, 3 Jun 2008 15:18:40 -0700 X-ASG-Debug-ID: 1212531564-100c015b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CA4C01776CE2 for ; Tue, 3 Jun 2008 15:19:24 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.124]) by cuda.sgi.com with ESMTP id PADvXBcUObZYw7eC for ; Tue, 03 Jun 2008 15:19:24 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta06.mail.rr.com with ESMTP id <20080603221924.IMPN9231.hrndva-omta06.mail.rr.com@tomslinux.homelinux.org>; Tue, 3 Jun 2008 22:19:24 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m53MJE1k030286; Tue, 3 Jun 2008 17:19:14 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m53MJDd3030285; Tue, 3 Jun 2008 17:19:13 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.255.56 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Tue, 3 Jun 2008 17:19:13 -0500 (CDT) Message-ID: <59654.143.166.255.56.1212531553.squirrel@tomslinux.homelinux.org> In-Reply-To: <4845C254.6050104@sandeen.net> References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> <4845C254.6050104@sandeen.net> Date: Tue, 3 Jun 2008 17:19:13 -0500 (CDT) X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article To: "Eric Sandeen" Cc: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.124] X-Barracuda-Start-Time: 1212531564 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0176 1.0000 -1.9067 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.91 X-Barracuda-Spam-Status: No, SCORE=-1.91 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52280 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16248 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs > Thomas King wrote: > >> -Concerning the block-size limit, will this eventually be a thing of the past? >> Mr. Newman's contention is massive filesystems should have much larger block >> sizes, but he also contends that OSD is the eventual answer instead of using >> block allocation. > > Just to reiterate what I already put on the ext4 list... :) > > ftp://ftp.kernel.org/pub/linux/kernel/people/christoph/largeblocksize/4/patches/ > http://kerneltrap.org/Linux/Large_Blocksize_Performance > > Not sure where those patches are headed. > > It's also not clear to me that this is really a critical feature for > large filesystems; space allocation is not done block by block per se in > xfs, as Mr. Newman seems (?) to imply (?) The block granularity is > there throughout the fs but I'm not sure how much it matters in > practice. Dave...? > > OSDs may have their place, we'll see. It's pretty new stuff (unless you > count Lustre, I guess, but I thought he didn't want to talk lustre...) > I don't think this relates to a linux shortcoming in any way (or to > xfs...), it's awfully new stuff that just about nobody really has in > production. > >> -Is there anything else y'all would like folks to understand about XFS and >> massive implementations? > > I already pointed him at the xfs_repair paper, since he seems concerned > about fsck (and pointed out that yes, xfs_repair really *DOES* check all > filesystem data and does not simply replay the log...) > > http://mirror.linux.org.au/pub/linux.conf.au/2008/slides/135-fixing_xfs_faster.pdf > > Maybe some of the folks on the list with said massive implementations > can speak up too. :) > > -Eric > Both you and Andreas gave me some excellent information on both lists, and thank you all for your patience. I appreciate everyone piping in. Like you say, if there is anyone with massive implementations that wishes to add, please do so. Thanks! Tom King From owner-xfs@oss.sgi.com Tue Jun 3 17:32:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 17:32:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m540WPtF005785 for ; Tue, 3 Jun 2008 17:32:25 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8220A3040C7; Tue, 3 Jun 2008 17:33:16 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m540XCjm1722453; Wed, 4 Jun 2008 10:33:13 +1000 (AEST) From: Niv Sardi To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] scale down 074 on lower end machines References: <20080515173913.GA11494@lst.de> Date: Wed, 04 Jun 2008 10:33:17 +1000 In-Reply-To: <20080515173913.GA11494@lst.de> (Christoph Hellwig's message of "Thu, 15 May 2008 19:39:13 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16249 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig writes: > 074 takes ages to complete on my kvm test VM, but scaling it back to the > level used on IRIX makes it complete in slightly under 10 minutes. > > I'm not sure if checking for UP vs SMP is the right way to go into slow > mode, but I couldn't think of anything better. Looks good enough for now. -- Niv Sardi From owner-xfs@oss.sgi.com Tue Jun 3 17:56:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 17:56:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m540uLSY006936 for ; Tue, 3 Jun 2008 17:56:21 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id 8021A3040C8; Tue, 3 Jun 2008 17:57:13 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m540v8jm1723566; Wed, 4 Jun 2008 10:57:09 +1000 (AEST) From: Niv Sardi To: Gary Lowell Cc: markgw@sgi.com, xfs@oss.sgi.com Subject: Re: DMAPI JFS bug fixes References: <483C78E2.4090000@sonic.net> <483C8227.6090408@sgi.com> <4FC34C16-F0FA-49C5-88CC-83EEF616C218@sonic.net> Date: Wed, 04 Jun 2008 10:57:13 +1000 In-Reply-To: <4FC34C16-F0FA-49C5-88CC-83EEF616C218@sonic.net> (Gary Lowell's message of "Thu, 29 May 2008 19:16:01 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16250 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Gary Lowell writes: > On May 27, 2008, at 2:50 PM, Mark Goodwin wrote: >> Gary Lowell wrote: >>> Hi - >>> The JFS version of DMAPI had a handful of bug fixes that don't seem >>> to be in the current tree. I couldn't find anything in the list >>> archive about them. Would there be any interest in applying those >>> fixes or is DMAPI pretty much dead ? >> >> no it's not dead :) >> >>> If there is interest, I've got a patch. >> >> yes please post it here, with due reference to the original author(s). >> >> Thanks > > Great. I'll double check that they still work with TOT and post them. And i thought JFS was dead =) any patch would do, I've been looking around and couldn't really find a repository of the JFS/DMAPI changes. did you find anything like that ? Cheers, -- Niv Sardi From owner-xfs@oss.sgi.com Tue Jun 3 17:59:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 17:59:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SUBJ_ALL_CAPS autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m540x6v1007375 for ; Tue, 3 Jun 2008 17:59:07 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA15319; Wed, 4 Jun 2008 10:59:54 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 16403) id 0D43558C4C3F; Wed, 4 Jun 2008 10:59:53 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 907752 - Message-Id: <20080604005954.0D43558C4C3F@chook.melbourne.sgi.com> Date: Wed, 4 Jun 2008 10:59:53 +1000 (EST) From: xaiki@sgi.com (Niv Sardi-Altivanik) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16251 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs 074 takes ages to complete on my kvm test VM, but scaling it back to the level used on IRIX makes it complete in slightly under 10 minutes. I'm not sure if checking for UP vs SMP is the right way to go into slow mode, but I couldn't think of anything better. Signed-off-by: Christoph Hellwig Date: Wed Jun 4 10:59:31 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/xaiki/isms/xfs-cmds Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31272a xfstests/074 - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/074.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h From owner-xfs@oss.sgi.com Tue Jun 3 19:38:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 19:38:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m542cTCB012203 for ; Tue, 3 Jun 2008 19:38:29 -0700 X-ASG-Debug-ID: 1212547162-148501190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 08ED21777FA0 for ; Tue, 3 Jun 2008 19:39:22 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id mcRUuB5PNLdglfde for ; Tue, 03 Jun 2008 19:39:22 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id CA657A9C51C; Tue, 3 Jun 2008 21:39:21 -0500 (CDT) Message-ID: <4846005B.6090907@sandeen.net> Date: Tue, 03 Jun 2008 21:39:23 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Niv Sardi CC: Gary Lowell , markgw@sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: DMAPI JFS bug fixes Subject: Re: DMAPI JFS bug fixes References: <483C78E2.4090000@sonic.net> <483C8227.6090408@sgi.com> <4FC34C16-F0FA-49C5-88CC-83EEF616C218@sonic.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212547163 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52296 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16252 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Niv Sardi wrote: > Gary Lowell writes: >> On May 27, 2008, at 2:50 PM, Mark Goodwin wrote: >>> Gary Lowell wrote: >>>> Hi - >>>> The JFS version of DMAPI had a handful of bug fixes that don't seem >>>> to be in the current tree. I couldn't find anything in the list >>>> archive about them. Would there be any interest in applying those >>>> fixes or is DMAPI pretty much dead ? >>> no it's not dead :) >>> >>>> If there is interest, I've got a patch. >>> yes please post it here, with due reference to the original author(s). >>> >>> Thanks >> Great. I'll double check that they still work with TOT and post them. > > And i thought JFS was dead =) > > any patch would do, I've been looking around and couldn't really find a > repository of the JFS/DMAPI changes. did you find anything like that ? didja google for "jfs dmapi? ;) http://jfs.sourceforge.net/project/pub/dmapi/ sorting out fixes from that looks like fun though. -Eric From owner-xfs@oss.sgi.com Tue Jun 3 22:28:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 22:28:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m545S8nO027912 for ; Tue, 3 Jun 2008 22:28:10 -0700 X-ASG-Debug-ID: 1212557341-383303720000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4AE181E58F5 for ; Tue, 3 Jun 2008 22:29:01 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id K2ESYV9IJsD7wagW for ; Tue, 03 Jun 2008 22:29:01 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K3lYR-0001hs-5X; Wed, 04 Jun 2008 05:28:59 +0000 Date: Wed, 4 Jun 2008 01:28:59 -0400 From: Christoph Hellwig To: Eric Sandeen Cc: Thomas King , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article Message-ID: <20080604052859.GA6509@infradead.org> References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> <4845C254.6050104@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4845C254.6050104@sandeen.net> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212557342 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52308 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16253 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 03, 2008 at 05:14:44PM -0500, Eric Sandeen wrote: > It's also not clear to me that this is really a critical feature for > large filesystems; space allocation is not done block by block per se in > xfs, as Mr. Newman seems (?) to imply (?) The block granularity is > there throughout the fs but I'm not sure how much it matters in > practice. Dave...? For streaming I/O workloads it doesn't matter anymore, see Dave's 2006 OLS talk. The direct to bio I/O path mitigates any blocksize impact. From owner-xfs@oss.sgi.com Tue Jun 3 22:31:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 22:31:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m545V3sa028337 for ; Tue, 3 Jun 2008 22:31:03 -0700 X-ASG-Debug-ID: 1212557516-157c03e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9EF8417784AA for ; Tue, 3 Jun 2008 22:31:57 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id L5IiSXBDGB1O5ee8 for ; Tue, 03 Jun 2008 22:31:57 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K3lbI-00028l-Ti; Wed, 04 Jun 2008 05:31:56 +0000 Date: Wed, 4 Jun 2008 01:31:56 -0400 From: Christoph Hellwig To: Thomas King Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article Message-ID: <20080604053156.GB6509@infradead.org> References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212557517 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52308 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16254 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 03, 2008 at 03:48:49PM -0500, Thomas King wrote: > For the most part, XFS is used for massive filesystems (hundreds of petabytes) I think undreds of petabytes is not something we commonly see today :) hundreds of TB is more reasonable. > -Does/Will XFS support NFS v4.1? I suspect he means support for PNFS. PNFS is just like CXFS over sunrpc, so for anyone whoe cares adding an XFS layout driver shouldn't be a problem, and not actually require changes to the disk format or low-level XFS code. Note that I think pnfs a really good idea. From owner-xfs@oss.sgi.com Tue Jun 3 23:10:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 03 Jun 2008 23:10:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m546AOYV030334 for ; Tue, 3 Jun 2008 23:10:24 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 5FAF4908A3; Tue, 3 Jun 2008 23:11:12 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m546B5jm1728280; Wed, 4 Jun 2008 16:11:05 +1000 (AEST) From: Niv Sardi To: Eric Sandeen Cc: Gary Lowell , markgw@sgi.com, xfs@oss.sgi.com Subject: Re: DMAPI JFS bug fixes References: <483C78E2.4090000@sonic.net> <483C8227.6090408@sgi.com> <4FC34C16-F0FA-49C5-88CC-83EEF616C218@sonic.net> <4846005B.6090907@sandeen.net> Date: Wed, 04 Jun 2008 16:11:09 +1000 In-Reply-To: <4846005B.6090907@sandeen.net> (Eric Sandeen's message of "Tue, 03 Jun 2008 21:39:23 -0500") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16255 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Eric Sandeen writes: > Niv Sardi wrote: >> Gary Lowell writes: >>> On May 27, 2008, at 2:50 PM, Mark Goodwin wrote: >>>> Gary Lowell wrote: >>>>> Hi - >>>>> The JFS version of DMAPI had a handful of bug fixes that don't seem >>>>> to be in the current tree. I couldn't find anything in the list >>>>> archive about them. Would there be any interest in applying those >>>>> fixes or is DMAPI pretty much dead ? >>>> no it's not dead :) >>>> >>>>> If there is interest, I've got a patch. >>>> yes please post it here, with due reference to the original author(s). >>>> >>>> Thanks >>> Great. I'll double check that they still work with TOT and post them. >> >> And i thought JFS was dead =) >> >> any patch would do, I've been looking around and couldn't really find a >> repository of the JFS/DMAPI changes. did you find anything like that ? ^^^^^^^^^^ > didja google for "jfs dmapi? ;) > > http://jfs.sourceforge.net/project/pub/dmapi/ > > sorting out fixes from that looks like fun though. That's exactly why the key word here was repository, I really didn't think I'd bother to even look at a website that still had frames in 2008 =) Cheers, -- Niv Sardi From owner-xfs@oss.sgi.com Wed Jun 4 02:08:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 02:08:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5498iAg015204 for ; Wed, 4 Jun 2008 02:08:46 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA24601; Wed, 4 Jun 2008 19:09:34 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 8A91458C4C3F; Wed, 4 Jun 2008 19:09:34 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE - mkfs/xfs_growfs with ASCII CI support with incorrect output Message-Id: <20080604090934.8A91458C4C3F@chook.melbourne.sgi.com> Date: Wed, 4 Jun 2008 19:09:34 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16256 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Fix up incorrect mkfs/growfs output for ascii-ci mode Date: Wed Jun 4 19:08:53 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: donaldd@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31275a xfsprogs/mkfs/xfs_mkfs.c - 1.91 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c.diff?r1=text&tr1=1.91&r2=text&tr2=1.90&f=h - Fix up incorrect mkfs output for ascii-ci mode and update usage xfsprogs/growfs/xfs_growfs.c - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/growfs/xfs_growfs.c.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h - Fix up incorrect growfs output for ascii-ci mode From owner-xfs@oss.sgi.com Wed Jun 4 06:54:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 06:54:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54DsDid004839 for ; Wed, 4 Jun 2008 06:54:14 -0700 X-ASG-Debug-ID: 1212587705-357203760000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from villon.fh-worms.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC048177ADC0 for ; Wed, 4 Jun 2008 06:55:06 -0700 (PDT) Received: from villon.fh-worms.de (ns.fh-worms.de [143.93.160.9]) by cuda.sgi.com with ESMTP id TEGd3kn6aeXW3Cvo for ; Wed, 04 Jun 2008 06:55:06 -0700 (PDT) Received: from sapserv.fh-worms.de (sapserv.fh-worms.de [143.93.160.2]) by villon.fh-worms.de (8.14.3/8.14.2) with ESMTP id m54Dt4aX009820 for ; Wed, 4 Jun 2008 15:55:04 +0200 (CEST) Received: from 84.169.34.1 (SquirrelMail authenticated user inf769) by webmailer.fh-worms.de with HTTP; Wed, 4 Jun 2008 15:55:04 +0200 (CEST) Message-ID: <8efbf9761cbff87b03e5326866cd914d.squirrel@webmailer.fh-worms.de> Date: Wed, 4 Jun 2008 15:55:04 +0200 (CEST) X-ASG-Orig-Subj: vfs dmapi handle generation problem Subject: vfs dmapi handle generation problem From: Tim =?iso-8859-1?Q?J=F6dicke?= To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (villon.fh-worms.de [0.0.0.0]); Wed, 04 Jun 2008 15:55:05 +0200 (CEST) X-Barracuda-Connect: ns.fh-worms.de[143.93.160.9] X-Barracuda-Start-Time: 1212587706 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52342 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16257 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tim.joedicke@fh-worms.de Precedence: bulk X-list: xfs hi, i have a question about the dmapi support for xfs. in detail, it's about the method "xfs_dm_inode_to_fh()". i tried to swap out this function to vfs code and this is what it looks like now: int vfs_dm_inode_to_fh(struct inode *ip, dm_fid_t *dmfid, dm_fsid_t *dmfsid) { dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); dmfid->dm_fid_pad = 0; memcpy(&dmfid->dm_fid_ino, &ip->i_ino, sizeof(dmfid->dm_fid_ino)); dmfid->dm_fid_gen = ip->i_generation; *dmfsid = 11; // need generation system return 0; } don't be bothered by the fsid. ;) i use to have exactly one filesystem registered und every time the fsid is used, it's 11. ;) the problem is, that the generated handle is wrong. dm_handle_is_valid() says, that the handle is valid, but i cannot set a disposition e.g. if i get a handle via dm_path_to_fshandle() or dm_path_to_handle() (says the handle is bad). on the other hand, if i set a global disposition, receive the mount event and get the fshandle from the message, the handle seems to be correct? maybe you can give ma a hint? is something wrong with dm_inode_to_fh()? thanks in advance, tim From owner-xfs@oss.sgi.com Wed Jun 4 07:15:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 07:15:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54EFQSB006430 for ; Wed, 4 Jun 2008 07:15:27 -0700 X-ASG-Debug-ID: 1212588980-071401520000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EA6B111B6DD9 for ; Wed, 4 Jun 2008 07:16:20 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.122]) by cuda.sgi.com with ESMTP id jMAKCBr285WWYzAQ for ; Wed, 04 Jun 2008 07:16:20 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta02.mail.rr.com with ESMTP id <20080604141612.OLHD25858.hrndva-omta02.mail.rr.com@tomslinux.homelinux.org>; Wed, 4 Jun 2008 14:16:12 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m54EG3kB006007; Wed, 4 Jun 2008 09:16:03 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m54EG2uG006006; Wed, 4 Jun 2008 09:16:02 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.226.42 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Wed, 4 Jun 2008 09:16:02 -0500 (CDT) Message-ID: <32954.143.166.226.42.1212588962.squirrel@tomslinux.homelinux.org> In-Reply-To: <20080604053156.GB6509@infradead.org> References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> <20080604053156.GB6509@infradead.org> Date: Wed, 4 Jun 2008 09:16:02 -0500 (CDT) X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article To: "Christoph Hellwig" Cc: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.122] X-Barracuda-Start-Time: 1212588980 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52343 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16258 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs > On Tue, Jun 03, 2008 at 03:48:49PM -0500, Thomas King wrote: >> For the most part, XFS is used for massive filesystems (hundreds of petabytes) > > I think undreds of petabytes is not something we commonly see today :) > hundreds of TB is more reasonable. If I'm going to answer his two articles, he's speaking in the context of massive filesystems. True, hundreds of petabytes are not common but that's the environment he's talking about. From what I'm seeing from XFS, BTRFS, ext4, and HAMMER, Linux filesystems are going to easily keep up with the current trend. For the massive filesystems Henry speaks of, XFS has some new features I don't think he's aware of and needs to come out in this answer. Tom King From owner-xfs@oss.sgi.com Wed Jun 4 07:51:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 07:51:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54EpHsN008069 for ; Wed, 4 Jun 2008 07:51:18 -0700 X-ASG-Debug-ID: 1212591130-3a5402a80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EF11B177B77B for ; Wed, 4 Jun 2008 07:52:10 -0700 (PDT) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by cuda.sgi.com with ESMTP id kvRwmqgUpzW34sHk for ; Wed, 04 Jun 2008 07:52:10 -0700 (PDT) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id ED53E17F521; Wed, 4 Jun 2008 16:52:09 +0200 (CEST) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by smtp8-g19.free.fr (Postfix) with ESMTP id 9ED1E17F55C; Wed, 4 Jun 2008 16:52:09 +0200 (CEST) Date: Wed, 4 Jun 2008 16:52:14 +0200 From: Emmanuel Florac To: Thomas King Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article Message-ID: <20080604165214.31dceeaa@harpe.intellique.com> In-Reply-To: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> References: <19868.143.166.226.57.1212507288.squirrel@tomslinux.homelinux.org> Organization: Intellique X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Barracuda-Connect: smtp8-g19.free.fr[212.27.42.65] X-Barracuda-Start-Time: 1212591131 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA074b X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52346 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_SA074b URI: Custom Rule SA074b X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m54EpJsN008071 X-archive-position: 16259 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: eflorac@intellique.com Precedence: bulk X-list: xfs Le Tue, 3 Jun 2008 10:34:48 -0500 (CDT) Thomas King écrivait: > I am writing an article to answer Henry Newman's at > http://www.enterprisestorageforum.com/sans/features/article.php/3749926. > I've already been bugging folks on the ext4 mailing list and one of > them mentioned I should also send some of the same questions to this > list. Please let me know if I may do so. Seems like a good idea. This guy doesn't even mention XFS, while it's more or less the only viable option for big filesystems (more than 8TB). I currently use 30, 40TB XFS filesystems that work just fine. I've already compared all filesystems : XFS works great for big filesystems. JFS works well too, however it lacks a defragmenting utility which is quite a problem for big filesystems with lots of write activity. reiserfs 3.6 simply breaks over 4TB; mkfs.ext3 is so slow than it's a problem from the start, then the performance is abysmal. -- ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 4 08:05:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 08:05:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54F5tOQ009142 for ; Wed, 4 Jun 2008 08:05:55 -0700 X-ASG-Debug-ID: 1212592008-593a003e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 69D3F11B76DD for ; Wed, 4 Jun 2008 08:06:49 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 2miyFXGNzRNsP3BK for ; Wed, 04 Jun 2008 08:06:49 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id CBC8C98FE36; Wed, 4 Jun 2008 10:06:47 -0500 (CDT) Message-ID: <4846AF87.8010307@sandeen.net> Date: Wed, 04 Jun 2008 10:06:47 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Thomas King CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Questions for article Subject: Re: Questions for article References: <13033.143.166.226.57.1212526129.squirrel@tomslinux.homelinux.org> <20080604053156.GB6509@infradead.org> <32954.143.166.226.42.1212588962.squirrel@tomslinux.homelinux.org> In-Reply-To: <32954.143.166.226.42.1212588962.squirrel@tomslinux.homelinux.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212592009 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52347 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16260 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Thomas King wrote: >> On Tue, Jun 03, 2008 at 03:48:49PM -0500, Thomas King wrote: >>> For the most part, XFS is used for massive filesystems (hundreds of petabytes) >> I think undreds of petabytes is not something we commonly see today :) >> hundreds of TB is more reasonable. > > If I'm going to answer his two articles, he's speaking in the context of massive > filesystems. True, hundreds of petabytes are not common but that's the > environment he's talking about. > > From what I'm seeing from XFS, BTRFS, ext4, and HAMMER, Linux filesystems are > going to easily keep up with the current trend. For the massive filesystems > Henry speaks of, XFS has some new features I don't think he's aware of and needs > to come out in this answer. > > Tom King One thing I would be careful of is not to fall into the trap of letting Linux filesystems get bashed over things that *nobody* really has today. Stuff like PNFS, OSD, DIF etc are bleeding-edge for almost *everybody* Petabyte filesystems are hard. For *everybody* And hundred-petabyte filesystems aren't just uncommon, they don't exist AFAIK. -Eric From owner-xfs@oss.sgi.com Wed Jun 4 08:15:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 08:16:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_15, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m54FFw9R010400 for ; Wed, 4 Jun 2008 08:15:59 -0700 X-ASG-Debug-ID: 1212592612-7a3100e40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C8E051B9E6F4 for ; Wed, 4 Jun 2008 08:16:52 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 6LKn1d013GhRNjhY for ; Wed, 04 Jun 2008 08:16:52 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K3ujL-0002XM-PK; Wed, 04 Jun 2008 15:16:51 +0000 Date: Wed, 4 Jun 2008 11:16:51 -0400 From: Christoph Hellwig To: Tim J?dicke Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: vfs dmapi handle generation problem Subject: Re: vfs dmapi handle generation problem Message-ID: <20080604151651.GA16376@infradead.org> References: <8efbf9761cbff87b03e5326866cd914d.squirrel@webmailer.fh-worms.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8efbf9761cbff87b03e5326866cd914d.squirrel@webmailer.fh-worms.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1212592612 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52346 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16261 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Jun 04, 2008 at 03:55:04PM +0200, Tim J?dicke wrote: > int > vfs_dm_inode_to_fh(struct inode *ip, dm_fid_t *dmfid, dm_fsid_t *dmfsid) > { > dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); > dmfid->dm_fid_pad = 0; > memcpy(&dmfid->dm_fid_ino, &ip->i_ino, sizeof(dmfid->dm_fid_ino)); > dmfid->dm_fid_gen = ip->i_generation; > > *dmfsid = 11; // need generation system > > return 0; i_ino in struct inode is unsigned long. If you run the above code on a 32bit system you'll get crap in the upper half of dm_fid_ino. Try: int vfs_dm_inode_to_fh(struct inode *ip, dm_fid_t *dmfid, dm_fsid_t *dmfsid) { dmfid->dm_fid_len = sizeof(dm_fid_t) - sizeof(dmfid->dm_fid_len); dmfid->dm_fid_pad = 0; dmfid->dm_fid_ino = ip->i_ino; dmfid->dm_fid_gen = ip->i_generation; *dmfsid = 11; // need generation system return 0; } instead. If you actually want to support 64bit inode numbers on 32bit systems you'll have to query for it with vfs_getattr, though. From owner-xfs@oss.sgi.com Wed Jun 4 22:37:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:37:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m555beIg020214 for ; Wed, 4 Jun 2008 22:37:40 -0700 X-ASG-Debug-ID: 1212644313-12b003020000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4846111C29AA for ; Wed, 4 Jun 2008 22:38:33 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id C1bNEs8roKcbkaRS for ; Wed, 04 Jun 2008 22:38:33 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4A0A8A9C502; Thu, 5 Jun 2008 00:38:30 -0500 (CDT) Message-ID: <48477BD6.2020909@sandeen.net> Date: Thu, 05 Jun 2008 00:38:30 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Timothy Shimmin CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> In-Reply-To: <4820609C.9090306@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212644314 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52405 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16262 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > Timothy Shimmin wrote: >> David Chinner wrote: >>> On Fri, May 02, 2008 at 03:55:45PM -0500, Eric Sandeen wrote: >>>> Eric Sandeen wrote: >>>>> Eric Sandeen wrote: >>>>>> This should fix the longstanding issues with xfs and old ABI >>>>>> arm boxes, which lead to various asserts and xfs shutdowns, >>>>>> and for which an (incorrect) patch has been floating around >>>>>> for years. (Said patch made ARM internally consistent, but >>>>>> altered the normal xfs on-disk format such that it looked >>>>>> corrupted on other architectures): >>>>>> http://lists.arm.linux.org.uk/lurker/message/20040311.002034.5ecf21a2.html >>>>> ping again... >>>> ping #3... >>> Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. is it EVER going to get checked in? -Eric >>> Looks like if I don't pick it up then nobody is going to answer. >>> I'll run it through my ia64 and x86_64 test boxes and if it's ok >>> then I'll commit it. >>> >> As it only defines __arch_pack for __arm__, >> I literally can't see how on earth it won't pass for ia64 and x86-64, >> though I realise (I guess) we need to test to be sure :) >> >> So Eric tested this on qemu-arm with success. >> And there was a little debate over whether ARM-EABI would work >> currently in XFS, >> with Luca Olivetti saying in one kernel he has success and in another >> he doesn't. And Andre Draszik saying that for ARM-EABI it wouldn't >> work. > > The patch should only affect behavior on *old* abi: > > +#if defined(__arm__) && !defined(__ARM_EABI__) > > it is the only one with the unique alignment that matters here. > > There *is* still another issue on some arm chips related to processor > cache flushing; I didn't see the problem in qemu because it the emulator > does not have this behavior. > > But, it's a separate issue from the structure alignment this patch > addresses. > > One thing at a time. :) > > Thanks, > > -Eric > >> That aside, Eric has tried out on ARM without EABI (old ABI) and has had success, >> so it is at least useful for this case. >> I don't see us doing any arm testing for this ourselves :) >> >> --Tim >> > > From owner-xfs@oss.sgi.com Wed Jun 4 22:45:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:45:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m555jc7U021030 for ; Wed, 4 Jun 2008 22:45:39 -0700 Received: from [134.14.55.13] (dhcp13.melbourne.sgi.com [134.14.55.13]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA19412; Thu, 5 Jun 2008 15:46:23 +1000 Message-ID: <48477DA3.8090602@sgi.com> Date: Thu, 05 Jun 2008 15:46:11 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Eric Sandeen CC: Timothy Shimmin , xfs-oss Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> In-Reply-To: <48477BD6.2020909@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16263 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Eric Sandeen wrote: >> Timothy Shimmin wrote: >>> David Chinner wrote: >>>> On Fri, May 02, 2008 at 03:55:45PM -0500, Eric Sandeen wrote: >>>>> Eric Sandeen wrote: >>>>>> Eric Sandeen wrote: >>>>>>> This should fix the longstanding issues with xfs and old ABI >>>>>>> arm boxes, which lead to various asserts and xfs shutdowns, >>>>>>> and for which an (incorrect) patch has been floating around >>>>>>> for years. (Said patch made ARM internally consistent, but >>>>>>> altered the normal xfs on-disk format such that it looked >>>>>>> corrupted on other architectures): >>>>>>> http://lists.arm.linux.org.uk/lurker/message/20040311.002034.5ecf21a2.html >>>>>> ping again... >>>>> ping #3... >>>> > > Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. > is it EVER going to get checked in? Please take it in Tim, that nasty CORRUPTION word caught my attention :) Cheers > > -Eric > >>>> Looks like if I don't pick it up then nobody is going to answer. >>>> I'll run it through my ia64 and x86_64 test boxes and if it's ok >>>> then I'll commit it. >>>> >>> As it only defines __arch_pack for __arm__, >>> I literally can't see how on earth it won't pass for ia64 and x86-64, >>> though I realise (I guess) we need to test to be sure :) >>> >>> So Eric tested this on qemu-arm with success. >>> And there was a little debate over whether ARM-EABI would work >>> currently in XFS, >>> with Luca Olivetti saying in one kernel he has success and in another >>> he doesn't. And Andre Draszik saying that for ARM-EABI it wouldn't >>> work. >> The patch should only affect behavior on *old* abi: >> >> +#if defined(__arm__) && !defined(__ARM_EABI__) >> >> it is the only one with the unique alignment that matters here. >> >> There *is* still another issue on some arm chips related to processor >> cache flushing; I didn't see the problem in qemu because it the emulator >> does not have this behavior. >> >> But, it's a separate issue from the structure alignment this patch >> addresses. >> >> One thing at a time. :) >> >> Thanks, >> >> -Eric >> >>> That aside, Eric has tried out on ARM without EABI (old ABI) and has had success, >>> so it is at least useful for this case. >>> I don't see us doing any arm testing for this ourselves :) >>> >>> --Tim >>> >> > > -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 4 22:48:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:48:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m555mFSN021516 for ; Wed, 4 Jun 2008 22:48:15 -0700 X-ASG-Debug-ID: 1212644949-16f201c40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 982CA1783482 for ; Wed, 4 Jun 2008 22:49:09 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 1zXtNRrfd0iKX51a for ; Wed, 04 Jun 2008 22:49:09 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 09F9AA9BF4C; Thu, 5 Jun 2008 00:49:09 -0500 (CDT) Message-ID: <48477E54.9090309@sandeen.net> Date: Thu, 05 Jun 2008 00:49:08 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <48477DA3.8090602@sgi.com> In-Reply-To: <48477DA3.8090602@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212644949 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16264 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Goodwin wrote: > > Eric Sandeen wrote: >> Eric Sandeen wrote: >>> Timothy Shimmin wrote: >>>> David Chinner wrote: >>>>> On Fri, May 02, 2008 at 03:55:45PM -0500, Eric Sandeen wrote: >>>>>> Eric Sandeen wrote: >>>>>>> Eric Sandeen wrote: >>>>>>>> This should fix the longstanding issues with xfs and old ABI >>>>>>>> arm boxes, which lead to various asserts and xfs shutdowns, >>>>>>>> and for which an (incorrect) patch has been floating around >>>>>>>> for years. (Said patch made ARM internally consistent, but >>>>>>>> altered the normal xfs on-disk format such that it looked >>>>>>>> corrupted on other architectures): >>>>>>>> http://lists.arm.linux.org.uk/lurker/message/20040311.002034.5ecf21a2.html >>>>>>> ping again... >>>>>> ping #3... >>>>> >> Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. >> is it EVER going to get checked in? > > Please take it in Tim, that nasty CORRUPTION word caught my attention :) > > Cheers heh, thanks Mark. Even though it's only CORRUPTION ON ARM I guess the shouting worked. :) Seriously though if you guys have any problems with it please let me know but I don't want it to just get dropped. -Eric From owner-xfs@oss.sgi.com Wed Jun 4 22:48:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:48:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m555mlZo021648 for ; Wed, 4 Jun 2008 22:48:48 -0700 X-ASG-Debug-ID: 1212644980-12ca01e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from QMTA10.westchester.pa.mail.comcast.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C4EF8178330A for ; Wed, 4 Jun 2008 22:49:41 -0700 (PDT) Received: from QMTA10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by cuda.sgi.com with ESMTP id 505stXBNRw37Ckrv for ; Wed, 04 Jun 2008 22:49:41 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA10.westchester.pa.mail.comcast.net with comcast id a5ng1Z00B1GhbT85A00F00; Thu, 05 Jun 2008 05:49:40 +0000 Received: from stupidest.org ([67.169.95.103]) by OMTA07.westchester.pa.mail.comcast.net with comcast id a5pf1Z0072DpGEz3T00000; Thu, 05 Jun 2008 05:49:40 +0000 X-Authority-Analysis: v=1.0 c=1 a=9gEKhqqyuJkA:10 a=8jcOJXanYWoA:10 a=-14rhKMkA-efwZynJ-cA:9 a=7l0rikYvuLYaqCxl0P_gDbbJ2e0A:4 a=LY0hPdMaydYA:10 Received: by tuatara.stupidest.org (Postfix, from userid 10000) id 032C52824F77; Wed, 4 Jun 2008 22:49:38 -0700 (PDT) Date: Wed, 4 Jun 2008 22:49:38 -0700 From: Chris Wedgwood To: Eric Sandeen Cc: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Message-ID: <20080605054938.GA17690@puku.stupidest.org> References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48477BD6.2020909@sandeen.net> X-Barracuda-Connect: qmta10.westchester.pa.mail.comcast.net[76.96.62.17] X-Barracuda-Start-Time: 1212644981 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52406 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16265 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: cw@f00f.org Precedence: bulk X-list: xfs On Thu, Jun 05, 2008 at 12:38:30AM -0500, Eric Sandeen wrote: > Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. [...] > >> As it only defines __arch_pack for __arm__, __arch_pack is a horrible name and not very intuitive, what's wrong with __on_disk or something else? From owner-xfs@oss.sgi.com Wed Jun 4 22:51:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 22:51:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m555pIee022245 for ; Wed, 4 Jun 2008 22:51:19 -0700 X-ASG-Debug-ID: 1212645133-26ee03cf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8543A1EBE89 for ; Wed, 4 Jun 2008 22:52:13 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id MUHnp6DoiwI7GJqb for ; Wed, 04 Jun 2008 22:52:13 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id BBFFCA9C504; Thu, 5 Jun 2008 00:52:12 -0500 (CDT) Message-ID: <48477F0C.80000@sandeen.net> Date: Thu, 05 Jun 2008 00:52:12 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Chris Wedgwood CC: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <20080605054938.GA17690@puku.stupidest.org> In-Reply-To: <20080605054938.GA17690@puku.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212645133 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52406 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16266 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris Wedgwood wrote: > On Thu, Jun 05, 2008 at 12:38:30AM -0500, Eric Sandeen wrote: > >> Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. > > [...] > >>>> As it only defines __arch_pack for __arm__, > > __arch_pack is a horrible name and not very intuitive, what's wrong > with __on_disk or something else? > because __on_disk implies that it's on disk. __arch_pack means that it's packed on some arches. Not the same thing. If anyone wants to change the name to __purple_ponies or whatever that's fine, but the intent is to pack these 3(?) and only these 3 structs on this arch and only this arch, at least for now. 'til Jeff gets his all-singing all-dancing no-regression gcc annotation in place anyway. -Eric From owner-xfs@oss.sgi.com Wed Jun 4 23:02:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 23:02:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5562023023095 for ; Wed, 4 Jun 2008 23:02:01 -0700 Received: from [134.14.55.13] (dhcp13.melbourne.sgi.com [134.14.55.13]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19840; Thu, 5 Jun 2008 16:02:41 +1000 Message-ID: <48478175.9060009@sgi.com> Date: Thu, 05 Jun 2008 16:02:29 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Eric Sandeen CC: Timothy Shimmin , xfs-oss Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <48477DA3.8090602@sgi.com> <48477E54.9090309@sandeen.net> In-Reply-To: <48477E54.9090309@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16267 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > > heh, thanks Mark. Even though it's only CORRUPTION ON ARM I guess the > shouting worked. :) Well, we're dealing with apparent insidious corruption after failed btree AG allocations (which aren't supposed to fail). This seems to stem from the fixes for the ENOSPC deadlock bugs (two years ago, see below). you and Nathan probably remember this ..? Timothy Shimmin wrote: > Okay some history in xfs-dev archives on this bug... > plenty of reading here :) > Reverse chronological order with initial report from > guy at NEC: > > May 2006 > Review thread b/w Nathan and Ying Ping: > http://ils.corp.sgi.com/Archives/xfs-dev/200605/msg00128.html > > April 2006 > Thread - dgc, Ying, nathan > http://ils.corp.sgi.com/Archives/xfs-dev/200604/msg00005.html > > March 2006 - 2 threads > http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00002.html > http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00140.html > > Feb 2006 > http://ils.corp.sgi.com/Archives/xfs-dev/200602/msg00062.html > Initial report and suggested test case by Asano Masahiro - NEC > (fwd'ed by Eric). > Plenty of commentary by Asano. > Thread - including comments by Steve Lord: > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/13268 -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 4 23:04:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 23:04:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5564GPF023482 for ; Wed, 4 Jun 2008 23:04:17 -0700 Received: from [134.14.55.13] (dhcp13.melbourne.sgi.com [134.14.55.13]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA19922; Thu, 5 Jun 2008 16:04:59 +1000 Message-ID: <48478200.7080308@sgi.com> Date: Thu, 05 Jun 2008 16:04:48 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: markgw@sgi.com CC: Eric Sandeen , Timothy Shimmin , xfs-oss Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <48477DA3.8090602@sgi.com> <48477E54.9090309@sandeen.net> <48478175.9060009@sgi.com> In-Reply-To: <48478175.9060009@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16268 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Just realized you can't read the ils threads. But you can read this one: http://thread.gmane.org/gmane.comp.file-systems.xfs.general/13268 -- Mark Mark Goodwin wrote: > > > Eric Sandeen wrote: >> >> heh, thanks Mark. Even though it's only CORRUPTION ON ARM I guess the >> shouting worked. :) > > Well, we're dealing with apparent insidious corruption after > failed btree AG allocations (which aren't supposed to fail). > This seems to stem from the fixes for the ENOSPC deadlock bugs > (two years ago, see below). you and Nathan probably remember > this ..? > > Timothy Shimmin wrote: >> Okay some history in xfs-dev archives on this bug... >> plenty of reading here :) >> Reverse chronological order with initial report from >> guy at NEC: >> >> May 2006 >> Review thread b/w Nathan and Ying Ping: >> http://ils.corp.sgi.com/Archives/xfs-dev/200605/msg00128.html >> >> April 2006 >> Thread - dgc, Ying, nathan >> http://ils.corp.sgi.com/Archives/xfs-dev/200604/msg00005.html >> >> March 2006 - 2 threads >> http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00002.html >> http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00140.html >> >> Feb 2006 >> http://ils.corp.sgi.com/Archives/xfs-dev/200602/msg00062.html >> Initial report and suggested test case by Asano Masahiro - NEC >> (fwd'ed by Eric). >> Plenty of commentary by Asano. >> Thread - including comments by Steve Lord: >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/13268 > -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 4 23:05:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 23:05:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m55659g9023631 for ; Wed, 4 Jun 2008 23:05:09 -0700 X-ASG-Debug-ID: 1212645962-1d7903c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3A60211C4D73 for ; Wed, 4 Jun 2008 23:06:02 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id wXB2eHWLCmYCm7qX for ; Wed, 04 Jun 2008 23:06:02 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 39A3998FF76; Thu, 5 Jun 2008 01:06:02 -0500 (CDT) Message-ID: <48478249.8060301@sandeen.net> Date: Thu, 05 Jun 2008 01:06:01 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <48477DA3.8090602@sgi.com> <48477E54.9090309@sandeen.net> <48478175.9060009@sgi.com> In-Reply-To: <48478175.9060009@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212645963 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52407 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16269 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Goodwin wrote: > > Eric Sandeen wrote: >> heh, thanks Mark. Even though it's only CORRUPTION ON ARM I guess the >> shouting worked. :) > > Well, we're dealing with apparent insidious corruption after > failed btree AG allocations (which aren't supposed to fail). > This seems to stem from the fixes for the ENOSPC deadlock bugs > (two years ago, see below). you and Nathan probably remember > this ..? nah it's easier to hit than that. Just run xfs-qa on arm with old abi and you'll hit it plenty quickly. there are other calculations around that assume no padding. Even if it doesn't look corrupted on arm, the filesystem isn't portable. -Eric > Timothy Shimmin wrote: >> Okay some history in xfs-dev archives on this bug... >> plenty of reading here :) >> Reverse chronological order with initial report from >> guy at NEC: >> >> May 2006 >> Review thread b/w Nathan and Ying Ping: >> http://ils.corp.sgi.com/Archives/xfs-dev/200605/msg00128.html >> >> April 2006 >> Thread - dgc, Ying, nathan >> http://ils.corp.sgi.com/Archives/xfs-dev/200604/msg00005.html >> >> March 2006 - 2 threads >> http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00002.html >> http://ils.corp.sgi.com/Archives/xfs-dev/200603/msg00140.html >> >> Feb 2006 >> http://ils.corp.sgi.com/Archives/xfs-dev/200602/msg00062.html >> Initial report and suggested test case by Asano Masahiro - NEC >> (fwd'ed by Eric). >> Plenty of commentary by Asano. >> Thread - including comments by Steve Lord: >> http://thread.gmane.org/gmane.comp.file-systems.xfs.general/13268 > From owner-xfs@oss.sgi.com Wed Jun 4 23:33:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 04 Jun 2008 23:33:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m556XPn4025936 for ; Wed, 4 Jun 2008 23:33:25 -0700 X-ASG-Debug-ID: 1212647658-691200680000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A248D11C599F for ; Wed, 4 Jun 2008 23:34:19 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id bdePHPLbQgrYZhp7 for ; Wed, 04 Jun 2008 23:34:19 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id AEE7A994A37; Thu, 5 Jun 2008 01:34:18 -0500 (CDT) Message-ID: <484788E9.8050800@sandeen.net> Date: Thu, 05 Jun 2008 01:34:17 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Chris Wedgwood CC: Timothy Shimmin , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <480E89B5.8070006@sandeen.net> <481B7FD1.3030107@sandeen.net> <20080505070847.GH155679365@sgi.com> <481FDCD1.2010905@sgi.com> <4820609C.9090306@sandeen.net> <48477BD6.2020909@sandeen.net> <20080605054938.GA17690@puku.stupidest.org> In-Reply-To: <20080605054938.GA17690@puku.stupidest.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212647659 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52407 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16270 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Chris Wedgwood wrote: > On Thu, Jun 05, 2008 at 12:38:30AM -0500, Eric Sandeen wrote: > >> Guys, this is SIMPLE, SAFE, and it fixes a CORRUPTION BUG. > > [...] > >>>> As it only defines __arch_pack for __arm__, > > __arch_pack is a horrible name and not very intuitive, what's wrong > with __on_disk or something else? > > seriously, if you don't like the name or the style of the fix that's fine, we can fix that up, but I went to enough trouble to track down the issue and test the fix it seems worth actually... fixing it. If you want to __on_disk annotate everything and only pack it on arm OABI that might be less hacky. cw almost convinced me of this. I was just going for "least invasive" here. -Eric From owner-xfs@oss.sgi.com Thu Jun 5 00:30:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 00:30:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m557UDNn005115 for ; Thu, 5 Jun 2008 00:30:15 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA21689; Thu, 5 Jun 2008 17:30:58 +1000 Message-ID: <48479632.4080406@sgi.com> Date: Thu, 05 Jun 2008 17:30:58 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] factor out inode has attrs check References: <20080603113955.GA2703@lst.de> In-Reply-To: <20080603113955.GA2703@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16271 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Looks good. I'll run thru qa and check in. So there are a couple of cases where XFS_DINODE_FMT_LOCAL is used in xfs_attr_inactive() as well as the noattr check. Okay, that's because the EAs would be in shortform so we don't have to do anything for inactive here (the inode inactive will suffice). Apart from that they are all replacements (callouts) except for the superfluous check Christoph mentioned. Cool. --Tim Christoph Hellwig wrote: > Note that xfs_attr_fetch did the check twice while keeping the inode > locked and we can just remove the superflous check. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_attr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:32:06.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 > @@ -111,6 +111,17 @@ xfs_attr_name_to_xname( > return 0; > } > > +STATIC int > +xfs_inode_hasattr( > + struct xfs_inode *ip) > +{ > + if (!XFS_IFORK_Q(ip) || > + (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > + ip->i_d.di_anextents == 0)) > + return 0; > + return 1; > +} > + > /*======================================================================== > * Overall external interface routines. > *========================================================================*/ > @@ -122,10 +133,8 @@ xfs_attr_fetch(xfs_inode_t *ip, struct x > xfs_da_args_t args; > int error; > > - if ((XFS_IFORK_Q(ip) == 0) || > - (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - ip->i_d.di_anextents == 0)) > - return(ENOATTR); > + if (!xfs_inode_hasattr(ip)) > + return ENOATTR; > > /* > * Fill in the arg structure for this request. > @@ -143,11 +152,7 @@ xfs_attr_fetch(xfs_inode_t *ip, struct x > /* > * Decide on what work routines to call based on the inode size. > */ > - if (XFS_IFORK_Q(ip) == 0 || > - (ip->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - ip->i_d.di_anextents == 0)) { > - error = XFS_ERROR(ENOATTR); > - } else if (ip->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > + if (ip->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > error = xfs_attr_shortform_getvalue(&args); > } else if (xfs_bmap_one_block(ip, XFS_ATTR_FORK)) { > error = xfs_attr_leaf_get(&args); > @@ -523,9 +528,7 @@ xfs_attr_remove_int(xfs_inode_t *dp, str > /* > * Decide on what work routines to call based on the inode size. > */ > - if (XFS_IFORK_Q(dp) == 0 || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp)) { > error = XFS_ERROR(ENOATTR); > goto out; > } > @@ -595,11 +598,9 @@ xfs_attr_remove( > return error; > > xfs_ilock(dp, XFS_ILOCK_SHARED); > - if (XFS_IFORK_Q(dp) == 0 || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp)) { > xfs_iunlock(dp, XFS_ILOCK_SHARED); > - return(XFS_ERROR(ENOATTR)); > + return XFS_ERROR(ENOATTR); > } > xfs_iunlock(dp, XFS_ILOCK_SHARED); > > @@ -615,9 +616,7 @@ xfs_attr_list_int(xfs_attr_list_context_ > /* > * Decide on what work routines to call based on the inode size. > */ > - if (XFS_IFORK_Q(dp) == 0 || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp)) { > error = 0; > } else if (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > error = xfs_attr_shortform_list(context); > @@ -810,12 +809,10 @@ xfs_attr_inactive(xfs_inode_t *dp) > ASSERT(! XFS_NOT_DQATTACHED(mp, dp)); > > xfs_ilock(dp, XFS_ILOCK_SHARED); > - if ((XFS_IFORK_Q(dp) == 0) || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp) || > + dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > xfs_iunlock(dp, XFS_ILOCK_SHARED); > - return(0); > + return 0; > } > xfs_iunlock(dp, XFS_ILOCK_SHARED); > > @@ -848,10 +845,8 @@ xfs_attr_inactive(xfs_inode_t *dp) > /* > * Decide on what work routines to call based on the inode size. > */ > - if ((XFS_IFORK_Q(dp) == 0) || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) || > - (dp->i_d.di_aformat == XFS_DINODE_FMT_EXTENTS && > - dp->i_d.di_anextents == 0)) { > + if (!xfs_inode_hasattr(dp) || > + dp->i_d.di_aformat == XFS_DINODE_FMT_LOCAL) { > error = 0; > goto out; > } > From owner-xfs@oss.sgi.com Thu Jun 5 00:58:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 00:58:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m557wFIg007925 for ; Thu, 5 Jun 2008 00:58:19 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA22026; Thu, 5 Jun 2008 17:58:58 +1000 Message-ID: <48479CC2.8000605@sgi.com> Date: Thu, 05 Jun 2008 17:58:58 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr References: <20080603114837.GB2703@lst.de> In-Reply-To: <20080603114837.GB2703@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16272 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Looks reasonable. Will run thru qa etc. -Tim. ----- Notes as walk thru patch...(prob. already mentioned by hch preamble:) xfs_attr.c * move stats/shutdown/lock/trace from xfs_attr_list into xfs_attr_list_int * xfs_attr_put_listent -> adds in a xfs_attr_namesp_match_overrides() check -> use alist for context->alist * remove xfs_attr_kern_list and xfs_attr_kern_list_sizes from xfs_attr.c * xfs_attr_list -> remove the conditional context setup code for put_listent callbacks -> KERNOVAL and KERNAMELS code removed from xfs_attr_list xfs_attr_leaf.c * call the put_listent function with the flags instead of the namespace * remove calls to xfs_attr_namesp_match_overrides() in the listing functions as we are now using flags instead of namespaces xfs_attr_leaf.h * move context def out as hch said - good idea xfs_xattr.c * xfs_attr_kern_list and xfs_attr_kern_list_sizes have moved here * xfs_vn_listxattr -> remove ATTR_KERN flags and setup put_listent function depending if want sizes or not -> replace result with context.count xfs_acl.c * removes ATTR_KERNACCESS flag from fetch call the rest of the KERN macros removed are LS ones -> TODO: need to look up references to KERNACCESS -> Okay, looks like it hasn't been used for a while So we remove: -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ Q: how do we get away with this? * ATTR_KERNAMELS is used for the top level EA list interface with linux, so if we do the call high enough then it isn't needed * ATTR_KERNORMALS will include secure namespace even if don't have namespace match * ATTR_KERNROOTLS will include root namespace even if don't have namespace match That we don't need these anymore shows how wacky that they were :-) * KERNACCESS unused for a while by the looks of it --Tim Christoph Hellwig wrote: > This patch switches xfs_vn_listxattr to set it's put_listent callback > directly and not go through xfs_attr_list. > > The changes to the lowleve attr code are: > > - the put_listent callback now gets the ondisk flags passed and > performce the namespace lookup and check aswell as the check > for the right attribute root itself > - xfs_attr_list_int is made non-static for use by other callers > than xfs_attr_list and now performs the inode locking and tracing > itself > > The changes to the xfs_attr_list path are: > > - all checks for now uneeded ATTR_KERN flags are gone, and only > the IRIX interface is supported for this code path > - xfs_attr_put_listent is simplified by not needing to lookup > the namespace but rather compare the integer flags directly. > > The changes to xfs_vn_listxattr are: > > - now directly calls xfs_attr_list_int with it's own put_listent > callbacks > - attr namespace prefix are now looked up by simple helpers, > struct attrnames is gone. > > Other changes: > > - struct xfs_attr_list_context is moved from xfs_attr_leaf.h into > xfs_attr.h. It's not realted to the leaf format at all and > xfs_attr.h contains the interface to the attr code which it is > part of now. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_attr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:44:07.000000000 +0200 > @@ -16,8 +16,6 @@ > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > */ > > -#include > - > #include "xfs.h" > #include "xfs_fs.h" > #include "xfs_types.h" > @@ -607,12 +605,20 @@ xfs_attr_remove( > return xfs_attr_remove_int(dp, &xname, flags); > } > > -STATIC int > +int > xfs_attr_list_int(xfs_attr_list_context_t *context) > { > int error; > xfs_inode_t *dp = context->dp; > > + XFS_STATS_INC(xs_attr_list); > + > + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > + return EIO; > + > + xfs_ilock(dp, XFS_ILOCK_SHARED); > + xfs_attr_trace_l_c("syscall start", context); > + > /* > * Decide on what work routines to call based on the inode size. > */ > @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ > } else { > error = xfs_attr_node_list(context); > } > + > + xfs_iunlock(dp, XFS_ILOCK_SHARED); > + xfs_attr_trace_l_c("syscall end", context); > + > return error; > } > > @@ -634,6 +644,18 @@ xfs_attr_list_int(xfs_attr_list_context_ > ((ATTR_ENTBASESIZE + (namelen) + 1 + sizeof(u_int32_t)-1) \ > & ~(sizeof(u_int32_t)-1)) > > +STATIC int > +xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) > +{ > + if (((arg_flags & ATTR_SECURE) == 0) != > + ((ondisk_flags & XFS_ATTR_SECURE) == 0)) > + return 0; > + if (((arg_flags & ATTR_ROOT) == 0) != > + ((ondisk_flags & XFS_ATTR_ROOT) == 0)) > + return 0; > + return 1; > +} > + > /* > * Format an attribute and copy it out to the user's buffer. > * Take care to check values and protect against them changing later, > @@ -641,74 +663,43 @@ xfs_attr_list_int(xfs_attr_list_context_ > */ > /*ARGSUSED*/ > STATIC int > -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, > +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, > char *name, int namelen, > int valuelen, char *value) > { > + struct attrlist *alist = (struct attrlist *)context->alist; > attrlist_ent_t *aep; > int arraytop; > > ASSERT(!(context->flags & ATTR_KERNOVAL)); > ASSERT(context->count >= 0); > ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); > - ASSERT(context->firstu >= sizeof(*context->alist)); > + ASSERT(context->firstu >= sizeof(*alist)); > ASSERT(context->firstu <= context->bufsize); > > - arraytop = sizeof(*context->alist) + > - context->count * sizeof(context->alist->al_offset[0]); > + if (xfs_attr_namesp_match_overrides(context->flags, flags)) > + return 0; > + > + arraytop = sizeof(*alist) + > + context->count * sizeof(alist->al_offset[0]); > context->firstu -= ATTR_ENTSIZE(namelen); > if (context->firstu < arraytop) { > xfs_attr_trace_l_c("buffer full", context); > - context->alist->al_more = 1; > + alist->al_more = 1; > context->seen_enough = 1; > return 1; > } > > - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); > + aep = (attrlist_ent_t *)&context->alist[context->firstu]; > aep->a_valuelen = valuelen; > memcpy(aep->a_name, name, namelen); > - aep->a_name[ namelen ] = 0; > - context->alist->al_offset[ context->count++ ] = context->firstu; > - context->alist->al_count = context->count; > + aep->a_name[namelen] = 0; > + alist->al_offset[context->count++] = context->firstu; > + alist->al_count = context->count; > xfs_attr_trace_l_c("add", context); > return 0; > } > > -STATIC int > -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, > - char *name, int namelen, > - int valuelen, char *value) > -{ > - char *offset; > - int arraytop; > - > - ASSERT(context->count >= 0); > - > - arraytop = context->count + namesp->attr_namelen + namelen + 1; > - if (arraytop > context->firstu) { > - context->count = -1; /* insufficient space */ > - return 1; > - } > - offset = (char *)context->alist + context->count; > - strncpy(offset, namesp->attr_name, namesp->attr_namelen); > - offset += namesp->attr_namelen; > - strncpy(offset, name, namelen); /* real name */ > - offset += namelen; > - *offset = '\0'; > - context->count += namesp->attr_namelen + namelen + 1; > - return 0; > -} > - > -/*ARGSUSED*/ > -STATIC int > -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, > - char *name, int namelen, > - int valuelen, char *value) > -{ > - context->count += namesp->attr_namelen + namelen + 1; > - return 0; > -} > - > /* > * Generate a list of extended attribute names and optionally > * also value lengths. Positive return value follows the XFS > @@ -725,10 +716,9 @@ xfs_attr_list( > attrlist_cursor_kern_t *cursor) > { > xfs_attr_list_context_t context; > + struct attrlist *alist; > int error; > > - XFS_STATS_INC(xs_attr_list); > - > /* > * Validate the cursor. > */ > @@ -749,52 +739,21 @@ xfs_attr_list( > /* > * Initialize the output buffer. > */ > + memset(&context, 0, sizeof(context)); > context.dp = dp; > context.cursor = cursor; > - context.count = 0; > - context.dupcnt = 0; > context.resynch = 1; > context.flags = flags; > - context.seen_enough = 0; > - context.alist = (attrlist_t *)buffer; > - context.put_value = 0; > - > - if (flags & ATTR_KERNAMELS) { > - context.bufsize = bufsize; > - context.firstu = context.bufsize; > - if (flags & ATTR_KERNOVAL) > - context.put_listent = xfs_attr_kern_list_sizes; > - else > - context.put_listent = xfs_attr_kern_list; > - } else { > - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ > - context.firstu = context.bufsize; > - context.alist->al_count = 0; > - context.alist->al_more = 0; > - context.alist->al_offset[0] = context.bufsize; > - context.put_listent = xfs_attr_put_listent; > - } > - > - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > - return EIO; > + context.alist = buffer; > + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ > + context.firstu = context.bufsize; > + context.put_listent = xfs_attr_put_listent; > > - xfs_ilock(dp, XFS_ILOCK_SHARED); > - xfs_attr_trace_l_c("syscall start", &context); > + alist = (struct attrlist *)context.alist; > + alist->al_offset[0] = context.bufsize; > > error = xfs_attr_list_int(&context); > - > - xfs_iunlock(dp, XFS_ILOCK_SHARED); > - xfs_attr_trace_l_c("syscall end", &context); > - > - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { > - /* must return negated buffer size or the error */ > - if (context.count < 0) > - error = XFS_ERROR(ERANGE); > - else > - error = -context.count; > - } else > - ASSERT(error >= 0); > - > + ASSERT(error >= 0); > return error; > } > > @@ -2357,12 +2316,7 @@ xfs_attr_trace_enter(int type, char *whe > (void *)((__psunsigned_t)context->bufsize), > (void *)((__psunsigned_t)context->count), > (void *)((__psunsigned_t)context->firstu), > - (void *)((__psunsigned_t) > - (((context->count > 0) && > - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) > - ? (ATTR_ENTRY(context->alist, > - context->count-1)->a_valuelen) > - : 0)), > + NULL, > (void *)((__psunsigned_t)context->dupcnt), > (void *)((__psunsigned_t)context->flags), > (void *)a13, (void *)a14, (void *)a15); > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:44:07.000000000 +0200 > @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att > * Namespace helper routines > *========================================================================*/ > > -STATIC_INLINE attrnames_t * > -xfs_attr_flags_namesp(int flags) > -{ > - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: > - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); > -} > - > /* > * If namespace bits don't match return 0. > * If all match then return 1. > @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int > return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); > } > > -/* > - * If namespace bits don't match and we don't have an override for it > - * then return 0. > - * If all match or are overridable then return 1. > - */ > -STATIC_INLINE int > -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) > -{ > - if (((arg_flags & ATTR_SECURE) == 0) != > - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && > - !(arg_flags & ATTR_KERNORMALS)) > - return 0; > - if (((arg_flags & ATTR_ROOT) == 0) != > - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && > - !(arg_flags & ATTR_KERNROOTLS)) > - return 0; > - return 1; > -} > - > > /*======================================================================== > * External routines when attribute fork size < XFS_LITINO(mp). > @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co > (XFS_ISRESET_CURSOR(cursor) && > (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { > for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { > - attrnames_t *namesp; > - > - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { > - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); > - continue; > - } > - namesp = xfs_attr_flags_namesp(sfe->flags); > error = context->put_listent(context, > - namesp, > + sfe->flags, > (char *)sfe->nameval, > (int)sfe->namelen, > (int)sfe->valuelen, > @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co > kmem_free(sbuf); > return XFS_ERROR(EFSCORRUPTED); > } > - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { > - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); > - continue; > - } > + > sbp->entno = i; > sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); > sbp->name = (char *)sfe->nameval; > @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co > * Loop putting entries into the user buffer. > */ > for ( ; i < nsbuf; i++, sbp++) { > - attrnames_t *namesp; > - > - namesp = xfs_attr_flags_namesp(sbp->flags); > - > if (cursor->hashval != sbp->hash) { > cursor->hashval = sbp->hash; > cursor->offset = 0; > } > error = context->put_listent(context, > - namesp, > + sbp->flags, > sbp->name, > sbp->namelen, > sbp->valuelen, > @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > */ > retval = 0; > for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { > - attrnames_t *namesp; > - > if (be32_to_cpu(entry->hashval) != cursor->hashval) { > cursor->hashval = be32_to_cpu(entry->hashval); > cursor->offset = 0; > @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > > if (entry->flags & XFS_ATTR_INCOMPLETE) > continue; /* skip incomplete entries */ > - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) > - continue; > - > - namesp = xfs_attr_flags_namesp(entry->flags); > > if (entry->flags & XFS_ATTR_LOCAL) { > xfs_attr_leaf_name_local_t *name_loc = > XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); > > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_loc->nameval, > (int)name_loc->namelen, > be16_to_cpu(name_loc->valuelen), > @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > if (retval) > return retval; > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_rmt->name, > (int)name_rmt->namelen, > valuelen, > (char*)args.value); > kmem_free(args.value); > - } > - else { > + } else { > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_rmt->name, > (int)name_rmt->namelen, > valuelen, > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:44:07.000000000 +0200 > @@ -30,7 +30,6 @@ > > struct attrlist; > struct attrlist_cursor_kern; > -struct attrnames; > struct xfs_dabuf; > struct xfs_da_args; > struct xfs_da_state; > @@ -204,33 +203,6 @@ static inline int xfs_attr_leaf_entsize_ > return (((bsize) >> 1) + ((bsize) >> 2)); > } > > - > -/*======================================================================== > - * Structure used to pass context around among the routines. > - *========================================================================*/ > - > - > -struct xfs_attr_list_context; > - > -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, > - char *, int, int, char *); > - > -typedef struct xfs_attr_list_context { > - struct xfs_inode *dp; /* inode */ > - struct attrlist_cursor_kern *cursor; /* position in list */ > - struct attrlist *alist; /* output buffer */ > - int seen_enough; /* T/F: seen enough of list? */ > - int count; /* num used entries */ > - int dupcnt; /* count dup hashvals seen */ > - int bufsize; /* total buffer size */ > - int firstu; /* first used byte in buffer */ > - int flags; /* from VOP call */ > - int resynch; /* T/F: resynch with cursor */ > - int put_value; /* T/F: need value for listent */ > - put_listent_func_t put_listent; /* list output fmt function */ > - int index; /* index into output buffer */ > -} xfs_attr_list_context_t; > - > /* > * Used to keep a list of "remote value" extents when unlinking an inode. > */ > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:44:07.000000000 +0200 > @@ -17,7 +17,11 @@ > */ > > #include "xfs.h" > +#include "xfs_da_btree.h" > +#include "xfs_bmap_btree.h" > +#include "xfs_inode.h" > #include "xfs_attr.h" > +#include "xfs_attr_leaf.h" > #include "xfs_acl.h" > #include "xfs_vnodeops.h" > > @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, > return __xfs_xattr_set(inode, name, value, size, flags, 0); > } > > -struct attrnames attr_user = { > - .attr_name = "user.", > - .attr_namelen = sizeof("user.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_user_handler = { > .prefix = XATTR_USER_PREFIX, > .get = xfs_xattr_user_get, > @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod > return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); > } > > -struct attrnames attr_trusted = { > - .attr_name = "trusted.", > - .attr_namelen = sizeof("trusted.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_trusted_handler = { > .prefix = XATTR_TRUSTED_PREFIX, > .get = xfs_xattr_trusted_get, > @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode > return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); > } > > -struct attrnames attr_secure = { > - .attr_name = "security.", > - .attr_namelen = sizeof("security.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_security_handler = { > .prefix = XATTR_SECURITY_PREFIX, > .get = xfs_xattr_secure_get, > @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers > NULL > }; > > +static unsigned int xfs_attr_prefix_len(int flags) > +{ > + if (flags & XFS_ATTR_SECURE) > + return sizeof("security"); > + else if (flags & XFS_ATTR_ROOT) > + return sizeof("trusted"); > + else > + return sizeof("user"); > +} > + > +static const char *xfs_attr_prefix(int flags) > +{ > + if (flags & XFS_ATTR_SECURE) > + return xfs_xattr_security_handler.prefix; > + else if (flags & XFS_ATTR_ROOT) > + return xfs_xattr_trusted_handler.prefix; > + else > + return xfs_xattr_user_handler.prefix; > +} > + > +static int > +xfs_attr_kern_list(struct xfs_attr_list_context *context, int flags, > + char *name, int namelen, int valuelen, char *value) > +{ > + unsigned int prefix_len = xfs_attr_prefix_len(flags); > + char *offset; > + int arraytop; > + > + ASSERT(context->count >= 0); > + > + /* > + * Only show root namespace entries if we are actually allowed to > + * see them. > + */ > + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) > + return 0; > + > + arraytop = context->count + prefix_len + namelen + 1; > + if (arraytop > context->firstu) { > + context->count = -1; /* insufficient space */ > + return 1; > + } > + offset = (char *)context->alist + context->count; > + strncpy(offset, xfs_attr_prefix(flags), prefix_len); > + offset += prefix_len; > + strncpy(offset, name, namelen); /* real name */ > + offset += namelen; > + *offset = '\0'; > + context->count += prefix_len + namelen + 1; > + return 0; > +} > + > +static int > +xfs_attr_kern_list_sizes(struct xfs_attr_list_context *context, int flags, > + char *name, int namelen, int valuelen, char *value) > +{ > + context->count += xfs_attr_prefix_len(flags) + namelen + 1; > + return 0; > +} > + > static int > list_one_attr(const char *name, const size_t len, void *data, > size_t size, ssize_t *result) > @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si > ssize_t > xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) > { > + struct xfs_attr_list_context context; > + struct attrlist_cursor_kern cursor = { 0 }; > struct inode *inode = dentry->d_inode; > - struct xfs_inode *ip = XFS_I(inode); > - attrlist_cursor_kern_t cursor = { 0 }; > - int error, xflags; > - ssize_t result; > - > - xflags = ATTR_KERNAMELS; > - if (!size) > - xflags |= ATTR_KERNOVAL; > - > - if (capable(CAP_SYS_ADMIN)) > - xflags |= ATTR_KERNFULLS; > - else > - xflags |= ATTR_KERNORMALS; > - > + int error; > > /* > * First read the regular on-disk attributes. > */ > - result = -xfs_attr_list(ip, data, size, xflags, &cursor); > - if (result < 0) > - return result; > + memset(&context, 0, sizeof(context)); > + context.dp = XFS_I(inode); > + context.cursor = &cursor; > + context.resynch = 1; > + context.alist = data; > + context.bufsize = size; > + context.firstu = context.bufsize; > + > + if (size) > + context.put_listent = xfs_attr_kern_list; > + else > + context.put_listent = xfs_attr_kern_list_sizes; > + > + xfs_attr_list_int(&context); > + if (context.count < 0) > + return -ERANGE; > > /* > * Then add the two synthetic ACL attributes. > @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_access(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_ACCESS, > strlen(POSIX_ACL_XATTR_ACCESS) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_default(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, > strlen(POSIX_ACL_XATTR_DEFAULT) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > > - return result; > + return context.count; > } > Index: linux-2.6-xfs/fs/xfs/xfs_acl.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-01 14:44:07.000000000 +0200 > @@ -341,8 +341,7 @@ xfs_acl_iaccess( > > /* If the file has no ACL return -1. */ > rval = sizeof(xfs_acl_t); > - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, > - ATTR_ROOT | ATTR_KERNACCESS)) { > + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { > _ACL_FREE(acl); > return -1; > } > Index: linux-2.6-xfs/fs/xfs/xfs_attr.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-01 14:44:07.000000000 +0200 > @@ -18,9 +18,11 @@ > #ifndef __XFS_ATTR_H__ > #define __XFS_ATTR_H__ > > +struct xfs_inode; > +struct xfs_da_args; > +struct xfs_attr_list_context; > + > /* > - * xfs_attr.h > - * > * Large attribute lists are structured around Btrees where all the data > * elements are in the leaf nodes. Attribute names are hashed into an int, > * then that int is used as the index into the Btree. Since the hashval > @@ -35,17 +37,6 @@ > * External interfaces > *========================================================================*/ > > -struct cred; > -struct xfs_attr_list_context; > - > -typedef struct attrnames { > - char * attr_name; > - unsigned int attr_namelen; > -} attrnames_t; > - > -extern struct attrnames attr_user; > -extern struct attrnames attr_secure; > -extern struct attrnames attr_trusted; > > #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ > #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ > @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; > #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ > #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ > > -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ > #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ > #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ > -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ > - > -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ > -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ > -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) > > /* > * The maximum size (into the kernel or returned from the kernel) of an > @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { > > > /*======================================================================== > - * Function prototypes for the kernel. > + * Structure used to pass context around among the routines. > *========================================================================*/ > > -struct xfs_inode; > -struct attrlist_cursor_kern; > -struct xfs_da_args; > + > +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, > + char *, int, int, char *); > + > +typedef struct xfs_attr_list_context { > + struct xfs_inode *dp; /* inode */ > + struct attrlist_cursor_kern *cursor; /* position in list */ > + char *alist; /* output buffer */ > + int seen_enough; /* T/F: seen enough of list? */ > + int count; /* num used entries */ > + int dupcnt; /* count dup hashvals seen */ > + int bufsize; /* total buffer size */ > + int firstu; /* first used byte in buffer */ > + int flags; /* from VOP call */ > + int resynch; /* T/F: resynch with cursor */ > + int put_value; /* T/F: need value for listent */ > + put_listent_func_t put_listent; /* list output fmt function */ > + int index; /* index into output buffer */ > +} xfs_attr_list_context_t; > + > + > +/*======================================================================== > + * Function prototypes for the kernel. > + *========================================================================*/ > > /* > * Overall external interface routines. > */ > int xfs_attr_inactive(struct xfs_inode *dp); > - > -int xfs_attr_shortform_getvalue(struct xfs_da_args *); > int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); > int xfs_attr_rmtval_get(struct xfs_da_args *args); > +int xfs_attr_list_int(struct xfs_attr_list_context *); > > #endif /* __XFS_ATTR_H__ */ > From owner-xfs@oss.sgi.com Thu Jun 5 09:15:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 09:15:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m55GFOkw021215 for ; Thu, 5 Jun 2008 09:15:24 -0700 X-ASG-Debug-ID: 1212682578-237e018c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rv-out-0708.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8DF1E1EF9C8 for ; Thu, 5 Jun 2008 09:16:18 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.242]) by cuda.sgi.com with ESMTP id lOFMmqf1U2nVrM6M for ; Thu, 05 Jun 2008 09:16:18 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so621401rvb.32 for ; Thu, 05 Jun 2008 09:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1nvA+sW+LduydZAVQSuoPB1jqpguEjXfT+bRaNSsuhs=; b=p3lH35u7GQJU+qcw0JEsTP6s2yXLQxnI3Ecu3o1snY3euxXMSCJMcnQRkbElSPguWo f3NMuBKbv2W5Tqhx699Q9Eqv8Q2YEPtnuPkYkgZUegLrXdB3A7TnnVFvWLdtpx0ZUsxw NV1kY9PaRijJbsI2vRjUxChCgz8+uNh26tJvM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=yF8pY0LhdWwt/hnVoKbJ+pv7iCJ44yDc/JdG18wx0mQmRco6oUW3iHplljxDTGpVDP 3twNFTjeV/VAm8FNPrI3MfvijZct5NPNrf54OZ+48xhHkexGk1D3gRz5Ws6m82ycByE/ cSIBEioUG+ntwqIm8+IdkjmI4ltQT2OwuO4v0= Received: by 10.141.129.14 with SMTP id g14mr1040209rvn.56.1212682577936; Thu, 05 Jun 2008 09:16:17 -0700 (PDT) Received: by 10.141.43.7 with HTTP; Thu, 5 Jun 2008 09:16:17 -0700 (PDT) Message-ID: <3607657a0806050916rd26b4f4tee83305644e66416@mail.gmail.com> Date: Thu, 5 Jun 2008 12:16:17 -0400 From: "Spam Magnet" To: "Stefan Smietanowski" X-ASG-Orig-Subj: Re: XFS: SB validate failed Subject: Re: XFS: SB validate failed Cc: "Timothy Shimmin" , "Eric Sandeen" , xfs@oss.sgi.com In-Reply-To: <4845A857.3090905@stesmi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <3607657a0805291005k457791cej1c5f867da0f95965@mail.gmail.com> <48408D3E.3090401@gmail.com> <48409981.1050405@stesmi.com> <48425148.1080105@gmail.com> <48427DEE.40400@stesmi.com> <3607657a0806031036r702ab6a5w7ca6517c19395b9b@mail.gmail.com> <3607657a0806031056w24efa917q625f13bfe9eaa706@mail.gmail.com> <4845949F.7080209@stesmi.com> <3607657a0806031239l6d788868u2f5654efcabf4abc@mail.gmail.com> <4845A857.3090905@stesmi.com> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.242] X-Barracuda-Start-Time: 1212682578 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52446 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16273 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: spam.wax@gmail.com Precedence: bulk X-list: xfs On Tue, Jun 3, 2008 at 4:23 PM, Stefan Smietanowski wrote: >> I think they are but I used -u option of fdisk: >> $ fdisk -ul jaz7.img >> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders >> Units = sectors of 1 * 512 bytes >> ----- partitions ----- >> Pt# Device Info Start End Sectors Id System >> 8: jaz7.img1 3072 2091007 2087936 a SGI xfs >> 9: jaz7.img2 0 3071 3072 0 SGI volhdr >> 11: jaz7.img3 0 2091007 2091008 6 SGI volume >> >> which lists partitions in sector units. As oppose to: >> >> $ fdisk -l jaz7.img >> >> Disk jaz7.img (SGI disk label): 255 heads, 63 sectors, 0 cylinders >> Units = cylinders of 16065 * 512 bytes >> >> ----- partitions ----- >> Pt# Device Info Start End Sectors Id System >> 8: jaz7.img1 1 130 2087936 a SGI xfs >> 9: jaz7.img2 0 0 3072 0 SGI volhdr >> 11: jaz7.img3 0 130 2091008 6 SGI volume > > I'd give it a shot regardless as I don't remember if the sector size is > actually IN the partition table and if it's NOT then it'll show the > native blocksize of the device, which is 512bytes! > > Just try it, what do you have to lose? I mean do the od .. > Worst case you get garbage or zeroes. 3072*2048=6,291,456 (30000000 octal) $ od -t c jaz7.img | grep 30000000 30000000 377 377 367 371 \0 \0 0 365 \0 \0 ? y \0 \0 004 016 130000000 201 244 \0 001 \0 \0 \0 \0 \0 \0 006 201 B 373 306 307 So I guess that didn't work either :( From owner-xfs@oss.sgi.com Thu Jun 5 21:40:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 21:40:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m564eZ8V017276 for ; Thu, 5 Jun 2008 21:40:38 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA15868; Fri, 6 Jun 2008 14:41:12 +1000 Message-ID: <4848BFE8.6000205@sgi.com> Date: Fri, 06 Jun 2008 14:41:12 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr References: <20080603114837.GB2703@lst.de> In-Reply-To: <20080603114837.GB2703@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16274 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > > /* > * Then add the two synthetic ACL attributes. > @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_access(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_ACCESS, > strlen(POSIX_ACL_XATTR_ACCESS) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_default(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, > strlen(POSIX_ACL_XATTR_DEFAULT) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) Need to fix param type. re: static int list_one_attr(const char *name, const size_t len, void *data, size_t size, ssize_t *result) typedef struct xfs_attr_list_context { struct xfs_inode *dp; /* inode */ struct attrlist_cursor_kern *cursor; /* position in list */ char *alist; /* output buffer */ int seen_enough; /* T/F: seen enough of list? */ int count; /* num used entries */ => mismatch type on &context.count (int) and list_one_attr's result param (ssize_t => long) --Tim From owner-xfs@oss.sgi.com Thu Jun 5 22:08:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 22:08:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5658Bmr019276 for ; Thu, 5 Jun 2008 22:08:13 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA16369; Fri, 6 Jun 2008 15:08:58 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 56FB758C4C3F; Fri, 6 Jun 2008 15:08:58 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 982930 - fix dir2 shortform structures on ARM old ABI Message-Id: <20080606050858.56FB758C4C3F@chook.melbourne.sgi.com> Date: Fri, 6 Jun 2008 15:08:58 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16275 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Pack some shortform dir2 structures for the ARM old ABI architecture. Finally put this in for Eric and the users of this arch. From Eric initially... This should fix the longstanding issues with xfs and old ABI arm boxes, which lead to various asserts and xfs shutdowns, and for which an (incorrect) patch has been floating around for years. I've verified this patch by comparing the on-disk structure layouts using pahole from the dwarves package, as well as running through a bit of xfsqa under qemu-arm, modified so that the check/repair phase after each test actually executes check/repair from the x86 host, on the filesystem populated by the arm emulator. Thus far it all looks good. There are 2 other structures with extra padding at the end, but they don't seem to cause trouble. I suppose they could be packed as well: xfs_dir2_data_unused_t and xfs_dir2_sf_t. Note that userspace needs a similar treatment, and any filesystems which were running with the previous rogue "fix" will now see corruption (either in the kernel, or during xfs_repair) with this fix properly in place; it may be worth teaching xfs_repair to identify and fix that specific issue. Signed-off-by: Eric Sandeen Date: Fri Jun 6 15:07:06 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31280a fs/xfs/xfs_dir2_sf.h - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_sf.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h - Fix up some dir2 shortform structures for ARM using packing fs/xfs/linux-2.6/xfs_linux.h - 1.167 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_linux.h.diff?r1=text&tr1=1.167&r2=text&tr2=1.166&f=h - setup __arch_pack for packing for ARM old ABI From owner-xfs@oss.sgi.com Thu Jun 5 22:16:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 22:16:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m565GqOp020200 for ; Thu, 5 Jun 2008 22:16:53 -0700 X-ASG-Debug-ID: 1212729466-61e8011f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BF1881FAC74 for ; Thu, 5 Jun 2008 22:17:47 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id 1tyQIL7Q5giYX6Zs for ; Thu, 05 Jun 2008 22:17:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIZjSEh5LFOM/2dsb2JhbACwGg X-IronPort-AV: E=Sophos;i="4.27,599,1204464600"; d="scan'208";a="127927529" Received: from ppp121-44-83-140.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.83.140]) by ipmail04.adl2.internode.on.net with ESMTP; 06 Jun 2008 14:47:44 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K4UKe-0002pt-Fz; Fri, 06 Jun 2008 15:17:44 +1000 Date: Fri, 6 Jun 2008 15:17:44 +1000 From: Dave Chinner To: Tim Shimmin Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 982930 - fix dir2 shortform structures on ARM old ABI Subject: Re: TAKE 982930 - fix dir2 shortform structures on ARM old ABI Message-ID: <20080606051744.GN10720@disturbed> Mail-Followup-To: Tim Shimmin , xfs@oss.sgi.com References: <20080606050858.56FB758C4C3F@chook.melbourne.sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080606050858.56FB758C4C3F@chook.melbourne.sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1212729467 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52497 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16276 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 06, 2008 at 03:08:58PM +1000, Tim Shimmin wrote: > Pack some shortform dir2 structures for the ARM old ABI architecture. > > Finally put this in for Eric and the users of this arch. Don't forget the matching userspace patch ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 5 22:43:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 05 Jun 2008 22:43:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m565h3Z4021975 for ; Thu, 5 Jun 2008 22:43:03 -0700 X-ASG-Debug-ID: 1212731036-606502670000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E59F01FAD1B; Thu, 5 Jun 2008 22:43:56 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id VriOWPdB0f1OvzJ3; Thu, 05 Jun 2008 22:43:56 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m565hlOc029947 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 6 Jun 2008 07:43:48 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m565hl0J029945; Fri, 6 Jun 2008 07:43:47 +0200 Date: Fri, 6 Jun 2008 07:43:47 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] simplify xfs_vn_listxattr Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr Message-ID: <20080606054347.GA29902@lst.de> References: <20080603114837.GB2703@lst.de> <4848BFE8.6000205@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4848BFE8.6000205@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1212731037 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52497 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16277 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 06, 2008 at 02:41:12PM +1000, Timothy Shimmin wrote: > Need to fix param type. > > re: > > static int > list_one_attr(const char *name, const size_t len, void *data, > size_t size, ssize_t *result) > > typedef struct xfs_attr_list_context { > struct xfs_inode *dp; /* inode */ > struct attrlist_cursor_kern *cursor; /* position in list */ > char *alist; /* output buffer */ > int seen_enough; /* T/F: seen enough of list? */ > int count; /* num used entries */ > > => mismatch type on &context.count (int) and list_one_attr's result > param (ssize_t => long) Yes, didn't see that on my 32-bit machine :) count should probably be ssize_t. From owner-xfs@oss.sgi.com Fri Jun 6 06:34:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 06 Jun 2008 06:34:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m56DYM72001056 for ; Fri, 6 Jun 2008 06:34:23 -0700 X-ASG-Debug-ID: 1212759315-402502430000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from noire.bucharest.roedu.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C1FE7795692 for ; Fri, 6 Jun 2008 06:35:15 -0700 (PDT) Received: from noire.bucharest.roedu.net (noire.Bucharest.roedu.net [141.85.128.18]) by cuda.sgi.com with ESMTP id 53rrYf3nH5R9medZ for ; Fri, 06 Jun 2008 06:35:15 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (noire.bucharest.roedu.net [141.85.128.18]) (authenticated bits=0) by noire.bucharest.roedu.net (8.12.10/8.12.10) with ESMTP id m56CZSke018730 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jun 2008 15:35:28 +0300 From: dizzy To: xfs@oss.sgi.com X-ASG-Orig-Subj: readdir() ordering guarantees on XFS Subject: readdir() ordering guarantees on XFS Date: Fri, 6 Jun 2008 16:34:13 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806061634.13990.dizzy@roedu.net> X-Barracuda-Connect: noire.Bucharest.roedu.net[141.85.128.18] X-Barracuda-Start-Time: 1212759316 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52528 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16278 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: xfs Hello POSIX leaves unspecified the order of getting the entries with readdir(). This is normal since different filesystems may implement their own techniques to organize entries in a directory (linear, hash, various search trees, etc). But if I can makes sure that several Linux machines will have the same FS (ie XFS), mount options and same kernels can assume that traversing the same file hierarchy structure (that is a file structure with the exact same directories and files as names, structure, attributes, except maybe "ctime" which we can't really control in Linux) can I expect that traversing using readdir() will give me the entries in the exact same order? Or are there any other conditions that I have to check for that would guarantee it? (such as, for a linear directory aproach one has to have created the directory entries in the same order on all the machines to expect same order on readdir()). Currently, we workaround this issue by reading all the directory entries, sorting them and traversing the entries in the sorted order. This however has been proven to slow the traversal (depth first traversal) operation about 30% than doing it in the order received from readdir() (I even had the test code read the whole directory contents, sort them in memory but still have it traverse in the order readdir() reported and it is 30% faster than traversing in the sorted order). Any idea? Thanks! PS: please Cc: me as I'm not subscribed to the list, thank you -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST From owner-xfs@oss.sgi.com Fri Jun 6 07:15:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 06 Jun 2008 07:15:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m56EF0cU004339 for ; Fri, 6 Jun 2008 07:15:00 -0700 X-ASG-Debug-ID: 1212761754-3780018f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F1F96C38D5A for ; Fri, 6 Jun 2008 07:15:54 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 8p5BrqQpSJFIIQZE for ; Fri, 06 Jun 2008 07:15:54 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 3EB5BA9C502; Fri, 6 Jun 2008 09:15:53 -0500 (CDT) Message-ID: <48494698.9080704@sandeen.net> Date: Fri, 06 Jun 2008 09:15:52 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs-oss CC: Barry Naujok X-ASG-Orig-Subj: Re: [PATCH] fix dir2 shortform structures on ARM old ABI Subject: Re: [PATCH] fix dir2 shortform structures on ARM old ABI References: <47DB4181.7040603@sandeen.net> <47E1D3C3.1050000@sandeen.net> In-Reply-To: <47E1D3C3.1050000@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212761754 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52532 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16279 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > Here's the userspace side. > Just a reminder after Dave's reminder. :) -Eric > -Eric > > > Index: xfs-cmds/xfsprogs/include/platform_defs.h.in > =================================================================== > --- xfs-cmds.orig/xfsprogs/include/platform_defs.h.in > +++ xfs-cmds/xfsprogs/include/platform_defs.h.in > @@ -147,4 +147,11 @@ typedef unsigned long long __psunsigned_ > | (minor&IRIX_DEV_MAXMIN))) > #define IRIX_DEV_TO_KDEVT(dev) makedev(IRIX_DEV_MAJOR(dev),IRIX_DEV_MINOR(dev)) > > +/* ARM old ABI has some weird alignment/padding */ > +#if defined(__arm__) && !defined(__ARM_EABI__) > +#define __arch_pack __attribute__((packed)) > +#else > +#define __arch_pack > +#endif > + > #endif /* __XFS_PLATFORM_DEFS_H__ */ > Index: xfs-cmds/xfsprogs/include/xfs_dir2_sf.h > =================================================================== > --- xfs-cmds.orig/xfsprogs/include/xfs_dir2_sf.h > +++ xfs-cmds/xfsprogs/include/xfs_dir2_sf.h > @@ -62,7 +62,7 @@ typedef union { > * Normalized offset (in a data block) of the entry, really xfs_dir2_data_off_t. > * Only need 16 bits, this is the byte offset into the single block form. > */ > -typedef struct { __uint8_t i[2]; } xfs_dir2_sf_off_t; > +typedef struct { __uint8_t i[2]; } __arch_pack xfs_dir2_sf_off_t; > > /* > * The parent directory has a dedicated field, and the self-pointer must > @@ -76,14 +76,14 @@ typedef struct xfs_dir2_sf_hdr { > __uint8_t count; /* count of entries */ > __uint8_t i8count; /* count of 8-byte inode #s */ > xfs_dir2_inou_t parent; /* parent dir inode number */ > -} xfs_dir2_sf_hdr_t; > +} __arch_pack xfs_dir2_sf_hdr_t; > > typedef struct xfs_dir2_sf_entry { > __uint8_t namelen; /* actual name length */ > xfs_dir2_sf_off_t offset; /* saved offset */ > __uint8_t name[1]; /* name, variable size */ > xfs_dir2_inou_t inumber; /* inode number, var. offset */ > -} xfs_dir2_sf_entry_t; > +} __arch_pack xfs_dir2_sf_entry_t; > > typedef struct xfs_dir2_sf { > xfs_dir2_sf_hdr_t hdr; /* shortform header */ > > > > > From owner-xfs@oss.sgi.com Fri Jun 6 11:32:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 06 Jun 2008 11:32:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m56IWQWF025675 for ; Fri, 6 Jun 2008 11:32:26 -0700 X-ASG-Debug-ID: 1212777199-425202d10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from defout.telus.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 378D417921B4 for ; Fri, 6 Jun 2008 11:33:19 -0700 (PDT) Received: from defout.telus.net (defout.telus.net [199.185.220.240]) by cuda.sgi.com with ESMTP id KuLPhha9m071OQmF for ; Fri, 06 Jun 2008 11:33:19 -0700 (PDT) Received: from priv-edtnaa04.telusplanet.net ([216.232.71.140]) by priv-edtnes25.telusplanet.net (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20080606183258.QPM16573.priv-edtnes25.telusplanet.net@priv-edtnaa04.telusplanet.net> for ; Fri, 6 Jun 2008 12:32:58 -0600 Received: from mail.zymeworks.com (s216-232-71-140.bc.hsia.telus.net [216.232.71.140]) by priv-edtnaa04.telusplanet.net (BorderWare MXtreme Infinity Mail Firewall) with ESMTP id D3G198CHK8 for ; Fri, 6 Jun 2008 12:33:18 -0600 (MDT) Received: from localhost (localhost [127.0.0.1]) by mail.zymeworks.com (Postfix) with ESMTP id 4FD60756D2D for ; Fri, 6 Jun 2008 11:33:18 -0700 (PDT) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at zymeworks.com Received: from mail.zymeworks.com ([127.0.0.1]) by localhost (barista.lan.zymeworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elqEHuWEccG6 for ; Fri, 6 Jun 2008 11:33:17 -0700 (PDT) Received: from zubrowka.lan.zymeworks.com (zubrowka.lan.zymeworks.com [10.3.3.16]) by mail.zymeworks.com (Postfix) with ESMTP id DC29D756D22 for ; Fri, 6 Jun 2008 11:33:17 -0700 (PDT) Message-Id: From: Kamil Kisiel To: xfs@oss.sgi.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) X-ASG-Orig-Subj: XFS and block-level snapshots Subject: XFS and block-level snapshots Date: Fri, 6 Jun 2008 11:33:17 -0700 X-Mailer: Apple Mail (2.919.2) X-Barracuda-Connect: defout.telus.net[199.185.220.240] X-Barracuda-Start-Time: 1212777200 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52549 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16280 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kamil@zymeworks.com Precedence: bulk X-list: xfs Hello, I had a question about XFS integrity and performing block-level snapshots. We currently have a 2TB (but growing soon..) volume mounted by a Linux host with kernel 2.6.23 over iSCSI from our SAN. Our SAN unit has the capability to perform block-level snapshots, which is done at regular intervals. I know that it is recommended to perform an xfs_freeze before performing a snapshot. However, the control of the snapshots is independent from the OS, which currently has no knowledge of their occurrence. I'm curious as to the repercussions of this. I understand that in all likelyhood, the integrity of files which are currently being written will not be preserved. However, even with an xfs_freeze this is not guaranteed, as an application may require additional disk transactions to maintain the file in a valid state (it is not necessarily atomic, depending on the application). As far as metadata transactions are concerned, the journal should make these atomic, so there should not be any problem there? Basically, I'd like to know what is the worst that could happen, and why an xfs_freeze is necessary in this scenario. ____________ Kamil Kisiel HPC Systems Engineer, Zymeworks Inc. 201-1401 West Broadway, Vancouver, BC, V6H 1H6, Canada Tel: (604) 678-1388 ext. 135 Fax: (604) 737-7077 www.zymeworks.com From owner-xfs@oss.sgi.com Sat Jun 7 16:02:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 07 Jun 2008 16:02:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m57N21R7031052 for ; Sat, 7 Jun 2008 16:02:03 -0700 X-ASG-Debug-ID: 1212879775-47cf01bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DAFC1C4F4F2 for ; Sat, 7 Jun 2008 16:02:55 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id RsNjyUSUWOwLgSPF for ; Sat, 07 Jun 2008 16:02:55 -0700 (PDT) Received: (qmail 9474 invoked from network); 7 Jun 2008 23:02:54 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Jun 2008 23:02:54 -0000 Message-ID: <484B15A3.4030505@sauce.co.nz> Date: Sun, 08 Jun 2008 11:11:31 +1200 From: Richard Scobie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Filestreams Subject: Filestreams Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1212879776 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0041 1.0000 -1.9945 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.99 X-Barracuda-Spam-Status: No, SCORE=-1.99 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52662 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16281 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Is my understanding of filestreams correct, in that files written to a particular filestreams enabled directory are all allocated to 1 ag as long as the filestreams timeout is not exceeded - which I believe is 30s? In other words, if I copy 100 files into a directory, (cp -a dir_containing_100_files dest_dir), wait 60 seconds and do (cp -a dir_containing_100_different_files dest_dir), each directory and contents in dest_dir will be stored in a single, different ag? Also, would it be possible for the filestreams parameter to be added to man pages/kernel docs? Thanks, Richard From owner-xfs@oss.sgi.com Sun Jun 8 20:30:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 08 Jun 2008 20:30:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m593UsUp010343 for ; Sun, 8 Jun 2008 20:30:54 -0700 X-ASG-Debug-ID: 1212982309-688502960000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D212AC565FE for ; Sun, 8 Jun 2008 20:31:49 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id FbRvyiIC497OGmcW for ; Sun, 08 Jun 2008 20:31:49 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E9A17A9BF46; Sun, 8 Jun 2008 22:31:46 -0500 (CDT) Message-ID: <484CA425.3080606@sandeen.net> Date: Sun, 08 Jun 2008 22:31:49 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Richard Scobie CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams Subject: Re: Filestreams References: <484B15A3.4030505@sauce.co.nz> In-Reply-To: <484B15A3.4030505@sauce.co.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1212982309 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52775 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16282 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Richard Scobie wrote: > Is my understanding of filestreams correct, in that files written to a > particular filestreams enabled directory are all allocated to 1 ag as > long as the filestreams timeout is not exceeded - which I believe is 30s? > > In other words, if I copy 100 files into a directory, (cp -a > dir_containing_100_files dest_dir), wait 60 seconds and do (cp -a > dir_containing_100_different_files dest_dir), each directory and > contents in dest_dir will be stored in a single, different ag? > > Also, would it be possible for the filestreams parameter to be added to > man pages/kernel docs? Yes please :) I was just noticing last week that there is no documentation anywhere on this feature .... -Eric > Thanks, > > Richard > > From owner-xfs@oss.sgi.com Mon Jun 9 08:00:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 08:00:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_05,J_CHICKENPOX_210, MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m59F09O1026558 for ; Mon, 9 Jun 2008 08:00:10 -0700 X-ASG-Debug-ID: 1213023663-1f41027a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from server515.appriver.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DDFA7C58DC8 for ; Mon, 9 Jun 2008 08:01:03 -0700 (PDT) Received: from server515.appriver.com (server515d.exghost.com [72.32.253.78]) by cuda.sgi.com with ESMTP id CH1yGFQfOjeM7iCl for ; Mon, 09 Jun 2008 08:01:03 -0700 (PDT) Received: by server515.appriver.com (CommuniGate Pro PIPE 5.2.0) with PIPE id 40013683; Mon, 09 Jun 2008 10:00:55 -0500 Received: from FE1.exchange.rackspace.com ([72.32.49.5] verified) by server515.appriver.com (CommuniGate Pro SMTP 5.2.0) with ESMTP id 40013576; Mon, 09 Jun 2008 10:00:53 -0500 Received: from 34093-C3-EVS3.exchange.rackspace.com ([192.168.1.161]) by FE1.exchange.rackspace.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Jun 2008 10:00:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-ASG-Orig-Subj: RE: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Subject: RE: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Date: Mon, 9 Jun 2008 09:56:14 -0500 Message-ID: In-Reply-To: <20080609142717.GB24950@rap.rap.dk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Thread-Index: AcjKPO3cniFd2lezSOGBLh6Tu+5cDgAAFrqA References: <8CA981CB5C2B4D6-E68-18E2@MBLK-M14.sysops.aol.com> <20080609142717.GB24950@rap.rap.dk> From: "David Lethe" To: =?iso-8859-1?Q?Keld_J=F8rn_Simonsen?= Cc: , , , , , , X-OriginalArrivalTime: 09 Jun 2008 15:00:58.0795 (UTC) FILETIME=[A01C3FB0:01C8CA41] X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Policy: GLOBAL X-Primary: david@santools.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: david@santools.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.5 X-Note-Reverse-DNS: fe1.exchange.rackspace.com X-Note-WHTLIST: david@santools.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 81 82 148 X-Note: Mail Class: ALLOWEDSENDER X-Barracuda-Connect: server515d.exghost.com[72.32.253.78] X-Barracuda-Start-Time: 1213023664 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.75 X-Barracuda-Spam-Status: No, SCORE=-1.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52821 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m59F0AO1026563 X-archive-position: 16283 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@santools.com Precedence: bulk X-list: xfs -----Original Message----- From: Keld Jørn Simonsen [mailto:keld@dkuug.dk] Sent: Monday, June 09, 2008 9:27 AM To: David Lethe Cc: thomas62186218@aol.com; dan.j.williams@gmail.com; jpiszcz@lucidpixels.com; linux-kernel@vger.kernel.org; linux-raid@vger.kernel.org; xfs@oss.sgi.com; ap@solarrain.com Subject: Re: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors On Mon, Jun 09, 2008 at 08:41:18AM -0500, David Lethe wrote: > For faster random I/O: > * Decrease chunk size > * Migrate files that have higher random I/O to a RAID1 set, using disks > with the lowest access time/latency > * If possible, use the /dev/shm file system > * Determine I/O size of apps that produce most of the random I/O, and > make sure that md+filesystem matches. If most random I/O is 32KB, then > don't waste bandwidth by making md read 256KB at a time, or making it > read 2x16KB I/Os. Also don't build md sets like 4-drive RAID5, (Do a > 5-drive RAID5 set), because non-parity data isn't a multiple of 2. A > 10-drive RAID5 set with heavy random I/O is also profoundly wrong > because you are just removing the opportunity to have all of those heads > processing random I/O. > * If you only have one partition on a md set, then partition it into a > few file systems. This may provide greater opportunity for caching I/Os. > * Experiment with different file systems, and optimize accordingly. > * Turn of journaling, or at least move journals to RAID1 devices. > * Add RAM and try to increase buffer cache in attempt to improve cache > hit percentage (this works up to a point) > * Buy a small SSD and migrate files that get pounded with random I/O to > that device. (Make sure you don't get a flash SSD, but a DRAM based SSD > that satisfies random I/O in nanoseconds instead of millisecs). They are > expensive, but the appropriate device. This is how companies such as > Google & Ebay manage to get things done. > The biggest thing to remember about random I/O, is that they are > expensive, so just step back and think about ways to minimize the I/O > requests to disk in the first place, and/or to spread the I/O across > multiple raidsets that can work independently to satisfy your load. All > suggestions above will not work for everybody. You must understand the > nature of the bottleneck. For faster random IO I would suggest to use raid10,f2 for the random reading, it performs like raid0, something like more than double the speed of a normal single-drive file system. For random writes raid10,f2 performs like most other mirrorred raids, given that data needs to be written twice. Try and see if you can gat any HW raids to match that performance. best regards keld -------------------------------------------------------------------------------- Keld: That is counter-intuitive. The issue is random IOPs, not throughput. I do not understand how a RAID10 would provide more IOs per sec than RAID1. Or, since you are using RAID10, then how could RAID10 serve more random I/Os then a pair of RAID1 filesystems? RAID0 dictates that each disk will supply half of the data you want per application I/O request. At least with RAID1, then each disk can get all the data you want with a single request, and dual-porting/load balancing will allow both disks to work independently of each other on reads so the disk with the least amount of load at any time can work on the request. That is why RAID1 can be faster than JBOD. Granted writes are handled differently, but with any RAID0 implementation you still have to write Half of the data to each disk requiring 2 I/Os + journaling & housekeeping. David From owner-xfs@oss.sgi.com Mon Jun 9 16:14:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 16:14:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,MIME_8BIT_HEADER autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m59NEXIX014612 for ; Mon, 9 Jun 2008 16:14:34 -0700 X-ASG-Debug-ID: 1213053327-163701be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from rap.rap.dk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6B628209C79 for ; Mon, 9 Jun 2008 16:15:28 -0700 (PDT) Received: from rap.rap.dk (213.237.47.228.adsl.vbr.worldonline.dk [213.237.47.228]) by cuda.sgi.com with ESMTP id G1yVpgj8JMWGBnAU for ; Mon, 09 Jun 2008 16:15:28 -0700 (PDT) Received: by rap.rap.dk (Postfix, from userid 500) id 0923D64754; Tue, 10 Jun 2008 01:15:26 +0200 (CEST) Date: Tue, 10 Jun 2008 01:15:26 +0200 From: Keld =?iso-8859-1?Q?J=F8rn?= Simonsen To: David Lethe Cc: thomas62186218@aol.com, dan.j.williams@gmail.com, jpiszcz@lucidpixels.com, linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com, ap@solarrain.com X-ASG-Orig-Subj: Re: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Subject: Re: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors Message-ID: <20080609231526.GA6404@rap.rap.dk> References: <8CA981CB5C2B4D6-E68-18E2@MBLK-M14.sysops.aol.com> <20080609142717.GB24950@rap.rap.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.11 X-Barracuda-Connect: 213.237.47.228.adsl.vbr.worldonline.dk[213.237.47.228] X-Barracuda-Start-Time: 1213053329 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.65 X-Barracuda-Spam-Status: No, SCORE=-1.65 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52852 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16284 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: keld@dkuug.dk Precedence: bulk X-list: xfs On Mon, Jun 09, 2008 at 09:56:14AM -0500, David Lethe wrote: > > > From: Keld Jørn Simonsen [mailto:keld@dkuug.dk] > Sent: Monday, June 09, 2008 9:27 AM > To: David Lethe > Cc: thomas62186218@aol.com; dan.j.williams@gmail.com; jpiszcz@lucidpixels.com; linux-kernel@vger.kernel.org; linux-raid@vger.kernel.org; xfs@oss.sgi.com; ap@solarrain.com > Subject: Re: Linux MD RAID 5 Benchmarks Across (3 to 10) 300 Gigabyte Veliciraptors > > For faster random IO I would suggest to use raid10,f2 for the random > reading, it performs like raid0, something like more than double the > speed of a normal single-drive file system. For random writes raid10,f2 > performs like most other mirrorred raids, given that data needs to be > written twice. > > Try and see if you can gat any HW raids to match that performance. > > best regards > keld > > -------------------------------------------------------------------------------- > Keld: > That is counter-intuitive. The issue is random IOPs, not throughput. That probably depends on your use. I run Linux mirrors, and for that purpose thruputi of random IO, especially reading, is key. For data bases it is probably something else, probably IOP. here I also think that Linux MD raid has good performance. Once again I think my pet RAID type, raid10,f2 has something to offer, especially with lower random seek rates, as the track span is shorter, and on the outer, faster tracks. And other uses may have other bottlenecks. In general I think that thruput is an important figure, as it shows how fast a system can process a given amount of data. Areas where this may count include web servers, file servers, print servers, ordinary workstations. I actually think those 2 measures for random IO: IO thruput, and IO transactions per second, for read and write, are the two most important measures. For the IO transacions per second I agree that your suggestions are good advice. I would like to have good benchmarking tools for this, and also I would like figures on how Linux MD compares to different HW RAID. > I do not > understand how a RAID10 would provide more IOs per sec than RAID1. Or, since > you are using RAID10, then how could RAID10 serve more random I/Os then a pair > of RAID1 filesystems? In theory you are right. The MD implementation of RAID1 does not seem to handle random seeks so well, AFAIK. Then the seeks are confined with raid10,f2 to less than half of the disk arm movement, taht does speed things up a little. > RAID0 dictates that each disk will supply half > of the data you want per application I/O request. At least with RAID1, then each > disk can get all the data you want with a single request, and dual-porting/load balancing > will allow both disks to work independently of each other on reads so the disk with > the least amount of load at any time can work on the request. That is why RAID1 can be > faster than JBOD. > > Granted writes are handled differently, but with any RAID0 implementation you still have to write > Half of the data to each disk requiring 2 I/Os + journaling & housekeeping. yes, indeed. best regards keld From owner-xfs@oss.sgi.com Mon Jun 9 18:48:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 18:49:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5A1mr3e001523 for ; Mon, 9 Jun 2008 18:48:55 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA11522; Tue, 10 Jun 2008 11:49:39 +1000 Message-ID: <484DDDB3.70000@sgi.com> Date: Tue, 10 Jun 2008 11:49:39 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Eric Sandeen , Richard Scobie CC: xfs@oss.sgi.com Subject: Re: Filestreams References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> In-Reply-To: <484CA425.3080606@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16285 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Richard Scobie wrote: >> Is my understanding of filestreams correct, in that files written to a >> particular filestreams enabled directory are all allocated to 1 ag as >> long as the filestreams timeout is not exceeded - which I believe is 30s? >> >> In other words, if I copy 100 files into a directory, (cp -a >> dir_containing_100_files dest_dir), wait 60 seconds and do (cp -a >> dir_containing_100_different_files dest_dir), each directory and >> contents in dest_dir will be stored in a single, different ag? >> >> Also, would it be possible for the filestreams parameter to be added to >> man pages/kernel docs? > > Yes please :) I was just noticing last week that there is no > documentation anywhere on this feature .... > > -Eric > >> Thanks, >> >> Richard >> >> > Sounds a reasonable idea :) BTW, Sam Vaughan wrote some tutorial notes on the allocator and in particular filestreams which I've pasted below: (I thought it might be here: http://oss.sgi.com/projects/xfs/training/ but I can't see it in the allocator lab and slides). ------------------------------------------------------------------------- Filestreams Allocator A certain class of applications such as those doing film scanner video ingest will write many large files to a directory in sequence. It's important for playback performance that these files end up allocated next to each other on disk, since consecutive data is retrieved optimally by hardware RAID read-ahead. XFS's standard allocator starts out doing the right thing as far as file allocation is concerned. Even if multiple streams are being written simultaneously, their files will be placed separately and contiguously on disk. The problem is that once an allocation group fills up, a new one must be chosen and there's no longer a parent directory in a unique AG to use as an AG "owner". Without a way to reserve the new AG for the original directory's use, all the files being allocated by all the streams will start getting placed in the same AGs as each other. The result is that consecutive frames in one directory are placed on disk with frames from other directories interleaved between them, which is a worst-case layout for playback performance. When reading back the frames in directory A, hardware RAID read-ahead will cache data from frames in directory B which is counterproductive. Create a file system with a small AG size to demonstrate: sles10:~ sjv: sudo mkfs.xfs -d agsize=64m /dev/sdb7 > /dev/null sles10:~ sjv: sudo mount /dev/sdb7 /test sles10:~ sjv: sudo chmod 777 /test sles10:~ sjv: cd /test sles10:/test sjv: Create ten 10MB files concurrently in two directories: sles10:/test sjv: mkdir a b sles10:/test sjv: for dir in a b; do > for file in `seq 0 9`; do > xfs_mkfile 10m $dir/$file > done & > done; wait 2>/dev/null [1] 30904 [2] 30905 sles10:/test sjv: ls -lid * */* 131 drwxr-xr-x 2 sjv users 86 2006-10-20 13:48 a 132 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/0 133 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/1 134 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/2 135 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/3 136 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/4 137 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/5 138 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/6 139 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/7 140 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/8 141 -rw------- 1 sjv users 10485760 2006-10-20 13:48 a/9 262272 drwxr-xr-x 2 sjv users 86 2006-10-20 13:48 b 262273 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/0 262274 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/1 262275 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/2 262276 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/3 262277 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/4 262278 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/5 262279 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/6 262280 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/7 262281 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/8 262282 -rw------- 1 sjv users 10485760 2006-10-20 13:48 b/9 sles10:/test sjv: Note that all the inodes are in the same AGs as each other. What about the file data? Use xfs_bmap -v to examine the extents: sles10:/test sjv: for file in `seq 0 9`; do > bmap_a=`xfs_bmap -v a/$file | tail -1` > bmap_b=`xfs_bmap -v b/$file | tail -1` > ag_a=`echo $bmap_a | awk '{print $4}'` > ag_b=`echo $bmap_b | awk '{print $4}'` > br_a=`echo $bmap_a | awk '{printf "%-18s", $3}'` > br_b=`echo $bmap_b | awk '{printf "%-18s", $3}'` > echo a/$file: $ag_a "$br_a" b/$file: $ag_b "$br_b" > done a/0: 0 96..20575 b/0: 1 131168..151647 a/1: 0 20576..41055 b/1: 1 151648..172127 a/2: 0 41056..61535 b/2: 1 172128..192607 a/3: 0 61536..82015 b/3: 1 192608..213087 a/4: 0 82016..102495 b/4: 1 213088..233567 a/5: 0 102496..122975 b/5: 1 233568..254047 a/6: 2 299600..300111 b/6: 2 262208..275007 a/7: 2 338016..338527 b/7: 2 312400..312911 a/8: 2 344672..361567 b/8: 3 393280..401983 a/9: 2 361568..382047 b/9: 3 401984..421951 sles10:/test sjv: The middle column is the AG number and the right column is the block range. Note how the extents for files in both directories get placed on top of each other in AG 2. Something to note in the results is that even though the file extents have worked their way up into AGs 2 and 3, the inode numbers show that the file inodes are all in the same AGs as their parent directory, i.e. AGs 0 and 1. Why is this? To understand, it's important to consider the order in which events are occurring. The two bash processes writing files are calling xfs_mkfile, which starts by opening a file with the O_CREAT flag. At this point, XFS has no idea how large the file's data is going to be, so it dutifully creates a new inode for the file in the same AG as the parent directory. The call returns successfully and the system continues with its tasks. When XFS is asked write the file data a short time later, a new AG must be found for it because the AG the inode is in is full. The result is a violation of the original goal to keep file data close to its inode on disk. In practice, because inodes are allocated in clusters on disk, a process that's reading back a stream is likely to cache all the inodes it needs with just one or two reads, so the disk seeking involved won't be as bad as it first seems. On the other hand, the extent data placement seen in the xfs_bmap -v output is a problem. Once the data extents spilled into AG 2, both processes were given allocations there on a first-come-first-served basis. This destroyed the neatly contiguous allocation pattern for the files and will certainly degrade read performance later on. To address this issue, a new allocation algorithm was added to XFS that associates a parent directory with an AG until a preset inactivity timeout elapses. The new algorithm is called the Filestreams allocator and it is enabled in one of two ways. Either the filesystem is mounted with the -o filestreams option, or the filestreams chattr flag is applied to a directory to indicate that all allocations beneath that point in the directory hierarchy should use the filestreams allocator. With the filestreams allocator enabled, the above test produces results that look like this: a/0: 0 96..20575 b/0: 1 131168..151647 a/1: 0 20576..41055 b/1: 1 151648..172127 a/2: 0 41056..61535 b/2: 1 172128..192607 a/3: 0 61536..82015 b/3: 1 192608..213087 a/4: 0 82016..102495 b/4: 1 213088..233567 a/5: 0 102496..122975 b/5: 1 233568..254047 a/6: 2 272456..273479 b/6: 3 393280..410271 a/7: 2 290904..300119 b/7: 3 410272..426655 a/8: 2 300632..321111 b/8: 3 426656..441503 a/9: 2 329304..343639 b/9: 3 441504..459935 Once the process writing files to the first directory starts using AG 2, that AG is no longer considered available so the other process skips it and moves to AG 3. --------------------------------- From owner-xfs@oss.sgi.com Mon Jun 9 19:04:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 19:04:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A24ApF003235 for ; Mon, 9 Jun 2008 19:04:11 -0700 X-ASG-Debug-ID: 1213063503-2bdb03b40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3DCC5C4FDB0 for ; Mon, 9 Jun 2008 19:05:03 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id vD5pLCe2Uom2ku3u for ; Mon, 09 Jun 2008 19:05:03 -0700 (PDT) Received: (qmail 19519 invoked from network); 10 Jun 2008 02:05:01 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Jun 2008 02:05:01 -0000 Message-ID: <484DE36A.2090903@sauce.co.nz> Date: Tue, 10 Jun 2008 14:14:02 +1200 From: Richard Scobie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Shimmin CC: Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams Subject: Re: Filestreams References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> In-Reply-To: <484DDDB3.70000@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1213063505 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52865 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16286 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Timothy Shimmin wrote: > BTW, Sam Vaughan wrote some tutorial notes on the allocator and in particular > filestreams which I've pasted below: Thanks Timothy, much appreciated. Regards, Richard From owner-xfs@oss.sgi.com Mon Jun 9 20:50:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 20:50:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_26 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A3oSBe018960 for ; Mon, 9 Jun 2008 20:50:30 -0700 X-ASG-Debug-ID: 1213069883-174901020000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 70B1D20A6EC for ; Mon, 9 Jun 2008 20:51:23 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id 8SjssLJ1o3WLvZ1w for ; Mon, 09 Jun 2008 20:51:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEhxTUh5LFOM/2dsb2JhbACwMw X-IronPort-AV: E=Sophos;i="4.27,615,1204464600"; d="scan'208";a="130250911" Received: from ppp121-44-83-140.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.83.140]) by ipmail04.adl2.internode.on.net with ESMTP; 10 Jun 2008 13:21:20 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K5utD-0003co-2R; Tue, 10 Jun 2008 13:51:19 +1000 Date: Tue, 10 Jun 2008 13:51:19 +1000 From: Dave Chinner To: Kamil Kisiel Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS and block-level snapshots Subject: Re: XFS and block-level snapshots Message-ID: <20080610035119.GY10720@disturbed> Mail-Followup-To: Kamil Kisiel , xfs@oss.sgi.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1213069884 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4774 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16287 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 06, 2008 at 11:33:17AM -0700, Kamil Kisiel wrote: > Hello, > > I had a question about XFS integrity and performing block-level > snapshots. > > We currently have a 2TB (but growing soon..) volume mounted by a Linux > host with kernel 2.6.23 over iSCSI from our SAN. Our SAN unit has the > capability to perform block-level snapshots, which is done at regular > intervals. > > I know that it is recommended to perform an xfs_freeze before performing > a snapshot. However, the control of the snapshots is independent from the > OS, which currently has no knowledge of their occurrence. I'm curious as > to the repercussions of this. I understand that in all likelyhood, the > integrity of files which are currently being written will not be > preserved. However, even with an xfs_freeze this is not guaranteed, as an > application may require additional disk transactions to maintain the file > in a valid state (it is not necessarily atomic, depending on the > application). That's from an application POV, not a filesystem POV. When you freeze the filesystem all the data and metadata is guaranteed to be consistent on disk. If your application requires further guarantees of atomicity, then it needs to call xfs_freeze at a time that the application can guarantee that it'sstate in the filesystem is consistent. i.e. not a filesystem problem. > As far as metadata transactions are concerned, the journal should > make these atomic, so there should not be any problem there? Sure, asssuming that at the time the snapshot is taken that the sum of the journal contents, the filesystem metadata on disk and the data on disk = a consistent filesystem image. Which, of course, will never happen when you randomly snapshot a busy filesystem as it's a constantly moving target. e.g. say that while the log is being snapshotted by the block device it wraps (i.e. the head moves from the end to the start) and metadata I/O completes so the tail moves forward. now you have a snapshot with the old tail in it and you've lost the transactions at the head of the log. i.e. the journal is no longer consistent with what is on disk in the snapshot. This can happen for data vs metadata, metadata vs metadata and metadata vs log. IOWs, if you don't freeze before you snapshot, your snapshot if full of nasty little inconsistencies just waiting to trip you over.... > Basically, I'd like to know what is the worst that could happen, and why > an xfs_freeze is necessary in this scenario. Worst case? Silent data corruption in the snapshot. Metadata corruption in the snapshot leading to filesystem shutdowns and system panics. Choose your poison - they're all bad. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Mon Jun 9 20:55:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 09 Jun 2008 20:55:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A3t1in019648 for ; Mon, 9 Jun 2008 20:55:05 -0700 X-ASG-Debug-ID: 1213070155-27bc00850000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 42BFA17A497D for ; Mon, 9 Jun 2008 20:55:55 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id aqZtYbTE8GsHSMzd for ; Mon, 09 Jun 2008 20:55:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEhxTUh5LFOM/2dsb2JhbACwMw X-IronPort-AV: E=Sophos;i="4.27,615,1204464600"; d="scan'208";a="130253736" Received: from ppp121-44-83-140.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.83.140]) by ipmail04.adl2.internode.on.net with ESMTP; 10 Jun 2008 13:25:48 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K5uxX-0003ie-Cn; Tue, 10 Jun 2008 13:55:47 +1000 Date: Tue, 10 Jun 2008 13:55:47 +1000 From: Dave Chinner To: dizzy Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: readdir() ordering guarantees on XFS Subject: Re: readdir() ordering guarantees on XFS Message-ID: <20080610035547.GZ10720@disturbed> Mail-Followup-To: dizzy , xfs@oss.sgi.com References: <200806061634.13990.dizzy@roedu.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806061634.13990.dizzy@roedu.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1213070157 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16288 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 06, 2008 at 04:34:13PM +0300, dizzy wrote: > Hello > > POSIX leaves unspecified the order of getting the entries with readdir(). This > is normal since different filesystems may implement their own techniques to > organize entries in a directory (linear, hash, various search trees, etc). > > But if I can makes sure that several Linux machines will have the same FS (ie > XFS), mount options and same kernels can assume that traversing the same file > hierarchy structure (that is a file structure with the exact same directories > and files as names, structure, attributes, except maybe "ctime" which we > can't really control in Linux) can I expect that traversing using readdir() > will give me the entries in the exact same order? No. For speed I suggest sorting the inode stat() calls in ascending inode number order before issuing them. Also, perhaps you should look at: http://oss.oracle.com/~mason/acp/ To see if you can use similar techniques to speed directory traversal. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 10 01:19:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 01:19:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A8JZde021178 for ; Tue, 10 Jun 2008 01:19:37 -0700 X-ASG-Debug-ID: 1213086029-6e7b02d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from noire.bucharest.roedu.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DA91617A50D9 for ; Tue, 10 Jun 2008 01:20:30 -0700 (PDT) Received: from noire.bucharest.roedu.net (noire.Bucharest.roedu.net [141.85.128.18]) by cuda.sgi.com with ESMTP id lpOH5nNvvsteBNn7 for ; Tue, 10 Jun 2008 01:20:30 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (noire.bucharest.roedu.net [141.85.128.18]) (authenticated bits=0) by noire.bucharest.roedu.net (8.12.10/8.12.10) with ESMTP id m5A7KVke027013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2008 10:20:32 +0300 From: dizzy To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: readdir() ordering guarantees on XFS Subject: Re: readdir() ordering guarantees on XFS Date: Tue, 10 Jun 2008 11:20:27 +0300 User-Agent: KMail/1.9.9 References: <200806061634.13990.dizzy@roedu.net> <20080610035547.GZ10720@disturbed> In-Reply-To: <20080610035547.GZ10720@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806101120.27473.dizzy@roedu.net> X-Barracuda-Connect: noire.Bucharest.roedu.net[141.85.128.18] X-Barracuda-Start-Time: 1213086030 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52892 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16289 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: xfs On Tuesday 10 June 2008 06:55:47 Dave Chinner wrote: > On Fri, Jun 06, 2008 at 04:34:13PM +0300, dizzy wrote: > > Hello > > > > POSIX leaves unspecified the order of getting the entries with readdir(). > > This is normal since different filesystems may implement their own > > techniques to organize entries in a directory (linear, hash, various > > search trees, etc). > > > > But if I can makes sure that several Linux machines will have the same FS > > (ie XFS), mount options and same kernels can assume that traversing the > > same file hierarchy structure (that is a file structure with the exact > > same directories and files as names, structure, attributes, except maybe > > "ctime" which we can't really control in Linux) can I expect that > > traversing using readdir() will give me the entries in the exact same > > order? > > No. For speed I suggest sorting the inode stat() calls in ascending > inode number order before issuing them. But this does not solve the main requirement, that is the files traversed on the multiple Linux machines have to be sent in the same order (not sure if I have specified this in the original mesage, sorry if not). For now I'm sorting them lexicographically which is pretty slow. Sorting them by inode would not give them in the same order. > Also, perhaps you should > look at: > > http://oss.oracle.com/~mason/acp/ > > To see if you can use similar techniques to speed directory > traversal. Funny that you mention acp. We have benchmarked simple "tar" reading and "acp" reading of directory structures and on XFS "tar" reading is faster (but not on ext3), here are some results (reading a linux kernel tree after a flush of the cache by "tar"-ing a huge ammount of data, double the memory size): - xfs: acp: 1m32s, tar: 1m12s - ext3: acp: 0m1.5s, tar: 0m2.8s Although in the test ext3 seems to be much faster than XFS overall in reading, it isn't so in writing so we will stick with XFS as it's fast enough for reading and fast for writing. Anyway that is another topic. We still have that ordering issues tho from the original message :) -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST From owner-xfs@oss.sgi.com Tue Jun 10 02:44:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 02:44:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5A9iHxm030278 for ; Tue, 10 Jun 2008 02:44:17 -0700 X-ASG-Debug-ID: 1213091112-5dd701b30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from noire.bucharest.roedu.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3602C67F73 for ; Tue, 10 Jun 2008 02:45:12 -0700 (PDT) Received: from noire.bucharest.roedu.net (noire.Bucharest.roedu.net [141.85.128.18]) by cuda.sgi.com with ESMTP id pWTraRRQU9Z3Xu8w for ; Tue, 10 Jun 2008 02:45:12 -0700 (PDT) Received: from ahriman.bucharest.roedu.net (noire.bucharest.roedu.net [141.85.128.18]) (authenticated bits=0) by noire.bucharest.roedu.net (8.12.10/8.12.10) with ESMTP id m5A8jFke009342 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jun 2008 11:45:15 +0300 From: dizzy To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS directory entries sort order Subject: XFS directory entries sort order Date: Tue, 10 Jun 2008 12:45:09 +0300 User-Agent: KMail/1.9.9 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806101245.09950.dizzy@roedu.net> X-Barracuda-Connect: noire.Bucharest.roedu.net[141.85.128.18] X-Barracuda-Start-Time: 1213091113 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52897 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16290 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dizzy@roedu.net Precedence: bulk X-list: xfs Hello Can someone tell me (in English or C :) ) the algorithm of the sorting order of the entries in an XFS directory as I would get them with a readdir() (or shell "find" command)? I am trying to figure it out by reading linux/fs/xfs/xfs_dir2*.c code but I don't seem to be doing much progress and I was hoping maybe someone that knows these details can help. Thank you! -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST From owner-xfs@oss.sgi.com Tue Jun 10 04:25:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 04:25:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ABPjjd012875 for ; Tue, 10 Jun 2008 04:25:45 -0700 X-ASG-Debug-ID: 1213097200-371f00c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 81846C69100 for ; Tue, 10 Jun 2008 04:26:40 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by cuda.sgi.com with ESMTP id SH34tlRalyuGMQZH for ; Tue, 10 Jun 2008 04:26:40 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so1857399fgb.8 for ; Tue, 10 Jun 2008 04:26:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=c8CT0UDvCgdQe2uE1zFiCwyWqEJCDNeCKY8lOu4dedk=; b=Sfoqidgn/YONSybSWUWg1SoKNo6C/POizQNms8qnZc0EsBtEKlBoTv2GAP+JqUopaf Qz8EyFeHsoacWoc+JB6wr9L1FNGmvmMR+MQ+NgjKvO/zlUlWj58xjocoXldvA8RlivI4 tdMT53Nhloaq09cvatcNtTygFs84wh04kSI1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=UMGvmp/KlEfUwV1VlgBOxUrL01ilX8Y5NvE3KSeAy4kNapA7vS4WZwTA8MEcmLRS3t d7Ugba3dIpA+obD5CEHgybV5Jg2nOo5c75C5F8fX3LRFJJMgMYsnpZES/0b2tB1861aQ UWDtC3WjzcxWVU8PUXj3Yb5GQ9GOLsUyZ9PVI= Received: by 10.86.33.10 with SMTP id g10mr5563673fgg.15.1213097199844; Tue, 10 Jun 2008 04:26:39 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Tue, 10 Jun 2008 04:26:39 -0700 (PDT) Message-ID: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> Date: Tue, 10 Jun 2008 13:26:39 +0200 From: "Oliver Pinter" To: xfs@oss.sgi.com X-ASG-Orig-Subj: [XFS] oss.sgi Subject: [XFS] oss.sgi MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.155] X-Barracuda-Start-Time: 1213097201 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3604 1.0000 -0.1170 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.12 X-Barracuda-Spam-Status: No, SCORE=-0.12 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52903 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16291 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs Hi All! is the http://oss.sgi.com/projects/xfs/ site up to date? -- Thanks, Oliver From owner-xfs@oss.sgi.com Tue Jun 10 04:28:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 04:28:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=AWL,BAYES_05,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ABSKZv013347 for ; Tue, 10 Jun 2008 04:28:20 -0700 X-ASG-Debug-ID: 1213097354-372100d50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.brightcove.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 43BC9C69123 for ; Tue, 10 Jun 2008 04:29:14 -0700 (PDT) Received: from mail.brightcove.com (mail.brightcove.com [38.113.27.188]) by cuda.sgi.com with ESMTP id 0eJF0xAb65aWKsV0 for ; Tue, 10 Jun 2008 04:29:14 -0700 (PDT) Received: from bcmail1.VIDMARK.LOCAL ([172.20.0.82]) by bcmail1.VIDMARK.LOCAL ([172.20.0.82]) with mapi; Tue, 10 Jun 2008 07:28:26 -0400 From: Lance Reed To: "'xfs@oss.sgi.com'" Date: Tue, 10 Jun 2008 07:28:21 -0400 X-ASG-Orig-Subj: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Topic: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Index: AcjK7RZXurwt0fiMRzmZ5Ha/4SFKNw== Message-ID: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Barracuda-Connect: mail.brightcove.com[38.113.27.188] X-Barracuda-Start-Time: 1213097355 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52903 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 2719 X-archive-position: 16292 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lreed@brightcove.com Precedence: bulk X-list: xfs So I am having trouble fixing a corrupted <16 TB file system on a 32bit Linux system: The problem is that xfs_repair dies due to xfs_repair: libxfs_initbuf can't memalign 4096 bytes: Cannot allocate memory: I found the below post, but the links are dead. I tried upping the system RAM to 12 GB, but the problem still exists, which I assume is the per process limit of 1-4 GB. So I am looking for advice on how to fix a large 32bit filesystem. I see options about running on a 64bit host. Can I do this with a newer version of xfs and kernel? We have many hosts that run 64bit Linux (2.6.18-8.1.15.el5 x86_64) and updated xfs progs. Is it possible to mount the existing LVM volumes on a new 64bit host with a newer OS and xfs progs and not risk losing data. Os details for old and possible new host below: Thanks in advance for any possible ideas. Really, THANKS! Lance Basic Os details: (Problem host used to mount XFS filesystem). CentOS release 4.4 (Final) 2.6.9-42.ELsmp i686 i686 i386 GNU/Linux XFS info: xfsprogs-2.8.11-1.c4 xfsdump-2.2.42-1.c4 kernel-module-xfs-2.6.9-42.ELsmp-0.1-3 Possible new host.: CentOS release 5 (Final) 2.6.18-8.1.15.el5 x86_64 xfsprogs-2.9.4-1.el5.centos xfsdump-2.2.46-1.el5.centos kmod-xfs-0.4-1.2.6.18_8.1.15.el5 Previous posts on list: #> I had 2GB RAM and a 300GB swap partition and was monitoring #> memory consumption with "top": it never went over 3BG before #> failing. # #The default 3GiB address space limit per process on a 32 bit #system is rather well documented, for a summary: # # http://WWW.sabi.co.UK/Notes/#060821c # #Let's mention this classic entry again: # # http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00045.html # # <> > Your filesystem (8TiB) may simply bee too large for your # > > system to be able to repair. Try mounting it on a 64bit # > > system with more RAM in it and repairing it from there. # # Now that linux supports larger than 2TiB filesystems on 32 # bit systems, this is true for Linux as well.> # #A previous entry in the same thread might help too: # # http://OSS.SGI.com/archives/linux-xfs/2005-08/msg00037.html # # <> I try xfs_check and xfs_ncheck (and more progs) with # > +200GB swap, but no different! less than 1 second and get # > out of memory. # # Swap won't help if you're running an ia32 (32bit) kernel - # you have a per-process memory limit of 1-4GiB (depending on # kernel and config). The amount of physical memory and swap # does not change this limitation.> # #Trying hard to avoid looking at what is a great time saving strategy! :-) # [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jun 10 05:07:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 05:07:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AC7G2w017195 for ; Tue, 10 Jun 2008 05:07:16 -0700 X-ASG-Debug-ID: 1213099691-616900920000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.brightcove.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0E77FC691D6 for ; Tue, 10 Jun 2008 05:08:11 -0700 (PDT) Received: from mail.brightcove.com (mail.brightcove.com [38.113.27.188]) by cuda.sgi.com with ESMTP id xpIJJCqajwpZdrZF for ; Tue, 10 Jun 2008 05:08:11 -0700 (PDT) Received: from bcmail1.VIDMARK.LOCAL ([172.20.0.82]) by bcmail1.VIDMARK.LOCAL ([172.20.0.82]) with mapi; Tue, 10 Jun 2008 08:07:24 -0400 From: Lance Reed To: Tru Huynh CC: "'xfs@oss.sgi.com'" Date: Tue, 10 Jun 2008 08:07:18 -0400 X-ASG-Orig-Subj: RE: Probems with xfs_repair on large filesystem and 32bit OS. Subject: RE: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Topic: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Index: AcjK8BpEbyrQwFoVQUScuQkoxlP36QAAdlbQ Message-ID: <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> References: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> <20080610115038.GD3005@sillage.bis.pasteur.fr> In-Reply-To: <20080610115038.GD3005@sillage.bis.pasteur.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Barracuda-Connect: mail.brightcove.com[38.113.27.188] X-Barracuda-Start-Time: 1213099692 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0004 1.0000 -2.0181 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52907 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m5AC7G2w017197 X-archive-position: 16293 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lreed@brightcove.com Precedence: bulk X-list: xfs SO, I take it from what you say that that I can running any newer version of xfs progs and a 64bit host (fiber attached, easy to do this), and run xfs_repair on the 32bit XFS volumes without fear of data corruption? Is this because XFS is not version specific, and xfs_repair will honor the 32bit file data structures? Again thanks so much for your response! Lance -----Original Message----- From: Tru Huynh [mailto:tru@pasteur.fr] Sent: Tuesday, June 10, 2008 7:51 AM To: Lance Reed Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. On Tue, Jun 10, 2008 at 07:28:21AM -0400, Lance Reed wrote: > So I am having trouble fixing a corrupted <16 TB file system on a 32bit Linux > system: > > > The problem is that xfs_repair dies due to xfs_repair: libxfs_initbuf can't > memalign 4096 bytes: Cannot allocate memory: > > I found the below post, but the links are dead. > > I tried upping the system RAM to 12 GB, but the problem still exists, which I > assume is the per process limit of 1-4 GB. you are on a 32 bits OS, so I would say are hitting a hard limit per process. > > So I am looking for advice on how to fix a large 32bit filesystem. I see > options about running on a 64bit host. Can I do this with a newer version of > xfs and kernel? We have many hosts that run 64bit Linux (2.6.18-8.1.15.el5 > x86_64) and updated xfs progs. Is it possible to mount the existing LVM > volumes on a new 64bit host with a newer OS and xfs progs and not risk losing > data. Os details for old and possible new host below: > My 0.2 cents. - you can install a x86_64 CentOS-4 machine and fix it from there or - you can install a x86_64 CentOS-5 machine and fix it from there or - upgrade to the **development** versions for CentOS-4 i386 at https://projects.centos.org/trac/xfs/ http://people.centos.org/tru/XFS/centos-4/RPMS/i386/xfsprogs-2.9.8-2.c4.i686.rpm http://people.centos.org/tru/XFS/centos-4/RPMS/i386/xfsdump-2.2.48-1.c4.i686.rpm and the right kmod-xfs http://people.centos.org/tru/XFS/centos-4/RPMS/i386/ > CentOS release 4.4 (Final) you should be running 4.6 > 2.6.9-42.ELsmp i686 i686 i386 GNU/Linux and 2.6.9-67.0.7.ELsmp... > > Possible new host.: > > CentOS release 5 (Final) > 2.6.18-8.1.15.el5 x86_64 2.6.18-53.1.21.el5 > xfsprogs-2.9.4-1.el5.centos > xfsdump-2.2.46-1.el5.centos or http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/xfsprogs-2.9.8-1.c5.x86_64.rpm http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/xfsdump-2.2.48-1.c5.x86_64.rpm > kmod-xfs-0.4-1.2.6.18_8.1.15.el5 or http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/kmod-xfs-0.4-2.2.6.18_53.1.21.el5.x86_64.rpm Cheers, Tru -- Dr Tru Huynh | http://www.pasteur.fr/recherche/unites/Binfs/ mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France From owner-xfs@oss.sgi.com Tue Jun 10 05:23:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 05:23:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ACNQ1d019409 for ; Tue, 10 Jun 2008 05:23:27 -0700 X-ASG-Debug-ID: 1213100660-5229004e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AF87020C68C for ; Tue, 10 Jun 2008 05:24:20 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id aE7zdBXRwknMMGGR for ; Tue, 10 Jun 2008 05:24:20 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K62tg-0006UW-FJ; Tue, 10 Jun 2008 12:24:20 +0000 Date: Tue, 10 Jun 2008 08:24:20 -0400 From: Christoph Hellwig To: Oliver Pinter Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [XFS] oss.sgi Subject: Re: [XFS] oss.sgi Message-ID: <20080610122420.GA15871@infradead.org> References: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213100662 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52907 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16294 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 10, 2008 at 01:26:39PM +0200, Oliver Pinter wrote: > Hi All! > > is the http://oss.sgi.com/projects/xfs/ site up to date? More or less. It could have a few more recent news items or reference to presentations from the last few month, but I can't find anything grossly out of date. From owner-xfs@oss.sgi.com Tue Jun 10 05:27:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 05:27:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ACRHUo020022 for ; Tue, 10 Jun 2008 05:27:17 -0700 X-ASG-Debug-ID: 1213100892-617c00ed0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 40AA612C28E6 for ; Tue, 10 Jun 2008 05:28:13 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id c7ekYpbaXtIzM2BS for ; Tue, 10 Jun 2008 05:28:13 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K62xP-0005E2-8z; Tue, 10 Jun 2008 12:28:11 +0000 Date: Tue, 10 Jun 2008 08:28:11 -0400 From: Christoph Hellwig To: Lance Reed Cc: Tru Huynh , "'xfs@oss.sgi.com'" X-ASG-Orig-Subj: Re: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. Message-ID: <20080610122811.GB15871@infradead.org> References: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> <20080610115038.GD3005@sillage.bis.pasteur.fr> <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213100893 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52907 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16295 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 10, 2008 at 08:07:18AM -0400, Lance Reed wrote: > SO, I take it from what you say that that I can running any newer version of xfs progs and a 64bit host (fiber attached, easy to do this), and run xfs_repair on the 32bit XFS volumes without fear of data corruption? > Is this because XFS is not version specific, and xfs_repair will honor the 32bit file data structures? Yes, this is fine. All the actual filesystem structures are endian and 32/64bit clean. The log needs to be in the same endianess and had 32bit vs 64bit problems on x86 for a while, but it needs to be recovered before you run xfs_repair anyway. From owner-xfs@oss.sgi.com Tue Jun 10 05:50:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 05:50:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ACoMEF022342 for ; Tue, 10 Jun 2008 05:50:23 -0700 X-ASG-Debug-ID: 1213102278-35a3016f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.brightcove.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1BA0020C8CF for ; Tue, 10 Jun 2008 05:51:18 -0700 (PDT) Received: from mail.brightcove.com (mail.brightcove.com [38.113.27.188]) by cuda.sgi.com with ESMTP id 2iWsyY3SnOafLbtb for ; Tue, 10 Jun 2008 05:51:18 -0700 (PDT) Received: from bcmail1.VIDMARK.LOCAL ([172.20.0.82]) by bcmail1.VIDMARK.LOCAL ([172.20.0.82]) with mapi; Tue, 10 Jun 2008 08:50:31 -0400 From: Lance Reed To: "'hch@infradead.org'" CC: "'xfs@oss.sgi.com'" Date: Tue, 10 Jun 2008 08:50:30 -0400 X-ASG-Orig-Subj: Re: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Topic: Probems with xfs_repair on large filesystem and 32bit OS. Thread-Index: AcjK9Vdp/jYCbGDUQgm9f8hNJxZjSQAAzizr Message-ID: <6A32BC807C106440B7E23208F280DDAF01D3FC9317@bcmail1.VIDMARK.LOCAL> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 X-Barracuda-Connect: mail.brightcove.com[38.113.27.188] X-Barracuda-Start-Time: 1213102279 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52910 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id m5ACoNEF022344 X-archive-position: 16296 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lreed@brightcove.com Precedence: bulk X-list: xfs Thanks! Yes the log died and was zeroed already with xfs_repair already. So I plan to put a 64bit head on the volumes and leave it that way. I asuume I need to still keep it under 16 tb since the fs datastuctures are 32bit? Thanks again for the help!!! ----- Original Message ----- From: Christoph Hellwig To: Lance Reed Cc: Tru Huynh ; 'xfs@oss.sgi.com' Sent: Tue Jun 10 08:28:11 2008 Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. On Tue, Jun 10, 2008 at 08:07:18AM -0400, Lance Reed wrote: > SO, I take it from what you say that that I can running any newer version of xfs progs and a 64bit host (fiber attached, easy to do this), and run xfs_repair on the 32bit XFS volumes without fear of data corruption? > Is this because XFS is not version specific, and xfs_repair will honor the 32bit file data structures? Yes, this is fine. All the actual filesystem structures are endian and 32/64bit clean. The log needs to be in the same endianess and had 32bit vs 64bit problems on x86 for a while, but it needs to be recovered before you run xfs_repair anyway. From owner-xfs@oss.sgi.com Tue Jun 10 06:00:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 06:00:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AD0pqZ023458 for ; Tue, 10 Jun 2008 06:00:51 -0700 X-ASG-Debug-ID: 1213102907-371f02cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AFB4912C2C81 for ; Tue, 10 Jun 2008 06:01:47 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id qmZgat7lH9VnDIv7 for ; Tue, 10 Jun 2008 06:01:47 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K63Tu-0007Og-VH; Tue, 10 Jun 2008 13:01:46 +0000 Date: Tue, 10 Jun 2008 09:01:46 -0400 From: "'hch@infradead.org'" To: Lance Reed Cc: "'hch@infradead.org'" , "'xfs@oss.sgi.com'" X-ASG-Orig-Subj: Re: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. Message-ID: <20080610130146.GA21510@infradead.org> References: <6A32BC807C106440B7E23208F280DDAF01D3FC9317@bcmail1.VIDMARK.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A32BC807C106440B7E23208F280DDAF01D3FC9317@bcmail1.VIDMARK.LOCAL> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213102907 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52909 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16297 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jun 10, 2008 at 08:50:30AM -0400, Lance Reed wrote: > Thanks! > > Yes the log died and was zeroed already with xfs_repair already. > > So I plan to put a 64bit head on the volumes and leave it that way. > > I asuume I need to still keep it under 16 tb since the fs datastuctures are 32bit? > All XFS data structures (which matter for this) are 64bit. But the pagecache size in 32bit x86 systems is indeeed limited, so a larger filesystem won't work there. From owner-xfs@oss.sgi.com Tue Jun 10 07:06:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 07:06:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AE6WPx029541 for ; Tue, 10 Jun 2008 07:06:32 -0700 X-ASG-Debug-ID: 1213106846-0c34037c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 828BD17A6D9C for ; Tue, 10 Jun 2008 07:07:26 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.125]) by cuda.sgi.com with ESMTP id ZdQtKGEJarxIcn5B for ; Tue, 10 Jun 2008 07:07:26 -0700 (PDT) Received: from tomslinux.homelinux.org ([24.28.24.180]) by hrndva-omta02.mail.rr.com with ESMTP id <20080610140725.ODII25858.hrndva-omta02.mail.rr.com@tomslinux.homelinux.org> for ; Tue, 10 Jun 2008 14:07:25 +0000 Received: from tomslinux.homelinux.org (localhost [127.0.0.1]) by tomslinux.homelinux.org (8.13.7/8.13.7) with ESMTP id m5AE7Gqa007632 for ; Tue, 10 Jun 2008 09:07:16 -0500 Received: (from apache@localhost) by tomslinux.homelinux.org (8.13.7/8.13.7/Submit) id m5AE7FVc007631; Tue, 10 Jun 2008 09:07:15 -0500 From: Thomas King X-Authentication-Warning: tomslinux.homelinux.org: apache set sender to kingttx@tomslinux.homelinux.org using -f Received: from 143.166.226.41 (SquirrelMail authenticated user kingttx) by tomslinux.homelinux.org with HTTP; Tue, 10 Jun 2008 09:07:15 -0500 (CDT) Message-ID: <9856.143.166.226.41.1213106835.squirrel@tomslinux.homelinux.org> Date: Tue, 10 Jun 2008 09:07:15 -0500 (CDT) X-ASG-Orig-Subj: Filesystem article up, thank you all! Subject: Filesystem article up, thank you all! To: xfs@oss.sgi.com User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.125] X-Barracuda-Start-Time: 1213106847 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0029 1.0000 -2.0020 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52906 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16298 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kingttx@tomslinux.homelinux.org Precedence: bulk X-list: xfs Folks, My article answering Henry Newman is up. If you wish to clarify or correct anything in the article, please do so in the comments. http://lxer.com/module/newswire/view/103802/index.html Thanks! Tom King ------- "Concern for man and his fate must always form the chief interest of all technical endeavors. Never forget this in the midst of your diagrams and equations." --Albert Einstein From owner-xfs@oss.sgi.com Tue Jun 10 10:06:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 10:06:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AH6Xbf016506 for ; Tue, 10 Jun 2008 10:06:33 -0700 X-ASG-Debug-ID: 1213117648-782a01ac0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out03.alice-dsl.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 457CA17A805C for ; Tue, 10 Jun 2008 10:07:28 -0700 (PDT) Received: from smtp-out03.alice-dsl.net (smtp-out03.alice-dsl.net [88.44.63.5]) by cuda.sgi.com with ESMTP id 6E01QiUtE2J8cFHM for ; Tue, 10 Jun 2008 10:07:28 -0700 (PDT) Received: from out.alice-dsl.de ([192.168.125.59]) by smtp-out03.alice-dsl.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 19:00:15 +0200 Received: from basil.firstfloor.org ([92.224.155.196]) by out.alice-dsl.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 19:00:15 +0200 Received: by basil.firstfloor.org (Postfix, from userid 1000) id ACC851B4212; Tue, 10 Jun 2008 19:07:26 +0200 (CEST) To: Christoph Hellwig Cc: Lance Reed , Tru Huynh , "'xfs@oss.sgi.com'" X-ASG-Orig-Subj: Re: Probems with xfs_repair on large filesystem and 32bit OS. Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. From: Andi Kleen References: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> <20080610115038.GD3005@sillage.bis.pasteur.fr> <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> <20080610122811.GB15871@infradead.org> Date: Tue, 10 Jun 2008 19:07:26 +0200 In-Reply-To: <20080610122811.GB15871@infradead.org> (Christoph Hellwig's message of "Tue, 10 Jun 2008 08:28:11 -0400") Message-ID: <87tzg1p6b5.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 10 Jun 2008 17:00:15.0939 (UTC) FILETIME=[74838130:01C8CB1B] X-Barracuda-Connect: smtp-out03.alice-dsl.net[88.44.63.5] X-Barracuda-Start-Time: 1213117649 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52926 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16299 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs Christoph Hellwig writes: > On Tue, Jun 10, 2008 at 08:07:18AM -0400, Lance Reed wrote: >> SO, I take it from what you say that that I can running any newer version of xfs progs and a 64bit host (fiber attached, easy to do this), and run xfs_repair on the 32bit XFS volumes without fear of data corruption? >> Is this because XFS is not version specific, and xfs_repair will honor the 32bit file data structures? > > Yes, this is fine. All the actual filesystem structures are endian and > 32/64bit clean. The log needs to be in the same endianess and had 32bit > vs 64bit problems on x86 for a while, but it needs to be recovered > before you run xfs_repair anyway. Actually there used to be some bugs in old versions where 32bit couldn't replay 64bit logs or vice versa. Probably all fixed in uptodate kernels. -Andi From owner-xfs@oss.sgi.com Tue Jun 10 10:19:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 10:19:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AHJ6Vg018375 for ; Tue, 10 Jun 2008 10:19:06 -0700 X-ASG-Debug-ID: 1213118401-676e02c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out04.alice-dsl.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B1E1120F15D for ; Tue, 10 Jun 2008 10:20:01 -0700 (PDT) Received: from smtp-out04.alice-dsl.net (smtp-out04.alice-dsl.net [88.44.63.6]) by cuda.sgi.com with ESMTP id 64lEEdH9NjCVy1Tq for ; Tue, 10 Jun 2008 10:20:01 -0700 (PDT) Received: from out.alice-dsl.de ([192.168.125.59]) by smtp-out04.alice-dsl.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 19:12:49 +0200 Received: from basil.firstfloor.org ([92.224.155.196]) by out.alice-dsl.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 19:12:49 +0200 Received: by basil.firstfloor.org (Postfix, from userid 1000) id 114471B4212; Tue, 10 Jun 2008 19:20:00 +0200 (CEST) To: dizzy Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS directory entries sort order Subject: Re: XFS directory entries sort order From: Andi Kleen References: <200806101245.09950.dizzy@roedu.net> Date: Tue, 10 Jun 2008 19:20:00 +0200 In-Reply-To: <200806101245.09950.dizzy@roedu.net> (dizzy@roedu.net's message of "Tue, 10 Jun 2008 12:45:09 +0300") Message-ID: <87prqpp5q7.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 10 Jun 2008 17:12:49.0141 (UTC) FILETIME=[35750250:01C8CB1D] X-Barracuda-Connect: smtp-out04.alice-dsl.net[88.44.63.6] X-Barracuda-Start-Time: 1213118402 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52928 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16300 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs dizzy writes: > Can someone tell me (in English or C :) ) the algorithm of the sorting order > of the entries in an XFS directory as I would get them with a readdir() (or > shell "find" command)? > > I am trying to figure it out by reading linux/fs/xfs/xfs_dir2*.c code but I > don't seem to be doing much progress and I was hoping maybe someone that > knows these details can help. I believe it computes a hash over the name and then sorts by the hash numerical value. At least the b*tree large directories do, small inline directories might be different (XFS uses different algorithms for different directory sizes) The hash function is in xfs_da_btree.c:xfs_da_hashname() With the recent case insensitive support there are also differences on the file systems which have that enabled. Also better don't rely on it never changing. -Andi From owner-xfs@oss.sgi.com Tue Jun 10 14:50:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 14:50:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ALo9CR015415 for ; Tue, 10 Jun 2008 14:50:09 -0700 X-ASG-Debug-ID: 1213134663-107e02a80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 51D2117A9D07 for ; Tue, 10 Jun 2008 14:51:04 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by cuda.sgi.com with ESMTP id 2ZQJ2RjM4iULdLJO for ; Tue, 10 Jun 2008 14:51:04 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so2023873fgb.8 for ; Tue, 10 Jun 2008 14:51:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=MEc7igpX47EZI1Zx5rvYsSq+dUJOPfZslPLmO9bPEIk=; b=A3SMENUshAlebLMjEXx0kykbU/2GIbwZWxrdIGw8NtAq/8kQAVbRVv7/TBdj3jpl0f 6P2jukjRqXvuZ0/0VWBCOZpVT89Bdi+Aw65RyUyj8VlCdwkDtdC4YTrdXnonwBP6sltJ +9NIa+ysVRdOayKo8SVojneYn1S/AN+eK9xGE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=aBsD4f6YQH77/lAU73eXPvzyzP3hD/ctlu6eu+P0Hd86I4iPywG0gA/JFo+VDZyP5F eLEP/A15Bj62EOMb9mUfRu4JlxSXyXs7fWHguCsENPzCtuhUhTAZn6tEam13blRtO+39 wn5dfSmyTrHfJhVTqmjo2Ahx8fKEnhsvAuf6I= Received: by 10.86.80.5 with SMTP id d5mr6334369fgb.19.1213134663461; Tue, 10 Jun 2008 14:51:03 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Tue, 10 Jun 2008 14:51:03 -0700 (PDT) Message-ID: <6101e8c40806101451tb160ed8rc0ba2739cafee84f@mail.gmail.com> Date: Tue, 10 Jun 2008 23:51:03 +0200 From: "Oliver Pinter" To: "Christoph Hellwig" X-ASG-Orig-Subj: Re: [XFS] oss.sgi Subject: Re: [XFS] oss.sgi Cc: xfs@oss.sgi.com In-Reply-To: <20080610122420.GA15871@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> <20080610122420.GA15871@infradead.org> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.154] X-Barracuda-Start-Time: 1213134665 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0031 1.0000 -2.0009 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52946 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16301 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs hi! thanks the info On 6/10/08, Christoph Hellwig wrote: > On Tue, Jun 10, 2008 at 01:26:39PM +0200, Oliver Pinter wrote: >> Hi All! >> >> is the http://oss.sgi.com/projects/xfs/ site up to date? > > More or less. It could have a few more recent news items or reference > to presentations from the last few month, but I can't find anything > grossly out of date. > > -- Thanks, Oliver From owner-xfs@oss.sgi.com Tue Jun 10 15:24:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 15:24:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,J_CHICKENPOX_33, J_CHICKENPOX_45,J_CHICKENPOX_48,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AMOqTp019254 for ; Tue, 10 Jun 2008 15:24:53 -0700 X-ASG-Debug-ID: 1213136747-107403640000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ueb.org.br (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 02F9F17AA1DE for ; Tue, 10 Jun 2008 15:25:47 -0700 (PDT) Received: from ueb.org.br (ns1.ueb.org.br [200.165.164.250]) by cuda.sgi.com with ESMTP id eELH4rCOMCs00JgE for ; Tue, 10 Jun 2008 15:25:47 -0700 (PDT) Received: from ueb.org.br (localhost.server.ueb.org.br [127.0.0.1]) by ueb.org.br (8.14.0/8.14.0) with ESMTP id m5AMQY8x048307 for ; Tue, 10 Jun 2008 19:26:35 -0300 (BRT) Received: (from www@localhost) by ueb.org.br (8.14.0/8.14.0/Submit) id m5AMQY0k048305; Tue, 10 Jun 2008 19:26:34 -0300 (BRT) Date: Tue, 10 Jun 2008 19:26:34 -0300 (BRT) Message-Id: <200806102226.m5AMQY0k048305@ueb.org.br> To: xfs@oss.sgi.com X-ASG-Orig-Subj: PROPERTIES. Subject: PROPERTIES. From: Samuel Juna Reply-To: as568agl@yahoo.com.hk MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ueb.org.br [0.0.0.0]); Tue, 10 Jun 2008 19:26:35 -0300 (BRT) X-Barracuda-Connect: ns1.ueb.org.br[200.165.164.250] X-Barracuda-Start-Time: 1213136749 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6699 1.0000 1.1518 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.15 X-Barracuda-Spam-Status: No, SCORE=1.15 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52948 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16302 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: as568agl@yahoo.com.hk Precedence: bulk X-list: xfs Good Day, I wish to introduce myself to you.I am Samuel Juna a top Sudanese Goverment official who opposed the war in Dafur in my country Sudan.Due to my oppostion to the war,the goverment of my country has been persecuting me.Consequently my wife,children and I managed to enter a red cross airplane that was evacuating foreigners and we are presently in Cape Town,South Africa. We wish to invest in properties in your country with your assistance and cooperation.If you are in a good position to help my family, please send an e-mail to the e-mail address below indicating your desire to help my family invest this funds in your country. best regards, Hope to meet you soon. God bless, Samuel Juna Email:as568agl@yahoo.com.hk From owner-xfs@oss.sgi.com Tue Jun 10 15:51:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 15:51:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AMpA5g021415 for ; Tue, 10 Jun 2008 15:51:10 -0700 X-ASG-Debug-ID: 1213138326-081b01290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B9D33212879 for ; Tue, 10 Jun 2008 15:52:06 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 31KbFTaNyyE09Aua for ; Tue, 10 Jun 2008 15:52:06 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A5B27A9BF4F; Tue, 10 Jun 2008 17:52:04 -0500 (CDT) Message-ID: <484F0594.1010406@sandeen.net> Date: Tue, 10 Jun 2008 17:52:04 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [XFS] oss.sgi Subject: Re: [XFS] oss.sgi References: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> <20080610122420.GA15871@infradead.org> <6101e8c40806101451tb160ed8rc0ba2739cafee84f@mail.gmail.com> In-Reply-To: <6101e8c40806101451tb160ed8rc0ba2739cafee84f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213138326 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52950 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16303 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > hi! > > thanks the info > > On 6/10/08, Christoph Hellwig wrote: >> On Tue, Jun 10, 2008 at 01:26:39PM +0200, Oliver Pinter wrote: >>> Hi All! >>> >>> is the http://oss.sgi.com/projects/xfs/ site up to date? >> More or less. It could have a few more recent news items or reference >> to presentations from the last few month, but I can't find anything >> grossly out of date. Is there any info in particular that you wondered about? :) -Eric From owner-xfs@oss.sgi.com Tue Jun 10 15:59:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 15:59:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5AMx9kF022396 for ; Tue, 10 Jun 2008 15:59:10 -0700 X-ASG-Debug-ID: 1213138803-18c8004d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E4FFEC7154D for ; Tue, 10 Jun 2008 16:00:03 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id lorknRtkVkyDQh5h for ; Tue, 10 Jun 2008 16:00:03 -0700 (PDT) Received: (qmail 26322 invoked from network); 10 Jun 2008 23:00:02 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 10 Jun 2008 23:00:02 -0000 Message-ID: <484F0998.90306@sauce.co.nz> Date: Wed, 11 Jun 2008 11:09:12 +1200 From: Richard Scobie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Shimmin CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> In-Reply-To: <484DDDB3.70000@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1213138805 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3269 1.0000 -0.2385 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.24 X-Barracuda-Spam-Status: No, SCORE=-0.24 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52947 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16304 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Timothy Shimmin wrote: > BTW, Sam Vaughan wrote some tutorial notes on the allocator and in particular > filestreams which I've pasted below: > (I thought it might be here: > http://oss.sgi.com/projects/xfs/training/ but I can't see it > in the allocator lab and slides). I did actually find an entry for filestreams in slide 6. While there I also found the information on 64bit inodes. My filesystem is 9.6TB and could well end up with a large quantity of 1-15MB files stored and the statement: "Operating system interfaces and legacy software products often mandate the use of 32 bit inode numbers even on systems that support 64 bit inode numbers." makes me wonder how common this still is in practice - the slide was written in 2006)? My initial preference would be to go with 64 bit inodes for performance reasons, but as one cannot revert the fs back to 32 bit inodes once committed, I am somewhat hesitant. Or am I worrying unecessarily about the negative impact of 32 bit inodes, given 9.6TB full of 1 to 15MB files? Regards, Richard From owner-xfs@oss.sgi.com Tue Jun 10 16:52:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 16:52:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_14 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5ANqSA2031776 for ; Tue, 10 Jun 2008 16:52:29 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id JAA07971; Wed, 11 Jun 2008 09:53:14 +1000 Date: Wed, 11 Jun 2008 09:53:40 +1000 To: "Andi Kleen" , dizzy Subject: Re: XFS directory entries sort order From: "Barry Naujok" Organization: SGI Cc: xfs@oss.sgi.com Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200806101245.09950.dizzy@roedu.net> <87prqpp5q7.fsf@basil.nowhere.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <87prqpp5q7.fsf@basil.nowhere.org> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16305 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 11 Jun 2008 03:20:00 +1000, Andi Kleen wrote: > dizzy writes: > >> Can someone tell me (in English or C :) ) the algorithm of the sorting >> order >> of the entries in an XFS directory as I would get them with a readdir() >> (or >> shell "find" command)? >> >> I am trying to figure it out by reading linux/fs/xfs/xfs_dir2*.c code >> but I >> don't seem to be doing much progress and I was hoping maybe someone that >> knows these details can help. > > I believe it computes a hash over the name and then sorts by the hash > numerical value. At least the b*tree large directories do, small inline > directories might be different (XFS uses different algorithms for > different directory sizes) readdir order is not dependant on the hashes. The order depends on the order of files being created, unlinked and the length of the filenames being unlinked/created. > The hash function is in xfs_da_btree.c:xfs_da_hashname() > > With the recent case insensitive support there are also differences > on the file systems which have that enabled. > > Also better don't rely on it never changing. Yes :) Barry. From owner-xfs@oss.sgi.com Tue Jun 10 16:58:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 16:58:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ANw4tK032557 for ; Tue, 10 Jun 2008 16:58:05 -0700 X-ASG-Debug-ID: 1213142340-6be102a30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from one.firstfloor.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC46A17AA72A for ; Tue, 10 Jun 2008 16:59:00 -0700 (PDT) Received: from one.firstfloor.org (one.firstfloor.org [213.235.205.2]) by cuda.sgi.com with ESMTP id 2mmiEkuIBPW3O0QC for ; Tue, 10 Jun 2008 16:59:00 -0700 (PDT) Received: from [92.224.154.155] (g224154155.adsl.alicedsl.de [92.224.154.155]) by one.firstfloor.org (Postfix) with ESMTP id CF8E618900BD; Wed, 11 Jun 2008 02:09:01 +0200 (CEST) Message-ID: <484F1541.7010203@firstfloor.org> Date: Wed, 11 Jun 2008 01:58:57 +0200 From: Andi Kleen User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Barry Naujok CC: dizzy , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS directory entries sort order Subject: Re: XFS directory entries sort order References: <200806101245.09950.dizzy@roedu.net> <87prqpp5q7.fsf@basil.nowhere.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: one.firstfloor.org[213.235.205.2] X-Barracuda-Start-Time: 1213142340 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0002 1.0000 -2.0199 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52954 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16306 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: andi@firstfloor.org Precedence: bulk X-list: xfs > readdir order is not dependant on the hashes. The order depends on the > order of files being created, unlinked and the length of the filenames > being unlinked/created. Thanks for the correction. It's a long time that I read that source so it probably got confused with some other fs. -Andi From owner-xfs@oss.sgi.com Tue Jun 10 17:00:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 17:00:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5B003Fn000620 for ; Tue, 10 Jun 2008 17:00:05 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08232; Wed, 11 Jun 2008 10:00:40 +1000 Date: Wed, 11 Jun 2008 10:01:08 +1000 To: "Lance Reed" , "Tru Huynh" Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. From: "Barry Naujok" Organization: SGI Cc: "'xfs@oss.sgi.com'" Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <6A32BC807C106440B7E23208F280DDAF01D3F6C8A8@bcmail1.VIDMARK.LOCAL> <20080610115038.GD3005@sillage.bis.pasteur.fr> <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <6A32BC807C106440B7E23208F280DDAF01D3F6C8B4@bcmail1.VIDMARK.LOCAL> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16307 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Tue, 10 Jun 2008 22:07:18 +1000, Lance Reed wrote: > SO, I take it from what you say that that I can running any newer > version of xfs progs and a 64bit host (fiber attached, easy to do this), > and run xfs_repair on the 32bit XFS volumes without fear of data > corruption? > Is this because XFS is not version specific, and xfs_repair will honor > the 32bit file data structures? > > Again thanks so much for your response! As Christoph said, you can run 64-bit kernel/xfsprogs on a filesystem used in a 32-bit kernel without problems. You'll also find that xfsprogs 2.9.4 and later is more memory optimised than the 2.8.x series. It may even work on your filesystem in 32-bit mode. I can't guarantee that though as you never actually specified the size of your filesystem and how many inodes are on it. I can repair a 9TB filesystem on a 2GB machine without using swap. > Lance > -----Original Message----- > From: Tru Huynh [mailto:tru@pasteur.fr] > Sent: Tuesday, June 10, 2008 7:51 AM > To: Lance Reed > Subject: Re: Probems with xfs_repair on large filesystem and 32bit OS. > > On Tue, Jun 10, 2008 at 07:28:21AM -0400, Lance Reed wrote: >> So I am having trouble fixing a corrupted <16 TB file system on a 32bit >> Linux >> system: >> >> >> The problem is that xfs_repair dies due to xfs_repair: libxfs_initbuf >> can't >> memalign 4096 bytes: Cannot allocate memory: >> >> I found the below post, but the links are dead. >> >> I tried upping the system RAM to 12 GB, but the problem still exists, >> which I >> assume is the per process limit of 1-4 GB. > you are on a 32 bits OS, so I would say are hitting a hard limit per > process. >> >> So I am looking for advice on how to fix a large 32bit filesystem. I >> see >> options about running on a 64bit host. Can I do this with a newer >> version of >> xfs and kernel? We have many hosts that run 64bit Linux >> (2.6.18-8.1.15.el5 >> x86_64) and updated xfs progs. Is it possible to mount the existing LVM >> volumes on a new 64bit host with a newer OS and xfs progs and not risk >> losing >> data. Os details for old and possible new host below: >> > My 0.2 cents. > - you can install a x86_64 CentOS-4 machine and fix it from there > or > - you can install a x86_64 CentOS-5 machine and fix it from there > or > - upgrade to the **development** versions for CentOS-4 i386 at > https://projects.centos.org/trac/xfs/ > > http://people.centos.org/tru/XFS/centos-4/RPMS/i386/xfsprogs-2.9.8-2.c4.i686.rpm > http://people.centos.org/tru/XFS/centos-4/RPMS/i386/xfsdump-2.2.48-1.c4.i686.rpm > and the right kmod-xfs > http://people.centos.org/tru/XFS/centos-4/RPMS/i386/ > >> CentOS release 4.4 (Final) > you should be running 4.6 >> 2.6.9-42.ELsmp i686 i686 i386 GNU/Linux > and 2.6.9-67.0.7.ELsmp... >> >> Possible new host.: >> >> CentOS release 5 (Final) >> 2.6.18-8.1.15.el5 x86_64 > 2.6.18-53.1.21.el5 > >> xfsprogs-2.9.4-1.el5.centos >> xfsdump-2.2.46-1.el5.centos > or > http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/xfsprogs-2.9.8-1.c5.x86_64.rpm > http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/xfsdump-2.2.48-1.c5.x86_64.rpm > >> kmod-xfs-0.4-1.2.6.18_8.1.15.el5 > or > http://people.centos.org/tru/XFS/centos-5/RPMS/x86_64/kmod-xfs-0.4-2.2.6.18_53.1.21.el5.x86_64.rpm > > Cheers, > > Tru > -- > Dr Tru Huynh | http://www.pasteur.fr/recherche/unites/Binfs/ > mailto:tru@pasteur.fr | tel/fax +33 1 45 68 87 37/19 > Institut Pasteur, 25-28 rue du Docteur Roux, 75724 Paris CEDEX 15 France > > From owner-xfs@oss.sgi.com Tue Jun 10 17:04:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 17:04:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5B044UC001254 for ; Tue, 10 Jun 2008 17:04:05 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08287; Wed, 11 Jun 2008 10:04:27 +1000 Date: Wed, 11 Jun 2008 10:04:56 +1000 To: "Andi Kleen" Subject: Re: XFS directory entries sort order From: "Barry Naujok" Organization: SGI Cc: dizzy , xfs@oss.sgi.com Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <200806101245.09950.dizzy@roedu.net> <87prqpp5q7.fsf@basil.nowhere.org> <484F1541.7010203@firstfloor.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <484F1541.7010203@firstfloor.org> User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16308 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Wed, 11 Jun 2008 09:58:57 +1000, Andi Kleen wrote: > >> readdir order is not dependant on the hashes. The order depends on the >> order of files being created, unlinked and the length of the filenames >> being unlinked/created. > > Thanks for the correction. It's a long time that I read that source > so it probably got confused with some other fs. If I read the code correctly, in node-form directories, it will try and use the same data block that other names with the same hash are located in. Barry. From owner-xfs@oss.sgi.com Tue Jun 10 17:38:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 17:38:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5B0csfV004922 for ; Tue, 10 Jun 2008 17:38:54 -0700 X-ASG-Debug-ID: 1213144788-1401035e0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bnc02.aitai.ne.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 2A108213103 for ; Tue, 10 Jun 2008 17:39:49 -0700 (PDT) Received: from bnc02.aitai.ne.jp (bnc02.aitai.ne.jp [211.1.192.125]) by cuda.sgi.com with SMTP id uRnF473y4u0kxadX for ; Tue, 10 Jun 2008 17:39:49 -0700 (PDT) Received: (qmail 642 invoked from network); 11 Jun 2008 09:39:48 +0900 Received: from unknown (HELO mira1.aitai.ne.jp) (211.1.194.32) by bnc02.aitai.ne.jp with SMTP; 11 Jun 2008 09:39:48 +0900 Received: from localhost (localhost) by mira1.aitai.ne.jp (MOS 3.8.4-GA) with internal id DKV43907; Wed, 11 Jun 2008 09:39:48 +0900 (JST) Date: Wed, 11 Jun 2008 09:39:48 +0900 (JST) From: Mail Delivery Subsystem Message-Id: <200806110039.DKV43907@mira1.aitai.ne.jp> To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="DKV43907.1213144788/mira1.aitai.ne.jp" X-ASG-Orig-Subj: Returned mail: User unknown (from [211.1.194.36]) Subject: Returned mail: User unknown (from [211.1.194.36]) Auto-Submitted: auto-generated (failure) X-DSN-Mirapoint-Virus: VIRUSDELETED; host=mira1.aitai.ne.jp; attachment=[2.1.2]; virus=Mal/Iframe-E X-Barracuda-Connect: bnc02.aitai.ne.jp[211.1.192.125] X-Barracuda-Start-Time: 1213144790 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4998 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52956 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16309 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@mira1.aitai.ne.jp Precedence: bulk X-list: xfs This is a MIME-encapsulated message --DKV43907.1213144788/mira1.aitai.ne.jp The original message was received at Wed, 11 Jun 2008 09:39:45 +0900 (JST) from p5165-ipbfp1901tokaisakaetozai.aichi.ocn.ne.jp [118.5.118.165] ----- The following addresses had permanent delivery errors ----- ----- Transcript of session is unavailable ----- --DKV43907.1213144788/mira1.aitai.ne.jp Content-Type: message/delivery-status Reporting-MTA: dns; mira1.aitai.ne.jp Arrival-Date: Wed, 11 Jun 2008 09:39:45 +0900 (JST) Final-Recipient: RFC822; m-bell@hm.aitai.ne.jp Action: failed Status: 5.1.1 Remote-MTA: DNS; [211.1.194.36] Diagnostic-Code: SMTP; 550 User unknown Last-Attempt-Date: Wed, 11 Jun 2008 09:39:48 +0900 (JST) --DKV43907.1213144788/mira1.aitai.ne.jp Content-Type: message/rfc822 Received: from hm.aitai.ne.jp (p5165-ipbfp1901tokaisakaetozai.aichi.ocn.ne.jp [118.5.118.165]) by mira1.aitai.ne.jp (MOS 3.8.4-GA) with ESMTP id DKV43792; Wed, 11 Jun 2008 09:39:44 +0900 (JST) Message-Id: <200806110039.DKV43792@mira1.aitai.ne.jp> From: linux-xfs@oss.sgi.com To: m-bell@hm.aitai.ne.jp Subject: Mail Delivery (failure m-bell@hm.aitai.ne.jp) Date: Wed, 11 Jun 2008 09:39:43 +0900 X-Priority: 3 X-MSMail-Priority: Normal X-matriXscan-RefId: str=0001.0A150202.484F1ED1.0021,ss=1,fgs=0 X-matriXscan: Uncategorized X-matriXscan-Action: Approve X-Mirapoint-Virus: VIRUSDELETED; host=mira1.aitai.ne.jp; attachment=[2.1.2]; virus=Mal/Iframe-E X-Mirapoint-Virus: VIRUSDELETED; host=mira1.aitai.ne.jp; attachment=[2.2]; virus=W32/Netsky-P --DKV43907.1213144788/mira1.aitai.ne.jp-- From owner-xfs@oss.sgi.com Tue Jun 10 18:40:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 18:40:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5B1dvnF009773 for ; Tue, 10 Jun 2008 18:39:59 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09999; Wed, 11 Jun 2008 11:39:35 +1000 Message-ID: <484F2CD7.9070506@sgi.com> Date: Wed, 11 Jun 2008 11:39:35 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Richard Scobie CC: xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> In-Reply-To: <484F0998.90306@sauce.co.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16310 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Hi Richard, Richard Scobie wrote: > Timothy Shimmin wrote: > >> BTW, Sam Vaughan wrote some tutorial notes on the allocator and in >> particular >> filestreams which I've pasted below: >> (I thought it might be here: >> http://oss.sgi.com/projects/xfs/training/ but I can't see it >> in the allocator lab and slides). > > I did actually find an entry for filestreams in slide 6. > Yes, so did I but on a quick scan it didn't have the same detail. > While there I also found the information on 64bit inodes. > > My filesystem is 9.6TB and could well end up with a large quantity of > 1-15MB files stored and the statement: > > "Operating system interfaces and legacy software products often mandate > the use of 32 bit inode numbers even on systems that support 64 bit > inode numbers." > > makes me wonder how common this still is in practice - the slide was > written in 2006)? > > My initial preference would be to go with 64 bit inodes for performance > reasons, but as one cannot revert the fs back to 32 bit inodes once > committed, I am somewhat hesitant. > > Or am I worrying unecessarily about the negative impact of 32 bit > inodes, given 9.6TB full of 1 to 15MB files? > Ah, the 32 bit inode versus 64 bit inode question :) I don't have any definitive answers and I'm sure there will be people on the list with their opinions and experiences. So just some thoughts... Firstly, XFS' current support for 32 bit inode numbers was added as an afterthought I think primarily at the time on IRIX for 32 bit backup clients such as Legato Networker. It is only a compatibility thing with performance downsides. So the question then becomes (1)what exactly is the compatibility matrix and (2)under what conditions are there performance problems and by how much. The other thing (3) is then a conversion tool for moving back from 64 bit inodes to 32 bit inodes if you have a compat problem. (3) There is a conversion tool called xfs_reno on IRIX. Barry has ported and modified it for Linux but I believe has not checked it in and has some outstanding Agami review points to address. Ideally, it would be nicer if we had more kernel support (as suggested by Dave (dgc)) for swapping all the inode's metadata (instead of just extents as we currently do). So in other words, it is not there yet and there is the question of whether we should update the kernel first (or maybe the tool should go in anyway for use on older kernels). (1) It would be nice to know what the state of the apps really are. There is also the question of interaction with CXFS and NFS. Greg Banks has a compat matrix for NFS. It looks like the main things is to get something half recent - linux 2.6, nfs v3, apps which use 64 bit sys calls (eg. stat64) etc... Would need to do investigating. There is also the possibility of other 32bit/64bit mapping schemes for xfs but I won't go there. --Tim From owner-xfs@oss.sgi.com Tue Jun 10 19:37:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 19:37:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5B2bqX3013882 for ; Tue, 10 Jun 2008 19:37:53 -0700 X-ASG-Debug-ID: 1213151928-1d4b02ec0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5EB92C71EF7 for ; Tue, 10 Jun 2008 19:38:48 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id ihnpGwtIc2SZhG8E for ; Tue, 10 Jun 2008 19:38:48 -0700 (PDT) Received: (qmail 28542 invoked from network); 11 Jun 2008 02:38:47 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Jun 2008 02:38:47 -0000 Message-ID: <484F3CDF.10001@sauce.co.nz> Date: Wed, 11 Jun 2008 14:47:59 +1200 From: Richard Scobie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Timothy Shimmin CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> In-Reply-To: <484F2CD7.9070506@sgi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1213151929 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0926 1.0000 -1.4373 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.44 X-Barracuda-Spam-Status: No, SCORE=-1.44 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52965 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16311 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Hi Timothy, Timothy Shimmin wrote: > Ah, the 32 bit inode versus 64 bit inode question :) > I don't have any definitive answers and I'm sure there will be people > on the list with their opinions and experiences. > So just some thoughts... On balance, I'm thinking the best compromise might be to stay 32 bit and bump the inode size to 2048 bytes. Regards, Richard From owner-xfs@oss.sgi.com Tue Jun 10 20:22:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 10 Jun 2008 20:22:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5B3MTIq021756 for ; Tue, 10 Jun 2008 20:22:29 -0700 X-ASG-Debug-ID: 1213154604-6a0000740000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6AE1CC72178 for ; Tue, 10 Jun 2008 20:23:24 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id BXoZFVwiygw0UIVM for ; Tue, 10 Jun 2008 20:23:24 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id E023198FF73; Tue, 10 Jun 2008 22:23:22 -0500 (CDT) Message-ID: <484F452A.8090909@sandeen.net> Date: Tue, 10 Jun 2008 22:23:22 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Timothy Shimmin CC: Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> In-Reply-To: <484F2CD7.9070506@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213154605 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.52965 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16312 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Timothy Shimmin wrote: > (1) It would be nice to know what the state of the apps really are. > There is also the question of interaction with CXFS and NFS. > Greg Banks has a compat matrix for NFS. It looks like the main > things is to get something half recent - linux 2.6, nfs v3, > apps which use 64 bit sys calls (eg. stat64) etc... > Would need to do investigating. Greg has a tool to scan binaries... some day I'm going to run it over the fedora universe, I'll get back to you... someday. -Eric From owner-xfs@oss.sgi.com Thu Jun 12 06:51:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 06:52:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CDpv7u021111 for ; Thu, 12 Jun 2008 06:51:57 -0700 X-ASG-Debug-ID: 1213278773-6997021b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 75A231BA1A82 for ; Thu, 12 Jun 2008 06:52:53 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id WrPzMXgrj03c8LBa for ; Thu, 12 Jun 2008 06:52:53 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4F44298534E; Thu, 12 Jun 2008 08:52:52 -0500 (CDT) Message-ID: <48512A34.1020604@sandeen.net> Date: Thu, 12 Jun 2008 08:52:52 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Timothy Shimmin CC: Richard Scobie , xfs@oss.sgi.com, Greg Banks X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> In-Reply-To: <484F452A.8090909@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213278773 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53093 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16313 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > Timothy Shimmin wrote: > >> (1) It would be nice to know what the state of the apps really are. >> There is also the question of interaction with CXFS and NFS. >> Greg Banks has a compat matrix for NFS. It looks like the main >> things is to get something half recent - linux 2.6, nfs v3, >> apps which use 64 bit sys calls (eg. stat64) etc... >> Would need to do investigating. > > Greg has a tool to scan binaries... some day I'm going to run it over > the fedora universe, I'll get back to you... someday. someday didn't take too long :) but it ain't pretty. I installed all fedora packages under a directory and ran greg's tool over: /sbin /usr/sbin /bin /usr/bin /usr/kerberos/bin/ /usr/kerberos/sbin/ Aggregate results: 4070 29.1% are scripts (shell, perl, whatever) 6598 47.2% don't use any stat() family calls at all 1829 13.1% use 32-bit stat() family interfaces only 1312 9.4% use 64-bit stat64() family interfaces only 180 1.3% use both 32-bit and 64-bit stat() family interfaces list of packages, sorted by the semi-lame "number of files in package which call a 32-bit stat variant" metric: http://sandeen.fedorapeople.org/stat32-ers I'm going to see if I can't leverage Fedora to clean some of this up. -Eric From owner-xfs@oss.sgi.com Thu Jun 12 07:49:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 07:49:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CEnKPS024593 for ; Thu, 12 Jun 2008 07:49:20 -0700 X-ASG-Debug-ID: 1213282215-213c00490000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8CDC917B7C9C for ; Thu, 12 Jun 2008 07:50:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by cuda.sgi.com with ESMTP id MSVub9SeUQjQvj4Y for ; Thu, 12 Jun 2008 07:50:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so2637289fgb.8 for ; Thu, 12 Jun 2008 07:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=GfUONjySnFi11nMrYDy3Ep9zONrqzX5WJPCC74dmosg=; b=B9dv37GzCLfLMuw/5sG8bch00kgHcZNzy65xuq4PYkfOkjQ/lVJ49KcrkdYc1xd4OP W8/icahuAvpaTgcZV1BNO1F7VFS3N4a89QvktMwp77+gyBVaL04BKvk/nx+ohmAtJUGv TOkntrHTZ05bxPAGaF/iB7KIO8TCYrsUP5anY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=S4h4nnkeyWlMwswxER88kCocTE3FeP8Zsv41UmOsHhLNC+8AC5BBoLYDvKkNn8G0bK GXwGPWDUskdx9aQAI4xaSnoRplzcK6JdQn/DDSpkiV3HAI4sSc1/KcHxYKoLWtlZexf+ KulUUaYKSjd/jjDmAle6JxWVZMFG/OWK1VCtk= Received: by 10.86.25.17 with SMTP id 17mr2391889fgy.50.1213282214095; Thu, 12 Jun 2008 07:50:14 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Thu, 12 Jun 2008 07:50:14 -0700 (PDT) Message-ID: <6101e8c40806120750r46f92c64tb4ac27d91163c07d@mail.gmail.com> Date: Thu, 12 Jun 2008 16:50:14 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: [XFS] oss.sgi Subject: Re: [XFS] oss.sgi Cc: "Christoph Hellwig" , xfs@oss.sgi.com In-Reply-To: <484F0594.1010406@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806100426i7a8d691brd87256ad49052e49@mail.gmail.com> <20080610122420.GA15871@infradead.org> <6101e8c40806101451tb160ed8rc0ba2739cafee84f@mail.gmail.com> <484F0594.1010406@sandeen.net> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.159] X-Barracuda-Start-Time: 1213282216 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3292 1.0000 -0.2296 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.23 X-Barracuda-Spam-Status: No, SCORE=-0.23 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53097 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16314 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs nothing strange, only that how much developed. I observe it otherwise in lkml or in git-logs ;) On 6/11/08, Eric Sandeen wrote: > Oliver Pinter wrote: >> hi! >> >> thanks the info >> >> On 6/10/08, Christoph Hellwig wrote: >>> On Tue, Jun 10, 2008 at 01:26:39PM +0200, Oliver Pinter wrote: >>>> Hi All! >>>> >>>> is the http://oss.sgi.com/projects/xfs/ site up to date? >>> More or less. It could have a few more recent news items or reference >>> to presentations from the last few month, but I can't find anything >>> grossly out of date. > > Is there any info in particular that you wondered about? :) > > -Eric > -- Thanks, Oliver From owner-xfs@oss.sgi.com Thu Jun 12 09:53:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 09:53:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CGrTnJ005405 for ; Thu, 12 Jun 2008 09:53:29 -0700 X-ASG-Debug-ID: 1213289665-65ed03c40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hrndva-omtalb.mail.rr.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0D39E21EE0C for ; Thu, 12 Jun 2008 09:54:25 -0700 (PDT) Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.123]) by cuda.sgi.com with ESMTP id vAesacvkSc2e7Jgg for ; Thu, 12 Jun 2008 09:54:25 -0700 (PDT) Received: from www.structurenet.com ([74.68.50.165]) by hrndva-omta03.mail.rr.com with ESMTP id <20080612165424.OOUT29933.hrndva-omta03.mail.rr.com@www.structurenet.com> for ; Thu, 12 Jun 2008 16:54:24 +0000 Received: from 38.117.134.222 (proxying for unknown) (SquirrelMail authenticated user bshi) by www.structurenet.com with HTTP; Thu, 12 Jun 2008 12:54:24 -0400 (EDT) Message-ID: <37328.38.117.134.222.1213289664.squirrel@www.structurenet.com> In-Reply-To: <9E397A467F4DB34884A1FD0D5D27CF43018903F96E@msxaoa4.twosigma.com> References: <9E397A467F4DB34884A1FD0D5D27CF43018903F96E@msxaoa4.twosigma.com> Date: Thu, 12 Jun 2008 12:54:24 -0400 (EDT) X-ASG-Orig-Subj: Re: several messages Subject: Re: several messages From: "Benjamin L. Shi" To: xfs@oss.sgi.com Reply-To: bshi@structurenet.com User-Agent: SquirrelMail/1.4.6-1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: hrndva-omtalb.mail.rr.com[71.74.56.123] X-Barracuda-Start-Time: 1213289666 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4909 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53105 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16315 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bshi@structurenet.com Precedence: bulk X-list: xfs Index: fs/xfs/xfs_iomap.c =================================================================== RCS file: /src/linux/2.6.18/fs/xfs/xfs_iomap.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- fs/xfs/xfs_iomap.c 29 Sep 2006 13:45:19 -0000 1.1.1.1 +++ fs/xfs/xfs_iomap.c 12 Jun 2008 15:59:10 -0000 1.2 @@ -706,11 +706,24 @@ * then we must have run out of space - flush delalloc, and retry.. */ if (nimaps == 0) { + if ((mp->m_flags & XFS_MOUNT_FULL) != 0) { + if (mp->m_sb.sb_fdblocks < 500) { + // printk("full again %llu\n", + // mp->m_sb.sb_fdblocks); + return XFS_ERROR(ENOSPC); + } else { + // printk("not full again %llu\n", + // mp->m_sb.sb_fdblocks); + mp->m_flags &= ~XFS_MOUNT_FULL; + } + } xfs_iomap_enter_trace(XFS_IOMAP_WRITE_NOSPACE, io, offset, count); - if (xfs_flush_space(ip, &fsynced, &ioflag)) + if (xfs_flush_space(ip, &fsynced, &ioflag)) { + mp->m_flags |= XFS_MOUNT_FULL; + //printk("set full %llu\n", mp->m_sb.sb_fdblocks); return XFS_ERROR(ENOSPC); - + } error = 0; goto retry; } Index: fs/xfs/xfs_mount.h =================================================================== RCS file: /src/linux/2.6.18/fs/xfs/xfs_mount.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- fs/xfs/xfs_mount.h 29 Sep 2006 13:45:19 -0000 1.1.1.1 +++ fs/xfs/xfs_mount.h 12 Jun 2008 15:59:10 -0000 1.2 @@ -459,6 +459,7 @@ * I/O size in stat() */ #define XFS_MOUNT_NO_PERCPU_SB (1ULL << 23) /* don't use per-cpu superblock counters */ +#define XFS_MOUNT_FULL (1ULL << 24) /* > > On Fri, 6 Oct 2006, David Chinner wrote: > >>> The backtrace looked like this: >>> >>> ... nfsd_write nfsd_vfs_write vfs_writev do_readv_writev >>> xfs_file_writev >>> xfs_write generic_file_buffered_write xfs_get_blocks __xfs_get_blocks >>> xfs_bmap xfs_iomap xfs_iomap_write_delay xfs_flush_space >>> xfs_flush_device >>> schedule_timeout_uninterruptible. >> >> Ahhh, this gets hit on the ->prepare_write path >> (xfs_iomap_write_delay()), > > Yes. > >> not the allocate path (xfs_iomap_write_allocate()). Sorry - I got myself >> (and probably everyone else) confused there which why I suspected sync >> writes - they trigger the allocate path in the write call. I don't think >> 2.6.18 will change anything. >> >> FWIW, I don't think we can avoid this sleep when we first hit ENOSPC >> conditions, but perhaps once we are certain of the ENOSPC status >> we can tag the filesystem with this state (say an xfs_mount flag) >> and only clear that tag when something is freed. We could then >> use the tag to avoid continually trying extremely hard to allocate >> space when we know there is none available.... > > Yes! That's what I was trying to suggest << OLE Object: Picture (Device > Independent Bitmap) >> . Thank you. > > Is that hard to do? > From owner-xfs@oss.sgi.com Thu Jun 12 10:08:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 10:08:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00, KB_DATE_CONTAINS_TAB autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CH8DU1006716 for ; Thu, 12 Jun 2008 10:08:14 -0700 X-ASG-Debug-ID: 1213290545-0fe702910000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp3.poczta.onet.pl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DEF6421F065 for ; Thu, 12 Jun 2008 10:09:06 -0700 (PDT) Received: from smtp3.poczta.onet.pl (smtp3.poczta.onet.pl [213.180.130.29]) by cuda.sgi.com with ESMTP id 5cDj4ExCN99Yj3FA for ; Thu, 12 Jun 2008 10:09:06 -0700 (PDT) Received: from rudy.mif.pg.gda.pl ([153.19.42.16]:34410 "EHLO orion.wszechswiat.org" rhost-flags-OK-OK-OK-FAIL) by ps3.test.onet.pl with ESMTPSA id S184555754AbYFLRJD4bzAh (ORCPT ); Thu, 12 Jun 2008 19:09:03 +0200 Message-ID: <485157D2.5050906@op.pl> Date: Thu, 12 Jun 2008 19:07:30 +0200 From: Bogdan User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Does XFS support sharing blocks? Subject: Does XFS support sharing blocks? X-Enigmail-Version: 0.95.6 OpenPGP: url=http://rudy.mif.pg.gda.pl/~bogdro/bogdan_publiczny.asc Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp3.poczta.onet.pl[213.180.130.29] X-Barracuda-Start-Time: 1213290546 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4983 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53105 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16316 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bogdandr@op.pl Precedence: bulk X-list: xfs Hello. I have a question: does the XFS filesystem support sharing blocks between objects (files, symlinks, fifos, ...). I mean, can 2 distinct objects have their data inside one physical block? If not, what is the "offset" field for in xfs_db output: xfs_db> inode 19331 xfs_db> bmap -d data offset 0 startblock 1212 (0/1212) count 1 flag 0 -- Pozdrawiam/Regards - Bogdan (GNU/Linux & FreeDOS) Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro Grupy dyskusyjne o asm: pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32 www.JabberPL.org www.TorProject.org Soft (EN): miniurl.pl/bogdro-soft From owner-xfs@oss.sgi.com Thu Jun 12 13:15:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 13:15:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CKFMSD024730 for ; Thu, 12 Jun 2008 13:15:51 -0700 X-ASG-Debug-ID: 1213301778-7f2a02190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C410ECA056D for ; Thu, 12 Jun 2008 13:16:19 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id v4Fcv4D4YOgl6xnt for ; Thu, 12 Jun 2008 13:16:19 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5CKGG7N004573; Thu, 12 Jun 2008 16:16:16 -0400 Received: from file.rdu.redhat.com (file.rdu.redhat.com [10.11.255.147]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5CKGFnC002079; Thu, 12 Jun 2008 16:16:15 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by file.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id m5CKGFBL006639; Thu, 12 Jun 2008 16:16:15 -0400 Message-ID: <4851840F.6060404@sandeen.net> Date: Thu, 12 Jun 2008 15:16:15 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Bogdan CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Does XFS support sharing blocks? Subject: Re: Does XFS support sharing blocks? References: <485157D2.5050906@op.pl> In-Reply-To: <485157D2.5050906@op.pl> Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1213301779 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16317 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Bogdan wrote: > Hello. > > I have a question: does the XFS filesystem support sharing blocks > between objects (files, symlinks, fifos, ...). I mean, can 2 distinct > objects have their data inside one physical block? If not, what is the > "offset" field for in xfs_db output: > > xfs_db> inode 19331 > xfs_db> bmap -d > data offset 0 startblock 1212 (0/1212) count 1 flag 0 it's simply the block number in the file. You have a 1 block file, it's first (and only) block is at physical block 1212 (block 1212 in AG 0) -Eric From owner-xfs@oss.sgi.com Thu Jun 12 15:19:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 15:19:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CMJd7p030755 for ; Thu, 12 Jun 2008 15:19:39 -0700 X-ASG-Debug-ID: 1213309234-6c67034e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2D124C898AD for ; Thu, 12 Jun 2008 15:20:34 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id gFi9ZmKwJ9lXWcM2 for ; Thu, 12 Jun 2008 15:20:34 -0700 (PDT) Received: (qmail 10972 invoked from network); 12 Jun 2008 22:20:31 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jun 2008 22:20:31 -0000 Message-ID: <4851A36B.6030404@sauce.co.nz> Date: Fri, 13 Jun 2008 10:30:03 +1200 From: Richard Scobie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: mkfs.xfs man page Subject: mkfs.xfs man page Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1213309236 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3555 1.0000 -0.1337 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.13 X-Barracuda-Spam-Status: No, SCORE=-0.13 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53126 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16318 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs The latest xfsprogs, 2.9.8-1 makes no mention of the "-d unwritten" option in the mkfs.xfs man page. Not sure if this is by design or not. Regards, Richard From owner-xfs@oss.sgi.com Thu Jun 12 15:26:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 15:26:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CMQGbl031300 for ; Thu, 12 Jun 2008 15:26:17 -0700 X-ASG-Debug-ID: 1213309631-067200680000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-vbr13.xs4all.nl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DD1892247B4 for ; Thu, 12 Jun 2008 15:27:11 -0700 (PDT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by cuda.sgi.com with ESMTP id catjtT6wkQ6RhTkS for ; Thu, 12 Jun 2008 15:27:11 -0700 (PDT) Received: from [192.168.1.129] (a82-95-163-142.adsl.xs4all.nl [82.95.163.142]) (authenticated bits=0) by smtp-vbr13.xs4all.nl (8.13.8/8.13.8) with ESMTP id m5CMR9XU081056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2008 00:27:09 +0200 (CEST) (envelope-from mikevs@xs4all.net) X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c From: Miquel van Smoorenburg To: Oliver Pinter Cc: lists@ku-gbr.de, linux-kernel@vger.kernel.org, Christoph Hellwig , xfs@oss.sgi.com, xfs-masters@oss.sgi.com, mikevs@xs4all.net In-Reply-To: <6101e8c40806120733m3c8647ccy149eb237e2c6d027@mail.gmail.com> References: <20080612123031.21594jyk6rjc1lfk@imp.ku-gbr.de> <6101e8c40806120733m3c8647ccy149eb237e2c6d027@mail.gmail.com> Content-Type: text/plain Date: Fri, 13 Jun 2008 00:27:09 +0200 Message-Id: <1213309629.29745.8.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by XS4ALL Virus Scanner X-Barracuda-Connect: smtp-vbr13.xs4all.nl[194.109.24.33] X-Barracuda-Start-Time: 1213309632 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53127 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16319 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikevs@xs4all.net Precedence: bulk X-list: xfs On Thu, 2008-06-12 at 16:33 +0200, Oliver Pinter wrote: > add CC's > > On 6/12/08, lists@ku-gbr.de wrote: > > Hi! > > > > Today morning my server at home bailed out two times (reboot between): > > Jun 12 07:23:40 zappa > > Jun 12 07:23:40 zappa xfs_force_shutdown(sda7,0x8) called from line > > 1164 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff802f4d8a > > Jun 12 07:23:40 zappa Filesystem "sda7": Corruption of in-memory data > > detected. Shutting down filesystem: sda7 > > Jun 12 07:23:40 zappa Please umount the filesystem, and rectify the > > problem(s) Hmm, interesting. I'm seeing the same thing on one of my servers since I upgraded from 2.6.ancient (14 or so) to 2.6.25, while XFS otherwise has been very stable for me over the years: Linux transit5.news.xs4all.nl 2.6.25.6 #1 SMP Wed Jun 11 10:59:10 CEST 2008 x86_64 GNU/Linux Filesystem "sda4": XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c. Caller 0xffffffff880f1315 Pid: 3402, comm: diablo Not tainted 2.6.25.6 #1 Call Trace: [] :xfs:xfs_create+0x1e5/0x520 [] :xfs:xfs_trans_cancel+0x126/0x150 [] :xfs:xfs_create+0x1e5/0x520 [] :xfs:xfs_vn_mknod+0x1d9/0x320 [] vfs_create+0xac/0xf0 [] open_namei+0x61d/0x6c0 [] autoremove_wake_function+0x0/0x30 [] do_filp_open+0x1c/0x50 [] get_unused_fd_flags+0x79/0x120 [] do_sys_open+0x5a/0xf0 [] system_call_after_swapgs+0x7b/0x80 xfs_force_shutdown(sda4,0x8) called from line 1164 of file fs/xfs/xfs_trans.c. Return address = 0xffffffff880ea4bf Filesystem "sda4": Corruption of in-memory data detected. Shutting down filesystem: sda4 Please umount the filesystem, and rectify the problem(s) After a reboot, xfs_repair didn't find anything wrong with the fs. It has happened 3 times over the last few days already. FS is on a local SCSI raid (dpt_i2o), not SATA. Mike. From owner-xfs@oss.sgi.com Thu Jun 12 15:30:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 15:31:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5CMUu8Y031826 for ; Thu, 12 Jun 2008 15:30:56 -0700 X-ASG-Debug-ID: 1213309913-1cf001bc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6DCF117BA8D6 for ; Thu, 12 Jun 2008 15:31:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id oUkZDMN0HUDcjNCW for ; Thu, 12 Jun 2008 15:31:53 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5CMVqFB017233; Thu, 12 Jun 2008 18:31:52 -0400 Received: from file.rdu.redhat.com (file.rdu.redhat.com [10.11.255.147]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5CMVphn011121; Thu, 12 Jun 2008 18:31:51 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by file.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id m5CMVp9p001563; Thu, 12 Jun 2008 18:31:51 -0400 Message-ID: <4851A3D6.809@sandeen.net> Date: Thu, 12 Jun 2008 17:31:50 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Richard Scobie CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: mkfs.xfs man page Subject: Re: mkfs.xfs man page References: <4851A36B.6030404@sauce.co.nz> In-Reply-To: <4851A36B.6030404@sauce.co.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1213309913 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16320 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Richard Scobie wrote: > The latest xfsprogs, 2.9.8-1 makes no mention of the "-d unwritten" > option in the mkfs.xfs man page. > > Not sure if this is by design or not. > > Regards, > > Richard It is intentional: http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/man/man8/mkfs.xfs.8#rev1.30 Thanks, -Eric From owner-xfs@oss.sgi.com Thu Jun 12 18:31:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 18:31:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D1VaTF012934 for ; Thu, 12 Jun 2008 18:31:36 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay1.corp.sgi.com (Postfix) with ESMTP id D14678F80C0; Thu, 12 Jun 2008 18:32:29 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D1WGjm1929339; Fri, 13 Jun 2008 11:32:21 +1000 (AEST) Message-ID: <4851CD32.7080106@melbourne.sgi.com> Date: Fri, 13 Jun 2008 11:28:18 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> In-Reply-To: <48512A34.1020604@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16321 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Eric Sandeen wrote: > >> Timothy Shimmin wrote: >> >> >>> (1) It would be nice to know what the state of the apps really are. >>> There is also the question of interaction with CXFS and NFS. >>> Greg Banks has a compat matrix for NFS. It looks like the main >>> things is to get something half recent - linux 2.6, nfs v3, >>> apps which use 64 bit sys calls (eg. stat64) etc... >>> Would need to do investigating. >>> >> Greg has a tool to scan binaries... some day I'm going to run it over >> the fedora universe, I'll get back to you... someday. >> > > someday didn't take too long :) Cool, thanks for the data Eric. > but it ain't pretty. > > I installed all fedora packages under a directory and ran greg's tool over: > > /sbin /usr/sbin /bin /usr/bin /usr/kerberos/bin/ /usr/kerberos/sbin/ > > Aggregate results: > > 4070 29.1% are scripts (shell, perl, whatever) > 6598 47.2% don't use any stat() family calls at all > 1829 13.1% use 32-bit stat() family interfaces only > 1312 9.4% use 64-bit stat64() family interfaces only > 180 1.3% use both 32-bit and 64-bit stat() family interfaces > Ouch. That's over two thousand executables to patch, rebuild, and ship. > list of packages, sorted by the semi-lame "number of files in package > which call a 32-bit stat variant" metric: > > http://sandeen.fedorapeople.org/stat32-ers > > I'm going to see if I can't leverage Fedora to clean some of this up. > > -Eric > Good luck with that. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. From owner-xfs@oss.sgi.com Thu Jun 12 20:05:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:05:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3595H017479 for ; Thu, 12 Jun 2008 20:05:09 -0700 X-ASG-Debug-ID: 1213326365-76e1036f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 84FB517BB82D for ; Thu, 12 Jun 2008 20:06:05 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 2HqD5gTVXznzLWCx for ; Thu, 12 Jun 2008 20:06:05 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 968AAA9BF45; Thu, 12 Jun 2008 22:06:04 -0500 (CDT) Message-ID: <4851E41C.6050108@sandeen.net> Date: Thu, 12 Jun 2008 22:06:04 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Greg Banks CC: Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> In-Reply-To: <4851CD32.7080106@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213326365 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0208 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53144 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16322 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Greg Banks wrote: > Eric Sandeen wrote: > Cool, thanks for the data Eric. > >> but it ain't pretty. >> >> I installed all fedora packages under a directory and ran greg's tool over: >> >> /sbin /usr/sbin /bin /usr/bin /usr/kerberos/bin/ /usr/kerberos/sbin/ >> >> Aggregate results: >> >> 4070 29.1% are scripts (shell, perl, whatever) >> 6598 47.2% don't use any stat() family calls at all >> 1829 13.1% use 32-bit stat() family interfaces only >> 1312 9.4% use 64-bit stat64() family interfaces only >> 180 1.3% use both 32-bit and 64-bit stat() family interfaces >> > Ouch. That's over two thousand executables to patch, rebuild, and ship. >> list of packages, sorted by the semi-lame "number of files in package >> which call a 32-bit stat variant" metric: >> >> http://sandeen.fedorapeople.org/stat32-ers And about 900 packages... >> I'm going to see if I can't leverage Fedora to clean some of this up. >> >> -Eric >> > Good luck with that. Heh :) At first I was just going to correlate with st_ino users to cut it down, but then I learned that glibc will actually give you an EOVERFLOW if, say st_ino overflows, even if you were only going to check st_mode. :( So pretty much everything needs fixing. (FWIW I gathered statfs/statvfs calls, too...) -Eric From owner-xfs@oss.sgi.com Thu Jun 12 20:19:33 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:19:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D3JUUa023007 for ; Thu, 12 Jun 2008 20:19:31 -0700 Received: from [134.14.55.22] (dhcp22.melbourne.sgi.com [134.14.55.22]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11274; Fri, 13 Jun 2008 13:20:20 +1000 Message-ID: <4851E774.2070401@sgi.com> Date: Fri, 13 Jun 2008 13:20:20 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Greg Banks CC: Eric Sandeen , Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> In-Reply-To: <4851CD32.7080106@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16323 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Greg Banks wrote: > Eric Sandeen wrote: >> 4070 29.1% are scripts (shell, perl, whatever) >> 6598 47.2% don't use any stat() family calls at all >> 1829 13.1% use 32-bit stat() family interfaces only >> 1312 9.4% use 64-bit stat64() family interfaces only >> 180 1.3% use both 32-bit and 64-bit stat() family interfaces >> > Ouch. That's over two thousand executables to patch, rebuild, and ship. >> list of packages, sorted by the semi-lame "number of files in package >> which call a 32-bit stat variant" metric: >> >> http://sandeen.fedorapeople.org/stat32-ers struct dirent has an embedded ino_t too, so for completeness we should also be looking for readdir(), readdir64(), getdirentries(), getdirentries64(), etc. >> I'm going to see if I can't leverage Fedora to clean some of this up. >> >> -Eric >> > Good luck with that. Yes good luck :) (and the plan for statically linked apps? ...) Cheers -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Thu Jun 12 20:27:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:27:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3RjQn023668 for ; Thu, 12 Jun 2008 20:27:46 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 46EB29088C; Thu, 12 Jun 2008 20:28:38 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D3SSjm1952859; Fri, 13 Jun 2008 13:28:32 +1000 (AEST) Message-ID: <4851E86E.6030203@melbourne.sgi.com> Date: Fri, 13 Jun 2008 13:24:30 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E41C.6050108@sandeen.net> In-Reply-To: <4851E41C.6050108@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16324 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > > Heh :) At first I was just going to correlate with st_ino users to cut > it down, but then I learned that glibc will actually give you an > EOVERFLOW if, say st_ino overflows, even if you were only going to check > st_mode. :( So pretty much everything needs fixing. > Of course. There's no way for the app to tell glibc that the app doesn't care about st_ino, so glibc must assume that glibc needs to return an accurate st_ino. The alternative is to return the lower 32 bits of st_ino, thus causing silent subtle failures in the very small number of applications which actually do something with st_ino. This is what glibc used to do back when I first started tracking the issue. > (FWIW I gathered statfs/statvfs calls, too...) > > Yes. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. From owner-xfs@oss.sgi.com Thu Jun 12 20:43:43 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:43:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3hheT024452 for ; Thu, 12 Jun 2008 20:43:43 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 2E0849088C; Thu, 12 Jun 2008 20:44:39 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D3iQjm1940596; Fri, 13 Jun 2008 13:44:28 +1000 (AEST) Message-ID: <4851EC2D.6010504@melbourne.sgi.com> Date: Fri, 13 Jun 2008 13:40:29 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: markgw@sgi.com CC: Eric Sandeen , Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> In-Reply-To: <4851E774.2070401@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16325 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs Mark Goodwin wrote: > > > Greg Banks wrote: >> Eric Sandeen wrote: >>> 4070 29.1% are scripts (shell, perl, whatever) >>> 6598 47.2% don't use any stat() family calls at all >>> 1829 13.1% use 32-bit stat() family interfaces only >>> 1312 9.4% use 64-bit stat64() family interfaces only >>> 180 1.3% use both 32-bit and 64-bit stat() family interfaces >>> >> Ouch. That's over two thousand executables to patch, rebuild, and ship. >>> list of packages, sorted by the semi-lame "number of files in package >>> which call a 32-bit stat variant" metric: >>> >>> http://sandeen.fedorapeople.org/stat32-ers > > struct dirent has an embedded ino_t too, so for completeness we should > also > be looking for readdir(), readdir64(), getdirentries(), > getdirentries64(), etc. Good point. Looking in the code, it seems the getdents common code in glibc will fail with EOVERFLOW if the inode number gets truncated during 64b-32b translation, just like the stat() family. I'll need to improve the scanning tool :-) > >>> I'm going to see if I can't leverage Fedora to clean some of this up. >>> >>> -Eric >>> >> Good luck with that. > > Yes good luck :) > (and the plan for statically linked apps? ...) Perhaps Fedora could enable the glibc magic for issuing warnings at link time when those symbols are used, like what happens today if you use the old unsafe gets() function: gnb@inara 1058> gcc -o fmeh x.c /tmp/ccQhxIIo.o: In function `main': x.c:(.text+0x18): warning: the `gets' function is dangerous and should not be used. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. From owner-xfs@oss.sgi.com Thu Jun 12 20:44:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:44:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3iG0R024640 for ; Thu, 12 Jun 2008 20:44:16 -0700 X-ASG-Debug-ID: 1213328712-39c601d50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F38C3C9CEF5 for ; Thu, 12 Jun 2008 20:45:12 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id VlblGYitsfNF5oOf for ; Thu, 12 Jun 2008 20:45:12 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id D1DF2A9C502; Thu, 12 Jun 2008 22:45:11 -0500 (CDT) Message-ID: <4851ED48.90103@sandeen.net> Date: Thu, 12 Jun 2008 22:45:12 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Greg Banks , Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> In-Reply-To: <4851E774.2070401@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213328712 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0190 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53147 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16326 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Goodwin wrote: > struct dirent has an embedded ino_t too, so for completeness we should also > be looking for readdir(), readdir64(), getdirentries(), > getdirentries64(), etc. *sigh* >>> I'm going to see if I can't leverage Fedora to clean some of this up. >>> >>> -Eric >>> >> Good luck with that. > > Yes good luck :) > (and the plan for statically linked apps? ...) I plan to encourage fedora to keep discouraging them ;) -Eric From owner-xfs@oss.sgi.com Thu Jun 12 20:46:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 20:46:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D3k3sX025191 for ; Thu, 12 Jun 2008 20:46:03 -0700 X-ASG-Debug-ID: 1213328819-2cdd01e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E1B9722535C for ; Thu, 12 Jun 2008 20:46:59 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 7JrKy4o2hjiICQXo for ; Thu, 12 Jun 2008 20:46:59 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 1372CA9C502; Thu, 12 Jun 2008 22:46:59 -0500 (CDT) Message-ID: <4851EDB3.1010601@sandeen.net> Date: Thu, 12 Jun 2008 22:46:59 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Greg Banks CC: markgw@sgi.com, Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> <4851EC2D.6010504@melbourne.sgi.com> In-Reply-To: <4851EC2D.6010504@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213328819 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0006 1.0000 -2.0170 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53148 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16327 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Greg Banks wrote: >> (and the plan for statically linked apps? ...) > > Perhaps Fedora could enable the glibc magic for issuing warnings at link > time when those symbols are used, like what happens today if you use the > old unsafe gets() function: > > gnb@inara 1058> gcc -o fmeh x.c > /tmp/ccQhxIIo.o: In function `main': > x.c:(.text+0x18): warning: the `gets' function is dangerous and should not be used. It wouldn't help the automated builds (nobody'd see it) but for normal user compilations that might be an option... -Eric From owner-xfs@oss.sgi.com Thu Jun 12 21:00:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 21:00:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D40foY026016 for ; Thu, 12 Jun 2008 21:00:41 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 9F71C9089F; Thu, 12 Jun 2008 21:01:34 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D41Mjm1957704; Fri, 13 Jun 2008 14:01:27 +1000 (AEST) Message-ID: <4851F024.7020508@melbourne.sgi.com> Date: Fri, 13 Jun 2008 13:57:24 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: markgw@sgi.com, Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> <4851EC2D.6010504@melbourne.sgi.com> <4851EDB3.1010601@sandeen.net> In-Reply-To: <4851EDB3.1010601@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16328 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Greg Banks wrote: > > >>> (and the plan for statically linked apps? ...) >>> >> Perhaps Fedora could enable the glibc magic for issuing warnings at link >> time when those symbols are used, like what happens today if you use the >> old unsafe gets() function: >> >> gnb@inara 1058> gcc -o fmeh x.c >> /tmp/ccQhxIIo.o: In function `main': >> x.c:(.text+0x18): warning: the `gets' function is dangerous and should not be used. >> > > > It wouldn't help the automated builds (nobody'd see it) Hmm. I don't see a way in glibc to upgrade that warning to an error to make those builds fail, at least in glibc 2.4. > but for normal > user compilations that might be an option... > > Indeed. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. From owner-xfs@oss.sgi.com Thu Jun 12 21:09:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 21:09:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D492k4026552 for ; Thu, 12 Jun 2008 21:09:03 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA12158; Fri, 13 Jun 2008 14:09:48 +1000 Message-ID: <4851F30C.4000108@sgi.com> Date: Fri, 13 Jun 2008 14:09:48 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr References: <20080603114837.GB2703@lst.de> In-Reply-To: <20080603114837.GB2703@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16329 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs This appears to break xfstests/063 (EA xfsdump test). Will look into it. --Tim Christoph Hellwig wrote: > This patch switches xfs_vn_listxattr to set it's put_listent callback > directly and not go through xfs_attr_list. > > The changes to the lowleve attr code are: > > - the put_listent callback now gets the ondisk flags passed and > performce the namespace lookup and check aswell as the check > for the right attribute root itself > - xfs_attr_list_int is made non-static for use by other callers > than xfs_attr_list and now performs the inode locking and tracing > itself > > The changes to the xfs_attr_list path are: > > - all checks for now uneeded ATTR_KERN flags are gone, and only > the IRIX interface is supported for this code path > - xfs_attr_put_listent is simplified by not needing to lookup > the namespace but rather compare the integer flags directly. > > The changes to xfs_vn_listxattr are: > > - now directly calls xfs_attr_list_int with it's own put_listent > callbacks > - attr namespace prefix are now looked up by simple helpers, > struct attrnames is gone. > > Other changes: > > - struct xfs_attr_list_context is moved from xfs_attr_leaf.h into > xfs_attr.h. It's not realted to the leaf format at all and > xfs_attr.h contains the interface to the attr code which it is > part of now. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_attr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-01 14:40:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-01 14:44:07.000000000 +0200 > @@ -16,8 +16,6 @@ > * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > */ > > -#include > - > #include "xfs.h" > #include "xfs_fs.h" > #include "xfs_types.h" > @@ -607,12 +605,20 @@ xfs_attr_remove( > return xfs_attr_remove_int(dp, &xname, flags); > } > > -STATIC int > +int > xfs_attr_list_int(xfs_attr_list_context_t *context) > { > int error; > xfs_inode_t *dp = context->dp; > > + XFS_STATS_INC(xs_attr_list); > + > + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > + return EIO; > + > + xfs_ilock(dp, XFS_ILOCK_SHARED); > + xfs_attr_trace_l_c("syscall start", context); > + > /* > * Decide on what work routines to call based on the inode size. > */ > @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ > } else { > error = xfs_attr_node_list(context); > } > + > + xfs_iunlock(dp, XFS_ILOCK_SHARED); > + xfs_attr_trace_l_c("syscall end", context); > + > return error; > } > > @@ -634,6 +644,18 @@ xfs_attr_list_int(xfs_attr_list_context_ > ((ATTR_ENTBASESIZE + (namelen) + 1 + sizeof(u_int32_t)-1) \ > & ~(sizeof(u_int32_t)-1)) > > +STATIC int > +xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) > +{ > + if (((arg_flags & ATTR_SECURE) == 0) != > + ((ondisk_flags & XFS_ATTR_SECURE) == 0)) > + return 0; > + if (((arg_flags & ATTR_ROOT) == 0) != > + ((ondisk_flags & XFS_ATTR_ROOT) == 0)) > + return 0; > + return 1; > +} > + > /* > * Format an attribute and copy it out to the user's buffer. > * Take care to check values and protect against them changing later, > @@ -641,74 +663,43 @@ xfs_attr_list_int(xfs_attr_list_context_ > */ > /*ARGSUSED*/ > STATIC int > -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, > +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, > char *name, int namelen, > int valuelen, char *value) > { > + struct attrlist *alist = (struct attrlist *)context->alist; > attrlist_ent_t *aep; > int arraytop; > > ASSERT(!(context->flags & ATTR_KERNOVAL)); > ASSERT(context->count >= 0); > ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); > - ASSERT(context->firstu >= sizeof(*context->alist)); > + ASSERT(context->firstu >= sizeof(*alist)); > ASSERT(context->firstu <= context->bufsize); > > - arraytop = sizeof(*context->alist) + > - context->count * sizeof(context->alist->al_offset[0]); > + if (xfs_attr_namesp_match_overrides(context->flags, flags)) > + return 0; > + > + arraytop = sizeof(*alist) + > + context->count * sizeof(alist->al_offset[0]); > context->firstu -= ATTR_ENTSIZE(namelen); > if (context->firstu < arraytop) { > xfs_attr_trace_l_c("buffer full", context); > - context->alist->al_more = 1; > + alist->al_more = 1; > context->seen_enough = 1; > return 1; > } > > - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); > + aep = (attrlist_ent_t *)&context->alist[context->firstu]; > aep->a_valuelen = valuelen; > memcpy(aep->a_name, name, namelen); > - aep->a_name[ namelen ] = 0; > - context->alist->al_offset[ context->count++ ] = context->firstu; > - context->alist->al_count = context->count; > + aep->a_name[namelen] = 0; > + alist->al_offset[context->count++] = context->firstu; > + alist->al_count = context->count; > xfs_attr_trace_l_c("add", context); > return 0; > } > > -STATIC int > -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, > - char *name, int namelen, > - int valuelen, char *value) > -{ > - char *offset; > - int arraytop; > - > - ASSERT(context->count >= 0); > - > - arraytop = context->count + namesp->attr_namelen + namelen + 1; > - if (arraytop > context->firstu) { > - context->count = -1; /* insufficient space */ > - return 1; > - } > - offset = (char *)context->alist + context->count; > - strncpy(offset, namesp->attr_name, namesp->attr_namelen); > - offset += namesp->attr_namelen; > - strncpy(offset, name, namelen); /* real name */ > - offset += namelen; > - *offset = '\0'; > - context->count += namesp->attr_namelen + namelen + 1; > - return 0; > -} > - > -/*ARGSUSED*/ > -STATIC int > -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, > - char *name, int namelen, > - int valuelen, char *value) > -{ > - context->count += namesp->attr_namelen + namelen + 1; > - return 0; > -} > - > /* > * Generate a list of extended attribute names and optionally > * also value lengths. Positive return value follows the XFS > @@ -725,10 +716,9 @@ xfs_attr_list( > attrlist_cursor_kern_t *cursor) > { > xfs_attr_list_context_t context; > + struct attrlist *alist; > int error; > > - XFS_STATS_INC(xs_attr_list); > - > /* > * Validate the cursor. > */ > @@ -749,52 +739,21 @@ xfs_attr_list( > /* > * Initialize the output buffer. > */ > + memset(&context, 0, sizeof(context)); > context.dp = dp; > context.cursor = cursor; > - context.count = 0; > - context.dupcnt = 0; > context.resynch = 1; > context.flags = flags; > - context.seen_enough = 0; > - context.alist = (attrlist_t *)buffer; > - context.put_value = 0; > - > - if (flags & ATTR_KERNAMELS) { > - context.bufsize = bufsize; > - context.firstu = context.bufsize; > - if (flags & ATTR_KERNOVAL) > - context.put_listent = xfs_attr_kern_list_sizes; > - else > - context.put_listent = xfs_attr_kern_list; > - } else { > - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ > - context.firstu = context.bufsize; > - context.alist->al_count = 0; > - context.alist->al_more = 0; > - context.alist->al_offset[0] = context.bufsize; > - context.put_listent = xfs_attr_put_listent; > - } > - > - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) > - return EIO; > + context.alist = buffer; > + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ > + context.firstu = context.bufsize; > + context.put_listent = xfs_attr_put_listent; > > - xfs_ilock(dp, XFS_ILOCK_SHARED); > - xfs_attr_trace_l_c("syscall start", &context); > + alist = (struct attrlist *)context.alist; > + alist->al_offset[0] = context.bufsize; > > error = xfs_attr_list_int(&context); > - > - xfs_iunlock(dp, XFS_ILOCK_SHARED); > - xfs_attr_trace_l_c("syscall end", &context); > - > - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { > - /* must return negated buffer size or the error */ > - if (context.count < 0) > - error = XFS_ERROR(ERANGE); > - else > - error = -context.count; > - } else > - ASSERT(error >= 0); > - > + ASSERT(error >= 0); > return error; > } > > @@ -2357,12 +2316,7 @@ xfs_attr_trace_enter(int type, char *whe > (void *)((__psunsigned_t)context->bufsize), > (void *)((__psunsigned_t)context->count), > (void *)((__psunsigned_t)context->firstu), > - (void *)((__psunsigned_t) > - (((context->count > 0) && > - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) > - ? (ATTR_ENTRY(context->alist, > - context->count-1)->a_valuelen) > - : 0)), > + NULL, > (void *)((__psunsigned_t)context->dupcnt), > (void *)((__psunsigned_t)context->flags), > (void *)a13, (void *)a14, (void *)a15); > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-01 14:44:07.000000000 +0200 > @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att > * Namespace helper routines > *========================================================================*/ > > -STATIC_INLINE attrnames_t * > -xfs_attr_flags_namesp(int flags) > -{ > - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: > - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); > -} > - > /* > * If namespace bits don't match return 0. > * If all match then return 1. > @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int > return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); > } > > -/* > - * If namespace bits don't match and we don't have an override for it > - * then return 0. > - * If all match or are overridable then return 1. > - */ > -STATIC_INLINE int > -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) > -{ > - if (((arg_flags & ATTR_SECURE) == 0) != > - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && > - !(arg_flags & ATTR_KERNORMALS)) > - return 0; > - if (((arg_flags & ATTR_ROOT) == 0) != > - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && > - !(arg_flags & ATTR_KERNROOTLS)) > - return 0; > - return 1; > -} > - > > /*======================================================================== > * External routines when attribute fork size < XFS_LITINO(mp). > @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co > (XFS_ISRESET_CURSOR(cursor) && > (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { > for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { > - attrnames_t *namesp; > - > - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { > - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); > - continue; > - } > - namesp = xfs_attr_flags_namesp(sfe->flags); > error = context->put_listent(context, > - namesp, > + sfe->flags, > (char *)sfe->nameval, > (int)sfe->namelen, > (int)sfe->valuelen, > @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co > kmem_free(sbuf); > return XFS_ERROR(EFSCORRUPTED); > } > - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { > - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); > - continue; > - } > + > sbp->entno = i; > sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); > sbp->name = (char *)sfe->nameval; > @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co > * Loop putting entries into the user buffer. > */ > for ( ; i < nsbuf; i++, sbp++) { > - attrnames_t *namesp; > - > - namesp = xfs_attr_flags_namesp(sbp->flags); > - > if (cursor->hashval != sbp->hash) { > cursor->hashval = sbp->hash; > cursor->offset = 0; > } > error = context->put_listent(context, > - namesp, > + sbp->flags, > sbp->name, > sbp->namelen, > sbp->valuelen, > @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > */ > retval = 0; > for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { > - attrnames_t *namesp; > - > if (be32_to_cpu(entry->hashval) != cursor->hashval) { > cursor->hashval = be32_to_cpu(entry->hashval); > cursor->offset = 0; > @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > > if (entry->flags & XFS_ATTR_INCOMPLETE) > continue; /* skip incomplete entries */ > - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) > - continue; > - > - namesp = xfs_attr_flags_namesp(entry->flags); > > if (entry->flags & XFS_ATTR_LOCAL) { > xfs_attr_leaf_name_local_t *name_loc = > XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); > > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_loc->nameval, > (int)name_loc->namelen, > be16_to_cpu(name_loc->valuelen), > @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, > if (retval) > return retval; > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_rmt->name, > (int)name_rmt->namelen, > valuelen, > (char*)args.value); > kmem_free(args.value); > - } > - else { > + } else { > retval = context->put_listent(context, > - namesp, > + entry->flags, > (char *)name_rmt->name, > (int)name_rmt->namelen, > valuelen, > Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-01 14:44:07.000000000 +0200 > @@ -30,7 +30,6 @@ > > struct attrlist; > struct attrlist_cursor_kern; > -struct attrnames; > struct xfs_dabuf; > struct xfs_da_args; > struct xfs_da_state; > @@ -204,33 +203,6 @@ static inline int xfs_attr_leaf_entsize_ > return (((bsize) >> 1) + ((bsize) >> 2)); > } > > - > -/*======================================================================== > - * Structure used to pass context around among the routines. > - *========================================================================*/ > - > - > -struct xfs_attr_list_context; > - > -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, > - char *, int, int, char *); > - > -typedef struct xfs_attr_list_context { > - struct xfs_inode *dp; /* inode */ > - struct attrlist_cursor_kern *cursor; /* position in list */ > - struct attrlist *alist; /* output buffer */ > - int seen_enough; /* T/F: seen enough of list? */ > - int count; /* num used entries */ > - int dupcnt; /* count dup hashvals seen */ > - int bufsize; /* total buffer size */ > - int firstu; /* first used byte in buffer */ > - int flags; /* from VOP call */ > - int resynch; /* T/F: resynch with cursor */ > - int put_value; /* T/F: need value for listent */ > - put_listent_func_t put_listent; /* list output fmt function */ > - int index; /* index into output buffer */ > -} xfs_attr_list_context_t; > - > /* > * Used to keep a list of "remote value" extents when unlinking an inode. > */ > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-01 14:44:07.000000000 +0200 > @@ -17,7 +17,11 @@ > */ > > #include "xfs.h" > +#include "xfs_da_btree.h" > +#include "xfs_bmap_btree.h" > +#include "xfs_inode.h" > #include "xfs_attr.h" > +#include "xfs_attr_leaf.h" > #include "xfs_acl.h" > #include "xfs_vnodeops.h" > > @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, > return __xfs_xattr_set(inode, name, value, size, flags, 0); > } > > -struct attrnames attr_user = { > - .attr_name = "user.", > - .attr_namelen = sizeof("user.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_user_handler = { > .prefix = XATTR_USER_PREFIX, > .get = xfs_xattr_user_get, > @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod > return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); > } > > -struct attrnames attr_trusted = { > - .attr_name = "trusted.", > - .attr_namelen = sizeof("trusted.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_trusted_handler = { > .prefix = XATTR_TRUSTED_PREFIX, > .get = xfs_xattr_trusted_get, > @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode > return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); > } > > -struct attrnames attr_secure = { > - .attr_name = "security.", > - .attr_namelen = sizeof("security.") - 1, > -}; > - > static struct xattr_handler xfs_xattr_security_handler = { > .prefix = XATTR_SECURITY_PREFIX, > .get = xfs_xattr_secure_get, > @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers > NULL > }; > > +static unsigned int xfs_attr_prefix_len(int flags) > +{ > + if (flags & XFS_ATTR_SECURE) > + return sizeof("security"); > + else if (flags & XFS_ATTR_ROOT) > + return sizeof("trusted"); > + else > + return sizeof("user"); > +} > + > +static const char *xfs_attr_prefix(int flags) > +{ > + if (flags & XFS_ATTR_SECURE) > + return xfs_xattr_security_handler.prefix; > + else if (flags & XFS_ATTR_ROOT) > + return xfs_xattr_trusted_handler.prefix; > + else > + return xfs_xattr_user_handler.prefix; > +} > + > +static int > +xfs_attr_kern_list(struct xfs_attr_list_context *context, int flags, > + char *name, int namelen, int valuelen, char *value) > +{ > + unsigned int prefix_len = xfs_attr_prefix_len(flags); > + char *offset; > + int arraytop; > + > + ASSERT(context->count >= 0); > + > + /* > + * Only show root namespace entries if we are actually allowed to > + * see them. > + */ > + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) > + return 0; > + > + arraytop = context->count + prefix_len + namelen + 1; > + if (arraytop > context->firstu) { > + context->count = -1; /* insufficient space */ > + return 1; > + } > + offset = (char *)context->alist + context->count; > + strncpy(offset, xfs_attr_prefix(flags), prefix_len); > + offset += prefix_len; > + strncpy(offset, name, namelen); /* real name */ > + offset += namelen; > + *offset = '\0'; > + context->count += prefix_len + namelen + 1; > + return 0; > +} > + > +static int > +xfs_attr_kern_list_sizes(struct xfs_attr_list_context *context, int flags, > + char *name, int namelen, int valuelen, char *value) > +{ > + context->count += xfs_attr_prefix_len(flags) + namelen + 1; > + return 0; > +} > + > static int > list_one_attr(const char *name, const size_t len, void *data, > size_t size, ssize_t *result) > @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si > ssize_t > xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) > { > + struct xfs_attr_list_context context; > + struct attrlist_cursor_kern cursor = { 0 }; > struct inode *inode = dentry->d_inode; > - struct xfs_inode *ip = XFS_I(inode); > - attrlist_cursor_kern_t cursor = { 0 }; > - int error, xflags; > - ssize_t result; > - > - xflags = ATTR_KERNAMELS; > - if (!size) > - xflags |= ATTR_KERNOVAL; > - > - if (capable(CAP_SYS_ADMIN)) > - xflags |= ATTR_KERNFULLS; > - else > - xflags |= ATTR_KERNORMALS; > - > + int error; > > /* > * First read the regular on-disk attributes. > */ > - result = -xfs_attr_list(ip, data, size, xflags, &cursor); > - if (result < 0) > - return result; > + memset(&context, 0, sizeof(context)); > + context.dp = XFS_I(inode); > + context.cursor = &cursor; > + context.resynch = 1; > + context.alist = data; > + context.bufsize = size; > + context.firstu = context.bufsize; > + > + if (size) > + context.put_listent = xfs_attr_kern_list; > + else > + context.put_listent = xfs_attr_kern_list_sizes; > + > + xfs_attr_list_int(&context); > + if (context.count < 0) > + return -ERANGE; > > /* > * Then add the two synthetic ACL attributes. > @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_access(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_ACCESS, > strlen(POSIX_ACL_XATTR_ACCESS) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, > if (xfs_acl_vhasacl_default(inode)) { > error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, > strlen(POSIX_ACL_XATTR_DEFAULT) + 1, > - data, size, &result); > + data, size, &context.count); > if (error) > return error; > } > > - return result; > + return context.count; > } > Index: linux-2.6-xfs/fs/xfs/xfs_acl.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-01 14:44:07.000000000 +0200 > @@ -341,8 +341,7 @@ xfs_acl_iaccess( > > /* If the file has no ACL return -1. */ > rval = sizeof(xfs_acl_t); > - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, > - ATTR_ROOT | ATTR_KERNACCESS)) { > + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { > _ACL_FREE(acl); > return -1; > } > Index: linux-2.6-xfs/fs/xfs/xfs_attr.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-01 14:31:40.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-01 14:44:07.000000000 +0200 > @@ -18,9 +18,11 @@ > #ifndef __XFS_ATTR_H__ > #define __XFS_ATTR_H__ > > +struct xfs_inode; > +struct xfs_da_args; > +struct xfs_attr_list_context; > + > /* > - * xfs_attr.h > - * > * Large attribute lists are structured around Btrees where all the data > * elements are in the leaf nodes. Attribute names are hashed into an int, > * then that int is used as the index into the Btree. Since the hashval > @@ -35,17 +37,6 @@ > * External interfaces > *========================================================================*/ > > -struct cred; > -struct xfs_attr_list_context; > - > -typedef struct attrnames { > - char * attr_name; > - unsigned int attr_namelen; > -} attrnames_t; > - > -extern struct attrnames attr_user; > -extern struct attrnames attr_secure; > -extern struct attrnames attr_trusted; > > #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ > #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ > @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; > #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ > #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ > > -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ > #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ > #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ > -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ > - > -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ > -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ > -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) > > /* > * The maximum size (into the kernel or returned from the kernel) of an > @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { > > > /*======================================================================== > - * Function prototypes for the kernel. > + * Structure used to pass context around among the routines. > *========================================================================*/ > > -struct xfs_inode; > -struct attrlist_cursor_kern; > -struct xfs_da_args; > + > +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, > + char *, int, int, char *); > + > +typedef struct xfs_attr_list_context { > + struct xfs_inode *dp; /* inode */ > + struct attrlist_cursor_kern *cursor; /* position in list */ > + char *alist; /* output buffer */ > + int seen_enough; /* T/F: seen enough of list? */ > + int count; /* num used entries */ > + int dupcnt; /* count dup hashvals seen */ > + int bufsize; /* total buffer size */ > + int firstu; /* first used byte in buffer */ > + int flags; /* from VOP call */ > + int resynch; /* T/F: resynch with cursor */ > + int put_value; /* T/F: need value for listent */ > + put_listent_func_t put_listent; /* list output fmt function */ > + int index; /* index into output buffer */ > +} xfs_attr_list_context_t; > + > + > +/*======================================================================== > + * Function prototypes for the kernel. > + *========================================================================*/ > > /* > * Overall external interface routines. > */ > int xfs_attr_inactive(struct xfs_inode *dp); > - > -int xfs_attr_shortform_getvalue(struct xfs_da_args *); > int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); > int xfs_attr_rmtval_get(struct xfs_da_args *args); > +int xfs_attr_list_int(struct xfs_attr_list_context *); > > #endif /* __XFS_ATTR_H__ */ > From owner-xfs@oss.sgi.com Thu Jun 12 22:38:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 22:38:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5D5cKKj030781 for ; Thu, 12 Jun 2008 22:38:20 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay1.corp.sgi.com (Postfix) with ESMTP id C86598F80A5; Thu, 12 Jun 2008 22:39:12 -0700 (PDT) Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5D5cvjm1916646; Fri, 13 Jun 2008 15:39:01 +1000 (AEST) Message-ID: <48520704.8050903@melbourne.sgi.com> Date: Fri, 13 Jun 2008 15:35:00 +1000 From: Greg Banks Organization: File Serving Technologies ; Silicon Graphics Inc. User-Agent: Thunderbird 1.5.0.12 (X11/20060911) MIME-Version: 1.0 To: Eric Sandeen CC: markgw@sgi.com, Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> <4851EC2D.6010504@melbourne.sgi.com> In-Reply-To: <4851EC2D.6010504@melbourne.sgi.com> Content-Type: multipart/mixed; boundary="------------020704050307000508040701" X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16330 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gnb@melbourne.sgi.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------020704050307000508040701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Greg Banks wrote: > Mark Goodwin wrote: > >> Greg Banks wrote: >> >>> Eric Sandeen wrote: >>> >>>> 4070 29.1% are scripts (shell, perl, whatever) >>>> 6598 47.2% don't use any stat() family calls at all >>>> 1829 13.1% use 32-bit stat() family interfaces only >>>> 1312 9.4% use 64-bit stat64() family interfaces only >>>> 180 1.3% use both 32-bit and 64-bit stat() family interfaces >>>> >>>> >>> Ouch. That's over two thousand executables to patch, rebuild, and ship. >>> >>>> list of packages, sorted by the semi-lame "number of files in package >>>> which call a 32-bit stat variant" metric: >>>> >>>> http://sandeen.fedorapeople.org/stat32-ers >>>> >> struct dirent has an embedded ino_t too, so for completeness we should >> also >> be looking for readdir(), readdir64(), getdirentries(), >> getdirentries64(), etc. >> > Good point. Looking in the code, it seems the getdents common code in > glibc will fail with EOVERFLOW if the inode number gets truncated during > 64b-32b translation, just like the stat() family. Experiment confirms this behaviour, using a small wrapper program around opendir/readdir/closedir: heave:~/stat64/mnt # ../myls64 idx d_ino d_off d_type d_name --- ---------------- ----- ------ ------ 0 0000000000000080 4 0 . 1 0000000000000080 6 0 .. 2 0000000000000083 8 0 d0 3 0000000080000080 10 0 d1 4 0000000100000080 12 0 d2 5 0000000180000080 14 0 d3 6 0000000200000080 16 0 d4 7 0000000280000080 18 0 d5 8 0000000300000080 20 0 d6 9 0000000380000080 22 0 d7 10 0000000400000080 24 0 d8 11 0000000480000080 26 0 d9 12 0000000500000080 28 0 d10 13 0000000580000080 30 0 d11 14 0000000600000080 32 0 d12 15 0000000680000080 34 0 d13 16 0000000700000080 36 0 d14 17 0000000780000080 38 0 d15 18 0000000800000080 40 0 d16 19 0000000880000080 42 0 d17 20 0000000900000080 44 0 d18 21 0000000980000080 46 0 d19 22 0000000a00000080 48 0 d20 23 0000000a80000080 50 0 d21 24 0000000b00000080 52 0 d22 25 0000000b80000080 54 0 d23 26 0000000c00000080 56 0 d24 27 0000000c80000080 58 0 d25 28 0000000d00000080 60 0 d26 29 0000000d80000080 62 0 d27 30 0000000e00000080 64 0 d28 31 0000000e80000080 66 0 d29 32 0000000f00000080 68 0 d30 33 0000000f80000080 70 0 d31 34 0000001000080080 72 0 d32 35 0000001080000080 74 0 d33 36 0000001100000080 76 0 d34 37 0000001180000080 78 0 d35 38 0000001200000080 80 0 d36 39 0000001280000080 82 0 d37 40 0000001300000080 84 0 d38 41 0000001380000080 86 0 d39 42 0000001400000080 88 0 d40 43 0000001480000080 90 0 d41 44 0000001500000080 92 0 d42 45 0000001580000080 94 0 d43 46 0000001600000080 96 0 d44 47 0000001680000080 98 0 d45 48 0000001700000080 100 0 d46 49 0000001780000080 102 0 d47 50 0000001800000080 104 0 d48 51 0000001880000080 106 0 d49 52 0000001900000080 108 0 d50 53 0000001980000080 110 0 d51 54 0000001a00000080 112 0 d52 55 0000001a80000080 114 0 d53 56 0000001b00000080 116 0 d54 57 0000001b80000080 118 0 d55 58 0000001c00000080 120 0 d56 59 0000001c80000080 122 0 d57 60 0000001d00000080 124 0 d58 61 0000001d80000080 126 0 d59 62 0000001e00000080 128 0 d60 63 0000001e80000080 130 0 d61 64 0000001f00000080 132 0 d62 65 0000001f80000080 512 0 d63 heave:~/stat64/mnt # ../myls32 idx d_ino d_off d_type d_name --- ---------------- ----- ------ ------ 0 0000000000000080 4 0 . 1 0000000000000080 6 0 .. 2 0000000000000083 8 0 d0 3 0000000080000080 10 0 d1 .: Value too large for defined data type heave:~/stat64/mnt # strace -s1024 ../myls32 execve("../myls32", ["../myls32"], [/* 60 vars */]) = 0 [ Process PID=12640 runs in 32 bit mode. ] ... open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 ... write(1, "idx d_ino d_off d_type d_name\n", 41) = 41 write(1, "--- ---------------- ----- ------ ------\n", 41) = 41 getdents64(3, /* 66 entries */, 4096) = 1584 _llseek(3, 10, [10], SEEK_SET) = 0 write(1, " 0 0000000000000080 4 0 .\n", 36) = 36 write(1, " 1 0000000000000080 6 0 ..\n", 37) = 37 write(1, " 2 0000000000000083 8 0 d0\n", 37) = 37 write(1, " 3 0000000080000080 10 0 d1\n", 37) = 37 getdents64(3, /* 62 entries */, 4096) = 1488 ... write(4, ".: Value too large for defined data type\n", 41) = 41 ... close(3) = 0 exit_group(0) = ? Process 12640 detached I also confirmed that using readdir64() allows the 32b app to work. Of course, the glibc readdir() interface makes it extra hard for the caller to tell the difference between an error and a normal EOF. In both cases, NULL is returned. In the error case, errno is set. In the EOF case, errno is unchanged. In the success case, EOF is also unchanged. So to detect the error from readdir() the application writer needs to do something like: DIR *dir; struct direntry *de; ... errno = 0; while ((de = readdir(dir)) != NULL) { // handle entry errno = 0; } if (errno) { // handle error } Otherwise the directory traversal just finishes early with no error reported. I'll bet that's what all the apps do :-) > I'll need to improve > the scanning tool :-) Attached. -- Greg Banks, P.Engineer, SGI Australian Software Group. The cake is *not* a lie. I don't speak for SGI. --------------020704050307000508040701 Content-Type: application/x-perl; name="summarise-stat64-2.pl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="summarise-stat64-2.pl" #!/usr/bin/perl # # A Perl script for evaluating and summarising which executables in # the given directories depend on the old 32-bit stat() family APIs. # # Version 2: detects use of old 32-bit readdir() calls. # # Usage: summariese-stat64.pl directory [...] # # Copyright (c) 2007 Silicon Graphics, Inc. All Rights Reserved. # By Greg Banks # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; either version 2 of the License, or # (at your option) any later version. # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the # GNU General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA # use strict; use warnings; my @pathnames; # file and directories to read, from the commandline my @results; # array of { path, used32, used64, not_exe, no_perm } hashes my $verbose = 0; sub usage { print STDERR "Usage: summarise-stat64 [--verbose] file_or_directory...\n"; exit 1; } # Parse arguments foreach my $a (@ARGV) { if ($a eq '--verbose' || $a eq '-v') { $verbose++; } elsif ($a =~ m/^-/) { usage; } else { push(@pathnames,$a); } } usage unless scalar(@pathnames); # Function to scan a file sub scan_file { my ($path) = @_; my $fh; my %res = ( path => $path, used32 => 0, used64 => 0, not_exe => 0, no_perm => 0, ); open $fh,'-|', "nm -uD \"$path\" 2>&1" or return; while (<$fh>) { chomp; if (m/File format not recognized/) { $res{not_exe} = 1; } elsif (m/Permission denied/) { $res{no_perm} = 1; } elsif (m/^\s+U __(|l|f)xstat$/) { $res{used32}++; } elsif (m/^\s+U __(|l|f)xstat64$/) { $res{used64}++; } elsif (m/^\s+U readdir$/) { $res{used32}++; } elsif (m/^\s+U readdir64$/) { $res{used64}++; } } close $fh; push(@results, \%res); } # Function to scan a directory sub scan_directory { my ($path) = @_; my $dh; return unless opendir($dh,$path); while (my $d = readdir $dh) { next if ($d =~ m/^\./); print "$path/$d\n" if $verbose > 2; scan_path("$path/$d"); } closedir $dh; } # Function to scan something that might be a file or a directory sub scan_path { my ($path) = @_; print "scan_path($path)\n" if $verbose > 2; if ( -d $path ) { scan_directory($path); } elsif ( -e $path ) { scan_file($path); } } # Scan files and directories specified in the commandline foreach my $path (@pathnames) { scan_path($path); } my @status_strings = ( "cannot be read (permission denied)", "are scripts (shell, perl, whatever)", "don't use any stat() or readdir() family calls at all", "use 32-bit stat() or readdir() family interfaces only", "use 64-bit stat64() or readdir() family interfaces only", "use both 32-bit and 64-bit stat() or readdir() family interfaces", ); sub STATUS_UNCLEAN { return 3 }; sub STATUS_MIXED { return 5 }; sub STATUS_MAX { return 5 }; sub status { my ($r) = @_; return 0 if ($r->{no_perm}); return 1 if ($r->{not_exe}); return 2 + ($r->{used64} ? 2 : 0) + ($r->{used32} ? 1 : 0); } # Function to generate a summary sub emit_summary { my @summ; my $total = 0; foreach my $r (@results) { my $s = status($r); $summ[$s] = 0 unless defined $summ[$s]; $summ[$s]++; $total++; printf "%s %s\n", $r->{path}, $status_strings[$s] if ($verbose && ($s == STATUS_UNCLEAN || $s == STATUS_MIXED)); } foreach my $s (0..STATUS_MAX) { next unless defined $summ[$s]; printf "%7d %4.1f%% %s\n", $summ[$s], (100.0 * $summ[$s] / $total), $status_strings[$s]; } } # Function to dump raw data sub emit_raw { foreach my $r (@results) { print "$r->{used32} $r->{used64} $r->{not_exe} $r->{no_perm} $r->{path}\n"; } } emit_raw if $verbose > 1; emit_summary; --------------020704050307000508040701-- From owner-xfs@oss.sgi.com Thu Jun 12 23:04:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 12 Jun 2008 23:04:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D6427H031812 for ; Thu, 12 Jun 2008 23:04:08 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA14191 for ; Fri, 13 Jun 2008 16:04:58 +1000 Date: Fri, 13 Jun 2008 16:06:57 +1000 To: "xfs@oss.sgi.com" Subject: [REVIEW] Invalidate dentry on unlink/rmdir if using CI mode From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Message-ID: User-Agent: Opera Mail/9.24 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16331 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs Once of the interesting features of vfs_unlink/d_delete functionality is that if it's the only inode being referenced, it makes the dentry negative. CI doesn't work with negative dentries, so the following code invalidate the dentry in CI mode. -- --- a/fs/xfs/linux-2.6/xfs_iops.c +++ b/fs/xfs/linux-2.6/xfs_iops.c @@ -482,6 +482,8 @@ xfs_vn_unlink( if (likely(!error)) { xfs_validate_fields(dir); /* size needs update */ xfs_validate_fields(inode); + if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) + d_invalidate(dentry); } return -error; } @@ -538,6 +540,8 @@ xfs_vn_rmdir( if (likely(!error)) { xfs_validate_fields(inode); xfs_validate_fields(dir); + if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) + d_invalidate(dentry); } return -error; } From owner-xfs@oss.sgi.com Fri Jun 13 00:18:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 00:18:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D7IGlB005405 for ; Fri, 13 Jun 2008 00:18:17 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15442; Fri, 13 Jun 2008 17:19:09 +1000 Message-ID: <48522031.5060700@sgi.com> Date: Fri, 13 Jun 2008 17:22:25 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] fix extent corruption in xfs_iext_irec_compact_full() Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16332 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs This function is used to compact the indirect extent list by moving extents from one page to the previous to fill them up. After we move some extents to an earlier page we need to shuffle the remaining extents to the start of the page. The actual bug here is the second argument to memmove() needs to index past the extents, that were copied to the previous page, and move the remaining extents. For pages that are already full (ie ext_avail == 0) the compaction code has no net effect so don't do it. Thanks to Dave Chinner for pointing out the bug. Lachlan --- fs/xfs/xfs_inode.c_1.504 2008-06-05 16:46:33.000000000 +1000 +++ fs/xfs/xfs_inode.c 2008-06-05 17:39:20.000000000 +1000 @@ -4541,31 +4541,35 @@ xfs_iext_irec_compact_full( ep_next = erp_next->er_extbuf; while (erp_idx < nlists - 1) { ext_avail = XFS_LINEAR_EXTS - erp->er_extcount; - ext_diff = MIN(ext_avail, erp_next->er_extcount); - memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); - erp->er_extcount += ext_diff; - erp_next->er_extcount -= ext_diff; - /* Remove next page */ - if (erp_next->er_extcount == 0) { - /* - * Free page before removing extent record - * so er_extoffs don't get modified in - * xfs_iext_irec_remove. - */ - kmem_free(erp_next->er_extbuf); - erp_next->er_extbuf = NULL; - xfs_iext_irec_remove(ifp, erp_idx + 1); - erp = &ifp->if_u1.if_ext_irec[erp_idx]; - nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; - /* Update next page */ - } else { - /* Move rest of page up to become next new page */ - memmove(erp_next->er_extbuf, ep_next, - erp_next->er_extcount * sizeof(xfs_bmbt_rec_t)); - ep_next = erp_next->er_extbuf; - memset(&ep_next[erp_next->er_extcount], 0, - (XFS_LINEAR_EXTS - erp_next->er_extcount) * - sizeof(xfs_bmbt_rec_t)); + if (ext_avail) { + ext_diff = MIN(ext_avail, erp_next->er_extcount); + memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); + erp->er_extcount += ext_diff; + erp_next->er_extcount -= ext_diff; + /* Remove next page */ + if (erp_next->er_extcount == 0) { + /* + * Free page before removing extent record + * so er_extoffs don't get modified in + * xfs_iext_irec_remove. + */ + kmem_free(erp_next->er_extbuf); + erp_next->er_extbuf = NULL; + xfs_iext_irec_remove(ifp, erp_idx + 1); + erp = &ifp->if_u1.if_ext_irec[erp_idx]; + nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; + /* Update next page */ + } else { + /* Move rest of page up to become next new page */ + memmove(erp_next->er_extbuf, &ep_next[ext_diff], + erp_next->er_extcount * + sizeof(xfs_bmbt_rec_t)); + ep_next = erp_next->er_extbuf; + memset(&ep_next[erp_next->er_extcount], 0, + (XFS_LINEAR_EXTS - + erp_next->er_extcount) * + sizeof(xfs_bmbt_rec_t)); + } } if (erp->er_extcount == XFS_LINEAR_EXTS) { erp_idx++; From owner-xfs@oss.sgi.com Fri Jun 13 00:34:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 00:34:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_42, J_CHICKENPOX_43,J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46, J_CHICKENPOX_47,J_CHICKENPOX_48 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5D7Y48Q010792 for ; Fri, 13 Jun 2008 00:34:06 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA15705; Fri, 13 Jun 2008 17:34:56 +1000 Message-ID: <485223E4.6030404@sgi.com> Date: Fri, 13 Jun 2008 17:38:12 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] Prevent extent btree block allocation failures Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16333 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs When at ENOSPC conditions extent btree block allocations can fail and we have no error handling to undo partial btree operations. Prior to extent btree operations we reserve enough disk blocks somewhere in the filesystem to satisfy the operation but in some conditions we require the blocks to come from specific AGs and if those AGs are full the allocation fails. This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs for the space needed. Since we have reserved the space these allocations are now guaranteed to succeed. In order to search all AGs I had to revert a change made to xfs_alloc_vextent() that prevented a search from looking at AGs lower than the starting AG. This original change was made to prevent out of order AG locking when allocating multiple extents on data writeout but since we only allocate one extent at a time now this particular problem can't happen. Lachlan --- fs/xfs/xfs_alloc.c_1.193 2008-06-03 11:28:55.000000000 +1000 +++ fs/xfs/xfs_alloc.c 2008-06-02 18:40:47.000000000 +1000 @@ -2376,19 +2376,9 @@ xfs_alloc_vextent( if (args->agno == sagno && type == XFS_ALLOCTYPE_START_BNO) args->type = XFS_ALLOCTYPE_THIS_AG; - /* - * For the first allocation, we can try any AG to get - * space. However, if we already have allocated a - * block, we don't want to try AGs whose number is below - * sagno. Otherwise, we may end up with out-of-order - * locking of AGF, which might cause deadlock. - */ - if (++(args->agno) == mp->m_sb.sb_agcount) { - if (args->firstblock != NULLFSBLOCK) - args->agno = sagno; - else - args->agno = 0; - } + + if (++(args->agno) == mp->m_sb.sb_agcount) + args->agno = 0; /* * Reached the starting a.g., must either be done * or switch to non-trylock mode. --- fs/xfs/xfs_bmap.c_1.392 2008-06-03 12:20:14.000000000 +1000 +++ fs/xfs/xfs_bmap.c 2008-06-03 15:57:40.000000000 +1000 @@ -3445,16 +3452,10 @@ xfs_bmap_extents_to_btree( args.tp = tp; args.mp = mp; args.firstblock = *firstblock; - if (*firstblock == NULLFSBLOCK) { - args.type = XFS_ALLOCTYPE_START_BNO; + args.fsbno = *firstblock; + if (*firstblock == NULLFSBLOCK) args.fsbno = XFS_INO_TO_FSB(mp, ip->i_ino); - } else if (flist->xbf_low) { - args.type = XFS_ALLOCTYPE_START_BNO; - args.fsbno = *firstblock; - } else { - args.type = XFS_ALLOCTYPE_NEAR_BNO; - args.fsbno = *firstblock; - } + args.type = XFS_ALLOCTYPE_START_BNO; args.minlen = args.maxlen = args.prod = 1; args.total = args.minleft = args.alignment = args.mod = args.isfl = args.minalignslop = 0; @@ -3585,13 +3586,10 @@ xfs_bmap_local_to_extents( * Allocate a block. We know we need only one, since the * file currently fits in an inode. */ - if (*firstblock == NULLFSBLOCK) { + args.fsbno = *firstblock; + if (*firstblock == NULLFSBLOCK) args.fsbno = XFS_INO_TO_FSB(args.mp, ip->i_ino); - args.type = XFS_ALLOCTYPE_START_BNO; - } else { - args.fsbno = *firstblock; - args.type = XFS_ALLOCTYPE_NEAR_BNO; - } + args.type = XFS_ALLOCTYPE_START_BNO; args.total = total; args.mod = args.minleft = args.alignment = args.wasdel = args.isfl = args.minalignslop = 0; --- fs/xfs/xfs_bmap_btree.c_1.169 2008-06-03 11:28:56.000000000 +1000 +++ fs/xfs/xfs_bmap_btree.c 2008-06-06 14:48:14.000000000 +1000 @@ -1493,11 +1493,9 @@ xfs_bmbt_split( left = XFS_BUF_TO_BMBT_BLOCK(lbp); args.fsbno = cur->bc_private.b.firstblock; args.firstblock = args.fsbno; - if (args.fsbno == NULLFSBLOCK) { + if (args.fsbno == NULLFSBLOCK) args.fsbno = lbno; - args.type = XFS_ALLOCTYPE_START_BNO; - } else - args.type = XFS_ALLOCTYPE_NEAR_BNO; + args.type = XFS_ALLOCTYPE_START_BNO; args.mod = args.minleft = args.alignment = args.total = args.isfl = args.userdata = args.minalignslop = 0; args.minlen = args.maxlen = args.prod = 1; @@ -2253,9 +2251,8 @@ xfs_bmbt_newroot( } #endif args.fsbno = be64_to_cpu(*pp); - args.type = XFS_ALLOCTYPE_START_BNO; - } else - args.type = XFS_ALLOCTYPE_NEAR_BNO; + } + args.type = XFS_ALLOCTYPE_START_BNO; if ((error = xfs_alloc_vextent(&args))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; From owner-xfs@oss.sgi.com Fri Jun 13 03:25:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 03:25:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DAOxsW024926 for ; Fri, 13 Jun 2008 03:25:00 -0700 X-ASG-Debug-ID: 1213352755-2ab301c20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AAB5812C48FB; Fri, 13 Jun 2008 03:25:55 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id i8bCcioAKW8HWFeQ; Fri, 13 Jun 2008 03:25:55 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K76Tj-0002uZ-4G; Fri, 13 Jun 2008 10:25:55 +0000 Date: Fri, 13 Jun 2008 06:25:55 -0400 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [REVIEW] Invalidate dentry on unlink/rmdir if using CI mode Subject: Re: [REVIEW] Invalidate dentry on unlink/rmdir if using CI mode Message-ID: <20080613102555.GA1700@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213352756 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53173 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16334 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 04:06:57PM +1000, Barry Naujok wrote: > Once of the interesting features of vfs_unlink/d_delete functionality > is that if it's the only inode being referenced, it makes the dentry > negative. CI doesn't work with negative dentries, so the following code > invalidate the dentry in CI mode. Please add a comment like this patch description near the the calls you added, otherwise ok. From owner-xfs@oss.sgi.com Fri Jun 13 06:22:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 06:22:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DDM9pf008133 for ; Fri, 13 Jun 2008 06:22:10 -0700 X-ASG-Debug-ID: 1213363384-5a9c033c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 04EFFCAA4AD; Fri, 13 Jun 2008 06:23:05 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id WYRrxDGnCZh5E7Oh; Fri, 13 Jun 2008 06:23:05 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K79FA-0007Lo-Gy; Fri, 13 Jun 2008 13:23:04 +0000 Date: Fri, 13 Jun 2008 09:23:04 -0400 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] fix extent corruption in xfs_iext_irec_compact_full() Subject: Re: [PATCH] fix extent corruption in xfs_iext_irec_compact_full() Message-ID: <20080613132304.GA28190@infradead.org> References: <48522031.5060700@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48522031.5060700@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213363386 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.02 X-Barracuda-Spam-Status: No, SCORE=-1.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC1_TG070 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53185 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.00 BSF_SC1_TG070 Custom Rule TG070 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16335 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 05:22:25PM +1000, Lachlan McIlroy wrote: > This function is used to compact the indirect extent list by moving > extents from one page to the previous to fill them up. After we > move some extents to an earlier page we need to shuffle the remaining > extents to the start of the page. The actual bug here is the second > argument to memmove() needs to index past the extents, that were copied > to the previous page, and move the remaining extents. For pages that > are already full (ie ext_avail == 0) the compaction code has no net > effect so don't do it. > > Thanks to Dave Chinner for pointing out the bug. Looks good but this function needs a lot more comments. Below is a version of the patch with some more comments describing what's going on that I came up with when trying to understand what this patch does in detail: Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2008-06-13 14:58:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2008-06-13 15:15:25.000000000 +0200 @@ -4532,39 +4532,63 @@ xfs_iext_irec_compact_full( int nlists; /* number of irec's (ex lists) */ ASSERT(ifp->if_flags & XFS_IFEXTIREC); + nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; erp = ifp->if_u1.if_ext_irec; ep = &erp->er_extbuf[erp->er_extcount]; erp_next = erp + 1; ep_next = erp_next->er_extbuf; + while (erp_idx < nlists - 1) { + /* + * Check how many extent records are available in this irec. + * If there is none skip the whole exercise. + */ ext_avail = XFS_LINEAR_EXTS - erp->er_extcount; - ext_diff = MIN(ext_avail, erp_next->er_extcount); - memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); - erp->er_extcount += ext_diff; - erp_next->er_extcount -= ext_diff; - /* Remove next page */ - if (erp_next->er_extcount == 0) { + if (ext_avail) { + + /* + * Copy over as many as possible extent records into + * the previous page. + */ + ext_diff = MIN(ext_avail, erp_next->er_extcount); + memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); + erp->er_extcount += ext_diff; + erp_next->er_extcount -= ext_diff; + /* - * Free page before removing extent record - * so er_extoffs don't get modified in - * xfs_iext_irec_remove. + * If the next irec is empty now we can simply + * remove it. */ - kmem_free(erp_next->er_extbuf); - erp_next->er_extbuf = NULL; - xfs_iext_irec_remove(ifp, erp_idx + 1); - erp = &ifp->if_u1.if_ext_irec[erp_idx]; - nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; - /* Update next page */ - } else { - /* Move rest of page up to become next new page */ - memmove(erp_next->er_extbuf, ep_next, - erp_next->er_extcount * sizeof(xfs_bmbt_rec_t)); - ep_next = erp_next->er_extbuf; - memset(&ep_next[erp_next->er_extcount], 0, - (XFS_LINEAR_EXTS - erp_next->er_extcount) * - sizeof(xfs_bmbt_rec_t)); + if (erp_next->er_extcount == 0) { + /* + * Free page before removing extent record + * so er_extoffs don't get modified in + * xfs_iext_irec_remove. + */ + kmem_free(erp_next->er_extbuf); + erp_next->er_extbuf = NULL; + xfs_iext_irec_remove(ifp, erp_idx + 1); + erp = &ifp->if_u1.if_ext_irec[erp_idx]; + nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; + + /* + * If the next irec is not empty move up the content + * that has not been copied to the previous page to + * the beggining of this one. + */ + } else { + memmove(erp_next->er_extbuf, &ep_next[ext_diff], + erp_next->er_extcount * + sizeof(xfs_bmbt_rec_t)); + ep_next = erp_next->er_extbuf; + memset(&ep_next[erp_next->er_extcount], 0, + (XFS_LINEAR_EXTS - + erp_next->er_extcount) * + sizeof(xfs_bmbt_rec_t)); + } } + if (erp->er_extcount == XFS_LINEAR_EXTS) { erp_idx++; if (erp_idx < nlists) From owner-xfs@oss.sgi.com Fri Jun 13 06:27:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 06:27:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DDRaB9008956 for ; Fri, 13 Jun 2008 06:27:36 -0700 X-ASG-Debug-ID: 1213363712-5acf03af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C0ADD12C4D0E for ; Fri, 13 Jun 2008 06:28:32 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 9IlivrV2v4mJm3KP for ; Fri, 13 Jun 2008 06:28:32 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 319E498FF6F; Fri, 13 Jun 2008 08:28:31 -0500 (CDT) Message-ID: <485275FF.2050909@sandeen.net> Date: Fri, 13 Jun 2008 08:28:31 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Greg Banks CC: markgw@sgi.com, Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Filestreams (and 64bit inodes) Subject: Re: Filestreams (and 64bit inodes) References: <484B15A3.4030505@sauce.co.nz> <484CA425.3080606@sandeen.net> <484DDDB3.70000@sgi.com> <484F0998.90306@sauce.co.nz> <484F2CD7.9070506@sgi.com> <484F452A.8090909@sandeen.net> <48512A34.1020604@sandeen.net> <4851CD32.7080106@melbourne.sgi.com> <4851E774.2070401@sgi.com> <4851EC2D.6010504@melbourne.sgi.com> <48520704.8050903@melbourne.sgi.com> In-Reply-To: <48520704.8050903@melbourne.sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213363712 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53185 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16336 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Greg Banks wrote: >> I'll need to improve >> the scanning tool :-) > Attached. > I had done something similar, except: --- summarise-stat64-2.pl.orig 2008-06-13 08:26:07.000000000 -0500 +++ summarise-stat64-2.pl 2008-06-13 08:26:24.000000000 -0500 @@ -93,11 +93,11 @@ { $res{used64}++; } - elsif (m/^\s+U readdir$/) + elsif (m/^\s+U readdir(|_r)$/) { $res{used32}++; } - elsif (m/^\s+U readdir64$/) + elsif (m/^\s+U readdir64(|_r)$/) { $res{used64}++; } (lazily whitespace-mangled, sorry) A new scan with my slightly different version of the tool yielded: 447 readdir32 908 stat32 38 statfs32 where the nr. is the nr. of packages with that particular 32-bit call. -Eric From owner-xfs@oss.sgi.com Fri Jun 13 06:43:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 06:43:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DDhN21010733 for ; Fri, 13 Jun 2008 06:43:23 -0700 X-ASG-Debug-ID: 1213364659-7d7d02ef0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1F77EC28C5F; Fri, 13 Jun 2008 06:44:19 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id UT5voo0emdHf732j; Fri, 13 Jun 2008 06:44:19 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K79Zi-0001Gk-GZ; Fri, 13 Jun 2008 13:44:18 +0000 Date: Fri, 13 Jun 2008 09:44:18 -0400 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080613134418.GA31720@infradead.org> References: <485223E4.6030404@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485223E4.6030404@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213364660 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53187 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16337 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: > This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), > xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs > for the space needed. Since we have reserved the space these allocations > are now guaranteed to succeed. This looks good and makes lot of sense to me. Please also add a comment to enum xfs_alloctype in xfs_alloc.h about the danger of the allocation types that never go out of the AG when used inside transactions. > In order to search all AGs I had to revert > a change made to xfs_alloc_vextent() that prevented a search from looking > at AGs lower than the starting AG. This original change was made to prevent > out of order AG locking when allocating multiple extents on data writeout > but since we only allocate one extent at a time now this particular problem > can't happen. This one also makes sense, but I have a very bad gut feeling about it. There's nothing preventing the same deadlock scenario from coming back when people modify the highlevel data allocator again. We really need some sort of assert to trigger early in that case to not got a nasty hard to trigger deadlock. > + if (++(args->agno) == mp->m_sb.sb_agcount) and while we're at it this should be if (++args->agno == mp->m_sb.sb_agcount) From owner-xfs@oss.sgi.com Fri Jun 13 08:56:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 08:56:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DFuEMd025238 for ; Fri, 13 Jun 2008 08:56:14 -0700 X-ASG-Debug-ID: 1213372630-541e022b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B635A2280F9 for ; Fri, 13 Jun 2008 08:57:10 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id DQT5mBxmzjf55JcR for ; Fri, 13 Jun 2008 08:57:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG81Ukh5LG+u/2dsb2JhbACuJA X-IronPort-AV: E=Sophos;i="4.27,639,1204464600"; d="scan'208";a="125714267" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 14 Jun 2008 01:27:09 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K7BeG-0006hS-Ci; Sat, 14 Jun 2008 01:57:08 +1000 Date: Sat, 14 Jun 2008 01:57:08 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080613155708.GG3700@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485223E4.6030404@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213372631 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53196 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16338 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: > When at ENOSPC conditions extent btree block allocations can fail and we > have no error handling to undo partial btree operations. Prior to extent > btree operations we reserve enough disk blocks somewhere in the filesystem > to satisfy the operation but in some conditions we require the blocks to > come from specific AGs and if those AGs are full the allocation fails. > > This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), > xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs > for the space needed. Since we have reserved the space these allocations > are now guaranteed to succeed. Sure, but we didn't reserve space for potential btree splits in a second AG as a result of this. That needs to be reserved in the transaction as well, which will blow out transaction reservations substantially as we'll need to add another 2 full AGF btree splits to every transaction that modifies the bmap btree. > In order to search all AGs I had to revert > a change made to xfs_alloc_vextent() that prevented a search from looking > at AGs lower than the starting AG. This original change was made to prevent > out of order AG locking when allocating multiple extents on data writeout > but since we only allocate one extent at a time now this particular problem > can't happen. You missed the fact that the AGF of modified AGs is already held locked in the transaction, hence the locking order within the transaction is wrong. Also, if we modify the free list in an AG the fail an allocation (e.g. can't do an exact allocation), we'll have multiple dirty and locked AGFs in the one allocation. Hence we still can have locking order violations if you remove that check and therefore deadlocks. This is not the solution to the problem. As I suggested (back when you first floated this idea as a fix for the problem several weeks ago) I think the bug is that we are not taking into account the number of blocks required for a bmbt split when selecting an AG to allocate from. All we take into account is the blocks required for the extent to be allocated and nothing else. If we take the blocks for a bmbt split into account then we'll never try to allocate an extent in an AG that we can't also allocate all the blocks for the bmbt split in at the same time. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Fri Jun 13 09:23:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 13 Jun 2008 09:23:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5DGNn8t028219 for ; Fri, 13 Jun 2008 09:23:50 -0700 X-ASG-Debug-ID: 1213374282-52df003d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7734F17BFEF6; Fri, 13 Jun 2008 09:24:42 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 3736AYHp4w0fpmaT; Fri, 13 Jun 2008 09:24:42 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5DGOXNW023148 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 13 Jun 2008 18:24:34 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5DGOXZB023146; Fri, 13 Jun 2008 18:24:33 +0200 Date: Fri, 13 Jun 2008 18:24:33 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] simplify xfs_vn_listxattr Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr Message-ID: <20080613162433.GA23022@lst.de> References: <20080603114837.GB2703@lst.de> <4851F30C.4000108@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4851F30C.4000108@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213374284 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53198 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16339 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 02:09:48PM +1000, Timothy Shimmin wrote: > This appears to break xfstests/063 (EA xfsdump test). Indeed, I did some stupid last minute changes after running it through xfsqa. Here's the updated version which makes 063 happy again: Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-13 16:12:17.000000000 +0200 @@ -16,8 +16,6 @@ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#include - #include "xfs.h" #include "xfs_fs.h" #include "xfs_types.h" @@ -607,12 +605,20 @@ xfs_attr_remove( return xfs_attr_remove_int(dp, &xname, flags); } -STATIC int +int xfs_attr_list_int(xfs_attr_list_context_t *context) { int error; xfs_inode_t *dp = context->dp; + XFS_STATS_INC(xs_attr_list); + + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) + return EIO; + + xfs_ilock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall start", context); + /* * Decide on what work routines to call based on the inode size. */ @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ } else { error = xfs_attr_node_list(context); } + + xfs_iunlock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall end", context); + return error; } @@ -641,74 +651,50 @@ xfs_attr_list_int(xfs_attr_list_context_ */ /*ARGSUSED*/ STATIC int -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, char *name, int namelen, int valuelen, char *value) { + struct attrlist *alist = (struct attrlist *)context->alist; attrlist_ent_t *aep; int arraytop; ASSERT(!(context->flags & ATTR_KERNOVAL)); ASSERT(context->count >= 0); ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); - ASSERT(context->firstu >= sizeof(*context->alist)); + ASSERT(context->firstu >= sizeof(*alist)); ASSERT(context->firstu <= context->bufsize); - arraytop = sizeof(*context->alist) + - context->count * sizeof(context->alist->al_offset[0]); + /* + * Only list entries in the right namespace. + */ + if (((context->flags & ATTR_SECURE) == 0) != + ((flags & XFS_ATTR_SECURE) == 0)) + return 0; + if (((context->flags & ATTR_ROOT) == 0) != + ((flags & XFS_ATTR_ROOT) == 0)) + return 0; + + arraytop = sizeof(*alist) + + context->count * sizeof(alist->al_offset[0]); context->firstu -= ATTR_ENTSIZE(namelen); if (context->firstu < arraytop) { xfs_attr_trace_l_c("buffer full", context); - context->alist->al_more = 1; + alist->al_more = 1; context->seen_enough = 1; return 1; } - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); + aep = (attrlist_ent_t *)&context->alist[context->firstu]; aep->a_valuelen = valuelen; memcpy(aep->a_name, name, namelen); - aep->a_name[ namelen ] = 0; - context->alist->al_offset[ context->count++ ] = context->firstu; - context->alist->al_count = context->count; + aep->a_name[namelen] = 0; + alist->al_offset[context->count++] = context->firstu; + alist->al_count = context->count; xfs_attr_trace_l_c("add", context); return 0; } -STATIC int -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - char *offset; - int arraytop; - - ASSERT(context->count >= 0); - - arraytop = context->count + namesp->attr_namelen + namelen + 1; - if (arraytop > context->firstu) { - context->count = -1; /* insufficient space */ - return 1; - } - offset = (char *)context->alist + context->count; - strncpy(offset, namesp->attr_name, namesp->attr_namelen); - offset += namesp->attr_namelen; - strncpy(offset, name, namelen); /* real name */ - offset += namelen; - *offset = '\0'; - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - -/*ARGSUSED*/ -STATIC int -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - /* * Generate a list of extended attribute names and optionally * also value lengths. Positive return value follows the XFS @@ -725,10 +711,9 @@ xfs_attr_list( attrlist_cursor_kern_t *cursor) { xfs_attr_list_context_t context; + struct attrlist *alist; int error; - XFS_STATS_INC(xs_attr_list); - /* * Validate the cursor. */ @@ -749,52 +734,21 @@ xfs_attr_list( /* * Initialize the output buffer. */ + memset(&context, 0, sizeof(context)); context.dp = dp; context.cursor = cursor; - context.count = 0; - context.dupcnt = 0; context.resynch = 1; context.flags = flags; - context.seen_enough = 0; - context.alist = (attrlist_t *)buffer; - context.put_value = 0; - - if (flags & ATTR_KERNAMELS) { - context.bufsize = bufsize; - context.firstu = context.bufsize; - if (flags & ATTR_KERNOVAL) - context.put_listent = xfs_attr_kern_list_sizes; - else - context.put_listent = xfs_attr_kern_list; - } else { - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ - context.firstu = context.bufsize; - context.alist->al_count = 0; - context.alist->al_more = 0; - context.alist->al_offset[0] = context.bufsize; - context.put_listent = xfs_attr_put_listent; - } + context.alist = buffer; + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ + context.firstu = context.bufsize; + context.put_listent = xfs_attr_put_listent; - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) - return EIO; - - xfs_ilock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall start", &context); + alist = (struct attrlist *)context.alist; + alist->al_offset[0] = context.bufsize; error = xfs_attr_list_int(&context); - - xfs_iunlock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall end", &context); - - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { - /* must return negated buffer size or the error */ - if (context.count < 0) - error = XFS_ERROR(ERANGE); - else - error = -context.count; - } else - ASSERT(error >= 0); - + ASSERT(error >= 0); return error; } @@ -2357,12 +2311,7 @@ xfs_attr_trace_enter(int type, char *whe (void *)((__psunsigned_t)context->bufsize), (void *)((__psunsigned_t)context->count), (void *)((__psunsigned_t)context->firstu), - (void *)((__psunsigned_t) - (((context->count > 0) && - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) - ? (ATTR_ENTRY(context->alist, - context->count-1)->a_valuelen) - : 0)), + NULL, (void *)((__psunsigned_t)context->dupcnt), (void *)((__psunsigned_t)context->flags), (void *)a13, (void *)a14, (void *)a15); Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-13 16:07:40.000000000 +0200 @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att * Namespace helper routines *========================================================================*/ -STATIC_INLINE attrnames_t * -xfs_attr_flags_namesp(int flags) -{ - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); -} - /* * If namespace bits don't match return 0. * If all match then return 1. @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); } -/* - * If namespace bits don't match and we don't have an override for it - * then return 0. - * If all match or are overridable then return 1. - */ -STATIC_INLINE int -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) -{ - if (((arg_flags & ATTR_SECURE) == 0) != - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && - !(arg_flags & ATTR_KERNORMALS)) - return 0; - if (((arg_flags & ATTR_ROOT) == 0) != - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && - !(arg_flags & ATTR_KERNROOTLS)) - return 0; - return 1; -} - /*======================================================================== * External routines when attribute fork size < XFS_LITINO(mp). @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co (XFS_ISRESET_CURSOR(cursor) && (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { - attrnames_t *namesp; - - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } - namesp = xfs_attr_flags_namesp(sfe->flags); error = context->put_listent(context, - namesp, + sfe->flags, (char *)sfe->nameval, (int)sfe->namelen, (int)sfe->valuelen, @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co kmem_free(sbuf); return XFS_ERROR(EFSCORRUPTED); } - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } + sbp->entno = i; sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); sbp->name = (char *)sfe->nameval; @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co * Loop putting entries into the user buffer. */ for ( ; i < nsbuf; i++, sbp++) { - attrnames_t *namesp; - - namesp = xfs_attr_flags_namesp(sbp->flags); - if (cursor->hashval != sbp->hash) { cursor->hashval = sbp->hash; cursor->offset = 0; } error = context->put_listent(context, - namesp, + sbp->flags, sbp->name, sbp->namelen, sbp->valuelen, @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, */ retval = 0; for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { - attrnames_t *namesp; - if (be32_to_cpu(entry->hashval) != cursor->hashval) { cursor->hashval = be32_to_cpu(entry->hashval); cursor->offset = 0; @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (entry->flags & XFS_ATTR_INCOMPLETE) continue; /* skip incomplete entries */ - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) - continue; - - namesp = xfs_attr_flags_namesp(entry->flags); if (entry->flags & XFS_ATTR_LOCAL) { xfs_attr_leaf_name_local_t *name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_loc->nameval, (int)name_loc->namelen, be16_to_cpu(name_loc->valuelen), @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (retval) return retval; retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, (char*)args.value); kmem_free(args.value); - } - else { + } else { retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-13 16:07:40.000000000 +0200 @@ -30,7 +30,6 @@ struct attrlist; struct attrlist_cursor_kern; -struct attrnames; struct xfs_dabuf; struct xfs_da_args; struct xfs_da_state; @@ -204,33 +203,6 @@ static inline int xfs_attr_leaf_entsize_ return (((bsize) >> 1) + ((bsize) >> 2)); } - -/*======================================================================== - * Structure used to pass context around among the routines. - *========================================================================*/ - - -struct xfs_attr_list_context; - -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, - char *, int, int, char *); - -typedef struct xfs_attr_list_context { - struct xfs_inode *dp; /* inode */ - struct attrlist_cursor_kern *cursor; /* position in list */ - struct attrlist *alist; /* output buffer */ - int seen_enough; /* T/F: seen enough of list? */ - int count; /* num used entries */ - int dupcnt; /* count dup hashvals seen */ - int bufsize; /* total buffer size */ - int firstu; /* first used byte in buffer */ - int flags; /* from VOP call */ - int resynch; /* T/F: resynch with cursor */ - int put_value; /* T/F: need value for listent */ - put_listent_func_t put_listent; /* list output fmt function */ - int index; /* index into output buffer */ -} xfs_attr_list_context_t; - /* * Used to keep a list of "remote value" extents when unlinking an inode. */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-13 16:14:08.000000000 +0200 @@ -17,7 +17,11 @@ */ #include "xfs.h" +#include "xfs_da_btree.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" #include "xfs_attr.h" +#include "xfs_attr_leaf.h" #include "xfs_acl.h" #include "xfs_vnodeops.h" @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, return __xfs_xattr_set(inode, name, value, size, flags, 0); } -struct attrnames attr_user = { - .attr_name = "user.", - .attr_namelen = sizeof("user.") - 1, -}; - static struct xattr_handler xfs_xattr_user_handler = { .prefix = XATTR_USER_PREFIX, .get = xfs_xattr_user_get, @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); } -struct attrnames attr_trusted = { - .attr_name = "trusted.", - .attr_namelen = sizeof("trusted.") - 1, -}; - static struct xattr_handler xfs_xattr_trusted_handler = { .prefix = XATTR_TRUSTED_PREFIX, .get = xfs_xattr_trusted_get, @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); } -struct attrnames attr_secure = { - .attr_name = "security.", - .attr_namelen = sizeof("security.") - 1, -}; - static struct xattr_handler xfs_xattr_security_handler = { .prefix = XATTR_SECURITY_PREFIX, .get = xfs_xattr_secure_get, @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers NULL }; +static unsigned int xfs_xattr_prefix_len(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return sizeof("security"); + else if (flags & XFS_ATTR_ROOT) + return sizeof("trusted"); + else + return sizeof("user"); +} + +static const char *xfs_xattr_prefix(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return xfs_xattr_security_handler.prefix; + else if (flags & XFS_ATTR_ROOT) + return xfs_xattr_trusted_handler.prefix; + else + return xfs_xattr_user_handler.prefix; +} + +static int +xfs_xattr_put_listent(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + unsigned int prefix_len = xfs_xattr_prefix_len(flags); + char *offset; + int arraytop; + + ASSERT(context->count >= 0); + + /* + * Only show root namespace entries if we are actually allowed to + * see them. + */ + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) + return 0; + + arraytop = context->count + prefix_len + namelen + 1; + if (arraytop > context->firstu) { + context->count = -1; /* insufficient space */ + return 1; + } + offset = (char *)context->alist + context->count; + strncpy(offset, xfs_xattr_prefix(flags), prefix_len); + offset += prefix_len; + strncpy(offset, name, namelen); /* real name */ + offset += namelen; + *offset = '\0'; + context->count += prefix_len + namelen + 1; + return 0; +} + +static int +xfs_xattr_put_listent_sizes(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + context->count += xfs_xattr_prefix_len(flags) + namelen + 1; + return 0; +} + static int list_one_attr(const char *name, const size_t len, void *data, size_t size, ssize_t *result) @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si ssize_t xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) { + struct xfs_attr_list_context context; + struct attrlist_cursor_kern cursor = { 0 }; struct inode *inode = dentry->d_inode; - struct xfs_inode *ip = XFS_I(inode); - attrlist_cursor_kern_t cursor = { 0 }; - int error, xflags; - ssize_t result; - - xflags = ATTR_KERNAMELS; - if (!size) - xflags |= ATTR_KERNOVAL; - - if (capable(CAP_SYS_ADMIN)) - xflags |= ATTR_KERNFULLS; - else - xflags |= ATTR_KERNORMALS; - + int error; /* * First read the regular on-disk attributes. */ - result = -xfs_attr_list(ip, data, size, xflags, &cursor); - if (result < 0) - return result; + memset(&context, 0, sizeof(context)); + context.dp = XFS_I(inode); + context.cursor = &cursor; + context.resynch = 1; + context.alist = data; + context.bufsize = size; + context.firstu = context.bufsize; + + if (size) + context.put_listent = xfs_xattr_put_listent; + else + context.put_listent = xfs_xattr_put_listent_sizes; + + xfs_attr_list_int(&context); + if (context.count < 0) + return -ERANGE; /* * Then add the two synthetic ACL attributes. @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_access(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_default(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } - return result; + return context.count; } Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-13 16:07:40.000000000 +0200 @@ -341,8 +341,7 @@ xfs_acl_iaccess( /* If the file has no ACL return -1. */ rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, - ATTR_ROOT | ATTR_KERNACCESS)) { + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { _ACL_FREE(acl); return -1; } Index: linux-2.6-xfs/fs/xfs/xfs_attr.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-13 15:59:18.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-13 16:07:40.000000000 +0200 @@ -18,9 +18,11 @@ #ifndef __XFS_ATTR_H__ #define __XFS_ATTR_H__ +struct xfs_inode; +struct xfs_da_args; +struct xfs_attr_list_context; + /* - * xfs_attr.h - * * Large attribute lists are structured around Btrees where all the data * elements are in the leaf nodes. Attribute names are hashed into an int, * then that int is used as the index into the Btree. Since the hashval @@ -35,17 +37,6 @@ * External interfaces *========================================================================*/ -struct cred; -struct xfs_attr_list_context; - -typedef struct attrnames { - char * attr_name; - unsigned int attr_namelen; -} attrnames_t; - -extern struct attrnames attr_user; -extern struct attrnames attr_secure; -extern struct attrnames attr_trusted; #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ - -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) /* * The maximum size (into the kernel or returned from the kernel) of an @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { /*======================================================================== - * Function prototypes for the kernel. + * Structure used to pass context around among the routines. *========================================================================*/ -struct xfs_inode; -struct attrlist_cursor_kern; -struct xfs_da_args; + +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, + char *, int, int, char *); + +typedef struct xfs_attr_list_context { + struct xfs_inode *dp; /* inode */ + struct attrlist_cursor_kern *cursor; /* position in list */ + char *alist; /* output buffer */ + int seen_enough; /* T/F: seen enough of list? */ + int count; /* num used entries */ + int dupcnt; /* count dup hashvals seen */ + int bufsize; /* total buffer size */ + int firstu; /* first used byte in buffer */ + int flags; /* from VOP call */ + int resynch; /* T/F: resynch with cursor */ + int put_value; /* T/F: need value for listent */ + put_listent_func_t put_listent; /* list output fmt function */ + int index; /* index into output buffer */ +} xfs_attr_list_context_t; + + +/*======================================================================== + * Function prototypes for the kernel. + *========================================================================*/ /* * Overall external interface routines. */ int xfs_attr_inactive(struct xfs_inode *dp); - -int xfs_attr_shortform_getvalue(struct xfs_da_args *); int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); int xfs_attr_rmtval_get(struct xfs_da_args *args); +int xfs_attr_list_int(struct xfs_attr_list_context *); #endif /* __XFS_ATTR_H__ */ From owner-xfs@oss.sgi.com Sat Jun 14 01:23:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 01:23:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5E8NgAd008236 for ; Sat, 14 Jun 2008 01:23:42 -0700 X-ASG-Debug-ID: 1213431877-6385027c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fk-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5CB2322F5D9 for ; Sat, 14 Jun 2008 01:24:38 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.191]) by cuda.sgi.com with ESMTP id XipLm9DejwmluhGG for ; Sat, 14 Jun 2008 01:24:38 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 26so2841356fkx.4 for ; Sat, 14 Jun 2008 01:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=ZEL5Ikdbq6JBC389sUBbdsM3d9miERHvgZCN5o4iqYI=; b=tW75Mfau9uqF1UZTP5ZNH57KZwT4diM0YKppeyR1zTofxbWarEbYLuugYnZzgDy/IG upsYlLtxITf9sVT8aJzAVL1drWCpUW5chr2miZAlWLEWGZjKOQVhHIcl37lznFtJIZw1 F3WR3MlC4LNG/TmZSFEmheVNDjfT9Eh1KXk70= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=nJccs43EvnCOSsZp95IT+9pm/cf4qmpUxYTU24gP3HMky/GjrMFdQ9dTfDX9EvHzYI qQy+/WmmNHZELkNUFoOkiAnpOQAHX17iinkqSFDmYmMwq+vICAfZ+y15pxWbcWATc6p9 peinfuA64j5HV9oZn/EfWJEKb5H98GPdqiS6U= Received: by 10.78.148.15 with SMTP id v15mr1569426hud.44.1213431877152; Sat, 14 Jun 2008 01:24:37 -0700 (PDT) Received: by 10.78.142.16 with HTTP; Sat, 14 Jun 2008 01:24:37 -0700 (PDT) Message-ID: <74d4a1e10806140124s3ed8dfa6x7e5ca656fea0e06e@mail.gmail.com> Date: Sat, 14 Jun 2008 10:24:37 +0200 From: "Paul Guermonprez" To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair aborting ... dir2.c:2133 Subject: xfs_repair aborting ... dir2.c:2133 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 00ae1e19c4a2582b X-Barracuda-Connect: fk-out-0910.google.com[209.85.128.191] X-Barracuda-Start-Time: 1213431879 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3466 1.0000 -0.1647 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.16 X-Barracuda-Spam-Status: No, SCORE=-0.16 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53259 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16340 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@guermonprez.eu Precedence: bulk X-list: xfs hello, i have a xfs dump i want to repair under linux ubuntu. the partition was created by a storage system ss4000-e. if i use version 2.9.4, i have a segfault and version 2.9.8, the proces is aborted with message : xfs_repair: dir2.c:2133: process_dir2: Assertion `(ino != mp->m_sb.sb_rootino && ino != *parent) || (ino == mp->m_sb.sb_rootino && (ino == *parent || need_root_dotdot == 1))' failed. Aborted i also tried to comment this test, but it returns a segfault just as version 2.9.4. note : i already restored 3 xfs dumps from the same machine, and everything went in the lost+found, partly with no name, no directory, partly with a directory structure and filenames as expected. before xfs_repair, the mounted fs was empty, not even the ".." for root ! thanks, paul. From owner-xfs@oss.sgi.com Sat Jun 14 06:48:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 06:48:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EDmuTB003642 for ; Sat, 14 Jun 2008 06:48:56 -0700 X-ASG-Debug-ID: 1213451393-7d0301bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from vms044pub.verizon.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1D6AB2308C5 for ; Sat, 14 Jun 2008 06:49:53 -0700 (PDT) Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by cuda.sgi.com with ESMTP id v9Pt99S94NqZayk4 for ; Sat, 14 Jun 2008 06:49:53 -0700 (PDT) Received: from [192.168.1.106] ([71.170.186.252]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K2G00CO2H2TN1Y2@vms044.mailsrvcs.net> for xfs@oss.sgi.com; Sat, 14 Jun 2008 08:49:41 -0500 (CDT) Date: Sat, 14 Jun 2008 08:49:40 -0500 From: Dave Littell X-ASG-Orig-Subj: GRIO for Linux...please! Subject: GRIO for Linux...please! To: xfs@oss.sgi.com Message-id: <4853CC74.8040206@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Thunderbird 1.5 (X11/20060317) X-Barracuda-Connect: vms044pub.verizon.net[206.46.252.44] X-Barracuda-Start-Time: 1213451394 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5017 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53282 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16341 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: littelld@verizon.net Precedence: bulk X-list: xfs Hi all, Is there any plan (or even hope!) to have GRIO ported to Linux? XFS is an excellent filesystem in any case, but GRIO would put it head and shoulders above the competition. Thanks, Dave From owner-xfs@oss.sgi.com Sat Jun 14 07:05:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 07:05:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_40 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EE5jZg005094 for ; Sat, 14 Jun 2008 07:05:45 -0700 X-ASG-Debug-ID: 1213452397-018702c30000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from glqvs (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 72C6A231127; Sat, 14 Jun 2008 07:06:40 -0700 (PDT) Received: from glqvs (200-47-51-61.comsat.net.ar [200.47.51.61]) by cuda.sgi.com with ESMTP id HT5hSuSyys4srKtQ; Sat, 14 Jun 2008 07:06:40 -0700 (PDT) Message-ID: <1213452437.0756@eds.com> To: X-ASG-Orig-Subj: LuxuryWatches For Cheap, High Quality And Certified. LowPriceGuaranteed! fpgt he Subject: LuxuryWatches For Cheap, High Quality And Certified. LowPriceGuaranteed! fpgt he Date: Sat, 14 Jun 2008 07:07:17 -0700 In-Reply-To: X-Sender: From: "Annamaria Hertha" Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8bit X-Barracuda-Connect: 200-47-51-61.comsat.net.ar[200.47.51.61] X-Barracuda-Start-Time: 1213452402 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.10 X-Barracuda-Spam-Status: No, SCORE=0.10 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53282 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16342 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: herthahc@eds.com Precedence: bulk X-list: xfs From owner-xfs@oss.sgi.com Sat Jun 14 08:17:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 08:17:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_46, J_CHICKENPOX_65,J_CHICKENPOX_72,J_CHICKENPOX_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EFHCX4010836 for ; Sat, 14 Jun 2008 08:17:14 -0700 X-ASG-Debug-ID: 1213456686-5313007d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 07B6323183D; Sat, 14 Jun 2008 08:18:06 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id uudRLE18a48ZCxJb; Sat, 14 Jun 2008 08:18:06 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5EFHuNW011409 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 14 Jun 2008 17:17:56 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5EFHuwR011407; Sat, 14 Jun 2008 17:17:56 +0200 Date: Sat, 14 Jun 2008 17:17:56 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] simplify xfs_vn_listxattr Subject: Re: [PATCH 1/2] simplify xfs_vn_listxattr Message-ID: <20080614151756.GA11331@lst.de> References: <20080603114837.GB2703@lst.de> <4851F30C.4000108@sgi.com> <20080613162433.GA23022@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080613162433.GA23022@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213456688 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53286 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16343 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 13, 2008 at 06:24:33PM +0200, Christoph Hellwig wrote: > On Fri, Jun 13, 2008 at 02:09:48PM +1000, Timothy Shimmin wrote: > > This appears to break xfstests/063 (EA xfsdump test). > > Indeed, I did some stupid last minute changes after running it through > xfsqa. Here's the updated version which makes 063 happy again: Needs another update to fix a (harmless) warning: Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-14 17:14:30.000000000 +0200 @@ -16,8 +16,6 @@ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA */ -#include - #include "xfs.h" #include "xfs_fs.h" #include "xfs_types.h" @@ -607,12 +605,20 @@ xfs_attr_remove( return xfs_attr_remove_int(dp, &xname, flags); } -STATIC int +int xfs_attr_list_int(xfs_attr_list_context_t *context) { int error; xfs_inode_t *dp = context->dp; + XFS_STATS_INC(xs_attr_list); + + if (XFS_FORCED_SHUTDOWN(dp->i_mount)) + return EIO; + + xfs_ilock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall start", context); + /* * Decide on what work routines to call based on the inode size. */ @@ -625,6 +631,10 @@ xfs_attr_list_int(xfs_attr_list_context_ } else { error = xfs_attr_node_list(context); } + + xfs_iunlock(dp, XFS_ILOCK_SHARED); + xfs_attr_trace_l_c("syscall end", context); + return error; } @@ -641,74 +651,50 @@ xfs_attr_list_int(xfs_attr_list_context_ */ /*ARGSUSED*/ STATIC int -xfs_attr_put_listent(xfs_attr_list_context_t *context, attrnames_t *namesp, +xfs_attr_put_listent(xfs_attr_list_context_t *context, int flags, char *name, int namelen, int valuelen, char *value) { + struct attrlist *alist = (struct attrlist *)context->alist; attrlist_ent_t *aep; int arraytop; ASSERT(!(context->flags & ATTR_KERNOVAL)); ASSERT(context->count >= 0); ASSERT(context->count < (ATTR_MAX_VALUELEN/8)); - ASSERT(context->firstu >= sizeof(*context->alist)); + ASSERT(context->firstu >= sizeof(*alist)); ASSERT(context->firstu <= context->bufsize); - arraytop = sizeof(*context->alist) + - context->count * sizeof(context->alist->al_offset[0]); + /* + * Only list entries in the right namespace. + */ + if (((context->flags & ATTR_SECURE) == 0) != + ((flags & XFS_ATTR_SECURE) == 0)) + return 0; + if (((context->flags & ATTR_ROOT) == 0) != + ((flags & XFS_ATTR_ROOT) == 0)) + return 0; + + arraytop = sizeof(*alist) + + context->count * sizeof(alist->al_offset[0]); context->firstu -= ATTR_ENTSIZE(namelen); if (context->firstu < arraytop) { xfs_attr_trace_l_c("buffer full", context); - context->alist->al_more = 1; + alist->al_more = 1; context->seen_enough = 1; return 1; } - aep = (attrlist_ent_t *)&(((char *)context->alist)[ context->firstu ]); + aep = (attrlist_ent_t *)&context->alist[context->firstu]; aep->a_valuelen = valuelen; memcpy(aep->a_name, name, namelen); - aep->a_name[ namelen ] = 0; - context->alist->al_offset[ context->count++ ] = context->firstu; - context->alist->al_count = context->count; + aep->a_name[namelen] = 0; + alist->al_offset[context->count++] = context->firstu; + alist->al_count = context->count; xfs_attr_trace_l_c("add", context); return 0; } -STATIC int -xfs_attr_kern_list(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - char *offset; - int arraytop; - - ASSERT(context->count >= 0); - - arraytop = context->count + namesp->attr_namelen + namelen + 1; - if (arraytop > context->firstu) { - context->count = -1; /* insufficient space */ - return 1; - } - offset = (char *)context->alist + context->count; - strncpy(offset, namesp->attr_name, namesp->attr_namelen); - offset += namesp->attr_namelen; - strncpy(offset, name, namelen); /* real name */ - offset += namelen; - *offset = '\0'; - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - -/*ARGSUSED*/ -STATIC int -xfs_attr_kern_list_sizes(xfs_attr_list_context_t *context, attrnames_t *namesp, - char *name, int namelen, - int valuelen, char *value) -{ - context->count += namesp->attr_namelen + namelen + 1; - return 0; -} - /* * Generate a list of extended attribute names and optionally * also value lengths. Positive return value follows the XFS @@ -725,10 +711,9 @@ xfs_attr_list( attrlist_cursor_kern_t *cursor) { xfs_attr_list_context_t context; + struct attrlist *alist; int error; - XFS_STATS_INC(xs_attr_list); - /* * Validate the cursor. */ @@ -749,52 +734,23 @@ xfs_attr_list( /* * Initialize the output buffer. */ + memset(&context, 0, sizeof(context)); context.dp = dp; context.cursor = cursor; - context.count = 0; - context.dupcnt = 0; context.resynch = 1; context.flags = flags; - context.seen_enough = 0; - context.alist = (attrlist_t *)buffer; - context.put_value = 0; - - if (flags & ATTR_KERNAMELS) { - context.bufsize = bufsize; - context.firstu = context.bufsize; - if (flags & ATTR_KERNOVAL) - context.put_listent = xfs_attr_kern_list_sizes; - else - context.put_listent = xfs_attr_kern_list; - } else { - context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ - context.firstu = context.bufsize; - context.alist->al_count = 0; - context.alist->al_more = 0; - context.alist->al_offset[0] = context.bufsize; - context.put_listent = xfs_attr_put_listent; - } - - if (XFS_FORCED_SHUTDOWN(dp->i_mount)) - return EIO; - - xfs_ilock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall start", &context); + context.alist = buffer; + context.bufsize = (bufsize & ~(sizeof(int)-1)); /* align */ + context.firstu = context.bufsize; + context.put_listent = xfs_attr_put_listent; + + alist = (struct attrlist *)context.alist; + alist->al_count = 0; + alist->al_more = 0; + alist->al_offset[0] = context.bufsize; error = xfs_attr_list_int(&context); - - xfs_iunlock(dp, XFS_ILOCK_SHARED); - xfs_attr_trace_l_c("syscall end", &context); - - if (context.flags & (ATTR_KERNOVAL|ATTR_KERNAMELS)) { - /* must return negated buffer size or the error */ - if (context.count < 0) - error = XFS_ERROR(ERANGE); - else - error = -context.count; - } else - ASSERT(error >= 0); - + ASSERT(error >= 0); return error; } @@ -2357,12 +2313,7 @@ xfs_attr_trace_enter(int type, char *whe (void *)((__psunsigned_t)context->bufsize), (void *)((__psunsigned_t)context->count), (void *)((__psunsigned_t)context->firstu), - (void *)((__psunsigned_t) - (((context->count > 0) && - !(context->flags & (ATTR_KERNAMELS|ATTR_KERNOVAL))) - ? (ATTR_ENTRY(context->alist, - context->count-1)->a_valuelen) - : 0)), + NULL, (void *)((__psunsigned_t)context->dupcnt), (void *)((__psunsigned_t)context->flags), (void *)a13, (void *)a14, (void *)a15); Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.c 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.c 2008-06-14 17:14:30.000000000 +0200 @@ -94,13 +94,6 @@ STATIC int xfs_attr_leaf_entsize(xfs_att * Namespace helper routines *========================================================================*/ -STATIC_INLINE attrnames_t * -xfs_attr_flags_namesp(int flags) -{ - return ((flags & XFS_ATTR_SECURE) ? &attr_secure: - ((flags & XFS_ATTR_ROOT) ? &attr_trusted : &attr_user)); -} - /* * If namespace bits don't match return 0. * If all match then return 1. @@ -111,25 +104,6 @@ xfs_attr_namesp_match(int arg_flags, int return XFS_ATTR_NSP_ONDISK(ondisk_flags) == XFS_ATTR_NSP_ARGS_TO_ONDISK(arg_flags); } -/* - * If namespace bits don't match and we don't have an override for it - * then return 0. - * If all match or are overridable then return 1. - */ -STATIC_INLINE int -xfs_attr_namesp_match_overrides(int arg_flags, int ondisk_flags) -{ - if (((arg_flags & ATTR_SECURE) == 0) != - ((ondisk_flags & XFS_ATTR_SECURE) == 0) && - !(arg_flags & ATTR_KERNORMALS)) - return 0; - if (((arg_flags & ATTR_ROOT) == 0) != - ((ondisk_flags & XFS_ATTR_ROOT) == 0) && - !(arg_flags & ATTR_KERNROOTLS)) - return 0; - return 1; -} - /*======================================================================== * External routines when attribute fork size < XFS_LITINO(mp). @@ -626,15 +600,8 @@ xfs_attr_shortform_list(xfs_attr_list_co (XFS_ISRESET_CURSOR(cursor) && (dp->i_afp->if_bytes + sf->hdr.count * 16) < context->bufsize)) { for (i = 0, sfe = &sf->list[0]; i < sf->hdr.count; i++) { - attrnames_t *namesp; - - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } - namesp = xfs_attr_flags_namesp(sfe->flags); error = context->put_listent(context, - namesp, + sfe->flags, (char *)sfe->nameval, (int)sfe->namelen, (int)sfe->valuelen, @@ -681,10 +648,7 @@ xfs_attr_shortform_list(xfs_attr_list_co kmem_free(sbuf); return XFS_ERROR(EFSCORRUPTED); } - if (!xfs_attr_namesp_match_overrides(context->flags, sfe->flags)) { - sfe = XFS_ATTR_SF_NEXTENTRY(sfe); - continue; - } + sbp->entno = i; sbp->hash = xfs_da_hashname((char *)sfe->nameval, sfe->namelen); sbp->name = (char *)sfe->nameval; @@ -728,16 +692,12 @@ xfs_attr_shortform_list(xfs_attr_list_co * Loop putting entries into the user buffer. */ for ( ; i < nsbuf; i++, sbp++) { - attrnames_t *namesp; - - namesp = xfs_attr_flags_namesp(sbp->flags); - if (cursor->hashval != sbp->hash) { cursor->hashval = sbp->hash; cursor->offset = 0; } error = context->put_listent(context, - namesp, + sbp->flags, sbp->name, sbp->namelen, sbp->valuelen, @@ -2402,8 +2362,6 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, */ retval = 0; for ( ; (i < be16_to_cpu(leaf->hdr.count)); entry++, i++) { - attrnames_t *namesp; - if (be32_to_cpu(entry->hashval) != cursor->hashval) { cursor->hashval = be32_to_cpu(entry->hashval); cursor->offset = 0; @@ -2411,17 +2369,13 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (entry->flags & XFS_ATTR_INCOMPLETE) continue; /* skip incomplete entries */ - if (!xfs_attr_namesp_match_overrides(context->flags, entry->flags)) - continue; - - namesp = xfs_attr_flags_namesp(entry->flags); if (entry->flags & XFS_ATTR_LOCAL) { xfs_attr_leaf_name_local_t *name_loc = XFS_ATTR_LEAF_NAME_LOCAL(leaf, i); retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_loc->nameval, (int)name_loc->namelen, be16_to_cpu(name_loc->valuelen), @@ -2448,16 +2402,15 @@ xfs_attr_leaf_list_int(xfs_dabuf_t *bp, if (retval) return retval; retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, (char*)args.value); kmem_free(args.value); - } - else { + } else { retval = context->put_listent(context, - namesp, + entry->flags, (char *)name_rmt->name, (int)name_rmt->namelen, valuelen, Index: linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr_leaf.h 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr_leaf.h 2008-06-14 17:16:25.000000000 +0200 @@ -30,7 +30,7 @@ struct attrlist; struct attrlist_cursor_kern; -struct attrnames; +struct xfs_attr_list_context; struct xfs_dabuf; struct xfs_da_args; struct xfs_da_state; @@ -204,33 +204,6 @@ static inline int xfs_attr_leaf_entsize_ return (((bsize) >> 1) + ((bsize) >> 2)); } - -/*======================================================================== - * Structure used to pass context around among the routines. - *========================================================================*/ - - -struct xfs_attr_list_context; - -typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, struct attrnames *, - char *, int, int, char *); - -typedef struct xfs_attr_list_context { - struct xfs_inode *dp; /* inode */ - struct attrlist_cursor_kern *cursor; /* position in list */ - struct attrlist *alist; /* output buffer */ - int seen_enough; /* T/F: seen enough of list? */ - int count; /* num used entries */ - int dupcnt; /* count dup hashvals seen */ - int bufsize; /* total buffer size */ - int firstu; /* first used byte in buffer */ - int flags; /* from VOP call */ - int resynch; /* T/F: resynch with cursor */ - int put_value; /* T/F: need value for listent */ - put_listent_func_t put_listent; /* list output fmt function */ - int index; /* index into output buffer */ -} xfs_attr_list_context_t; - /* * Used to keep a list of "remote value" extents when unlinking an inode. */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-14 17:14:30.000000000 +0200 @@ -17,7 +17,11 @@ */ #include "xfs.h" +#include "xfs_da_btree.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" #include "xfs_attr.h" +#include "xfs_attr_leaf.h" #include "xfs_acl.h" #include "xfs_vnodeops.h" @@ -145,11 +149,6 @@ xfs_xattr_user_set(struct inode *inode, return __xfs_xattr_set(inode, name, value, size, flags, 0); } -struct attrnames attr_user = { - .attr_name = "user.", - .attr_namelen = sizeof("user.") - 1, -}; - static struct xattr_handler xfs_xattr_user_handler = { .prefix = XATTR_USER_PREFIX, .get = xfs_xattr_user_get, @@ -171,11 +170,6 @@ xfs_xattr_trusted_set(struct inode *inod return __xfs_xattr_set(inode, name, value, size, flags, ATTR_ROOT); } -struct attrnames attr_trusted = { - .attr_name = "trusted.", - .attr_namelen = sizeof("trusted.") - 1, -}; - static struct xattr_handler xfs_xattr_trusted_handler = { .prefix = XATTR_TRUSTED_PREFIX, .get = xfs_xattr_trusted_get, @@ -197,11 +191,6 @@ xfs_xattr_secure_set(struct inode *inode return __xfs_xattr_set(inode, name, value, size, flags, ATTR_SECURE); } -struct attrnames attr_secure = { - .attr_name = "security.", - .attr_namelen = sizeof("security.") - 1, -}; - static struct xattr_handler xfs_xattr_security_handler = { .prefix = XATTR_SECURITY_PREFIX, .get = xfs_xattr_secure_get, @@ -217,6 +206,66 @@ struct xattr_handler *xfs_xattr_handlers NULL }; +static unsigned int xfs_xattr_prefix_len(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return sizeof("security"); + else if (flags & XFS_ATTR_ROOT) + return sizeof("trusted"); + else + return sizeof("user"); +} + +static const char *xfs_xattr_prefix(int flags) +{ + if (flags & XFS_ATTR_SECURE) + return xfs_xattr_security_handler.prefix; + else if (flags & XFS_ATTR_ROOT) + return xfs_xattr_trusted_handler.prefix; + else + return xfs_xattr_user_handler.prefix; +} + +static int +xfs_xattr_put_listent(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + unsigned int prefix_len = xfs_xattr_prefix_len(flags); + char *offset; + int arraytop; + + ASSERT(context->count >= 0); + + /* + * Only show root namespace entries if we are actually allowed to + * see them. + */ + if ((flags & XFS_ATTR_ROOT) && !capable(CAP_SYS_ADMIN)) + return 0; + + arraytop = context->count + prefix_len + namelen + 1; + if (arraytop > context->firstu) { + context->count = -1; /* insufficient space */ + return 1; + } + offset = (char *)context->alist + context->count; + strncpy(offset, xfs_xattr_prefix(flags), prefix_len); + offset += prefix_len; + strncpy(offset, name, namelen); /* real name */ + offset += namelen; + *offset = '\0'; + context->count += prefix_len + namelen + 1; + return 0; +} + +static int +xfs_xattr_put_listent_sizes(struct xfs_attr_list_context *context, int flags, + char *name, int namelen, int valuelen, char *value) +{ + context->count += xfs_xattr_prefix_len(flags) + namelen + 1; + return 0; +} + static int list_one_attr(const char *name, const size_t len, void *data, size_t size, ssize_t *result) @@ -236,28 +285,30 @@ list_one_attr(const char *name, const si ssize_t xfs_vn_listxattr(struct dentry *dentry, char *data, size_t size) { + struct xfs_attr_list_context context; + struct attrlist_cursor_kern cursor = { 0 }; struct inode *inode = dentry->d_inode; - struct xfs_inode *ip = XFS_I(inode); - attrlist_cursor_kern_t cursor = { 0 }; - int error, xflags; - ssize_t result; - - xflags = ATTR_KERNAMELS; - if (!size) - xflags |= ATTR_KERNOVAL; - - if (capable(CAP_SYS_ADMIN)) - xflags |= ATTR_KERNFULLS; - else - xflags |= ATTR_KERNORMALS; - + int error; /* * First read the regular on-disk attributes. */ - result = -xfs_attr_list(ip, data, size, xflags, &cursor); - if (result < 0) - return result; + memset(&context, 0, sizeof(context)); + context.dp = XFS_I(inode); + context.cursor = &cursor; + context.resynch = 1; + context.alist = data; + context.bufsize = size; + context.firstu = context.bufsize; + + if (size) + context.put_listent = xfs_xattr_put_listent; + else + context.put_listent = xfs_xattr_put_listent_sizes; + + xfs_attr_list_int(&context); + if (context.count < 0) + return -ERANGE; /* * Then add the two synthetic ACL attributes. @@ -265,7 +316,7 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_access(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } @@ -273,10 +324,10 @@ xfs_vn_listxattr(struct dentry *dentry, if (xfs_acl_vhasacl_default(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, - data, size, &result); + data, size, &context.count); if (error) return error; } - return result; + return context.count; } Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-06-14 17:14:30.000000000 +0200 @@ -341,8 +341,7 @@ xfs_acl_iaccess( /* If the file has no ACL return -1. */ rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, - ATTR_ROOT | ATTR_KERNACCESS)) { + if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { _ACL_FREE(acl); return -1; } Index: linux-2.6-xfs/fs/xfs/xfs_attr.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-06-14 17:12:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-06-14 17:14:30.000000000 +0200 @@ -18,9 +18,11 @@ #ifndef __XFS_ATTR_H__ #define __XFS_ATTR_H__ +struct xfs_inode; +struct xfs_da_args; +struct xfs_attr_list_context; + /* - * xfs_attr.h - * * Large attribute lists are structured around Btrees where all the data * elements are in the leaf nodes. Attribute names are hashed into an int, * then that int is used as the index into the Btree. Since the hashval @@ -35,17 +37,6 @@ * External interfaces *========================================================================*/ -struct cred; -struct xfs_attr_list_context; - -typedef struct attrnames { - char * attr_name; - unsigned int attr_namelen; -} attrnames_t; - -extern struct attrnames attr_user; -extern struct attrnames attr_secure; -extern struct attrnames attr_trusted; #define ATTR_DONTFOLLOW 0x0001 /* -- unused, from IRIX -- */ #define ATTR_ROOT 0x0002 /* use attrs in root (trusted) namespace */ @@ -54,14 +45,8 @@ extern struct attrnames attr_trusted; #define ATTR_CREATE 0x0010 /* pure create: fail if attr already exists */ #define ATTR_REPLACE 0x0020 /* pure set: fail if attr does not exist */ -#define ATTR_KERNACCESS 0x0400 /* [kernel] iaccess, inode held io-locked */ #define ATTR_KERNOTIME 0x1000 /* [kernel] don't update inode timestamps */ #define ATTR_KERNOVAL 0x2000 /* [kernel] get attr size only, not value */ -#define ATTR_KERNAMELS 0x4000 /* [kernel] list attr names (simple list) */ - -#define ATTR_KERNORMALS 0x0800 /* [kernel] normal attr list: user+secure */ -#define ATTR_KERNROOTLS 0x8000 /* [kernel] include root in the attr list */ -#define ATTR_KERNFULLS (ATTR_KERNORMALS|ATTR_KERNROOTLS) /* * The maximum size (into the kernel or returned from the kernel) of an @@ -113,20 +98,40 @@ typedef struct attrlist_cursor_kern { /*======================================================================== - * Function prototypes for the kernel. + * Structure used to pass context around among the routines. *========================================================================*/ -struct xfs_inode; -struct attrlist_cursor_kern; -struct xfs_da_args; + +typedef int (*put_listent_func_t)(struct xfs_attr_list_context *, int, + char *, int, int, char *); + +typedef struct xfs_attr_list_context { + struct xfs_inode *dp; /* inode */ + struct attrlist_cursor_kern *cursor; /* position in list */ + char *alist; /* output buffer */ + int seen_enough; /* T/F: seen enough of list? */ + int count; /* num used entries */ + int dupcnt; /* count dup hashvals seen */ + int bufsize; /* total buffer size */ + int firstu; /* first used byte in buffer */ + int flags; /* from VOP call */ + int resynch; /* T/F: resynch with cursor */ + int put_value; /* T/F: need value for listent */ + put_listent_func_t put_listent; /* list output fmt function */ + int index; /* index into output buffer */ +} xfs_attr_list_context_t; + + +/*======================================================================== + * Function prototypes for the kernel. + *========================================================================*/ /* * Overall external interface routines. */ int xfs_attr_inactive(struct xfs_inode *dp); - -int xfs_attr_shortform_getvalue(struct xfs_da_args *); int xfs_attr_fetch(struct xfs_inode *, struct xfs_name *, char *, int *, int); int xfs_attr_rmtval_get(struct xfs_da_args *args); +int xfs_attr_list_int(struct xfs_attr_list_context *); #endif /* __XFS_ATTR_H__ */ From owner-xfs@oss.sgi.com Sat Jun 14 09:00:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:00:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_66,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EG0h1r018082 for ; Sat, 14 Jun 2008 09:00:44 -0700 X-ASG-Debug-ID: 1213459296-4161028d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4230F17C57F8 for ; Sat, 14 Jun 2008 09:01:37 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id nNPSFkytZew5W8OG for ; Sat, 14 Jun 2008 09:01:37 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5EG1RNW015501 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 14 Jun 2008 18:01:27 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5EG1RAq015499 for xfs@oss.sgi.com; Sat, 14 Jun 2008 18:01:27 +0200 Date: Sat, 14 Jun 2008 18:01:27 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] use generic posix ACL code, enable ACL caching Subject: [PATCH] use generic posix ACL code, enable ACL caching Message-ID: <20080614160127.GA15404@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213459298 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53288 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16344 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Switch XFS to use the generic ACL code and enable caching the ACL values in the XFS inode. Compared to the last post various bugs have been fixed and a locking strategy has been designed and implemented. This now passes XFSQA. You'll need my various attr-related patches applies before this one. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c 2008-06-14 15:53:35.000000000 +0200 @@ -0,0 +1,517 @@ +/* + * Copyright (C) 2008 Christoph Hellwig. + * Released under GPL v2. + */ +#include "xfs.h" +#include "xfs_acl.h" +#include "xfs_attr.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" +#include "xfs_vnodeops.h" +#include +#include + + +#define XFS_ACL_NOT_CACHED ((void *)-1) + +/* + * Locking scheme: + * - all ACL updates are protected by inode->i_mutex, which is taken before + * calling into this file. + * - access and updates to the ip->i_acl and ip->i_default_acl pointers are + * protected by inode->i_lock. + */ + +static struct posix_acl * +xfs_acl_from_disk(struct xfs_acl *aclp) +{ + struct posix_acl_entry *acl_e; + struct posix_acl *acl; + struct xfs_acl_entry *ace; + int count, i; + + count = be32_to_cpu(aclp->acl_cnt); + + acl = posix_acl_alloc(count, GFP_KERNEL); + if (!acl) + return ERR_PTR(-ENOMEM); + + for (i = 0; i < count; i++) { + acl_e = &acl->a_entries[i]; + ace = &aclp->acl_entry[i]; + + /* + * The tag is 32 bits on disk and 16 bits in core. + * + * Because every access to it goes through the core + * format first this is not a problem. + */ + acl_e->e_tag = be32_to_cpu(ace->ae_tag); + acl_e->e_perm = be16_to_cpu(ace->ae_perm); + + switch (acl_e->e_tag) { + case ACL_USER: + case ACL_GROUP: + acl_e->e_id = be32_to_cpu(ace->ae_id); + break; + case ACL_USER_OBJ: + case ACL_GROUP_OBJ: + case ACL_MASK: + case ACL_OTHER: + acl_e->e_id = ACL_UNDEFINED_ID; + break; + default: + goto fail; + } + } + return acl; + +fail: + posix_acl_release(acl); + return ERR_PTR(-EINVAL); +} + +static void +xfs_acl_to_disk(struct xfs_acl *aclp, const struct posix_acl *acl) +{ + const struct posix_acl_entry *acl_e; + struct xfs_acl_entry *ace; + int i; + + aclp->acl_cnt = cpu_to_be32(acl->a_count); + for (i = 0; i < acl->a_count; i++) { + ace = &aclp->acl_entry[i]; + acl_e = &acl->a_entries[i]; + + ace->ae_tag = cpu_to_be32(acl_e->e_tag); + ace->ae_id = cpu_to_be32(acl_e->e_id); + ace->ae_perm = cpu_to_be16(acl_e->e_perm); + } +} + +/* + * Update the cached ACL pointer in the inode. + * + * Because we don't hold any locks while reading/writing the attribute + * from/to disk another thread could have raced and updated the cached + * ACL value before us. In that case we release the previous cached value + * and update it with our new value. + */ +static void +xfs_update_cached_acl(struct inode *inode, struct posix_acl **p_acl, + struct posix_acl *acl) +{ + spin_lock(&inode->i_lock); + if (*p_acl && *p_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(*p_acl); + *p_acl = posix_acl_dup(acl); + spin_unlock(&inode->i_lock); +} + +struct posix_acl * +xfs_get_acl(struct inode *inode, int type) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl *acl = NULL, **p_acl; + struct xfs_acl *xfs_acl; + int len = sizeof(struct xfs_acl); + char *ea_name; + int error; + + switch (type) { + case ACL_TYPE_ACCESS: + ea_name = SGI_ACL_FILE; + p_acl = &ip->i_acl; + break; + case ACL_TYPE_DEFAULT: + ea_name = SGI_ACL_DEFAULT; + p_acl = &ip->i_default_acl; + break; + default: + return ERR_PTR(-EINVAL); + } + + spin_lock(&inode->i_lock); + if (*p_acl != XFS_ACL_NOT_CACHED) + acl = posix_acl_dup(*p_acl); + spin_unlock(&inode->i_lock); + + /* + * If we have a cached ACLs value just return it, not need to + * go out to the disk. + */ + if (acl) + return acl; + + xfs_acl = kzalloc(sizeof(struct xfs_acl), GFP_KERNEL); + if (!xfs_acl) + return ERR_PTR(-ENOMEM); + + error = -xfs_attr_get(ip, ea_name, (char *)xfs_acl, &len, ATTR_ROOT); + if (error) { + /* + * If the attribute doesn't exist make sure we have a negative + * cache entry, for any other error assume it is transient and + * leave the cache entry as XFS_ACL_NOT_CACHED. + */ + if (error == -ENOATTR) { + acl = NULL; + goto out_update_cache; + } + goto out; + } + + acl = xfs_acl_from_disk(xfs_acl); + if (IS_ERR(acl)) + goto out; + + out_update_cache: + xfs_update_cached_acl(inode, p_acl, acl); + out: + kfree(xfs_acl); + return acl; +} + +static int +xfs_set_acl(struct inode *inode, int type, struct posix_acl *acl) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl **p_acl; + char *ea_name; + int error; + + if (S_ISLNK(inode->i_mode)) + return -EOPNOTSUPP; + + switch (type) { + case ACL_TYPE_ACCESS: + ea_name = SGI_ACL_FILE; + p_acl = &ip->i_acl; + break; + case ACL_TYPE_DEFAULT: + if (!S_ISDIR(inode->i_mode)) + return acl ? -EACCES : 0; + ea_name = SGI_ACL_DEFAULT; + p_acl = &ip->i_default_acl; + break; + default: + return -EINVAL; + } + + if (acl) { + struct xfs_acl *xfs_acl; + int len; + + xfs_acl = kzalloc(sizeof(struct xfs_acl), GFP_KERNEL); + if (!xfs_acl) + return -ENOMEM; + + xfs_acl_to_disk(xfs_acl, acl); + len = sizeof(struct xfs_acl) - + (sizeof(struct xfs_acl_entry) * + (XFS_ACL_MAX_ENTRIES - acl->a_count)); + + error = -xfs_attr_set(ip, ea_name, (char *)xfs_acl, + len, ATTR_ROOT); + + kfree(xfs_acl); + } else { + /* + * A NULL ACL argument means we want to remove the ACL. + */ + error = -xfs_attr_remove(ip, ea_name, ATTR_ROOT); + + /* + * If the attribute didn't exist to start with that's fine. + */ + if (error == -ENOATTR) + error = 0; + } + + if (!error) + xfs_update_cached_acl(inode, p_acl, acl); + return error; +} + +static int +xfs_check_acl(struct inode *inode, int mask) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl *acl; + int error = -EAGAIN; + + xfs_itrace_entry(ip); + + /* + * If there is no attribute fork no ACL exists on this inode and + * we can skip the whole exercise. + */ + if (!XFS_IFORK_Q(ip)) + return -EAGAIN; + + acl = xfs_get_acl(inode, ACL_TYPE_ACCESS); + if (IS_ERR(acl)) + return PTR_ERR(acl); + if (acl) { + error = posix_acl_permission(inode, acl, mask); + posix_acl_release(acl); + } + + return error; +} + +int +xfs_vn_permission(struct inode *inode, int mask, struct nameidata *nd) +{ + return generic_permission(inode, mask, xfs_check_acl); +} + +static int +xfs_set_mode(struct inode *inode, mode_t mode) +{ + int error = 0; + + if (mode != inode->i_mode) { + struct bhv_vattr va; + + va.va_mask = XFS_AT_MODE; + va.va_mode = mode; + + error = -xfs_setattr(XFS_I(inode), &va, 0, sys_cred); + inode->i_mode = mode; + } + + return error; +} + +static int +xfs_acl_exists(struct inode *inode, char *name) +{ + int len = sizeof(struct xfs_acl); + + return (xfs_attr_get(XFS_I(inode), name, NULL, &len, + ATTR_ROOT|ATTR_KERNOVAL) == 0); +} + +int +posix_acl_access_exists(struct inode *inode) +{ + return xfs_acl_exists(inode, SGI_ACL_FILE); +} + +int +posix_acl_default_exists(struct inode *inode) +{ + if (!S_ISDIR(inode->i_mode)) + return 0; + return xfs_acl_exists(inode, SGI_ACL_DEFAULT); +} + +/* + * No need for i_mutex because the inode is not yet exposed to the VFS. + */ +int +xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl) +{ + struct posix_acl *clone; + mode_t mode; + int error = 0, inherit = 0; + + if (S_ISDIR(inode->i_mode)) { + error = xfs_set_acl(inode, ACL_TYPE_DEFAULT, default_acl); + if (error) + return error; + } + + clone = posix_acl_clone(default_acl, GFP_KERNEL); + if (!clone) + return -ENOMEM; + + mode = inode->i_mode; + error = posix_acl_create_masq(clone, &mode); + if (error < 0) + goto out_release_clone; + + /* + * If posix_acl_create_masq returns a positive value we need to + * inherit a permission that can't be represented using the Unix + * mode bits and we actually need to set an ACL. + */ + if (error > 0) + inherit = 1; + + error = xfs_set_mode(inode, mode); + if (error) + goto out_release_clone; + + if (inherit) + error = xfs_set_acl(inode, ACL_TYPE_ACCESS, clone); + + out_release_clone: + posix_acl_release(clone); + return error; +} + +int +xfs_acl_chmod(struct inode *inode) +{ + struct posix_acl *acl, *clone; + int error; + + if (S_ISLNK(inode->i_mode)) + return -EOPNOTSUPP; + + acl = xfs_get_acl(inode, ACL_TYPE_ACCESS); + if (IS_ERR(acl) || !acl) + return PTR_ERR(acl); + + clone = posix_acl_clone(acl, GFP_KERNEL); + posix_acl_release(acl); + if (!clone) + return -ENOMEM; + + error = posix_acl_chmod_masq(clone, inode->i_mode); + if (!error) + error = xfs_set_acl(inode, ACL_TYPE_ACCESS, clone); + + posix_acl_release(clone); + return error; +} + +void +xfs_inode_init_acls(struct xfs_inode *ip) +{ + /* + * No need for locking, inode is not live yet. + */ + ip->i_acl = XFS_ACL_NOT_CACHED; + ip->i_default_acl = XFS_ACL_NOT_CACHED; +} + +void +xfs_inode_clear_acls(struct xfs_inode *ip) +{ + /* + * No need for locking here, the inode is not live anymore + * and just about to be freed. + */ + if (ip->i_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(ip->i_acl); + if (ip->i_default_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(ip->i_default_acl); +} + + +/* + * System xattr handlers. + * + * Currently Posix ACLs are the only system namespace extended attribute + * handlers supported by XFS, so we just implement the handlers here. + * If we ever support other system extended attributes this will need + * some refactoring. + */ + +static int +xfs_decode_acl(const char *name) +{ + if (strcmp(name, "posix_acl_access") == 0) + return ACL_TYPE_ACCESS; + else if (strcmp(name, "posix_acl_default") == 0) + return ACL_TYPE_DEFAULT; + return -EINVAL; +} + +static int +xfs_xattr_system_get(struct inode *inode, const char *name, + void *value, size_t size) +{ + struct posix_acl *acl; + int type, error; + + type = xfs_decode_acl(name); + if (type < 0) + return type; + + acl = xfs_get_acl(inode, type); + if (IS_ERR(acl)) + return PTR_ERR(acl); + if (acl == NULL) + return -ENODATA; + + error = posix_acl_to_xattr(acl, value, size); + posix_acl_release(acl); + + return error; +} + +static int +xfs_xattr_system_set(struct inode *inode, const char *name, + const void *value, size_t size, int flags) +{ + struct posix_acl *acl = NULL; + int error = 0, type; + + type = xfs_decode_acl(name); + if (type < 0) + return type; + if (flags & XATTR_CREATE) + return -EINVAL; + if (type == ACL_TYPE_DEFAULT && !S_ISDIR(inode->i_mode)) + return value ? -EACCES : 0; + if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER)) + return -EPERM; + + if (!value) + goto set_acl; + + acl = posix_acl_from_xattr(value, size); + if (!acl) { + /* + * acl_set_file(3) may request that we set default ACLs with + * zero length -- defend (gracefully) against that here. + */ + goto out; + } + if (IS_ERR(acl)) { + error = PTR_ERR(acl); + goto out; + } + + error = posix_acl_valid(acl); + if (error) + goto out_release; + + error = -EINVAL; + if (acl->a_count > XFS_ACL_MAX_ENTRIES) + goto out_release; + + if (type == ACL_TYPE_ACCESS) { + mode_t mode = inode->i_mode; + error = posix_acl_equiv_mode(acl, &mode); + + if (error <= 0) { + posix_acl_release(acl); + acl = NULL; + + if (error < 0) + return error; + } + + error = xfs_set_mode(inode, mode); + if (error) + goto out_release; + } + + set_acl: + error = xfs_set_acl(inode, type, acl); + out_release: + posix_acl_release(acl); + out: + return error; +} + +struct xattr_handler xfs_xattr_system_handler = { + .prefix = XATTR_SYSTEM_PREFIX, + .get = xfs_xattr_system_get, + .set = xfs_xattr_system_set, +}; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-14 15:14:12.000000000 +0200 @@ -51,6 +51,7 @@ #include #include #include +#include #include #include @@ -259,9 +260,8 @@ xfs_vn_mknod( { struct inode *inode; struct xfs_inode *ip = NULL; - xfs_acl_t *default_acl = NULL; + struct posix_acl *default_acl = NULL; struct xfs_name name; - int (*test_default_acl)(struct inode *) = _ACL_DEFAULT_EXISTS; int error; /* @@ -271,21 +271,17 @@ xfs_vn_mknod( if (unlikely(!sysv_valid_dev(rdev) || MAJOR(rdev) & ~0x1ff)) return -EINVAL; - if (test_default_acl && test_default_acl(dir)) { - if (!_ACL_ALLOC(default_acl)) { - return -ENOMEM; - } - if (!_ACL_GET_DEFAULT(dir, default_acl)) { - _ACL_FREE(default_acl); - default_acl = NULL; - } + if (IS_POSIXACL(dir)) { + default_acl = xfs_get_acl(dir, ACL_TYPE_DEFAULT); + if (IS_ERR(default_acl)) + return -PTR_ERR(default_acl); + + if (!default_acl) + mode &= ~current->fs->umask; } xfs_dentry_to_name(&name, dentry); - if (IS_POSIXACL(dir) && !default_acl) - mode &= ~current->fs->umask; - switch (mode & S_IFMT) { case S_IFCHR: case S_IFBLK: @@ -313,11 +309,11 @@ xfs_vn_mknod( goto out_cleanup_inode; if (default_acl) { - error = _ACL_INHERIT(inode, mode, default_acl); + error = -xfs_inherit_acl(inode, default_acl); if (unlikely(error)) goto out_cleanup_inode; xfs_iflags_set(ip, XFS_IMODIFIED); - _ACL_FREE(default_acl); + posix_acl_release(default_acl); } @@ -327,8 +323,7 @@ xfs_vn_mknod( out_cleanup_inode: xfs_cleanup_inode(dir, inode, dentry); out_free_acl: - if (default_acl) - _ACL_FREE(default_acl); + posix_acl_release(default_acl); return -error; } @@ -550,38 +545,6 @@ xfs_vn_put_link( kfree(s); } -#ifdef CONFIG_XFS_POSIX_ACL -STATIC int -xfs_check_acl( - struct inode *inode, - int mask) -{ - struct xfs_inode *ip = XFS_I(inode); - int error; - - xfs_itrace_entry(ip); - - if (XFS_IFORK_Q(ip)) { - error = xfs_acl_iaccess(ip, mask, NULL); - if (error != -1) - return -error; - } - - return -EAGAIN; -} - -STATIC int -xfs_vn_permission( - struct inode *inode, - int mask, - struct nameidata *nd) -{ - return generic_permission(inode, mask, xfs_check_acl); -} -#else -#define xfs_vn_permission NULL -#endif - STATIC int xfs_vn_getattr( struct vfsmount *mnt, @@ -694,6 +657,9 @@ xfs_vn_setattr( error = xfs_setattr(XFS_I(inode), &vattr, flags, NULL); if (likely(!error)) vn_revalidate(vn_from_inode(inode)); + + if (!error && (attr->ia_valid & ATTR_MODE)) + error = -xfs_acl_chmod(inode); return -error; } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.h 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.h 2008-06-14 15:14:12.000000000 +0200 @@ -29,6 +29,12 @@ extern void xfs_ichgtime_fast(struct xfs extern void xfs_setup_inode(struct xfs_inode *); +#ifdef CONFIG_XFS_POSIX_ACL +int xfs_vn_permission(struct inode *inode, int mask, struct nameidata *nd); +#else +#define xfs_vn_permission NULL +#endif + #define xfs_vtoi(vp) \ ((struct xfs_inode *)vn_to_inode(vp)->i_private) Index: linux-2.6-xfs/fs/xfs/xfs_acl.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.h 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.h 2008-06-14 15:55:57.000000000 +0200 @@ -18,82 +18,85 @@ #ifndef __XFS_ACL_H__ #define __XFS_ACL_H__ -/* - * Access Control Lists - */ -typedef __uint16_t xfs_acl_perm_t; -typedef __int32_t xfs_acl_type_t; -typedef __int32_t xfs_acl_tag_t; -typedef __int32_t xfs_acl_id_t; +struct inode; +struct posix_acl; +struct xfs_inode; + #define XFS_ACL_MAX_ENTRIES 25 #define XFS_ACL_NOT_PRESENT (-1) -typedef struct xfs_acl_entry { - xfs_acl_tag_t ae_tag; - xfs_acl_id_t ae_id; - xfs_acl_perm_t ae_perm; -} xfs_acl_entry_t; - -typedef struct xfs_acl { - __int32_t acl_cnt; - xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES]; -} xfs_acl_t; +struct xfs_acl { + __be32 acl_cnt; + struct xfs_acl_entry { + __be32 ae_tag; + __be32 ae_id; + __be16 ae_perm; + } acl_entry[XFS_ACL_MAX_ENTRIES]; +}; /* On-disk XFS extended attribute names */ -#define SGI_ACL_FILE "SGI_ACL_FILE" -#define SGI_ACL_DEFAULT "SGI_ACL_DEFAULT" +#define SGI_ACL_FILE "SGI_ACL_FILE" +#define SGI_ACL_DEFAULT "SGI_ACL_DEFAULT" #define SGI_ACL_FILE_SIZE (sizeof(SGI_ACL_FILE)-1) #define SGI_ACL_DEFAULT_SIZE (sizeof(SGI_ACL_DEFAULT)-1) #ifdef CONFIG_XFS_POSIX_ACL -struct vattr; -struct xfs_inode; +struct posix_acl *xfs_get_acl(struct inode *inode, int type); +int xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl); +int xfs_acl_chmod(struct inode *inode); +void xfs_inode_init_acls(struct xfs_inode *ip); +void xfs_inode_clear_acls(struct xfs_inode *ip); +int posix_acl_access_exists(struct inode *inode); +int posix_acl_default_exists(struct inode *inode); -extern struct kmem_zone *xfs_acl_zone; -#define xfs_acl_zone_init(zone, name) \ - (zone) = kmem_zone_init(sizeof(xfs_acl_t), (name)) -#define xfs_acl_zone_destroy(zone) kmem_zone_destroy(zone) - -extern int xfs_acl_inherit(bhv_vnode_t *, mode_t mode, xfs_acl_t *); -extern int xfs_acl_iaccess(struct xfs_inode *, mode_t, cred_t *); -extern int xfs_acl_vtoacl(bhv_vnode_t *, xfs_acl_t *, xfs_acl_t *); -extern int xfs_acl_vhasacl_access(bhv_vnode_t *); -extern int xfs_acl_vhasacl_default(bhv_vnode_t *); -extern int xfs_acl_vset(bhv_vnode_t *, void *, size_t, int); -extern int xfs_acl_vget(bhv_vnode_t *, void *, size_t, int); -extern int xfs_acl_vremove(bhv_vnode_t *, int); - -#define _ACL_TYPE_ACCESS 1 -#define _ACL_TYPE_DEFAULT 2 -#define _ACL_PERM_INVALID(perm) ((perm) & ~(ACL_READ|ACL_WRITE|ACL_EXECUTE)) - -#define _ACL_INHERIT(c,m,d) (xfs_acl_inherit(c,m,d)) -#define _ACL_GET_ACCESS(pv,pa) (xfs_acl_vtoacl(pv,pa,NULL) == 0) -#define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd) == 0) -#define _ACL_ACCESS_EXISTS xfs_acl_vhasacl_access -#define _ACL_DEFAULT_EXISTS xfs_acl_vhasacl_default - -#define _ACL_ALLOC(a) ((a) = kmem_zone_alloc(xfs_acl_zone, KM_SLEEP)) -#define _ACL_FREE(a) ((a)? kmem_zone_free(xfs_acl_zone, (a)):(void)0) +extern struct xattr_handler xfs_xattr_system_handler; #else -#define xfs_acl_zone_init(zone,name) -#define xfs_acl_zone_destroy(zone) -#define xfs_acl_vset(v,p,sz,t) (-EOPNOTSUPP) -#define xfs_acl_vget(v,p,sz,t) (-EOPNOTSUPP) -#define xfs_acl_vremove(v,t) (-EOPNOTSUPP) -#define xfs_acl_vhasacl_access(v) (0) -#define xfs_acl_vhasacl_default(v) (0) -#define _ACL_ALLOC(a) (1) /* successfully allocate nothing */ -#define _ACL_FREE(a) ((void)0) -#define _ACL_INHERIT(c,m,d) (0) -#define _ACL_GET_ACCESS(pv,pa) (0) -#define _ACL_GET_DEFAULT(pv,pd) (0) -#define _ACL_ACCESS_EXISTS (NULL) -#define _ACL_DEFAULT_EXISTS (NULL) -#endif +static inline struct posix_acl * +xfs_get_acl(struct inode *inode, int type) +{ + BUG(); + return NULL; +} + +static inline int +xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl) +{ + BUG(); + return 0; +} + +static inline int +xfs_acl_chmod(struct inode *inode) +{ + return 0; +} + +static inline void +xfs_inode_init_acls(struct xfs_inode *ip) +{ +} + +static inline void +xfs_inode_clear_acls(struct xfs_inode *ip) +{ +} + +static inline int +posix_acl_access_exists(struct inode *inode) +{ + return 0; +} + +static inline int +posix_acl_default_exists(struct inode *inode) +{ + return 0; +} + +#endif /* CONFIG_XFS_POSIX_ACL */ #endif /* __XFS_ACL_H__ */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-14 15:14:12.000000000 +0200 @@ -50,7 +50,6 @@ #include "xfs_dir2_block.h" #include "xfs_dir2_node.h" #include "xfs_dir2_trace.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_attr_leaf.h" #include "xfs_inode_item.h" @@ -178,10 +177,6 @@ EXPORT_SYMBOL(uuid_table_remove); EXPORT_SYMBOL(vn_hold); EXPORT_SYMBOL(vn_revalidate); -#if defined(CONFIG_XFS_POSIX_ACL) -EXPORT_SYMBOL(xfs_acl_vtoacl); -EXPORT_SYMBOL(xfs_acl_inherit); -#endif EXPORT_SYMBOL(xfs_alloc_buftarg); EXPORT_SYMBOL(xfs_flush_buftarg); EXPORT_SYMBOL(xfs_free_buftarg); Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-14 15:03:47.000000000 +0200 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,881 +0,0 @@ -/* - * Copyright (c) 2001-2002,2005 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ -#include "xfs.h" -#include "xfs_fs.h" -#include "xfs_types.h" -#include "xfs_bit.h" -#include "xfs_inum.h" -#include "xfs_ag.h" -#include "xfs_dir2.h" -#include "xfs_bmap_btree.h" -#include "xfs_alloc_btree.h" -#include "xfs_ialloc_btree.h" -#include "xfs_dir2_sf.h" -#include "xfs_attr_sf.h" -#include "xfs_dinode.h" -#include "xfs_inode.h" -#include "xfs_btree.h" -#include "xfs_acl.h" -#include "xfs_attr.h" -#include "xfs_vnodeops.h" - -#include -#include - -STATIC int xfs_acl_setmode(bhv_vnode_t *, xfs_acl_t *, int *); -STATIC void xfs_acl_filter_mode(mode_t, xfs_acl_t *); -STATIC void xfs_acl_get_endian(xfs_acl_t *); -STATIC int xfs_acl_access(uid_t, gid_t, xfs_acl_t *, mode_t, cred_t *); -STATIC int xfs_acl_invalid(xfs_acl_t *); -STATIC void xfs_acl_sync_mode(mode_t, xfs_acl_t *); -STATIC void xfs_acl_get_attr(bhv_vnode_t *, xfs_acl_t *, int, int, int *); -STATIC void xfs_acl_set_attr(bhv_vnode_t *, xfs_acl_t *, int, int *); -STATIC int xfs_acl_allow_set(bhv_vnode_t *, int); - -kmem_zone_t *xfs_acl_zone; - - -/* - * Test for existence of access ACL attribute as efficiently as possible. - */ -int -xfs_acl_vhasacl_access( - bhv_vnode_t *vp) -{ - int error; - - xfs_acl_get_attr(vp, NULL, _ACL_TYPE_ACCESS, ATTR_KERNOVAL, &error); - return (error == 0); -} - -/* - * Test for existence of default ACL attribute as efficiently as possible. - */ -int -xfs_acl_vhasacl_default( - bhv_vnode_t *vp) -{ - int error; - - if (!S_ISDIR(vp->i_mode)) - return 0; - xfs_acl_get_attr(vp, NULL, _ACL_TYPE_DEFAULT, ATTR_KERNOVAL, &error); - return (error == 0); -} - -/* - * Convert from extended attribute representation to in-memory for XFS. - */ -STATIC int -posix_acl_xattr_to_xfs( - posix_acl_xattr_header *src, - size_t size, - xfs_acl_t *dest) -{ - posix_acl_xattr_entry *src_entry; - xfs_acl_entry_t *dest_entry; - int n; - - if (!src || !dest) - return EINVAL; - - if (size < sizeof(posix_acl_xattr_header)) - return EINVAL; - - if (src->a_version != cpu_to_le32(POSIX_ACL_XATTR_VERSION)) - return EOPNOTSUPP; - - memset(dest, 0, sizeof(xfs_acl_t)); - dest->acl_cnt = posix_acl_xattr_count(size); - if (dest->acl_cnt < 0 || dest->acl_cnt > XFS_ACL_MAX_ENTRIES) - return EINVAL; - - /* - * acl_set_file(3) may request that we set default ACLs with - * zero length -- defend (gracefully) against that here. - */ - if (!dest->acl_cnt) - return 0; - - src_entry = (posix_acl_xattr_entry *)((char *)src + sizeof(*src)); - dest_entry = &dest->acl_entry[0]; - - for (n = 0; n < dest->acl_cnt; n++, src_entry++, dest_entry++) { - dest_entry->ae_perm = le16_to_cpu(src_entry->e_perm); - if (_ACL_PERM_INVALID(dest_entry->ae_perm)) - return EINVAL; - dest_entry->ae_tag = le16_to_cpu(src_entry->e_tag); - switch(dest_entry->ae_tag) { - case ACL_USER: - case ACL_GROUP: - dest_entry->ae_id = le32_to_cpu(src_entry->e_id); - break; - case ACL_USER_OBJ: - case ACL_GROUP_OBJ: - case ACL_MASK: - case ACL_OTHER: - dest_entry->ae_id = ACL_UNDEFINED_ID; - break; - default: - return EINVAL; - } - } - if (xfs_acl_invalid(dest)) - return EINVAL; - - return 0; -} - -/* - * Comparison function called from xfs_sort(). - * Primary key is ae_tag, secondary key is ae_id. - */ -STATIC int -xfs_acl_entry_compare( - const void *va, - const void *vb) -{ - xfs_acl_entry_t *a = (xfs_acl_entry_t *)va, - *b = (xfs_acl_entry_t *)vb; - - if (a->ae_tag == b->ae_tag) - return (a->ae_id - b->ae_id); - return (a->ae_tag - b->ae_tag); -} - -/* - * Convert from in-memory XFS to extended attribute representation. - */ -STATIC int -posix_acl_xfs_to_xattr( - xfs_acl_t *src, - posix_acl_xattr_header *dest, - size_t size) -{ - int n; - size_t new_size = posix_acl_xattr_size(src->acl_cnt); - posix_acl_xattr_entry *dest_entry; - xfs_acl_entry_t *src_entry; - - if (size < new_size) - return -ERANGE; - - /* Need to sort src XFS ACL by */ - xfs_sort(src->acl_entry, src->acl_cnt, sizeof(src->acl_entry[0]), - xfs_acl_entry_compare); - - dest->a_version = cpu_to_le32(POSIX_ACL_XATTR_VERSION); - dest_entry = &dest->a_entries[0]; - src_entry = &src->acl_entry[0]; - for (n = 0; n < src->acl_cnt; n++, dest_entry++, src_entry++) { - dest_entry->e_perm = cpu_to_le16(src_entry->ae_perm); - if (_ACL_PERM_INVALID(src_entry->ae_perm)) - return -EINVAL; - dest_entry->e_tag = cpu_to_le16(src_entry->ae_tag); - switch (src_entry->ae_tag) { - case ACL_USER: - case ACL_GROUP: - dest_entry->e_id = cpu_to_le32(src_entry->ae_id); - break; - case ACL_USER_OBJ: - case ACL_GROUP_OBJ: - case ACL_MASK: - case ACL_OTHER: - dest_entry->e_id = cpu_to_le32(ACL_UNDEFINED_ID); - break; - default: - return -EINVAL; - } - } - return new_size; -} - -int -xfs_acl_vget( - bhv_vnode_t *vp, - void *acl, - size_t size, - int kind) -{ - int error; - xfs_acl_t *xfs_acl = NULL; - posix_acl_xattr_header *ext_acl = acl; - int flags = 0; - - VN_HOLD(vp); - if(size) { - if (!(_ACL_ALLOC(xfs_acl))) { - error = ENOMEM; - goto out; - } - memset(xfs_acl, 0, sizeof(xfs_acl_t)); - } else - flags = ATTR_KERNOVAL; - - xfs_acl_get_attr(vp, xfs_acl, kind, flags, &error); - if (error) - goto out; - - if (!size) { - error = -posix_acl_xattr_size(XFS_ACL_MAX_ENTRIES); - } else { - if (xfs_acl_invalid(xfs_acl)) { - error = EINVAL; - goto out; - } - if (kind == _ACL_TYPE_ACCESS) - xfs_acl_sync_mode(xfs_vtoi(vp)->i_d.di_mode, xfs_acl); - error = -posix_acl_xfs_to_xattr(xfs_acl, ext_acl, size); - } -out: - VN_RELE(vp); - if(xfs_acl) - _ACL_FREE(xfs_acl); - return -error; -} - -int -xfs_acl_vremove( - bhv_vnode_t *vp, - int kind) -{ - int error; - - VN_HOLD(vp); - error = xfs_acl_allow_set(vp, kind); - if (!error) { - error = xfs_attr_remove(xfs_vtoi(vp), - kind == _ACL_TYPE_DEFAULT? - SGI_ACL_DEFAULT: SGI_ACL_FILE, - ATTR_ROOT); - if (error == ENOATTR) - error = 0; /* 'scool */ - } - VN_RELE(vp); - return -error; -} - -int -xfs_acl_vset( - bhv_vnode_t *vp, - void *acl, - size_t size, - int kind) -{ - posix_acl_xattr_header *ext_acl = acl; - xfs_acl_t *xfs_acl; - int error; - int basicperms = 0; /* more than std unix perms? */ - - if (!acl) - return -EINVAL; - - if (!(_ACL_ALLOC(xfs_acl))) - return -ENOMEM; - - error = posix_acl_xattr_to_xfs(ext_acl, size, xfs_acl); - if (error) { - _ACL_FREE(xfs_acl); - return -error; - } - if (!xfs_acl->acl_cnt) { - _ACL_FREE(xfs_acl); - return 0; - } - - VN_HOLD(vp); - error = xfs_acl_allow_set(vp, kind); - - /* Incoming ACL exists, set file mode based on its value */ - if (!error && kind == _ACL_TYPE_ACCESS) - error = xfs_acl_setmode(vp, xfs_acl, &basicperms); - - if (error) - goto out; - - /* - * If we have more than std unix permissions, set up the actual attr. - * Otherwise, delete any existing attr. This prevents us from - * having actual attrs for permissions that can be stored in the - * standard permission bits. - */ - if (!basicperms) { - xfs_acl_set_attr(vp, xfs_acl, kind, &error); - } else { - error = -xfs_acl_vremove(vp, _ACL_TYPE_ACCESS); - } - -out: - VN_RELE(vp); - _ACL_FREE(xfs_acl); - return -error; -} - -int -xfs_acl_iaccess( - xfs_inode_t *ip, - mode_t mode, - cred_t *cr) -{ - xfs_acl_t *acl; - int rval; - struct xfs_name acl_name = {SGI_ACL_FILE, SGI_ACL_FILE_SIZE}; - - if (!(_ACL_ALLOC(acl))) - return -1; - - /* If the file has no ACL return -1. */ - rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { - _ACL_FREE(acl); - return -1; - } - xfs_acl_get_endian(acl); - - /* If the file has an empty ACL return -1. */ - if (acl->acl_cnt == XFS_ACL_NOT_PRESENT) { - _ACL_FREE(acl); - return -1; - } - - /* Synchronize ACL with mode bits */ - xfs_acl_sync_mode(ip->i_d.di_mode, acl); - - rval = xfs_acl_access(ip->i_d.di_uid, ip->i_d.di_gid, acl, mode, cr); - _ACL_FREE(acl); - return rval; -} - -STATIC int -xfs_acl_allow_set( - bhv_vnode_t *vp, - int kind) -{ - if (vp->i_flags & (S_IMMUTABLE|S_APPEND)) - return EPERM; - if (kind == _ACL_TYPE_DEFAULT && !S_ISDIR(vp->i_mode)) - return ENOTDIR; - if (vp->i_sb->s_flags & MS_RDONLY) - return EROFS; - if (xfs_vtoi(vp)->i_d.di_uid != current->fsuid && !capable(CAP_FOWNER)) - return EPERM; - return 0; -} - -/* - * Note: cr is only used here for the capability check if the ACL test fails. - * It is not used to find out the credentials uid or groups etc, as was - * done in IRIX. It is assumed that the uid and groups for the current - * thread are taken from "current" instead of the cr parameter. - */ -STATIC int -xfs_acl_access( - uid_t fuid, - gid_t fgid, - xfs_acl_t *fap, - mode_t md, - cred_t *cr) -{ - xfs_acl_entry_t matched; - int i, allows; - int maskallows = -1; /* true, but not 1, either */ - int seen_userobj = 0; - - matched.ae_tag = 0; /* Invalid type */ - matched.ae_perm = 0; - - for (i = 0; i < fap->acl_cnt; i++) { - /* - * Break out if we've got a user_obj entry or - * a user entry and the mask (and have processed USER_OBJ) - */ - if (matched.ae_tag == ACL_USER_OBJ) - break; - if (matched.ae_tag == ACL_USER) { - if (maskallows != -1 && seen_userobj) - break; - if (fap->acl_entry[i].ae_tag != ACL_MASK && - fap->acl_entry[i].ae_tag != ACL_USER_OBJ) - continue; - } - /* True if this entry allows the requested access */ - allows = ((fap->acl_entry[i].ae_perm & md) == md); - - switch (fap->acl_entry[i].ae_tag) { - case ACL_USER_OBJ: - seen_userobj = 1; - if (fuid != current->fsuid) - continue; - matched.ae_tag = ACL_USER_OBJ; - matched.ae_perm = allows; - break; - case ACL_USER: - if (fap->acl_entry[i].ae_id != current->fsuid) - continue; - matched.ae_tag = ACL_USER; - matched.ae_perm = allows; - break; - case ACL_GROUP_OBJ: - if ((matched.ae_tag == ACL_GROUP_OBJ || - matched.ae_tag == ACL_GROUP) && !allows) - continue; - if (!in_group_p(fgid)) - continue; - matched.ae_tag = ACL_GROUP_OBJ; - matched.ae_perm = allows; - break; - case ACL_GROUP: - if ((matched.ae_tag == ACL_GROUP_OBJ || - matched.ae_tag == ACL_GROUP) && !allows) - continue; - if (!in_group_p(fap->acl_entry[i].ae_id)) - continue; - matched.ae_tag = ACL_GROUP; - matched.ae_perm = allows; - break; - case ACL_MASK: - maskallows = allows; - break; - case ACL_OTHER: - if (matched.ae_tag != 0) - continue; - matched.ae_tag = ACL_OTHER; - matched.ae_perm = allows; - break; - } - } - /* - * First possibility is that no matched entry allows access. - * The capability to override DAC may exist, so check for it. - */ - switch (matched.ae_tag) { - case ACL_OTHER: - case ACL_USER_OBJ: - if (matched.ae_perm) - return 0; - break; - case ACL_USER: - case ACL_GROUP_OBJ: - case ACL_GROUP: - if (maskallows && matched.ae_perm) - return 0; - break; - case 0: - break; - } - - /* EACCES tells generic_permission to check for capability overrides */ - return EACCES; -} -EXPORT_SYMBOL(xfs_acl_access); - -/* - * ACL validity checker. - * This acl validation routine checks each ACL entry read in makes sense. - */ -STATIC int -xfs_acl_invalid( - xfs_acl_t *aclp) -{ - xfs_acl_entry_t *entry, *e; - int user = 0, group = 0, other = 0, mask = 0; - int mask_required = 0; - int i, j; - - if (!aclp) - goto acl_invalid; - - if (aclp->acl_cnt > XFS_ACL_MAX_ENTRIES) - goto acl_invalid; - - for (i = 0; i < aclp->acl_cnt; i++) { - entry = &aclp->acl_entry[i]; - switch (entry->ae_tag) { - case ACL_USER_OBJ: - if (user++) - goto acl_invalid; - break; - case ACL_GROUP_OBJ: - if (group++) - goto acl_invalid; - break; - case ACL_OTHER: - if (other++) - goto acl_invalid; - break; - case ACL_USER: - case ACL_GROUP: - for (j = i + 1; j < aclp->acl_cnt; j++) { - e = &aclp->acl_entry[j]; - if (e->ae_id == entry->ae_id && - e->ae_tag == entry->ae_tag) - goto acl_invalid; - } - mask_required++; - break; - case ACL_MASK: - if (mask++) - goto acl_invalid; - break; - default: - goto acl_invalid; - } - } - if (!user || !group || !other || (mask_required && !mask)) - goto acl_invalid; - else - return 0; -acl_invalid: - return EINVAL; -} - -/* - * Do ACL endian conversion. - */ -STATIC void -xfs_acl_get_endian( - xfs_acl_t *aclp) -{ - xfs_acl_entry_t *ace, *end; - - INT_SET(aclp->acl_cnt, ARCH_CONVERT, aclp->acl_cnt); - end = &aclp->acl_entry[0]+aclp->acl_cnt; - for (ace = &aclp->acl_entry[0]; ace < end; ace++) { - INT_SET(ace->ae_tag, ARCH_CONVERT, ace->ae_tag); - INT_SET(ace->ae_id, ARCH_CONVERT, ace->ae_id); - INT_SET(ace->ae_perm, ARCH_CONVERT, ace->ae_perm); - } -} - -/* - * Get the ACL from the EA and do endian conversion. - */ -STATIC void -xfs_acl_get_attr( - bhv_vnode_t *vp, - xfs_acl_t *aclp, - int kind, - int flags, - int *error) -{ - int len = sizeof(xfs_acl_t); - - ASSERT((flags & ATTR_KERNOVAL) ? (aclp == NULL) : 1); - flags |= ATTR_ROOT; - *error = xfs_attr_get(xfs_vtoi(vp), - kind == _ACL_TYPE_ACCESS ? - SGI_ACL_FILE : SGI_ACL_DEFAULT, - (char *)aclp, &len, flags); - if (*error || (flags & ATTR_KERNOVAL)) - return; - xfs_acl_get_endian(aclp); -} - -/* - * Set the EA with the ACL and do endian conversion. - */ -STATIC void -xfs_acl_set_attr( - bhv_vnode_t *vp, - xfs_acl_t *aclp, - int kind, - int *error) -{ - xfs_acl_entry_t *ace, *newace, *end; - xfs_acl_t *newacl; - int len; - - if (!(_ACL_ALLOC(newacl))) { - *error = ENOMEM; - return; - } - - len = sizeof(xfs_acl_t) - - (sizeof(xfs_acl_entry_t) * (XFS_ACL_MAX_ENTRIES - aclp->acl_cnt)); - end = &aclp->acl_entry[0]+aclp->acl_cnt; - for (ace = &aclp->acl_entry[0], newace = &newacl->acl_entry[0]; - ace < end; - ace++, newace++) { - INT_SET(newace->ae_tag, ARCH_CONVERT, ace->ae_tag); - INT_SET(newace->ae_id, ARCH_CONVERT, ace->ae_id); - INT_SET(newace->ae_perm, ARCH_CONVERT, ace->ae_perm); - } - INT_SET(newacl->acl_cnt, ARCH_CONVERT, aclp->acl_cnt); - *error = xfs_attr_set(xfs_vtoi(vp), - kind == _ACL_TYPE_ACCESS ? - SGI_ACL_FILE: SGI_ACL_DEFAULT, - (char *)newacl, len, ATTR_ROOT); - _ACL_FREE(newacl); -} - -int -xfs_acl_vtoacl( - bhv_vnode_t *vp, - xfs_acl_t *access_acl, - xfs_acl_t *default_acl) -{ - int error = 0; - - if (access_acl) { - /* - * Get the Access ACL and the mode. If either cannot - * be obtained for some reason, invalidate the access ACL. - */ - xfs_acl_get_attr(vp, access_acl, _ACL_TYPE_ACCESS, 0, &error); - if (error) - access_acl->acl_cnt = XFS_ACL_NOT_PRESENT; - else /* We have a good ACL and the file mode, synchronize. */ - xfs_acl_sync_mode(xfs_vtoi(vp)->i_d.di_mode, access_acl); - } - - if (default_acl) { - xfs_acl_get_attr(vp, default_acl, _ACL_TYPE_DEFAULT, 0, &error); - if (error) - default_acl->acl_cnt = XFS_ACL_NOT_PRESENT; - } - return error; -} - -/* - * This function retrieves the parent directory's acl, processes it - * and lets the child inherit the acl(s) that it should. - */ -int -xfs_acl_inherit( - bhv_vnode_t *vp, - mode_t mode, - xfs_acl_t *pdaclp) -{ - xfs_acl_t *cacl; - int error = 0; - int basicperms = 0; - - /* - * If the parent does not have a default ACL, or it's an - * invalid ACL, we're done. - */ - if (!vp) - return 0; - if (!pdaclp || xfs_acl_invalid(pdaclp)) - return 0; - - /* - * Copy the default ACL of the containing directory to - * the access ACL of the new file and use the mode that - * was passed in to set up the correct initial values for - * the u::,g::[m::], and o:: entries. This is what makes - * umask() "work" with ACL's. - */ - - if (!(_ACL_ALLOC(cacl))) - return ENOMEM; - - memcpy(cacl, pdaclp, sizeof(xfs_acl_t)); - xfs_acl_filter_mode(mode, cacl); - error = xfs_acl_setmode(vp, cacl, &basicperms); - if (error) - goto out_error; - - /* - * Set the Default and Access ACL on the file. The mode is already - * set on the file, so we don't need to worry about that. - * - * If the new file is a directory, its default ACL is a copy of - * the containing directory's default ACL. - */ - if (S_ISDIR(vp->i_mode)) - xfs_acl_set_attr(vp, pdaclp, _ACL_TYPE_DEFAULT, &error); - if (!error && !basicperms) - xfs_acl_set_attr(vp, cacl, _ACL_TYPE_ACCESS, &error); -out_error: - _ACL_FREE(cacl); - return error; -} - -/* - * Set up the correct mode on the file based on the supplied ACL. This - * makes sure that the mode on the file reflects the state of the - * u::,g::[m::], and o:: entries in the ACL. Since the mode is where - * the ACL is going to get the permissions for these entries, we must - * synchronize the mode whenever we set the ACL on a file. - */ -STATIC int -xfs_acl_setmode( - bhv_vnode_t *vp, - xfs_acl_t *acl, - int *basicperms) -{ - bhv_vattr_t va; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - int i, nomask = 1; - - *basicperms = 1; - - if (acl->acl_cnt == XFS_ACL_NOT_PRESENT) - return 0; - - /* - * Copy the u::, g::, o::, and m:: bits from the ACL into the - * mode. The m:: bits take precedence over the g:: bits. - */ - va.va_mask = XFS_AT_MODE; - va.va_mode = xfs_vtoi(vp)->i_d.di_mode; - va.va_mode &= ~(S_IRWXU|S_IRWXG|S_IRWXO); - ap = acl->acl_entry; - for (i = 0; i < acl->acl_cnt; ++i) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - va.va_mode |= ap->ae_perm << 6; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: /* more than just standard modes */ - nomask = 0; - va.va_mode |= ap->ae_perm << 3; - *basicperms = 0; - break; - case ACL_OTHER: - va.va_mode |= ap->ae_perm; - break; - default: /* more than just standard modes */ - *basicperms = 0; - break; - } - ap++; - } - - /* Set the group bits from ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - va.va_mode |= gap->ae_perm << 3; - - return xfs_setattr(xfs_vtoi(vp), &va, 0, sys_cred); -} - -/* - * The permissions for the special ACL entries (u::, g::[m::], o::) are - * actually stored in the file mode (if there is both a group and a mask, - * the group is stored in the ACL entry and the mask is stored on the file). - * This allows the mode to remain automatically in sync with the ACL without - * the need for a call-back to the ACL system at every point where the mode - * could change. This function takes the permissions from the specified mode - * and places it in the supplied ACL. - * - * This implementation draws its validity from the fact that, when the ACL - * was assigned, the mode was copied from the ACL. - * If the mode did not change, therefore, the mode remains exactly what was - * taken from the special ACL entries at assignment. - * If a subsequent chmod() was done, the POSIX spec says that the change in - * mode must cause an update to the ACL seen at user level and used for - * access checks. Before and after a mode change, therefore, the file mode - * most accurately reflects what the special ACL entries should permit/deny. - * - * CAVEAT: If someone sets the SGI_ACL_FILE attribute directly, - * the existing mode bits will override whatever is in the - * ACL. Similarly, if there is a pre-existing ACL that was - * never in sync with its mode (owing to a bug in 6.5 and - * before), it will now magically (or mystically) be - * synchronized. This could cause slight astonishment, but - * it is better than inconsistent permissions. - * - * The supplied ACL is a template that may contain any combination - * of special entries. These are treated as place holders when we fill - * out the ACL. This routine does not add or remove special entries, it - * simply unites each special entry with its associated set of permissions. - */ -STATIC void -xfs_acl_sync_mode( - mode_t mode, - xfs_acl_t *acl) -{ - int i, nomask = 1; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - - /* - * Set ACL entries. POSIX1003.1eD16 requires that the MASK - * be set instead of the GROUP entry, if there is a MASK. - */ - for (ap = acl->acl_entry, i = 0; i < acl->acl_cnt; ap++, i++) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - ap->ae_perm = (mode >> 6) & 0x7; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: - nomask = 0; - ap->ae_perm = (mode >> 3) & 0x7; - break; - case ACL_OTHER: - ap->ae_perm = mode & 0x7; - break; - default: - break; - } - } - /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm = (mode >> 3) & 0x7; -} - -/* - * When inheriting an Access ACL from a directory Default ACL, - * the ACL bits are set to the intersection of the ACL default - * permission bits and the file permission bits in mode. If there - * are no permission bits on the file then we must not give them - * the ACL. This is what what makes umask() work with ACLs. - */ -STATIC void -xfs_acl_filter_mode( - mode_t mode, - xfs_acl_t *acl) -{ - int i, nomask = 1; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - - /* - * Set ACL entries. POSIX1003.1eD16 requires that the MASK - * be merged with GROUP entry, if there is a MASK. - */ - for (ap = acl->acl_entry, i = 0; i < acl->acl_cnt; ap++, i++) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - ap->ae_perm &= (mode >> 6) & 0x7; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: - nomask = 0; - ap->ae_perm &= (mode >> 3) & 0x7; - break; - case ACL_OTHER: - ap->ae_perm &= mode & 0x7; - break; - default: - break; - } - } - /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm &= (mode >> 3) & 0x7; -} Index: linux-2.6-xfs/fs/xfs/Makefile =================================================================== --- linux-2.6-xfs.orig/fs/xfs/Makefile 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/Makefile 2008-06-14 15:14:12.000000000 +0200 @@ -29,7 +29,7 @@ obj-$(CONFIG_XFS_QUOTA) += quota/ obj-$(CONFIG_XFS_DMAPI) += dmapi/ xfs-$(CONFIG_XFS_RT) += xfs_rtalloc.o -xfs-$(CONFIG_XFS_POSIX_ACL) += xfs_acl.o +xfs-$(CONFIG_XFS_POSIX_ACL) += $(XFS_LINUX)/xfs_acl.o xfs-$(CONFIG_PROC_FS) += $(XFS_LINUX)/xfs_stats.o xfs-$(CONFIG_SYSCTL) += $(XFS_LINUX)/xfs_sysctl.o xfs-$(CONFIG_COMPAT) += $(XFS_LINUX)/xfs_ioctl32.o Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2008-06-14 15:56:37.000000000 +0200 @@ -816,6 +816,7 @@ xfs_iread( ip->i_mount = mp; atomic_set(&ip->i_iocount, 0); spin_lock_init(&ip->i_flags_lock); + xfs_inode_init_acls(ip); /* * Get pointer's to the on-disk inode and the buffer containing it. @@ -2668,6 +2669,8 @@ xfs_idestroy( } xfs_inode_item_destroy(ip); } + + xfs_inode_clear_acls(ip); kmem_zone_free(xfs_inode_zone, ip); } Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2008-06-14 15:14:12.000000000 +0200 @@ -18,6 +18,7 @@ #ifndef __XFS_INODE_H__ #define __XFS_INODE_H__ +struct posix_acl; struct xfs_dinode; struct xfs_dinode_core; @@ -239,6 +240,11 @@ typedef struct xfs_inode { xfs_fsize_t i_size; /* in-memory size */ xfs_fsize_t i_new_size; /* size when write completes */ atomic_t i_iocount; /* outstanding I/O count */ + +#ifdef CONFIG_XFS_POSIX_ACL + struct posix_acl *i_acl; + struct posix_acl *i_default_acl; +#endif /* Trace buffers per inode. */ #ifdef XFS_INODE_TRACE struct ktrace *i_trace; /* general inode trace */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-14 15:14:12.000000000 +0200 @@ -29,70 +29,6 @@ #include -/* - * ACL handling. Should eventually be moved into xfs_acl.c - */ - -static int -xfs_decode_acl(const char *name) -{ - if (strcmp(name, "posix_acl_access") == 0) - return _ACL_TYPE_ACCESS; - else if (strcmp(name, "posix_acl_default") == 0) - return _ACL_TYPE_DEFAULT; - return -EINVAL; -} - -/* - * Get system extended attributes which at the moment only - * includes Posix ACLs. - */ -static int -xfs_xattr_system_get(struct inode *inode, const char *name, - void *buffer, size_t size) -{ - int acl; - - acl = xfs_decode_acl(name); - if (acl < 0) - return acl; - - return xfs_acl_vget(inode, buffer, size, acl); -} - -static int -xfs_xattr_system_set(struct inode *inode, const char *name, - const void *value, size_t size, int flags) -{ - int error, acl; - - acl = xfs_decode_acl(name); - if (acl < 0) - return acl; - if (flags & XATTR_CREATE) - return -EINVAL; - - if (!value) - return xfs_acl_vremove(inode, acl); - - error = xfs_acl_vset(inode, (void *)value, size, acl); - if (!error) - vn_revalidate(inode); - return error; -} - -static struct xattr_handler xfs_xattr_system_handler = { - .prefix = XATTR_SYSTEM_PREFIX, - .get = xfs_xattr_system_get, - .set = xfs_xattr_system_set, -}; - - -/* - * Real xattr handling. The only difference between the namespaces is - * a flag passed to the low-level attr code. - */ - static int __xfs_xattr_get(struct inode *inode, const char *name, void *value, size_t size, int xflags) @@ -202,7 +138,9 @@ struct xattr_handler *xfs_xattr_handlers &xfs_xattr_user_handler, &xfs_xattr_trusted_handler, &xfs_xattr_security_handler, +#ifdef CONFIG_XFS_POSIX_ACL &xfs_xattr_system_handler, +#endif NULL }; @@ -313,7 +251,7 @@ xfs_vn_listxattr(struct dentry *dentry, /* * Then add the two synthetic ACL attributes. */ - if (xfs_acl_vhasacl_access(inode)) { + if (posix_acl_access_exists(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, data, size, &context.count); @@ -321,7 +259,7 @@ xfs_vn_listxattr(struct dentry *dentry, return error; } - if (xfs_acl_vhasacl_default(inode)) { + if (posix_acl_default_exists(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, data, size, &context.count); Index: linux-2.6-xfs/fs/xfs/Kconfig =================================================================== --- linux-2.6-xfs.orig/fs/xfs/Kconfig 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/Kconfig 2008-06-14 15:14:12.000000000 +0200 @@ -51,6 +51,7 @@ config XFS_DMAPI config XFS_POSIX_ACL bool "XFS POSIX ACL support" depends on XFS_FS + select FS_POSIX_ACL help POSIX Access Control Lists (ACLs) support permissions for users and groups beyond the owner/group/world scheme. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2008-06-14 15:03:47.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-06-14 15:57:29.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_itable.h" #include "xfs_fsops.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_utils.h" @@ -1909,18 +1908,8 @@ xfs_init_zones(void) if (!xfs_ili_zone) goto out_destroy_inode_zone; -#ifdef CONFIG_XFS_POSIX_ACL - xfs_acl_zone = kmem_zone_init(sizeof(xfs_acl_t), "xfs_acl"); - if (!xfs_acl_zone) - goto out_destroy_ili_zone; -#endif - return 0; -#ifdef CONFIG_XFS_POSIX_ACL - out_destroy_ili_zone: -#endif - kmem_zone_destroy(xfs_ili_zone); out_destroy_inode_zone: kmem_zone_destroy(xfs_inode_zone); out_destroy_efi_zone: @@ -1956,9 +1945,6 @@ xfs_init_zones(void) STATIC void xfs_destroy_zones(void) { -#ifdef CONFIG_XFS_POSIX_ACL - kmem_zone_destroy(xfs_acl_zone); -#endif kmem_zone_destroy(xfs_ili_zone); kmem_zone_destroy(xfs_inode_zone); kmem_zone_destroy(xfs_efi_zone); Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-14 15:50:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-14 15:50:59.000000000 +0200 @@ -45,7 +45,6 @@ #include "xfs_error.h" #include "xfs_quota.h" #include "xfs_trans_space.h" -#include "xfs_acl.h" #include "xfs_rw.h" #include "xfs_vnodeops.h" Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2008-06-14 15:51:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2008-06-14 15:51:05.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/xfs_rw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rw.c 2008-06-14 15:51:32.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_rw.c 2008-06-14 15:51:34.000000000 +0200 @@ -41,7 +41,6 @@ #include "xfs_ialloc.h" #include "xfs_attr.h" #include "xfs_bmap.h" -#include "xfs_acl.h" #include "xfs_error.h" #include "xfs_buf_item.h" #include "xfs_rw.h" Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2008-06-14 15:51:37.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2008-06-14 15:51:39.000000000 +0200 @@ -47,7 +47,6 @@ #include "xfs_log_priv.h" #include "xfs_dir2_trace.h" #include "xfs_extfree_item.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_mru_cache.h" #include "xfs_filestream.h" Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2008-06-14 15:58:33.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-06-14 15:58:34.000000000 +0200 @@ -41,7 +41,6 @@ #include "xfs_itable.h" #include "xfs_bmap.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_attr_leaf.h" #include "xfs_inode_item.h" Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-14 15:57:35.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-14 15:57:36.000000000 +0200 @@ -40,7 +40,6 @@ #include "xfs_itable.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_bmap.h" #include "xfs_buf_item.h" Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2008-06-14 15:57:42.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2008-06-14 15:57:43.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_inode_item.h" #include "xfs_buf_item.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_dquot.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_dquot.c 2008-06-14 15:58:28.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_dquot.c 2008-06-14 15:58:30.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_dquot_item.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_dquot_item.c 2008-06-14 15:57:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_dquot_item.c 2008-06-14 15:57:58.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_priv.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c 2008-06-14 15:58:03.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c 2008-06-14 15:58:05.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_bmap.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_bhv.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_bhv.c 2008-06-14 15:58:21.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_bhv.c 2008-06-14 15:58:23.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_qm.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_stats.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_stats.c 2008-06-14 15:58:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_stats.c 2008-06-14 15:58:18.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_qm.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-14 15:57:49.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-14 15:57:51.000000000 +0200 @@ -45,7 +45,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_utils.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_trans_dquot.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_trans_dquot.c 2008-06-14 15:58:07.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_trans_dquot.c 2008-06-14 15:58:09.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_priv.h" From owner-xfs@oss.sgi.com Sat Jun 14 09:42:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:42:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EGgF21022296 for ; Sat, 14 Jun 2008 09:42:16 -0700 X-ASG-Debug-ID: 1213461792-0c0600e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wa-out-1112.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CDBAFFCBBEB for ; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by cuda.sgi.com with ESMTP id WbGgx7b8YawjDiLv for ; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id j5so4037342wah.18 for ; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=JY4JJI2S44eRIC3hS+Mf8WmjJPwRU0fRX6sU+t9fif8=; b=etjZWf6jLqhEY6qDT8zlbRkT2TNyi4SZ+FRojMzxYXzRdrcK/Fop/k/xxiMqD8Ayv4 Hj1p2e4AaETrHcs3d+knJu04fmA5qotJ/ThudZhYhlc4I8Xp9Ghko6wRppPT6kc8wVT/ fTOd/DopWCCPqSFIjcXO0lVvGrnxflO8pVxjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=tDzGi7bo+KxkUlRvY4YoNspXOAhB6ZfJ80WpwS/fFIqDKpfqHT8CGqiIGi7udFpo04 C0xkJ7p2TDky6ewSp2QlHORIiIPWx/pK+Wp2dfmV1RglxCg9674Y1jDyLkCTMjpuKGwJ 2OqQ9pP/M3xYExJ09jzzRApcUJohyo6bvfDbw= Received: by 10.115.79.1 with SMTP id g1mr4505302wal.61.1213461792147; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) Received: by 10.114.183.7 with HTTP; Sat, 14 Jun 2008 09:43:12 -0700 (PDT) Message-ID: Date: Sat, 14 Jun 2008 12:43:12 -0400 From: Simon To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair trouble Subject: xfs_repair trouble MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: cb84e5feed0b76d8 X-Barracuda-Connect: wa-out-1112.google.com[209.85.146.179] X-Barracuda-Start-Time: 1213461792 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4781 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53289 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16345 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: simonjj@gmail.com Precedence: bulk X-list: xfs Hello all, I have a corrupted xfs filesystem on top of a RAID 5 (1TB in size). The RAID is still fully intact but the filesystem was damaged. When trying to repair the filesystem xfs_repair fails. I have tried various versions of xfs_repair, the latest stable (2.9.8) and the latest trunk (from CVS). I'd love to investigate and/or fix the issue further but I am a bit confused about some of my xfs_repair runs (both done with trunk). Could someone shed some light on where the problem could be, I'd be happy to continue digging if I would only know where roughly Run 1 ============================================ ./xfs_repair -P -m 170 /dev/evms/monster_evms ... more output ... bad hash table for directory inode 4842 (no data entry): rebuilding rebuilding directory inode 4842 entry ".." in directory inode 27930072 points to free inode 2013274702 bad hash table for directory inode 27930072 (no data entry): rebuilding rebuilding directory inode 27930072 bad hash table for directory inode 28776251 (no data entry): rebuilding rebuilding directory inode 28776251 fixing i8count in inode 29111010 xfs_repair: phase6.c:3411: shortform_dir2_entry_check: Assertion `bytes_deleted > 0' failed. Aborted ================================================= Exits with an Assert, it would be interesting to know why this Assert is there and what it means for bytes_deleted to be 0. Run 2 ============================================ ./xfs_repair -P -m 166 /dev/evms/monster_evms ... more output ... bad hash table for directory inode 2013274673 (no data entry): rebuilding rebuilding directory inode 2013274673 bad hash table for directory inode 2029477400 (no data entry): rebuilding rebuilding directory inode 2029477400 bad hash table for directory inode 2037825112 (no data entry): rebuilding rebuilding directory inode 2037825112 fatal error -- malloc failed in longform_dir2_entry_check (2585598792 bytes) ================================================= Exists with an malloc failed, even though I am using the -m option which I think was created to avoid exactly this scenario. Run 3 Run 3 ============================================ ./xfs_repair -P -m 200 /dev/evms/monster_evms ... more output ... - agno = 38 - agno = 39 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 4842 (no data entry): rebuilding rebuilding directory inode 4842 bad hash table for directory inode 28776251 (no data entry): rebuilding rebuilding directory inode 28776251 fixing i8count in inode 29111010 corrupt block 0 in directory inode 321685982: junking block Segmentation fault ================================================= Exists with a Seg Fault. I found this one interesting especially since it happens at the exact same inode as Run 1 All comments appreciated. Simon From owner-xfs@oss.sgi.com Sat Jun 14 09:50:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:50:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EGoWLO023236 for ; Sat, 14 Jun 2008 09:50:32 -0700 X-ASG-Debug-ID: 1213462289-0c0401940000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AB4CC17C19B6 for ; Sat, 14 Jun 2008 09:51:29 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id SVAOuMySlMwL7B98 for ; Sat, 14 Jun 2008 09:51:29 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 56FAAAC6275; Sat, 14 Jun 2008 11:51:28 -0500 (CDT) Message-ID: <4853F70F.6010400@sandeen.net> Date: Sat, 14 Jun 2008 11:51:27 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Paul Guermonprez CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair aborting ... dir2.c:2133 Subject: Re: xfs_repair aborting ... dir2.c:2133 References: <74d4a1e10806140124s3ed8dfa6x7e5ca656fea0e06e@mail.gmail.com> In-Reply-To: <74d4a1e10806140124s3ed8dfa6x7e5ca656fea0e06e@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213462289 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53291 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16346 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Paul Guermonprez wrote: > hello, > > i have a xfs dump i want to repair under linux ubuntu. > the partition was created by a storage system ss4000-e. Do you mean that you did xfsrestore on a previous dump and then tried to repair the resulting filesystem? Maybe the dump was corrupt? > if i use version 2.9.4, i have a segfault > and version 2.9.8, the proces is aborted with message : > xfs_repair: dir2.c:2133: process_dir2: Assertion `(ino != > mp->m_sb.sb_rootino && ino != *parent) || (ino == mp->m_sb.sb_rootino > && (ino == *parent || need_root_dotdot == 1))' failed. > Aborted If you are willing to provide an xfs_metadump image, Barry would probably look into it for you :) Did anything interesting go wrong before your fs got so mangled? > i also tried to comment this test, but it returns a segfault just as > version 2.9.4. > > note : > i already restored 3 xfs dumps from the same machine, and everything > went in the lost+found, partly with no name, no directory, partly with > a directory structure and filenames as expected. xfsrestore did this? that's pretty weird. -Eric > before xfs_repair, the mounted fs was empty, not even the ".." for root ! > > thanks, paul. > > From owner-xfs@oss.sgi.com Sat Jun 14 09:52:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:52:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EGqYWM023732 for ; Sat, 14 Jun 2008 09:52:34 -0700 X-ASG-Debug-ID: 1213462411-150500120000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 26A95CBA819 for ; Sat, 14 Jun 2008 09:53:31 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id yB5lX6i93NLE0QbC for ; Sat, 14 Jun 2008 09:53:31 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id D5E68AC6275; Sat, 14 Jun 2008 11:53:30 -0500 (CDT) Message-ID: <4853F78A.1060605@sandeen.net> Date: Sat, 14 Jun 2008 11:53:30 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Dave Littell CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: GRIO for Linux...please! Subject: Re: GRIO for Linux...please! References: <4853CC74.8040206@verizon.net> In-Reply-To: <4853CC74.8040206@verizon.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213462412 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0015 1.0000 -2.0113 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53290 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16347 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Dave Littell wrote: > Hi all, > > Is there any plan (or even hope!) to have GRIO ported to Linux? XFS is > an excellent filesystem in any case, but GRIO would put it head and > shoulders above the competition. GRIOV1 was a highly irix-specific beast... GRIOV2 was quite different, and available on linux but AFAIK there were never any plans to make it GPL. Doesn't hurt to ask I suppose. :) You do have the realtime subvolume on linux, though, which was originally a component of GRIOV1. -Eric > > Thanks, > Dave > > From owner-xfs@oss.sgi.com Sat Jun 14 09:55:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 09:55:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EGteVj024378 for ; Sat, 14 Jun 2008 09:55:40 -0700 X-ASG-Debug-ID: 1213462596-0c0501f40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ug-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0C2D117C5E6D for ; Sat, 14 Jun 2008 09:56:36 -0700 (PDT) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by cuda.sgi.com with ESMTP id 5Xz6W58sT8FI4ju1 for ; Sat, 14 Jun 2008 09:56:36 -0700 (PDT) Received: by ug-out-1314.google.com with SMTP id m3so221502uge.20 for ; Sat, 14 Jun 2008 09:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=VNDcFKTOewML7SXRRQsnt4pfQhcNNoJsFX+d89obg08=; b=Zlat2JgBhyQWgPk3mXk26La13GMU6ZL9zNd/DzqoQ1QLkJRcLnBNC1RSWH2KjyijAg SYqvndxd2QOqVdZhGDDBekJKKZ/iPo2PEADBgTNig68W9bWGbvpcx1bYmln5x+DZtnWR rVXhs6t81m379k5MY6IErfdNw914+jNYKizpQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=qNSm04+Y+hcS2XfM8DR7BzkAEtKMgiHFMZlMNgQnpGMzC9UHyv0WKSbkEWjzqP4YCb cyawWenjft5Sl30KahBfWkC0fmCnFVsKbwv4O2fQXzo1O/UnF1HIQaU2YsLX6byF9uYx SghCZLFNZrK6gSh7/L0nNVkp2Mx0B0xoAfyqU= Received: by 10.67.26.7 with SMTP id d7mr3116034ugj.22.1213462595450; Sat, 14 Jun 2008 09:56:35 -0700 (PDT) Received: by 10.66.218.1 with HTTP; Sat, 14 Jun 2008 09:56:34 -0700 (PDT) Message-ID: Date: Sat, 14 Jun 2008 12:56:34 -0400 From: "Simon J" To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair trouble Subject: xfs_repair trouble MIME-Version: 1.0 X-Barracuda-Connect: ug-out-1314.google.com[66.249.92.169] X-Barracuda-Start-Time: 1213462597 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.95 X-Barracuda-Spam-Status: No, SCORE=0.95 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53291 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 3011 X-archive-position: 16348 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: simonjj@gmail.com Precedence: bulk X-list: xfs Hello all, I have a corrupted xfs filesystem on top of a RAID 5 (1TB in size). The RAID is still fully intact but the filesystem was damaged. When trying to repair the filesystem xfs_repair fails. I have tried various versions of xfs_repair, the latest stable (2.9.8) and the latest trunk (from CVS). I'd love to investigate and/or fix the issue further but I am a bit confused about some of my xfs_repair runs (both done with trunk). Could someone shed some light on where the problem could be, I'd be happy to continue digging if I would only know where roughly Run 1 ============================================ ./xfs_repair -P -m 170 /dev/evms/monster_evms ... more output ... bad hash table for directory inode 4842 (no data entry): rebuilding rebuilding directory inode 4842 entry ".." in directory inode 27930072 points to free inode 2013274702 bad hash table for directory inode 27930072 (no data entry): rebuilding rebuilding directory inode 27930072 bad hash table for directory inode 28776251 (no data entry): rebuilding rebuilding directory inode 28776251 fixing i8count in inode 29111010 xfs_repair: phase6.c:3411: shortform_dir2_entry_check: Assertion `bytes_deleted > 0' failed. Aborted ================================================= Exits with an Assert, it would be interesting to know why this Assert is there and what it means for bytes_deleted to be 0. Run 2 ============================================ ./xfs_repair -P -m 166 /dev/evms/monster_evms ... more output ... bad hash table for directory inode 2013274673 (no data entry): rebuilding rebuilding directory inode 2013274673 bad hash table for directory inode 2029477400 (no data entry): rebuilding rebuilding directory inode 2029477400 bad hash table for directory inode 2037825112 (no data entry): rebuilding rebuilding directory inode 2037825112 fatal error -- malloc failed in longform_dir2_entry_check (2585598792 bytes) ================================================= Exists with an malloc failed, even though I am using the -m option which I think was created to avoid exactly this scenario. Run 3 Run 3 ============================================ ./xfs_repair -P -m 200 /dev/evms/monster_evms ... more output ... - agno = 38 - agno = 39 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... bad hash table for directory inode 4842 (no data entry): rebuilding rebuilding directory inode 4842 bad hash table for directory inode 28776251 (no data entry): rebuilding rebuilding directory inode 28776251 fixing i8count in inode 29111010 corrupt block 0 in directory inode 321685982: junking block Segmentation fault ================================================= Exists with a Seg Fault. I found this one interesting especially since it happens at the exact same inode as Run 1 All comments appreciated. Simon [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Sat Jun 14 10:54:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 10:54:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EHsNJf028363 for ; Sat, 14 Jun 2008 10:54:23 -0700 X-ASG-Debug-ID: 1213466118-2303037e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 46FD3230DE7 for ; Sat, 14 Jun 2008 10:55:19 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 9J6uMDAvZEstudwR for ; Sat, 14 Jun 2008 10:55:19 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5EHtANW021192 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 14 Jun 2008 19:55:10 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5EHtArm021190 for xfs@oss.sgi.com; Sat, 14 Jun 2008 19:55:10 +0200 Date: Sat, 14 Jun 2008 19:55:10 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH, RFC] fix XFSQA 145 / test_hole Subject: [PATCH, RFC] fix XFSQA 145 / test_hole Message-ID: <20080614175510.GA21014@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213466120 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_MJ615 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53295 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_MJ615 Custom Rule MJ615 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16349 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs There are two errors I see all the time in 145: - dm_probe_hole returns EINVAL for offsets close to the file size - dm_probe_hole wants EAGAIN for a probe at offset 1, length 0 The first error is a consequence of how the hole puching / probing works. It always rounds the requested offset up to the next block size and then checks if that rounded offset still fits into the file size. Just do the same rounding in the testcase to make sure we don't probe invalid offsets. The second error is very odd to me, as we never return AGAIN in the whole dm_probe_hole path. I've just commented it out. I've also re-enabled the E2BIG to past-EOF test that was uncommented before because it works perfectly fine now. Signed-off-by: Christoph Hellwig --- xfstests/145.out 19 Dec 2006 02:55:36 -0000 1.1 +++ xfstests/145.out 14 Jun 2008 17:49:49 -0000 @@ -16,13 +16,13 @@ Hole test beginning... Verified hole at 4096 (beginning errno subtests...) report on test for E2BIG in probe (from past EOF): test successful + report on test for E2BIG in probe (to past EOF): test successful report on test for EACCES in no-right probe: test successful report on test for success in SHARED probe: test successful. report on test for success in EXCL probe: test successful. report on test for EACCES in no-right punch: test successful report on test for EACCES in SHARED punch: test successful report on test for success in EXCL punch: test successful. - report on test for EAGAIN in punch: test successful report on test for EBADF in probe: test successful report on test for EBADF in punch: test successful report on test for EFAULT in probe (null handle): test successful --- xfstests/dmapi/src/suite2/src/test_hole.c 9 Nov 2005 02:50:19 -0000 1.8 +++ xfstests/dmapi/src/suite2/src/test_hole.c 14 Jun 2008 17:49:49 -0000 @@ -69,7 +69,7 @@ main( dm_sessid_t sid = DM_NO_SESSION; char *pathname = NULL; char *ls_path = NULL; - dm_off_t offset = 0; + dm_off_t offset = 0, end; dm_off_t ex_off = 0; dm_extent_t extent[20]; u_int nelem; @@ -162,10 +162,16 @@ main( exit(1); } + /* + * The kernel always rounds the offset up to the next block + * size, so we can only probes up to the previous to last block. + */ + end = (29604 / blocksize) * blocksize; + /* Check that dm_probe_hole returns an extent from the next * highest multiple of the block size, to the end of the file */ - for (offset = 0; offset < 29604; offset++) { + for (offset = 0; offset < end; offset++) { if (dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, offset, length, &roff, &rlen)) { fprintf(stdout, "dm_probe_hole failed on pass %lld (%s)\n", @@ -275,15 +281,10 @@ main( dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, 30000, length, &roff, &rlen)) /*---------------------------------------------------------*/ -#if 0 - PROBLEM: No error is produced. - off+len >= filesize should produce E2BIG... - ERRTEST(E2BIG, "probe (to past EOF)", dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, 15000, 150000, &roff, &rlen)) -#endif /*---------------------------------------------------------*/ SHAREDTEST("probe", hanp, hlen, test_token, dm_probe_hole(sid, hanp, hlen, test_token, @@ -292,10 +293,18 @@ main( EXCLTEST("punch", hanp, hlen, test_token, dm_punch_hole(sid, hanp, hlen, test_token, 0, 0)) /*---------------------------------------------------------*/ + /* + * No idea where that EAGAIN should come from, it's never + * returned from the kernel. + * + * -- hch + */ +#if 0 ERRTEST(EAGAIN, "punch", dm_punch_hole(sid, hanp, hlen, DM_NO_TOKEN, 1, length)) +#endif /*---------------------------------------------------------*/ if ((test_vp = handle_clone(hanp, hlen)) == NULL) { fprintf(stderr, From owner-xfs@oss.sgi.com Sat Jun 14 12:22:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 12:22:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EJM1hh005274 for ; Sat, 14 Jun 2008 12:22:01 -0700 X-ASG-Debug-ID: 1213471377-628d029c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6AD8E231D27 for ; Sat, 14 Jun 2008 12:22:57 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 5YsUq2Tuwm6pR1lI for ; Sat, 14 Jun 2008 12:22:57 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5EJMmNW025306 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 14 Jun 2008 21:22:49 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5EJMmrf025304 for xfs@oss.sgi.com; Sat, 14 Jun 2008 21:22:48 +0200 Date: Sat, 14 Jun 2008 21:22:48 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] fix XFSQA 144 Subject: [PATCH] fix XFSQA 144 Message-ID: <20080614192248.GA24329@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213471378 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0405 1.0000 -1.7598 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.76 X-Barracuda-Spam-Status: No, SCORE=-1.76 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53300 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16350 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Two really dumb bugs: - "foo & 0x3FFFFFFFFFFFF" doesn't cap at 1TB, but rather at more than two magnitudes larger than that. That gets us EFBIG with typical 32bit XFS setups. - the command array can easily overflow and thus let the test fail Signed-off-by: Christoph Hellwig Index: xfstests/dmapi/src/suite2/src/test_fileattr.c =================================================================== RCS file: /cvs/xfs-cmds/xfstests/dmapi/src/suite2/src/test_fileattr.c,v retrieving revision 1.12 diff -u -p -r1.12 test_fileattr.c --- xfstests/dmapi/src/suite2/src/test_fileattr.c 21 Sep 2007 04:15:06 -0000 1.12 +++ xfstests/dmapi/src/suite2/src/test_fileattr.c 14 Jun 2008 19:12:43 -0000 @@ -160,7 +160,7 @@ main( char *ls_path; char *pathname; char test_file[100]; - char command[100]; + char command[200]; int num_files=50; dm_stat_t *stat_arr; dm_stat_t dmstat; @@ -244,7 +244,7 @@ main( stat_arr[i].dt_uid=(uid_t)(rand()+rand()*0x10000); stat_arr[i].dt_gid=(gid_t)(rand()+rand()*0x10000); stat_arr[i].dt_mode=(mode_t)((rand()%4096)+32768); - stat_arr[i].dt_size=((dm_off_t)(rand()+rand()*0x10000)) & 0x3FFFFFFFFFFFF; /* 1 TB max */ + stat_arr[i].dt_size=((dm_off_t)(rand()+rand()*0x10000)) & 0x1FFFFFFFFFFULL; /* 1 TB max */ } /*-----------------------------------------------------*\ From owner-xfs@oss.sgi.com Sat Jun 14 12:40:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 12:40:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5EJeKij006588 for ; Sat, 14 Jun 2008 12:40:20 -0700 X-ASG-Debug-ID: 1213472475-731402400000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CDB4417C6036 for ; Sat, 14 Jun 2008 12:41:15 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by cuda.sgi.com with ESMTP id 13ujCbF8xvgPbolB for ; Sat, 14 Jun 2008 12:41:15 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3169346fgb.8 for ; Sat, 14 Jun 2008 12:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=99LTjddslmi6iJqeZ7Ue89eIwkCR5SN2U+6qynDgKSs=; b=dYY2JREtcIl+n7ZupdQQn62jFjCIgBhmsHV/O2Txv8l3DBstgGnBaEqP8kipf9pZeb QthXRQIZLqqRJu/A5sFVo8msdiWJT/NHjVi/V15THc98TBYYs3d377LcWRIP54MEnIgB ungNFy4JNnT07o3ot+Sz6gPN7izX7DYk963YM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=nLCpnVJm1mpCNDdYlbj8h790xO/1aQA7AibVwCOBxyoM61arOJeMhmVY2YmUlE1cSQ tjhGJlN+vd59rDV4Iv01uEKzJuvP/fy1VCzFT9eifUYQRa3Ff2CuPSvQY2OM51jQbpm0 5g1qwrptsDDNnY5EF4AFPZ7HEPolQxCKJeBC8= Received: by 10.86.26.11 with SMTP id 11mr6238077fgz.23.1213472472996; Sat, 14 Jun 2008 12:41:12 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sat, 14 Jun 2008 12:41:12 -0700 (PDT) Message-ID: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> Date: Sat, 14 Jun 2008 21:41:12 +0200 From: "Oliver Pinter" To: "Chris Wright" , "Christoph Hellwig" , stable@kernel.org, xfs@oss.sgi.com, xfs-masters@oss.sgi.com X-ASG-Orig-Subj: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: "Miquel van Smoorenburg" , "Konstantin Kletschke" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.157] X-Barracuda-Start-Time: 1213472476 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0570 1.0000 -1.6558 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.66 X-Barracuda-Spam-Status: No, SCORE=-1.66 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53301 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16351 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg tainted with: nvidia and madwifi kernel: 2.6.25.6 + queue patches (queue head on aa8edcb997ff605bd1424630356866b78ef06cdc) -- Thanks, Oliver From owner-xfs@oss.sgi.com Sat Jun 14 18:52:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 14 Jun 2008 18:52:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5F1qDbQ004043 for ; Sat, 14 Jun 2008 18:52:13 -0700 X-ASG-Debug-ID: 1213494789-0f6b036f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8A1AF23287C; Sat, 14 Jun 2008 18:53:09 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id V1S8rEViMW5fxyp8; Sat, 14 Jun 2008 18:53:09 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 92B15AC6275; Sat, 14 Jun 2008 20:53:08 -0500 (CDT) Message-ID: <48547604.9060700@sandeen.net> Date: Sat, 14 Jun 2008 20:53:08 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: Chris Wright , Christoph Hellwig , stable@kernel.org, xfs@oss.sgi.com, xfs-masters@oss.sgi.com, Miquel van Smoorenburg , Konstantin Kletschke X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> In-Reply-To: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213494790 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53327 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16352 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg > > tainted with: nvidia and madwifi > kernel: 2.6.25.6 + queue patches (queue head on > aa8edcb997ff605bd1424630356866b78ef06cdc) > What sort of remount were you doing? -Eric From owner-xfs@oss.sgi.com Sun Jun 15 05:37:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 05:37:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FCbcY0028359 for ; Sun, 15 Jun 2008 05:37:39 -0700 X-ASG-Debug-ID: 1213533514-2f5b012d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 06460233643 for ; Sun, 15 Jun 2008 05:38:35 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by cuda.sgi.com with ESMTP id c8D3JaqCihCRm8PH for ; Sun, 15 Jun 2008 05:38:35 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3236610fgb.8 for ; Sun, 15 Jun 2008 05:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ANZCvqDyR3wj4ODXTP2FkJsqjt4TEpYtUTp7IJ6dU5M=; b=gBUHgb47uO8IWbKJJVbvboxoRPoHbexyPzNgVh1TKOiCnBOWoNaxfO5DhU2SVWVq+G pZ82pOApy0/D0N64x9bI46nhgPQOPb1+/V3Q4Eyjkgmoe4vXy1fcZPQLau5MmxZ9cFa0 RH5Plo2i0a4Z4tjg2Up8gQR+x5jGyuPmjHxpg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=arml7M4rZDhYH3TxLZSiHq349l90Pzdj5LJKyZ5I1jgW9mmT71gFmAlliYc9xqbAeL NURKEu7WkIl6nH280k8UnQdSl2QBMzf5wT19SKghZ6WT3ZGZRrHik2JTXVb7IiPlSvHP uA6kS2V5Cvm1rAWivI5T1S1k/9fhq2B92hKpU= Received: by 10.86.27.9 with SMTP id a9mr6888083fga.57.1213533513023; Sun, 15 Jun 2008 05:38:33 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 05:38:33 -0700 (PDT) Message-ID: <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> Date: Sun, 15 Jun 2008 14:38:33 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: "Chris Wright" , "Christoph Hellwig" , stable@kernel.org, xfs@oss.sgi.com, xfs-masters@oss.sgi.com, "Miquel van Smoorenburg" , "Konstantin Kletschke" In-Reply-To: <48547604.9060700@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.158] X-Barracuda-Start-Time: 1213533516 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0208 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53368 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16353 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs this mistake shutdownkor comes out, remount launched because he panics, only Alt+Sysrq+foo works On 6/15/08, Eric Sandeen wrote: > Oliver Pinter wrote: >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg >> >> tainted with: nvidia and madwifi >> kernel: 2.6.25.6 + queue patches (queue head on >> aa8edcb997ff605bd1424630356866b78ef06cdc) >> > > What sort of remount were you doing? > > -Eric > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 08:57:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 08:57:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FFvEQ6011045 for ; Sun, 15 Jun 2008 08:57:14 -0700 X-ASG-Debug-ID: 1213545490-2a5302900000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 84A2417C7BF8 for ; Sun, 15 Jun 2008 08:58:10 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id QRvA93vk4GbV2p3H for ; Sun, 15 Jun 2008 08:58:10 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id AC12AAC626E; Sun, 15 Jun 2008 10:58:09 -0500 (CDT) Message-ID: <48553C11.2060606@sandeen.net> Date: Sun, 15 Jun 2008 10:58:09 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> In-Reply-To: <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213545491 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0006 1.0000 -2.0173 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16354 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > this mistake shutdownkor comes out, remount launched because he > panics, only Alt+Sysrq+foo works I'm not sure I follow. Assuming that : http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg is the first event of interest, it is hitting an assertion on the remount path: ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); in xfs_attr_quiesce. Are you saying something else happen before this? If so, what? -Eric > On 6/15/08, Eric Sandeen wrote: >> Oliver Pinter wrote: >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg >>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg >>> >>> tainted with: nvidia and madwifi >>> kernel: 2.6.25.6 + queue patches (queue head on >>> aa8edcb997ff605bd1424630356866b78ef06cdc) >>> >> What sort of remount were you doing? >> >> -Eric >> > > From owner-xfs@oss.sgi.com Sun Jun 15 09:08:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:08:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_72 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FG8Ghs011814 for ; Sun, 15 Jun 2008 09:08:16 -0700 X-ASG-Debug-ID: 1213546152-4b8f02d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 86027CBD058 for ; Sun, 15 Jun 2008 09:09:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by cuda.sgi.com with ESMTP id 04WICle1BBDffa8P for ; Sun, 15 Jun 2008 09:09:12 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3255420fgb.8 for ; Sun, 15 Jun 2008 09:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=O61G5oAAITA8C/GYW1KBnNl7t7SI4RhrzZkiasB7GKc=; b=VzWyqlVWyAj0f5hhPgKoJ0B+xNkXN37I7CeyIhS/HMMOgKZzcTnKw1MFByaeZg0nb8 Gk8Zr7/DZdApnKOzFkNanhk8GZyNPJvWezaQoWW8nxzKKgJ+MzChXRSa9fnWPei4GKd/ cjOz7KxnB/Z3lLqgIL7/rjfJ2ni28KFOLLlRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BZxoRb+lsPOSsHPqXwfdrE8TtvTZTDLSlT3gXxiFtAqQ671Q7OxWQ4J4gseSwcc4Cg TdqAktx96fgPb8Wcf5vJRGV81S2YOkZELdS7z4eG68tW45qzFZMEiI2h/v9bWQJyPyP9 qI3XBX/SAlfoUlsooXwWh7FHEL8SLkcRT1eos= Received: by 10.86.80.5 with SMTP id d5mr7048273fgb.26.1213546151843; Sun, 15 Jun 2008 09:09:11 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 09:09:11 -0700 (PDT) Message-ID: <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> Date: Sun, 15 Jun 2008 18:09:11 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: xfs@oss.sgi.com In-Reply-To: <48553C11.2060606@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.159] X-Barracuda-Start-Time: 1213546153 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4594 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16355 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs this is the debian way of the unmounting the root fs: do_stop () { [ "$VERBOSE" = no ] || log_action_begin_msg "Mounting root filesystem re ad-only" MOUNT_FORCE_OPT= [ "$(uname -s)" = "GNU/kFreeBSD" ] && MOUNT_FORCE_OPT=-f # This: # mount -n -o remount,ro / # will act on a bind mount of / if there is one. # See #339023 and the comment in checkroot.sh mount $MOUNT_FORCE_OPT -n -o remount,ro -t dummytype dummydev / 2>/de v/null \ || mount $MOUNT_FORCE_OPT -n -o remount,ro dummydev / 2>/de v/null \ || mount $MOUNT_FORCE_OPT -n -o remount,ro / ES=$? [ "$VERBOSE" = no ] || log_action_end_msg $ES } On 6/15/08, Eric Sandeen wrote: > Oliver Pinter wrote: >> this mistake shutdownkor comes out, remount launched because he >> panics, only Alt+Sysrq+foo works > > I'm not sure I follow. > > Assuming that : > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg > > is the first event of interest, it is hitting an assertion on the > remount path: > > ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); > > in xfs_attr_quiesce. > > Are you saying something else happen before this? If so, what? > > -Eric > >> On 6/15/08, Eric Sandeen wrote: >>> Oliver Pinter wrote: >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00776.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00777.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00778.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00779.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00780.jpg >>>> http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00781.jpg >>>> >>>> tainted with: nvidia and madwifi >>>> kernel: 2.6.25.6 + queue patches (queue head on >>>> aa8edcb997ff605bd1424630356866b78ef06cdc) >>>> >>> What sort of remount were you doing? >>> >>> -Eric >>> >> >> > > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 09:11:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:11:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FGB64s012247 for ; Sun, 15 Jun 2008 09:11:06 -0700 X-ASG-Debug-ID: 1213546323-4b8e032e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1DA97CBE74B for ; Sun, 15 Jun 2008 09:12:03 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id wcl71DCUzuT0Gk8u for ; Sun, 15 Jun 2008 09:12:03 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 31D6BAC626E; Sun, 15 Jun 2008 11:12:03 -0500 (CDT) Message-ID: <48553F53.7000208@sandeen.net> Date: Sun, 15 Jun 2008 11:12:03 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> In-Reply-To: <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213546324 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0008 1.0000 -2.0158 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16356 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > this is the debian way of the unmounting the root fs: Ok we're slowly getting to useful information. So you were shutting down the system when the panic happened, correct? -Eric From owner-xfs@oss.sgi.com Sun Jun 15 09:13:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:13:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FGDNcC012643 for ; Sun, 15 Jun 2008 09:13:23 -0700 X-ASG-Debug-ID: 1213546459-4b8f03130000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC21ACBE775 for ; Sun, 15 Jun 2008 09:14:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by cuda.sgi.com with ESMTP id E83VlKtwfJDacqVt for ; Sun, 15 Jun 2008 09:14:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3255922fgb.8 for ; Sun, 15 Jun 2008 09:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0y3Z7nhgv9hyc0hv5IrNBL1xtV8TjLUoI2uyRc4Quuo=; b=SCaWtQlpDmxrtKZqUvsZBkikjrAjX2owJ4J8Db1ceMyANS0Nszgb5LVSRXQHXSusFA 2tVrly+ZtO3CiEjFAKJr+vjLR6lfSRvV2vlflpW6aIr+9nLY/vVFMOPcuHaL3X1u6udv 79lhAywJ7T/pZhwUihtcXbJgSuuXUF+2d//Lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=VLCZcaGA1DcS1twgTrGsSQENmGRpe+777VWfLBkP/OSu40M4zYEPyCZ+2ZMhOZzBaK 1smzp3mdUwsTV/cu6UN9Y6GBRic1am2dSWss14kTuUchdAXV5yjjhFz4ihK+7LY0vy/t mjsCFvccMV9GPYKjO9R9JcX6iPcUgcxgXWaRo= Received: by 10.86.80.17 with SMTP id d17mr7036271fgb.33.1213546458347; Sun, 15 Jun 2008 09:14:18 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 09:14:18 -0700 (PDT) Message-ID: <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> Date: Sun, 15 Jun 2008 18:14:18 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: xfs@oss.sgi.com In-Reply-To: <48553F53.7000208@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> <48553F53.7000208@sandeen.net> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.153] X-Barracuda-Start-Time: 1213546460 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4261 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16357 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs sorry, but I did not learn English, is going a little bit slowly in this manner. yeah, under poweroff (init 0) panics the system On 6/15/08, Eric Sandeen wrote: > Oliver Pinter wrote: >> this is the debian way of the unmounting the root fs: > > Ok we're slowly getting to useful information. > > So you were shutting down the system when the panic happened, correct? > > -Eric > > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 09:16:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:16:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FGG4vJ013290 for ; Sun, 15 Jun 2008 09:16:04 -0700 X-ASG-Debug-ID: 1213546621-5b4600a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ECFBF17C78F2 for ; Sun, 15 Jun 2008 09:17:01 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by cuda.sgi.com with ESMTP id ZAWD2GEgLkbW95tB for ; Sun, 15 Jun 2008 09:17:01 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3256188fgb.8 for ; Sun, 15 Jun 2008 09:17:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=t9hLDeMD/kNAqPcGg/Z25iUzA7LJIlk+CIZEittPQps=; b=rtvLQgmSzgOrRySt8xrmZeXwAq/mUAyq90D0n2bmD+lR/bHVE9mxWyEyL97cQFGz2v qrXNRPUv102m5vMCe4QIlZ8jIVUPNuQNTPufKrd9QUEXy9wsOoz+vT70Jzd7nqMRTHEn 9QK08p3sUOtl6CxI85GScnq29mNd/MOc7kuQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=OUpQUIrph5PhnFwEPZ4BdQa8UnB35L5TJL+uZ7nNQVX5qJiuE/bJzz9ZkSPm0d8Eic ej7TueprMk4gp1Ysc3W/SNV5CNoi5y6JFiCqt/hBQvINyeWu+EY6wULoG5W7fjJYpzx5 1iDLk1UuOO7+eyu8dzpR15pnKPRaFYe9G8uAA= Received: by 10.86.82.16 with SMTP id f16mr7076733fgb.9.1213546620801; Sun, 15 Jun 2008 09:17:00 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 09:17:00 -0700 (PDT) Message-ID: <6101e8c40806150917w5d17e31wd8b55e1d38da2411@mail.gmail.com> Date: Sun, 15 Jun 2008 18:17:00 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: xfs@oss.sgi.com In-Reply-To: <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> <48553F53.7000208@sandeen.net> <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.159] X-Barracuda-Start-Time: 1213546621 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1336 1.0000 -1.1949 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.19 X-Barracuda-Spam-Status: No, SCORE=-1.19 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16358 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs hmm, the system have two XFS partition the / (sda4) and /home (sda3) /dev/sda3 on /home type xfs (rw,noexec,nosuid,nodev) /dev/sda4 on / type xfs (rw) On 6/15/08, Oliver Pinter wrote: > sorry, but I did not learn English, is going a little bit slowly in this > manner. > > yeah, under poweroff (init 0) panics the system > > On 6/15/08, Eric Sandeen wrote: >> Oliver Pinter wrote: >>> this is the debian way of the unmounting the root fs: >> >> Ok we're slowly getting to useful information. >> >> So you were shutting down the system when the panic happened, correct? >> >> -Eric >> >> > > > -- > Thanks, > Oliver > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 09:26:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 09:26:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FGQfxf014041 for ; Sun, 15 Jun 2008 09:26:41 -0700 X-ASG-Debug-ID: 1213547257-7bef02070000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fg-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 69C98233D4A for ; Sun, 15 Jun 2008 09:27:38 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by cuda.sgi.com with ESMTP id M4tk6hjm9Y5BJp0D for ; Sun, 15 Jun 2008 09:27:38 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so3257200fgb.8 for ; Sun, 15 Jun 2008 09:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=TERbNxAU+lrjyyW7PS4fn+wvHz4z2EJThby7hsLE2MU=; b=C91lzB9ROXbKw9txEdJpuB6k5Vby565kKPFdyrandhRe0je9QH8h/EZS/1+1GiJ/Ay U8kq7UdpdFFX/XVa+2/ZPJ7s6NvmschA2/OO+r6JOoz7MNpkhjQp8qD6OFUo4OEeCdng IfvbnEFPFxvQPrp17du8ji8cX+9BhqjiFP/Uc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=putUqgfcVh0fxIFGq37oWYyf/DfHxOH8+K4MpBv6vKe4xbPQjnv2bgEZ7Nh6sJGsHf J9ELvDzUAvF0rbQzqxFpjseRQ2BT7iQMQYKO73qD1vqpSgO6fVOG9vcg23JDFxgqhuEm I0Rgd4un7L5WJ4EsVjbc5mnbjryEqWk6t91j4= Received: by 10.86.31.19 with SMTP id e19mr6428856fge.42.1213547256602; Sun, 15 Jun 2008 09:27:36 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Sun, 15 Jun 2008 09:27:36 -0700 (PDT) Message-ID: <6101e8c40806150927g7ec36ad7w92ad0c2eebd85437@mail.gmail.com> Date: Sun, 15 Jun 2008 18:27:36 +0200 From: "Oliver Pinter" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Cc: xfs@oss.sgi.com In-Reply-To: <6101e8c40806150917w5d17e31wd8b55e1d38da2411@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> <48553F53.7000208@sandeen.net> <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> <6101e8c40806150917w5d17e31wd8b55e1d38da2411@mail.gmail.com> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.153] X-Barracuda-Start-Time: 1213547259 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3281 1.0000 -0.2338 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.23 X-Barracuda-Spam-Status: No, SCORE=-0.23 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53383 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16359 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs but now it was him that you say the antecedents apt-get update & upgrade and git-update-tree (is is a script, that updated 3 git tree (linux-2.6, linux-2.6.25.y and stable-queue)) , that is heavy disc i/o with much small files On 6/15/08, Oliver Pinter wrote: > hmm, the system have two XFS partition the / (sda4) and /home (sda3) > > /dev/sda3 on /home type xfs (rw,noexec,nosuid,nodev) > /dev/sda4 on / type xfs (rw) > > On 6/15/08, Oliver Pinter wrote: >> sorry, but I did not learn English, is going a little bit slowly in this >> manner. >> >> yeah, under poweroff (init 0) panics the system >> >> On 6/15/08, Eric Sandeen wrote: >>> Oliver Pinter wrote: >>>> this is the debian way of the unmounting the root fs: >>> >>> Ok we're slowly getting to useful information. >>> >>> So you were shutting down the system when the panic happened, correct? >>> >>> -Eric >>> >>> >> >> >> -- >> Thanks, >> Oliver >> > > > -- > Thanks, > Oliver > -- Thanks, Oliver From owner-xfs@oss.sgi.com Sun Jun 15 11:59:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 11:59:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5FIxmFo023561 for ; Sun, 15 Jun 2008 11:59:48 -0700 X-ASG-Debug-ID: 1213556444-7605014c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from fk-out-0910.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A1E031BA1D98 for ; Sun, 15 Jun 2008 12:00:44 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.185]) by cuda.sgi.com with ESMTP id TrBxlp7oyZCTl4H0 for ; Sun, 15 Jun 2008 12:00:44 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 26so3471289fkx.4 for ; Sun, 15 Jun 2008 12:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=FoYlgcZh9oHfTPcg37yVSIelaz7Q7sbPvWmLfz70iwc=; b=xX9ISO4J3qRCjUCng8UplTvItSbAYMoUtNySJifb/B7DU4iWB4/vfyXL1HqRc5nO3B Jzfa/e+Ww3UnfcHa/4rzswtbCM+Pc3M/F9SSa9TaEsHxmVSKtkmv/blXXUNc/Bk/Z7sz /hFqzgO2+yDNcIyeVhDxMHgD6gnLfzoimi9Ao= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=Aoyk9aLw7PR9nOrDxOhXdbijofSm8JrZU9ImXPzlSfOeQZ5HSzEmtsOSIpWpiXTMfh ta/cpvLX+Vd2DfdBAK5jKHC0i8RWlWyIwPz4wClAAErVYJH/FNT7pClp/7dYf/4PjPw/ QqSnLjZpf1sEGfvypBDBOak7F20xGFrog/ai4= Received: by 10.78.144.11 with SMTP id r11mr2271785hud.49.1213556443707; Sun, 15 Jun 2008 12:00:43 -0700 (PDT) Received: by 10.78.142.16 with HTTP; Sun, 15 Jun 2008 12:00:43 -0700 (PDT) Message-ID: <74d4a1e10806151200u4f00f0c5xa18e36ab5925ca77@mail.gmail.com> Date: Sun, 15 Jun 2008 21:00:43 +0200 From: "Paul Guermonprez" To: "Eric Sandeen" X-ASG-Orig-Subj: Re: xfs_repair aborting ... dir2.c:2133 Subject: Re: xfs_repair aborting ... dir2.c:2133 Cc: xfs@oss.sgi.com In-Reply-To: <4853F70F.6010400@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <74d4a1e10806140124s3ed8dfa6x7e5ca656fea0e06e@mail.gmail.com> <4853F70F.6010400@sandeen.net> X-Google-Sender-Auth: 3a608eeb448819aa X-Barracuda-Connect: fk-out-0910.google.com[209.85.128.185] X-Barracuda-Start-Time: 1213556445 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4024 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53395 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16360 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: paul@guermonprez.eu Precedence: bulk X-list: xfs hello, > Do you mean that you did xfsrestore on a previous dump and then tried to > repair the resulting filesystem? Maybe the dump was corrupt? i used dd to copy the xfs part of the original raid disk to my new disk. in this ss4000e box, xfs partitions are contained in a big partition "IPSTOR" (built on a raid linear) with a XML descriptor of start/end/... for logical partitions inside. so using regular tools was not a option as regular partitions are not seen. the dd step seems to work fine, but of course i could always try several times and see if the output is the same. the output seems like a regular xfs partition, xfs_repair then mounted as a loop and got what i was able to get from lost+found. > If you are willing to provide an xfs_metadump image, Barry would > probably look into it for you :) xfs_metadup has been running for more than 6 hours now (xfs_db at 100% on a recent desktop CPU) and still running. and all i have is a 230kb file, so i posted it here : http://dl.free.fr/nHuj52ETY/xfs_metadump.bz2 in theory the important part of the disk contains about 50 folders, with 50 tif files of 30Mo in each, plus other stuff. tried the lastest version, now using 400%, nice but same result. > Did anything interesting go wrong before your fs got so mangled? as i was using this box, i wasn't in contact with the filesystem, all i can say is that the raid is OK and the disk seem OK too. ( i know it's stupid to use such a box where everything is hidden won't do it again ! ) the last thing was probably a crach of the system, and impossibility to reboot the embedded OS of the thing with the drives in. > xfsrestore did this? that's pretty weird. xfs_repair did this. i used dd to copy the data but again i can't be totally sure of what kind of strange XFS version IPSTOR is using, perhaps it is not even standard ??? tried to contact them with no luck. in fact i am trying to exploit my miserable situation to write a rescue guide for this box, but this last xfs problem is blocking me, so thanks a lot for your help. thanks, paul. From owner-xfs@oss.sgi.com Sun Jun 15 18:10:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 18:10:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G1AiDd022583 for ; Sun, 15 Jun 2008 18:10:45 -0700 X-ASG-Debug-ID: 1213578700-532002fc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 246A81B33405 for ; Sun, 15 Jun 2008 18:11:40 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id erH60O8DUdzKk7Fb for ; Sun, 15 Jun 2008 18:11:40 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 1F51CAC626E; Sun, 15 Jun 2008 20:11:40 -0500 (CDT) Message-ID: <4855BDCB.3030103@sandeen.net> Date: Sun, 15 Jun 2008 20:11:39 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Oliver Pinter CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <6101e8c40806150909s4f9b95d2u685c09a0ba3767e3@mail.gmail.com> <48553F53.7000208@sandeen.net> <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> In-Reply-To: <6101e8c40806150914k1226611ej52b20b7bb9ffa9d5@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213578702 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0113 1.0000 -1.9474 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.95 X-Barracuda-Spam-Status: No, SCORE=-1.95 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53419 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16361 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Oliver Pinter wrote: > sorry, but I did not learn English, is going a little bit slowly in this manner. That's, ok, it's just useful to know what you were doing when it panicked. I'm sure you speak english better than I speak you native language ;) > yeah, under poweroff (init 0) panics the system Hm, interesting. > but now it was him that you say the antecedents apt-get update & > upgrade and git-update-tree (is is a script, that updated 3 git tree > (linux-2.6, linux-2.6.25.y and stable-queue)) , that is heavy disc i/o > with much small files So, you had a lot of IO just before shutdown? -Eric > On 6/15/08, Eric Sandeen wrote: >> Oliver Pinter wrote: >>> this is the debian way of the unmounting the root fs: >> Ok we're slowly getting to useful information. >> >> So you were shutting down the system when the panic happened, correct? >> >> -Eric >> >> > > From owner-xfs@oss.sgi.com Sun Jun 15 19:04:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 19:04:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5G2431g026509 for ; Sun, 15 Jun 2008 19:04:05 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10436; Mon, 16 Jun 2008 12:04:50 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 0068258C4C3F; Mon, 16 Jun 2008 12:04:49 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 983102 - XFS case-insensitive: Assertion Failed: xfs_dir2_sf_lookup(args) == ENOENT Message-Id: <20080616020450.0068258C4C3F@chook.melbourne.sgi.com> Date: Mon, 16 Jun 2008 12:04:49 +1000 (EST) From: bnaujok@sgi.com (Barry Naujok) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16362 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs The vfs_unlink/d_delete functionality in the Linux VFS make the dentry negative if it is the only inode being referenced. Case-insensitive mode doesn't work with negative dentries, so if using CI-mode, invalidate the dentry on unlink/rmdir. Date: Mon Jun 16 12:04:04 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/2.6.x-xfs Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31308a fs/xfs/linux-2.6/xfs_iops.c - 1.289 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.289&r2=text&tr2=1.288&f=h - Invalidate dentry in unlink/rmdir if in CI mode From owner-xfs@oss.sgi.com Sun Jun 15 19:17:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 19:17:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5G2HH02027669 for ; Sun, 15 Jun 2008 19:17:19 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA10702; Mon, 16 Jun 2008 12:18:07 +1000 Message-ID: <4855CE2D.70505@sgi.com> Date: Mon, 16 Jun 2008 12:21:33 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] Always reset btree cursor after an insert Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16363 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs After a btree insert operation a cursor can be invalid due to block splits and a maybe a new root block. We reset the cursor in xfs_bmbt_insert() in the cases where we think we need to but it isn't enough as we still see assertions. Just do what we do elsewhere and reset the cursor unconditionally. Lachlan --- fs/xfs/xfs_bmap.c_1.392 2008-06-03 12:20:14.000000000 +1000 +++ fs/xfs/xfs_bmap.c 2008-06-16 12:11:47.000000000 +1000 @@ -1745,11 +1745,17 @@ xfs_bmap_add_extent_unwritten_real( if ((error = xfs_bmbt_insert(cur, &i))) goto done; ASSERT(i == 1); - if ((error = xfs_bmbt_increment(cur, 0, &i))) + /* + * Reset the cursor, don't trust it after any insert + * operation. + */ + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, + new->br_startblock, new->br_blockcount, + &i))) goto done; - ASSERT(i == 1); + ASSERT(i == 0); /* new middle extent - newext */ - cur->bc_rec.b = *new; + cur->bc_rec.b.br_state = new->br_state; if ((error = xfs_bmbt_insert(cur, &i))) goto done; ASSERT(i == 1); From owner-xfs@oss.sgi.com Sun Jun 15 20:14:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 20:14:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5G3EaYY030761 for ; Sun, 15 Jun 2008 20:14:38 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA11555; Mon, 16 Jun 2008 13:15:20 +1000 Message-ID: <4855DB96.9030208@sgi.com> Date: Mon, 16 Jun 2008 13:18:46 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs-dev , xfs-oss Subject: Re: [PATCH] fix extent corruption in xfs_iext_irec_compact_full() References: <48522031.5060700@sgi.com> <20080613132304.GA28190@infradead.org> In-Reply-To: <20080613132304.GA28190@infradead.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16364 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 13, 2008 at 05:22:25PM +1000, Lachlan McIlroy wrote: >> This function is used to compact the indirect extent list by moving >> extents from one page to the previous to fill them up. After we >> move some extents to an earlier page we need to shuffle the remaining >> extents to the start of the page. The actual bug here is the second >> argument to memmove() needs to index past the extents, that were copied >> to the previous page, and move the remaining extents. For pages that >> are already full (ie ext_avail == 0) the compaction code has no net >> effect so don't do it. >> >> Thanks to Dave Chinner for pointing out the bug. > > > Looks good but this function needs a lot more comments. Below is a > version of the patch with some more comments describing what's going > on that I came up with when trying to understand what this patch does > in detail: Thanks Christoph. > > > Index: linux-2.6-xfs/fs/xfs/xfs_inode.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2008-06-13 14:58:33.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2008-06-13 15:15:25.000000000 +0200 > @@ -4532,39 +4532,63 @@ xfs_iext_irec_compact_full( > int nlists; /* number of irec's (ex lists) */ > > ASSERT(ifp->if_flags & XFS_IFEXTIREC); > + > nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; > erp = ifp->if_u1.if_ext_irec; > ep = &erp->er_extbuf[erp->er_extcount]; > erp_next = erp + 1; > ep_next = erp_next->er_extbuf; > + > while (erp_idx < nlists - 1) { > + /* > + * Check how many extent records are available in this irec. > + * If there is none skip the whole exercise. > + */ > ext_avail = XFS_LINEAR_EXTS - erp->er_extcount; > - ext_diff = MIN(ext_avail, erp_next->er_extcount); > - memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); > - erp->er_extcount += ext_diff; > - erp_next->er_extcount -= ext_diff; > - /* Remove next page */ > - if (erp_next->er_extcount == 0) { > + if (ext_avail) { > + > + /* > + * Copy over as many as possible extent records into > + * the previous page. > + */ > + ext_diff = MIN(ext_avail, erp_next->er_extcount); > + memcpy(ep, ep_next, ext_diff * sizeof(xfs_bmbt_rec_t)); > + erp->er_extcount += ext_diff; > + erp_next->er_extcount -= ext_diff; > + > /* > - * Free page before removing extent record > - * so er_extoffs don't get modified in > - * xfs_iext_irec_remove. > + * If the next irec is empty now we can simply > + * remove it. > */ > - kmem_free(erp_next->er_extbuf); > - erp_next->er_extbuf = NULL; > - xfs_iext_irec_remove(ifp, erp_idx + 1); > - erp = &ifp->if_u1.if_ext_irec[erp_idx]; > - nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; > - /* Update next page */ > - } else { > - /* Move rest of page up to become next new page */ > - memmove(erp_next->er_extbuf, ep_next, > - erp_next->er_extcount * sizeof(xfs_bmbt_rec_t)); > - ep_next = erp_next->er_extbuf; > - memset(&ep_next[erp_next->er_extcount], 0, > - (XFS_LINEAR_EXTS - erp_next->er_extcount) * > - sizeof(xfs_bmbt_rec_t)); > + if (erp_next->er_extcount == 0) { > + /* > + * Free page before removing extent record > + * so er_extoffs don't get modified in > + * xfs_iext_irec_remove. > + */ > + kmem_free(erp_next->er_extbuf); > + erp_next->er_extbuf = NULL; > + xfs_iext_irec_remove(ifp, erp_idx + 1); > + erp = &ifp->if_u1.if_ext_irec[erp_idx]; > + nlists = ifp->if_real_bytes / XFS_IEXT_BUFSZ; > + > + /* > + * If the next irec is not empty move up the content > + * that has not been copied to the previous page to > + * the beggining of this one. > + */ > + } else { > + memmove(erp_next->er_extbuf, &ep_next[ext_diff], > + erp_next->er_extcount * > + sizeof(xfs_bmbt_rec_t)); > + ep_next = erp_next->er_extbuf; > + memset(&ep_next[erp_next->er_extcount], 0, > + (XFS_LINEAR_EXTS - > + erp_next->er_extcount) * > + sizeof(xfs_bmbt_rec_t)); > + } > } > + > if (erp->er_extcount == XFS_LINEAR_EXTS) { > erp_idx++; > if (erp_idx < nlists) > From owner-xfs@oss.sgi.com Sun Jun 15 20:53:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 20:53:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G3rfeW005076 for ; Sun, 15 Jun 2008 20:53:41 -0700 X-ASG-Debug-ID: 1213588475-18df01810000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 0636E17C849B for ; Sun, 15 Jun 2008 20:54:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id uvWmRmhYY6vtEOFm for ; Sun, 15 Jun 2008 20:54:36 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA12325; Mon, 16 Jun 2008 13:54:27 +1000 Message-ID: <4855E4C0.4090309@sgi.com> Date: Mon, 16 Jun 2008 13:57:52 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613134418.GA31720@infradead.org> In-Reply-To: <20080613134418.GA31720@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213588479 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53429 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16365 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: >> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), >> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs >> for the space needed. Since we have reserved the space these allocations >> are now guaranteed to succeed. > > This looks good and makes lot of sense to me. Please also add a comment > to enum xfs_alloctype in xfs_alloc.h about the danger of the allocation > types that never go out of the AG when used inside transactions. The flags already have comments? Are you referring specifically to the fact we have reserved space somewhere in the filesystem but expect to find it in a single AG? > >> In order to search all AGs I had to revert >> a change made to xfs_alloc_vextent() that prevented a search from looking >> at AGs lower than the starting AG. This original change was made to prevent >> out of order AG locking when allocating multiple extents on data writeout >> but since we only allocate one extent at a time now this particular problem >> can't happen. > > This one also makes sense, but I have a very bad gut feeling about it. > There's nothing preventing the same deadlock scenario from coming back > when people modify the highlevel data allocator again. We really need > some sort of assert to trigger early in that case to not got a nasty > hard to trigger deadlock. Yes I agree. I was thinking about making the allocation of a second data extent in the same transaction a conditional try operation to avoid the deadlock. If a caller to the allocator provides room to return more than one extent then I don't think we have to return more than one - multiple extents in one transaction is just an optimisation. > >> + if (++(args->agno) == mp->m_sb.sb_agcount) > > and while we're at it this should be > > if (++args->agno == mp->m_sb.sb_agcount) Done, thanks. From owner-xfs@oss.sgi.com Sun Jun 15 21:44:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 21:44:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G4igVo008603 for ; Sun, 15 Jun 2008 21:44:42 -0700 X-ASG-Debug-ID: 1213591527-57a7006c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id D9488CC179B for ; Sun, 15 Jun 2008 21:45:37 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id sy57TCE3TJvK7KLw for ; Sun, 15 Jun 2008 21:45:37 -0700 (PDT) Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13485; Mon, 16 Jun 2008 14:45:23 +1000 To: Simon , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair trouble Subject: Re: xfs_repair trouble From: "Barry Naujok" Organization: SGI Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: Content-Transfer-Encoding: 7bit Date: Mon, 16 Jun 2008 14:47:04 +1000 Message-ID: In-Reply-To: User-Agent: Opera Mail/9.24 (Win32) X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213591539 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4158 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53434 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16366 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs On Sun, 15 Jun 2008 02:43:12 +1000, Simon wrote: > Hello all, > > > I have a corrupted xfs filesystem on top of a RAID 5 (1TB in size). > The RAID is still fully intact but the filesystem was damaged. When > trying to repair the filesystem xfs_repair fails. I have tried various > versions of xfs_repair, the latest stable (2.9.8) and the latest trunk > (from CVS). I'd love to investigate and/or fix the issue further but I > am a bit confused about some of my xfs_repair runs (both done with > trunk). > Could someone shed some light on where the problem could be, I'd be > happy to continue digging if I would only know where roughly Are you able to generate an xfs_metadump? If you can make that available, I should be able to find out the problem pretty easily. Regards, Barry. From owner-xfs@oss.sgi.com Sun Jun 15 21:51:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 21:51:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G4pTpk009428 for ; Sun, 15 Jun 2008 21:51:30 -0700 X-ASG-Debug-ID: 1213591944-22ae032d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 35B8F17C87A7 for ; Sun, 15 Jun 2008 21:52:25 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id hWPmPQ7MJ5DPm0bg for ; Sun, 15 Jun 2008 21:52:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALuLVUh5LG+u/2dsb2JhbACsEg X-IronPort-AV: E=Sophos;i="4.27,650,1204464600"; d="scan'208";a="127310636" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 16 Jun 2008 14:22:22 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K86hZ-0005GP-VS; Mon, 16 Jun 2008 14:52:21 +1000 Date: Mon, 16 Jun 2008 14:52:21 +1000 From: Dave Chinner To: Eric Sandeen Cc: Oliver Pinter , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Message-ID: <20080616045221.GJ3700@disturbed> Mail-Followup-To: Eric Sandeen , Oliver Pinter , xfs@oss.sgi.com References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48553C11.2060606@sandeen.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213591946 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1613 1.0000 -1.0380 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.04 X-Barracuda-Spam-Status: No, SCORE=-1.04 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53429 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16367 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Sun, Jun 15, 2008 at 10:58:09AM -0500, Eric Sandeen wrote: > Oliver Pinter wrote: > > this mistake shutdownkor comes out, remount launched because he > > panics, only Alt+Sysrq+foo works > > I'm not sure I follow. > > Assuming that : > http://students.zipernowsky.hu/~oliverp/upload/xfs_error/dsc00775.jpg > > is the first event of interest, it is hitting an assertion on the > remount path: > > ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); > > in xfs_attr_quiesce. That's caused by a race condition in the VFS w.r.t setting the MS_RDONLY flag. It should be fixed in 2.6.26. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 15 22:00:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 22:00:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G50uhW010362 for ; Sun, 15 Jun 2008 22:00:57 -0700 X-ASG-Debug-ID: 1213592513-189e01a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60820234D2A for ; Sun, 15 Jun 2008 22:01:53 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id n3AEG1ixUiPVIvo8 for ; Sun, 15 Jun 2008 22:01:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAECPVUh5LG+u/2dsb2JhbACsHA X-IronPort-AV: E=Sophos;i="4.27,650,1204464600"; d="scan'208";a="127318039" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 16 Jun 2008 14:31:52 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K86qk-0005SF-PN; Mon, 16 Jun 2008 15:01:50 +1000 Date: Mon, 16 Jun 2008 15:01:50 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert Message-ID: <20080616050150.GK3700@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <4855CE2D.70505@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4855CE2D.70505@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213592514 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53435 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16368 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 16, 2008 at 12:21:33PM +1000, Lachlan McIlroy wrote: > After a btree insert operation a cursor can be invalid due to block > splits and a maybe a new root block. We reset the cursor in > xfs_bmbt_insert() in the cases where we think we need to but it > isn't enough as we still see assertions. Just do what we do elsewhere > and reset the cursor unconditionally. Ok, so you should also kill the new code in the btree insert that revalidates the btree cursor. IIRC, this was the only place it was needed for.... > --- fs/xfs/xfs_bmap.c_1.392 2008-06-03 12:20:14.000000000 +1000 > +++ fs/xfs/xfs_bmap.c 2008-06-16 12:11:47.000000000 +1000 > @@ -1745,11 +1745,17 @@ xfs_bmap_add_extent_unwritten_real( > if ((error = xfs_bmbt_insert(cur, &i))) > goto done; > ASSERT(i == 1); > - if ((error = xfs_bmbt_increment(cur, 0, &i))) > + /* > + * Reset the cursor, don't trust it after any insert > + * operation. > + */ /* * reset the cursor to the position of the new extent we are about * to insert as we can't trust it after the previous insert */ > + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, > + new->br_startblock, new->br_blockcount, > + &i))) > goto done; error = xfs_bmbt_lookup_eq(cur, new->br_startoff, br_startblock, new->br_blockcount, &i); if (error) goto done; > - ASSERT(i == 1); > + ASSERT(i == 0); ASSERT? How about a WANT_CORRUPTED_GOTO()? > /* new middle extent - newext */ > - cur->bc_rec.b = *new; > + cur->bc_rec.b.br_state = new->br_state; > if ((error = xfs_bmbt_insert(cur, &i))) > goto done; > ASSERT(i == 1); Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 15 23:06:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:06:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G66t9a015146 for ; Sun, 15 Jun 2008 23:06:55 -0700 X-ASG-Debug-ID: 1213596469-2d4002450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 681E02350C7 for ; Sun, 15 Jun 2008 23:07:50 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id ociSLFtR0V60inVo for ; Sun, 15 Jun 2008 23:07:50 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15237; Mon, 16 Jun 2008 16:07:43 +1000 Message-ID: <485603FD.2080204@sgi.com> Date: Mon, 16 Jun 2008 16:11:09 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> In-Reply-To: <20080613155708.GG3700@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213596473 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53439 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16369 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: >> When at ENOSPC conditions extent btree block allocations can fail and we >> have no error handling to undo partial btree operations. Prior to extent >> btree operations we reserve enough disk blocks somewhere in the filesystem >> to satisfy the operation but in some conditions we require the blocks to >> come from specific AGs and if those AGs are full the allocation fails. >> >> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), >> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs >> for the space needed. Since we have reserved the space these allocations >> are now guaranteed to succeed. > > Sure, but we didn't reserve space for potential btree splits in a > second AG as a result of this. That needs to be reserved in the > transaction as well, which will blow out transaction reservations > substantially as we'll need to add another 2 full AGF btree splits to > every transaction that modifies the bmap btree. Right. And most of the time we wont need the space either so it's a real waste. > >> In order to search all AGs I had to revert >> a change made to xfs_alloc_vextent() that prevented a search from looking >> at AGs lower than the starting AG. This original change was made to prevent >> out of order AG locking when allocating multiple extents on data writeout >> but since we only allocate one extent at a time now this particular problem >> can't happen. > > You missed the fact that the AGF of modified AGs is already held > locked in the transaction, hence the locking order within the > transaction is wrong. Also, if we modify the free list in an AG > the fail an allocation (e.g. can't do an exact allocation), we'll > have multiple dirty and locked AGFs in the one allocation. Hence > we still can have locking order violations if you remove that check > and therefore deadlocks. I'm well aware of that particular deadlock involving the freelist - I hit it while testing. If you look closely at the code that deadlock can occur with or without the AG locking avoidance logic. This is because the rest of the transaction is unaware that an AG has been locked due to a freelist operation. > > This is not the solution to the problem. As I suggested (back when > you first floated this idea as a fix for the problem several weeks > ago) I think the bug is that we are not taking into account the > number of blocks required for a bmbt split when selecting an AG to > allocate from. All we take into account is the blocks required for > the extent to be allocated and nothing else. If we take the blocks > for a bmbt split into account then we'll never try to allocate an > extent in an AG that we can't also allocate all the blocks for the > bmbt split in at the same time. > I considered that approach (using the minleft field in xfs_alloc_arg_t) but it has it's problems too. When we reserve space for the btree operations it is done on the global filesystem counters, not a particular AG, so there is the possibility that not one AG has sufficent space to perform the allocation even though there is enough free space in the whole filesystem. Of course if we have enough space left in one AG and the AG is locked then the space we reserved doesn't matter anymore and it should all work. I'm worried with this approach that we could have delayed allocations and unwritten extents that need to be converted but we can't do it because we don't have the space we might need (but probably don't). From owner-xfs@oss.sgi.com Sun Jun 15 23:17:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:17:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G6Hsnm016391 for ; Sun, 15 Jun 2008 23:17:55 -0700 X-ASG-Debug-ID: 1213597129-113602320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3BB191BA25DF for ; Sun, 15 Jun 2008 23:18:49 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id m3rVx5Ea4o5wQF1C for ; Sun, 15 Jun 2008 23:18:49 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5G6IdNW005401 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2008 08:18:39 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5G6Idum005399 for xfs@oss.sgi.com; Mon, 16 Jun 2008 08:18:39 +0200 Date: Mon, 16 Jun 2008 08:18:39 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] merge xfs_rmdir into xfs_remove Subject: Re: [PATCH 1/2] merge xfs_rmdir into xfs_remove Message-ID: <20080616061839.GA5230@lst.de> References: <20080502105757.GB17870@lst.de> <20080521082548.GB3215@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080521082548.GB3215@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213597131 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53439 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16370 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Wed, May 21, 2008 at 10:25:48AM +0200, Christoph Hellwig wrote: > On Fri, May 02, 2008 at 12:57:57PM +0200, Christoph Hellwig wrote: > > xfs_remove and xfs_rmdir are almost the same with a little more work > > performed in xfs_rmdir due to the . and .. entries. This patch merges > > xfs_rmdir into xfs_remove and performs these actions conditionally. > > > > Also clean up the error handling which was a nightmare in both versions > > before. > > Updated for the case-insensitive filename changes. And another update for the d_invalidate added on unlink/rmdir. Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-06-16 08:11:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-06-16 08:14:16.000000000 +0200 @@ -2116,13 +2116,6 @@ again: #endif } -#ifdef DEBUG -#define REMOVE_DEBUG_TRACE(x) {remove_which_error_return = (x);} -int remove_which_error_return = 0; -#else /* ! DEBUG */ -#define REMOVE_DEBUG_TRACE(x) -#endif /* ! DEBUG */ - int xfs_remove( xfs_inode_t *dp, @@ -2131,6 +2124,7 @@ xfs_remove( { xfs_mount_t *mp = dp->i_mount; xfs_trans_t *tp = NULL; + int is_dir = S_ISDIR(ip->i_d.di_mode); int error = 0; xfs_bmap_free_t free_list; xfs_fsblock_t first_block; @@ -2138,8 +2132,11 @@ xfs_remove( int committed; int link_zero; uint resblks; + uint trans; + uint log_count; xfs_itrace_entry(dp); + xfs_itrace_entry(ip); if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); @@ -2152,19 +2149,25 @@ xfs_remove( return error; } - xfs_itrace_entry(ip); - xfs_itrace_ref(ip); - error = XFS_QM_DQATTACH(mp, dp, 0); - if (!error) - error = XFS_QM_DQATTACH(mp, ip, 0); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); + if (error) + goto std_return; + + error = XFS_QM_DQATTACH(mp, ip, 0); + if (error) goto std_return; + + if (is_dir) { + trans = XFS_TRANS_RMDIR; + log_count = XFS_DEFAULT_LOG_COUNT; + } else { + trans = XFS_TRANS_REMOVE; + log_count = XFS_REMOVE_LOG_COUNT; } - tp = xfs_trans_alloc(mp, XFS_TRANS_REMOVE); + tp = xfs_trans_alloc(mp, trans); cancel_flags = XFS_TRANS_RELEASE_LOG_RES; + /* * We try to get the real space reservation first, * allowing for directory btree deletion(s) implying @@ -2176,25 +2179,21 @@ xfs_remove( */ resblks = XFS_REMOVE_SPACE_RES(mp); error = xfs_trans_reserve(tp, resblks, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_REMOVE_LOG_COUNT); + XFS_TRANS_PERM_LOG_RES, log_count); if (error == ENOSPC) { resblks = 0; error = xfs_trans_reserve(tp, 0, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_REMOVE_LOG_COUNT); + XFS_TRANS_PERM_LOG_RES, log_count); } if (error) { ASSERT(error != ENOSPC); - REMOVE_DEBUG_TRACE(__LINE__); - xfs_trans_cancel(tp, 0); - return error; + cancel_flags = 0; + goto out_trans_cancel; } error = xfs_lock_dir_and_entry(dp, ip); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - xfs_trans_cancel(tp, cancel_flags); - goto std_return; - } + if (error) + goto out_trans_cancel; /* * At this point, we've gotten both the directory and the entry @@ -2207,6 +2206,21 @@ xfs_remove( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); /* + * If we're removing a directory perform some additional validation. + */ + if (is_dir) { + ASSERT(ip->i_d.di_nlink >= 2); + if (ip->i_d.di_nlink != 2) { + error = XFS_ERROR(ENOTEMPTY); + goto out_trans_cancel; + } + if (!xfs_dir_isempty(ip)) { + error = XFS_ERROR(ENOTEMPTY); + goto out_trans_cancel; + } + } + + /* * Entry must exist since we did a lookup in xfs_lock_dir_and_entry. */ XFS_BMAP_INIT(&free_list, &first_block); @@ -2214,39 +2228,64 @@ xfs_remove( &first_block, &free_list, resblks); if (error) { ASSERT(error != ENOENT); - REMOVE_DEBUG_TRACE(__LINE__); - goto error1; + goto out_bmap_cancel; } xfs_ichgtime(dp, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); + /* + * Bump the in memory generation count on the parent + * directory so that other can know that it has changed. + */ dp->i_gen++; xfs_trans_log_inode(tp, dp, XFS_ILOG_CORE); - error = xfs_droplink(tp, ip); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - goto error1; + if (is_dir) { + /* + * Drop the link from ip's "..". + */ + error = xfs_droplink(tp, dp); + if (error) + goto out_bmap_cancel; + + /* + * Drop the link from dp to ip. + */ + error = xfs_droplink(tp, ip); + if (error) + goto out_bmap_cancel; + } else { + /* + * When removing a non-directory we need to log the parent + * inode here for the i_gen update. For a directory this is + * done implicitly by the xfs_droplink call for the ".." entry. + */ + xfs_trans_log_inode(tp, dp, XFS_ILOG_CORE); } - /* Determine if this is the last link while + /* + * Drop the "." link from ip to self. + */ + error = xfs_droplink(tp, ip); + if (error) + goto out_bmap_cancel; + + /* + * Determine if this is the last link while * we are in the transaction. */ - link_zero = (ip)->i_d.di_nlink==0; + link_zero = (ip->i_d.di_nlink == 0); /* * If this is a synchronous mount, make sure that the * remove transaction goes to disk before returning to * the user. */ - if (mp->m_flags & (XFS_MOUNT_WSYNC|XFS_MOUNT_DIRSYNC)) { + if (mp->m_flags & (XFS_MOUNT_WSYNC|XFS_MOUNT_DIRSYNC)) xfs_trans_set_sync(tp); - } error = xfs_bmap_finish(&tp, &free_list, &committed); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - goto error_rele; - } + if (error) + goto out_bmap_cancel; error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); if (error) @@ -2258,39 +2297,27 @@ xfs_remove( * will get killed on last close in xfs_close() so we don't * have to worry about that. */ - if (link_zero && xfs_inode_is_filestream(ip)) + if (!is_dir && link_zero && xfs_inode_is_filestream(ip)) xfs_filestream_deassociate(ip); xfs_itrace_exit(ip); + xfs_itrace_exit(dp); -/* Fall through to std_return with error = 0 */ std_return: if (DM_EVENT_ENABLED(dp, DM_EVENT_POSTREMOVE)) { - (void) XFS_SEND_NAMESP(mp, DM_EVENT_POSTREMOVE, - dp, DM_RIGHT_NULL, - NULL, DM_RIGHT_NULL, - name->name, NULL, ip->i_d.di_mode, error, 0); + XFS_SEND_NAMESP(mp, DM_EVENT_POSTREMOVE, dp, DM_RIGHT_NULL, + NULL, DM_RIGHT_NULL, name->name, NULL, + ip->i_d.di_mode, error, 0); } + return error; - error1: + out_bmap_cancel: xfs_bmap_cancel(&free_list); cancel_flags |= XFS_TRANS_ABORT; + out_trans_cancel: xfs_trans_cancel(tp, cancel_flags); goto std_return; - - error_rele: - /* - * In this case make sure to not release the inode until after - * the current transaction is aborted. Releasing it beforehand - * can cause us to go to xfs_inactive and start a recursive - * transaction which can easily deadlock with the current one. - */ - xfs_bmap_cancel(&free_list); - cancel_flags |= XFS_TRANS_ABORT; - xfs_trans_cancel(tp, cancel_flags); - - goto std_return; } int @@ -2656,186 +2683,6 @@ std_return: } int -xfs_rmdir( - xfs_inode_t *dp, - struct xfs_name *name, - xfs_inode_t *cdp) -{ - xfs_mount_t *mp = dp->i_mount; - xfs_trans_t *tp; - int error; - xfs_bmap_free_t free_list; - xfs_fsblock_t first_block; - int cancel_flags; - int committed; - int last_cdp_link; - uint resblks; - - xfs_itrace_entry(dp); - - if (XFS_FORCED_SHUTDOWN(mp)) - return XFS_ERROR(EIO); - - if (DM_EVENT_ENABLED(dp, DM_EVENT_REMOVE)) { - error = XFS_SEND_NAMESP(mp, DM_EVENT_REMOVE, - dp, DM_RIGHT_NULL, - NULL, DM_RIGHT_NULL, name->name, - NULL, cdp->i_d.di_mode, 0, 0); - if (error) - return XFS_ERROR(error); - } - - /* - * Get the dquots for the inodes. - */ - error = XFS_QM_DQATTACH(mp, dp, 0); - if (!error) - error = XFS_QM_DQATTACH(mp, cdp, 0); - if (error) { - REMOVE_DEBUG_TRACE(__LINE__); - goto std_return; - } - - tp = xfs_trans_alloc(mp, XFS_TRANS_RMDIR); - cancel_flags = XFS_TRANS_RELEASE_LOG_RES; - /* - * We try to get the real space reservation first, - * allowing for directory btree deletion(s) implying - * possible bmap insert(s). If we can't get the space - * reservation then we use 0 instead, and avoid the bmap - * btree insert(s) in the directory code by, if the bmap - * insert tries to happen, instead trimming the LAST - * block from the directory. - */ - resblks = XFS_REMOVE_SPACE_RES(mp); - error = xfs_trans_reserve(tp, resblks, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_DEFAULT_LOG_COUNT); - if (error == ENOSPC) { - resblks = 0; - error = xfs_trans_reserve(tp, 0, XFS_REMOVE_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_DEFAULT_LOG_COUNT); - } - if (error) { - ASSERT(error != ENOSPC); - cancel_flags = 0; - goto error_return; - } - XFS_BMAP_INIT(&free_list, &first_block); - - /* - * Now lock the child directory inode and the parent directory - * inode in the proper order. This will take care of validating - * that the directory entry for the child directory inode has - * not changed while we were obtaining a log reservation. - */ - error = xfs_lock_dir_and_entry(dp, cdp); - if (error) { - xfs_trans_cancel(tp, cancel_flags); - goto std_return; - } - - IHOLD(dp); - xfs_trans_ijoin(tp, dp, XFS_ILOCK_EXCL); - - IHOLD(cdp); - xfs_trans_ijoin(tp, cdp, XFS_ILOCK_EXCL); - - ASSERT(cdp->i_d.di_nlink >= 2); - if (cdp->i_d.di_nlink != 2) { - error = XFS_ERROR(ENOTEMPTY); - goto error_return; - } - if (!xfs_dir_isempty(cdp)) { - error = XFS_ERROR(ENOTEMPTY); - goto error_return; - } - - error = xfs_dir_removename(tp, dp, name, cdp->i_ino, - &first_block, &free_list, resblks); - if (error) - goto error1; - - xfs_ichgtime(dp, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); - - /* - * Bump the in memory generation count on the parent - * directory so that other can know that it has changed. - */ - dp->i_gen++; - - /* - * Drop the link from cdp's "..". - */ - error = xfs_droplink(tp, dp); - if (error) { - goto error1; - } - - /* - * Drop the link from dp to cdp. - */ - error = xfs_droplink(tp, cdp); - if (error) { - goto error1; - } - - /* - * Drop the "." link from cdp to self. - */ - error = xfs_droplink(tp, cdp); - if (error) { - goto error1; - } - - /* Determine these before committing transaction */ - last_cdp_link = (cdp)->i_d.di_nlink==0; - - /* - * If this is a synchronous mount, make sure that the - * rmdir transaction goes to disk before returning to - * the user. - */ - if (mp->m_flags & (XFS_MOUNT_WSYNC|XFS_MOUNT_DIRSYNC)) { - xfs_trans_set_sync(tp); - } - - error = xfs_bmap_finish (&tp, &free_list, &committed); - if (error) { - xfs_bmap_cancel(&free_list); - xfs_trans_cancel(tp, (XFS_TRANS_RELEASE_LOG_RES | - XFS_TRANS_ABORT)); - goto std_return; - } - - error = xfs_trans_commit(tp, XFS_TRANS_RELEASE_LOG_RES); - if (error) { - goto std_return; - } - - - /* Fall through to std_return with error = 0 or the errno - * from xfs_trans_commit. */ - std_return: - if (DM_EVENT_ENABLED(dp, DM_EVENT_POSTREMOVE)) { - (void) XFS_SEND_NAMESP(mp, DM_EVENT_POSTREMOVE, - dp, DM_RIGHT_NULL, - NULL, DM_RIGHT_NULL, - name->name, NULL, cdp->i_d.di_mode, - error, 0); - } - return error; - - error1: - xfs_bmap_cancel(&free_list); - cancel_flags |= XFS_TRANS_ABORT; - /* FALLTHROUGH */ - - error_return: - xfs_trans_cancel(tp, cancel_flags); - goto std_return; -} - -int xfs_symlink( xfs_inode_t *dp, struct xfs_name *link_name, Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-16 08:14:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-16 08:15:00.000000000 +0200 @@ -252,8 +252,7 @@ STATIC void xfs_cleanup_inode( struct inode *dir, struct inode *inode, - struct dentry *dentry, - int mode) + struct dentry *dentry) { struct xfs_name teardown; @@ -264,10 +263,7 @@ xfs_cleanup_inode( */ xfs_dentry_to_name(&teardown, dentry); - if (S_ISDIR(mode)) - xfs_rmdir(XFS_I(dir), &teardown, XFS_I(inode)); - else - xfs_remove(XFS_I(dir), &teardown, XFS_I(inode)); + xfs_remove(XFS_I(dir), &teardown, XFS_I(inode)); iput(inode); } @@ -349,7 +345,7 @@ xfs_vn_mknod( return -error; out_cleanup_inode: - xfs_cleanup_inode(dir, inode, dentry, mode); + xfs_cleanup_inode(dir, inode, dentry); out_free_acl: if (default_acl) _ACL_FREE(default_acl); @@ -525,38 +521,12 @@ xfs_vn_symlink( return 0; out_cleanup_inode: - xfs_cleanup_inode(dir, inode, dentry, 0); + xfs_cleanup_inode(dir, inode, dentry); out: return -error; } STATIC int -xfs_vn_rmdir( - struct inode *dir, - struct dentry *dentry) -{ - struct inode *inode = dentry->d_inode; - struct xfs_name name; - int error; - - xfs_dentry_to_name(&name, dentry); - - error = xfs_rmdir(XFS_I(dir), &name, XFS_I(inode)); - if (likely(!error)) { - xfs_validate_fields(inode); - xfs_validate_fields(dir); - /* - * With rmdir, the VFS makes the dentry "negative": no inode, - * but still hashed. This is incompatible with case-insensitive - * mode, so invalidate (unhash) the dentry in CI-mode. - */ - if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) - d_invalidate(dentry); - } - return -error; -} - -STATIC int xfs_vn_rename( struct inode *odir, struct dentry *odentry, @@ -850,7 +820,13 @@ static const struct inode_operations xfs .unlink = xfs_vn_unlink, .symlink = xfs_vn_symlink, .mkdir = xfs_vn_mkdir, - .rmdir = xfs_vn_rmdir, + /* + * Yes, XFS uses the same method for rmdir and unlink. + * + * There are some subtile differences deeper in the code, + * but we use S_ISDIR to check for those. + */ + .rmdir = xfs_vn_unlink, .mknod = xfs_vn_mknod, .rename = xfs_vn_rename, .permission = xfs_vn_permission, @@ -869,7 +845,13 @@ static const struct inode_operations xfs .unlink = xfs_vn_unlink, .symlink = xfs_vn_symlink, .mkdir = xfs_vn_mkdir, - .rmdir = xfs_vn_rmdir, + /* + * Yes, XFS uses the same method for rmdir and unlink. + * + * There are some subtile differences deeper in the code, + * but we use S_ISDIR to check for those. + */ + .rmdir = xfs_vn_unlink, .mknod = xfs_vn_mknod, .rename = xfs_vn_rename, .permission = xfs_vn_permission, Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2008-06-16 08:11:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2008-06-16 08:14:16.000000000 +0200 @@ -31,8 +31,6 @@ int xfs_link(struct xfs_inode *tdp, stru struct xfs_name *target_name); int xfs_mkdir(struct xfs_inode *dp, struct xfs_name *dir_name, mode_t mode, struct xfs_inode **ipp, struct cred *credp); -int xfs_rmdir(struct xfs_inode *dp, struct xfs_name *name, - struct xfs_inode *cdp); int xfs_readdir(struct xfs_inode *dp, void *dirent, size_t bufsize, xfs_off_t *offset, filldir_t filldir); int xfs_symlink(struct xfs_inode *dp, struct xfs_name *link_name, From owner-xfs@oss.sgi.com Sun Jun 15 23:24:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:24:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G6OPgC017137 for ; Sun, 15 Jun 2008 23:24:25 -0700 X-ASG-Debug-ID: 1213597521-57ab01c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 49D24CC1D62 for ; Sun, 15 Jun 2008 23:25:22 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id BXy3T3Z0g7qyuTOr for ; Sun, 15 Jun 2008 23:25:22 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5G6PDNW005930 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2008 08:25:13 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5G6PD6G005927 for xfs@oss.sgi.com; Mon, 16 Jun 2008 08:25:13 +0200 Date: Mon, 16 Jun 2008 08:25:13 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] don't update i_size for directories and special files Subject: Re: [PATCH] don't update i_size for directories and special files Message-ID: <20080616062513.GA5842@lst.de> References: <20080518130707.GB28501@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080518130707.GB28501@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213597523 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53440 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16371 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Sun, May 18, 2008 at 03:07:07PM +0200, Christoph Hellwig wrote: > The core kernel uses vfs_getattr to look at the inode size and similar > attributes, so there is no need to keep i_size uptodate for directories > or special files. This means we can remove xfs_validate_fields because > the I/O path already keeps i_size uptodate for regular files. > Updated for the d_invalidate added on unlink/rmdir. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-16 08:15:00.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-16 08:20:56.000000000 +0200 @@ -188,23 +188,6 @@ xfs_ichgtime_fast( mark_inode_dirty_sync(inode); } - -/* - * Pull the link count and size up from the xfs inode to the linux inode - */ -STATIC void -xfs_validate_fields( - struct inode *inode) -{ - struct xfs_inode *ip = XFS_I(inode); - loff_t size; - - /* we're under i_sem so i_size can't change under us */ - size = XFS_ISIZE(ip); - if (i_size_read(inode) != size) - i_size_write(inode, size); -} - /* * Hook in SELinux. This is not quite correct yet, what we really need * here (as we do for default ACLs) is a mechanism by which creation of @@ -338,10 +321,7 @@ xfs_vn_mknod( } - if (S_ISDIR(mode)) - xfs_validate_fields(inode); d_instantiate(dentry, inode); - xfs_validate_fields(dir); return -error; out_cleanup_inode: @@ -457,7 +437,6 @@ xfs_vn_link( } xfs_iflags_set(XFS_I(dir), XFS_IMODIFIED); - xfs_validate_fields(inode); d_instantiate(dentry, inode); return 0; } @@ -467,26 +446,23 @@ xfs_vn_unlink( struct inode *dir, struct dentry *dentry) { - struct inode *inode; struct xfs_name name; int error; - inode = dentry->d_inode; xfs_dentry_to_name(&name, dentry); - error = xfs_remove(XFS_I(dir), &name, XFS_I(inode)); - if (likely(!error)) { - xfs_validate_fields(dir); /* size needs update */ - xfs_validate_fields(inode); - /* - * With unlink, the VFS makes the dentry "negative": no inode, - * but still hashed. This is incompatible with case-insensitive - * mode, so invalidate (unhash) the dentry in CI-mode. - */ - if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) - d_invalidate(dentry); - } - return -error; + error = -xfs_remove(XFS_I(dir), &name, XFS_I(dentry->d_inode)); + if (error) + return error; + + /* + * With unlink, the VFS makes the dentry "negative": no inode, + * but still hashed. This is incompatible with case-insensitive + * mode, so invalidate (unhash) the dentry in CI-mode. + */ + if (xfs_sb_version_hasasciici(&XFS_M(dir->i_sb)->m_sb)) + d_invalidate(dentry); + return 0; } STATIC int @@ -516,8 +492,6 @@ xfs_vn_symlink( goto out_cleanup_inode; d_instantiate(dentry, inode); - xfs_validate_fields(dir); - xfs_validate_fields(inode); return 0; out_cleanup_inode: @@ -536,22 +510,13 @@ xfs_vn_rename( struct inode *new_inode = ndentry->d_inode; struct xfs_name oname; struct xfs_name nname; - int error; xfs_dentry_to_name(&oname, odentry); xfs_dentry_to_name(&nname, ndentry); - error = xfs_rename(XFS_I(odir), &oname, XFS_I(odentry->d_inode), + return -xfs_rename(XFS_I(odir), &oname, XFS_I(odentry->d_inode), XFS_I(ndir), &nname, new_inode ? XFS_I(new_inode) : NULL); - if (likely(!error)) { - if (new_inode) - xfs_validate_fields(new_inode); - xfs_validate_fields(odir); - if (ndir != odir) - xfs_validate_fields(ndir); - } - return -error; } /* From owner-xfs@oss.sgi.com Sun Jun 15 23:25:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:25:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G6Pk6Q017540 for ; Sun, 15 Jun 2008 23:25:46 -0700 X-ASG-Debug-ID: 1213597602-708400750000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2F961235148 for ; Sun, 15 Jun 2008 23:26:43 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id YiiCHG0b4qDDgmkZ for ; Sun, 15 Jun 2008 23:26:43 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5G6QYNW006023 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2008 08:26:34 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5G6QYep006021 for xfs@oss.sgi.com; Mon, 16 Jun 2008 08:26:34 +0200 Date: Mon, 16 Jun 2008 08:26:34 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] kill XFS_PURGE_INODE Subject: [PATCH] kill XFS_PURGE_INODE Message-ID: <20080616062634.GA5971@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213597604 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53440 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16372 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Just a useless alias for IRELE. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c 2008-06-05 20:21:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c 2008-06-05 20:22:37.000000000 +0200 @@ -444,11 +444,11 @@ xfs_qm_unmount_quotas( } } if (uqp) { - XFS_PURGE_INODE(uqp); + IRELE(uqp); mp->m_quotainfo->qi_uquotaip = NULL; } if (gqp) { - XFS_PURGE_INODE(gqp); + IRELE(gqp); mp->m_quotainfo->qi_gquotaip = NULL; } out: @@ -1239,11 +1239,11 @@ xfs_qm_destroy_quotainfo( xfs_qm_list_destroy(&qi->qi_dqlist); if (qi->qi_uquotaip) { - XFS_PURGE_INODE(qi->qi_uquotaip); + IRELE(qi->qi_uquotaip); qi->qi_uquotaip = NULL; /* paranoia */ } if (qi->qi_gquotaip) { - XFS_PURGE_INODE(qi->qi_gquotaip); + IRELE(qi->qi_gquotaip); qi->qi_gquotaip = NULL; } mutex_destroy(&qi->qi_quotaofflock); @@ -1393,7 +1393,7 @@ xfs_qm_qino_alloc( * locked exclusively and joined to the transaction already. */ ASSERT(xfs_isilocked(*ip, XFS_ILOCK_EXCL)); - VN_HOLD(XFS_ITOV((*ip))); + IHOLD(*ip); /* * Make the changes in the superblock, and log those too. Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2008-05-23 09:31:39.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-05 20:21:09.000000000 +0200 @@ -362,11 +362,11 @@ xfs_qm_scall_quotaoff( * if we don't need them anymore. */ if ((dqtype & XFS_QMOPT_UQUOTA) && XFS_QI_UQIP(mp)) { - XFS_PURGE_INODE(XFS_QI_UQIP(mp)); + IRELE(XFS_QI_UQIP(mp)); XFS_QI_UQIP(mp) = NULL; } if ((dqtype & (XFS_QMOPT_GQUOTA|XFS_QMOPT_PQUOTA)) && XFS_QI_GQIP(mp)) { - XFS_PURGE_INODE(XFS_QI_GQIP(mp)); + IRELE(XFS_QI_GQIP(mp)); XFS_QI_GQIP(mp) = NULL; } out_error: Index: linux-2.6-xfs/fs/xfs/quota/xfs_quota_priv.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_quota_priv.h 2008-05-23 09:31:39.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_quota_priv.h 2008-06-05 20:21:09.000000000 +0200 @@ -158,9 +158,6 @@ for ((dqp) = (qlist)->qh_next; (dqp) != #define XFS_IS_SUSER_DQUOT(dqp) \ (!((dqp)->q_core.d_id)) -#define XFS_PURGE_INODE(ip) \ - IRELE(ip); - #define DQFLAGTO_TYPESTR(d) (((d)->dq_flags & XFS_DQ_USER) ? "USR" : \ (((d)->dq_flags & XFS_DQ_GROUP) ? "GRP" : \ (((d)->dq_flags & XFS_DQ_PROJ) ? "PRJ":"???"))) From owner-xfs@oss.sgi.com Sun Jun 15 23:36:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 15 Jun 2008 23:37:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G6axf3018635 for ; Sun, 15 Jun 2008 23:36:59 -0700 X-ASG-Debug-ID: 1213598274-627800230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 25BCC1BA27EC for ; Sun, 15 Jun 2008 23:37:55 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id nSZmtqJacC1QCxSp for ; Sun, 15 Jun 2008 23:37:55 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15918; Mon, 16 Jun 2008 16:37:49 +1000 Message-ID: <48560B0B.3060204@sgi.com> Date: Mon, 16 Jun 2008 16:41:15 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert References: <4855CE2D.70505@sgi.com> <20080616050150.GK3700@disturbed> In-Reply-To: <20080616050150.GK3700@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213598277 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4211 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53441 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16373 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Mon, Jun 16, 2008 at 12:21:33PM +1000, Lachlan McIlroy wrote: >> After a btree insert operation a cursor can be invalid due to block >> splits and a maybe a new root block. We reset the cursor in >> xfs_bmbt_insert() in the cases where we think we need to but it >> isn't enough as we still see assertions. Just do what we do elsewhere >> and reset the cursor unconditionally. > > Ok, so you should also kill the new code in the btree insert that > revalidates the btree cursor. IIRC, this was the only place it was > needed for.... That was the plan. > >> --- fs/xfs/xfs_bmap.c_1.392 2008-06-03 12:20:14.000000000 +1000 >> +++ fs/xfs/xfs_bmap.c 2008-06-16 12:11:47.000000000 +1000 >> @@ -1745,11 +1745,17 @@ xfs_bmap_add_extent_unwritten_real( >> if ((error = xfs_bmbt_insert(cur, &i))) >> goto done; >> ASSERT(i == 1); >> - if ((error = xfs_bmbt_increment(cur, 0, &i))) >> + /* >> + * Reset the cursor, don't trust it after any insert >> + * operation. >> + */ > > /* > * reset the cursor to the position of the new extent we are about > * to insert as we can't trust it after the previous insert > */ Fair enough. > >> + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, >> + new->br_startblock, new->br_blockcount, >> + &i))) >> goto done; > > > error = xfs_bmbt_lookup_eq(cur, new->br_startoff, > br_startblock, new->br_blockcount, &i); > if (error) > goto done; > >> - ASSERT(i == 1); >> + ASSERT(i == 0); > > ASSERT? How about a WANT_CORRUPTED_GOTO()? I was just being consistent with the rest of the code. If you think this ASSERT should be changed then what about all of them? > >> /* new middle extent - newext */ >> - cur->bc_rec.b = *new; >> + cur->bc_rec.b.br_state = new->br_state; >> if ((error = xfs_bmbt_insert(cur, &i))) >> goto done; >> ASSERT(i == 1); > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Mon Jun 16 02:11:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 02:11:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_51, NORMAL_HTTP_TO_IP,UPPERCASE_50_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5G9BCBf005409 for ; Mon, 16 Jun 2008 02:11:12 -0700 X-ASG-Debug-ID: 1213607526-48c902b90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bay0-omc2-s23.bay0.hotmail.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D628B11D3097 for ; Mon, 16 Jun 2008 02:12:06 -0700 (PDT) Received: from bay0-omc2-s23.bay0.hotmail.com (bay0-omc2-s23.bay0.hotmail.com [65.54.246.159]) by cuda.sgi.com with ESMTP id lObAfXGa95sokLQq for ; Mon, 16 Jun 2008 02:12:06 -0700 (PDT) Received: from hotmail.com ([65.54.174.78]) by bay0-omc2-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jun 2008 02:12:06 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 16 Jun 2008 02:12:05 -0700 Message-ID: Received: from 85.32.103.134 by BAY103-DAV6.phx.gbl with DAV; Mon, 16 Jun 2008 09:12:03 +0000 X-Originating-IP: [85.32.103.134] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: Cc: X-ASG-Orig-Subj: XFS: 2.6.26-rc6 link count mismatch for inode Subject: XFS: 2.6.26-rc6 link count mismatch for inode Date: Mon, 16 Jun 2008 11:11:31 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 16 Jun 2008 09:12:05.0938 (UTC) FILETIME=[0C0C0120:01C8CF91] X-Barracuda-Connect: bay0-omc2-s23.bay0.hotmail.com[65.54.246.159] X-Barracuda-Start-Time: 1213607526 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.93 X-Barracuda-Spam-Status: No, SCORE=-0.93 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, MSGID_FROM_MTA_HEADER, NORMAL_HTTP_TO_IP, UPPERCASE_50_75 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53442 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.59 UPPERCASE_50_75 message body is 50-75% uppercase 0.50 BSF_RULE7568M Custom Rule 7568M 0.00 MSGID_FROM_MTA_HEADER Message-Id was added by a relay X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16374 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Hi Folk, I was tring to compile firefox 3.0rc3 and while I was erasing a previous /tmp/mozilla tree, I started a new tar xjf mozilla-blabla. After a while linux 2.6.26-rc6 was unresponsive: I have unplugged the power cable. No problem at startup, but: root@Venus:/tmp# rm -r mozilla/ rm: cannot remove `mozilla//netwerk/build/.deps': No such file or directory rm: cannot remove `mozilla//netwerk/resources/content/CVS': No such file or directory root@Venus:/tmp/mozilla/netwerk# rm -r build rm: cannot remove `build/.deps': No such file or directory root@Venus:/tmp/mozilla/netwerk# cd build/ root@Venus:/tmp/mozilla/netwerk/build# rm -r .deps rm: cannot remove `.deps': No such file or directory root@Venus:/tmp/mozilla/netwerk/build# ls -fl /bin/ls: cannot access .deps: No such file or directory total 0 drwxr-xr-x 3 root root 18 2008-06-16 10:03 ./ drwxr-xr-x 4 root root 34 2008-06-16 10:03 ../ ?????????? ? ? ? ? ? .deps so, I have checked the filesystem with: xfs_check /dev/sda2: bad format 1 for inode 70353 type 0 bad format 2 for inode 98831 type 0 agi unlinked bucket 13 is 10573 in ag 0 (inode=10573) agi unlinked bucket 6 is 1309318 in ag 1 (inode=18086534) agi unlinked bucket 7 is 1309319 in ag 1 (inode=18086535) agi unlinked bucket 40 is 471720 in ag 2 (inode=34026152) bad format 1 for inode 85450805 type 0 bad format 2 for inode 85450806 type 0 bad format 2 for inode 85450807 type 0 bad format 2 for inode 85450808 type 0 bad format 2 for inode 85450809 type 0 block 0/6279 type unknown not expected block 0/6280 type unknown not expected block 0/6281 type unknown not expected block 0/6282 type unknown not expected block 0/6283 type unknown not expected block 0/6284 type unknown not expected block 0/6285 type unknown not expected block 5/97840 type unknown not expected block 5/97841 type unknown not expected block 5/97842 type unknown not expected block 5/97843 type unknown not expected link count mismatch for inode 70353 (name ?), nlink 0, counted 1 allocated inode 98831 has 0 link count allocated inode 10573 has 0 link count allocated inode 18086534 has 0 link count allocated inode 18086535 has 0 link count link count mismatch for inode 19893187 (name ?), nlink 3, counted 2 allocated inode 34026152 has 0 link count link count mismatch for inode 67179727 (name ?), nlink 3, counted 2 link count mismatch for inode 85450805 (name ?), nlink 0, counted 1 allocated inode 85450806 has 0 link count allocated inode 85450807 has 0 link count allocated inode 85450808 has 0 link count allocated inode 85450809 has 0 link count I have not run xfs_repair. If anyone need ssh access to the box just drop me a message. Metadump available at: http://80.204.235.230/metadump.bin.bz2 and xfs_check verbose: http://80.204.235.230/xfs_check_log.bz2 Linux Venus 2.6.26-rc6 #1 SMP PREEMPT Fri Jun 13 13:01:19 CEST 2008 i686 Intel(R ) Core(TM)2 Duo CPU T8100 @ 2.10GHz GenuineIntel GNU/Linux Gnu C 4.2.3 Gnu make 3.81 binutils 2.17.50.0.17.20070615 util-linux 2.13.1 mount 2.13.1 module-init-tools 3.4 e2fsprogs 1.40.8 xfsprogs 2.9.7 pcmciautils 014 PPP 2.4.4 Linux C Library 2.7 Dynamic linker (ldd) 2.7 Linux C++ Library 6.0.9 Procps 3.2.7 Net-tools 1.60 Kbd 1.12 oprofile 0.9.2 Sh-utils 6.9 Modules Loaded ext2 snd_seq_oss snd_seq_device snd_seq_midi_event snd_se q snd_pcm_oss snd_mixer_oss snd_hda_intel snd_pcm snd_timer snd soundcore snd_pa ge_alloc pcmcia crc32 yenta_socket rsrc_nonstatic pcmcia_core battery ac ppp_syn ctty ppp_deflate zlib_deflate zlib_inflate ppp_async crc_ccitt bsd_comp ppp_gene ric slhc intel_agp ohci_hcd option usbserial usbcore tg3 psmouse # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26-rc6 # Fri Jun 13 13:13:53 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_FAST_CMPXCHG_LOCAL=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_HWEIGHT=y # CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y # CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_SYSFS_DEPRECATED_V2 is not set # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_CLASSIC_RCU=y # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set # CONFIG_PARAVIRT_GUEST is not set # CONFIG_M386 is not set # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set CONFIG_MCORE2=y # CONFIG_GENERIC_CPU is not set # CONFIG_X86_GENERIC is not set CONFIG_X86_CPU=y CONFIG_X86_CMPXCHG=y CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_XADD=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_GOOD_APIC=y CONFIG_X86_INTEL_USERCOPY=y CONFIG_X86_USE_PPRO_CHECKSUM=y CONFIG_X86_P6_NOP=y CONFIG_X86_TSC=y CONFIG_X86_MINIMUM_CPU_FAMILY=6 CONFIG_X86_DEBUGCTLMSR=y CONFIG_HPET_TIMER=y CONFIG_DMI=y # CONFIG_IOMMU_HELPER is not set CONFIG_NR_CPUS=2 # CONFIG_SCHED_SMT is not set CONFIG_SCHED_MC=y # CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set CONFIG_PREEMPT=y # CONFIG_PREEMPT_RCU is not set CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set CONFIG_VM86=y # CONFIG_TOSHIBA is not set # CONFIG_I8K is not set # CONFIG_X86_REBOOTFIXUPS is not set # CONFIG_MICROCODE is not set # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 CONFIG_HIGHMEM=y CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_PAGEFLAGS_EXTENDED=y CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y # CONFIG_HIGHPTE is not set # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_X86_PAT is not set # CONFIG_EFI is not set # CONFIG_IRQBALANCE is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 # CONFIG_SCHED_HRTICK is not set # CONFIG_KEXEC is not set CONFIG_PHYSICAL_START=0x100000 CONFIG_PHYSICAL_ALIGN=0x200000 # CONFIG_COMPAT_VDSO is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SUSPEND is not set # CONFIG_HIBERNATION is not set CONFIG_ACPI=y CONFIG_ACPI_PROCFS=y CONFIG_ACPI_PROCFS_POWER=y # CONFIG_ACPI_SYSFS_POWER is not set # CONFIG_ACPI_PROC_EVENT is not set CONFIG_ACPI_AC=m CONFIG_ACPI_BATTERY=m CONFIG_ACPI_BUTTON=m CONFIG_ACPI_FAN=m CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set # CONFIG_ACPI_CUSTOM_DSDT is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y CONFIG_ACPI_SBS=m # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # CONFIG_CPU_IDLE is not set # # Bus options (PCI etc.) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set # CONFIG_PCI_GOOLPC is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y # CONFIG_PCI_MSI is not set # CONFIG_PCI_LEGACY is not set # CONFIG_HT_IRQ is not set CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set # CONFIG_MCA is not set # CONFIG_SCx200 is not set # CONFIG_OLPC is not set CONFIG_PCCARD=m # CONFIG_PCMCIA_DEBUG is not set CONFIG_PCMCIA=m # CONFIG_PCMCIA_IOCTL is not set CONFIG_CARDBUS=y # # PC-card bridges # CONFIG_YENTA=m CONFIG_YENTA_O2=y CONFIG_YENTA_RICOH=y CONFIG_YENTA_TI=y CONFIG_YENTA_ENE_TUNE=y CONFIG_YENTA_TOSHIBA=y CONFIG_PD6729=m CONFIG_I82092=m CONFIG_PCCARD_NONSTATIC=m # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_AOUT is not set # CONFIG_BINFMT_MISC is not set # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y CONFIG_NET_KEY=m CONFIG_INET=y # CONFIG_IP_MULTICAST is not set CONFIG_IP_ADVANCED_ROUTER=y CONFIG_ASK_IP_FIB_HASH=y # CONFIG_IP_FIB_TRIE is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_VERBOSE=y # CONFIG_IP_PNP is not set CONFIG_NET_IPIP=m CONFIG_NET_IPGRE=m CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set CONFIG_INET_ESP=m CONFIG_INET_IPCOMP=m CONFIG_INET_XFRM_TUNNEL=m CONFIG_INET_TUNNEL=m CONFIG_INET_XFRM_MODE_TRANSPORT=m CONFIG_INET_XFRM_MODE_TUNNEL=m # CONFIG_INET_XFRM_MODE_BEET is not set # CONFIG_INET_LRO is not set CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" # CONFIG_IP_VS is not set # CONFIG_IPV6 is not set # CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y # CONFIG_NETFILTER_DEBUG is not set CONFIG_NETFILTER_ADVANCED=y # # Core Netfilter Configuration # CONFIG_NETFILTER_NETLINK=m CONFIG_NETFILTER_NETLINK_QUEUE=m CONFIG_NETFILTER_NETLINK_LOG=m CONFIG_NF_CONNTRACK=m CONFIG_NF_CT_ACCT=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_EVENTS=y CONFIG_NF_CT_PROTO_GRE=m CONFIG_NF_CT_PROTO_UDPLITE=m CONFIG_NF_CONNTRACK_AMANDA=m CONFIG_NF_CONNTRACK_FTP=m CONFIG_NF_CONNTRACK_H323=m CONFIG_NF_CONNTRACK_IRC=m CONFIG_NF_CONNTRACK_NETBIOS_NS=m CONFIG_NF_CONNTRACK_PPTP=m CONFIG_NF_CONNTRACK_SIP=m CONFIG_NF_CONNTRACK_TFTP=m CONFIG_NF_CT_NETLINK=m CONFIG_NETFILTER_XTABLES=m CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m CONFIG_NETFILTER_XT_TARGET_CONNMARK=m CONFIG_NETFILTER_XT_TARGET_DSCP=m CONFIG_NETFILTER_XT_TARGET_MARK=m CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m CONFIG_NETFILTER_XT_TARGET_NFLOG=m CONFIG_NETFILTER_XT_TARGET_NOTRACK=m CONFIG_NETFILTER_XT_TARGET_RATEEST=m CONFIG_NETFILTER_XT_TARGET_TRACE=m CONFIG_NETFILTER_XT_TARGET_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_COMMENT=m CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m CONFIG_NETFILTER_XT_MATCH_CONNMARK=m CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m CONFIG_NETFILTER_XT_MATCH_DCCP=m CONFIG_NETFILTER_XT_MATCH_DSCP=m CONFIG_NETFILTER_XT_MATCH_ESP=m CONFIG_NETFILTER_XT_MATCH_HELPER=m CONFIG_NETFILTER_XT_MATCH_IPRANGE=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m CONFIG_NETFILTER_XT_MATCH_QUOTA=m CONFIG_NETFILTER_XT_MATCH_RATEEST=m CONFIG_NETFILTER_XT_MATCH_REALM=m CONFIG_NETFILTER_XT_MATCH_STATE=m CONFIG_NETFILTER_XT_MATCH_STATISTIC=m CONFIG_NETFILTER_XT_MATCH_STRING=m CONFIG_NETFILTER_XT_MATCH_TCPMSS=m CONFIG_NETFILTER_XT_MATCH_TIME=m CONFIG_NETFILTER_XT_MATCH_U32=m CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m # # IP: Netfilter Configuration # CONFIG_NF_CONNTRACK_IPV4=m # CONFIG_NF_CONNTRACK_PROC_COMPAT is not set # CONFIG_IP_NF_QUEUE is not set CONFIG_IP_NF_IPTABLES=m CONFIG_IP_NF_MATCH_RECENT=m CONFIG_IP_NF_MATCH_ECN=m CONFIG_IP_NF_MATCH_AH=m CONFIG_IP_NF_MATCH_TTL=m CONFIG_IP_NF_MATCH_ADDRTYPE=m CONFIG_IP_NF_FILTER=m CONFIG_IP_NF_TARGET_REJECT=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_NF_NAT=m CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=m CONFIG_IP_NF_TARGET_REDIRECT=m CONFIG_IP_NF_TARGET_NETMAP=m CONFIG_NF_NAT_SNMP_BASIC=m CONFIG_NF_NAT_PROTO_GRE=m CONFIG_NF_NAT_PROTO_UDPLITE=m CONFIG_NF_NAT_FTP=m CONFIG_NF_NAT_IRC=m CONFIG_NF_NAT_TFTP=m CONFIG_NF_NAT_AMANDA=m CONFIG_NF_NAT_PPTP=m CONFIG_NF_NAT_H323=m CONFIG_NF_NAT_SIP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_TTL=m CONFIG_IP_NF_RAW=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set # CONFIG_DECNET is not set # CONFIG_LLC2 is not set # CONFIG_IPX is not set # CONFIG_ATALK is not set CONFIG_NET_SCHED=y # # Queueing/Scheduling # # CONFIG_NET_SCH_CBQ is not set CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RR=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m # # Classification # CONFIG_NET_CLS=y CONFIG_NET_CLS_BASIC=m CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m # CONFIG_NET_CLS_RSVP6 is not set CONFIG_NET_CLS_FLOW=m CONFIG_NET_EMATCH=y CONFIG_NET_EMATCH_STACK=32 CONFIG_NET_EMATCH_CMP=m CONFIG_NET_EMATCH_NBYTE=m CONFIG_NET_EMATCH_U32=m CONFIG_NET_EMATCH_META=m CONFIG_NET_EMATCH_TEXT=m CONFIG_NET_CLS_ACT=y CONFIG_NET_ACT_POLICE=m CONFIG_NET_ACT_GACT=m CONFIG_GACT_PROB=y CONFIG_NET_ACT_MIRRED=m CONFIG_NET_ACT_IPT=m CONFIG_NET_ACT_NAT=m CONFIG_NET_ACT_PEDIT=m # CONFIG_NET_ACT_SIMP is not set # CONFIG_NET_CLS_IND is not set CONFIG_NET_SCH_FIFO=y # # Network testing # CONFIG_NET_PKTGEN=m # CONFIG_HAMRADIO is not set # CONFIG_CAN is not set # CONFIG_IRDA is not set # CONFIG_BT is not set CONFIG_FIB_RULES=y # # Wireless # # CONFIG_CFG80211 is not set # CONFIG_WIRELESS_EXT is not set # CONFIG_MAC80211 is not set # CONFIG_IEEE80211 is not set # CONFIG_RFKILL is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y # CONFIG_PREVENT_FIRMWARE_BUILD is not set # CONFIG_FW_LOADER is not set # CONFIG_SYS_HYPERVISOR is not set # CONFIG_CONNECTOR is not set # CONFIG_MTD is not set # CONFIG_PARPORT is not set CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y # CONFIG_BLK_DEV_FD is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=m # CONFIG_BLK_DEV_CRYPTOLOOP is not set # CONFIG_BLK_DEV_NBD is not set # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set # CONFIG_CDROM_PKTCDVD is not set # CONFIG_ATA_OVER_ETH is not set # CONFIG_MISC_DEVICES is not set CONFIG_HAVE_IDE=y CONFIG_IDE=m # CONFIG_BLK_DEV_IDE is not set # CONFIG_BLK_DEV_HD_ONLY is not set # CONFIG_BLK_DEV_HD is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set CONFIG_BLK_DEV_SR=m # CONFIG_BLK_DEV_SR_VENDOR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m # # SCSI Transports # # CONFIG_SCSI_SPI_ATTRS is not set # CONFIG_SCSI_FC_ATTRS is not set # CONFIG_SCSI_ISCSI_ATTRS is not set # CONFIG_SCSI_SAS_LIBSAS is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_LOWLEVEL is not set # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y # CONFIG_SATA_PMP is not set CONFIG_SATA_AHCI=y # CONFIG_SATA_SIL24 is not set CONFIG_ATA_SFF=y # CONFIG_SATA_SVW is not set CONFIG_ATA_PIIX=y # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set # CONFIG_SATA_QSTOR is not set # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SIL is not set # CONFIG_SATA_SIS is not set # CONFIG_SATA_ULI is not set # CONFIG_SATA_VIA is not set # CONFIG_SATA_VITESSE is not set # CONFIG_SATA_INIC162X is not set # CONFIG_PATA_ACPI is not set # CONFIG_PATA_AMD is not set # CONFIG_PATA_ARTOP is not set # CONFIG_PATA_ATIIXP is not set # CONFIG_PATA_CMD64X is not set # CONFIG_PATA_CS5520 is not set # CONFIG_PATA_EFAR is not set # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set # CONFIG_PATA_HPT3X3 is not set # CONFIG_PATA_IT821X is not set # CONFIG_PATA_JMICRON is not set # CONFIG_PATA_TRIFLEX is not set # CONFIG_PATA_MARVELL is not set # CONFIG_PATA_MPIIX is not set # CONFIG_PATA_OLDPIIX is not set # CONFIG_PATA_NETCELL is not set # CONFIG_PATA_PCMCIA is not set # CONFIG_PATA_RZ1000 is not set # CONFIG_PATA_SERVERWORKS is not set # CONFIG_PATA_PDC2027X is not set # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_VIA is not set # CONFIG_PATA_WINBOND is not set # CONFIG_PATA_SCH is not set # CONFIG_MD is not set # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # # # An alternative FireWire stack is available with EXPERIMENTAL=y # # CONFIG_IEEE1394 is not set # CONFIG_I2O is not set # CONFIG_MACINTOSH_DRIVERS is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set CONFIG_IFB=m CONFIG_DUMMY=m # CONFIG_BONDING is not set # CONFIG_EQUALIZER is not set CONFIG_TUN=m # CONFIG_VETH is not set # CONFIG_NET_SB1000 is not set # CONFIG_ARCNET is not set # CONFIG_NET_ETHERNET is not set CONFIG_NETDEV_1000=y # CONFIG_ACENIC is not set # CONFIG_DL2K is not set # CONFIG_E1000 is not set # CONFIG_E1000E is not set # CONFIG_E1000E_ENABLED is not set # CONFIG_IGB is not set # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_R8169 is not set # CONFIG_SIS190 is not set # CONFIG_SKGE is not set # CONFIG_SKY2 is not set # CONFIG_VIA_VELOCITY is not set CONFIG_TIGON3=m CONFIG_BNX2=m # CONFIG_QLA3XXX is not set # CONFIG_NETDEV_10000 is not set # CONFIG_TR is not set # # Wireless LAN # # CONFIG_WLAN_PRE80211 is not set # CONFIG_WLAN_80211 is not set # CONFIG_IWLWIFI_LEDS is not set # # USB Network Adapters # # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set # CONFIG_USB_USBNET is not set # CONFIG_NET_PCMCIA is not set # CONFIG_WAN is not set # CONFIG_FDDI is not set CONFIG_PPP=m CONFIG_PPP_FILTER=y CONFIG_PPP_ASYNC=m CONFIG_PPP_SYNC_TTY=m CONFIG_PPP_DEFLATE=m CONFIG_PPP_BSDCOMP=m # CONFIG_SLIP is not set CONFIG_SLHC=m # CONFIG_NET_FC is not set # CONFIG_NETPOLL is not set # CONFIG_NET_POLL_CONTROLLER is not set # CONFIG_ISDN is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y # CONFIG_INPUT_FF_MEMLESS is not set # CONFIG_INPUT_POLLDEV is not set # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y # CONFIG_INPUT_MOUSEDEV_PSAUX is not set CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set # CONFIG_INPUT_EVDEV is not set # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set # CONFIG_KEYBOARD_XTKBD is not set # CONFIG_KEYBOARD_NEWTON is not set # CONFIG_KEYBOARD_STOWAWAY is not set CONFIG_INPUT_MOUSE=y CONFIG_MOUSE_PS2=m CONFIG_MOUSE_PS2_ALPS=y CONFIG_MOUSE_PS2_LOGIPS2PP=y CONFIG_MOUSE_PS2_SYNAPTICS=y CONFIG_MOUSE_PS2_LIFEBOOK=y CONFIG_MOUSE_PS2_TRACKPOINT=y # CONFIG_MOUSE_PS2_TOUCHKIT is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set # CONFIG_INPUT_TABLET is not set # CONFIG_INPUT_TOUCHSCREEN is not set CONFIG_INPUT_MISC=y CONFIG_INPUT_PCSPKR=m # CONFIG_INPUT_WISTRON_BTNS is not set # CONFIG_INPUT_ATLAS_BTNS is not set # CONFIG_INPUT_ATI_REMOTE is not set # CONFIG_INPUT_ATI_REMOTE2 is not set # CONFIG_INPUT_POWERMATE is not set # CONFIG_INPUT_UINPUT is not set # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y # CONFIG_SERIO_SERPORT is not set # CONFIG_SERIO_CT82C710 is not set # CONFIG_SERIO_PCIPS2 is not set CONFIG_SERIO_LIBPS2=y # CONFIG_SERIO_RAW is not set # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y # CONFIG_VT_HW_CONSOLE_BINDING is not set # CONFIG_DEVKMEM is not set # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # # CONFIG_SERIAL_8250 is not set CONFIG_FIX_EARLYCON_MEM=y # # Non-8250 serial port support # # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # CONFIG_IPMI_HANDLER is not set # CONFIG_HW_RANDOM is not set # CONFIG_NVRAM is not set # CONFIG_RTC is not set # CONFIG_GEN_RTC is not set # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set # # PCMCIA character devices # # CONFIG_SYNCLINK_CS is not set # CONFIG_CARDMAN_4000 is not set # CONFIG_CARDMAN_4040 is not set # CONFIG_IPWIRELESS is not set # CONFIG_MWAVE is not set # CONFIG_PC8736x_GPIO is not set # CONFIG_NSC_GPIO is not set # CONFIG_CS5535_GPIO is not set # CONFIG_RAW_DRIVER is not set # CONFIG_HPET is not set # CONFIG_HANGCHECK_TIMER is not set CONFIG_DEVPORT=y # CONFIG_I2C is not set # CONFIG_SPI is not set # CONFIG_W1 is not set # CONFIG_POWER_SUPPLY is not set # CONFIG_HWMON is not set CONFIG_THERMAL=m # CONFIG_WATCHDOG is not set # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y # CONFIG_SSB is not set # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # CONFIG_HTC_PASIC3 is not set # # Multimedia devices # # # Multimedia core support # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_VIDEO_MEDIA is not set # # Multimedia drivers # # CONFIG_DAB is not set # # Graphics support # CONFIG_AGP=y # CONFIG_AGP_ALI is not set # CONFIG_AGP_ATI is not set # CONFIG_AGP_AMD is not set # CONFIG_AGP_AMD64 is not set CONFIG_AGP_INTEL=m # CONFIG_AGP_NVIDIA is not set # CONFIG_AGP_SIS is not set # CONFIG_AGP_SWORKS is not set # CONFIG_AGP_VIA is not set # CONFIG_AGP_EFFICEON is not set CONFIG_DRM=m # CONFIG_DRM_TDFX is not set # CONFIG_DRM_R128 is not set # CONFIG_DRM_RADEON is not set CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_I915=m # CONFIG_DRM_MGA is not set # CONFIG_DRM_SIS is not set # CONFIG_DRM_VIA is not set # CONFIG_DRM_SAVAGE is not set # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set # CONFIG_FB is not set # CONFIG_BACKLIGHT_LCD_SUPPORT is not set # # Display device support # # CONFIG_DISPLAY_SUPPORT is not set # # Console display driver support # CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set # CONFIG_VIDEO_SELECT is not set CONFIG_DUMMY_CONSOLE=y # # Sound # CONFIG_SOUND=m # # Advanced Linux Sound Architecture # CONFIG_SND=m CONFIG_SND_TIMER=m CONFIG_SND_PCM=m CONFIG_SND_RAWMIDI=m CONFIG_SND_SEQUENCER=m CONFIG_SND_SEQ_DUMMY=m CONFIG_SND_OSSEMUL=y CONFIG_SND_MIXER_OSS=m CONFIG_SND_PCM_OSS=m CONFIG_SND_PCM_OSS_PLUGINS=y CONFIG_SND_SEQUENCER_OSS=y # CONFIG_SND_DYNAMIC_MINORS is not set # CONFIG_SND_SUPPORT_OLD_API is not set CONFIG_SND_VERBOSE_PROCFS=y # CONFIG_SND_VERBOSE_PRINTK is not set # CONFIG_SND_DEBUG is not set CONFIG_SND_VMASTER=y # # Generic devices # CONFIG_SND_MPU401_UART=m CONFIG_SND_DUMMY=m CONFIG_SND_VIRMIDI=m CONFIG_SND_MTPAV=m CONFIG_SND_SERIAL_U16550=m CONFIG_SND_MPU401=m # # PCI devices # # CONFIG_SND_AD1889 is not set # CONFIG_SND_ALS300 is not set # CONFIG_SND_ALS4000 is not set # CONFIG_SND_ALI5451 is not set # CONFIG_SND_ATIIXP is not set # CONFIG_SND_ATIIXP_MODEM is not set # CONFIG_SND_AU8810 is not set # CONFIG_SND_AU8820 is not set # CONFIG_SND_AU8830 is not set # CONFIG_SND_AW2 is not set # CONFIG_SND_BT87X is not set # CONFIG_SND_CA0106 is not set # CONFIG_SND_CMIPCI is not set # CONFIG_SND_OXYGEN is not set # CONFIG_SND_CS4281 is not set # CONFIG_SND_CS46XX is not set # CONFIG_SND_CS5530 is not set # CONFIG_SND_CS5535AUDIO is not set # CONFIG_SND_DARLA20 is not set # CONFIG_SND_GINA20 is not set # CONFIG_SND_LAYLA20 is not set # CONFIG_SND_DARLA24 is not set # CONFIG_SND_GINA24 is not set # CONFIG_SND_LAYLA24 is not set # CONFIG_SND_MONA is not set # CONFIG_SND_MIA is not set # CONFIG_SND_ECHO3G is not set # CONFIG_SND_INDIGO is not set # CONFIG_SND_INDIGOIO is not set # CONFIG_SND_INDIGODJ is not set # CONFIG_SND_EMU10K1 is not set # CONFIG_SND_EMU10K1X is not set # CONFIG_SND_ENS1370 is not set # CONFIG_SND_ENS1371 is not set # CONFIG_SND_ES1938 is not set # CONFIG_SND_ES1968 is not set # CONFIG_SND_FM801 is not set CONFIG_SND_HDA_INTEL=m # CONFIG_SND_HDA_HWDEP is not set # CONFIG_SND_HDA_CODEC_REALTEK is not set CONFIG_SND_HDA_CODEC_ANALOG=y # CONFIG_SND_HDA_CODEC_SIGMATEL is not set # CONFIG_SND_HDA_CODEC_VIA is not set # CONFIG_SND_HDA_CODEC_ATIHDMI is not set # CONFIG_SND_HDA_CODEC_CONEXANT is not set # CONFIG_SND_HDA_CODEC_CMEDIA is not set # CONFIG_SND_HDA_CODEC_SI3054 is not set CONFIG_SND_HDA_GENERIC=y # CONFIG_SND_HDSP is not set # CONFIG_SND_HDSPM is not set # CONFIG_SND_HIFIER is not set # CONFIG_SND_ICE1712 is not set # CONFIG_SND_ICE1724 is not set # CONFIG_SND_INTEL8X0 is not set # CONFIG_SND_INTEL8X0M is not set # CONFIG_SND_KORG1212 is not set # CONFIG_SND_MAESTRO3 is not set # CONFIG_SND_MIXART is not set # CONFIG_SND_NM256 is not set # CONFIG_SND_PCXHR is not set # CONFIG_SND_RIPTIDE is not set # CONFIG_SND_RME32 is not set # CONFIG_SND_RME96 is not set # CONFIG_SND_RME9652 is not set # CONFIG_SND_SIS7019 is not set # CONFIG_SND_SONICVIBES is not set # CONFIG_SND_TRIDENT is not set # CONFIG_SND_VIA82XX is not set # CONFIG_SND_VIA82XX_MODEM is not set # CONFIG_SND_VIRTUOSO is not set # CONFIG_SND_VX222 is not set # CONFIG_SND_YMFPCI is not set # # USB devices # # CONFIG_SND_USB_AUDIO is not set # CONFIG_SND_USB_USX2Y is not set # CONFIG_SND_USB_CAIAQ is not set # # PCMCIA devices # # CONFIG_SND_VXPOCKET is not set # CONFIG_SND_PDAUDIOCF is not set # # System on Chip audio support # # CONFIG_SND_SOC is not set # # ALSA SoC audio for Freescale SOCs # # # SoC Audio for the Texas Instruments OMAP # # # Open Sound System # # CONFIG_SOUND_PRIME is not set CONFIG_HID_SUPPORT=y CONFIG_HID=m # CONFIG_HID_DEBUG is not set # CONFIG_HIDRAW is not set # # USB Input Devices # CONFIG_USB_HID=m # CONFIG_USB_HIDINPUT_POWERBOOK is not set # CONFIG_USB_HIDDEV is not set # # USB HID Boot Protocol drivers # # CONFIG_USB_KBD is not set # CONFIG_USB_MOUSE is not set CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=m # CONFIG_USB_DEBUG is not set # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y # CONFIG_USB_DEVICE_CLASS is not set # CONFIG_USB_DYNAMIC_MINORS is not set # CONFIG_USB_SUSPEND is not set # # USB Host Controller Drivers # # CONFIG_USB_C67X00_HCD is not set CONFIG_USB_EHCI_HCD=m # CONFIG_USB_EHCI_ROOT_HUB_TT is not set # CONFIG_USB_ISP116X_HCD is not set CONFIG_USB_OHCI_HCD=m # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=m # CONFIG_USB_SL811_HCD is not set # CONFIG_USB_R8A66597_HCD is not set # # USB Device Class drivers # CONFIG_USB_ACM=m # CONFIG_USB_PRINTER is not set # CONFIG_USB_WDM is not set # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set # CONFIG_USB_STORAGE_USBAT is not set # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set # CONFIG_USB_STORAGE_ALAUDA is not set # CONFIG_USB_STORAGE_ONETOUCH is not set # CONFIG_USB_STORAGE_KARMA is not set # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # # CONFIG_USB_MDC800 is not set # CONFIG_USB_MICROTEK is not set # CONFIG_USB_MON is not set # # USB port drivers # CONFIG_USB_SERIAL=m # CONFIG_USB_EZUSB is not set # CONFIG_USB_SERIAL_GENERIC is not set # CONFIG_USB_SERIAL_AIRCABLE is not set CONFIG_USB_SERIAL_AIRPRIME=m # CONFIG_USB_SERIAL_ARK3116 is not set # CONFIG_USB_SERIAL_BELKIN is not set # CONFIG_USB_SERIAL_CH341 is not set # CONFIG_USB_SERIAL_WHITEHEAT is not set # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set # CONFIG_USB_SERIAL_CP2101 is not set # CONFIG_USB_SERIAL_CYPRESS_M8 is not set # CONFIG_USB_SERIAL_EMPEG is not set # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_FUNSOFT is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set # CONFIG_USB_SERIAL_EDGEPORT is not set # CONFIG_USB_SERIAL_EDGEPORT_TI is not set # CONFIG_USB_SERIAL_GARMIN is not set # CONFIG_USB_SERIAL_IPW is not set # CONFIG_USB_SERIAL_IUU is not set # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set # CONFIG_USB_SERIAL_KEYSPAN is not set # CONFIG_USB_SERIAL_KLSI is not set # CONFIG_USB_SERIAL_KOBIL_SCT is not set # CONFIG_USB_SERIAL_MCT_U232 is not set # CONFIG_USB_SERIAL_MOS7720 is not set # CONFIG_USB_SERIAL_MOS7840 is not set # CONFIG_USB_SERIAL_MOTOROLA is not set # CONFIG_USB_SERIAL_NAVMAN is not set # CONFIG_USB_SERIAL_PL2303 is not set # CONFIG_USB_SERIAL_OTI6858 is not set # CONFIG_USB_SERIAL_SPCP8X5 is not set # CONFIG_USB_SERIAL_HP4X is not set # CONFIG_USB_SERIAL_SAFE is not set CONFIG_USB_SERIAL_SIERRAWIRELESS=m # CONFIG_USB_SERIAL_TI is not set # CONFIG_USB_SERIAL_CYBERJACK is not set # CONFIG_USB_SERIAL_XIRCOM is not set CONFIG_USB_SERIAL_OPTION=m # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_SERIAL_DEBUG is not set # # USB Miscellaneous drivers # # CONFIG_USB_EMI62 is not set # CONFIG_USB_EMI26 is not set # CONFIG_USB_ADUTUX is not set # CONFIG_USB_AUERSWALD is not set # CONFIG_USB_RIO500 is not set # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set # CONFIG_USB_LED is not set # CONFIG_USB_CYPRESS_CY7C63 is not set # CONFIG_USB_CYTHERM is not set # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set # CONFIG_USB_FTDI_ELAN is not set # CONFIG_USB_APPLEDISPLAY is not set # CONFIG_USB_SISUSBVGA is not set # CONFIG_USB_LD is not set # CONFIG_USB_TRANCEVIBRATOR is not set # CONFIG_USB_IOWARRIOR is not set # CONFIG_USB_TEST is not set # CONFIG_USB_ISIGHTFW is not set # CONFIG_USB_GADGET is not set # CONFIG_MMC is not set # CONFIG_MEMSTICK is not set # CONFIG_NEW_LEDS is not set # CONFIG_ACCESSIBILITY is not set # CONFIG_INFINIBAND is not set # CONFIG_RTC_CLASS is not set # CONFIG_DMADEVICES is not set # CONFIG_UIO is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set # CONFIG_DMIID is not set # CONFIG_ISCSI_IBFT_FIND is not set # # File systems # CONFIG_EXT2_FS=m # CONFIG_EXT2_FS_XATTR is not set # CONFIG_EXT2_FS_XIP is not set # CONFIG_EXT3_FS is not set # CONFIG_REISERFS_FS is not set # CONFIG_JFS_FS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=y # CONFIG_XFS_QUOTA is not set # CONFIG_XFS_POSIX_ACL is not set # CONFIG_XFS_RT is not set # CONFIG_OCFS2_FS is not set # CONFIG_DNOTIFY is not set CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_QUOTA is not set # CONFIG_AUTOFS_FS is not set # CONFIG_AUTOFS4_FS is not set CONFIG_FUSE_FS=m # # CD-ROM/DVD Filesystems # CONFIG_ISO9660_FS=m CONFIG_JOLIET=y # CONFIG_ZISOFS is not set CONFIG_UDF_FS=m CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=m # CONFIG_MSDOS_FS is not set CONFIG_VFAT_FS=m CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" CONFIG_NTFS_FS=m # CONFIG_NTFS_DEBUG is not set CONFIG_NTFS_RW=y # # Pseudo filesystems # CONFIG_PROC_FS=y # CONFIG_PROC_KCORE is not set CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y # CONFIG_TMPFS is not set # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set # CONFIG_CONFIGFS_FS is not set # # Miscellaneous filesystems # # CONFIG_HFSPLUS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set # CONFIG_MINIX_FS is not set # CONFIG_HPFS_FS is not set # CONFIG_QNX4FS_FS is not set # CONFIG_ROMFS_FS is not set # CONFIG_SYSV_FS is not set # CONFIG_UFS_FS is not set CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_LOCKD=m CONFIG_LOCKD_V4=y CONFIG_EXPORTFS=m CONFIG_NFS_ACL_SUPPORT=m CONFIG_NFS_COMMON=y CONFIG_SUNRPC=m # CONFIG_SMB_FS is not set CONFIG_CIFS=m CONFIG_CIFS_STATS=y CONFIG_CIFS_STATS2=y CONFIG_CIFS_WEAK_PW_HASH=y CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # # Partition Types # # CONFIG_PARTITION_ADVANCED is not set CONFIG_MSDOS_PARTITION=y CONFIG_NLS=m CONFIG_NLS_DEFAULT="iso8859-1" CONFIG_NLS_CODEPAGE_437=m # CONFIG_NLS_CODEPAGE_737 is not set # CONFIG_NLS_CODEPAGE_775 is not set # CONFIG_NLS_CODEPAGE_850 is not set # CONFIG_NLS_CODEPAGE_852 is not set # CONFIG_NLS_CODEPAGE_855 is not set # CONFIG_NLS_CODEPAGE_857 is not set # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set # CONFIG_NLS_CODEPAGE_864 is not set # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set # CONFIG_NLS_CODEPAGE_932 is not set # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=m CONFIG_NLS_ISO8859_1=m # CONFIG_NLS_ISO8859_2 is not set # CONFIG_NLS_ISO8859_3 is not set # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set # CONFIG_NLS_ISO8859_7 is not set # CONFIG_NLS_ISO8859_9 is not set # CONFIG_NLS_ISO8859_13 is not set # CONFIG_NLS_ISO8859_14 is not set CONFIG_NLS_ISO8859_15=m # CONFIG_NLS_KOI8_R is not set # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=m # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set # CONFIG_ENABLE_WARN_DEPRECATED is not set # CONFIG_ENABLE_MUST_CHECK is not set CONFIG_FRAME_WARN=1024 # CONFIG_MAGIC_SYSRQ is not set # CONFIG_UNUSED_SYMBOLS is not set # CONFIG_DEBUG_FS is not set # CONFIG_HEADERS_CHECK is not set # CONFIG_DEBUG_KERNEL is not set # CONFIG_SLUB_DEBUG_ON is not set # CONFIG_SLUB_STATS is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_LATENCYTOP is not set # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set # CONFIG_SAMPLES is not set CONFIG_HAVE_ARCH_KGDB=y # CONFIG_NONPROMISC_DEVMEM is not set CONFIG_EARLY_PRINTK=y # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # # Security options # # CONFIG_KEYS is not set # CONFIG_SECURITY is not set CONFIG_CRYPTO=y # # Crypto core or helper # CONFIG_CRYPTO_ALGAPI=m CONFIG_CRYPTO_AEAD=m CONFIG_CRYPTO_BLKCIPHER=m CONFIG_CRYPTO_HASH=m CONFIG_CRYPTO_MANAGER=m # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_AUTHENC=m # CONFIG_CRYPTO_TEST is not set # # Authenticated Encryption with Associated Data # # CONFIG_CRYPTO_CCM is not set # CONFIG_CRYPTO_GCM is not set # CONFIG_CRYPTO_SEQIV is not set # # Block modes # CONFIG_CRYPTO_CBC=m # CONFIG_CRYPTO_CTR is not set # CONFIG_CRYPTO_CTS is not set # CONFIG_CRYPTO_ECB is not set # CONFIG_CRYPTO_PCBC is not set # # Hash modes # CONFIG_CRYPTO_HMAC=m # # Digest # # CONFIG_CRYPTO_CRC32C is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=m # CONFIG_CRYPTO_MICHAEL_MIC is not set CONFIG_CRYPTO_SHA1=m CONFIG_CRYPTO_SHA256=m CONFIG_CRYPTO_SHA512=m # CONFIG_CRYPTO_TGR192 is not set # CONFIG_CRYPTO_WP512 is not set # # Ciphers # CONFIG_CRYPTO_AES=m CONFIG_CRYPTO_AES_586=m # CONFIG_CRYPTO_ANUBIS is not set # CONFIG_CRYPTO_ARC4 is not set CONFIG_CRYPTO_BLOWFISH=m # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_CAST5 is not set # CONFIG_CRYPTO_CAST6 is not set CONFIG_CRYPTO_DES=m # CONFIG_CRYPTO_FCRYPT is not set # CONFIG_CRYPTO_KHAZAD is not set # CONFIG_CRYPTO_SEED is not set CONFIG_CRYPTO_SERPENT=m # CONFIG_CRYPTO_TEA is not set # CONFIG_CRYPTO_TWOFISH is not set CONFIG_CRYPTO_TWOFISH_COMMON=m CONFIG_CRYPTO_TWOFISH_586=m # # Compression # CONFIG_CRYPTO_DEFLATE=m CONFIG_CRYPTO_LZO=m # CONFIG_CRYPTO_HW is not set CONFIG_HAVE_KVM=y # CONFIG_VIRTUALIZATION is not set # # Library routines # CONFIG_BITREVERSE=m CONFIG_GENERIC_FIND_FIRST_BIT=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_CRC_CCITT=m # CONFIG_CRC16 is not set CONFIG_CRC_ITU_T=m CONFIG_CRC32=m # CONFIG_CRC7 is not set # CONFIG_LIBCRC32C is not set CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG_LZO_COMPRESS=m CONFIG_LZO_DECOMPRESS=m CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=m CONFIG_TEXTSEARCH_BM=m CONFIG_TEXTSEARCH_FSM=m CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y From owner-xfs@oss.sgi.com Mon Jun 16 03:00:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 03:00:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GA0RhP011056 for ; Mon, 16 Jun 2008 03:00:28 -0700 X-ASG-Debug-ID: 1213610485-48dc03e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DE520122E66E for ; Mon, 16 Jun 2008 03:01:25 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id ONKgY6BlPxr9QMLp for ; Mon, 16 Jun 2008 03:01:25 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K8BWc-0002ib-S2; Mon, 16 Jun 2008 10:01:22 +0000 Date: Mon, 16 Jun 2008 06:01:22 -0400 From: Christoph Hellwig To: Eric Sandeen , Oliver Pinter , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Subject: Re: XFS errors / BUG / panic, with 2.6.25.7-queue (and older 2.6.25.y) Message-ID: <20080616100122.GA1360@infradead.org> References: <6101e8c40806141241h4a23f7a6ka5366c84130f1291@mail.gmail.com> <48547604.9060700@sandeen.net> <6101e8c40806150538h4372dcedob2ab9c45aa01741c@mail.gmail.com> <48553C11.2060606@sandeen.net> <20080616045221.GJ3700@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080616045221.GJ3700@disturbed> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213610485 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53442 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16375 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Mon, Jun 16, 2008 at 02:52:21PM +1000, Dave Chinner wrote: > > is the first event of interest, it is hitting an assertion on the > > remount path: > > > > ASSERT_ALWAYS(atomic_read(&mp->m_active_trans) == 0); > > > > in xfs_attr_quiesce. > > That's caused by a race condition in the VFS w.r.t setting the MS_RDONLY > flag. It should be fixed in 2.6.26. I was claiming it would be fixed in 2.6.26 but unfortunately the part of the the per-mount r/o patches that fixes various bits in remount isn't there yet. From owner-xfs@oss.sgi.com Mon Jun 16 03:13:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 03:13:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GADOEZ012030 for ; Mon, 16 Jun 2008 03:13:25 -0700 X-ASG-Debug-ID: 1213611260-7e0a00fe0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 46702CC1E1E for ; Mon, 16 Jun 2008 03:14:21 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id gJsPylyidb6Y5vx5 for ; Mon, 16 Jun 2008 03:14:21 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5GAECNW017988 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Mon, 16 Jun 2008 12:14:12 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5GAECGt017986 for xfs@oss.sgi.com; Mon, 16 Jun 2008 12:14:12 +0200 Date: Mon, 16 Jun 2008 12:14:12 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] kill INDUCE_IO_ERROR Subject: Re: [PATCH] kill INDUCE_IO_ERROR Message-ID: <20080616101412.GA17939@lst.de> References: <20080523062323.GA32637@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080523062323.GA32637@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213611262 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53452 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16376 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, May 23, 2008 at 08:23:23AM +0200, Christoph Hellwig wrote: > All the error injection is already enabled through ifdef DEBUG, so kill > the never set second cpp symbol to activate it without the rest of the > debugging infrastructure. Can I get a review on this absolutely trivial patch? > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_error.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_error.c 2008-05-22 18:55:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_error.c 2008-05-22 18:55:16.000000000 +0200 > @@ -58,9 +58,6 @@ xfs_error_trap(int e) > } > return e; > } > -#endif > - > -#if (defined(DEBUG) || defined(INDUCE_IO_ERROR)) > > int xfs_etest[XFS_NUM_INJECT_ERROR]; > int64_t xfs_etest_fsid[XFS_NUM_INJECT_ERROR]; > @@ -154,7 +151,7 @@ xfs_errortag_clearall(xfs_mount_t *mp, i > > return 0; > } > -#endif /* DEBUG || INDUCE_IO_ERROR */ > +#endif /* DEBUG */ > > static void > xfs_fs_vcmn_err(int level, xfs_mount_t *mp, char *fmt, va_list ap) > Index: linux-2.6-xfs/fs/xfs/xfs_error.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_error.h 2008-05-22 18:55:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_error.h 2008-05-22 18:55:16.000000000 +0200 > @@ -125,22 +125,14 @@ extern void xfs_corruption_error(char *t > #define XFS_RANDOM_DIOWRITE_IOERR (XFS_RANDOM_DEFAULT/10) > #define XFS_RANDOM_BMAPIFORMAT XFS_RANDOM_DEFAULT > > -#if (defined(DEBUG) || defined(INDUCE_IO_ERROR)) > +#ifdef DEBUG > extern int xfs_error_test(int, int *, char *, int, char *, unsigned long); > > #define XFS_NUM_INJECT_ERROR 10 > - > -#ifdef __ANSI_CPP__ > -#define XFS_TEST_ERROR(expr, mp, tag, rf) \ > - ((expr) || \ > - xfs_error_test((tag), (mp)->m_fixedfsid, #expr, __LINE__, __FILE__, \ > - (rf))) > -#else > #define XFS_TEST_ERROR(expr, mp, tag, rf) \ > ((expr) || \ > xfs_error_test((tag), (mp)->m_fixedfsid, "expr", __LINE__, __FILE__, \ > (rf))) > -#endif /* __ANSI_CPP__ */ > > extern int xfs_errortag_add(int error_tag, xfs_mount_t *mp); > extern int xfs_errortag_clearall(xfs_mount_t *mp, int loud); > @@ -148,7 +140,7 @@ extern int xfs_errortag_clearall(xfs_mou > #define XFS_TEST_ERROR(expr, mp, tag, rf) (expr) > #define xfs_errortag_add(tag, mp) (ENOSYS) > #define xfs_errortag_clearall(mp, loud) (ENOSYS) > -#endif /* (DEBUG || INDUCE_IO_ERROR) */ > +#endif /* DEBUG */ > > /* > * XFS panic tags -- allow a call to xfs_cmn_err() be turned into > Index: linux-2.6-xfs/fs/xfs/xfs_mount.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2008-05-22 18:55:05.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2008-05-23 08:11:46.000000000 +0200 > @@ -1322,7 +1322,7 @@ xfs_unmountfs(xfs_mount_t *mp) > if ((mp->m_flags & XFS_MOUNT_NOUUID) == 0) > uuid_table_remove(&mp->m_sb.sb_uuid); > > -#if defined(DEBUG) || defined(INDUCE_IO_ERROR) > +#if defined(DEBUG) > xfs_errortag_clearall(mp, 0); > #endif > xfs_mount_free(mp); ---end quoted text--- From owner-xfs@oss.sgi.com Mon Jun 16 08:49:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 08:49:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GFnKGD014531 for ; Mon, 16 Jun 2008 08:49:21 -0700 X-ASG-Debug-ID: 1213631416-6ea0009d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-vbr11.xs4all.nl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1954017CAE3C; Mon, 16 Jun 2008 08:50:17 -0700 (PDT) Received: from smtp-vbr11.xs4all.nl (smtp-vbr11.xs4all.nl [194.109.24.31]) by cuda.sgi.com with ESMTP id ooqLaCyfech8VB4i; Mon, 16 Jun 2008 08:50:17 -0700 (PDT) Received: from [194.109.0.112] (n2o.xs4all.nl [194.109.0.112]) by smtp-vbr11.xs4all.nl (8.13.8/8.13.8) with ESMTP id m5GFo6sO048733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jun 2008 17:50:08 +0200 (CEST) (envelope-from mikevs@xs4all.net) X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c From: Miquel van Smoorenburg To: Dave Chinner Cc: Oliver Pinter , lists@ku-gbr.de, linux-kernel@vger.kernel.org, Christoph Hellwig , xfs@oss.sgi.com, xfs-masters@oss.sgi.com, mikevs@xs4all.net In-Reply-To: <1213356518.8530.5.camel@n2o.xs4all.nl> References: <20080612123031.21594jyk6rjc1lfk@imp.ku-gbr.de> <6101e8c40806120733m3c8647ccy149eb237e2c6d027@mail.gmail.com> <1213309629.29745.8.camel@localhost.localdomain> <20080613030841.GC3700@disturbed> <1213356518.8530.5.camel@n2o.xs4all.nl> Content-Type: text/plain Organization: XS4ALL Internet B.V. Date: Mon, 16 Jun 2008 17:50:06 +0200 Message-Id: <1213631406.19372.15.camel@n2o.xs4all.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by XS4ALL Virus Scanner X-Barracuda-Connect: smtp-vbr11.xs4all.nl[194.109.24.31] X-Barracuda-Start-Time: 1213631418 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53471 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16377 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mikevs@xs4all.net Precedence: bulk X-list: xfs On Fri, 2008-06-13 at 13:28 +0200, Miquel van Smoorenburg wrote: > On Fri, 2008-06-13 at 13:08 +1000, Dave Chinner wrote: > > On Fri, Jun 13, 2008 at 12:27:09AM +0200, Miquel van Smoorenburg wrote: > > > > Linux transit5.news.xs4all.nl 2.6.25.6 #1 SMP Wed Jun 11 10:59:10 CEST > > > 2008 x86_64 GNU/Linux > > > > > > Filesystem "sda4": XFS internal error xfs_trans_cancel at line 1163 of > > > file fs/xfs/xfs_trans.c. Caller 0xffffffff880f1315 > > > Pid: 3402, comm: diablo Not tainted 2.6.25.6 #1 > > > > This commit in 2.6.26 will probably fix it. > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=75de2a91c98a6f486f261c1367fe59f5583e15a3 > > "At ENOSPC, we can get a filesystem shutdown due to a cancelling a dirty > transaction in xfs_mkdir or xfs_create." > > But The filesystem is only used for 35%. It might have hit 100% somewhere in > the recent past though (a few reboots ago). > I've applied the patch to 2.6.25.6 just in case, I'll let it run over > the weekend to see what happens. Well, the box has been up for 3 days now. When this problem first appeared it only stayed up for a day max, so I'm reasonably positive it's fixed. The patch applies cleanly to 2.6.25.6 - perhaps it should go into -stable. Thanks, Mike. From owner-xfs@oss.sgi.com Mon Jun 16 10:09:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 10:09:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GH9RcM019787 for ; Mon, 16 Jun 2008 10:09:28 -0700 X-ASG-Debug-ID: 1213636224-240e00420000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BAF7C239DBA for ; Mon, 16 Jun 2008 10:10:24 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id qcLAOuRWQcdzQNZN for ; Mon, 16 Jun 2008 10:10:24 -0700 (PDT) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m5GHA08Z017894 for ; Mon, 16 Jun 2008 10:10:00 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m5GHA02H014936 for ; Mon, 16 Jun 2008 10:10:00 -0700 Received: from dchinner-64.agami.com ([10.123.4.83]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 10:10:23 -0700 From: Dave Chinner To: lachlan@sgi.com X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Date: Mon, 16 Jun 2008 10:10:22 -0700 User-Agent: KMail/1.8.2 Cc: xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> In-Reply-To: <485603FD.2080204@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806161010.22476.dchinner@agami.com> X-OriginalArrivalTime: 16 Jun 2008 17:10:23.0211 (UTC) FILETIME=[DCF45BB0:01C8CFD3] X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1213636224 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_GENERIC_NO_PTR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53476 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_GENERIC_NO_PTR Delivered to trusted network by host with generic-looking RDNS - indicates no PTR record X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16378 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: > Dave Chinner wrote: > > On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: > >> When at ENOSPC conditions extent btree block allocations can fail and we > >> have no error handling to undo partial btree operations. Prior to extent > >> btree operations we reserve enough disk blocks somewhere in the filesystem > >> to satisfy the operation but in some conditions we require the blocks to > >> come from specific AGs and if those AGs are full the allocation fails. > >> > >> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), > >> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs > >> for the space needed. Since we have reserved the space these allocations > >> are now guaranteed to succeed. > > > > Sure, but we didn't reserve space for potential btree splits in a > > second AG as a result of this. That needs to be reserved in the > > transaction as well, which will blow out transaction reservations > > substantially as we'll need to add another 2 full AGF btree splits to > > every transaction that modifies the bmap btree. > > Right. And most of the time we wont need the space either so it's a > real waste. Waste, yes, but still needed otherwise transaction overruns and log space deadlocks could occur.... > >> In order to search all AGs I had to revert > >> a change made to xfs_alloc_vextent() that prevented a search from looking > >> at AGs lower than the starting AG. This original change was made to prevent > >> out of order AG locking when allocating multiple extents on data writeout > >> but since we only allocate one extent at a time now this particular problem > >> can't happen. > > > > You missed the fact that the AGF of modified AGs is already held > > locked in the transaction, hence the locking order within the > > transaction is wrong. Also, if we modify the free list in an AG > > the fail an allocation (e.g. can't do an exact allocation), we'll > > have multiple dirty and locked AGFs in the one allocation. Hence > > we still can have locking order violations if you remove that check > > and therefore deadlocks. > > I'm well aware of that particular deadlock involving the freelist - I > hit it while testing. If you look closely at the code that deadlock > can occur with or without the AG locking avoidance logic. This is > because the rest of the transaction is unaware that an AG has been > locked due to a freelist operation. Yes, which is why you need to prevent freelist modifications occurring when you can't allocate anything out of the AG. > > This is not the solution to the problem. As I suggested (back when > > you first floated this idea as a fix for the problem several weeks > > ago) I think the bug is that we are not taking into account the > > number of blocks required for a bmbt split when selecting an AG to > > allocate from. All we take into account is the blocks required for > > the extent to be allocated and nothing else. If we take the blocks > > for a bmbt split into account then we'll never try to allocate an > > extent in an AG that we can't also allocate all the blocks for the > > bmbt split in at the same time. > > I considered that approach (using the minleft field in xfs_alloc_arg_t) > but it has it's problems too. When we reserve space for the btree > operations it is done on the global filesystem counters, not a > particular AG, so there is the possibility that not one AG has sufficent > space to perform the allocation even though there is enough free space > in the whole filesystem. Yes, we had that problem with the ENOSPC deadlock fixes in that we always needed at least 4 blocks per AG available for a extent free to succeed. Hence we have the XFS_ALLOC_SET_ASIDE() value for determining if the filesystem is out of space, not a count of zero free blocks. In this case, this macro can be extended to guarantee that our aggregate block usage never goes below the threshold that would prevent each AG from holding enough blocks for a worst case allocation to succeed..... > Of course if we have enough space left in one > AG and the AG is locked then the space we reserved doesn't matter anymore > and it should all work. Yes. > I'm worried with this approach that we could have delayed allocations and > unwritten extents that need to be converted but we can't do it because we > don't have the space we might need (but probably don't). Delayed allocation is the issue - unwritten extent conversion failure will simply return an error and leave the extent unwritten. With delayed allocation, we can oversubscribe a given AG but we can always try a different AG. If we get to the situation that we don't have enough space in any AG then we are screwed. However, by ensuring we can sustain a worst-case split within any AG we can avoid this situation completely. Cheers, Dave. From owner-xfs@oss.sgi.com Mon Jun 16 10:13:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 10:13:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GHD8nd020313 for ; Mon, 16 Jun 2008 10:13:08 -0700 X-ASG-Debug-ID: 1213636445-7f8c02ae0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7A10BCC72AE for ; Mon, 16 Jun 2008 10:14:05 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id sO79sz6ONKwvwmPh for ; Mon, 16 Jun 2008 10:14:05 -0700 (PDT) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m5GHDg8Z018049 for ; Mon, 16 Jun 2008 10:13:42 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m5GHDgrb015226 for ; Mon, 16 Jun 2008 10:13:42 -0700 Received: from dchinner-64.agami.com ([10.123.4.83]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 10:14:05 -0700 From: Dave Chinner To: lachlan@sgi.com X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert Date: Mon, 16 Jun 2008 10:14:04 -0700 User-Agent: KMail/1.8.2 Cc: xfs-dev , xfs-oss References: <4855CE2D.70505@sgi.com> <20080616050150.GK3700@disturbed> <48560B0B.3060204@sgi.com> In-Reply-To: <48560B0B.3060204@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806161014.04407.dchinner@agami.com> X-OriginalArrivalTime: 16 Jun 2008 17:14:05.0322 (UTC) FILETIME=[6157CEA0:01C8CFD4] X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1213636446 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0472 1.0000 -1.7177 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.62 X-Barracuda-Spam-Status: No, SCORE=-1.62 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_GENERIC_NO_PTR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53467 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_GENERIC_NO_PTR Delivered to trusted network by host with generic-looking RDNS - indicates no PTR record X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16379 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Sunday 15 June 2008 11:41 pm, Lachlan McIlroy wrote: > Dave Chinner wrote: > > On Mon, Jun 16, 2008 at 12:21:33PM +1000, Lachlan McIlroy wrote: > >> After a btree insert operation a cursor can be invalid due to block > >> splits and a maybe a new root block. We reset the cursor in > >> xfs_bmbt_insert() in the cases where we think we need to but it > >> isn't enough as we still see assertions. Just do what we do elsewhere > >> and reset the cursor unconditionally. > > > > Ok, so you should also kill the new code in the btree insert that > > revalidates the btree cursor. IIRC, this was the only place it was > > needed for.... > > That was the plan. Cool. Please include it in the next version of the patch. > >> + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, > >> + new->br_startblock, new->br_blockcount, > >> + &i))) > >> goto done; > > > > > > error = xfs_bmbt_lookup_eq(cur, new->br_startoff, > > br_startblock, new->br_blockcount, &i); > > if (error) > > goto done; > > > >> - ASSERT(i == 1); > >> + ASSERT(i == 0); > > > > ASSERT? How about a WANT_CORRUPTED_GOTO()? > > I was just being consistent with the rest of the code. If you think this > ASSERT should be changed then what about all of them? Well, the ASSERT means silent failure on a production system. Given that failure here indicates a corrupt btree, then we really should be treating it as such. i.e. shut down the filesystem. This might have saved us a whole heap of trouble tracking down these problems as a shutdown here would have pointed us right at the source of the problem... Cheers, Dave. From owner-xfs@oss.sgi.com Mon Jun 16 10:14:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 10:14:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5GHEF9m020730 for ; Mon, 16 Jun 2008 10:14:15 -0700 X-ASG-Debug-ID: 1213636513-2581003c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D7130239F0F for ; Mon, 16 Jun 2008 10:15:13 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id mUvCeC4VRAxsGXmp for ; Mon, 16 Jun 2008 10:15:13 -0700 (PDT) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m5GHEo8Z018114 for ; Mon, 16 Jun 2008 10:14:50 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m5GHEone015257 for ; Mon, 16 Jun 2008 10:14:50 -0700 Received: from dchinner-64.agami.com ([10.123.4.83]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jun 2008 10:15:13 -0700 From: Dave Chinner To: Christoph Hellwig X-ASG-Orig-Subj: Re: [PATCH] kill XFS_PURGE_INODE Subject: Re: [PATCH] kill XFS_PURGE_INODE Date: Mon, 16 Jun 2008 10:15:12 -0700 User-Agent: KMail/1.8.2 Cc: xfs@oss.sgi.com References: <20080616062634.GA5971@lst.de> In-Reply-To: <20080616062634.GA5971@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806161015.12363.dchinner@agami.com> X-OriginalArrivalTime: 16 Jun 2008 17:15:13.0057 (UTC) FILETIME=[89B75910:01C8CFD4] X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1213636513 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2034 1.0000 -0.8098 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.71 X-Barracuda-Spam-Status: No, SCORE=-0.71 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_GENERIC_NO_PTR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53476 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_GENERIC_NO_PTR Delivered to trusted network by host with generic-looking RDNS - indicates no PTR record X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16380 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Sunday 15 June 2008 11:26 pm, Christoph Hellwig wrote: > Just a useless alias for IRELE. Looks sane. Cheers, Dave. From owner-xfs@oss.sgi.com Mon Jun 16 18:20:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 18:20:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H1K3SL028564 for ; Mon, 16 Jun 2008 18:20:04 -0700 X-ASG-Debug-ID: 1213665658-2e7901190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id B310417CEB76 for ; Mon, 16 Jun 2008 18:20:59 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id 3VShDinxdeHJh20o for ; Mon, 16 Jun 2008 18:20:59 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA08519; Tue, 17 Jun 2008 11:20:48 +1000 Message-ID: <48571241.20806@sgi.com> Date: Tue, 17 Jun 2008 11:24:17 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Dave Chinner CC: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert References: <4855CE2D.70505@sgi.com> <20080616050150.GK3700@disturbed> <48560B0B.3060204@sgi.com> <200806161014.04407.dchinner@agami.com> In-Reply-To: <200806161014.04407.dchinner@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213665661 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0206 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53511 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16381 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Sunday 15 June 2008 11:41 pm, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Mon, Jun 16, 2008 at 12:21:33PM +1000, Lachlan McIlroy wrote: >>>> After a btree insert operation a cursor can be invalid due to block >>>> splits and a maybe a new root block. We reset the cursor in >>>> xfs_bmbt_insert() in the cases where we think we need to but it >>>> isn't enough as we still see assertions. Just do what we do elsewhere >>>> and reset the cursor unconditionally. >>> Ok, so you should also kill the new code in the btree insert that >>> revalidates the btree cursor. IIRC, this was the only place it was >>> needed for.... >> That was the plan. > > Cool. Please include it in the next version of the patch. > >>>> + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, >>>> + new->br_startblock, new->br_blockcount, >>>> + &i))) >>>> goto done; >>> >>> error = xfs_bmbt_lookup_eq(cur, new->br_startoff, >>> br_startblock, new->br_blockcount, &i); >>> if (error) >>> goto done; >>> >>>> - ASSERT(i == 1); >>>> + ASSERT(i == 0); >>> ASSERT? How about a WANT_CORRUPTED_GOTO()? >> I was just being consistent with the rest of the code. If you think this >> ASSERT should be changed then what about all of them? > > Well, the ASSERT means silent failure on a production system. > Given that failure here indicates a corrupt btree, then we really > should be treating it as such. i.e. shut down the filesystem. This > might have saved us a whole heap of trouble tracking down these > problems as a shutdown here would have pointed us right at the > source of the problem... > Dave, what I was asking is what about the rest of the ASSERTs in this file - should we change them too? There's a lot of them. After this change they are all equally likely to trigger so if it makes sense to change one then the same argument applies to all of them. From owner-xfs@oss.sgi.com Mon Jun 16 18:54:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 18:54:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H1sYI5030352 for ; Mon, 16 Jun 2008 18:54:34 -0700 X-ASG-Debug-ID: 1213667726-4fa000220000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 4AA8523A0AD for ; Mon, 16 Jun 2008 18:55:26 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id zRmCF7qjQa3RX3xt for ; Mon, 16 Jun 2008 18:55:26 -0700 (PDT) Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA09126; Tue, 17 Jun 2008 11:55:18 +1000 Message-ID: <48571A57.5090901@sgi.com> Date: Tue, 17 Jun 2008 11:58:47 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Dave Chinner CC: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> In-Reply-To: <200806161010.22476.dchinner@agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1213667732 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53513 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16382 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Fri, Jun 13, 2008 at 05:38:12PM +1000, Lachlan McIlroy wrote: >>>> When at ENOSPC conditions extent btree block allocations can fail and we >>>> have no error handling to undo partial btree operations. Prior to extent >>>> btree operations we reserve enough disk blocks somewhere in the filesystem >>>> to satisfy the operation but in some conditions we require the blocks to >>>> come from specific AGs and if those AGs are full the allocation fails. >>>> >>>> This change fixes xfs_bmap_extents_to_btree(), xfs_bmap_local_to_extents(), >>>> xfs_bmbt_split() and xfs_bmbt_newroot() so that they can search other AGs >>>> for the space needed. Since we have reserved the space these allocations >>>> are now guaranteed to succeed. >>> Sure, but we didn't reserve space for potential btree splits in a >>> second AG as a result of this. That needs to be reserved in the >>> transaction as well, which will blow out transaction reservations >>> substantially as we'll need to add another 2 full AGF btree splits to >>> every transaction that modifies the bmap btree. >> Right. And most of the time we wont need the space either so it's a >> real waste. > > Waste, yes, but still needed otherwise transaction overruns and log space > deadlocks could occur.... > >>>> In order to search all AGs I had to revert >>>> a change made to xfs_alloc_vextent() that prevented a search from looking >>>> at AGs lower than the starting AG. This original change was made to prevent >>>> out of order AG locking when allocating multiple extents on data writeout >>>> but since we only allocate one extent at a time now this particular problem >>>> can't happen. >>> You missed the fact that the AGF of modified AGs is already held >>> locked in the transaction, hence the locking order within the >>> transaction is wrong. Also, if we modify the free list in an AG >>> the fail an allocation (e.g. can't do an exact allocation), we'll >>> have multiple dirty and locked AGFs in the one allocation. Hence >>> we still can have locking order violations if you remove that check >>> and therefore deadlocks. >> I'm well aware of that particular deadlock involving the freelist - I >> hit it while testing. If you look closely at the code that deadlock >> can occur with or without the AG locking avoidance logic. This is >> because the rest of the transaction is unaware that an AG has been >> locked due to a freelist operation. > > Yes, which is why you need to prevent freelist modifications occurring > when you can't allocate anything out of the AG. That sounds reasonable but it isn't consistent with the deadlock I saw. One of the threads that was deadlocked had tried to allocate a data extent in AG3 but didn't find the space. It had modified, and hence locked, AG3 due to modifying the freelist but since it didn't get the space it needed it had to go on to another AG. So before we even allocated the data extent (and before we tried to modify the btree, etc) we had an AG locked. The deadlock avoidance code in xfs_alloc_vextent() didn't know this because it only checks for a previous allocation. It makes sense that we should avoid modifying the freelist if there isn't enough space for the allocation so the puzzle is why didn't the code do that? > >>> This is not the solution to the problem. As I suggested (back when >>> you first floated this idea as a fix for the problem several weeks >>> ago) I think the bug is that we are not taking into account the >>> number of blocks required for a bmbt split when selecting an AG to >>> allocate from. All we take into account is the blocks required for >>> the extent to be allocated and nothing else. If we take the blocks >>> for a bmbt split into account then we'll never try to allocate an >>> extent in an AG that we can't also allocate all the blocks for the >>> bmbt split in at the same time. >> I considered that approach (using the minleft field in xfs_alloc_arg_t) >> but it has it's problems too. When we reserve space for the btree >> operations it is done on the global filesystem counters, not a >> particular AG, so there is the possibility that not one AG has sufficent >> space to perform the allocation even though there is enough free space >> in the whole filesystem. > > Yes, we had that problem with the ENOSPC deadlock fixes in that we always > needed at least 4 blocks per AG available for a extent free to succeed. > Hence we have the XFS_ALLOC_SET_ASIDE() value for determining if the > filesystem is out of space, not a count of zero free blocks. Those 4 blocks are for one extent free operation, right? What if we have multiple threads all trying to do the same thing (in the same AG)? > > In this case, this macro can be extended to guarantee that our aggregate > block usage never goes below the threshold that would prevent each AG from > holding enough blocks for a worst case allocation to succeed..... > >> Of course if we have enough space left in one >> AG and the AG is locked then the space we reserved doesn't matter anymore >> and it should all work. > > Yes. > >> I'm worried with this approach that we could have delayed allocations and >> unwritten extents that need to be converted but we can't do it because we >> don't have the space we might need (but probably don't). > > Delayed allocation is the issue - unwritten extent conversion failure will > simply return an error and leave the extent unwritten. That's still a problem though - if we can't convert unwritten extents then we can't clean dirty pages and we wont be able to unmount the filesystem. > > With delayed allocation, we can oversubscribe a given AG but we can > always try a different AG. If we get to the situation that we don't have > enough space in any AG then we are screwed. However, by ensuring we can > sustain a worst-case split within any AG we can avoid this situation > completely. > > Cheers, > > Dave. > From owner-xfs@oss.sgi.com Mon Jun 16 22:20:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 22:20:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H5Kish013730 for ; Mon, 16 Jun 2008 22:20:45 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id DC7DE30408C; Mon, 16 Jun 2008 22:21:38 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5H5LZjm2070622; Tue, 17 Jun 2008 15:21:36 +1000 (AEST) From: Niv Sardi To: lachlan@sgi.com Cc: xfs-dev , xfs-oss Subject: Re: [PATCH] Remove infinite loop from xfsidbg_xaildump References: <4856195F.9030809@sgi.com> Date: Tue, 17 Jun 2008 15:21:24 +1000 In-Reply-To: <4856195F.9030809@sgi.com> (Lachlan McIlroy's message of "Mon, 16 Jun 2008 17:42:23 +1000") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16383 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs looks good, -- Niv Sardi From owner-xfs@oss.sgi.com Mon Jun 16 22:42:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 16 Jun 2008 22:42:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H5gigk015379 for ; Mon, 16 Jun 2008 22:42:44 -0700 X-ASG-Debug-ID: 1213681420-314b02f20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 54C2C23C906 for ; Mon, 16 Jun 2008 22:43:41 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id FtWaaEhkJqU2EC16 for ; Mon, 16 Jun 2008 22:43:41 -0700 (PDT) Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail04.adl2.internode.on.net with ESMTP; 17 Jun 2008 15:11:53 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K8TvV-00027X-Ob; Tue, 17 Jun 2008 15:40:17 +1000 Date: Tue, 17 Jun 2008 15:40:17 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: Dave Chinner , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Always reset btree cursor after an insert Subject: Re: [PATCH] Always reset btree cursor after an insert Message-ID: <20080617054017.GO3700@disturbed> Mail-Followup-To: Lachlan McIlroy , Dave Chinner , xfs-dev , xfs-oss References: <4855CE2D.70505@sgi.com> <20080616050150.GK3700@disturbed> <48560B0B.3060204@sgi.com> <200806161014.04407.dchinner@agami.com> <48571241.20806@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48571241.20806@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1213681422 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0204 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53524 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16384 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Tue, Jun 17, 2008 at 11:24:17AM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: >> On Sunday 15 June 2008 11:41 pm, Lachlan McIlroy wrote: >>>> ASSERT? How about a WANT_CORRUPTED_GOTO()? >>> I was just being consistent with the rest of the code. If you think this >>> ASSERT should be changed then what about all of them? >> >> Well, the ASSERT means silent failure on a production system. >> Given that failure here indicates a corrupt btree, then we really >> should be treating it as such. i.e. shut down the filesystem. This >> might have saved us a whole heap of trouble tracking down these >> problems as a shutdown here would have pointed us right at the >> source of the problem... > > Dave, what I was asking is what about the rest of the ASSERTs in > this file - should we change them too? There's a lot of them. > After this change they are all equally likely to trigger so if > it makes sense to change one then the same argument applies to > all of them. In the past we've only changed the bits of the code that have been needed for debugging problems. e.g. there's WANT_CORRUPTED throughout the alloc code, but only some bits of the bmbt code and almost none in the inobt. Really we should be consistent with our catching and handling of errors. IOWs, I'd say we probably should change them all, but it's going to touch lots of code. For the btree code, I'd say it should be done with the factoring (get them all in one go), but xfs_bmap.c code is separate and could be done separately. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 17 00:33:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 00:33:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_50 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H7X06r028418 for ; Tue, 17 Jun 2008 00:33:01 -0700 X-ASG-Debug-ID: 1213688038-60e702f60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34506.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id CAFEACD2914 for ; Tue, 17 Jun 2008 00:33:58 -0700 (PDT) Received: from web34506.mail.mud.yahoo.com (web34506.mail.mud.yahoo.com [66.163.178.172]) by cuda.sgi.com with SMTP id BMytHpoKSqocM4o8 for ; Tue, 17 Jun 2008 00:33:58 -0700 (PDT) Received: (qmail 19408 invoked by uid 60001); 17 Jun 2008 07:33:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=11bCm9abXFrwNb1K1xInDc2Ap6fhFIHyesRHe0Xsl7liayuykRpp7vtaPjWjbAc6bwjDMKUMl/wFyDZCsXCYUAQD+Qd6sBwQBbLm4moJYEbbvEOHF5RRh3G8mpyY08sqTeOOXbxaLlUWqM9fZ8rbwtYHY97E+9nF98+Wzt1iMwY=; Received: from [96.14.254.25] by web34506.mail.mud.yahoo.com via HTTP; Tue, 17 Jun 2008 00:33:57 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 17 Jun 2008 00:33:57 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: XFS mkfs/mount options Subject: XFS mkfs/mount options To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <881489.19090.qm@web34506.mail.mud.yahoo.com> X-Barracuda-Connect: web34506.mail.mud.yahoo.com[66.163.178.172] X-Barracuda-Start-Time: 1213688038 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53534 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16385 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs I have been doing some experiments with XFS on my "hot new desktop system," and I have turned up an interesting bit of info. (Note: My system is an AMD64 X2 2.5GHz running Linux.) When I mount an XFS volume (thus loading the xfs kernel module), the kernel spawns two CPU-bound threads for "xfslogd" and "xfsdatad". However, it appears that only one of each of these kernel processes is getting any load, as indicated by "ps ax": 3700 ? S< 0:00 [xfslogd/0] 3701 ? S< 0:19 [xfslogd/1] 3702 ? S< 0:00 [xfsdatad/0] 3703 ? D< 0:05 [xfsdatad/1] For each of these kernel threads, only those on CPU #2 are actually pulling notable load. Why is this? I understand that I may have overlooked some critical tidbit of info in the man pages, or perhaps I have not yet found something online that could explain a default limitation. If so, I would very much enjoy new information about using XFS on a desktop system. TYIA for your answer(s). -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Tue Jun 17 00:41:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 00:41:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H7fTsH029221 for ; Tue, 17 Jun 2008 00:41:30 -0700 X-ASG-Debug-ID: 1213688545-7480033d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6C18A17D8401 for ; Tue, 17 Jun 2008 00:42:26 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id q7fUAnvjSApHsb7F for ; Tue, 17 Jun 2008 00:42:26 -0700 (PDT) Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 17 Jun 2008 17:09:51 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K8VnB-0004VT-Vw; Tue, 17 Jun 2008 17:39:49 +1000 Date: Tue, 17 Jun 2008 17:39:49 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: Dave Chinner , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080617073949.GP3700@disturbed> Mail-Followup-To: Lachlan McIlroy , Dave Chinner , xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48571A57.5090901@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213688547 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53534 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16386 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Tue, Jun 17, 2008 at 11:58:47AM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: >> On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: >>> I'm well aware of that particular deadlock involving the freelist - I >>> hit it while testing. If you look closely at the code that deadlock >>> can occur with or without the AG locking avoidance logic. This is >>> because the rest of the transaction is unaware that an AG has been >>> locked due to a freelist operation. >> >> Yes, which is why you need to prevent freelist modifications occurring >> when you can't allocate anything out of the AG. > > That sounds reasonable but it isn't consistent with the deadlock I saw. > One of the threads that was deadlocked had tried to allocate a data extent > in AG3 but didn't find the space. It had modified, and hence locked, AG3 > due to modifying the freelist but since it didn't get the space it needed > it had to go on to another AG. That sounds like an exact allocation failure - there is enough space, a large enough extent but no free space at the exact block required. This is exactly the case that occurred with the inode allocation - and then allocation in the same AG failed because of alignment that wasn't taken into account by the first exact allocation attempt. Perhaps the minalignslop calculation in xfs_bmap_btalloc() is incorrect... > So before we even allocated the data extent > (and before we tried to modify the btree, etc) we had an AG locked. The > deadlock avoidance code in xfs_alloc_vextent() didn't know this because > it only checks for a previous allocation. It makes sense that we should > avoid modifying the freelist if there isn't enough space for the allocation > so the puzzle is why didn't the code do that? Good question, and I think that is one we need to answer. >>> I considered that approach (using the minleft field in xfs_alloc_arg_t) >>> but it has it's problems too. When we reserve space for the btree >>> operations it is done on the global filesystem counters, not a >>> particular AG, so there is the possibility that not one AG has sufficent >>> space to perform the allocation even though there is enough free space >>> in the whole filesystem. >> >> Yes, we had that problem with the ENOSPC deadlock fixes in that we always >> needed at least 4 blocks per AG available for a extent free to succeed. >> Hence we have the XFS_ALLOC_SET_ASIDE() value for determining if the >> filesystem is out of space, not a count of zero free blocks. > > Those 4 blocks are for one extent free operation, right? What if we have > multiple threads all trying to do the same thing (in the same AG)? If we have empty AGF btrees we need to allocate two new root blocks, and then we won't have to allocate any more btree blocks for the next 100+ extent free operations... For allocations, the first would succeed, the rest would have to search for another AG... >>> I'm worried with this approach that we could have delayed allocations and >>> unwritten extents that need to be converted but we can't do it because we >>> don't have the space we might need (but probably don't). >> >> Delayed allocation is the issue - unwritten extent conversion failure will >> simply return an error and leave the extent unwritten. > > That's still a problem though - if we can't convert unwritten extents then > we can't clean dirty pages and we wont be able to unmount the filesystem. There will be errors logged and the extents will remain unwritten. The filesystem should still be able to be unmounted. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 17 00:42:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 00:42:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H7gFee029377 for ; Tue, 17 Jun 2008 00:42:16 -0700 X-ASG-Debug-ID: 1213688590-748003490000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EFB4917D846B for ; Tue, 17 Jun 2008 00:43:11 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id JxDgt09AUHLegEWZ for ; Tue, 17 Jun 2008 00:43:11 -0700 (PDT) Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 17 Jun 2008 17:12:02 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K8VpG-0004Ye-4o; Tue, 17 Jun 2008 17:41:58 +1000 Date: Tue, 17 Jun 2008 17:41:58 +1000 From: Dave Chinner To: Mark Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options Message-ID: <20080617074158.GQ3700@disturbed> Mail-Followup-To: Mark , xfs@oss.sgi.com References: <881489.19090.qm@web34506.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <881489.19090.qm@web34506.mail.mud.yahoo.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213688593 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4223 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53534 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16387 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Tue, Jun 17, 2008 at 12:33:57AM -0700, Mark wrote: > I have been doing some experiments with XFS on my "hot new desktop > system," and I have turned up an interesting bit of info. (Note: > My system is an AMD64 X2 2.5GHz running Linux.) > > When I mount an XFS volume (thus loading the xfs kernel module), > the kernel spawns two CPU-bound threads for "xfslogd" and > "xfsdatad". However, it appears that only one of each of these > kernel processes is getting any load, as indicated by "ps ax": > > 3700 ? S< 0:00 [xfslogd/0] > 3701 ? S< 0:19 [xfslogd/1] > 3702 ? S< 0:00 [xfsdatad/0] > 3703 ? D< 0:05 [xfsdatad/1] > > For each of these kernel threads, only those on CPU #2 are actually pulling notable load. Why is this? Because your disk interrupts are delivered to that CPU only. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 17 02:19:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 02:19:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5H9JGZP003159 for ; Tue, 17 Jun 2008 02:19:17 -0700 X-ASG-Debug-ID: 1213694414-193c01f70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34501.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 0E05823D365 for ; Tue, 17 Jun 2008 02:20:14 -0700 (PDT) Received: from web34501.mail.mud.yahoo.com (web34501.mail.mud.yahoo.com [66.163.178.167]) by cuda.sgi.com with SMTP id PMHBnWPdZr5xk2r6 for ; Tue, 17 Jun 2008 02:20:14 -0700 (PDT) Received: (qmail 86430 invoked by uid 60001); 17 Jun 2008 09:20:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=TKPCWKe7G5eLA4FX+T+cVUF3xeqvWWnh9/X0DvVld/ML49yuii7Ug139Knr37OrSErk8ksfXu9DdaUzjKH1aUrzzzMzbIIldwXqeDD5Rsd6mQAJB+KpXg4cHynhCp5r7ygAZn6H3brsBoto2Iyx6PWMfhxZinrlrTbKv+GegkyI=; Received: from [96.14.203.219] by web34501.mail.mud.yahoo.com via HTTP; Tue, 17 Jun 2008 02:20:14 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 17 Jun 2008 02:20:14 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <153266.85236.qm@web34501.mail.mud.yahoo.com> X-Barracuda-Connect: web34501.mail.mud.yahoo.com[66.163.178.167] X-Barracuda-Start-Time: 1213694415 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53541 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16388 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs --- On Tue, 6/17/08, Dave Chinner wrote: > > For each of these kernel threads, only those on CPU #2 > are actually pulling notable load. Why is this? > > Because your disk interrupts are delivered to that CPU > only. Thank you! Tuning my IRQ delivery gave a noticeable speed-up. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Tue Jun 17 05:26:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 05:26:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5HCQnrD019247 for ; Tue, 17 Jun 2008 05:26:49 -0700 X-ASG-Debug-ID: 1213705666-5b6601100000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 612BF23DC9E for ; Tue, 17 Jun 2008 05:27:47 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id ydxWzOAcGQTnugUH for ; Tue, 17 Jun 2008 05:27:47 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id AB9242ED2D; Tue, 17 Jun 2008 08:27:46 -0400 (EDT) Date: Tue, 17 Jun 2008 08:27:46 -0400 (EDT) From: Justin Piszcz To: Mark cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options In-Reply-To: <153266.85236.qm@web34501.mail.mud.yahoo.com> Message-ID: References: <153266.85236.qm@web34501.mail.mud.yahoo.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1213705667 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53552 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16389 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs How did you tune your IRQ delivery? Justin. On Tue, 17 Jun 2008, Mark wrote: > --- On Tue, 6/17/08, Dave Chinner wrote: > >>> For each of these kernel threads, only those on CPU #2 >> are actually pulling notable load. Why is this? >> >> Because your disk interrupts are delivered to that CPU >> only. > > Thank you! Tuning my IRQ delivery gave a noticeable speed-up. > > -- > Mark > > "What better place to find oneself than > on the streets of one's home village?" > --Capt. Jean-Luc Picard, "Family" > > From owner-xfs@oss.sgi.com Tue Jun 17 07:04:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 07:04:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_50,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5HE4YWF025624 for ; Tue, 17 Jun 2008 07:04:35 -0700 X-ASG-Debug-ID: 1213711529-39fe00f40000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gw4.outgw.tn (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C562A17D95C2 for ; Tue, 17 Jun 2008 07:05:29 -0700 (PDT) Received: from gw4.outgw.tn (gw4.outgw.tn [193.95.97.184]) by cuda.sgi.com with ESMTP id vn8eo8Tw2nYf9U3D for ; Tue, 17 Jun 2008 07:05:29 -0700 (PDT) Received: from smtp.rnu.tn (smtp.rnu.tn [193.95.32.173]) by tounes-18.ati.tn (Postfix) with ESMTP id BFF78108810C for ; Tue, 17 Jun 2008 16:04:44 +0200 (CEST) Received: from localhost (rnu.tn [127.0.0.1]) by smtp.rnu.tn (Postfix) with ESMTP id B4F7DCB386 for ; Tue, 17 Jun 2008 15:42:17 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at rnu.tn Received: from smtp.rnu.tn ([127.0.0.1]) by localhost (smtp.rnu.tn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO-gmpYjIE9Y for ; Tue, 17 Jun 2008 15:42:17 +0200 (CEST) Received: from Khalil (unknown [41.229.115.3]) by smtp.rnu.tn (Postfix) with ESMTP id 2214DCB384 for ; Tue, 17 Jun 2008 15:42:17 +0200 (CEST) From: "E-MEDISYS 08" X-ASG-Orig-Subj: E-MEDISYS'08: Extended Paper submission deadline Subject: E-MEDISYS'08: Extended Paper submission deadline To: linux-xfs@oss.sgi.com MIME-Version: 1.0 Date: Tue, 17 Jun 2008 16:07:43 +0200 Message-ID: <2008617.396160,672023472222222@enis.rnu.tn> X-Barracuda-Connect: gw4.outgw.tn[193.95.97.184] X-Barracuda-Start-Time: 1213711530 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5045 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.88 X-Barracuda-Spam-Status: No, SCORE=0.88 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE, HTML_TAG_EXIST_TBODY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53557 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.13 HTML_TAG_EXIST_TBODY BODY: HTML has "tbody" tag 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 5607 X-archive-position: 16390 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: medsalim.bouhlel@enis.rnu.tn Precedence: bulk X-list: xfs =20 =20=20=20=20=20=20=20=20=20 Dear Colleagues=20 Apologies for any cross-postings=20 At the request of a number of potential contributors, the E-MEDISYS 2008 Or= ganizing Committee has decided to extend the deadline of paper submission t= o June 30th, 2008. The 2nd International Conference: E-Medical Systems E-MEDISYS 2008 is techn= ically co-sponsored by IEEE. It will be held from 29 to 31 October 2008 in = Sfax, Tunisia.=20 You can find more details in:=20 http://www.setit.rnu.tn/E-Medisys=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 The paper submission can be done on-line at=20 http://www.setit.rnu.tn/E-Medisys/submission=20 Your propositions are welcome (they can be made either in French or in Engl= ish).=20 Accepted Papers will be published in the Conference Proceedings, as a Book= Chapter with the ISBN: 978-9973-0-0124-5 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TUNIS AIR, the Official carrier for the Conference, accords to the particip= ants and their accompaniers a reduction of 50% to the plane tickets.=20 We are waiting for seeing you in Tunisia in E-MEDISYS 2008.=20 Best Regards=20 Mohamed Salim BOUHLEL=20 General Co-Chair, E-MEDISYS 2008=20 Head of Research Unit: Sciences & Technologies of Image and Telecommunicati= ons=20 Higher Institute of Biotechnology of Sfax (Sfax University)=20 BP 261 3038 SFAX TUNISIA=20 GSM +216 20 200005=20 **********************************************************************=20 This email is sent out to all those on the E-MEDISYS 2008 database. If you = want to be removed from this database, please send an email to unsubscribe.= emedisys@gmail.com with subject Unsubscribe. ***************************************************************************= ** E-MEDISYS 2008 Second International Conference of E-Medical Systems Technically co-sponsored by IEEE=20 Sfax, Tunisia, October 29-31, 2008 http://www.setit.rnu.tn/E-medisys/ =20 =3D=3D E-MEDISYS 2008 PRESENTATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D E-Medisys is a new international conference, very innovative, on the topic = of the telemedicine. This conference was born out of collaboration of three teams of research di= vided between Sfax (Tunisia), Besan=E7on (France) and Fez (Morocco). E-Medisys, from its topic interdisciplinary, has the role to bring together= the researchers, and the industrialists, who are actors of the telemedicin= e as well from the medical point of view as from the data-processing point = of view. It is what makes a single event of it: the meeting of the actors who will = allow treating the telemedicine =93from beginning to end=94. This conferenc= e will be held in French and English. Papers will be selected by a mixed re= ading panel gathering of the specialists to re-elect in the field of the te= lemedicine. =3D=3D TOPICS=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The topics of this conference are voluntarily opened in order to support th= e participation of many teams (researchers, teachers, engineers, industrial= ists and students). A broad place will be reserved for the new ideas, with = not yet succeeded work, original work positioning clearly compared to what = exists. Here a non exhaustive list of the topics: Medical Information Management=20 Patient Information=20 Data Archiving=20 Information Systems=20 Data Bases Multimedia=20 Evaluation of the Information Systems of Health=20 Security=20 NTIC and Health Medical Imagery=20 Data-processing Applications for Medical Imagery=20 Segmentation, Rebuilding 3D=20 Computer Graphics=20 Signal Treatments=20 Image, Compression, Coding and Encoding Remote Telemedical Plateforms=20 Collaborative Work, Collaborative Virtual Environments=20 Remote Monitoring=20 Telediagnosis, Teleconsulting=20 E-health=20 Information Systems Integrated of Health for the Shared and Collaborative C= are Ergonomics of the Interfaces=20 Remote Human Computer Interfaces=20 Virtual Reality=20 Increased reality=20 Increased Reality Safety in Distributed Multimedia Applications Medical Systems Communicating=20 Wireless Adhoc Networks (MANET)=20 Personal Networks (PN), Personal Area=20 Networks (PAN), WIMAX=20 Ubiquity and Networks without Wire=20 Networks of Health=20 Sensor Networks: Patients Steady, Patient with Handicap=20 Mobile Care Patient, Mobility=20 Security in Networks =3D=3D IMPORTANT DATES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Paper submission: June 30, 2008 Notification of acceptance: July 31, 2008 Final manuscript due: September 15, 2008 Main conference : October 29-31, 2008 =3D=3D CONFERENCE'S PLACE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Sfax is a city in Tunisia, located 270 km southeast of Tunis. The city is t= he capital of the south of Tunisia, and a Mediterranean port on the Gulf of= Gabes, it is an industrial and touristic center.=20 It is often described as Tunisia's Second city.=20 [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jun 17 10:28:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 10:28:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5HHSe7A009997 for ; Tue, 17 Jun 2008 10:28:40 -0700 X-ASG-Debug-ID: 1213723777-55e100270000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34508.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 6C3B923E7A8 for ; Tue, 17 Jun 2008 10:29:37 -0700 (PDT) Received: from web34508.mail.mud.yahoo.com (web34508.mail.mud.yahoo.com [66.163.178.174]) by cuda.sgi.com with SMTP id F1zgtmdrCaSDsZyu for ; Tue, 17 Jun 2008 10:29:37 -0700 (PDT) Received: (qmail 8593 invoked by uid 60001); 17 Jun 2008 17:29:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=1x95siqWzPS7I3mYhe5COl1BPfcNJx+PZvip1m+nJoa6WQRwYiePod3qXwvcc+g1Vm3sPqNTLdAIT0St43S2z0yCScjni/xc3SG1fg38itGtL4g8LlSz95WhHPcNGbh561oImQipxRfpgS6nmFtVTVqv+pB6xEBuyydHVtF/qlk=; Received: from [96.13.201.11] by web34508.mail.mud.yahoo.com via HTTP; Tue, 17 Jun 2008 10:29:37 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 17 Jun 2008 10:29:37 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <338502.8443.qm@web34508.mail.mud.yahoo.com> X-Barracuda-Connect: web34508.mail.mud.yahoo.com[66.163.178.174] X-Barracuda-Start-Time: 1213723778 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.28 X-Barracuda-Spam-Status: No, SCORE=0.28 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53574 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16391 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs --- On Tue, 6/17/08, Justin Piszcz wrote: > From: Justin Piszcz > Subject: Re: XFS mkfs/mount options > To: "Mark" > Cc: xfs@oss.sgi.com > Date: Tuesday, June 17, 2008, 5:27 AM > > How did you tune your IRQ delivery? Generically: echo X > /proc/irq/[IRQ#]/smp_affinity Where X is a 32-bit hexadecimal bitmask. My real procedure: First, I confirmed that both drives (sda and sdb) were triggering different interrupts on the same CPU. "cat /dev/sda > /dev/null &" for activity, followed by "cat /proc/interrupts" a few times. (NOT AS ROOT!) Interrupt 20 was triggering only on the second CPU. Killed the background task. Repeat, using "cat /dev/sdb > /dev/null &". Interrupt 21, also routing to the second CPU. Bottleneck likely confirmed. A short hunt in /usr/src/linux/Documentation turned up the smp_affinity files. Looking at /proc/irq/2[01]/smp_affinity shows that both contain "ffffffff", that is, use all available CPU's. To force the matter, I typed: echo 00000001 > /proc/irq/21/smp_affinity echo 00000002 > /proc/irq/20/smp_affinity I dropped privileges, then repeated the "cat /dev..." above for both drives, confirming that interrupts were indeed going to CPU0 for int21 and CPU1 for int20. Running a homebrewed multi-threading benchmark showed a possible speed-up for writes on XFS. I have not yet run "official" tests (Bonnie++ or my own) but will do so tonight. I expect the loss from cache-bouncing to be canceled out by the win from concurrent I/O. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Tue Jun 17 13:40:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 13:40:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5HKeSVr027334 for ; Tue, 17 Jun 2008 13:40:28 -0700 X-ASG-Debug-ID: 1213735285-761602300000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 756A1CD8DA0; Tue, 17 Jun 2008 13:41:25 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id y85k3T2vOkYytWXp; Tue, 17 Jun 2008 13:41:25 -0700 (PDT) Received: from [10.0.0.21] (DSL01.83.171.162.93.ip-pool.NEFkom.net [83.171.162.93]) by mail.lichtvoll.de (Postfix) with ESMTP id A61BD5AE11; Tue, 17 Jun 2008 22:38:17 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com, MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options Subject: Re: XFS mkfs/mount options Date: Tue, 17 Jun 2008 22:41:21 +0200 User-Agent: KMail/1.9.9 Cc: xfs@oss.sgi.com References: <338502.8443.qm@web34508.mail.mud.yahoo.com> (sfid-20080617_222310_564625_90C3CEF2) In-Reply-To: <338502.8443.qm@web34508.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806172241.22211.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1213735286 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2268 1.0000 -0.6896 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.41 X-Barracuda-Spam-Status: No, SCORE=-0.41 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53588 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.28 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16392 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Hi Mark, Am Dienstag 17 Juni 2008 schrieb Mark: > --- On Tue, 6/17/08, Justin Piszcz wrote: > > From: Justin Piszcz > > Subject: Re: XFS mkfs/mount options > > To: "Mark" > > Cc: xfs@oss.sgi.com > > Date: Tuesday, June 17, 2008, 5:27 AM > > > > How did you tune your IRQ delivery? > > Generically: > > echo X > /proc/irq/[IRQ#]/smp_affinity > > Where X is a 32-bit hexadecimal bitmask. > > My real procedure: [... longer procedure ...] We always use martin@shambala> apt-cache show irqbalance Package: irqbalance Priority: extra Section: utils Installed-Size: 64 Maintainer: Kyle McMartin Architecture: i386 Version: 0.55-2.1 Depends: debconf (>= 0.5) | debconf-2.0, libc6 (>= 2.7-1), libglib2.0-0 (>= 2.12.0) Filename: pool/main/i/irqbalance/irqbalance_0.55-2.1_i386.deb Size: 17496 MD5sum: e4393d6ac2659e08f1bdecab2d94c1bf SHA1: 4b49deb3b522dec88c820bde78cfb6abb20365dd SHA256: 069104aff5561f09c8affcfe2aa9e144bed359a7c935c71c9968c78d1e8bf1b3 Description: Daemon to balance interrupts for SMP systems Daemon to balance interrupts across multiple CPUs, which can lead to better performance and IO balance on SMP systems. This package is especially useful on systems with multi-core processors, as interrupts will typically only be serviced by the first core. Tag: admin::hardware, admin::kernel, interface::commandline, interface::daemon, network::server, role::program for this kind of task or well the version in Debian Etch of it, the former is Lenny/Sid: Version: 0.12-7 Depends: libc6 (>= 2.3.6-6), debconf (>= 0.5) | debconf-2.0 Is there any need to fine-tune interrupts manually? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Jun 17 20:41:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 20:41:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I3fO1R030083 for ; Tue, 17 Jun 2008 20:41:25 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA09556; Wed, 18 Jun 2008 13:42:16 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 7663558C4C3F; Wed, 18 Jun 2008 13:42:16 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 983394 - factor out has_attrs function Message-Id: <20080618034216.7663558C4C3F@chook.melbourne.sgi.com> Date: Wed, 18 Jun 2008 13:42:16 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16393 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Factor out code for whether inode has attributes or not. Signed-off-by: Christoph Hellwig Date: Wed Jun 18 13:41:05 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31323a fs/xfs/xfs_attr.c - 1.153 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.153&r2=text&tr2=1.152&f=h - Factor out xfs_inode_hasattr. From owner-xfs@oss.sgi.com Tue Jun 17 21:02:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:02:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I42ejw031403 for ; Tue, 17 Jun 2008 21:02:41 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10051; Wed, 18 Jun 2008 14:03:34 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id A209958C4C3F; Wed, 18 Jun 2008 14:03:34 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 983395 - simplify xfs_vn_listxattr Message-Id: <20080618040334.A209958C4C3F@chook.melbourne.sgi.com> Date: Wed, 18 Jun 2008 14:03:34 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16394 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. Signed-off-by: Christoph Hellwig Date: Wed Jun 18 14:02:38 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31324a fs/xfs/xfs_acl.c - 1.74 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.c.diff?r1=text&tr1=1.74&r2=text&tr2=1.73&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/xfs_attr_leaf.h - 1.48 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.h.diff?r1=text&tr1=1.48&r2=text&tr2=1.47&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/xfs_attr_leaf.c - 1.113 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr_leaf.c.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/xfs_attr.c - 1.154 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.c.diff?r1=text&tr1=1.154&r2=text&tr2=1.153&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/xfs_attr.h - 1.42 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.42&r2=text&tr2=1.41&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. fs/xfs/linux-2.6/xfs_xattr.c - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_xattr.c.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - Switches xfs_vn_listxattr to set it's put_listent callback directly and not go through xfs_attr_list. From owner-xfs@oss.sgi.com Tue Jun 17 21:22:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:22:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I4Lq1I032751 for ; Tue, 17 Jun 2008 21:21:57 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10437; Wed, 18 Jun 2008 14:22:47 +1000 Message-ID: <48588E6B.3010006@sgi.com> Date: Wed, 18 Jun 2008 14:26:19 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: lachlan@sgi.com CC: xfs-dev , xfs-oss Subject: Re: [PATCH V2] make inode reclaim wait for log I/O to complete References: <48364E43.3030108@sgi.com> In-Reply-To: <48364E43.3030108@sgi.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16395 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs ping. Lachlan McIlroy wrote: > During a forced shutdown a xfs inode can be destroyed before log > I/O involving that inode is complete. We need to wait for the > inode to be unpinned before tearing it down. Version 2 cleans up > the code a bit by relying on xfs_iflush() to do the unpinning and > forced shutdown check. > > --- fs/xfs/xfs_inode.c_1.504 2008-05-23 11:19:21.000000000 +1000 > +++ fs/xfs/xfs_inode.c 2008-05-23 11:21:14.000000000 +1000 > @@ -3082,8 +3082,6 @@ xfs_iflush( > * flush lock and do nothing. > */ > if (xfs_inode_clean(ip)) { > - ASSERT((iip != NULL) ? > - !(iip->ili_item.li_flags & XFS_LI_IN_AIL) : 1); > xfs_ifunlock(ip); > return 0; > } > --- fs/xfs/xfs_vnodeops.c_1.760 2008-05-22 16:01:09.000000000 +1000 > +++ fs/xfs/xfs_vnodeops.c 2008-05-23 11:52:54.000000000 +1000 > @@ -3260,7 +3260,6 @@ xfs_finish_reclaim( > { > xfs_perag_t *pag = xfs_get_perag(ip->i_mount, ip->i_ino); > bhv_vnode_t *vp = XFS_ITOV_NULL(ip); > - int error; > > if (vp && VN_BAD(vp)) > goto reclaim; > @@ -3303,29 +3302,16 @@ xfs_finish_reclaim( > xfs_iflock(ip); > } > > - if (!XFS_FORCED_SHUTDOWN(ip->i_mount)) { > - if (ip->i_update_core || > - ((ip->i_itemp != NULL) && > - (ip->i_itemp->ili_format.ilf_fields != 0))) { > - error = xfs_iflush(ip, sync_mode); > - /* > - * If we hit an error, typically because of filesystem > - * shutdown, we don't need to let vn_reclaim to know > - * because we're gonna reclaim the inode anyway. > - */ > - if (error) { > - xfs_iunlock(ip, XFS_ILOCK_EXCL); > - goto reclaim; > - } > - xfs_iflock(ip); /* synchronize with xfs_iflush_done */ > - } > - > - ASSERT(ip->i_update_core == 0); > - ASSERT(ip->i_itemp == NULL || > - ip->i_itemp->ili_format.ilf_fields == 0); > + /* > + * In the case of a forced shutdown we rely on xfs_iflush() to > + * wait for the inode to be unpinned before returning an error. > + */ > + if (xfs_iflush(ip, sync_mode) == 0) { > + /* synchronize with xfs_iflush_done */ > + xfs_iflock(ip); > + xfs_ifunlock(ip); > } > > - xfs_ifunlock(ip); > xfs_iunlock(ip, XFS_ILOCK_EXCL); > > reclaim: > > > From owner-xfs@oss.sgi.com Tue Jun 17 21:29:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:29:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5I4TEk6000914 for ; Tue, 17 Jun 2008 21:29:14 -0700 X-ASG-Debug-ID: 1213763410-601503090000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 674182426A4 for ; Tue, 17 Jun 2008 21:30:11 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id MH9DsiCWiCc9piZS for ; Tue, 17 Jun 2008 21:30:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoGADgrWEh5LG+uWmdsb2JhbACSKwEdnFI X-IronPort-AV: E=Sophos;i="4.27,662,1204464600"; d="scan'208";a="128906682" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 18 Jun 2008 14:00:04 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K8pJ5-0004vU-0Y; Wed, 18 Jun 2008 14:30:03 +1000 Date: Wed, 18 Jun 2008 14:30:02 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH V2] make inode reclaim wait for log I/O to complete Subject: Re: [PATCH V2] make inode reclaim wait for log I/O to complete Message-ID: <20080618043002.GS3700@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <48364E43.3030108@sgi.com> <48588E6B.3010006@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48588E6B.3010006@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213763412 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0004 1.0000 -2.0181 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53609 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16396 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 02:26:19PM +1000, Lachlan McIlroy wrote: > ping. > > Lachlan McIlroy wrote: >> During a forced shutdown a xfs inode can be destroyed before log >> I/O involving that inode is complete. We need to wait for the >> inode to be unpinned before tearing it down. Version 2 cleans up >> the code a bit by relying on xfs_iflush() to do the unpinning and >> forced shutdown check. Sorry I missed this when you first posted it. This one looks ok. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 17 21:44:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:44:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I4iKlA002146 for ; Tue, 17 Jun 2008 21:44:23 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA10990; Wed, 18 Jun 2008 14:45:11 +1000 Message-ID: <485892D7.4080000@sgi.com> Date: Wed, 18 Jun 2008 14:45:11 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] kill INDUCE_IO_ERROR References: <20080523062323.GA32637@lst.de> <20080616101412.GA17939@lst.de> In-Reply-To: <20080616101412.GA17939@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16397 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, May 23, 2008 at 08:23:23AM +0200, Christoph Hellwig wrote: >> All the error injection is already enabled through ifdef DEBUG, so kill >> the never set second cpp symbol to activate it without the rest of the >> debugging infrastructure. > > Can I get a review on this absolutely trivial patch? I'd like to keep INDUCE_IO_ERROR around so we have a way to introduce ioerrors in release builds during testing. We could add it to xfs.h with the commented out QUOTADEBUG so people know we still want to use it. Don >> >> Signed-off-by: Christoph Hellwig >> >> Index: linux-2.6-xfs/fs/xfs/xfs_error.c >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/xfs_error.c 2008-05-22 18:55:04.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/xfs_error.c 2008-05-22 18:55:16.000000000 +0200 >> @@ -58,9 +58,6 @@ xfs_error_trap(int e) >> } >> return e; >> } >> -#endif >> - >> -#if (defined(DEBUG) || defined(INDUCE_IO_ERROR)) >> >> int xfs_etest[XFS_NUM_INJECT_ERROR]; >> int64_t xfs_etest_fsid[XFS_NUM_INJECT_ERROR]; >> @@ -154,7 +151,7 @@ xfs_errortag_clearall(xfs_mount_t *mp, i >> >> return 0; >> } >> -#endif /* DEBUG || INDUCE_IO_ERROR */ >> +#endif /* DEBUG */ >> >> static void >> xfs_fs_vcmn_err(int level, xfs_mount_t *mp, char *fmt, va_list ap) >> Index: linux-2.6-xfs/fs/xfs/xfs_error.h >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/xfs_error.h 2008-05-22 18:55:04.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/xfs_error.h 2008-05-22 18:55:16.000000000 +0200 >> @@ -125,22 +125,14 @@ extern void xfs_corruption_error(char *t >> #define XFS_RANDOM_DIOWRITE_IOERR (XFS_RANDOM_DEFAULT/10) >> #define XFS_RANDOM_BMAPIFORMAT XFS_RANDOM_DEFAULT >> >> -#if (defined(DEBUG) || defined(INDUCE_IO_ERROR)) >> +#ifdef DEBUG >> extern int xfs_error_test(int, int *, char *, int, char *, unsigned long); >> >> #define XFS_NUM_INJECT_ERROR 10 >> - >> -#ifdef __ANSI_CPP__ >> -#define XFS_TEST_ERROR(expr, mp, tag, rf) \ >> - ((expr) || \ >> - xfs_error_test((tag), (mp)->m_fixedfsid, #expr, __LINE__, __FILE__, \ >> - (rf))) >> -#else >> #define XFS_TEST_ERROR(expr, mp, tag, rf) \ >> ((expr) || \ >> xfs_error_test((tag), (mp)->m_fixedfsid, "expr", __LINE__, __FILE__, \ >> (rf))) >> -#endif /* __ANSI_CPP__ */ >> >> extern int xfs_errortag_add(int error_tag, xfs_mount_t *mp); >> extern int xfs_errortag_clearall(xfs_mount_t *mp, int loud); >> @@ -148,7 +140,7 @@ extern int xfs_errortag_clearall(xfs_mou >> #define XFS_TEST_ERROR(expr, mp, tag, rf) (expr) >> #define xfs_errortag_add(tag, mp) (ENOSYS) >> #define xfs_errortag_clearall(mp, loud) (ENOSYS) >> -#endif /* (DEBUG || INDUCE_IO_ERROR) */ >> +#endif /* DEBUG */ >> >> /* >> * XFS panic tags -- allow a call to xfs_cmn_err() be turned into >> Index: linux-2.6-xfs/fs/xfs/xfs_mount.c >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/xfs_mount.c 2008-05-22 18:55:05.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/xfs_mount.c 2008-05-23 08:11:46.000000000 +0200 >> @@ -1322,7 +1322,7 @@ xfs_unmountfs(xfs_mount_t *mp) >> if ((mp->m_flags & XFS_MOUNT_NOUUID) == 0) >> uuid_table_remove(&mp->m_sb.sb_uuid); >> >> -#if defined(DEBUG) || defined(INDUCE_IO_ERROR) >> +#if defined(DEBUG) >> xfs_errortag_clearall(mp, 0); >> #endif >> xfs_mount_free(mp); > ---end quoted text--- > From owner-xfs@oss.sgi.com Tue Jun 17 21:48:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 21:48:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5I4maXO002748 for ; Tue, 17 Jun 2008 21:48:40 -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 OAA11059; Wed, 18 Jun 2008 14:49:30 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 5DAC558C4C3F; Wed, 18 Jun 2008 14:49:30 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 982930 - userland changes for dir2 shortform structures fixes on ARM old ABI Message-Id: <20080618044930.5DAC558C4C3F@chook.melbourne.sgi.com> Date: Wed, 18 Jun 2008 14:49:30 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16398 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 Userland side of kernel changes for fixing issues with dir2 ondisk differences on old ARM ABI boxes. Provided by Eric Sandeen. Date: Wed Jun 18 14:47:55 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/xfs-cmds Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31325a xfsprogs/doc/CHANGES - 1.254 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/doc/CHANGES.diff?r1=text&tr1=1.254&r2=text&tr2=1.253&f=h xfsprogs/include/xfs_dir2_sf.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/xfs_dir2_sf.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h xfsprogs/include/platform_defs.h.in - 1.35 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfsprogs/include/platform_defs.h.in.diff?r1=text&tr1=1.35&r2=text&tr2=1.34&f=h - Userland side of kernel changes for fixing issues with dir2 ondisk differences on old ARM ABI boxes. From owner-xfs@oss.sgi.com Tue Jun 17 23:35:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 23:35:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I6Zams009281 for ; Tue, 17 Jun 2008 23:35:37 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA12923; Wed, 18 Jun 2008 16:36:30 +1000 Message-ID: <4858ADC3.4060609@sgi.com> Date: Wed, 18 Jun 2008 16:40:03 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH V2] make inode reclaim wait for log I/O to complete References: <48364E43.3030108@sgi.com> <48588E6B.3010006@sgi.com> <20080618043002.GS3700@disturbed> In-Reply-To: <20080618043002.GS3700@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16399 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Wed, Jun 18, 2008 at 02:26:19PM +1000, Lachlan McIlroy wrote: >> ping. >> >> Lachlan McIlroy wrote: >>> During a forced shutdown a xfs inode can be destroyed before log >>> I/O involving that inode is complete. We need to wait for the >>> inode to be unpinned before tearing it down. Version 2 cleans up >>> the code a bit by relying on xfs_iflush() to do the unpinning and >>> forced shutdown check. > > Sorry I missed this when you first posted it. This one looks ok. > Thanks Dave. From owner-xfs@oss.sgi.com Tue Jun 17 23:42:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 17 Jun 2008 23:42:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from 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 m5I6gigr010967 for ; Tue, 17 Jun 2008 23:42:45 -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 QAA13017; Wed, 18 Jun 2008 16:43:38 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 0CABC58C4C3F; Wed, 18 Jun 2008 16:43:37 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 981240 - make inode reclaim wait for log I/O to complete Message-Id: <20080618064338.0CABC58C4C3F@chook.melbourne.sgi.com> Date: Wed, 18 Jun 2008 16:43:37 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) 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: 16400 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs make inode reclaim wait for log I/O to complete During a forced shutdown a xfs inode can be destroyed before log I/O involving that inode is complete. We need to wait for the inode to be unpinned before tearing it down. Version 2 cleans up the code a bit by relying on xfs_iflush() to do the unpinning and forced shutdown check. Date: Wed Jun 18 16:42:26 AEST 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-iunpin Inspected by: dgc Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31326a fs/xfs/xfs_vnodeops.c - 1.761 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.761&r2=text&tr2=1.760&f=h fs/xfs/xfs_inode.c - 1.505 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.505&r2=text&tr2=1.504&f=h - make inode reclaim wait for log I/O to complete From owner-xfs@oss.sgi.com Wed Jun 18 00:18:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 00:18:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5I7ISUS015915 for ; Wed, 18 Jun 2008 00:18:29 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA13695; Wed, 18 Jun 2008 17:19:16 +1000 Message-ID: <4858B6F4.5010705@sgi.com> Date: Wed, 18 Jun 2008 17:19:16 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] fix XFSQA 144 References: <20080614192248.GA24329@lst.de> In-Reply-To: <20080614192248.GA24329@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16401 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > Two really dumb bugs: > > - "foo & 0x3FFFFFFFFFFFF" doesn't cap at 1TB, but rather at more than > two magnitudes larger than that. That gets us EFBIG with typical > 32bit XFS setups. > - the command array can easily overflow and thus let the test fail > > > Signed-off-by: Christoph Hellwig Looks good, thanks for the fix. Checking it in now. > > > Index: xfstests/dmapi/src/suite2/src/test_fileattr.c > =================================================================== > RCS file: /cvs/xfs-cmds/xfstests/dmapi/src/suite2/src/test_fileattr.c,v > retrieving revision 1.12 > diff -u -p -r1.12 test_fileattr.c > --- xfstests/dmapi/src/suite2/src/test_fileattr.c 21 Sep 2007 04:15:06 -0000 1.12 > +++ xfstests/dmapi/src/suite2/src/test_fileattr.c 14 Jun 2008 19:12:43 -0000 > @@ -160,7 +160,7 @@ main( > char *ls_path; > char *pathname; > char test_file[100]; > - char command[100]; > + char command[200]; > int num_files=50; > dm_stat_t *stat_arr; > dm_stat_t dmstat; > @@ -244,7 +244,7 @@ main( > stat_arr[i].dt_uid=(uid_t)(rand()+rand()*0x10000); > stat_arr[i].dt_gid=(gid_t)(rand()+rand()*0x10000); > stat_arr[i].dt_mode=(mode_t)((rand()%4096)+32768); > - stat_arr[i].dt_size=((dm_off_t)(rand()+rand()*0x10000)) & 0x3FFFFFFFFFFFF; /* 1 TB max */ > + stat_arr[i].dt_size=((dm_off_t)(rand()+rand()*0x10000)) & 0x1FFFFFFFFFFULL; /* 1 TB max */ > } > > /*-----------------------------------------------------*\ > From owner-xfs@oss.sgi.com Wed Jun 18 00:20:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 00:20:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SUBJ_FORWARDED 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 m5I7K3TX020806 for ; Wed, 18 Jun 2008 00:20:04 -0700 X-ASG-Debug-ID: 1213773661-38f803c00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34506.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 4F86ECE50DB for ; Wed, 18 Jun 2008 00:21:01 -0700 (PDT) Received: from web34506.mail.mud.yahoo.com (web34506.mail.mud.yahoo.com [66.163.178.172]) by cuda.sgi.com with SMTP id H5hhsmkFzYmkbDHx for ; Wed, 18 Jun 2008 00:21:01 -0700 (PDT) Received: (qmail 1429 invoked by uid 60001); 18 Jun 2008 07:21:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=olE9+g4I4R5+FNFwppU1s6gwLh10iRlvV47wgRUj+CcN/N5UC7N8hGbIunT28wZZCLC1Z9QmXYP+tACh1EMAiyCzXYgyYw42dMtjhAhPR/uVaeuL+dvjD8oIEg7GdD+xWsMsR6bxxm0TvQoKmh6hGaYC5Gbb7toNIGhMQ1Wt5A8=; Received: from [96.13.199.29] by web34506.mail.mud.yahoo.com via HTTP; Wed, 18 Jun 2008 00:21:01 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Wed, 18 Jun 2008 00:21:01 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: Fw: Re: XFS mkfs/mount options Subject: Fw: Re: XFS mkfs/mount options To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <521591.99815.qm@web34506.mail.mud.yahoo.com> X-Barracuda-Connect: web34506.mail.mud.yahoo.com[66.163.178.172] X-Barracuda-Start-Time: 1213773662 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53622 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: 16402 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs To all, It appears I have found a defect in my testing. Generally, the procedure has been something like: create filesystem mount filesystem and set owner/group run benchmark alter some condition (CPU speed or IRQ routing) re-run benchmark compare results The second run is contaminated by caching effects from the first run. This accounts for the roughly 5% speedup I saw after enabling explicit IRQ routing. Once I corrected this oversight, the difference became statistical noise. My apologies to all for this red herring. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Wed Jun 18 00:21:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 00:21:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=5.0 tests=AWL,BAYES_50,J_CHICKENPOX_51, NORMAL_HTTP_TO_IP,SUBJ_FORWARDED,UPPERCASE_50_75 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5I7LlsN021244 for ; Wed, 18 Jun 2008 00:21:47 -0700 X-ASG-Debug-ID: 1213773761-348403c60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bay0-omc3-s27.bay0.hotmail.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A8B6D1037CDC for ; Wed, 18 Jun 2008 00:22:41 -0700 (PDT) Received: from bay0-omc3-s27.bay0.hotmail.com (bay0-omc3-s27.bay0.hotmail.com [65.54.246.227]) by cuda.sgi.com with ESMTP id ms7KwnGVla6cKEsX for ; Wed, 18 Jun 2008 00:22:41 -0700 (PDT) Received: from hotmail.com ([65.54.174.78]) by bay0-omc3-s27.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jun 2008 00:22:40 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 Jun 2008 00:22:40 -0700 Message-ID: Received: from 85.32.103.134 by BAY103-DAV6.phx.gbl with DAV; Wed, 18 Jun 2008 07:22:38 +0000 X-Originating-IP: [85.32.103.134] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: X-ASG-Orig-Subj: Fw: 2.6.26-rc6 link count mismatch for inode Subject: Fw: 2.6.26-rc6 link count mismatch for inode Date: Wed, 18 Jun 2008 09:22:03 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 18 Jun 2008 07:22:40.0522 (UTC) FILETIME=[179486A0:01C8D114] X-Barracuda-Connect: bay0-omc3-s27.bay0.hotmail.com[65.54.246.227] X-Barracuda-Start-Time: 1213773762 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.93 X-Barracuda-Spam-Status: No, SCORE=-0.93 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, MSGID_FROM_MTA_HEADER, NORMAL_HTTP_TO_IP, UPPERCASE_50_75 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53622 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.59 UPPERCASE_50_75 message body is 50-75% uppercase 0.50 BSF_RULE7568M Custom Rule 7568M 0.00 MSGID_FROM_MTA_HEADER Message-Id was added by a relay X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16403 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Marco Berizzi wrote: > Hi Folk, > > I was tring to compile firefox 3.0rc3 > and while I was erasing a previous > /tmp/mozilla tree, I started a new > tar xjf mozilla-blabla. > After a while linux 2.6.26-rc6 was > unresponsive: I have unplugged the > power cable. No problem at startup, > but: sorry folks, is there any news about this problem? > root@Venus:/tmp# rm -r mozilla/ > rm: cannot remove `mozilla//netwerk/build/.deps': No such file or > directory > rm: cannot remove `mozilla//netwerk/resources/content/CVS': No such file > or directory > > root@Venus:/tmp/mozilla/netwerk# rm -r build > rm: cannot remove `build/.deps': No such file or directory > root@Venus:/tmp/mozilla/netwerk# cd build/ > root@Venus:/tmp/mozilla/netwerk/build# rm -r .deps > rm: cannot remove `.deps': No such file or directory > root@Venus:/tmp/mozilla/netwerk/build# ls -fl > /bin/ls: cannot access .deps: No such file or directory > total 0 > drwxr-xr-x 3 root root 18 2008-06-16 10:03 ./ > drwxr-xr-x 4 root root 34 2008-06-16 10:03 ../ > ?????????? ? ? ? ? ? .deps > > so, I have checked the filesystem with: > xfs_check /dev/sda2: > > bad format 1 for inode 70353 type 0 > bad format 2 for inode 98831 type 0 > agi unlinked bucket 13 is 10573 in ag 0 (inode=10573) > agi unlinked bucket 6 is 1309318 in ag 1 (inode=18086534) > agi unlinked bucket 7 is 1309319 in ag 1 (inode=18086535) > agi unlinked bucket 40 is 471720 in ag 2 (inode=34026152) > bad format 1 for inode 85450805 type 0 > bad format 2 for inode 85450806 type 0 > bad format 2 for inode 85450807 type 0 > bad format 2 for inode 85450808 type 0 > bad format 2 for inode 85450809 type 0 > block 0/6279 type unknown not expected > block 0/6280 type unknown not expected > block 0/6281 type unknown not expected > block 0/6282 type unknown not expected > block 0/6283 type unknown not expected > block 0/6284 type unknown not expected > block 0/6285 type unknown not expected > block 5/97840 type unknown not expected > block 5/97841 type unknown not expected > block 5/97842 type unknown not expected > block 5/97843 type unknown not expected > link count mismatch for inode 70353 (name ?), nlink 0, counted 1 > allocated inode 98831 has 0 link count > allocated inode 10573 has 0 link count > allocated inode 18086534 has 0 link count > allocated inode 18086535 has 0 link count > link count mismatch for inode 19893187 (name ?), nlink 3, counted 2 > allocated inode 34026152 has 0 link count > link count mismatch for inode 67179727 (name ?), nlink 3, counted 2 > link count mismatch for inode 85450805 (name ?), nlink 0, counted 1 > allocated inode 85450806 has 0 link count > allocated inode 85450807 has 0 link count > allocated inode 85450808 has 0 link count > allocated inode 85450809 has 0 link count > > I have not run xfs_repair. If anyone > need ssh access to the box just drop > me a message. > > Metadump available at: > > http://80.204.235.230/metadump.bin.bz2 > > and xfs_check verbose: > > http://80.204.235.230/xfs_check_log.bz2 > > Linux Venus 2.6.26-rc6 #1 SMP PREEMPT Fri Jun 13 13:01:19 CEST 2008 i686 > Intel(R > ) Core(TM)2 Duo CPU T8100 @ 2.10GHz GenuineIntel GNU/Linux > > Gnu C 4.2.3 > Gnu make 3.81 > binutils 2.17.50.0.17.20070615 > util-linux 2.13.1 > mount 2.13.1 > module-init-tools 3.4 > e2fsprogs 1.40.8 > xfsprogs 2.9.7 > pcmciautils 014 > PPP 2.4.4 > Linux C Library 2.7 > Dynamic linker (ldd) 2.7 > Linux C++ Library 6.0.9 > Procps 3.2.7 > Net-tools 1.60 > Kbd 1.12 > oprofile 0.9.2 > Sh-utils 6.9 > Modules Loaded ext2 snd_seq_oss snd_seq_device > snd_seq_midi_event snd_se > q snd_pcm_oss snd_mixer_oss snd_hda_intel snd_pcm snd_timer snd > soundcore snd_pa > ge_alloc pcmcia crc32 yenta_socket rsrc_nonstatic pcmcia_core battery ac > ppp_syn > ctty ppp_deflate zlib_deflate zlib_inflate ppp_async crc_ccitt bsd_comp > ppp_gene > ric slhc intel_agp ohci_hcd option usbserial usbcore tg3 psmouse > > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.26-rc6 > # Fri Jun 13 13:13:53 2008 > # > # CONFIG_64BIT is not set > CONFIG_X86_32=y > # CONFIG_X86_64 is not set > CONFIG_X86=y > CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig" > # CONFIG_GENERIC_LOCKBREAK is not set > CONFIG_GENERIC_TIME=y > CONFIG_GENERIC_CMOS_UPDATE=y > CONFIG_CLOCKSOURCE_WATCHDOG=y > CONFIG_GENERIC_CLOCKEVENTS=y > CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y > CONFIG_LOCKDEP_SUPPORT=y > CONFIG_STACKTRACE_SUPPORT=y > CONFIG_HAVE_LATENCYTOP_SUPPORT=y > CONFIG_FAST_CMPXCHG_LOCAL=y > CONFIG_MMU=y > CONFIG_ZONE_DMA=y > CONFIG_GENERIC_ISA_DMA=y > CONFIG_GENERIC_IOMAP=y > CONFIG_GENERIC_BUG=y > CONFIG_GENERIC_HWEIGHT=y > # CONFIG_GENERIC_GPIO is not set > CONFIG_ARCH_MAY_HAVE_PC_FDC=y > # CONFIG_RWSEM_GENERIC_SPINLOCK is not set > CONFIG_RWSEM_XCHGADD_ALGORITHM=y > # CONFIG_ARCH_HAS_ILOG2_U32 is not set > # CONFIG_ARCH_HAS_ILOG2_U64 is not set > CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y > CONFIG_GENERIC_CALIBRATE_DELAY=y > # CONFIG_GENERIC_TIME_VSYSCALL is not set > CONFIG_ARCH_HAS_CPU_RELAX=y > CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > CONFIG_HAVE_SETUP_PER_CPU_AREA=y > # CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set > CONFIG_ARCH_HIBERNATION_POSSIBLE=y > CONFIG_ARCH_SUSPEND_POSSIBLE=y > # CONFIG_ZONE_DMA32 is not set > CONFIG_ARCH_POPULATES_NODE_MAP=y > # CONFIG_AUDIT_ARCH is not set > CONFIG_ARCH_SUPPORTS_AOUT=y > CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y > CONFIG_GENERIC_HARDIRQS=y > CONFIG_GENERIC_IRQ_PROBE=y > CONFIG_GENERIC_PENDING_IRQ=y > CONFIG_X86_SMP=y > CONFIG_X86_32_SMP=y > CONFIG_X86_HT=y > CONFIG_X86_BIOS_REBOOT=y > CONFIG_X86_TRAMPOLINE=y > CONFIG_KTIME_SCALAR=y > CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" > > # > # General setup > # > # CONFIG_EXPERIMENTAL is not set > CONFIG_LOCK_KERNEL=y > CONFIG_INIT_ENV_ARG_LIMIT=32 > CONFIG_LOCALVERSION="" > # CONFIG_LOCALVERSION_AUTO is not set > CONFIG_SWAP=y > CONFIG_SYSVIPC=y > CONFIG_SYSVIPC_SYSCTL=y > CONFIG_BSD_PROCESS_ACCT=y > # CONFIG_BSD_PROCESS_ACCT_V3 is not set > # CONFIG_TASKSTATS is not set > # CONFIG_AUDIT is not set > # CONFIG_IKCONFIG is not set > CONFIG_LOG_BUF_SHIFT=14 > # CONFIG_CGROUPS is not set > CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y > # CONFIG_SYSFS_DEPRECATED_V2 is not set > # CONFIG_RELAY is not set > CONFIG_NAMESPACES=y > # CONFIG_UTS_NS is not set > # CONFIG_IPC_NS is not set > # CONFIG_BLK_DEV_INITRD is not set > # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set > CONFIG_SYSCTL=y > # CONFIG_EMBEDDED is not set > CONFIG_UID16=y > CONFIG_SYSCTL_SYSCALL=y > CONFIG_SYSCTL_SYSCALL_CHECK=y > CONFIG_KALLSYMS=y > # CONFIG_KALLSYMS_EXTRA_PASS is not set > CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > CONFIG_ELF_CORE=y > CONFIG_PCSPKR_PLATFORM=y > CONFIG_COMPAT_BRK=y > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_ANON_INODES=y > CONFIG_EPOLL=y > CONFIG_SIGNALFD=y > CONFIG_TIMERFD=y > CONFIG_EVENTFD=y > CONFIG_SHMEM=y > CONFIG_VM_EVENT_COUNTERS=y > CONFIG_SLUB_DEBUG=y > # CONFIG_SLAB is not set > CONFIG_SLUB=y > # CONFIG_SLOB is not set > # CONFIG_PROFILING is not set > # CONFIG_MARKERS is not set > CONFIG_HAVE_OPROFILE=y > # CONFIG_KPROBES is not set > CONFIG_HAVE_KPROBES=y > CONFIG_HAVE_KRETPROBES=y > # CONFIG_HAVE_DMA_ATTRS is not set > CONFIG_PROC_PAGE_MONITOR=y > CONFIG_SLABINFO=y > CONFIG_RT_MUTEXES=y > # CONFIG_TINY_SHMEM is not set > CONFIG_BASE_SMALL=0 > CONFIG_MODULES=y > # CONFIG_MODULE_FORCE_LOAD is not set > CONFIG_MODULE_UNLOAD=y > # CONFIG_MODVERSIONS is not set > # CONFIG_MODULE_SRCVERSION_ALL is not set > # CONFIG_KMOD is not set > CONFIG_STOP_MACHINE=y > CONFIG_BLOCK=y > # CONFIG_LBD is not set > # CONFIG_BLK_DEV_IO_TRACE is not set > # CONFIG_LSF is not set > > # > # IO Schedulers > # > CONFIG_IOSCHED_NOOP=y > # CONFIG_IOSCHED_AS is not set > # CONFIG_IOSCHED_DEADLINE is not set > CONFIG_IOSCHED_CFQ=y > # CONFIG_DEFAULT_AS is not set > # CONFIG_DEFAULT_DEADLINE is not set > CONFIG_DEFAULT_CFQ=y > # CONFIG_DEFAULT_NOOP is not set > CONFIG_DEFAULT_IOSCHED="cfq" > CONFIG_CLASSIC_RCU=y > > # > # Processor type and features > # > # CONFIG_TICK_ONESHOT is not set > # CONFIG_NO_HZ is not set > # CONFIG_HIGH_RES_TIMERS is not set > CONFIG_GENERIC_CLOCKEVENTS_BUILD=y > CONFIG_SMP=y > CONFIG_X86_PC=y > # CONFIG_X86_ELAN is not set > # CONFIG_X86_VOYAGER is not set > # CONFIG_X86_NUMAQ is not set > # CONFIG_X86_SUMMIT is not set > # CONFIG_X86_BIGSMP is not set > # CONFIG_X86_VISWS is not set > # CONFIG_X86_GENERICARCH is not set > # CONFIG_X86_ES7000 is not set > # CONFIG_X86_RDC321X is not set > # CONFIG_X86_VSMP is not set > # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set > # CONFIG_PARAVIRT_GUEST is not set > # CONFIG_M386 is not set > # CONFIG_M486 is not set > # CONFIG_M586 is not set > # CONFIG_M586TSC is not set > # CONFIG_M586MMX is not set > # CONFIG_M686 is not set > # CONFIG_MPENTIUMII is not set > # CONFIG_MPENTIUMIII is not set > # CONFIG_MPENTIUMM is not set > # CONFIG_MPENTIUM4 is not set > # CONFIG_MK6 is not set > # CONFIG_MK7 is not set > # CONFIG_MK8 is not set > # CONFIG_MCRUSOE is not set > # CONFIG_MEFFICEON is not set > # CONFIG_MWINCHIPC6 is not set > # CONFIG_MWINCHIP2 is not set > # CONFIG_MWINCHIP3D is not set > # CONFIG_MGEODEGX1 is not set > # CONFIG_MGEODE_LX is not set > # CONFIG_MCYRIXIII is not set > # CONFIG_MVIAC3_2 is not set > # CONFIG_MVIAC7 is not set > # CONFIG_MPSC is not set > CONFIG_MCORE2=y > # CONFIG_GENERIC_CPU is not set > # CONFIG_X86_GENERIC is not set > CONFIG_X86_CPU=y > CONFIG_X86_CMPXCHG=y > CONFIG_X86_L1_CACHE_SHIFT=6 > CONFIG_X86_XADD=y > CONFIG_X86_WP_WORKS_OK=y > CONFIG_X86_INVLPG=y > CONFIG_X86_BSWAP=y > CONFIG_X86_POPAD_OK=y > CONFIG_X86_GOOD_APIC=y > CONFIG_X86_INTEL_USERCOPY=y > CONFIG_X86_USE_PPRO_CHECKSUM=y > CONFIG_X86_P6_NOP=y > CONFIG_X86_TSC=y > CONFIG_X86_MINIMUM_CPU_FAMILY=6 > CONFIG_X86_DEBUGCTLMSR=y > CONFIG_HPET_TIMER=y > CONFIG_DMI=y > # CONFIG_IOMMU_HELPER is not set > CONFIG_NR_CPUS=2 > # CONFIG_SCHED_SMT is not set > CONFIG_SCHED_MC=y > # CONFIG_PREEMPT_NONE is not set > # CONFIG_PREEMPT_VOLUNTARY is not set > CONFIG_PREEMPT=y > # CONFIG_PREEMPT_RCU is not set > CONFIG_X86_LOCAL_APIC=y > CONFIG_X86_IO_APIC=y > # CONFIG_X86_MCE is not set > CONFIG_VM86=y > # CONFIG_TOSHIBA is not set > # CONFIG_I8K is not set > # CONFIG_X86_REBOOTFIXUPS is not set > # CONFIG_MICROCODE is not set > # CONFIG_X86_MSR is not set > # CONFIG_X86_CPUID is not set > # CONFIG_NOHIGHMEM is not set > CONFIG_HIGHMEM4G=y > # CONFIG_HIGHMEM64G is not set > CONFIG_PAGE_OFFSET=0xC0000000 > CONFIG_HIGHMEM=y > CONFIG_FLATMEM=y > CONFIG_FLAT_NODE_MEM_MAP=y > # CONFIG_SPARSEMEM_STATIC is not set > # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set > CONFIG_PAGEFLAGS_EXTENDED=y > CONFIG_SPLIT_PTLOCK_CPUS=4 > # CONFIG_RESOURCES_64BIT is not set > CONFIG_ZONE_DMA_FLAG=1 > CONFIG_BOUNCE=y > CONFIG_VIRT_TO_BUS=y > # CONFIG_HIGHPTE is not set > # CONFIG_MATH_EMULATION is not set > CONFIG_MTRR=y > # CONFIG_X86_PAT is not set > # CONFIG_EFI is not set > # CONFIG_IRQBALANCE is not set > CONFIG_SECCOMP=y > # CONFIG_HZ_100 is not set > CONFIG_HZ_250=y > # CONFIG_HZ_300 is not set > # CONFIG_HZ_1000 is not set > CONFIG_HZ=250 > # CONFIG_SCHED_HRTICK is not set > # CONFIG_KEXEC is not set > CONFIG_PHYSICAL_START=0x100000 > CONFIG_PHYSICAL_ALIGN=0x200000 > # CONFIG_COMPAT_VDSO is not set > CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y > > # > # Power management options > # > CONFIG_PM=y > # CONFIG_PM_DEBUG is not set > # CONFIG_SUSPEND is not set > # CONFIG_HIBERNATION is not set > CONFIG_ACPI=y > CONFIG_ACPI_PROCFS=y > CONFIG_ACPI_PROCFS_POWER=y > # CONFIG_ACPI_SYSFS_POWER is not set > # CONFIG_ACPI_PROC_EVENT is not set > CONFIG_ACPI_AC=m > CONFIG_ACPI_BATTERY=m > CONFIG_ACPI_BUTTON=m > CONFIG_ACPI_FAN=m > CONFIG_ACPI_DOCK=y > CONFIG_ACPI_PROCESSOR=m > CONFIG_ACPI_THERMAL=m > # CONFIG_ACPI_ASUS is not set > # CONFIG_ACPI_TOSHIBA is not set > # CONFIG_ACPI_CUSTOM_DSDT is not set > CONFIG_ACPI_BLACKLIST_YEAR=0 > # CONFIG_ACPI_DEBUG is not set > CONFIG_ACPI_EC=y > CONFIG_ACPI_POWER=y > CONFIG_ACPI_SYSTEM=y > CONFIG_X86_PM_TIMER=y > CONFIG_ACPI_SBS=m > > # > # CPU Frequency scaling > # > # CONFIG_CPU_FREQ is not set > # CONFIG_CPU_IDLE is not set > > # > # Bus options (PCI etc.) > # > CONFIG_PCI=y > # CONFIG_PCI_GOBIOS is not set > # CONFIG_PCI_GOMMCONFIG is not set > # CONFIG_PCI_GODIRECT is not set > # CONFIG_PCI_GOOLPC is not set > CONFIG_PCI_GOANY=y > CONFIG_PCI_BIOS=y > CONFIG_PCI_DIRECT=y > CONFIG_PCI_MMCONFIG=y > CONFIG_PCI_DOMAINS=y > # CONFIG_PCIEPORTBUS is not set > CONFIG_ARCH_SUPPORTS_MSI=y > # CONFIG_PCI_MSI is not set > # CONFIG_PCI_LEGACY is not set > # CONFIG_HT_IRQ is not set > CONFIG_ISA_DMA_API=y > # CONFIG_ISA is not set > # CONFIG_MCA is not set > # CONFIG_SCx200 is not set > # CONFIG_OLPC is not set > CONFIG_PCCARD=m > # CONFIG_PCMCIA_DEBUG is not set > CONFIG_PCMCIA=m > # CONFIG_PCMCIA_IOCTL is not set > CONFIG_CARDBUS=y > > # > # PC-card bridges > # > CONFIG_YENTA=m > CONFIG_YENTA_O2=y > CONFIG_YENTA_RICOH=y > CONFIG_YENTA_TI=y > CONFIG_YENTA_ENE_TUNE=y > CONFIG_YENTA_TOSHIBA=y > CONFIG_PD6729=m > CONFIG_I82092=m > CONFIG_PCCARD_NONSTATIC=m > # CONFIG_HOTPLUG_PCI is not set > > # > # Executable file formats / Emulations > # > CONFIG_BINFMT_ELF=y > # CONFIG_BINFMT_AOUT is not set > # CONFIG_BINFMT_MISC is not set > > # > # Networking > # > CONFIG_NET=y > > # > # Networking options > # > CONFIG_PACKET=y > CONFIG_PACKET_MMAP=y > CONFIG_UNIX=y > CONFIG_XFRM=y > CONFIG_XFRM_USER=y > CONFIG_NET_KEY=m > CONFIG_INET=y > # CONFIG_IP_MULTICAST is not set > CONFIG_IP_ADVANCED_ROUTER=y > CONFIG_ASK_IP_FIB_HASH=y > # CONFIG_IP_FIB_TRIE is not set > CONFIG_IP_FIB_HASH=y > CONFIG_IP_MULTIPLE_TABLES=y > CONFIG_IP_ROUTE_MULTIPATH=y > CONFIG_IP_ROUTE_VERBOSE=y > # CONFIG_IP_PNP is not set > CONFIG_NET_IPIP=m > CONFIG_NET_IPGRE=m > CONFIG_SYN_COOKIES=y > # CONFIG_INET_AH is not set > CONFIG_INET_ESP=m > CONFIG_INET_IPCOMP=m > CONFIG_INET_XFRM_TUNNEL=m > CONFIG_INET_TUNNEL=m > CONFIG_INET_XFRM_MODE_TRANSPORT=m > CONFIG_INET_XFRM_MODE_TUNNEL=m > # CONFIG_INET_XFRM_MODE_BEET is not set > # CONFIG_INET_LRO is not set > CONFIG_INET_DIAG=y > CONFIG_INET_TCP_DIAG=y > # CONFIG_TCP_CONG_ADVANCED is not set > CONFIG_TCP_CONG_CUBIC=y > CONFIG_DEFAULT_TCP_CONG="cubic" > # CONFIG_IP_VS is not set > # CONFIG_IPV6 is not set > # CONFIG_NETWORK_SECMARK is not set > CONFIG_NETFILTER=y > # CONFIG_NETFILTER_DEBUG is not set > CONFIG_NETFILTER_ADVANCED=y > > # > # Core Netfilter Configuration > # > CONFIG_NETFILTER_NETLINK=m > CONFIG_NETFILTER_NETLINK_QUEUE=m > CONFIG_NETFILTER_NETLINK_LOG=m > CONFIG_NF_CONNTRACK=m > CONFIG_NF_CT_ACCT=y > CONFIG_NF_CONNTRACK_MARK=y > CONFIG_NF_CONNTRACK_EVENTS=y > CONFIG_NF_CT_PROTO_GRE=m > CONFIG_NF_CT_PROTO_UDPLITE=m > CONFIG_NF_CONNTRACK_AMANDA=m > CONFIG_NF_CONNTRACK_FTP=m > CONFIG_NF_CONNTRACK_H323=m > CONFIG_NF_CONNTRACK_IRC=m > CONFIG_NF_CONNTRACK_NETBIOS_NS=m > CONFIG_NF_CONNTRACK_PPTP=m > CONFIG_NF_CONNTRACK_SIP=m > CONFIG_NF_CONNTRACK_TFTP=m > CONFIG_NF_CT_NETLINK=m > CONFIG_NETFILTER_XTABLES=m > CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m > CONFIG_NETFILTER_XT_TARGET_CONNMARK=m > CONFIG_NETFILTER_XT_TARGET_DSCP=m > CONFIG_NETFILTER_XT_TARGET_MARK=m > CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m > CONFIG_NETFILTER_XT_TARGET_NFLOG=m > CONFIG_NETFILTER_XT_TARGET_NOTRACK=m > CONFIG_NETFILTER_XT_TARGET_RATEEST=m > CONFIG_NETFILTER_XT_TARGET_TRACE=m > CONFIG_NETFILTER_XT_TARGET_TCPMSS=m > CONFIG_NETFILTER_XT_MATCH_COMMENT=m > CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m > CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m > CONFIG_NETFILTER_XT_MATCH_CONNMARK=m > CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m > CONFIG_NETFILTER_XT_MATCH_DCCP=m > CONFIG_NETFILTER_XT_MATCH_DSCP=m > CONFIG_NETFILTER_XT_MATCH_ESP=m > CONFIG_NETFILTER_XT_MATCH_HELPER=m > CONFIG_NETFILTER_XT_MATCH_IPRANGE=m > CONFIG_NETFILTER_XT_MATCH_LENGTH=m > CONFIG_NETFILTER_XT_MATCH_LIMIT=m > CONFIG_NETFILTER_XT_MATCH_MAC=m > CONFIG_NETFILTER_XT_MATCH_MARK=m > CONFIG_NETFILTER_XT_MATCH_OWNER=m > CONFIG_NETFILTER_XT_MATCH_POLICY=m > CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m > CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m > CONFIG_NETFILTER_XT_MATCH_QUOTA=m > CONFIG_NETFILTER_XT_MATCH_RATEEST=m > CONFIG_NETFILTER_XT_MATCH_REALM=m > CONFIG_NETFILTER_XT_MATCH_STATE=m > CONFIG_NETFILTER_XT_MATCH_STATISTIC=m > CONFIG_NETFILTER_XT_MATCH_STRING=m > CONFIG_NETFILTER_XT_MATCH_TCPMSS=m > CONFIG_NETFILTER_XT_MATCH_TIME=m > CONFIG_NETFILTER_XT_MATCH_U32=m > CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m > > # > # IP: Netfilter Configuration > # > CONFIG_NF_CONNTRACK_IPV4=m > # CONFIG_NF_CONNTRACK_PROC_COMPAT is not set > # CONFIG_IP_NF_QUEUE is not set > CONFIG_IP_NF_IPTABLES=m > CONFIG_IP_NF_MATCH_RECENT=m > CONFIG_IP_NF_MATCH_ECN=m > CONFIG_IP_NF_MATCH_AH=m > CONFIG_IP_NF_MATCH_TTL=m > CONFIG_IP_NF_MATCH_ADDRTYPE=m > CONFIG_IP_NF_FILTER=m > CONFIG_IP_NF_TARGET_REJECT=m > CONFIG_IP_NF_TARGET_LOG=m > CONFIG_IP_NF_TARGET_ULOG=m > CONFIG_NF_NAT=m > CONFIG_NF_NAT_NEEDED=y > CONFIG_IP_NF_TARGET_MASQUERADE=m > CONFIG_IP_NF_TARGET_REDIRECT=m > CONFIG_IP_NF_TARGET_NETMAP=m > CONFIG_NF_NAT_SNMP_BASIC=m > CONFIG_NF_NAT_PROTO_GRE=m > CONFIG_NF_NAT_PROTO_UDPLITE=m > CONFIG_NF_NAT_FTP=m > CONFIG_NF_NAT_IRC=m > CONFIG_NF_NAT_TFTP=m > CONFIG_NF_NAT_AMANDA=m > CONFIG_NF_NAT_PPTP=m > CONFIG_NF_NAT_H323=m > CONFIG_NF_NAT_SIP=m > CONFIG_IP_NF_MANGLE=m > CONFIG_IP_NF_TARGET_ECN=m > CONFIG_IP_NF_TARGET_TTL=m > CONFIG_IP_NF_RAW=m > CONFIG_IP_NF_ARPTABLES=m > CONFIG_IP_NF_ARPFILTER=m > CONFIG_IP_NF_ARP_MANGLE=m > # CONFIG_ATM is not set > # CONFIG_BRIDGE is not set > # CONFIG_VLAN_8021Q is not set > # CONFIG_DECNET is not set > # CONFIG_LLC2 is not set > # CONFIG_IPX is not set > # CONFIG_ATALK is not set > CONFIG_NET_SCHED=y > > # > # Queueing/Scheduling > # > # CONFIG_NET_SCH_CBQ is not set > CONFIG_NET_SCH_HTB=m > CONFIG_NET_SCH_HFSC=m > CONFIG_NET_SCH_PRIO=m > CONFIG_NET_SCH_RR=m > CONFIG_NET_SCH_RED=m > CONFIG_NET_SCH_SFQ=m > CONFIG_NET_SCH_TEQL=m > CONFIG_NET_SCH_TBF=m > CONFIG_NET_SCH_GRED=m > CONFIG_NET_SCH_DSMARK=m > CONFIG_NET_SCH_NETEM=m > CONFIG_NET_SCH_INGRESS=m > > # > # Classification > # > CONFIG_NET_CLS=y > CONFIG_NET_CLS_BASIC=m > CONFIG_NET_CLS_TCINDEX=m > CONFIG_NET_CLS_ROUTE4=m > CONFIG_NET_CLS_ROUTE=y > CONFIG_NET_CLS_FW=m > CONFIG_NET_CLS_U32=m > CONFIG_CLS_U32_PERF=y > CONFIG_CLS_U32_MARK=y > CONFIG_NET_CLS_RSVP=m > # CONFIG_NET_CLS_RSVP6 is not set > CONFIG_NET_CLS_FLOW=m > CONFIG_NET_EMATCH=y > CONFIG_NET_EMATCH_STACK=32 > CONFIG_NET_EMATCH_CMP=m > CONFIG_NET_EMATCH_NBYTE=m > CONFIG_NET_EMATCH_U32=m > CONFIG_NET_EMATCH_META=m > CONFIG_NET_EMATCH_TEXT=m > CONFIG_NET_CLS_ACT=y > CONFIG_NET_ACT_POLICE=m > CONFIG_NET_ACT_GACT=m > CONFIG_GACT_PROB=y > CONFIG_NET_ACT_MIRRED=m > CONFIG_NET_ACT_IPT=m > CONFIG_NET_ACT_NAT=m > CONFIG_NET_ACT_PEDIT=m > # CONFIG_NET_ACT_SIMP is not set > # CONFIG_NET_CLS_IND is not set > CONFIG_NET_SCH_FIFO=y > > # > # Network testing > # > CONFIG_NET_PKTGEN=m > # CONFIG_HAMRADIO is not set > # CONFIG_CAN is not set > # CONFIG_IRDA is not set > # CONFIG_BT is not set > CONFIG_FIB_RULES=y > > # > # Wireless > # > # CONFIG_CFG80211 is not set > # CONFIG_WIRELESS_EXT is not set > # CONFIG_MAC80211 is not set > # CONFIG_IEEE80211 is not set > # CONFIG_RFKILL is not set > > # > # Device Drivers > # > > # > # Generic Driver Options > # > CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" > CONFIG_STANDALONE=y > # CONFIG_PREVENT_FIRMWARE_BUILD is not set > # CONFIG_FW_LOADER is not set > # CONFIG_SYS_HYPERVISOR is not set > # CONFIG_CONNECTOR is not set > # CONFIG_MTD is not set > # CONFIG_PARPORT is not set > CONFIG_PNP=y > # CONFIG_PNP_DEBUG is not set > > # > # Protocols > # > CONFIG_PNPACPI=y > CONFIG_BLK_DEV=y > # CONFIG_BLK_DEV_FD is not set > # CONFIG_BLK_CPQ_DA is not set > # CONFIG_BLK_CPQ_CISS_DA is not set > # CONFIG_BLK_DEV_DAC960 is not set > # CONFIG_BLK_DEV_COW_COMMON is not set > CONFIG_BLK_DEV_LOOP=m > # CONFIG_BLK_DEV_CRYPTOLOOP is not set > # CONFIG_BLK_DEV_NBD is not set > # CONFIG_BLK_DEV_SX8 is not set > # CONFIG_BLK_DEV_UB is not set > # CONFIG_BLK_DEV_RAM is not set > # CONFIG_CDROM_PKTCDVD is not set > # CONFIG_ATA_OVER_ETH is not set > # CONFIG_MISC_DEVICES is not set > CONFIG_HAVE_IDE=y > CONFIG_IDE=m > # CONFIG_BLK_DEV_IDE is not set > # CONFIG_BLK_DEV_HD_ONLY is not set > # CONFIG_BLK_DEV_HD is not set > > # > # SCSI device support > # > # CONFIG_RAID_ATTRS is not set > CONFIG_SCSI=y > CONFIG_SCSI_DMA=y > # CONFIG_SCSI_NETLINK is not set > # CONFIG_SCSI_PROC_FS is not set > > # > # SCSI support type (disk, tape, CD-ROM) > # > CONFIG_BLK_DEV_SD=y > # CONFIG_CHR_DEV_ST is not set > # CONFIG_CHR_DEV_OSST is not set > CONFIG_BLK_DEV_SR=m > # CONFIG_BLK_DEV_SR_VENDOR is not set > # CONFIG_CHR_DEV_SG is not set > # CONFIG_CHR_DEV_SCH is not set > > # > # Some SCSI devices (e.g. CD jukebox) support multiple LUNs > # > # CONFIG_SCSI_MULTI_LUN is not set > # CONFIG_SCSI_CONSTANTS is not set > # CONFIG_SCSI_LOGGING is not set > # CONFIG_SCSI_SCAN_ASYNC is not set > CONFIG_SCSI_WAIT_SCAN=m > > # > # SCSI Transports > # > # CONFIG_SCSI_SPI_ATTRS is not set > # CONFIG_SCSI_FC_ATTRS is not set > # CONFIG_SCSI_ISCSI_ATTRS is not set > # CONFIG_SCSI_SAS_LIBSAS is not set > # CONFIG_SCSI_SRP_ATTRS is not set > # CONFIG_SCSI_LOWLEVEL is not set > # CONFIG_SCSI_LOWLEVEL_PCMCIA is not set > CONFIG_ATA=y > # CONFIG_ATA_NONSTANDARD is not set > CONFIG_ATA_ACPI=y > # CONFIG_SATA_PMP is not set > CONFIG_SATA_AHCI=y > # CONFIG_SATA_SIL24 is not set > CONFIG_ATA_SFF=y > # CONFIG_SATA_SVW is not set > CONFIG_ATA_PIIX=y > # CONFIG_SATA_NV is not set > # CONFIG_PDC_ADMA is not set > # CONFIG_SATA_QSTOR is not set > # CONFIG_SATA_PROMISE is not set > # CONFIG_SATA_SIL is not set > # CONFIG_SATA_SIS is not set > # CONFIG_SATA_ULI is not set > # CONFIG_SATA_VIA is not set > # CONFIG_SATA_VITESSE is not set > # CONFIG_SATA_INIC162X is not set > # CONFIG_PATA_ACPI is not set > # CONFIG_PATA_AMD is not set > # CONFIG_PATA_ARTOP is not set > # CONFIG_PATA_ATIIXP is not set > # CONFIG_PATA_CMD64X is not set > # CONFIG_PATA_CS5520 is not set > # CONFIG_PATA_EFAR is not set > # CONFIG_ATA_GENERIC is not set > # CONFIG_PATA_HPT366 is not set > # CONFIG_PATA_HPT3X3 is not set > # CONFIG_PATA_IT821X is not set > # CONFIG_PATA_JMICRON is not set > # CONFIG_PATA_TRIFLEX is not set > # CONFIG_PATA_MARVELL is not set > # CONFIG_PATA_MPIIX is not set > # CONFIG_PATA_OLDPIIX is not set > # CONFIG_PATA_NETCELL is not set > # CONFIG_PATA_PCMCIA is not set > # CONFIG_PATA_RZ1000 is not set > # CONFIG_PATA_SERVERWORKS is not set > # CONFIG_PATA_PDC2027X is not set > # CONFIG_PATA_SIL680 is not set > # CONFIG_PATA_VIA is not set > # CONFIG_PATA_WINBOND is not set > # CONFIG_PATA_SCH is not set > # CONFIG_MD is not set > # CONFIG_FUSION is not set > > # > # IEEE 1394 (FireWire) support > # > > # > # An alternative FireWire stack is available with EXPERIMENTAL=y > # > # CONFIG_IEEE1394 is not set > # CONFIG_I2O is not set > # CONFIG_MACINTOSH_DRIVERS is not set > CONFIG_NETDEVICES=y > # CONFIG_NETDEVICES_MULTIQUEUE is not set > CONFIG_IFB=m > CONFIG_DUMMY=m > # CONFIG_BONDING is not set > # CONFIG_EQUALIZER is not set > CONFIG_TUN=m > # CONFIG_VETH is not set > # CONFIG_NET_SB1000 is not set > # CONFIG_ARCNET is not set > # CONFIG_NET_ETHERNET is not set > CONFIG_NETDEV_1000=y > # CONFIG_ACENIC is not set > # CONFIG_DL2K is not set > # CONFIG_E1000 is not set > # CONFIG_E1000E is not set > # CONFIG_E1000E_ENABLED is not set > # CONFIG_IGB is not set > # CONFIG_NS83820 is not set > # CONFIG_HAMACHI is not set > # CONFIG_R8169 is not set > # CONFIG_SIS190 is not set > # CONFIG_SKGE is not set > # CONFIG_SKY2 is not set > # CONFIG_VIA_VELOCITY is not set > CONFIG_TIGON3=m > CONFIG_BNX2=m > # CONFIG_QLA3XXX is not set > # CONFIG_NETDEV_10000 is not set > # CONFIG_TR is not set > > # > # Wireless LAN > # > # CONFIG_WLAN_PRE80211 is not set > # CONFIG_WLAN_80211 is not set > # CONFIG_IWLWIFI_LEDS is not set > > # > # USB Network Adapters > # > # CONFIG_USB_KAWETH is not set > # CONFIG_USB_PEGASUS is not set > # CONFIG_USB_USBNET is not set > # CONFIG_NET_PCMCIA is not set > # CONFIG_WAN is not set > # CONFIG_FDDI is not set > CONFIG_PPP=m > CONFIG_PPP_FILTER=y > CONFIG_PPP_ASYNC=m > CONFIG_PPP_SYNC_TTY=m > CONFIG_PPP_DEFLATE=m > CONFIG_PPP_BSDCOMP=m > # CONFIG_SLIP is not set > CONFIG_SLHC=m > # CONFIG_NET_FC is not set > # CONFIG_NETPOLL is not set > # CONFIG_NET_POLL_CONTROLLER is not set > # CONFIG_ISDN is not set > # CONFIG_PHONE is not set > > # > # Input device support > # > CONFIG_INPUT=y > # CONFIG_INPUT_FF_MEMLESS is not set > # CONFIG_INPUT_POLLDEV is not set > > # > # Userland interfaces > # > CONFIG_INPUT_MOUSEDEV=y > # CONFIG_INPUT_MOUSEDEV_PSAUX is not set > CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 > CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 > # CONFIG_INPUT_JOYDEV is not set > # CONFIG_INPUT_EVDEV is not set > # CONFIG_INPUT_EVBUG is not set > > # > # Input Device Drivers > # > CONFIG_INPUT_KEYBOARD=y > CONFIG_KEYBOARD_ATKBD=y > # CONFIG_KEYBOARD_SUNKBD is not set > # CONFIG_KEYBOARD_LKKBD is not set > # CONFIG_KEYBOARD_XTKBD is not set > # CONFIG_KEYBOARD_NEWTON is not set > # CONFIG_KEYBOARD_STOWAWAY is not set > CONFIG_INPUT_MOUSE=y > CONFIG_MOUSE_PS2=m > CONFIG_MOUSE_PS2_ALPS=y > CONFIG_MOUSE_PS2_LOGIPS2PP=y > CONFIG_MOUSE_PS2_SYNAPTICS=y > CONFIG_MOUSE_PS2_LIFEBOOK=y > CONFIG_MOUSE_PS2_TRACKPOINT=y > # CONFIG_MOUSE_PS2_TOUCHKIT is not set > # CONFIG_MOUSE_SERIAL is not set > # CONFIG_MOUSE_APPLETOUCH is not set > # CONFIG_MOUSE_VSXXXAA is not set > # CONFIG_INPUT_JOYSTICK is not set > # CONFIG_INPUT_TABLET is not set > # CONFIG_INPUT_TOUCHSCREEN is not set > CONFIG_INPUT_MISC=y > CONFIG_INPUT_PCSPKR=m > # CONFIG_INPUT_WISTRON_BTNS is not set > # CONFIG_INPUT_ATLAS_BTNS is not set > # CONFIG_INPUT_ATI_REMOTE is not set > # CONFIG_INPUT_ATI_REMOTE2 is not set > # CONFIG_INPUT_POWERMATE is not set > # CONFIG_INPUT_UINPUT is not set > > # > # Hardware I/O ports > # > CONFIG_SERIO=y > CONFIG_SERIO_I8042=y > # CONFIG_SERIO_SERPORT is not set > # CONFIG_SERIO_CT82C710 is not set > # CONFIG_SERIO_PCIPS2 is not set > CONFIG_SERIO_LIBPS2=y > # CONFIG_SERIO_RAW is not set > # CONFIG_GAMEPORT is not set > > # > # Character devices > # > CONFIG_VT=y > CONFIG_VT_CONSOLE=y > CONFIG_HW_CONSOLE=y > # CONFIG_VT_HW_CONSOLE_BINDING is not set > # CONFIG_DEVKMEM is not set > # CONFIG_SERIAL_NONSTANDARD is not set > > # > # Serial drivers > # > # CONFIG_SERIAL_8250 is not set > CONFIG_FIX_EARLYCON_MEM=y > > # > # Non-8250 serial port support > # > # CONFIG_SERIAL_JSM is not set > CONFIG_UNIX98_PTYS=y > # CONFIG_LEGACY_PTYS is not set > # CONFIG_IPMI_HANDLER is not set > # CONFIG_HW_RANDOM is not set > # CONFIG_NVRAM is not set > # CONFIG_RTC is not set > # CONFIG_GEN_RTC is not set > # CONFIG_R3964 is not set > # CONFIG_APPLICOM is not set > > # > # PCMCIA character devices > # > # CONFIG_SYNCLINK_CS is not set > # CONFIG_CARDMAN_4000 is not set > # CONFIG_CARDMAN_4040 is not set > # CONFIG_IPWIRELESS is not set > # CONFIG_MWAVE is not set > # CONFIG_PC8736x_GPIO is not set > # CONFIG_NSC_GPIO is not set > # CONFIG_CS5535_GPIO is not set > # CONFIG_RAW_DRIVER is not set > # CONFIG_HPET is not set > # CONFIG_HANGCHECK_TIMER is not set > CONFIG_DEVPORT=y > # CONFIG_I2C is not set > # CONFIG_SPI is not set > # CONFIG_W1 is not set > # CONFIG_POWER_SUPPLY is not set > # CONFIG_HWMON is not set > CONFIG_THERMAL=m > # CONFIG_WATCHDOG is not set > > # > # Sonics Silicon Backplane > # > CONFIG_SSB_POSSIBLE=y > # CONFIG_SSB is not set > > # > # Multifunction device drivers > # > # CONFIG_MFD_SM501 is not set > # CONFIG_HTC_PASIC3 is not set > > # > # Multimedia devices > # > > # > # Multimedia core support > # > # CONFIG_VIDEO_DEV is not set > # CONFIG_DVB_CORE is not set > # CONFIG_VIDEO_MEDIA is not set > > # > # Multimedia drivers > # > # CONFIG_DAB is not set > > # > # Graphics support > # > CONFIG_AGP=y > # CONFIG_AGP_ALI is not set > # CONFIG_AGP_ATI is not set > # CONFIG_AGP_AMD is not set > # CONFIG_AGP_AMD64 is not set > CONFIG_AGP_INTEL=m > # CONFIG_AGP_NVIDIA is not set > # CONFIG_AGP_SIS is not set > # CONFIG_AGP_SWORKS is not set > # CONFIG_AGP_VIA is not set > # CONFIG_AGP_EFFICEON is not set > CONFIG_DRM=m > # CONFIG_DRM_TDFX is not set > # CONFIG_DRM_R128 is not set > # CONFIG_DRM_RADEON is not set > CONFIG_DRM_I810=m > CONFIG_DRM_I830=m > CONFIG_DRM_I915=m > # CONFIG_DRM_MGA is not set > # CONFIG_DRM_SIS is not set > # CONFIG_DRM_VIA is not set > # CONFIG_DRM_SAVAGE is not set > # CONFIG_VGASTATE is not set > # CONFIG_VIDEO_OUTPUT_CONTROL is not set > # CONFIG_FB is not set > # CONFIG_BACKLIGHT_LCD_SUPPORT is not set > > # > # Display device support > # > # CONFIG_DISPLAY_SUPPORT is not set > > # > # Console display driver support > # > CONFIG_VGA_CONSOLE=y > # CONFIG_VGACON_SOFT_SCROLLBACK is not set > # CONFIG_VIDEO_SELECT is not set > CONFIG_DUMMY_CONSOLE=y > > # > # Sound > # > CONFIG_SOUND=m > > # > # Advanced Linux Sound Architecture > # > CONFIG_SND=m > CONFIG_SND_TIMER=m > CONFIG_SND_PCM=m > CONFIG_SND_RAWMIDI=m > CONFIG_SND_SEQUENCER=m > CONFIG_SND_SEQ_DUMMY=m > CONFIG_SND_OSSEMUL=y > CONFIG_SND_MIXER_OSS=m > CONFIG_SND_PCM_OSS=m > CONFIG_SND_PCM_OSS_PLUGINS=y > CONFIG_SND_SEQUENCER_OSS=y > # CONFIG_SND_DYNAMIC_MINORS is not set > # CONFIG_SND_SUPPORT_OLD_API is not set > CONFIG_SND_VERBOSE_PROCFS=y > # CONFIG_SND_VERBOSE_PRINTK is not set > # CONFIG_SND_DEBUG is not set > CONFIG_SND_VMASTER=y > > # > # Generic devices > # > CONFIG_SND_MPU401_UART=m > CONFIG_SND_DUMMY=m > CONFIG_SND_VIRMIDI=m > CONFIG_SND_MTPAV=m > CONFIG_SND_SERIAL_U16550=m > CONFIG_SND_MPU401=m > > # > # PCI devices > # > # CONFIG_SND_AD1889 is not set > # CONFIG_SND_ALS300 is not set > # CONFIG_SND_ALS4000 is not set > # CONFIG_SND_ALI5451 is not set > # CONFIG_SND_ATIIXP is not set > # CONFIG_SND_ATIIXP_MODEM is not set > # CONFIG_SND_AU8810 is not set > # CONFIG_SND_AU8820 is not set > # CONFIG_SND_AU8830 is not set > # CONFIG_SND_AW2 is not set > # CONFIG_SND_BT87X is not set > # CONFIG_SND_CA0106 is not set > # CONFIG_SND_CMIPCI is not set > # CONFIG_SND_OXYGEN is not set > # CONFIG_SND_CS4281 is not set > # CONFIG_SND_CS46XX is not set > # CONFIG_SND_CS5530 is not set > # CONFIG_SND_CS5535AUDIO is not set > # CONFIG_SND_DARLA20 is not set > # CONFIG_SND_GINA20 is not set > # CONFIG_SND_LAYLA20 is not set > # CONFIG_SND_DARLA24 is not set > # CONFIG_SND_GINA24 is not set > # CONFIG_SND_LAYLA24 is not set > # CONFIG_SND_MONA is not set > # CONFIG_SND_MIA is not set > # CONFIG_SND_ECHO3G is not set > # CONFIG_SND_INDIGO is not set > # CONFIG_SND_INDIGOIO is not set > # CONFIG_SND_INDIGODJ is not set > # CONFIG_SND_EMU10K1 is not set > # CONFIG_SND_EMU10K1X is not set > # CONFIG_SND_ENS1370 is not set > # CONFIG_SND_ENS1371 is not set > # CONFIG_SND_ES1938 is not set > # CONFIG_SND_ES1968 is not set > # CONFIG_SND_FM801 is not set > CONFIG_SND_HDA_INTEL=m > # CONFIG_SND_HDA_HWDEP is not set > # CONFIG_SND_HDA_CODEC_REALTEK is not set > CONFIG_SND_HDA_CODEC_ANALOG=y > # CONFIG_SND_HDA_CODEC_SIGMATEL is not set > # CONFIG_SND_HDA_CODEC_VIA is not set > # CONFIG_SND_HDA_CODEC_ATIHDMI is not set > # CONFIG_SND_HDA_CODEC_CONEXANT is not set > # CONFIG_SND_HDA_CODEC_CMEDIA is not set > # CONFIG_SND_HDA_CODEC_SI3054 is not set > CONFIG_SND_HDA_GENERIC=y > # CONFIG_SND_HDSP is not set > # CONFIG_SND_HDSPM is not set > # CONFIG_SND_HIFIER is not set > # CONFIG_SND_ICE1712 is not set > # CONFIG_SND_ICE1724 is not set > # CONFIG_SND_INTEL8X0 is not set > # CONFIG_SND_INTEL8X0M is not set > # CONFIG_SND_KORG1212 is not set > # CONFIG_SND_MAESTRO3 is not set > # CONFIG_SND_MIXART is not set > # CONFIG_SND_NM256 is not set > # CONFIG_SND_PCXHR is not set > # CONFIG_SND_RIPTIDE is not set > # CONFIG_SND_RME32 is not set > # CONFIG_SND_RME96 is not set > # CONFIG_SND_RME9652 is not set > # CONFIG_SND_SIS7019 is not set > # CONFIG_SND_SONICVIBES is not set > # CONFIG_SND_TRIDENT is not set > # CONFIG_SND_VIA82XX is not set > # CONFIG_SND_VIA82XX_MODEM is not set > # CONFIG_SND_VIRTUOSO is not set > # CONFIG_SND_VX222 is not set > # CONFIG_SND_YMFPCI is not set > > # > # USB devices > # > # CONFIG_SND_USB_AUDIO is not set > # CONFIG_SND_USB_USX2Y is not set > # CONFIG_SND_USB_CAIAQ is not set > > # > # PCMCIA devices > # > # CONFIG_SND_VXPOCKET is not set > # CONFIG_SND_PDAUDIOCF is not set > > # > # System on Chip audio support > # > # CONFIG_SND_SOC is not set > > # > # ALSA SoC audio for Freescale SOCs > # > > # > # SoC Audio for the Texas Instruments OMAP > # > > # > # Open Sound System > # > # CONFIG_SOUND_PRIME is not set > CONFIG_HID_SUPPORT=y > CONFIG_HID=m > # CONFIG_HID_DEBUG is not set > # CONFIG_HIDRAW is not set > > # > # USB Input Devices > # > CONFIG_USB_HID=m > # CONFIG_USB_HIDINPUT_POWERBOOK is not set > # CONFIG_USB_HIDDEV is not set > > # > # USB HID Boot Protocol drivers > # > # CONFIG_USB_KBD is not set > # CONFIG_USB_MOUSE is not set > CONFIG_USB_SUPPORT=y > CONFIG_USB_ARCH_HAS_HCD=y > CONFIG_USB_ARCH_HAS_OHCI=y > CONFIG_USB_ARCH_HAS_EHCI=y > CONFIG_USB=m > # CONFIG_USB_DEBUG is not set > # CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set > > # > # Miscellaneous USB options > # > CONFIG_USB_DEVICEFS=y > # CONFIG_USB_DEVICE_CLASS is not set > # CONFIG_USB_DYNAMIC_MINORS is not set > # CONFIG_USB_SUSPEND is not set > > # > # USB Host Controller Drivers > # > # CONFIG_USB_C67X00_HCD is not set > CONFIG_USB_EHCI_HCD=m > # CONFIG_USB_EHCI_ROOT_HUB_TT is not set > # CONFIG_USB_ISP116X_HCD is not set > CONFIG_USB_OHCI_HCD=m > # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set > # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set > CONFIG_USB_OHCI_LITTLE_ENDIAN=y > CONFIG_USB_UHCI_HCD=m > # CONFIG_USB_SL811_HCD is not set > # CONFIG_USB_R8A66597_HCD is not set > > # > # USB Device Class drivers > # > CONFIG_USB_ACM=m > # CONFIG_USB_PRINTER is not set > # CONFIG_USB_WDM is not set > > # > # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' > # > > # > # may also be needed; see USB_STORAGE Help for more information > # > CONFIG_USB_STORAGE=m > # CONFIG_USB_STORAGE_DEBUG is not set > # CONFIG_USB_STORAGE_DATAFAB is not set > # CONFIG_USB_STORAGE_FREECOM is not set > # CONFIG_USB_STORAGE_ISD200 is not set > # CONFIG_USB_STORAGE_DPCM is not set > # CONFIG_USB_STORAGE_USBAT is not set > # CONFIG_USB_STORAGE_SDDR09 is not set > # CONFIG_USB_STORAGE_SDDR55 is not set > # CONFIG_USB_STORAGE_JUMPSHOT is not set > # CONFIG_USB_STORAGE_ALAUDA is not set > # CONFIG_USB_STORAGE_ONETOUCH is not set > # CONFIG_USB_STORAGE_KARMA is not set > # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set > # CONFIG_USB_LIBUSUAL is not set > > # > # USB Imaging devices > # > # CONFIG_USB_MDC800 is not set > # CONFIG_USB_MICROTEK is not set > # CONFIG_USB_MON is not set > > # > # USB port drivers > # > CONFIG_USB_SERIAL=m > # CONFIG_USB_EZUSB is not set > # CONFIG_USB_SERIAL_GENERIC is not set > # CONFIG_USB_SERIAL_AIRCABLE is not set > CONFIG_USB_SERIAL_AIRPRIME=m > # CONFIG_USB_SERIAL_ARK3116 is not set > # CONFIG_USB_SERIAL_BELKIN is not set > # CONFIG_USB_SERIAL_CH341 is not set > # CONFIG_USB_SERIAL_WHITEHEAT is not set > # CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set > # CONFIG_USB_SERIAL_CP2101 is not set > # CONFIG_USB_SERIAL_CYPRESS_M8 is not set > # CONFIG_USB_SERIAL_EMPEG is not set > # CONFIG_USB_SERIAL_FTDI_SIO is not set > # CONFIG_USB_SERIAL_FUNSOFT is not set > # CONFIG_USB_SERIAL_VISOR is not set > # CONFIG_USB_SERIAL_IPAQ is not set > # CONFIG_USB_SERIAL_IR is not set > # CONFIG_USB_SERIAL_EDGEPORT is not set > # CONFIG_USB_SERIAL_EDGEPORT_TI is not set > # CONFIG_USB_SERIAL_GARMIN is not set > # CONFIG_USB_SERIAL_IPW is not set > # CONFIG_USB_SERIAL_IUU is not set > # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set > # CONFIG_USB_SERIAL_KEYSPAN is not set > # CONFIG_USB_SERIAL_KLSI is not set > # CONFIG_USB_SERIAL_KOBIL_SCT is not set > # CONFIG_USB_SERIAL_MCT_U232 is not set > # CONFIG_USB_SERIAL_MOS7720 is not set > # CONFIG_USB_SERIAL_MOS7840 is not set > # CONFIG_USB_SERIAL_MOTOROLA is not set > # CONFIG_USB_SERIAL_NAVMAN is not set > # CONFIG_USB_SERIAL_PL2303 is not set > # CONFIG_USB_SERIAL_OTI6858 is not set > # CONFIG_USB_SERIAL_SPCP8X5 is not set > # CONFIG_USB_SERIAL_HP4X is not set > # CONFIG_USB_SERIAL_SAFE is not set > CONFIG_USB_SERIAL_SIERRAWIRELESS=m > # CONFIG_USB_SERIAL_TI is not set > # CONFIG_USB_SERIAL_CYBERJACK is not set > # CONFIG_USB_SERIAL_XIRCOM is not set > CONFIG_USB_SERIAL_OPTION=m > # CONFIG_USB_SERIAL_OMNINET is not set > # CONFIG_USB_SERIAL_DEBUG is not set > > # > # USB Miscellaneous drivers > # > # CONFIG_USB_EMI62 is not set > # CONFIG_USB_EMI26 is not set > # CONFIG_USB_ADUTUX is not set > # CONFIG_USB_AUERSWALD is not set > # CONFIG_USB_RIO500 is not set > # CONFIG_USB_LEGOTOWER is not set > # CONFIG_USB_LCD is not set > # CONFIG_USB_BERRY_CHARGE is not set > # CONFIG_USB_LED is not set > # CONFIG_USB_CYPRESS_CY7C63 is not set > # CONFIG_USB_CYTHERM is not set > # CONFIG_USB_PHIDGET is not set > # CONFIG_USB_IDMOUSE is not set > # CONFIG_USB_FTDI_ELAN is not set > # CONFIG_USB_APPLEDISPLAY is not set > # CONFIG_USB_SISUSBVGA is not set > # CONFIG_USB_LD is not set > # CONFIG_USB_TRANCEVIBRATOR is not set > # CONFIG_USB_IOWARRIOR is not set > # CONFIG_USB_TEST is not set > # CONFIG_USB_ISIGHTFW is not set > # CONFIG_USB_GADGET is not set > # CONFIG_MMC is not set > # CONFIG_MEMSTICK is not set > # CONFIG_NEW_LEDS is not set > # CONFIG_ACCESSIBILITY is not set > # CONFIG_INFINIBAND is not set > # CONFIG_RTC_CLASS is not set > # CONFIG_DMADEVICES is not set > # CONFIG_UIO is not set > > # > # Firmware Drivers > # > # CONFIG_EDD is not set > # CONFIG_DELL_RBU is not set > # CONFIG_DCDBAS is not set > # CONFIG_DMIID is not set > # CONFIG_ISCSI_IBFT_FIND is not set > > # > # File systems > # > CONFIG_EXT2_FS=m > # CONFIG_EXT2_FS_XATTR is not set > # CONFIG_EXT2_FS_XIP is not set > # CONFIG_EXT3_FS is not set > # CONFIG_REISERFS_FS is not set > # CONFIG_JFS_FS is not set > CONFIG_FS_POSIX_ACL=y > CONFIG_XFS_FS=y > # CONFIG_XFS_QUOTA is not set > # CONFIG_XFS_POSIX_ACL is not set > # CONFIG_XFS_RT is not set > # CONFIG_OCFS2_FS is not set > # CONFIG_DNOTIFY is not set > CONFIG_INOTIFY=y > CONFIG_INOTIFY_USER=y > # CONFIG_QUOTA is not set > # CONFIG_AUTOFS_FS is not set > # CONFIG_AUTOFS4_FS is not set > CONFIG_FUSE_FS=m > > # > # CD-ROM/DVD Filesystems > # > CONFIG_ISO9660_FS=m > CONFIG_JOLIET=y > # CONFIG_ZISOFS is not set > CONFIG_UDF_FS=m > CONFIG_UDF_NLS=y > > # > # DOS/FAT/NT Filesystems > # > CONFIG_FAT_FS=m > # CONFIG_MSDOS_FS is not set > CONFIG_VFAT_FS=m > CONFIG_FAT_DEFAULT_CODEPAGE=437 > CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" > CONFIG_NTFS_FS=m > # CONFIG_NTFS_DEBUG is not set > CONFIG_NTFS_RW=y > > # > # Pseudo filesystems > # > CONFIG_PROC_FS=y > # CONFIG_PROC_KCORE is not set > CONFIG_PROC_SYSCTL=y > CONFIG_SYSFS=y > # CONFIG_TMPFS is not set > # CONFIG_HUGETLBFS is not set > # CONFIG_HUGETLB_PAGE is not set > # CONFIG_CONFIGFS_FS is not set > > # > # Miscellaneous filesystems > # > # CONFIG_HFSPLUS_FS is not set > # CONFIG_CRAMFS is not set > # CONFIG_VXFS_FS is not set > # CONFIG_MINIX_FS is not set > # CONFIG_HPFS_FS is not set > # CONFIG_QNX4FS_FS is not set > # CONFIG_ROMFS_FS is not set > # CONFIG_SYSV_FS is not set > # CONFIG_UFS_FS is not set > CONFIG_NETWORK_FILESYSTEMS=y > CONFIG_NFS_FS=m > CONFIG_NFS_V3=y > CONFIG_NFS_V3_ACL=y > CONFIG_NFSD=m > CONFIG_NFSD_V2_ACL=y > CONFIG_NFSD_V3=y > CONFIG_NFSD_V3_ACL=y > CONFIG_LOCKD=m > CONFIG_LOCKD_V4=y > CONFIG_EXPORTFS=m > CONFIG_NFS_ACL_SUPPORT=m > CONFIG_NFS_COMMON=y > CONFIG_SUNRPC=m > # CONFIG_SMB_FS is not set > CONFIG_CIFS=m > CONFIG_CIFS_STATS=y > CONFIG_CIFS_STATS2=y > CONFIG_CIFS_WEAK_PW_HASH=y > CONFIG_CIFS_XATTR=y > CONFIG_CIFS_POSIX=y > # CONFIG_CIFS_DEBUG2 is not set > # CONFIG_NCP_FS is not set > # CONFIG_CODA_FS is not set > > # > # Partition Types > # > # CONFIG_PARTITION_ADVANCED is not set > CONFIG_MSDOS_PARTITION=y > CONFIG_NLS=m > CONFIG_NLS_DEFAULT="iso8859-1" > CONFIG_NLS_CODEPAGE_437=m > # CONFIG_NLS_CODEPAGE_737 is not set > # CONFIG_NLS_CODEPAGE_775 is not set > # CONFIG_NLS_CODEPAGE_850 is not set > # CONFIG_NLS_CODEPAGE_852 is not set > # CONFIG_NLS_CODEPAGE_855 is not set > # CONFIG_NLS_CODEPAGE_857 is not set > # CONFIG_NLS_CODEPAGE_860 is not set > # CONFIG_NLS_CODEPAGE_861 is not set > # CONFIG_NLS_CODEPAGE_862 is not set > # CONFIG_NLS_CODEPAGE_863 is not set > # CONFIG_NLS_CODEPAGE_864 is not set > # CONFIG_NLS_CODEPAGE_865 is not set > # CONFIG_NLS_CODEPAGE_866 is not set > # CONFIG_NLS_CODEPAGE_869 is not set > # CONFIG_NLS_CODEPAGE_936 is not set > # CONFIG_NLS_CODEPAGE_950 is not set > # CONFIG_NLS_CODEPAGE_932 is not set > # CONFIG_NLS_CODEPAGE_949 is not set > # CONFIG_NLS_CODEPAGE_874 is not set > # CONFIG_NLS_ISO8859_8 is not set > # CONFIG_NLS_CODEPAGE_1250 is not set > # CONFIG_NLS_CODEPAGE_1251 is not set > CONFIG_NLS_ASCII=m > CONFIG_NLS_ISO8859_1=m > # CONFIG_NLS_ISO8859_2 is not set > # CONFIG_NLS_ISO8859_3 is not set > # CONFIG_NLS_ISO8859_4 is not set > # CONFIG_NLS_ISO8859_5 is not set > # CONFIG_NLS_ISO8859_6 is not set > # CONFIG_NLS_ISO8859_7 is not set > # CONFIG_NLS_ISO8859_9 is not set > # CONFIG_NLS_ISO8859_13 is not set > # CONFIG_NLS_ISO8859_14 is not set > CONFIG_NLS_ISO8859_15=m > # CONFIG_NLS_KOI8_R is not set > # CONFIG_NLS_KOI8_U is not set > CONFIG_NLS_UTF8=m > > # > # Kernel hacking > # > CONFIG_TRACE_IRQFLAGS_SUPPORT=y > # CONFIG_PRINTK_TIME is not set > # CONFIG_ENABLE_WARN_DEPRECATED is not set > # CONFIG_ENABLE_MUST_CHECK is not set > CONFIG_FRAME_WARN=1024 > # CONFIG_MAGIC_SYSRQ is not set > # CONFIG_UNUSED_SYMBOLS is not set > # CONFIG_DEBUG_FS is not set > # CONFIG_HEADERS_CHECK is not set > # CONFIG_DEBUG_KERNEL is not set > # CONFIG_SLUB_DEBUG_ON is not set > # CONFIG_SLUB_STATS is not set > CONFIG_DEBUG_BUGVERBOSE=y > # CONFIG_LATENCYTOP is not set > # CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set > # CONFIG_SAMPLES is not set > CONFIG_HAVE_ARCH_KGDB=y > # CONFIG_NONPROMISC_DEVMEM is not set > CONFIG_EARLY_PRINTK=y > # CONFIG_4KSTACKS is not set > CONFIG_X86_FIND_SMP_CONFIG=y > CONFIG_X86_MPPARSE=y > CONFIG_DOUBLEFAULT=y > CONFIG_IO_DELAY_TYPE_0X80=0 > CONFIG_IO_DELAY_TYPE_0XED=1 > CONFIG_IO_DELAY_TYPE_UDELAY=2 > CONFIG_IO_DELAY_TYPE_NONE=3 > CONFIG_IO_DELAY_0X80=y > # CONFIG_IO_DELAY_0XED is not set > # CONFIG_IO_DELAY_UDELAY is not set > # CONFIG_IO_DELAY_NONE is not set > CONFIG_DEFAULT_IO_DELAY_TYPE=0 > > # > # Security options > # > # CONFIG_KEYS is not set > # CONFIG_SECURITY is not set > CONFIG_CRYPTO=y > > # > # Crypto core or helper > # > CONFIG_CRYPTO_ALGAPI=m > CONFIG_CRYPTO_AEAD=m > CONFIG_CRYPTO_BLKCIPHER=m > CONFIG_CRYPTO_HASH=m > CONFIG_CRYPTO_MANAGER=m > # CONFIG_CRYPTO_NULL is not set > # CONFIG_CRYPTO_CRYPTD is not set > CONFIG_CRYPTO_AUTHENC=m > # CONFIG_CRYPTO_TEST is not set > > # > # Authenticated Encryption with Associated Data > # > # CONFIG_CRYPTO_CCM is not set > # CONFIG_CRYPTO_GCM is not set > # CONFIG_CRYPTO_SEQIV is not set > > # > # Block modes > # > CONFIG_CRYPTO_CBC=m > # CONFIG_CRYPTO_CTR is not set > # CONFIG_CRYPTO_CTS is not set > # CONFIG_CRYPTO_ECB is not set > # CONFIG_CRYPTO_PCBC is not set > > # > # Hash modes > # > CONFIG_CRYPTO_HMAC=m > > # > # Digest > # > # CONFIG_CRYPTO_CRC32C is not set > # CONFIG_CRYPTO_MD4 is not set > CONFIG_CRYPTO_MD5=m > # CONFIG_CRYPTO_MICHAEL_MIC is not set > CONFIG_CRYPTO_SHA1=m > CONFIG_CRYPTO_SHA256=m > CONFIG_CRYPTO_SHA512=m > # CONFIG_CRYPTO_TGR192 is not set > # CONFIG_CRYPTO_WP512 is not set > > # > # Ciphers > # > CONFIG_CRYPTO_AES=m > CONFIG_CRYPTO_AES_586=m > # CONFIG_CRYPTO_ANUBIS is not set > # CONFIG_CRYPTO_ARC4 is not set > CONFIG_CRYPTO_BLOWFISH=m > # CONFIG_CRYPTO_CAMELLIA is not set > # CONFIG_CRYPTO_CAST5 is not set > # CONFIG_CRYPTO_CAST6 is not set > CONFIG_CRYPTO_DES=m > # CONFIG_CRYPTO_FCRYPT is not set > # CONFIG_CRYPTO_KHAZAD is not set > # CONFIG_CRYPTO_SEED is not set > CONFIG_CRYPTO_SERPENT=m > # CONFIG_CRYPTO_TEA is not set > # CONFIG_CRYPTO_TWOFISH is not set > CONFIG_CRYPTO_TWOFISH_COMMON=m > CONFIG_CRYPTO_TWOFISH_586=m > > # > # Compression > # > CONFIG_CRYPTO_DEFLATE=m > CONFIG_CRYPTO_LZO=m > # CONFIG_CRYPTO_HW is not set > CONFIG_HAVE_KVM=y > # CONFIG_VIRTUALIZATION is not set > > # > # Library routines > # > CONFIG_BITREVERSE=m > CONFIG_GENERIC_FIND_FIRST_BIT=y > CONFIG_GENERIC_FIND_NEXT_BIT=y > CONFIG_CRC_CCITT=m > # CONFIG_CRC16 is not set > CONFIG_CRC_ITU_T=m > CONFIG_CRC32=m > # CONFIG_CRC7 is not set > # CONFIG_LIBCRC32C is not set > CONFIG_ZLIB_INFLATE=m > CONFIG_ZLIB_DEFLATE=m > CONFIG_LZO_COMPRESS=m > CONFIG_LZO_DECOMPRESS=m > CONFIG_TEXTSEARCH=y > CONFIG_TEXTSEARCH_KMP=m > CONFIG_TEXTSEARCH_BM=m > CONFIG_TEXTSEARCH_FSM=m > CONFIG_PLIST=y > CONFIG_HAS_IOMEM=y > CONFIG_HAS_IOPORT=y > CONFIG_HAS_DMA=y > > From owner-xfs@oss.sgi.com Wed Jun 18 00:29:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 00:29:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from molten.melbourne.sgi.com (molten.melbourne.sgi.com [134.14.54.33]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5I7TOML021975 for ; Wed, 18 Jun 2008 00:29:25 -0700 Received: by molten.melbourne.sgi.com (Postfix, from userid 16365) id D5F4A53426; Wed, 18 Jun 2008 17:32:55 +1000 (EST) Date: Wed, 18 Jun 2008 17:32:55 +1000 To: xfs@oss.sgi.com Subject: TAKE 956281 - Fix XFSQA test 144 User-Agent: nail 11.25 7/29/05 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20080618073255.D5F4A53426@molten.melbourne.sgi.com> From: donaldd@molten.melbourne.sgi.com (Donald Douwsma) 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: 16404 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@molten.melbourne.sgi.com Precedence: bulk X-list: xfs Fix XFSQA test 144 Two really dumb bugs: - "foo & 0x3FFFFFFFFFFFF" doesn't cap at 1TB, but rather at more than two magnitudes larger than that. That gets us EFBIG with typical 32bit XFS setups. - the command array can easily overflow and thus let the test fail Signed-off-by: Christoph Hellwig Date: Wed Jun 18 17:23:46 AEST 2008 Workarea: molten.melbourne.sgi.com:/home/donaldd/isms/xfs-cmds Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31327a xfstests/dmapi/src/suite2/src/test_fileattr.c - 1.13 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/dmapi/src/suite2/src/test_fileattr.c.diff?r1=text&tr1=1.13&r2=text&tr2=1.12&f=h - Fix XFSQA test 144 From owner-xfs@oss.sgi.com Wed Jun 18 00:51:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 00:51:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_33 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 m5I7pNnN024075 for ; Wed, 18 Jun 2008 00:51:24 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA14410; Wed, 18 Jun 2008 17:52:14 +1000 Message-ID: <4858BEAE.2080606@sgi.com> Date: Wed, 18 Jun 2008 17:52:14 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH, RFC] fix XFSQA 145 / test_hole References: <20080614175510.GA21014@lst.de> In-Reply-To: <20080614175510.GA21014@lst.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16405 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > There are two errors I see all the time in 145: > > - dm_probe_hole returns EINVAL for offsets close to the file size > - dm_probe_hole wants EAGAIN for a probe at offset 1, length 0 > > > The first error is a consequence of how the hole puching / probing > works. It always rounds the requested offset up to the next block > size and then checks if that rounded offset still fits into the file > size. Just do the same rounding in the testcase to make sure we don't > probe invalid offsets. > > The second error is very odd to me, as we never return AGAIN in the > whole dm_probe_hole path. I've just commented it out. > > I've also re-enabled the E2BIG to past-EOF test that was uncommented > before because it works perfectly fine now. > > > Signed-off-by: Christoph Hellwig Looks good. I have no idea what the EGAIN test is looking for ether. Don > > --- xfstests/145.out 19 Dec 2006 02:55:36 -0000 1.1 > +++ xfstests/145.out 14 Jun 2008 17:49:49 -0000 > @@ -16,13 +16,13 @@ Hole test beginning... > Verified hole at 4096 > (beginning errno subtests...) > report on test for E2BIG in probe (from past EOF): test successful > + report on test for E2BIG in probe (to past EOF): test successful > report on test for EACCES in no-right probe: test successful > report on test for success in SHARED probe: test successful. > report on test for success in EXCL probe: test successful. > report on test for EACCES in no-right punch: test successful > report on test for EACCES in SHARED punch: test successful > report on test for success in EXCL punch: test successful. > - report on test for EAGAIN in punch: test successful > report on test for EBADF in probe: test successful > report on test for EBADF in punch: test successful > report on test for EFAULT in probe (null handle): test successful > --- xfstests/dmapi/src/suite2/src/test_hole.c 9 Nov 2005 02:50:19 -0000 1.8 > +++ xfstests/dmapi/src/suite2/src/test_hole.c 14 Jun 2008 17:49:49 -0000 > @@ -69,7 +69,7 @@ main( > dm_sessid_t sid = DM_NO_SESSION; > char *pathname = NULL; > char *ls_path = NULL; > - dm_off_t offset = 0; > + dm_off_t offset = 0, end; > dm_off_t ex_off = 0; > dm_extent_t extent[20]; > u_int nelem; > @@ -162,10 +162,16 @@ main( > exit(1); > } > > + /* > + * The kernel always rounds the offset up to the next block > + * size, so we can only probes up to the previous to last block. > + */ > + end = (29604 / blocksize) * blocksize; > + > /* Check that dm_probe_hole returns an extent from the next > * highest multiple of the block size, to the end of the file > */ > - for (offset = 0; offset < 29604; offset++) { > + for (offset = 0; offset < end; offset++) { > if (dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, offset, length, > &roff, &rlen)) { > fprintf(stdout, "dm_probe_hole failed on pass %lld (%s)\n", > @@ -275,15 +281,10 @@ main( > dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, 30000, length, > &roff, &rlen)) > /*---------------------------------------------------------*/ > -#if 0 > - PROBLEM: No error is produced. > - off+len >= filesize should produce E2BIG... > - > ERRTEST(E2BIG, > "probe (to past EOF)", > dm_probe_hole(sid, hanp, hlen, DM_NO_TOKEN, 15000, 150000, > &roff, &rlen)) > -#endif > /*---------------------------------------------------------*/ > SHAREDTEST("probe", hanp, hlen, test_token, > dm_probe_hole(sid, hanp, hlen, test_token, > @@ -292,10 +293,18 @@ main( > EXCLTEST("punch", hanp, hlen, test_token, > dm_punch_hole(sid, hanp, hlen, test_token, 0, 0)) > /*---------------------------------------------------------*/ > + /* > + * No idea where that EAGAIN should come from, it's never > + * returned from the kernel. > + * > + * -- hch > + */ > +#if 0 > ERRTEST(EAGAIN, > "punch", > dm_punch_hole(sid, hanp, hlen, DM_NO_TOKEN, > 1, length)) > +#endif > /*---------------------------------------------------------*/ > if ((test_vp = handle_clone(hanp, hlen)) == NULL) { > fprintf(stderr, > From owner-xfs@oss.sgi.com Wed Jun 18 00:54:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 00:54: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=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from molten.melbourne.sgi.com (molten.melbourne.sgi.com [134.14.54.33]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5I7srtV024714 for ; Wed, 18 Jun 2008 00:54:54 -0700 Received: by molten.melbourne.sgi.com (Postfix, from userid 16365) id 540975359B; Wed, 18 Jun 2008 17:58:28 +1000 (EST) To: sgi.bugs.xfs@engr.melbourne.sgi.com, xfs@oss.sgi.com Subject: PARTIAL TAKE 956281 - fix XFSQA 145 / test_hole Message-Id: <20080618075828.540975359B@molten.melbourne.sgi.com> Date: Wed, 18 Jun 2008 17:58:28 +1000 (EST) From: donaldd@molten.melbourne.sgi.com (Donald Douwsma) 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: 16406 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@molten.melbourne.sgi.com Precedence: bulk X-list: xfs fix XFSQA 145 / test_hole There are two errors I see all the time in 145: - dm_probe_hole returns EINVAL for offsets close to the file size - dm_probe_hole wants EAGAIN for a probe at offset 1, length 0 The first error is a consequence of how the hole puching / probing works. It always rounds the requested offset up to the next block size and then checks if that rounded offset still fits into the file size. Just do the same rounding in the testcase to make sure we don't probe invalid offsets. The second error is very odd to me, as we never return AGAIN in the whole dm_probe_hole path. I've just commented it out. I've also re-enabled the E2BIG to past-EOF test that was uncommented before because it works perfectly fine now. Signed-off-by: Christoph Hellwig Date: Wed Jun 18 17:54:10 AEST 2008 Workarea: molten.melbourne.sgi.com:/home/donaldd/isms/xfs-cmds Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31330a xfstests/dmapi/src/suite2/src/test_hole.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/dmapi/src/suite2/src/test_hole.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h xfstests/145.out - 1.2 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/145.out.diff?r1=text&tr1=1.2&r2=text&tr2=1.1&f=h - fix XFSQA 145 / test_hole From owner-xfs@oss.sgi.com Wed Jun 18 02:04:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 02:04:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65 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 m5I944c1030939 for ; Wed, 18 Jun 2008 02:04:06 -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 TAA15709 for ; Wed, 18 Jun 2008 19:05:01 +1000 Date: Wed, 18 Jun 2008 19:07:59 +1000 To: "xfs@oss.sgi.com" Subject: [PATCH] XFS: Fix returning case-preserved name with CI node form directories From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------EJpXaOfPIMJQnq9LtbCipS 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 X-archive-position: 16407 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 ------------EJpXaOfPIMJQnq9LtbCipS Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: Quoted-Printable xfs_dir2_node_lookup() calls xfs_da_node_lookup_int() which iterates through leaf blocks containing the matching hash value for the name being looked up. Inside xfs_da_node_lookup_int(), it calls the xfs_dir2_leafn_lookup_for_entry() for each leaf block. xfs_dir2_leafn_lookup_for_entry() iterates through each matching hash/offset pair doing a name comparison to find the matching dirent. For CI mode, the state->extrablk retains the details of the block that has the CI match so xfs_dir2_node_lookup() can return the case-preserved name. The original implementation didn't retain the xfs_da_buf_t properly, so the lookup was returning a bogus name to be stored in the dentry. In the case of unlink, the bad name was passed and in debug mode, ASSERTed when it can't find the entry. --- fs/xfs/xfs_dir2_node.c | 69=20=20 ++++++++++++++++++++++++++++++------------------- 1 file changed, 43 insertions(+), 26 deletions(-) Index: 2.6.x-xfs/fs/xfs/xfs_dir2_node.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2_node.c +++ 2.6.x-xfs/fs/xfs/xfs_dir2_node.c @@ -549,7 +549,6 @@ xfs_dir2_leafn_lookup_for_entry( xfs_dir2_data_entry_t *dep; /* data block entry */ xfs_inode_t *dp; /* incore directory inode */ int error; /* error return value */ - int di =3D -1; /* data entry index */ int index; /* leaf entry index */ xfs_dir2_leaf_t *leaf; /* leaf structure */ xfs_dir2_leaf_entry_t *lep; /* leaf entry */ @@ -577,7 +576,6 @@ xfs_dir2_leafn_lookup_for_entry( if (state->extravalid) { curbp =3D state->extrablk.bp; curdb =3D state->extrablk.blkno; - di =3D state->extrablk.index; } /* * Loop over leaf entries with the right hash value. @@ -602,17 +600,27 @@ xfs_dir2_leafn_lookup_for_entry( */ if (newdb !=3D curdb) { /* - * If we had a block before, drop it. + * If we had a block before that we aren't saving + * for a CI name, drop it */ - if (curbp) + if (curbp && (args->cmpresult =3D=3D XFS_CMP_DIFFERENT || + curdb !=3D state->extrablk.blkno)) xfs_da_brelse(tp, curbp); /* - * Read the data block. + * If needing the block that is saved with a CI match, + * use it otherwise read in the new data block. */ - error =3D xfs_da_read_buf(tp, dp, xfs_dir2_db_to_da(mp, - newdb), -1, &curbp, XFS_DATA_FORK); - if (error) - return error; + if (args->cmpresult !=3D XFS_CMP_DIFFERENT && + newdb =3D=3D state->extrablk.blkno) { + ASSERT(state->extravalid); + curbp =3D state->extrablk.bp; + } else { + error =3D xfs_da_read_buf(tp, dp, + xfs_dir2_db_to_da(mp, newdb), + -1, &curbp, XFS_DATA_FORK); + if (error) + return error; + } xfs_dir2_data_check(dp, curbp); curdb =3D newdb; } @@ -624,38 +632,47 @@ xfs_dir2_leafn_lookup_for_entry( /* * Compare the entry and if it's an exact match, return * EEXIST immediately. If it's the first case-insensitive - * match, store the inode number and continue looking. + * match, store the block & inode number and continue looking. */ cmp =3D mp->m_dirnameops->compname(args, dep->name, dep->namelen); if (cmp !=3D XFS_CMP_DIFFERENT && cmp !=3D args->cmpresult) { + /* If there is a CI match block, drop it */ + if (args->cmpresult !=3D XFS_CMP_DIFFERENT && + curdb !=3D state->extrablk.blkno) + xfs_da_brelse(tp, state->extrablk.bp); args->cmpresult =3D cmp; args->inumber =3D be64_to_cpu(dep->inumber); - di =3D (int)((char *)dep - (char *)curbp->data); - error =3D EEXIST; + *indexp =3D index; + state->extravalid =3D 1; + state->extrablk.bp =3D curbp; + state->extrablk.blkno =3D curdb; + state->extrablk.index =3D (int)((char *)dep - + (char *)curbp->data); + state->extrablk.magic =3D XFS_DIR2_DATA_MAGIC; if (cmp =3D=3D XFS_CMP_EXACT) - goto out; + return XFS_ERROR(EEXIST); } } - /* Didn't find an exact match. */ - error =3D ENOENT; ASSERT(index =3D=3D be16_to_cpu(leaf->hdr.count) || (args->op_flags & XFS_DA_OP_OKNOENT)); -out: if (curbp) { - /* Giving back a data block. */ - state->extravalid =3D 1; - state->extrablk.bp =3D curbp; - state->extrablk.index =3D di; - state->extrablk.blkno =3D curdb; - state->extrablk.magic =3D XFS_DIR2_DATA_MAGIC; + if (args->cmpresult =3D=3D XFS_CMP_DIFFERENT) { + /* Giving back last used data block. */ + state->extravalid =3D 1; + state->extrablk.bp =3D curbp; + state->extrablk.index =3D -1; + state->extrablk.blkno =3D curdb; + state->extrablk.magic =3D XFS_DIR2_DATA_MAGIC; + } else { + /* If the curbp is not the CI match block, drop it */ + if (state->extrablk.bp !=3D curbp) + xfs_da_brelse(tp, curbp); + } } else { state->extravalid =3D 0; } - /* - * Return the index, that will be the deletion point for remove/replace. - */ *indexp =3D index; - return XFS_ERROR(error); + return XFS_ERROR(ENOENT); } /* ------------EJpXaOfPIMJQnq9LtbCipS Content-Disposition: attachment; filename=fix_node_form_dir_ci_name_return.patch Content-Type: text/x-patch; name=fix_node_form_dir_ci_name_return.patch Content-Transfer-Encoding: Quoted-Printable XFS: Fix returning case-preserved name with CI node form directories xfs_dir2_node_lookup() calls xfs_da_node_lookup_int() which iterates through leaf blocks containing the matching hash value for the name being looked up. Inside xfs_da_node_lookup_int(), it calls the=20 xfs_dir2_leafn_lookup_for_entry() for each leaf block.=20 xfs_dir2_leafn_lookup_for_entry() iterates through each matching hash/offset pair doing a name comparison to find the matching=20 dirent.=20 For CI mode, the state->extrablk retains the details of the block that has the CI match so xfs_dir2_node_lookup() can return the case-preserved name. The original implementation didn't retain the xfs_da_buf_t properly, so the lookup was returning a bogus name to be stored in the dentry. In the case of unlink, the bad name was passed and in debug mode, ASSERTed when it can't find the entry. --- fs/xfs/xfs_dir2_node.c | 69 ++++++++++++++++++++++++++++++--------------= ----- 1 file changed, 43 insertions(+), 26 deletions(-) Index: 2.6.x-xfs/fs/xfs/xfs_dir2_node.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- 2.6.x-xfs.orig/fs/xfs/xfs_dir2_node.c +++ 2.6.x-xfs/fs/xfs/xfs_dir2_node.c @@ -549,7 +549,6 @@ xfs_dir2_leafn_lookup_for_entry( xfs_dir2_data_entry_t *dep; /* data block entry */ xfs_inode_t *dp; /* incore directory inode */ int error; /* error return value */ - int di =3D -1; /* data entry index */ int index; /* leaf entry index */ xfs_dir2_leaf_t *leaf; /* leaf structure */ xfs_dir2_leaf_entry_t *lep; /* leaf entry */ @@ -577,7 +576,6 @@ xfs_dir2_leafn_lookup_for_entry( if (state->extravalid) { curbp =3D state->extrablk.bp; curdb =3D state->extrablk.blkno; - di =3D state->extrablk.index; } /* * Loop over leaf entries with the right hash value. @@ -602,17 +600,27 @@ xfs_dir2_leafn_lookup_for_entry( */ if (newdb !=3D curdb) { /* - * If we had a block before, drop it. + * If we had a block before that we aren't saving + * for a CI name, drop it */ - if (curbp) + if (curbp && (args->cmpresult =3D=3D XFS_CMP_DIFFERENT || + curdb !=3D state->extrablk.blkno)) xfs_da_brelse(tp, curbp); /* - * Read the data block. + * If needing the block that is saved with a CI match, + * use it otherwise read in the new data block. */ - error =3D xfs_da_read_buf(tp, dp, xfs_dir2_db_to_da(mp, - newdb), -1, &curbp, XFS_DATA_FORK); - if (error) - return error; + if (args->cmpresult !=3D XFS_CMP_DIFFERENT && + newdb =3D=3D state->extrablk.blkno) { + ASSERT(state->extravalid); + curbp =3D state->extrablk.bp; + } else { + error =3D xfs_da_read_buf(tp, dp, + xfs_dir2_db_to_da(mp, newdb), + -1, &curbp, XFS_DATA_FORK); + if (error) + return error; + } xfs_dir2_data_check(dp, curbp); curdb =3D newdb; } @@ -624,38 +632,47 @@ xfs_dir2_leafn_lookup_for_entry( /* * Compare the entry and if it's an exact match, return * EEXIST immediately. If it's the first case-insensitive - * match, store the inode number and continue looking. + * match, store the block & inode number and continue looking. */ cmp =3D mp->m_dirnameops->compname(args, dep->name, dep->namelen); if (cmp !=3D XFS_CMP_DIFFERENT && cmp !=3D args->cmpresult) { + /* If there is a CI match block, drop it */ + if (args->cmpresult !=3D XFS_CMP_DIFFERENT && + curdb !=3D state->extrablk.blkno) + xfs_da_brelse(tp, state->extrablk.bp); args->cmpresult =3D cmp; args->inumber =3D be64_to_cpu(dep->inumber); - di =3D (int)((char *)dep - (char *)curbp->data); - error =3D EEXIST; + *indexp =3D index; + state->extravalid =3D 1; + state->extrablk.bp =3D curbp; + state->extrablk.blkno =3D curdb; + state->extrablk.index =3D (int)((char *)dep - + (char *)curbp->data); + state->extrablk.magic =3D XFS_DIR2_DATA_MAGIC; if (cmp =3D=3D XFS_CMP_EXACT) - goto out; + return XFS_ERROR(EEXIST); } } - /* Didn't find an exact match. */ - error =3D ENOENT; ASSERT(index =3D=3D be16_to_cpu(leaf->hdr.count) || (args->op_flags & XFS_DA_OP_OKNOENT)); -out: if (curbp) { - /* Giving back a data block. */ - state->extravalid =3D 1; - state->extrablk.bp =3D curbp; - state->extrablk.index =3D di; - state->extrablk.blkno =3D curdb; - state->extrablk.magic =3D XFS_DIR2_DATA_MAGIC; + if (args->cmpresult =3D=3D XFS_CMP_DIFFERENT) { + /* Giving back last used data block. */ + state->extravalid =3D 1; + state->extrablk.bp =3D curbp; + state->extrablk.index =3D -1; + state->extrablk.blkno =3D curdb; + state->extrablk.magic =3D XFS_DIR2_DATA_MAGIC; + } else { + /* If the curbp is not the CI match block, drop it */ + if (state->extrablk.bp !=3D curbp) + xfs_da_brelse(tp, curbp); + } } else { state->extravalid =3D 0; } - /* - * Return the index, that will be the deletion point for remove/replace. - */ *indexp =3D index; - return XFS_ERROR(error); + return XFS_ERROR(ENOENT); } =20 /* ------------EJpXaOfPIMJQnq9LtbCipS-- From owner-xfs@oss.sgi.com Wed Jun 18 05:04:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 05:04:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5IC4n83017683 for ; Wed, 18 Jun 2008 05:04:49 -0700 X-ASG-Debug-ID: 1213790745-0b6e012e0000-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 5F58417DF006; Wed, 18 Jun 2008 05:05:45 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id QWCPjdkbMw0lVQAk; Wed, 18 Jun 2008 05:05:45 -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 m5IC5aNW000570 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 Jun 2008 14:05:36 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5IC5aQD000560; Wed, 18 Jun 2008 14:05:36 +0200 Date: Wed, 18 Jun 2008 14:05:36 +0200 From: Christoph Hellwig To: Donald Douwsma Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] kill INDUCE_IO_ERROR Subject: Re: [PATCH] kill INDUCE_IO_ERROR Message-ID: <20080618120535.GA32691@lst.de> References: <20080523062323.GA32637@lst.de> <20080616101412.GA17939@lst.de> <485892D7.4080000@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485892D7.4080000@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213790747 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0360 1.0000 -1.7883 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.79 X-Barracuda-Spam-Status: No, SCORE=-1.79 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.53637 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: 16408 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 02:45:11PM +1000, Donald Douwsma wrote: > Christoph Hellwig wrote: > >On Fri, May 23, 2008 at 08:23:23AM +0200, Christoph Hellwig wrote: > >>All the error injection is already enabled through ifdef DEBUG, so kill > >>the never set second cpp symbol to activate it without the rest of the > >>debugging infrastructure. > > > >Can I get a review on this absolutely trivial patch? > > I'd like to keep INDUCE_IO_ERROR around so we have a way to introduce > ioerrors in release builds during testing. > > We could add it to xfs.h with the commented out QUOTADEBUG so people > know we still want to use it. cpp symbols not exposed by Kconfig will never get tested. If you thing it's really useful for release builds (which don't quite agree with) we should just enable it unconditionally. It's just in a few places, and any branch predictor worth it's name should take care of the additional branches without visible cost. From owner-xfs@oss.sgi.com Wed Jun 18 07:44:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 07: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.0 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5IEildJ028593 for ; Wed, 18 Jun 2008 07:44:48 -0700 X-ASG-Debug-ID: 1213800343-5e9c001f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zen.pimp.org.za (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1BE24CE5990 for ; Wed, 18 Jun 2008 07:45:43 -0700 (PDT) Received: from zen.pimp.org.za (zen.pimp.org.za [70.85.31.111]) by cuda.sgi.com with ESMTP id dp6awqqCybI9fBUY for ; Wed, 18 Jun 2008 07:45:43 -0700 (PDT) Received: from area51.pimp.org.za (87-194-135-198.bethere.co.uk [87.194.135.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-gateway.pimp.org.za", Issuer "Certificate Authority" (verified OK)) by zen.pimp.org.za (Postfix) with ESMTP id 3A6B143A4 for ; Wed, 18 Jun 2008 15:45:43 +0100 (BST) Received: from aurora.pimp.org.za (aurora.pimp.org.za [192.168.1.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by area51.pimp.org.za (Postfix) with ESMTPS id 1F94A34846 for ; Wed, 18 Jun 2008 15:45:24 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by aurora.pimp.org.za (Postfix) with ESMTP id 5F9C234833 for ; Wed, 18 Jun 2008 15:45:40 +0100 (BST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new 2.5.3 (NetBSD) at pimp.org.za Received: from aurora.pimp.org.za ([127.0.0.1]) by localhost (aurora.pimp.org.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wwEG3agfpDE for ; Wed, 18 Jun 2008 15:45:34 +0100 (BST) Received: by aurora.pimp.org.za (Postfix, from userid 1000) id 995B834830; Wed, 18 Jun 2008 15:45:34 +0100 (BST) Date: Wed, 18 Jun 2008 15:45:34 +0100 From: Michael-John Turner To: xfs@oss.sgi.com X-ASG-Orig-Subj: Directory mtime update issue (kernel 2.6.25) Subject: Directory mtime update issue (kernel 2.6.25) Message-ID: <20080618144534.GC11301@aurora.pimp.org.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (NetBSD aurora.pimp.org.za 4.0_STABLE sparc64) X-Barracuda-Connect: zen.pimp.org.za[70.85.31.111] X-Barracuda-Start-Time: 1213800344 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3983 1.0000 -0.0042 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.00 X-Barracuda-Spam-Status: No, SCORE=-0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53651 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16409 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mj@mjturner.net Precedence: bulk X-list: xfs Hi all, I'm a recent convert to XFS and am experiencing something that I consider rather odd. When I move a directory on the same filesystem, XFS updates the directory's mtime, which is something I wouldn't expect to happen. I tested the same set of commands on a tmpfs filesystem and the renamed directory's mtime doesn't change. Similarly, when I move a file between directories on an XFS filesystem, the file's mtime doesn't change (as expected). Is this behaviour correct? I'm running Linux kernel 2.6.25.6 on an x86_64 system, filesystem mounted with the standard options (see below). For example (~ and ~/tmp are the same filesystem, /home): [0] mj@majestic:~/tmp$ mount |grep home /dev/mapper/data-home on /home type xfs (rw) [0] mj@majestic:~/tmp$ mkdir test [0] mj@majestic:~/tmp$ ls -ld test drwxr-sr-x 2 mj mj 6 Jun 18 15:28 test [0] mj@majestic:~/tmp$ touch -t 200801011530 test [0] mj@majestic:~/tmp$ ls -ld test drwxr-sr-x 2 mj mj 6 Jan 1 15:30 test [0] mj@majestic:~/tmp$ stat test File: `test' Size: 6 Blocks: 0 IO Block: 4096 directory Device: fd00h/64768d Inode: 951267331 Links: 2 Access: (2755/drwxr-sr-x) Uid: ( 1000/ mj) Gid: ( 1000/ mj) Access: 2008-01-01 15:30:00.000000000 +0000 Modify: 2008-01-01 15:30:00.000000000 +0000 Change: 2008-06-18 15:29:08.173750666 +0100 [0] mj@majestic:~/tmp$ mv test test1 [0] mj@majestic:~/tmp$ ls -ld test1 drwxr-sr-x 2 mj mj 6 Jan 1 15:30 test1 [0] mj@majestic:~/tmp$ mv test1 .. [0] mj@majestic:~/tmp$ ls -ld ../test1 drwxr-sr-x 2 mj mj 6 Jun 18 15:30 ../test1 File: `../test1' Size: 6 Blocks: 0 IO Block: 4096 directory Device: fd00h/64768d Inode: 951267331 Links: 2 Access: (2755/drwxr-sr-x) Uid: ( 1000/ mj) Gid: ( 1000/ mj) Access: 2008-01-01 15:30:00.000000000 +0000 Modify: 2008-06-18 15:30:02.814078187 +0100 Change: 2008-06-18 15:30:02.814078187 +0100 -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/ From owner-xfs@oss.sgi.com Wed Jun 18 09:11:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 09:12: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.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5IGBvXZ005982 for ; Wed, 18 Jun 2008 09:11:58 -0700 X-ASG-Debug-ID: 1213805574-38aa00e00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C6B91CE6AF4 for ; Wed, 18 Jun 2008 09:12:54 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id tEslOOzGkEfoZSw4 for ; Wed, 18 Jun 2008 09:12:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADjQWEh5LG+u/2dsb2JhbACwXA X-IronPort-AV: E=Sophos;i="4.27,666,1204464600"; d="scan'208";a="129305555" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 19 Jun 2008 01:42:53 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K90HE-0002Yb-Cv; Thu, 19 Jun 2008 02:12:52 +1000 Date: Thu, 19 Jun 2008 02:12:52 +1000 From: Dave Chinner To: Marco Berizzi Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: 2.6.26-rc6 link count mismatch for inode Subject: Re: XFS: 2.6.26-rc6 link count mismatch for inode Message-ID: <20080618161252.GV3700@disturbed> Mail-Followup-To: Marco Berizzi , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213805575 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4398 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53657 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: 16410 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 16, 2008 at 11:11:31AM +0200, Marco Berizzi wrote: > Hi Folk, > > I was tring to compile firefox 3.0rc3 > and while I was erasing a previous > /tmp/mozilla tree, I started a new > tar xjf mozilla-blabla. > After a while linux 2.6.26-rc6 was > unresponsive: I have unplugged the > power cable. No problem at startup, > but: What are your mount options? Are you using barriers (what does XFS output in dmesg when mounting the filesystem)? I ask because I've seen this sort of directory corruption before when using volatile write caches and yanking the power.... i.e. the corruption could have been caused by the way you reset the system, not because of the hang. Do you have any information on what caused the hang? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jun 18 09:33:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 09:33:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5IGX0p9007596 for ; Wed, 18 Jun 2008 09:33:00 -0700 X-ASG-Debug-ID: 1213806837-1ec103800000-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 8093C17E1173 for ; Wed, 18 Jun 2008 09:33:57 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 7g44ArIiV60mDTR1 for ; Wed, 18 Jun 2008 09:33:57 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K90bc-00061I-NM; Wed, 18 Jun 2008 16:33:56 +0000 Date: Wed, 18 Jun 2008 12:33:56 -0400 From: Christoph Hellwig To: Michael-John Turner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Directory mtime update issue (kernel 2.6.25) Subject: Re: Directory mtime update issue (kernel 2.6.25) Message-ID: <20080618163356.GA6330@infradead.org> References: <20080618144534.GC11301@aurora.pimp.org.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080618144534.GC11301@aurora.pimp.org.za> 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: 1213806838 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.53658 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: 16411 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 03:45:34PM +0100, Michael-John Turner wrote: > Hi all, > > I'm a recent convert to XFS and am experiencing something that I consider > rather odd. When I move a directory on the same filesystem, XFS updates the > directory's mtime, which is something I wouldn't expect to happen. I tested > the same set of commands on a tmpfs filesystem and the renamed directory's > mtime doesn't change. Similarly, when I move a file between directories on > an XFS filesystem, the file's mtime doesn't change (as expected). > > Is this behaviour correct? I'm running Linux kernel 2.6.25.6 on an x86_64 > system, filesystem mounted with the standard options (see below). Posix says about rename(2): Upon successful completion, rename() shall mark for update the st_ctime and st_mtime fields of the parent directory of each file. It doesn't mention anything about timestampt updates on the renamed file nor the victim. Ext2 and friends update ctime on the renamed inode and victim and have this comment: /* * Like most other Unix systems, set the ctime for inodes on a * rename. * inode_dec_link_count() will mark the inode dirty. */ XFS does indeed updated the mtime too for the case when the source is a directory and we get a new parent but just the ctime in all other cases, which seems highly dubious to me. XFS also has an interesting comment on why ctime is updated at all: /* * We always want to hit the ctime on the source inode. * We do it in the if clause above for the 'new_parent && * src_is_directory' case, and here we get all the other * cases. This isn't strictly required by the standards * since the source inode isn't really being changed, * but old unix file systems did it and some incremental * backup programs won't work without it. */ Below is an untested patch to always just update the ctime: Index: linux-2.6-xfs/fs/xfs/xfs_rename.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rename.c 2008-06-18 18:24:38.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_rename.c 2008-06-18 18:30:17.000000000 +0200 @@ -336,22 +336,18 @@ xfs_rename( ASSERT(error != EEXIST); if (error) goto abort_return; - xfs_ichgtime(src_ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); - - } else { - /* - * We always want to hit the ctime on the source inode. - * We do it in the if clause above for the 'new_parent && - * src_is_directory' case, and here we get all the other - * cases. This isn't strictly required by the standards - * since the source inode isn't really being changed, - * but old unix file systems did it and some incremental - * backup programs won't work without it. - */ - xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG); } /* + * We always want to hit the ctime on the source inode. + * + * This isn't strictly required by the standards since the source + * inode isn't really being changed, but old unix file systems did + * it and some incremental backup programs won't work without it. + */ + xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG); + + /* * Adjust the link count on src_dp. This is necessary when * renaming a directory, either within one parent when * the target existed, or across two parent directories. From owner-xfs@oss.sgi.com Wed Jun 18 09:39:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 09:39: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=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5IGdYGO008211 for ; Wed, 18 Jun 2008 09:39:34 -0700 X-ASG-Debug-ID: 1213807232-3bb102990000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bay0-omc1-s3.bay0.hotmail.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ACEC6CE69F1 for ; Wed, 18 Jun 2008 09:40:32 -0700 (PDT) Received: from bay0-omc1-s3.bay0.hotmail.com (bay0-omc1-s3.bay0.hotmail.com [65.54.246.75]) by cuda.sgi.com with ESMTP id dVszXOghj6Lqx3NH for ; Wed, 18 Jun 2008 09:40:32 -0700 (PDT) Received: from hotmail.com ([65.54.174.73]) by bay0-omc1-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Jun 2008 09:40:32 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 18 Jun 2008 09:40:32 -0700 Message-ID: Received: from 85.32.103.134 by BAY103-DAV1.phx.gbl with DAV; Wed, 18 Jun 2008 16:40:31 +0000 X-Originating-IP: [85.32.103.134] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Dave Chinner" Cc: , References: <20080618161252.GV3700@disturbed> X-ASG-Orig-Subj: Re: XFS: 2.6.26-rc6 link count mismatch for inode Subject: Re: XFS: 2.6.26-rc6 link count mismatch for inode Date: Wed, 18 Jun 2008 18:39:59 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 18 Jun 2008 16:40:32.0201 (UTC) FILETIME=[06416B90:01C8D162] X-Barracuda-Connect: bay0-omc1-s3.bay0.hotmail.com[65.54.246.75] X-Barracuda-Start-Time: 1213807232 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3637 1.0000 -0.1061 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.39 X-Barracuda-Spam-Status: No, SCORE=0.39 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, MSGID_FROM_MTA_HEADER X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53658 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 0.00 MSGID_FROM_MTA_HEADER Message-Id was added by a relay X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16412 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Mon, Jun 16, 2008 at 11:11:31AM +0200, Marco Berizzi wrote: > > Hi Folk, > > > > I was tring to compile firefox 3.0rc3 > > and while I was erasing a previous > > /tmp/mozilla tree, I started a new > > tar xjf mozilla-blabla. > > After a while linux 2.6.26-rc6 was > > unresponsive: I have unplugged the > > power cable. No problem at startup, > > but: > > What are your mount options? root@Venus:/etc# cat mtab /dev/sda2 / xfs rw 0 0 root@Venus:/etc# cat fstab /dev/sda2 / xfs defaults 1 1 > Are you using barriers (what does XFS > output in dmesg when mounting the filesystem)? scsi0 : ahci scsi1 : ahci scsi2 : ahci ata1: SATA max UDMA/133 abar m2048@0xe4809000 port 0xe4809100 irq 17 ata2: DUMMY ata3: DUMMY ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded ata1.00: ACPI cmd ef/10:03:00:00:00:a0 succeeded ata1.00: ATA-7: ST9160821AS, 3.BHE, max UDMA/100 ata1.00: 312581808 sectors, multi 16: LBA48 ata1.00: ACPI cmd f5/00:00:00:00:00:a0 filtered out ata1.00: ACPI cmd b1/c1:00:00:00:00:a0 filtered out ata1.00: ACPI cmd c6/00:10:00:00:00:a0 succeeded ata1.00: ACPI cmd ef/10:03:00:00:00:a0 succeeded ata1.00: configured for UDMA/100 ata1.00: configured for UDMA/100 ata1: EH complete scsi 0:0:0:0: Direct-Access ATA ST9160821AS 3.BH PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sda3 sda4 sd 0:0:0:0: [sda] Attached SCSI disk ata_piix 0000:00:1f.1: version 2.12 ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 16 (level, low) -> IRQ 16 PCI: Setting latency timer of device 0000:00:1f.1 to 64 scsi3 : ata_piix scsi4 : ata_piix ata4: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x40c0 irq 14 ata5: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x40c8 irq 15 ata4.00: ATAPI: HL-DT-ST DVDRAM GSA-T20L, NC08, max MWDMA2 ata4.00: configured for MWDMA2 ata5: port disabled. ignoring. scsi 3:0:0:0: CD-ROM HL-DT-ST DVDRAM GSA-T20L NC08 PQ: 0 ANSI: 5 PNP: PS/2 Controller [PNP0303:C298,PNP0f13:C299] at 0x60,0x64 irq 1,12 i8042.c: Detected active multiplexing controller, rev 1.1. serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX0 port at 0x60,0x64 irq 12 serio: i8042 AUX1 port at 0x60,0x64 irq 12 serio: i8042 AUX2 port at 0x60,0x64 irq 12 serio: i8042 AUX3 port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice TCP cubic registered Initializing XFRM netlink socket NET: Registered protocol family 17 Using IPI Shortcut mode input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/inpu t0 XFS mounting filesystem sda2 Ending clean XFS mount for filesystem: sda2 VFS: Mounted root (xfs filesystem) readonly. > I ask because I've > seen this sort of directory corruption before when using volatile > write caches and yanking the power.... > > i.e. the corruption could have been caused by the way you reset the > system, not because of the hang. Do you have any information on what > caused the hang? The tar xf mozilla-source.tarball was not responding nor writing anything on the disk. I did issue also a kill -9 'pid of tar xf' but it did not want to die. So I think the problem was on the filesystem before the incorrect shutdown. I can retry the test. Let me know if I can do a xfs_repair. From owner-xfs@oss.sgi.com Wed Jun 18 10:08:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 10:08: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.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5IH8pbb010140 for ; Wed, 18 Jun 2008 10:08:51 -0700 X-ASG-Debug-ID: 1213808989-5280034a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3F99CE7004 for ; Wed, 18 Jun 2008 10:09:49 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id dKHVDR7YL0uxBkEg for ; Wed, 18 Jun 2008 10:09:49 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4308DA84114 for ; Wed, 18 Jun 2008 12:09:48 -0500 (CDT) Message-ID: <4859415B.3000009@sandeen.net> Date: Wed, 18 Jun 2008 12:09:47 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: is the flush-on-close-after-truncate still needed? Subject: is the flush-on-close-after-truncate still needed? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213808989 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0202 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.53658 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: 16413 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs After Lachlan's fix to separate on-disk and in-memory sizes, and only update on-disk when data is on-disk (http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed? Thanks, -Eric From owner-xfs@oss.sgi.com Wed Jun 18 10:48:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 10:48:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5IHmEXN012932 for ; Wed, 18 Jun 2008 10:48:16 -0700 X-ASG-Debug-ID: 1213811352-100c026c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ext.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 768A5CE57A6 for ; Wed, 18 Jun 2008 10:49:12 -0700 (PDT) Received: from ext.agami.com (64.221.212.177.ptr.us.xo.net [64.221.212.177]) by cuda.sgi.com with ESMTP id bOHfjipoYCbWRA41 for ; Wed, 18 Jun 2008 10:49:12 -0700 (PDT) Received: from agami.com (mail [192.168.168.5]) by ext.agami.com (8.12.5/8.12.5) with ESMTP id m5IHmnmb011345 for ; Wed, 18 Jun 2008 10:48:49 -0700 Received: from mx1.agami.com (mx1.agami.com [10.123.10.30]) by agami.com (8.12.11/8.12.11) with ESMTP id m5IHmjuG017143 for ; Wed, 18 Jun 2008 10:48:49 -0700 Received: from dchinner-64.agami.com ([10.123.4.83]) by mx1.agami.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jun 2008 10:49:08 -0700 From: Dave Chinner To: Eric Sandeen X-ASG-Orig-Subj: Re: is the flush-on-close-after-truncate still needed? Subject: Re: is the flush-on-close-after-truncate still needed? Date: Wed, 18 Jun 2008 10:49:07 -0700 User-Agent: KMail/1.8.2 Cc: xfs-oss References: <4859415B.3000009@sandeen.net> In-Reply-To: <4859415B.3000009@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806181049.07812.dchinner@agami.com> X-OriginalArrivalTime: 18 Jun 2008 17:49:08.0553 (UTC) FILETIME=[9BCAE390:01C8D16B] X-Barracuda-Connect: 64.221.212.177.ptr.us.xo.net[64.221.212.177] X-Barracuda-Start-Time: 1213811353 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2714 1.0000 -0.4746 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.37 X-Barracuda-Spam-Status: No, SCORE=-0.37 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_GENERIC_NO_PTR X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53664 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_GENERIC_NO_PTR Delivered to trusted network by host with generic-looking RDNS - indicates no PTR record X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16414 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Wednesday 18 June 2008 10:09 am, Eric Sandeen wrote: > After Lachlan's fix to separate on-disk and in-memory sizes, and only > update on-disk when data is on-disk > (http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the > XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed? Yes, because waiting 30s before writing back /etc/fstab after it has been modified will result in lots of bug reports of /etc/fstab being zero length after a crash instead of being full of NULLs. We have had very few reports of zero length files or files with NULLs since this change was made (regardless of the file size update ordering changes). i.e. if we remove this code then the common case where NULL files occurred will return - only this time as zero length files. Cheers, Dave. From owner-xfs@oss.sgi.com Wed Jun 18 10:58:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 10:58:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5IHw5jr013796 for ; Wed, 18 Jun 2008 10:58:05 -0700 X-ASG-Debug-ID: 1213811943-470100950000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C1C6A247BD1 for ; Wed, 18 Jun 2008 10:59:03 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id H0kLNQkUwhYvPRgY for ; Wed, 18 Jun 2008 10:59:03 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id DB37AAC626E; Wed, 18 Jun 2008 12:59:02 -0500 (CDT) Message-ID: <48594CE6.1080209@sandeen.net> Date: Wed, 18 Jun 2008 12:59:02 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Dave Chinner CC: xfs-oss X-ASG-Orig-Subj: Re: is the flush-on-close-after-truncate still needed? Subject: Re: is the flush-on-close-after-truncate still needed? References: <4859415B.3000009@sandeen.net> <200806181049.07812.dchinner@agami.com> In-Reply-To: <200806181049.07812.dchinner@agami.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1213811943 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.53665 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: 16415 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Dave Chinner wrote: > On Wednesday 18 June 2008 10:09 am, Eric Sandeen wrote: >> After Lachlan's fix to separate on-disk and in-memory sizes, and only >> update on-disk when data is on-disk >> (http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the >> XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed? > > Yes, because waiting 30s before writing back /etc/fstab after it > has been modified will result in lots of bug reports of /etc/fstab > being zero length after a crash instead of being full of NULLs. > We have had very few reports of zero length files or files with > NULLs since this change was made (regardless of the file size > update ordering changes). i.e. if we remove this code then the > common case where NULL files occurred will return - only this > time as zero length files. Ah, right. Ok, thanks! -Eric > Cheers, > > Dave. > From owner-xfs@oss.sgi.com Wed Jun 18 12:09:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 12:10:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,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 m5IJ9vae018352 for ; Wed, 18 Jun 2008 12:09:57 -0700 X-ASG-Debug-ID: 1213816254-04b7014e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zen.pimp.org.za (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2ECFB17E2538 for ; Wed, 18 Jun 2008 12:10:54 -0700 (PDT) Received: from zen.pimp.org.za (zen.pimp.org.za [70.85.31.111]) by cuda.sgi.com with ESMTP id EIvHGruG43QRehTP for ; Wed, 18 Jun 2008 12:10:54 -0700 (PDT) Received: from area51.pimp.org.za (87-194-135-198.bethere.co.uk [87.194.135.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-gateway.pimp.org.za", Issuer "Certificate Authority" (verified OK)) by zen.pimp.org.za (Postfix) with ESMTP id D860B449D; Wed, 18 Jun 2008 20:10:53 +0100 (BST) Received: from aurora.pimp.org.za (aurora.pimp.org.za [192.168.1.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by area51.pimp.org.za (Postfix) with ESMTPS id 8F6CC34846; Wed, 18 Jun 2008 20:10:28 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by aurora.pimp.org.za (Postfix) with ESMTP id 0BCA534833; Wed, 18 Jun 2008 20:10:51 +0100 (BST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new 2.5.3 (NetBSD) at pimp.org.za Received: from aurora.pimp.org.za ([127.0.0.1]) by localhost (aurora.pimp.org.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qrGS0sy6jDD; Wed, 18 Jun 2008 20:10:45 +0100 (BST) Received: by aurora.pimp.org.za (Postfix, from userid 1000) id 2568C34830; Wed, 18 Jun 2008 20:10:45 +0100 (BST) Date: Wed, 18 Jun 2008 20:10:45 +0100 From: Michael-John Turner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Directory mtime update issue (kernel 2.6.25) Subject: Re: Directory mtime update issue (kernel 2.6.25) Message-ID: <20080618191045.GA10722@aurora.pimp.org.za> References: <20080618144534.GC11301@aurora.pimp.org.za> <20080618163356.GA6330@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080618163356.GA6330@infradead.org> User-Agent: Mutt/1.5.18 (NetBSD aurora.pimp.org.za 4.0_STABLE sparc64) X-Barracuda-Connect: zen.pimp.org.za[70.85.31.111] X-Barracuda-Start-Time: 1213816255 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3517 1.0000 -0.1469 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.15 X-Barracuda-Spam-Status: No, SCORE=-0.15 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53669 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16416 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mj@mjturner.net Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 12:33:56PM -0400, Christoph Hellwig wrote: > XFS does indeed updated the mtime too for the case when the source is > a directory and we get a new parent but just the ctime in all other > cases, which seems highly dubious to me. Thanks for the prompt reply and the patch. I'm surprised this hasn't been mentioned before as every other Unix filesystem I've used has not updated the moved file's mtime during a rename(2). It's also odd that XFS only changes the mtime when there's a new parent. What does everyone else think? Would it be possible to have this patch or a similar one committed upstream? -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/ From owner-xfs@oss.sgi.com Wed Jun 18 15:30:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 15:30:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5IMU1IL001853 for ; Wed, 18 Jun 2008 15:30:01 -0700 X-ASG-Debug-ID: 1213828259-35af02f50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zen.pimp.org.za (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DB90217E32BE for ; Wed, 18 Jun 2008 15:30:59 -0700 (PDT) Received: from zen.pimp.org.za (zen.pimp.org.za [70.85.31.111]) by cuda.sgi.com with ESMTP id GLSRLF50yc3F13sQ for ; Wed, 18 Jun 2008 15:30:59 -0700 (PDT) Received: from area51.pimp.org.za (87-194-135-198.bethere.co.uk [87.194.135.198]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-gateway.pimp.org.za", Issuer "Certificate Authority" (verified OK)) by zen.pimp.org.za (Postfix) with ESMTP id D2BE3449D; Wed, 18 Jun 2008 23:30:58 +0100 (BST) Received: from aurora.pimp.org.za (aurora.pimp.org.za [192.168.1.6]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by area51.pimp.org.za (Postfix) with ESMTPS id 2436334846; Wed, 18 Jun 2008 23:30:29 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by aurora.pimp.org.za (Postfix) with ESMTP id 341003482F; Wed, 18 Jun 2008 23:30:56 +0100 (BST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new 2.5.3 (NetBSD) at pimp.org.za Received: from aurora.pimp.org.za ([127.0.0.1]) by localhost (aurora.pimp.org.za [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPhxiHt2OqUs; Wed, 18 Jun 2008 23:30:50 +0100 (BST) Received: by aurora.pimp.org.za (Postfix, from userid 1000) id CE58B34833; Wed, 18 Jun 2008 23:30:50 +0100 (BST) Date: Wed, 18 Jun 2008 23:30:50 +0100 From: Michael-John Turner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Directory mtime update issue (kernel 2.6.25) Subject: Re: Directory mtime update issue (kernel 2.6.25) Message-ID: <20080618223050.GA15558@aurora.pimp.org.za> References: <20080618144534.GC11301@aurora.pimp.org.za> <20080618163356.GA6330@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080618163356.GA6330@infradead.org> User-Agent: Mutt/1.5.18 (NetBSD aurora.pimp.org.za 4.0_STABLE sparc64) X-Barracuda-Connect: zen.pimp.org.za[70.85.31.111] X-Barracuda-Start-Time: 1213828259 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4826 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53683 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16417 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mj@mjturner.net Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 12:33:56PM -0400, Christoph Hellwig wrote: > Below is an untested patch to always just update the ctime: Just a quick update - the patch does the trick and changes the rename(2) behaviour to be what I expect. Now, when a directory is renamed, its mtime doesn't change, even if it has a new parent. -mj -- Michael-John Turner mj@mjturner.net <> http://mjturner.net/ From owner-xfs@oss.sgi.com Wed Jun 18 21:13:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 21:13: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.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5J4Dmnk001955 for ; Wed, 18 Jun 2008 21:13:51 -0700 X-ASG-Debug-ID: 1213848885-3e4002e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F05B217E5A72 for ; Wed, 18 Jun 2008 21:14:46 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id gUFA6OCxiaYg4qu8 for ; Wed, 18 Jun 2008 21:14:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPh4WUh5LG+u/2dsb2JhbACwMw X-IronPort-AV: E=Sophos;i="4.27,670,1204464600"; d="scan'208";a="129718666" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 19 Jun 2008 13:44:42 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K9BXl-0000Vt-GD; Thu, 19 Jun 2008 14:14:41 +1000 Date: Thu, 19 Jun 2008 14:14:41 +1000 From: Dave Chinner To: Marco Berizzi Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS: 2.6.26-rc6 link count mismatch for inode Subject: Re: XFS: 2.6.26-rc6 link count mismatch for inode Message-ID: <20080619041441.GW3700@disturbed> Mail-Followup-To: Marco Berizzi , linux-kernel@vger.kernel.org, xfs@oss.sgi.com References: <20080618161252.GV3700@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213848886 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.53705 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: 16418 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 06:39:59PM +0200, Marco Berizzi wrote: > Dave Chinner wrote: > > > On Mon, Jun 16, 2008 at 11:11:31AM +0200, Marco Berizzi wrote: > > > Hi Folk, > > > > > > I was tring to compile firefox 3.0rc3 > > > and while I was erasing a previous > > > /tmp/mozilla tree, I started a new > > > tar xjf mozilla-blabla. > > > After a while linux 2.6.26-rc6 was > > > unresponsive: I have unplugged the > > > power cable. No problem at startup, > > > but: > > > > What are your mount options? > > root@Venus:/etc# cat mtab > /dev/sda2 / xfs rw 0 0 > > root@Venus:/etc# cat fstab > /dev/sda2 / xfs defaults 1 1 [...] > XFS mounting filesystem sda2 > Ending clean XFS mount for filesystem: sda2 > VFS: Mounted root (xfs filesystem) readonly. > > > I ask because I've > > seen this sort of directory corruption before when using volatile > > write caches and yanking the power.... > > > > i.e. the corruption could have been caused by the way you reset the > > system, not because of the hang. Do you have any information on what > > caused the hang? > > The tar xf mozilla-source.tarball was not responding > nor writing anything on the disk. I did issue also a > kill -9 'pid of tar xf' but it did not want to die. > So I think the problem was on the filesystem before > the incorrect shutdown. Yeah, it sounds like the I/O subsystem hung somewhere. Without details I can't say what went wrong. If it happens again doing this: # echo w > /proc/sysrq-trigger To get a dump of all the blocked processes on the console. That may contain enough info to tell us what the problem is. > I can retry the test. Let me know if I can do a > xfs_repair. Sure, go ahead and fix it up. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jun 18 21:35:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 21:35:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5J4ZOfU003819 for ; Wed, 18 Jun 2008 21:35:27 -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 OAA08182; Thu, 19 Jun 2008 14:36:18 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 0B4A258C4C3F; Thu, 19 Jun 2008 14:36:17 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 981498 - Remove infinite loop from xfsidbg_xaildump Message-Id: <20080619043618.0B4A258C4C3F@chook.melbourne.sgi.com> Date: Thu, 19 Jun 2008 14:36:17 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) 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: 16419 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Remove infinite loop from xfsidbg_xaildump The 'for' loop is non-terminating as 'lip' cannot become NULL. Actually, the loop isn't even needed so remove it. Date: Thu Jun 19 13:56:47 AEST 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-agno2 Inspected by: xaiki Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31331a fs/xfs/xfsidbg.c - 1.352 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfsidbg.c.diff?r1=text&tr1=1.352&r2=text&tr2=1.351&f=h - Remove infinite loop from xfsidbg_xaildump From owner-xfs@oss.sgi.com Wed Jun 18 21:38:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 21:38:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5J4c8pY004344 for ; Wed, 18 Jun 2008 21:38:10 -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 OAA08227; Thu, 19 Jun 2008 14:39:03 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id A166B58C4C3F; Thu, 19 Jun 2008 14:39:03 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 983337 - fix extent corruption in xfs_iext_irec_compact_full() Message-Id: <20080619043903.A166B58C4C3F@chook.melbourne.sgi.com> Date: Thu, 19 Jun 2008 14:39:03 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) 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: 16420 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs fix extent corruption in xfs_iext_irec_compact_full() This function is used to compact the indirect extent list by moving extents from one page to the previous to fill them up. After we move some extents to an earlier page we need to shuffle the remaining extents to the start of the page. The actual bug here is the second argument to memmove() needs to index past the extents, that were copied to the previous page, and move the remaining extents. For pages that are already full (ie ext_avail == 0) the compaction code has no net effect so don't do it. Date: Thu Jun 19 14:38:15 AEST 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-agno2 Inspected by: hch Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31332a fs/xfs/xfs_inode.c - 1.506 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_inode.c.diff?r1=text&tr1=1.506&r2=text&tr2=1.505&f=h - fix extent corruption in xfs_iext_irec_compact_full() From owner-xfs@oss.sgi.com Wed Jun 18 22:27:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 22:27:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5J5R2tU008475 for ; Wed, 18 Jun 2008 22:27:03 -0700 X-ASG-Debug-ID: 1213853277-479a02700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zimbra.vpac.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5A2E0CEE3D6 for ; Wed, 18 Jun 2008 22:27:57 -0700 (PDT) Received: from zimbra.vpac.org (zimbra.vpac.org [202.158.218.6]) by cuda.sgi.com with ESMTP id FjB5dhCXdmKO6sdD for ; Wed, 18 Jun 2008 22:27:57 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.vpac.org (Postfix) with ESMTP id CBF9346D0182; Thu, 19 Jun 2008 15:27:56 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at Received: from zimbra.vpac.org ([127.0.0.1]) by localhost (zimbra.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr+DWNvk-4zM; Thu, 19 Jun 2008 15:27:48 +1000 (EST) Received: from [172.25.10.11] (firewall.vpac.org [202.158.218.253]) by zimbra.vpac.org (Postfix) with ESMTP id 5A6B546D01A0; Thu, 19 Jun 2008 15:27:48 +1000 (EST) Message-ID: <4859EE54.6050801@vpac.org> Date: Thu, 19 Jun 2008 15:27:48 +1000 From: Brian May User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 Followup-To: brian@vpac.org,xfs@oss.sgi.com To: xfs@oss.sgi.com X-ASG-Orig-Subj: open sleeps Subject: open sleeps Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: zimbra.vpac.org[202.158.218.6] X-Barracuda-Start-Time: 1213853278 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4993 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53710 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16421 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brian@vpac.org Precedence: bulk X-list: xfs Hello, I am having (weird) issues with XFS, in that open(...) on certain files takes 45 seconds to return. After the file has been opened, the next file in the same directory takes 45 seconds. If the file was recently opened it returns immediately. I thought this was a low level I/O issue, so copied the files in question to a completely independent RAID array (separate LVM, RAID, controllers, disks), but the problem remains. More details at thread starting from . Any ideas? Please CC me responses. Thanks. Brian May From owner-xfs@oss.sgi.com Wed Jun 18 22:29:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 22:29: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.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 m5J5TFwS009020 for ; Wed, 18 Jun 2008 22:29:16 -0700 X-ASG-Debug-ID: 1213853413-2294026a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zimbra.vpac.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 512BE17E5AD3 for ; Wed, 18 Jun 2008 22:30:13 -0700 (PDT) Received: from zimbra.vpac.org (zimbra.vpac.org [202.158.218.6]) by cuda.sgi.com with ESMTP id TeQoqjOOXRShOCYe for ; Wed, 18 Jun 2008 22:30:13 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.vpac.org (Postfix) with ESMTP id 8578E46D0195; Thu, 19 Jun 2008 15:30:12 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at Received: from zimbra.vpac.org ([127.0.0.1]) by localhost (zimbra.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rk7Mhs9Zd02Q; Thu, 19 Jun 2008 15:30:03 +1000 (EST) Received: from [172.25.10.11] (firewall.vpac.org [202.158.218.253]) by zimbra.vpac.org (Postfix) with ESMTP id 0D04146D0182; Thu, 19 Jun 2008 15:30:03 +1000 (EST) Message-ID: <4859EEDA.3060906@vpac.org> Date: Thu, 19 Jun 2008 15:30:02 +1000 From: Brian May User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Brian May CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: open sleeps Subject: Re: open sleeps References: <4859EE54.6050801@vpac.org> In-Reply-To: <4859EE54.6050801@vpac.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: zimbra.vpac.org[202.158.218.6] X-Barracuda-Start-Time: 1213853414 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4976 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53711 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16422 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brian@vpac.org Precedence: bulk X-list: xfs Sorry, repost with the weird Followup-To header (was hoping Thunderbird would use Mail-Followup-To but obviously not). Brian May wrote: > Hello, > > I am having (weird) issues with XFS, in that open(...) on certain > files takes 45 seconds to return. After the file has been opened, the > next file in the same directory takes 45 seconds. If the file was > recently opened it returns immediately. > > I thought this was a low level I/O issue, so copied the files in > question to a completely independent RAID array (separate LVM, RAID, > controllers, disks), but the problem remains. > > More details at thread starting from > . > > Any ideas? > > Please CC me responses. > > Thanks. > > Brian May From owner-xfs@oss.sgi.com Wed Jun 18 22:34:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 22:34: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 m5J5XwMa009941 for ; Wed, 18 Jun 2008 22:34:00 -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 PAA09349; Thu, 19 Jun 2008 15:34:50 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 5F57058C4C3F; Thu, 19 Jun 2008 15:34:50 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 983395 - fix warning for: simplify xfs_vn_listxattr Message-Id: <20080619053450.5F57058C4C3F@chook.melbourne.sgi.com> Date: Thu, 19 Jun 2008 15:34:50 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16423 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 Fix up 64bit warning for xfs_vn_listxattr's call of list_one_attr() with context count of ssize_t versus int. Change context count to be ssize_t. As suggested by hch. --Tim Date: Thu Jun 19 15:33:13 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: lachlan@sgi.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31333a fs/xfs/xfs_attr.h - 1.43 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.43&r2=text&tr2=1.42&f=h - Fix up warning for xfs_vn_listxattr's call of list_one_attr() with context count of ssize_t versus int. Change context count to be ssize_t. From owner-xfs@oss.sgi.com Wed Jun 18 23:12:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 23:12:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_61, J_CHICKENPOX_64 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 m5J6CjRO013306 for ; Wed, 18 Jun 2008 23:12:46 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA09988; Thu, 19 Jun 2008 16:13:39 +1000 Message-ID: <4859F9EB.5050505@sgi.com> Date: Thu, 19 Jun 2008 16:17:15 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH V2] Always reset btree cursor after an insert Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16424 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs After a btree insert operation a cursor can be invalid due to block splits and a maybe a new root block. We reset the cursor in xfs_bmbt_insert() in the cases where we think we need to but it isn't enough as we still see assertions. Just do what we do elsewhere and reset the cursor unconditionally. Version 2 adds XFS_WANT_CORRUPTED_GOTO checks throughout xfs_bmap.c and removes the fix to revalidate the original cursor in xfs_bmbt_insert(). Lachlan --- fs/xfs/xfs_bmap.c_1.392 2008-06-16 17:25:09.000000000 +1000 +++ fs/xfs/xfs_bmap.c 2008-06-19 16:07:47.000000000 +1000 @@ -428,7 +428,8 @@ xfs_bmap_add_attrfork_btree( cur->bc_private.b.firstblock = *firstblock; if ((error = xfs_bmbt_lookup_ge(cur, 0, 0, 0, &stat))) goto error0; - ASSERT(stat == 1); /* must be at least one entry */ + /* must be at least one entry */ + XFS_WANT_CORRUPTED_GOTO(stat == 1, error0); if ((error = xfs_bmbt_newroot(cur, flags, &stat))) goto error0; if (stat == 0) { @@ -816,13 +817,13 @@ xfs_bmap_add_extent_delay_real( RIGHT.br_startblock, RIGHT.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_delete(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_decrement(cur, 0, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, LEFT.br_startoff, LEFT.br_startblock, LEFT.br_blockcount + @@ -860,7 +861,7 @@ xfs_bmap_add_extent_delay_real( LEFT.br_startblock, LEFT.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, LEFT.br_startoff, LEFT.br_startblock, LEFT.br_blockcount + @@ -895,7 +896,7 @@ xfs_bmap_add_extent_delay_real( RIGHT.br_startblock, RIGHT.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, PREV.br_startoff, new->br_startblock, PREV.br_blockcount + @@ -928,11 +929,11 @@ xfs_bmap_add_extent_delay_real( new->br_startblock, new->br_blockcount, &i))) goto done; - ASSERT(i == 0); + XFS_WANT_CORRUPTED_GOTO(i == 0, done); cur->bc_rec.b.br_state = XFS_EXT_NORM; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } *dnew = 0; /* DELTA: The in-core extent described by new changed type. */ @@ -963,7 +964,7 @@ xfs_bmap_add_extent_delay_real( LEFT.br_startblock, LEFT.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, LEFT.br_startoff, LEFT.br_startblock, LEFT.br_blockcount + @@ -1004,11 +1005,11 @@ xfs_bmap_add_extent_delay_real( new->br_startblock, new->br_blockcount, &i))) goto done; - ASSERT(i == 0); + XFS_WANT_CORRUPTED_GOTO(i == 0, done); cur->bc_rec.b.br_state = XFS_EXT_NORM; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } if (ip->i_d.di_format == XFS_DINODE_FMT_EXTENTS && ip->i_d.di_nextents > ip->i_df.if_ext_max) { @@ -1054,7 +1055,7 @@ xfs_bmap_add_extent_delay_real( RIGHT.br_startblock, RIGHT.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, new->br_startoff, new->br_startblock, new->br_blockcount + @@ -1094,11 +1095,11 @@ xfs_bmap_add_extent_delay_real( new->br_startblock, new->br_blockcount, &i))) goto done; - ASSERT(i == 0); + XFS_WANT_CORRUPTED_GOTO(i == 0, done); cur->bc_rec.b.br_state = XFS_EXT_NORM; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } if (ip->i_d.di_format == XFS_DINODE_FMT_EXTENTS && ip->i_d.di_nextents > ip->i_df.if_ext_max) { @@ -1149,11 +1150,11 @@ xfs_bmap_add_extent_delay_real( new->br_startblock, new->br_blockcount, &i))) goto done; - ASSERT(i == 0); + XFS_WANT_CORRUPTED_GOTO(i == 0, done); cur->bc_rec.b.br_state = XFS_EXT_NORM; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } if (ip->i_d.di_format == XFS_DINODE_FMT_EXTENTS && ip->i_d.di_nextents > ip->i_df.if_ext_max) { @@ -1377,19 +1378,19 @@ xfs_bmap_add_extent_unwritten_real( RIGHT.br_startblock, RIGHT.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_delete(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_decrement(cur, 0, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_delete(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_decrement(cur, 0, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, LEFT.br_startoff, LEFT.br_startblock, LEFT.br_blockcount + PREV.br_blockcount + @@ -1426,13 +1427,13 @@ xfs_bmap_add_extent_unwritten_real( PREV.br_startblock, PREV.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_delete(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_decrement(cur, 0, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, LEFT.br_startoff, LEFT.br_startblock, LEFT.br_blockcount + PREV.br_blockcount, @@ -1469,13 +1470,13 @@ xfs_bmap_add_extent_unwritten_real( RIGHT.br_startblock, RIGHT.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_delete(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_decrement(cur, 0, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, new->br_startoff, new->br_startblock, new->br_blockcount + RIGHT.br_blockcount, @@ -1508,7 +1509,7 @@ xfs_bmap_add_extent_unwritten_real( new->br_startblock, new->br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, new->br_startoff, new->br_startblock, new->br_blockcount, newext))) @@ -1549,7 +1550,7 @@ xfs_bmap_add_extent_unwritten_real( PREV.br_startblock, PREV.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, PREV.br_startoff + new->br_blockcount, PREV.br_startblock + new->br_blockcount, @@ -1596,7 +1597,7 @@ xfs_bmap_add_extent_unwritten_real( PREV.br_startblock, PREV.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, PREV.br_startoff + new->br_blockcount, PREV.br_startblock + new->br_blockcount, @@ -1606,7 +1607,7 @@ xfs_bmap_add_extent_unwritten_real( cur->bc_rec.b = *new; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } /* DELTA: One in-core extent is split in two. */ temp = PREV.br_startoff; @@ -1640,7 +1641,7 @@ xfs_bmap_add_extent_unwritten_real( PREV.br_startblock, PREV.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, PREV.br_startoff, PREV.br_startblock, PREV.br_blockcount - new->br_blockcount, @@ -1682,7 +1683,7 @@ xfs_bmap_add_extent_unwritten_real( PREV.br_startblock, PREV.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, PREV.br_startoff, PREV.br_startblock, PREV.br_blockcount - new->br_blockcount, @@ -1692,11 +1693,11 @@ xfs_bmap_add_extent_unwritten_real( new->br_startblock, new->br_blockcount, &i))) goto done; - ASSERT(i == 0); + XFS_WANT_CORRUPTED_GOTO(i == 0, done); cur->bc_rec.b.br_state = XFS_EXT_NORM; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } /* DELTA: One in-core extent is split in two. */ temp = PREV.br_startoff; @@ -1732,7 +1733,7 @@ xfs_bmap_add_extent_unwritten_real( PREV.br_startblock, PREV.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); /* new right extent - oldext */ if ((error = xfs_bmbt_update(cur, r[1].br_startoff, r[1].br_startblock, r[1].br_blockcount, @@ -1744,15 +1745,22 @@ xfs_bmap_add_extent_unwritten_real( cur->bc_rec.b = PREV; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); - if ((error = xfs_bmbt_increment(cur, 0, &i))) + XFS_WANT_CORRUPTED_GOTO(i == 1, done); + /* + * Reset the cursor to the position of the new extent + * we are about to insert as we can't trust it after + * the previous insert. + */ + if ((error = xfs_bmbt_lookup_eq(cur, new->br_startoff, + new->br_startblock, new->br_blockcount, + &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 0, done); /* new middle extent - newext */ - cur->bc_rec.b = *new; + cur->bc_rec.b.br_state = new->br_state; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } /* DELTA: One in-core extent is split in three. */ temp = PREV.br_startoff; @@ -2097,13 +2105,13 @@ xfs_bmap_add_extent_hole_real( right.br_startblock, right.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_delete(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_decrement(cur, 0, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, left.br_startoff, left.br_startblock, left.br_blockcount + @@ -2139,7 +2147,7 @@ xfs_bmap_add_extent_hole_real( left.br_startblock, left.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, left.br_startoff, left.br_startblock, left.br_blockcount + @@ -2174,7 +2182,7 @@ xfs_bmap_add_extent_hole_real( right.br_startblock, right.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); if ((error = xfs_bmbt_update(cur, new->br_startoff, new->br_startblock, new->br_blockcount + @@ -2208,11 +2216,11 @@ xfs_bmap_add_extent_hole_real( new->br_startblock, new->br_blockcount, &i))) goto done; - ASSERT(i == 0); + XFS_WANT_CORRUPTED_GOTO(i == 0, done); cur->bc_rec.b.br_state = new->br_state; if ((error = xfs_bmbt_insert(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } /* DELTA: A new extent was added in a hole. */ temp = new->br_startoff; @@ -3131,7 +3139,7 @@ xfs_bmap_del_extent( got.br_startblock, got.br_blockcount, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } da_old = da_new = 0; } else { @@ -3164,7 +3172,7 @@ xfs_bmap_del_extent( } if ((error = xfs_bmbt_delete(cur, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); break; case 2: @@ -3268,7 +3276,7 @@ xfs_bmap_del_extent( got.br_startblock, temp, &i))) goto done; - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); /* * Update the btree record back * to the original value. @@ -3289,7 +3297,7 @@ xfs_bmap_del_extent( error = XFS_ERROR(ENOSPC); goto done; } - ASSERT(i == 1); + XFS_WANT_CORRUPTED_GOTO(i == 1, done); } else flags |= XFS_ILOG_FEXT(whichfork); XFS_IFORK_NEXT_SET(ip, whichfork, --- fs/xfs/xfs_bmap_btree.c_1.169 2008-06-16 17:25:10.000000000 +1000 +++ fs/xfs/xfs_bmap_btree.c 2008-06-19 16:12:43.000000000 +1000 @@ -2029,22 +2029,8 @@ xfs_bmbt_increment( * Insert the current record at the point referenced by cur. * * A multi-level split of the tree on insert will invalidate the original - * cursor. It appears, however, that some callers assume that the cursor is - * always valid. Hence if we do a multi-level split we need to revalidate the - * cursor. - * - * When a split occurs, we will see a new cursor returned. Use that as a - * trigger to determine if we need to revalidate the original cursor. If we get - * a split, then use the original irec to lookup up the path of the record we - * just inserted. - * - * Note that the fact that the btree root is in the inode means that we can - * have the level of the tree change without a "split" occurring at the root - * level. What happens is that the root is migrated to an allocated block and - * the inode root is pointed to it. This means a single split can change the - * level of the tree (level 2 -> level 3) and invalidate the old cursor. Hence - * the level change should be accounted as a split so as to correctly trigger a - * revalidation of the old cursor. + * cursor. All callers of this function should assume that the cursor is + * no longer valid and revalidate it. */ int /* error */ xfs_bmbt_insert( @@ -2057,14 +2043,11 @@ xfs_bmbt_insert( xfs_fsblock_t nbno; xfs_btree_cur_t *ncur; xfs_bmbt_rec_t nrec; - xfs_bmbt_irec_t oirec; /* original irec */ xfs_btree_cur_t *pcur; - int splits = 0; XFS_BMBT_TRACE_CURSOR(cur, ENTRY); level = 0; nbno = NULLFSBLOCK; - oirec = cur->bc_rec.b; xfs_bmbt_disk_set_all(&nrec, &cur->bc_rec.b); ncur = NULL; pcur = cur; @@ -2073,13 +2056,11 @@ xfs_bmbt_insert( &i))) { if (pcur != cur) xfs_btree_del_cursor(pcur, XFS_BTREE_ERROR); - goto error0; + XFS_BMBT_TRACE_CURSOR(cur, ERROR); + return error; } XFS_WANT_CORRUPTED_GOTO(i == 1, error0); if (pcur != cur && (ncur || nbno == NULLFSBLOCK)) { - /* allocating a new root is effectively a split */ - if (cur->bc_nlevels != pcur->bc_nlevels) - splits++; cur->bc_nlevels = pcur->bc_nlevels; cur->bc_private.b.allocated += pcur->bc_private.b.allocated; @@ -2093,21 +2074,10 @@ xfs_bmbt_insert( xfs_btree_del_cursor(pcur, XFS_BTREE_NOERROR); } if (ncur) { - splits++; pcur = ncur; ncur = NULL; } } while (nbno != NULLFSBLOCK); - - if (splits > 1) { - /* revalidate the old cursor as we had a multi-level split */ - error = xfs_bmbt_lookup_eq(cur, oirec.br_startoff, - oirec.br_startblock, oirec.br_blockcount, &i); - if (error) - goto error0; - ASSERT(i == 1); - } - XFS_BMBT_TRACE_CURSOR(cur, EXIT); *stat = i; return 0; From owner-xfs@oss.sgi.com Wed Jun 18 23:20:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 23:20:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5J6KV5q014464 for ; Wed, 18 Jun 2008 23:20:31 -0700 X-ASG-Debug-ID: 1213856488-15ea00920000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D879BCEE2CD for ; Wed, 18 Jun 2008 23:21:29 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id sfcEPtG1Nb3qTrNE for ; Wed, 18 Jun 2008 23:21:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAG+VWUh5LG+u/2dsb2JhbACwGw X-IronPort-AV: E=Sophos;i="4.27,671,1204464600"; d="scan'208";a="129810988" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 19 Jun 2008 15:51:19 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K9DWI-0003Al-7i; Thu, 19 Jun 2008 16:21:18 +1000 Date: Thu, 19 Jun 2008 16:21:18 +1000 From: Dave Chinner To: Brian May Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: open sleeps Subject: Re: open sleeps Message-ID: <20080619062118.GY3700@disturbed> Mail-Followup-To: Brian May , xfs@oss.sgi.com References: <4859EE54.6050801@vpac.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4859EE54.6050801@vpac.org> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213856489 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4932 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53714 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: 16425 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 Thu, Jun 19, 2008 at 03:27:48PM +1000, Brian May wrote: > Hello, > > I am having (weird) issues with XFS, in that open(...) on certain files > takes 45 seconds to return. After the file has been opened, the next > file in the same directory takes 45 seconds. If the file was recently > opened it returns immediately. > > I thought this was a low level I/O issue, so copied the files in > question to a completely independent RAID array (separate LVM, RAID, > controllers, disks), but the problem remains. > > More details at thread starting from > . > > Any ideas? # echo t > /proc/sysrq-trigger when it is hung to get a stack trace of the blocked open call. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jun 18 23:39:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 18 Jun 2008 23:39:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5J6dDGU017138 for ; Wed, 18 Jun 2008 23:39:13 -0700 X-ASG-Debug-ID: 1213857610-7d3b02b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zimbra.vpac.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3A1D4CEECA8 for ; Wed, 18 Jun 2008 23:40:10 -0700 (PDT) Received: from zimbra.vpac.org (zimbra.vpac.org [202.158.218.6]) by cuda.sgi.com with ESMTP id y8qoeG6JAAsT7xza for ; Wed, 18 Jun 2008 23:40:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.vpac.org (Postfix) with ESMTP id D771A46D0182; Thu, 19 Jun 2008 16:40:09 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at Received: from zimbra.vpac.org ([127.0.0.1]) by localhost (zimbra.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH42COS2oNZA; Thu, 19 Jun 2008 16:40:01 +1000 (EST) Received: from [172.25.10.11] (firewall.vpac.org [202.158.218.253]) by zimbra.vpac.org (Postfix) with ESMTP id 29D7946D0195; Thu, 19 Jun 2008 16:40:01 +1000 (EST) Message-ID: <4859FF40.8010206@vpac.org> Date: Thu, 19 Jun 2008 16:40:00 +1000 From: Brian May User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Brian May , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: open sleeps Subject: Re: open sleeps References: <4859EE54.6050801@vpac.org> <20080619062118.GY3700@disturbed> In-Reply-To: <20080619062118.GY3700@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: zimbra.vpac.org[202.158.218.6] X-Barracuda-Start-Time: 1213857611 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.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53714 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Status: Clean X-archive-position: 16426 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brian@vpac.org Precedence: bulk X-list: xfs Dave Chinner wrote: > On Thu, Jun 19, 2008 at 03:27:48PM +1000, Brian May wrote: > >> Hello, >> >> I am having (weird) issues with XFS, in that open(...) on certain files >> takes 45 seconds to return. After the file has been opened, the next >> file in the same directory takes 45 seconds. If the file was recently >> opened it returns immediately. >> >> I thought this was a low level I/O issue, so copied the files in >> question to a completely independent RAID array (separate LVM, RAID, >> controllers, disks), but the problem remains. >> >> More details at thread starting from >> . >> >> Any ideas? >> > > # echo t > /proc/sysrq-trigger > > when it is hung to get a stack trace of the blocked open call. > > Cheers, > > Dave. > Does the following help? I still have the logs of the other processes, if required (just in case it is some weird interaction between multiple processes?) It seems to be pretty consistent with lock_timer_base, every time I look (assuming I haven't read the stack trace upside down...). Jun 19 16:33:30 hq kernel: grep S 00000000 0 12793 12567 (NOTLB) Jun 19 16:33:30 hq kernel: f0c23e7c 00200082 000a1089 00000000 00000010 00000008 cd0db550 dfa97550 Jun 19 16:33:30 hq kernel: 34f84262 00273db2 0008a1dc 00000001 cd0db660 c20140a0 dfe1cbe8 00200286 Jun 19 16:33:30 hq kernel: c0125380 a4dbf26b dfa6a000 00200286 000000ff 00000000 00000000 a4dbf26b Jun 19 16:33:30 hq kernel: Call Trace: Jun 19 16:33:30 hq kernel: [] lock_timer_base+0x15/0x2f Jun 19 16:33:30 hq kernel: [] schedule_timeout+0x71/0x8c Jun 19 16:33:30 hq kernel: [] process_timeout+0x0/0x5 Jun 19 16:33:30 hq kernel: [] __break_lease+0x2a8/0x2b9 Jun 19 16:33:30 hq kernel: [] default_wake_function+0x0/0xc Jun 19 16:33:30 hq kernel: [] may_open+0x125/0x203 Jun 19 16:33:30 hq kernel: [] open_namei+0x23d/0x5c8 Jun 19 16:33:30 hq kernel: [] do_filp_open+0x1c/0x31 Jun 19 16:33:30 hq kernel: [] sys_stat64+0x1e/0x23 Jun 19 16:33:30 hq kernel: [] do_sys_open+0x3e/0xb3 Jun 19 16:33:30 hq kernel: [] sys_open+0x16/0x18 Jun 19 16:33:30 hq kernel: [] sysenter_past_esp+0x56/0x79 Jun 19 16:33:50 hq kernel: grep S 00000000 0 12793 12567 (NOTLB) Jun 19 16:33:50 hq kernel: f0c23e7c 00200082 000a1089 00000000 00000010 00000008 cd0db550 dfa97550 Jun 19 16:33:50 hq kernel: 34f84262 00273db2 0008a1dc 00000001 cd0db660 c20140a0 dfe1cbe8 00200286 Jun 19 16:33:50 hq kernel: c0125380 a4dbf26b dfa6a000 00200286 000000ff 00000000 00000000 a4dbf26b Jun 19 16:33:50 hq kernel: Call Trace: Jun 19 16:33:50 hq kernel: [] lock_timer_base+0x15/0x2f Jun 19 16:33:50 hq kernel: [] schedule_timeout+0x71/0x8c Jun 19 16:33:50 hq kernel: [] process_timeout+0x0/0x5 Jun 19 16:33:50 hq kernel: [] __break_lease+0x2a8/0x2b9 Jun 19 16:33:50 hq kernel: [] default_wake_function+0x0/0xc Jun 19 16:33:50 hq kernel: [] may_open+0x125/0x203 Jun 19 16:33:50 hq kernel: [] open_namei+0x23d/0x5c8 Jun 19 16:33:50 hq kernel: [] do_filp_open+0x1c/0x31 Jun 19 16:33:50 hq kernel: [] sys_stat64+0x1e/0x23 Jun 19 16:33:50 hq kernel: [] do_sys_open+0x3e/0xb3 Jun 19 16:33:50 hq kernel: [] sys_open+0x16/0x18 Jun 19 16:33:50 hq kernel: [] sysenter_past_esp+0x56/0x79 Thanks. Brian May From owner-xfs@oss.sgi.com Thu Jun 19 00:24:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 00:24:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_47,J_CHICKENPOX_48 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5J7OMjh000450 for ; Thu, 19 Jun 2008 00:24:23 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA11197; Thu, 19 Jun 2008 17:25:14 +1000 Message-ID: <485A0AB2.4060009@sgi.com> Date: Thu, 19 Jun 2008 17:28:50 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , Dave Chinner , xfs-dev , xfs-oss Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> In-Reply-To: <20080617073949.GP3700@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16427 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Tue, Jun 17, 2008 at 11:58:47AM +1000, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: >>>> I'm well aware of that particular deadlock involving the freelist - I >>>> hit it while testing. If you look closely at the code that deadlock >>>> can occur with or without the AG locking avoidance logic. This is >>>> because the rest of the transaction is unaware that an AG has been >>>> locked due to a freelist operation. >>> Yes, which is why you need to prevent freelist modifications occurring >>> when you can't allocate anything out of the AG. >> That sounds reasonable but it isn't consistent with the deadlock I saw. >> One of the threads that was deadlocked had tried to allocate a data extent >> in AG3 but didn't find the space. It had modified, and hence locked, AG3 >> due to modifying the freelist but since it didn't get the space it needed >> it had to go on to another AG. > > That sounds like an exact allocation failure - there is enough > space, a large enough extent but no free space at the exact block > required. This is exactly the case that occurred with the inode > allocation - and then allocation in the same AG failed because of > alignment that wasn't taken into account by the first exact > allocation attempt. Perhaps the minalignslop calculation in > xfs_bmap_btalloc() is incorrect... Okay I'll look into that. There's something else that looks suspicious to me - this code in xfs_bmap_btalloc() is setting minleft to 0. Doesn't this go against what you were saying about setting minleft to be the space we might need for the btree operations? if (args.fsbno == NULLFSBLOCK && nullfb) { args.fsbno = 0; args.type = XFS_ALLOCTYPE_FIRST_AG; args.total = ap->minlen; args.minleft = 0; if ((error = xfs_alloc_vextent(&args))) return error; ap->low = 1; } I see it sets a lowspace indicator which filters back up and into some btree operations. It appears the purpose of this feature is to allow allocations to search for space in other AGs as in this example from xfs_bmap_extents_to_btree(): if (*firstblock == NULLFSBLOCK) { args.type = XFS_ALLOCTYPE_START_BNO; args.fsbno = XFS_INO_TO_FSB(mp, ip->i_ino); } else if (flist->xbf_low) { args.type = XFS_ALLOCTYPE_START_BNO; args.fsbno = *firstblock; } else { args.type = XFS_ALLOCTYPE_NEAR_BNO; args.fsbno = *firstblock; } This is sort of what I was trying to do with my patch but without the special lowspace condition. This lowspace feature is probably broken because there was a similar special case in xfs_bmbt_split() that got removed with the changes that fixed the AG out-of-order locking problem. @@ -1569,12 +1569,11 @@ lbno = XFS_DADDR_TO_FSB(args.mp, XFS_BUF_ADDR(lbp)); left = XFS_BUF_TO_BMBT_BLOCK(lbp); args.fsbno = cur->bc_private.b.firstblock; + args.firstblock = args.fsbno; if (args.fsbno == NULLFSBLOCK) { args.fsbno = lbno; args.type = XFS_ALLOCTYPE_START_BNO; - } else if (cur->bc_private.b.flist->xbf_low) - args.type = XFS_ALLOCTYPE_FIRST_AG; - else + } else args.type = XFS_ALLOCTYPE_NEAR_BNO; args.mod = args.minleft = args.alignment = args.total = args.isfl = args.userdata = args.minalignslop = 0; This could be why we have allocations failing now. Maybe it should have been left in and XFS_ALLOCTYPE_FIRST_AG changed to XFS_ALLOCTYPE_START_BNO. But even then it could still fail because the AG deadlock avoidance code may prevent us from searching the AG that has the space we need. Should we ditch this lowspace special condition (and the code in xfs_bmap_btalloc()) and insist that all the space we need (using minleft) should come from one AG? > >> So before we even allocated the data extent >> (and before we tried to modify the btree, etc) we had an AG locked. The >> deadlock avoidance code in xfs_alloc_vextent() didn't know this because >> it only checks for a previous allocation. It makes sense that we should >> avoid modifying the freelist if there isn't enough space for the allocation >> so the puzzle is why didn't the code do that? > > Good question, and I think that is one we need to answer. > >>>> I considered that approach (using the minleft field in xfs_alloc_arg_t) >>>> but it has it's problems too. When we reserve space for the btree >>>> operations it is done on the global filesystem counters, not a >>>> particular AG, so there is the possibility that not one AG has sufficent >>>> space to perform the allocation even though there is enough free space >>>> in the whole filesystem. >>> Yes, we had that problem with the ENOSPC deadlock fixes in that we always >>> needed at least 4 blocks per AG available for a extent free to succeed. >>> Hence we have the XFS_ALLOC_SET_ASIDE() value for determining if the >>> filesystem is out of space, not a count of zero free blocks. >> Those 4 blocks are for one extent free operation, right? What if we have >> multiple threads all trying to do the same thing (in the same AG)? > > If we have empty AGF btrees we need to allocate two new root blocks, > and then we won't have to allocate any more btree blocks for the > next 100+ extent free operations... > > For allocations, the first would succeed, the rest would have to > search for another AG... > >>>> I'm worried with this approach that we could have delayed allocations and >>>> unwritten extents that need to be converted but we can't do it because we >>>> don't have the space we might need (but probably don't). >>> Delayed allocation is the issue - unwritten extent conversion failure will >>> simply return an error and leave the extent unwritten. >> That's still a problem though - if we can't convert unwritten extents then >> we can't clean dirty pages and we wont be able to unmount the filesystem. > > There will be errors logged and the extents will remain unwritten. > The filesystem should still be able to be unmounted. > So returning an error from unwritten extent conversion will not re-dirty the pages? So we effectively throw the user's data away? From owner-xfs@oss.sgi.com Thu Jun 19 01:20:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 01:20:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 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 m5J8Kdne006071 for ; Thu, 19 Jun 2008 01:20:41 -0700 X-ASG-Debug-ID: 1213863697-5bc402180000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bay0-omc3-s17.bay0.hotmail.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 58E00CF398C for ; Thu, 19 Jun 2008 01:21:37 -0700 (PDT) Received: from bay0-omc3-s17.bay0.hotmail.com (bay0-omc3-s17.bay0.hotmail.com [65.54.246.217]) by cuda.sgi.com with ESMTP id SSSnxwTbdAmCl98W for ; Thu, 19 Jun 2008 01:21:37 -0700 (PDT) Received: from hotmail.com ([65.54.174.82]) by bay0-omc3-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jun 2008 01:21:36 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 19 Jun 2008 01:21:36 -0700 Message-ID: Received: from 85.32.103.134 by BAY103-DAV10.phx.gbl with DAV; Thu, 19 Jun 2008 08:21:32 +0000 X-Originating-IP: [85.32.103.134] X-Originating-Email: [pupilla@hotmail.com] X-Sender: pupilla@hotmail.com From: "Marco Berizzi" To: "Dave Chinner" Cc: , References: <20080618161252.GV3700@disturbed> <20080619041441.GW3700@disturbed> X-ASG-Orig-Subj: Re: XFS: 2.6.26-rc6 link count mismatch for inode Subject: Re: XFS: 2.6.26-rc6 link count mismatch for inode Date: Thu, 19 Jun 2008 10:20:56 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1123 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1123 X-OriginalArrivalTime: 19 Jun 2008 08:21:36.0561 (UTC) FILETIME=[7DA30210:01C8D1E5] X-Barracuda-Connect: bay0-omc3-s17.bay0.hotmail.com[65.54.246.217] X-Barracuda-Start-Time: 1213863698 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0193 1.0000 -1.8957 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.90 X-Barracuda-Spam-Status: No, SCORE=-1.90 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MSGID_FROM_MTA_HEADER X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53714 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MSGID_FROM_MTA_HEADER Message-Id was added by a relay X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16429 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pupilla@hotmail.com Precedence: bulk X-list: xfs Dave Chinner wrote: > Yeah, it sounds like the I/O subsystem hung somewhere. Without > details I can't say what went wrong. If it happens again doing > this: > > # echo w > /proc/sysrq-trigger ok, thanks for the tip. > To get a dump of all the blocked processes on the console. That > may contain enough info to tell us what the problem is. > > Sure, go ahead and fix it up. right now, I'm not able to reproduce the bug anymore. Thanks for the support Dave. BTW, this is the xfs_repair output: Phase 1 - find and verify superblock... Phase 2 - using internal log - zero log... - scan filesystem freespace and inode maps... - found root inode chunk Phase 3 - for each AG... - scan and clear agi unlinked lists... - process known inodes and perform inode discovery... - agno = 0 b77dcb90: Badness in key lookup (length) bp=(bno 5280, len 16384 bytes) key=(bno 5280, len 8192 bytes) imap claims a free inode 70353 is in use, correcting imap and clearing inode cleared inode 70353 imap claims a free inode 98831 is in use, correcting imap and clearing inode cleared inode 98831 b5659b90: Badness in key lookup (length) bp=(bno 5655872, len 16384 bytes) key=(bno 5655872, len 8192 bytes) - agno = 1 b4bffb90: Badness in key lookup (length) bp=(bno 10238304, len 16384 bytes) key=(bno 10238304, len 8192 bytes) - agno = 2 - agno = 3 - agno = 4 - agno = 5 imap claims a free inode 85450805 is in use, correcting imap and clearing inode cleared inode 85450805 imap claims a free inode 85450806 is in use, correcting imap and clearing inode cleared inode 85450806 imap claims a free inode 85450807 is in use, correcting imap and clearing inode cleared inode 85450807 imap claims a free inode 85450808 is in use, correcting imap and clearing inode cleared inode 85450808 imap claims a free inode 85450809 is in use, correcting imap and clearing inode cleared inode 85450809 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 entry ".deps" in shortform directory 19893187 references free inode 70353 junking entry ".deps" in directory inode 19893187 - agno = 2 - agno = 3 - agno = 4 - agno = 5 entry "CVS" in shortform directory 67179727 references free inode 85450805 junking entry "CVS" in directory inode 67179727 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 Phase 5 - rebuild AG headers and trees... - reset superblock... Phase 6 - check inode connectivity... - resetting contents of realtime bitmap and summary inodes - traversing filesystem ... - traversal finished ... - moving disconnected inodes to lost+found ... disconnected inode 10573, moving to lost+found disconnected inode 18086534, moving to lost+found disconnected inode 18086535, moving to lost+found disconnected inode 34026152, moving to lost+found Phase 7 - verify and correct link counts... resetting inode 19893187 nlinks from 3 to 2 resetting inode 67179727 nlinks from 3 to 2 done From owner-xfs@oss.sgi.com Thu Jun 19 01:20:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 01:20:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=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 m5J8KQ0w006008 for ; Thu, 19 Jun 2008 01:20:27 -0700 X-ASG-Debug-ID: 1213863684-4fae02de0000-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 53BD3CF3985 for ; Thu, 19 Jun 2008 01:21:24 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id wtfXlQyVXUA9WBju for ; Thu, 19 Jun 2008 01:21:24 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K9FOW-0007rR-EW; Thu, 19 Jun 2008 08:21:24 +0000 Date: Thu, 19 Jun 2008 04:21:24 -0400 From: Christoph Hellwig To: Michael-John Turner Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Directory mtime update issue (kernel 2.6.25) Subject: Re: Directory mtime update issue (kernel 2.6.25) Message-ID: <20080619082124.GA24076@infradead.org> References: <20080618144534.GC11301@aurora.pimp.org.za> <20080618163356.GA6330@infradead.org> <20080618191045.GA10722@aurora.pimp.org.za> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080618191045.GA10722@aurora.pimp.org.za> 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: 1213863685 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.53714 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: 16428 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 08:10:45PM +0100, Michael-John Turner wrote: > Thanks for the prompt reply and the patch. I'm surprised this hasn't been > mentioned before as every other Unix filesystem I've used has not updated > the moved file's mtime during a rename(2). It's also odd that XFS only > changes the mtime when there's a new parent. > > What does everyone else think? Would it be possible to have this patch or a > similar one committed upstream? The patch also passes xfsqa, so it should be ready now. From owner-xfs@oss.sgi.com Thu Jun 19 01:31:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 01:31:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5J8Vj2o007779 for ; Thu, 19 Jun 2008 01:31:45 -0700 X-ASG-Debug-ID: 1213864363-36c402ad0000-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 7B5F424B204; Thu, 19 Jun 2008 01:32:43 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id jVfRtnH30Y9CANN2; Thu, 19 Jun 2008 01:32:43 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K9FZT-0004VJ-Dp; Thu, 19 Jun 2008 08:32:43 +0000 Date: Thu, 19 Jun 2008 04:32:43 -0400 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: [PATCH] XFS: Fix returning case-preserved name with CI node form directories Subject: Re: [PATCH] XFS: Fix returning case-preserved name with CI node form directories Message-ID: <20080619083243.GA8821@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: 1213864364 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.53719 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: 16430 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Jun 18, 2008 at 07:07:59PM +1000, Barry Naujok wrote: > xfs_dir2_node_lookup() calls xfs_da_node_lookup_int() which iterates > through leaf blocks containing the matching hash value for the name > being looked up. Inside xfs_da_node_lookup_int(), it calls the > xfs_dir2_leafn_lookup_for_entry() for each leaf block. > xfs_dir2_leafn_lookup_for_entry() iterates through each matching > hash/offset pair doing a name comparison to find the matching > dirent. > > For CI mode, the state->extrablk retains the details of the block > that has the CI match so xfs_dir2_node_lookup() can return the > case-preserved name. > > The original implementation didn't retain the xfs_da_buf_t properly, > so the lookup was returning a bogus name to be stored in the dentry. > > In the case of unlink, the bad name was passed and in debug mode, > ASSERTed when it can't find the entry. Looks good to me, although I don't really like how much of a mess xfs_dir2_leafn_lookup_for_entry has become. No idea for a nice why to write it, though. Btw, any chance we could get some CI tests in xfsqa? Looks like you have quite a few testcases that found issues so far. From owner-xfs@oss.sgi.com Thu Jun 19 01:34:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 01:34:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5J8YlgL008399 for ; Thu, 19 Jun 2008 01:34:47 -0700 X-ASG-Debug-ID: 1213864544-7c4d00f70000-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 8097DCF579E; Thu, 19 Jun 2008 01:35:44 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id zbKDEaPxXu83prmU; Thu, 19 Jun 2008 01:35:44 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K9FcO-00068d-Im; Thu, 19 Jun 2008 08:35:44 +0000 Date: Thu, 19 Jun 2008 04:35:44 -0400 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH V2] Always reset btree cursor after an insert Subject: Re: [PATCH V2] Always reset btree cursor after an insert Message-ID: <20080619083544.GA19606@infradead.org> References: <4859F9EB.5050505@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4859F9EB.5050505@sgi.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213864545 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.53714 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: 16431 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 Thu, Jun 19, 2008 at 04:17:15PM +1000, Lachlan McIlroy wrote: > After a btree insert operation a cursor can be invalid due to block > splits and a maybe a new root block. We reset the cursor in > xfs_bmbt_insert() in the cases where we think we need to but it > isn't enough as we still see assertions. Just do what we do elsewhere > and reset the cursor unconditionally. Version 2 adds > XFS_WANT_CORRUPTED_GOTO checks throughout xfs_bmap.c and removes the > fix to revalidate the original cursor in xfs_bmbt_insert(). Can you commit the XFS_WANT_CORRUPTED_GOTO checks as a separate patch before the cursor reset? ACK from me for those hunks. From owner-xfs@oss.sgi.com Thu Jun 19 01:36:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 01:36:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5J8aDT8008846 for ; Thu, 19 Jun 2008 01:36:14 -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 SAA12536; Thu, 19 Jun 2008 18:37:04 +1000 Date: Thu, 19 Jun 2008 18:39:55 +1000 To: "Christoph Hellwig" Subject: Re: [PATCH] XFS: Fix returning case-preserved name with CI node form directories 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: <20080619083243.GA8821@infradead.org> Content-Transfer-Encoding: 7bit Message-ID: In-Reply-To: <20080619083243.GA8821@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 X-archive-position: 16432 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 Thu, 19 Jun 2008 18:32:43 +1000, Christoph Hellwig wrote: > On Wed, Jun 18, 2008 at 07:07:59PM +1000, Barry Naujok wrote: >> xfs_dir2_node_lookup() calls xfs_da_node_lookup_int() which iterates >> through leaf blocks containing the matching hash value for the name >> being looked up. Inside xfs_da_node_lookup_int(), it calls the >> xfs_dir2_leafn_lookup_for_entry() for each leaf block. >> xfs_dir2_leafn_lookup_for_entry() iterates through each matching >> hash/offset pair doing a name comparison to find the matching >> dirent. >> >> For CI mode, the state->extrablk retains the details of the block >> that has the CI match so xfs_dir2_node_lookup() can return the >> case-preserved name. >> >> The original implementation didn't retain the xfs_da_buf_t properly, >> so the lookup was returning a bogus name to be stored in the dentry. >> >> In the case of unlink, the bad name was passed and in debug mode, >> ASSERTed when it can't find the entry. > > Looks good to me, although I don't really like how much of a mess > xfs_dir2_leafn_lookup_for_entry has become. No idea for a nice why > to write it, though. Yeah, bit of a problem with that. I can un-optimise the original code by not keeping the current block between calls to xfs_dir2_leafn_lookup_for_entry() and always freeing it. That will clean it up a lot. > Btw, any chance we could get some CI tests in xfsqa? Looks like you > have quite a few testcases that found issues so far. Yes, they are coming. Barry. From owner-xfs@oss.sgi.com Thu Jun 19 01:42:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 01:42:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5J8gDAe009695 for ; Thu, 19 Jun 2008 01:42:14 -0700 X-ASG-Debug-ID: 1213864992-7c4d01490000-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 709C2CEE67A for ; Thu, 19 Jun 2008 01:43:12 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id RpSrxWZbacNHQUc6 for ; Thu, 19 Jun 2008 01:43:12 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1K9Fjb-00035o-CA; Thu, 19 Jun 2008 08:43:11 +0000 Date: Thu, 19 Jun 2008 04:43:11 -0400 From: Christoph Hellwig To: Brian May Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: open sleeps Subject: Re: open sleeps Message-ID: <20080619084311.GA16736@infradead.org> References: <4859EE54.6050801@vpac.org> <20080619062118.GY3700@disturbed> <4859FF40.8010206@vpac.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4859FF40.8010206@vpac.org> User-Agent: Mutt/1.5.17 (2007-11-01) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1213864992 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.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53722 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 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: 16433 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 Thu, Jun 19, 2008 at 04:40:00PM +1000, Brian May wrote: > Does the following help? I still have the logs of the other processes, if > required (just in case it is some weird interaction between multiple > processes?) > > It seems to be pretty consistent with lock_timer_base, every time I look > (assuming I haven't read the stack trace upside down...). > > Jun 19 16:33:30 hq kernel: grep S 00000000 0 12793 12567 (NOTLB) > > Jun 19 16:33:30 hq kernel: f0c23e7c 00200082 000a1089 00000000 > 00000010 00000008 cd0db550 dfa97550 > Jun 19 16:33:30 hq kernel: 34f84262 00273db2 0008a1dc 00000001 > cd0db660 c20140a0 dfe1cbe8 00200286 > Jun 19 16:33:30 hq kernel: c0125380 a4dbf26b dfa6a000 00200286 > 000000ff 00000000 00000000 a4dbf26b > Jun 19 16:33:30 hq kernel: Call Trace: > > Jun 19 16:33:30 hq kernel: [] lock_timer_base+0x15/0x2f > > Jun 19 16:33:30 hq kernel: [] schedule_timeout+0x71/0x8c > > Jun 19 16:33:30 hq kernel: [] process_timeout+0x0/0x5 > > Jun 19 16:33:30 hq kernel: [] __break_lease+0x2a8/0x2b9 That's the lease breaking code in the VFS, long before we call into XFS. Looks like someone (samba?) has a least on this file and we're having trouble having it broken. Try sending a report about this to linux-fsdevel@vger.kernel.org From owner-xfs@oss.sgi.com Thu Jun 19 02:47:33 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 02:47: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=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 m5J9lX6w016426 for ; Thu, 19 Jun 2008 02:47:33 -0700 X-ASG-Debug-ID: 1213868910-480602a30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from relay.ihostexchange.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AC87717EEE25 for ; Thu, 19 Jun 2008 02:48:30 -0700 (PDT) Received: from relay.ihostexchange.net (hub103.ihostexchange.net [66.46.182.53]) by cuda.sgi.com with ESMTP id mhous10zEjGp9xua for ; Thu, 19 Jun 2008 02:48:30 -0700 (PDT) Received: from VMBX103.ihostexchange.net ([192.168.3.3]) by HUB103.ihostexchange.net ([192.168.4.3]) with mapi; Thu, 19 Jun 2008 05:50:47 -0400 From: Sebastian Brings To: "xfs@oss.sgi.com" Date: Thu, 19 Jun 2008 05:48:28 -0400 X-ASG-Orig-Subj: RE: open sleeps Subject: RE: open sleeps Thread-Topic: open sleeps Thread-Index: AcjR6OaTzUVNwjE2QXyam8WFCInnggACGDQQ Message-ID: <5948362D99F6F145B37A7D45B5DDA448072B3F00D7@VMBX103.ihostexchange.net> References: <4859EE54.6050801@vpac.org> <20080619062118.GY3700@disturbed> <4859FF40.8010206@vpac.org> <20080619084311.GA16736@infradead.org> In-Reply-To: <20080619084311.GA16736@infradead.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Barracuda-Connect: hub103.ihostexchange.net[66.46.182.53] X-Barracuda-Start-Time: 1213868911 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3170 1.0000 -0.2778 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.22 X-Barracuda-Spam-Status: No, SCORE=0.22 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53727 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 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 m5J9lX6w016428 X-archive-position: 16434 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sbrings@silexmedia.com Precedence: bulk X-list: xfs > -----Original Message----- > From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] > On Behalf Of Christoph Hellwig > Sent: Donnerstag, 19. Juni 2008 10:43 > To: Brian May > Cc: xfs@oss.sgi.com > Subject: Re: open sleeps > > On Thu, Jun 19, 2008 at 04:40:00PM +1000, Brian May wrote: > > Does the following help? I still have the logs of the other > processes, if > > required (just in case it is some weird interaction between multiple > > processes?) > > > > It seems to be pretty consistent with lock_timer_base, > every time I look > > (assuming I haven't read the stack trace upside down...). > > > > Jun 19 16:33:30 hq kernel: grep S 00000000 0 > 12793 12567 (NOTLB) > > > > Jun 19 16:33:30 hq kernel: f0c23e7c 00200082 > 000a1089 00000000 > > 00000010 00000008 cd0db550 dfa97550 > > Jun 19 16:33:30 hq kernel: 34f84262 00273db2 > 0008a1dc 00000001 > > cd0db660 c20140a0 dfe1cbe8 00200286 > > Jun 19 16:33:30 hq kernel: c0125380 a4dbf26b > dfa6a000 00200286 > > 000000ff 00000000 00000000 a4dbf26b > > Jun 19 16:33:30 hq kernel: Call Trace: > > > > Jun 19 16:33:30 hq kernel: [] lock_timer_base+0x15/0x2f > > > > Jun 19 16:33:30 hq kernel: [] schedule_timeout+0x71/0x8c > > > > Jun 19 16:33:30 hq kernel: [] process_timeout+0x0/0x5 > > > > Jun 19 16:33:30 hq kernel: [] __break_lease+0x2a8/0x2b9 > > That's the lease breaking code in the VFS, long before we call > into XFS. Looks like someone (samba?) has a least on this file and > we're having trouble having it broken. Try sending a report about > this to linux-fsdevel@vger.kernel.org > > For curiosity: Is the lease breaking you mention breaking a kernel oplock samba may hold? From owner-xfs@oss.sgi.com Thu Jun 19 12:25:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 12:25:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=BAYES_40,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5JJP1bl027509 for ; Thu, 19 Jun 2008 12:25:01 -0700 X-ASG-Debug-ID: 1213903559-7c1e00580000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from graphics.sendsations.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1718ECFF398 for ; Thu, 19 Jun 2008 12:25:59 -0700 (PDT) Received: from graphics.sendsations.com (graphics.sendsations.com [70.97.166.26]) by cuda.sgi.com with ESMTP id kX7OGJGkIMY1jsDv for ; Thu, 19 Jun 2008 12:25:59 -0700 (PDT) Received: from [127.0.0.1] ([10.0.0.229]) by graphics.sendsations.com (8.13.7/8.13.4) with ESMTP id m5JJPvHR011233 for ; Thu, 19 Jun 2008 13:25:58 -0600 Message-ID: <485AB312.4040608@gmail.com> Date: Thu, 19 Jun 2008 13:27:14 -0600 From: Ashley Oviatt User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair Subject: xfs_repair X-Barracuda-Connect: graphics.sendsations.com[70.97.166.26] X-Barracuda-Start-Time: 1213903560 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0100 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.96 X-Barracuda-Spam-Status: No, SCORE=0.96 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_10_20, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53766 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.94 HTML_10_20 BODY: Message is 10% to 20% HTML X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1708 X-archive-position: 16435 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ashovi@gmail.com Precedence: bulk X-list: xfs I am having the same problem as the person in this thread (Which problem is xfs_repair has been running for 16 hours on a 1 TB raid array): http://www.linux.sgi.com/archives/xfs/2007-03/msg00061.html It gave the same errors as this thread, saying that it could not use any of the super blocks it found. The last email in the thread says: ----------------------------------------- xfs-repair did find candidate secondary superblocks - it discarded them for some reason or another. If they were ok, all repair would have done is copied them to block zero and then continued. I'm suggesting that you manually do this step, and then see if repair will run. >/ Before wrapping this up, if you could just clarify a couple things. If I/ >/ look at the bytes at the beginning of each physical part of the LVM's,/ >/ what am I looking for? "XFSB"?/ yes. >/ If I do find that byte string, why/ >/ couldn't xfs_repair find it when it did the scan and what do I do with it/ >/ if I do find one?/ As I said above, xfs-repair did find some, but rejected them for some (unknown) reason. if you find one, copy it over block zero of the partition, and see if repair will run. Like I said, though, you'll probably want to back up th partition first, or at least run repair in no-modify mode. -------------------------------------- The poster, Dave Chinner, says to manually copy the superblock to the right place, but not how to do it. I am familiar with dd, but would like to know the exact command or steps to take to replace the primary superblock manually with a secondary superblock. I am using slackware linux 10 with an intel raid card. Ashley [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Jun 19 14:55:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 14:55:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5JLtm9k013101 for ; Thu, 19 Jun 2008 14:55:49 -0700 X-ASG-Debug-ID: 1213912605-493202e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from realtouchweb.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8768BCFFF4A for ; Thu, 19 Jun 2008 14:56:46 -0700 (PDT) Received: from realtouchweb.com (realtouchweb.com [161.58.239.72]) by cuda.sgi.com with ESMTP id 9lNIFwpWisD0bcMa for ; Thu, 19 Jun 2008 14:56:46 -0700 (PDT) Received: from [127.0.0.1] (graphics.sendsations.com [70.97.166.26]) by realtouchweb.com (8.12.11.20060614) id m5JLuhTI026682; Thu, 19 Jun 2008 15:56:44 -0600 (MDT) Message-ID: <485AD667.1060402@qwest.net> Date: Thu, 19 Jun 2008 15:57:59 -0600 From: Ash User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: xfs_repair taking a long time Subject: xfs_repair taking a long time Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: realtouchweb.com[161.58.239.72] X-Barracuda-Start-Time: 1213912607 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0100 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.01 X-Barracuda-Spam-Status: No, SCORE=0.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53776 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: 16436 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ashovi@qwest.net Precedence: bulk X-list: xfs I am having the same problem as the person in this thread: Which is xfs_repair has been running for 16 hours on a 1 TB raid array. It gave the same errors as this thread, saying that it could not use any of the super blocks it found. The last email in the thread says: ----------------------------------------- xfs-repair did find candidate secondary superblocks - it discarded them for some reason or another. If they were ok, all repair would have done is copied them to block zero and then continued. I'm suggesting that you manually do this step, and then see if repair will run. > Before wrapping this up, if you could just clarify a couple things. If I > look at the bytes at the beginning of each physical part of the LVM's, > what am I looking for? "XFSB"? yes. > If I do find that byte string, why > couldn't xfs_repair find it when it did the scan and what do I do with it > if I do find one? As I said above, xfs-repair did find some, but rejected them for some (unknown) reason. if you find one, copy it over block zero of the partition, and see if repair will run. Like I said, though, you'll probably want to back up th partition first, or at least run repair in no-modify mode. -------------------------------------- The poster, Dave Chinner, says to manually copy the superblock to the right place, but not how to do it. I am familiar with dd, but would like to know the exact command or steps to take to replace the primary superblock manually with a secondary superblock. Ashley (I sent this earlier but I haven't seen it come over the list yet, so I'll send it again. Please forgive the duplicate.) From owner-xfs@oss.sgi.com Thu Jun 19 18:07:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 18:08:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5K17s2i007867 for ; Thu, 19 Jun 2008 18:07:55 -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 LAA02080; Fri, 20 Jun 2008 11:08:48 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 8977858C4C3F; Fri, 20 Jun 2008 11:08:48 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 981498 - Merge xfs_rmdir into xfs_remove Message-Id: <20080620010848.8977858C4C3F@chook.melbourne.sgi.com> Date: Fri, 20 Jun 2008 11:08:48 +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: 16437 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 Merge xfs_rmdir into xfs_remove xfs_remove and xfs_rmdir are almost the same with a little more work performed in xfs_rmdir due to the . and .. entries. This patch merges xfs_rmdir into xfs_remove and performs these actions conditionally. Also clean up the error handling which was a nightmare in both versions before. Signed-off-by: Christoph Hellwig Date: Fri Jun 20 11:07:57 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31335a fs/xfs/xfs_vnodeops.c - 1.762 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.c.diff?r1=text&tr1=1.762&r2=text&tr2=1.761&f=h - Merge xfs_remove and xfs_rmdir fs/xfs/linux-2.6/xfs_iops.c - 1.290 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.290&r2=text&tr2=1.289&f=h - Merge xfs_vn_rmdir and xfs_vn_unlink fs/xfs/xfs_vnodeops.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vnodeops.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h - Merge xfs_remove and xfs_rmdir From owner-xfs@oss.sgi.com Thu Jun 19 18:11:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 18:11:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5K1B8i9008519 for ; Thu, 19 Jun 2008 18:11:09 -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 LAA02134; Fri, 20 Jun 2008 11:12:03 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 2D3C758C4C3F; Fri, 20 Jun 2008 11:12:03 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 981498 - Don't update i_size for directories and special files Message-Id: <20080620011203.2D3C758C4C3F@chook.melbourne.sgi.com> Date: Fri, 20 Jun 2008 11:12:03 +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: 16438 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 Don't update i_size for directories and special files The core kernel uses vfs_getattr to look at the inode size and similar attributes, so there is no need to keep i_size uptodate for directories or special files. This means we can remove xfs_validate_fields because the I/O path already keeps i_size uptodate for regular files. Signed-off-by: Christoph Hellwig Date: Fri Jun 20 11:11:11 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/2.6.x-xfs Inspected by: bnaujok The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31336a fs/xfs/linux-2.6/xfs_iops.c - 1.291 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_iops.c.diff?r1=text&tr1=1.291&r2=text&tr2=1.290&f=h - Don't update i_size for directories and special files From owner-xfs@oss.sgi.com Thu Jun 19 18:14:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 18:14:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5K1Eg4H009411 for ; Thu, 19 Jun 2008 18:14:43 -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 LAA02313; Fri, 20 Jun 2008 11:15:37 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 2E01958C4C3F; Fri, 20 Jun 2008 11:15:37 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 983284 - Assertion failure in node form directory lookup in CI mode Message-Id: <20080620011537.2E01958C4C3F@chook.melbourne.sgi.com> Date: Fri, 20 Jun 2008 11:15:37 +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: 16439 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 returning case-preserved name with CI node form directories xfs_dir2_node_lookup() calls xfs_da_node_lookup_int() which iterates through leaf blocks containing the matching hash value for the name being looked up. Inside xfs_da_node_lookup_int(), it calls the xfs_dir2_leafn_lookup_for_entry() for each leaf block. xfs_dir2_leafn_lookup_for_entry() iterates through each matching hash/offset pair doing a name comparison to find the matching dirent. For CI mode, the state->extrablk retains the details of the block that has the CI match so xfs_dir2_node_lookup() can return the case-preserved name. The original implementation didn't retain the xfs_da_buf_t properly, so the lookup was returning a bogus name to be stored in the dentry. In the case of unlink, the bad name was passed and in debug mode, ASSERTed when it can't find the entry. Date: Fri Jun 20 11:14:53 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31337a fs/xfs/xfs_dir2_node.c - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_node.c.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h - Fix returning case-preserved name with CI node form directories From owner-xfs@oss.sgi.com Thu Jun 19 18:38:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 18:38:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 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 m5K1bvuQ012226 for ; Thu, 19 Jun 2008 18:37:58 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA02734; Fri, 20 Jun 2008 11:38:49 +1000 Message-ID: <485B0B04.80808@sgi.com> Date: Fri, 20 Jun 2008 11:42:28 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs-dev , xfs-oss Subject: Re: [PATCH V2] Always reset btree cursor after an insert References: <4859F9EB.5050505@sgi.com> <20080619083544.GA19606@infradead.org> In-Reply-To: <20080619083544.GA19606@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16440 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Thu, Jun 19, 2008 at 04:17:15PM +1000, Lachlan McIlroy wrote: >> After a btree insert operation a cursor can be invalid due to block >> splits and a maybe a new root block. We reset the cursor in >> xfs_bmbt_insert() in the cases where we think we need to but it >> isn't enough as we still see assertions. Just do what we do elsewhere >> and reset the cursor unconditionally. Version 2 adds >> XFS_WANT_CORRUPTED_GOTO checks throughout xfs_bmap.c and removes the >> fix to revalidate the original cursor in xfs_bmbt_insert(). > > Can you commit the XFS_WANT_CORRUPTED_GOTO checks as a separate patch > before the cursor reset? ACK from me for those hunks. > Yeah, no problem, thanks. From owner-xfs@oss.sgi.com Thu Jun 19 18:47:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 18:47: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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5K1l3lR013537 for ; Thu, 19 Jun 2008 18:47:03 -0700 X-ASG-Debug-ID: 1213926479-032c012b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zimbra.vpac.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D0B87255384 for ; Thu, 19 Jun 2008 18:47:59 -0700 (PDT) Received: from zimbra.vpac.org (zimbra.vpac.org [202.158.218.6]) by cuda.sgi.com with ESMTP id rgZ7OJc6WAmD1LOX for ; Thu, 19 Jun 2008 18:47:59 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.vpac.org (Postfix) with ESMTP id 3A2BA46D019D; Fri, 20 Jun 2008 11:47:59 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at Received: from zimbra.vpac.org ([127.0.0.1]) by localhost (zimbra.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58vdrFVuU7We; Fri, 20 Jun 2008 11:47:51 +1000 (EST) Received: from [172.25.10.11] (firewall.vpac.org [202.158.218.253]) by zimbra.vpac.org (Postfix) with ESMTP id 4ECBC46D0182; Fri, 20 Jun 2008 11:47:51 +1000 (EST) Message-ID: <485B0C47.5060001@vpac.org> Date: Fri, 20 Jun 2008 11:47:51 +1000 From: Brian May User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: open sleeps Subject: Re: open sleeps References: <4859EE54.6050801@vpac.org> <20080619062118.GY3700@disturbed> <4859FF40.8010206@vpac.org> <20080619084311.GA16736@infradead.org> In-Reply-To: <20080619084311.GA16736@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: zimbra.vpac.org[202.158.218.6] X-Barracuda-Start-Time: 1213926480 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.12 X-Barracuda-Spam-Status: No, SCORE=-1.12 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, BSF_SC0_SA085b, INFO_TLD X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53793 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 INFO_TLD URI: Contains an URL in the INFO top-level domain 0.50 BSF_RULE7568M Custom Rule 7568M 0.40 BSF_SC0_SA085b Custom Rule SA085b X-Virus-Status: Clean X-archive-position: 16441 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brian@vpac.org Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Thu, Jun 19, 2008 at 04:40:00PM +1000, Brian May wrote: > >> Does the following help? I still have the logs of the other processes, if >> required (just in case it is some weird interaction between multiple >> processes?) >> >> It seems to be pretty consistent with lock_timer_base, every time I look >> (assuming I haven't read the stack trace upside down...). >> >> Jun 19 16:33:30 hq kernel: grep S 00000000 0 12793 12567 (NOTLB) >> >> Jun 19 16:33:30 hq kernel: f0c23e7c 00200082 000a1089 00000000 >> 00000010 00000008 cd0db550 dfa97550 >> Jun 19 16:33:30 hq kernel: 34f84262 00273db2 0008a1dc 00000001 >> cd0db660 c20140a0 dfe1cbe8 00200286 >> Jun 19 16:33:30 hq kernel: c0125380 a4dbf26b dfa6a000 00200286 >> 000000ff 00000000 00000000 a4dbf26b >> Jun 19 16:33:30 hq kernel: Call Trace: >> >> Jun 19 16:33:30 hq kernel: [] lock_timer_base+0x15/0x2f >> >> Jun 19 16:33:30 hq kernel: [] schedule_timeout+0x71/0x8c >> >> Jun 19 16:33:30 hq kernel: [] process_timeout+0x0/0x5 >> >> Jun 19 16:33:30 hq kernel: [] __break_lease+0x2a8/0x2b9 >> > > That's the lease breaking code in the VFS, long before we call > into XFS. Looks like someone (samba?) has a least on this file and > we're having trouble having it broken. Try sending a report about > this to linux-fsdevel@vger.kernel.org > I feel I am going around in circles. Anyway, I started the discussion from . In the last message (which isn't archived yet), I looked at the Samba process that is holding the lease. The following is the stack trace of this process. I don't understand why the XFS code is calling e1000 code, the filesystem isn't attached via the network. Perhaps this would mean the problem is with the network code??? Jun 20 10:54:37 hq kernel: smbd S 00000000 0 13516 11112 13459 (NOTLB) Jun 20 10:54:37 hq kernel: ddd19b70 00000082 034cdfca 00000000 00000001 00000007 f7c2c550 dfa9caa0 Jun 20 10:54:37 hq kernel: ae402975 002779a9 0000830f 00000003 f7c2c660 c20240a0 00000001 00000286 Jun 20 10:54:37 hq kernel: c0125380 a5d7f11b c2116000 00000286 000000ff 00000000 00000000 a5d7f11b Jun 20 10:54:37 hq kernel: Call Trace: Jun 20 10:54:37 hq kernel: [] lock_timer_base+0x15/0x2f Jun 20 10:54:37 hq kernel: [] schedule_timeout+0x71/0x8c Jun 20 10:54:37 hq kernel: [] process_timeout+0x0/0x5 Jun 20 10:54:37 hq kernel: [] do_select+0x37a/0x3d4 Jun 20 10:54:37 hq kernel: [] __pollwait+0x0/0xb2 Jun 20 10:54:37 hq kernel: [] default_wake_function+0x0/0xc Jun 20 10:54:37 hq kernel: [] default_wake_function+0x0/0xc Jun 20 10:54:37 hq kernel: [] e1000_xmit_frame+0x928/0x958 [e1000] Jun 20 10:54:37 hq kernel: [] tasklet_action+0x55/0xaf Jun 20 10:54:37 hq kernel: [] dev_hard_start_xmit+0x19a/0x1f0 Jun 20 10:54:37 hq kernel: [] xfs_iext_bno_to_ext+0xd8/0x191 [xfs] Jun 20 10:54:37 hq kernel: [] xfs_bmap_search_multi_extents+0xa8/0xc5 [xfs] Jun 20 10:54:37 hq kernel: [] xfs_bmap_search_extents+0x49/0xbe [xfs] Jun 20 10:54:37 hq kernel: [] xfs_bmapi+0x26e/0x20ce [xfs] Jun 20 10:54:37 hq kernel: [] xfs_bmapi+0x26e/0x20ce [xfs] Jun 20 10:54:37 hq kernel: [] tcp_transmit_skb+0x604/0x632 Jun 20 10:54:37 hq kernel: [] __tcp_push_pending_frames+0x6a2/0x758 Jun 20 10:54:37 hq kernel: [] __d_lookup+0x98/0xdb Jun 20 10:54:37 hq kernel: [] __d_lookup+0x98/0xdb Jun 20 10:54:37 hq kernel: [] do_lookup+0x4f/0x135 Jun 20 10:54:37 hq kernel: [] dput+0x1a/0x11b Jun 20 10:54:37 hq kernel: [] __link_path_walk+0xbe4/0xd1d Jun 20 10:54:37 hq kernel: [] core_sys_select+0x28c/0x2a9 Jun 20 10:54:37 hq kernel: [] link_path_walk+0xb3/0xbd Jun 20 10:54:37 hq kernel: [] xfs_inactive_free_eofblocks+0xdf/0x23f [xfs] Jun 20 10:54:37 hq kernel: [] do_path_lookup+0x20a/0x225 Jun 20 10:54:37 hq kernel: [] xfs_vn_getattr+0x27/0x2f [xfs] Jun 20 10:54:37 hq kernel: [] cp_new_stat64+0xfd/0x10f Jun 20 10:54:37 hq kernel: [] sys_select+0x9f/0x182 Jun 20 10:54:37 hq kernel: [] sysenter_past_esp+0x56/0x79 I guess I also need to make sure I get this same stack trace each time. Thanks. Brian May From owner-xfs@oss.sgi.com Thu Jun 19 18:57:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 18:57:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5K1vgcB014938 for ; Thu, 19 Jun 2008 18:57:43 -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 LAA03083; Fri, 20 Jun 2008 11:58:36 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 509CE58C4C3F; Fri, 20 Jun 2008 11:58:36 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 983500 - Convert ASSERTs to XFS_WANT_CORRUPTED_GOTOs Message-Id: <20080620015836.509CE58C4C3F@chook.melbourne.sgi.com> Date: Fri, 20 Jun 2008 11:58:36 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) 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: 16442 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Convert ASSERTs to XFS_WANT_CORRUPTED_GOTOs ASSERTs are no good to us on a non-debug build so use XFS_WANT_CORRUPTED_GOTOs to report extent btree corruption ASAP. Date: Fri Jun 20 11:57:41 AEST 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-agno2 Inspected by: hch Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31338a fs/xfs/xfs_bmap.c - 1.393 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.393&r2=text&tr2=1.392&f=h - Convert ASSERTs to XFS_WANT_CORRUPTED_GOTOs From owner-xfs@oss.sgi.com Thu Jun 19 19:45:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 19:45:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_74, 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 m5K2jYdS021084 for ; Thu, 19 Jun 2008 19:45:34 -0700 X-ASG-Debug-ID: 1213929991-75bb012c0000-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 CAD0A17F4B0E for ; Thu, 19 Jun 2008 19:46:32 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.240]) by cuda.sgi.com with ESMTP id e86tSCHC4XWu1ctf for ; Thu, 19 Jun 2008 19:46:32 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so5666923rvb.32 for ; Thu, 19 Jun 2008 19:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=4woE+Fbbu/zBvgPXfISn0bV6UNSjfD+SeeJHDg25s68=; b=FBtSfLn6Ucl42NbfFzbBe0mIH2KeE8veyCFNVIQsqHOlYvH5TulnyPIptFFI7U9qb/ qkkLqNltR/lkLR3OlAyUUbE4FQ/OVAeUd2K3TBZx4blZ332mK2WntY/cQMDM05XSTx39 /g5amPKsoEukvUfUmDvrETjRvhLLztv59W6KU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=iInw5XRSIJUA/chc5bKKbUQG5y4ZtEIEDARq7BxEAcr4U1x+AXQXd0nbVfpxxxneM9 6pk2xJNiAXL5ueVC/qeOxNclZn5sWsl2LZ6uKx0tOI2Bo86derTo075kJXVHpkvnDVxQ p1A55ILE5hGHvNL746mJFFUf8eeWGtSFX8uLw= Received: by 10.114.201.1 with SMTP id y1mr3662123waf.216.1213929991702; Thu, 19 Jun 2008 19:46:31 -0700 (PDT) Received: by 10.114.205.5 with HTTP; Thu, 19 Jun 2008 19:46:31 -0700 (PDT) Message-ID: Date: Thu, 19 Jun 2008 22:46:31 -0400 From: Simon To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair trouble Subject: Re: xfs_repair trouble Cc: "Barry Naujok" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 942486f565d241e0 X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.240] X-Barracuda-Start-Time: 1213929992 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4830 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53795 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: 16444 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: simonjj@gmail.com Precedence: bulk X-list: xfs Running xfs_metadump.sh will give me output below. Does all this mean it's best to think about alternatives to fixing/recovering these files? root@redlace:~/xfsprogs-trunk/xfs-cmds/xfsprogs/db# ./xfs_metadump.sh -g /dev/evms/monster_evms monster.dump Copied 320 of 112448 inodes (0 of 0 AGs) xfs_db: metadump.c:465: generate_obfuscated_name: Assertion `libxfs_da_hashname(newname, namelen) == hash' failed. ./xfs_metadump.sh: line 31: 17542 Aborted xfs_db$DBOPTS -i -p xfs_metadump -c "metadump$OPTS $2" $1 On Mon, Jun 16, 2008 at 12:47 AM, Barry Naujok wrote: > On Sun, 15 Jun 2008 02:43:12 +1000, Simon wrote: > >> Hello all, >> >> >> I have a corrupted xfs filesystem on top of a RAID 5 (1TB in size). >> The RAID is still fully intact but the filesystem was damaged. When >> trying to repair the filesystem xfs_repair fails. I have tried various >> versions of xfs_repair, the latest stable (2.9.8) and the latest trunk >> (from CVS). I'd love to investigate and/or fix the issue further but I >> am a bit confused about some of my xfs_repair runs (both done with >> trunk). >> Could someone shed some light on where the problem could be, I'd be >> happy to continue digging if I would only know where roughly > > Are you able to generate an xfs_metadump? If you can make that available, > I should be able to find out the problem pretty easily. > > Regards, > Barry. > From owner-xfs@oss.sgi.com Thu Jun 19 19:44:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 19:44:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_74 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 m5K2irbn020866 for ; Thu, 19 Jun 2008 19:44:53 -0700 X-ASG-Debug-ID: 1213929951-258500fe0000-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 BA0F9D01983 for ; Thu, 19 Jun 2008 19:45:51 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.245]) by cuda.sgi.com with ESMTP id mOWyYBypqD9EaSfM for ; Thu, 19 Jun 2008 19:45:51 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so5666777rvb.32 for ; Thu, 19 Jun 2008 19:45:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=QP/G6wuHbEUvmfU1TjxRan2vLd3g1OQ2gif53nD57XY=; b=fvvNbILuYxWrnpJEzkf9BP3zynREmVonxEcRWMp3He6xms3ZiUKdQ3FMdatgbSoelI 7jZL0dKwFDvjg0aG+cH99c/J7DdT5F8vQf74hPI8zl62srrLFjRalbklvwW17wX1oS1M oAW1B1k659FvdbhuNcDRmObUV64L9uilH4lRU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=VUr8aHIhaSNEg8Jv2+rdGGeAbWz/12Hccc3J4czs+9G7K/Y8fFZWaJeyb1b9TajvDF 2g1zIJfovDU+b4DWC9HAZvmbaWu6VH678s6/of+SRQ0cQe5o/Yyuub1b6EVW7UrFBWOf 5oVLdTosOncyb6mHTaTkcOkk5AIJbvs4vxt7Q= Received: by 10.114.144.1 with SMTP id r1mr3669162wad.136.1213929951058; Thu, 19 Jun 2008 19:45:51 -0700 (PDT) Received: by 10.114.205.5 with HTTP; Thu, 19 Jun 2008 19:45:50 -0700 (PDT) Message-ID: Date: Thu, 19 Jun 2008 22:45:50 -0400 From: "Simon Jakesch" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair trouble Subject: Re: xfs_repair trouble Cc: "Barry Naujok" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.245] X-Barracuda-Start-Time: 1213929951 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0995 1.0000 -1.3959 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.40 X-Barracuda-Spam-Status: No, SCORE=-1.40 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.53796 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: 16443 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: simon.jakesch@gmail.com Precedence: bulk X-list: xfs Running xfs_metadump.sh will give me output below. Does all this mean it's best to think about alternatives to fixing/recovering these files? root@redlace:~/xfsprogs-trunk/xfs-cmds/xfsprogs/db# ./xfs_metadump.sh -g /dev/evms/monster_evms monster.dump Copied 320 of 112448 inodes (0 of 0 AGs) xfs_db: metadump.c:465: generate_obfuscated_name: Assertion `libxfs_da_hashname(newname, namelen) == hash' failed. ./xfs_metadump.sh: line 31: 17542 Aborted xfs_db$DBOPTS -i -p xfs_metadump -c "metadump$OPTS $2" $1 On Mon, Jun 16, 2008 at 12:47 AM, Barry Naujok wrote: > On Sun, 15 Jun 2008 02:43:12 +1000, Simon wrote: > >> Hello all, >> >> >> I have a corrupted xfs filesystem on top of a RAID 5 (1TB in size). >> The RAID is still fully intact but the filesystem was damaged. When >> trying to repair the filesystem xfs_repair fails. I have tried various >> versions of xfs_repair, the latest stable (2.9.8) and the latest trunk >> (from CVS). I'd love to investigate and/or fix the issue further but I >> am a bit confused about some of my xfs_repair runs (both done with >> trunk). >> Could someone shed some light on where the problem could be, I'd be >> happy to continue digging if I would only know where roughly > > Are you able to generate an xfs_metadump? If you can make that available, > I should be able to find out the problem pretty easily. > > Regards, > Barry. > From owner-xfs@oss.sgi.com Thu Jun 19 20:36:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 20:36:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5K3aGUs032152 for ; Thu, 19 Jun 2008 20:36:16 -0700 X-ASG-Debug-ID: 1213933034-2585037b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C4DD71230958 for ; Thu, 19 Jun 2008 20:37:15 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id JsHB9fBywnJGq3sb for ; Thu, 19 Jun 2008 20:37:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALC/Wkh5LG+u/2dsb2JhbACwHA X-IronPort-AV: E=Sophos;i="4.27,676,1204464600"; d="scan'208";a="130501893" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 20 Jun 2008 13:07:12 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K9XR0-00046p-Fm; Fri, 20 Jun 2008 13:37:10 +1000 Date: Fri, 20 Jun 2008 13:37:10 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: Christoph Hellwig , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH V2] Always reset btree cursor after an insert Subject: Re: [PATCH V2] Always reset btree cursor after an insert Message-ID: <20080620033710.GZ3700@disturbed> Mail-Followup-To: Lachlan McIlroy , Christoph Hellwig , xfs-dev , xfs-oss References: <4859F9EB.5050505@sgi.com> <20080619083544.GA19606@infradead.org> <485B0B04.80808@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485B0B04.80808@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213933035 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.53800 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: 16445 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 20, 2008 at 11:42:28AM +1000, Lachlan McIlroy wrote: > Christoph Hellwig wrote: >> On Thu, Jun 19, 2008 at 04:17:15PM +1000, Lachlan McIlroy wrote: >>> After a btree insert operation a cursor can be invalid due to block >>> splits and a maybe a new root block. We reset the cursor in >>> xfs_bmbt_insert() in the cases where we think we need to but it >>> isn't enough as we still see assertions. Just do what we do elsewhere >>> and reset the cursor unconditionally. Version 2 adds >>> XFS_WANT_CORRUPTED_GOTO checks throughout xfs_bmap.c and removes the >>> fix to revalidate the original cursor in xfs_bmbt_insert(). >> >> Can you commit the XFS_WANT_CORRUPTED_GOTO checks as a separate patch >> before the cursor reset? ACK from me for those hunks. >> > > Yeah, no problem, thanks. The rest of it looks ok as well, Lachlan. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 19 21:10:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 21:10:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5K4ALcO003783 for ; Thu, 19 Jun 2008 21:10:21 -0700 X-ASG-Debug-ID: 1213935079-6ce901090000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zimbra.vpac.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 87B621230A61 for ; Thu, 19 Jun 2008 21:11:20 -0700 (PDT) Received: from zimbra.vpac.org (zimbra.vpac.org [202.158.218.6]) by cuda.sgi.com with ESMTP id NKNfzCQMSKcO60Gp for ; Thu, 19 Jun 2008 21:11:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.vpac.org (Postfix) with ESMTP id 6349746D0195; Fri, 20 Jun 2008 14:11:19 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at Received: from zimbra.vpac.org ([127.0.0.1]) by localhost (zimbra.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT8O+LLmQy2S; Fri, 20 Jun 2008 14:11:16 +1000 (EST) Received: from [172.25.10.11] (firewall.vpac.org [202.158.218.253]) by zimbra.vpac.org (Postfix) with ESMTP id 766D746D0182; Fri, 20 Jun 2008 14:11:16 +1000 (EST) Message-ID: <485B2DE4.2080907@vpac.org> Date: Fri, 20 Jun 2008 14:11:16 +1000 From: Brian May User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Brian May CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: open sleeps Subject: Re: open sleeps References: <4859EE54.6050801@vpac.org> <20080619062118.GY3700@disturbed> <4859FF40.8010206@vpac.org> <20080619084311.GA16736@infradead.org> <485B0C47.5060001@vpac.org> In-Reply-To: <485B0C47.5060001@vpac.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: zimbra.vpac.org[202.158.218.6] X-Barracuda-Start-Time: 1213935080 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4974 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53802 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16446 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brian@vpac.org Precedence: bulk X-list: xfs Brian May wrote: > I guess I also need to make sure I get this same stack trace each time. Yes. Looks consistent to me. Brian May. From owner-xfs@oss.sgi.com Thu Jun 19 22:20:33 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 22:20:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_47,J_CHICKENPOX_48,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5K5KUjF012796 for ; Thu, 19 Jun 2008 22:20:33 -0700 X-ASG-Debug-ID: 1213939283-0afd01810000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 88A5E17F53AC for ; Thu, 19 Jun 2008 22:21:23 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id VJYQaSLRNQkdEZxU for ; Thu, 19 Jun 2008 22:21:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIjYWkh5LG+u/2dsb2JhbACvdA X-IronPort-AV: E=Sophos;i="4.27,677,1204464600"; d="scan'208";a="130571793" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 20 Jun 2008 14:51:21 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1K9Z3o-0006Be-AO; Fri, 20 Jun 2008 15:21:20 +1000 Date: Fri, 20 Jun 2008 15:21:20 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080620052120.GA3700@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> <485A0AB2.4060009@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485A0AB2.4060009@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1213939288 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.53807 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: 16447 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 Thu, Jun 19, 2008 at 05:28:50PM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: >> On Tue, Jun 17, 2008 at 11:58:47AM +1000, Lachlan McIlroy wrote: >>> Dave Chinner wrote: >>>> On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: >>>>> I'm well aware of that particular deadlock involving the freelist - I >>>>> hit it while testing. If you look closely at the code that deadlock >>>>> can occur with or without the AG locking avoidance logic. This is >>>>> because the rest of the transaction is unaware that an AG has been >>>>> locked due to a freelist operation. >>>> Yes, which is why you need to prevent freelist modifications occurring >>>> when you can't allocate anything out of the AG. >>> That sounds reasonable but it isn't consistent with the deadlock I saw. >>> One of the threads that was deadlocked had tried to allocate a data extent >>> in AG3 but didn't find the space. It had modified, and hence locked, AG3 >>> due to modifying the freelist but since it didn't get the space it needed >>> it had to go on to another AG. >> >> That sounds like an exact allocation failure - there is enough >> space, a large enough extent but no free space at the exact block >> required. This is exactly the case that occurred with the inode >> allocation - and then allocation in the same AG failed because of >> alignment that wasn't taken into account by the first exact >> allocation attempt. Perhaps the minalignslop calculation in >> xfs_bmap_btalloc() is incorrect... > > Okay I'll look into that. > > There's something else that looks suspicious to me - this code in > xfs_bmap_btalloc() is setting minleft to 0. Doesn't this go against > what you were saying about setting minleft to be the space we might > need for the btree operations? > > if (args.fsbno == NULLFSBLOCK && nullfb) { > args.fsbno = 0; > args.type = XFS_ALLOCTYPE_FIRST_AG; > args.total = ap->minlen; > args.minleft = 0; > if ((error = xfs_alloc_vextent(&args))) > return error; > ap->low = 1; > } Hmmm - that looks suspicious. In xfs_bmapi(), when we are doing a write and *firstblock == NULLFSBLOCK (which leads to nullfb being set in the above code), we do: if (wr && *firstblock == NULLFSBLOCK) { if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; else minleft = 1; } else minleft = 0; If we are in btree format we set the minleft to the number of blocks needed for a split. If we are in extent or local format, change to extent of btree format requires one extra block. The above code you point out definitely breaks this - we haven't done a previous allocation so we can start from the first AG, but we sure as hell still need minleft set to the number of blocks needed for a format change or btree split. > I see it sets a lowspace indicator which filters back up and into > some btree operations. It appears the purpose of this feature is to > allow allocations to search for space in other AGs as in this example > from xfs_bmap_extents_to_btree(): > > if (*firstblock == NULLFSBLOCK) { > args.type = XFS_ALLOCTYPE_START_BNO; > args.fsbno = XFS_INO_TO_FSB(mp, ip->i_ino); > } else if (flist->xbf_low) { > args.type = XFS_ALLOCTYPE_START_BNO; > args.fsbno = *firstblock; > } else { > args.type = XFS_ALLOCTYPE_NEAR_BNO; > args.fsbno = *firstblock; > } Hmmm - the only place xbf_low is used in the extent-to-btree conversion. I don't have access to the revision history anymore, so i can't find out what bug the xbf_low condition was added for. It certainly looks like it is allowing the btree block to be allocated in a different AG to data block. > This is sort of what I was trying to do with my patch but without the > special lowspace condition. This lowspace feature is probably broken > because there was a similar special case in xfs_bmbt_split() that got > removed with the changes that fixed the AG out-of-order locking problem. > > @@ -1569,12 +1569,11 @@ > lbno = XFS_DADDR_TO_FSB(args.mp, XFS_BUF_ADDR(lbp)); > left = XFS_BUF_TO_BMBT_BLOCK(lbp); > args.fsbno = cur->bc_private.b.firstblock; > + args.firstblock = args.fsbno; > if (args.fsbno == NULLFSBLOCK) { > args.fsbno = lbno; > args.type = XFS_ALLOCTYPE_START_BNO; > - } else if (cur->bc_private.b.flist->xbf_low) > - args.type = XFS_ALLOCTYPE_FIRST_AG; > - else > + } else > args.type = XFS_ALLOCTYPE_NEAR_BNO; > args.mod = args.minleft = args.alignment = args.total = args.isfl = > args.userdata = args.minalignslop = 0; > > This could be why we have allocations failing now. Hmmm - yes, could be. Well found, Lachlan. Was there an equivalent change to the allocation of a new root block? > Maybe it should > have been left in and XFS_ALLOCTYPE_FIRST_AG changed to > XFS_ALLOCTYPE_START_BNO. But even then it could still fail because the > AG deadlock avoidance code may prevent us from searching the AG that has > the space we need. Right. But it would definitely be more likely to find space than the current code without re-introducing the deadlock. > Should we ditch this lowspace special condition (and the code in > xfs_bmap_btalloc()) and insist that all the space we need (using minleft) > should come from one AG? Well, we could, but I suspect that one condition that it is used it is safe to do so. That is, the logic goes like this: - allocate the last extent in an AG. By definition, that has not caused a AGF btree split as the trees are now empty. - because we haven't split any AGF btrees, we still have an unused transaction reservation for full AGF btree splits. - seeing as we have a full reservation, we can safely allocate in a different AG without overrunning a transaction reservation. However, we still need to obey the AGF locking order. Hmmmm - perhaps before allocating with minleft = 0 we need to check if we can allocate the rest of the blocks from another AG and lock both AGs in the correct order first, recheck we can allocate from both of them after they are locked but before modifying anything and only then proceed. If we can't find two AGs to allocate from then we can safely ENOSPC without any problems. In this special case we'd then be able to search the entire FS for space and hence only get an ENOSPC if we are really at ENOSPC. Can you pick holes in this? >>>>> I'm worried with this approach that we could have delayed allocations and >>>>> unwritten extents that need to be converted but we can't do it because we >>>>> don't have the space we might need (but probably don't). >>>> Delayed allocation is the issue - unwritten extent conversion failure will >>>> simply return an error and leave the extent unwritten. >>> That's still a problem though - if we can't convert unwritten extents then >>> we can't clean dirty pages and we wont be able to unmount the filesystem. >> >> There will be errors logged and the extents will remain unwritten. >> The filesystem should still be able to be unmounted. > > So returning an error from unwritten extent conversion will not re-dirty the > pages? So we effectively throw the user's data away? Yes, I think that can happen async writes. For anything that is sync the error will be propagated back to application. Often there is nothing to report errors back to on async writes - I'm not sure if the errors get logged in that case, though... I suspect that this is a holdover from before we had ENOSPC checking on mmap writes - that could result in mmap oversubscribing space and the data could not ever be written. In low memory conditions this could deadlock the machine if we did not throw the pages away. We probably need to reevisit this now that ->page_mkwrite() prevents oversubscription from occurring.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 19 22:41:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 22:41:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5K5f1Km015250 for ; Thu, 19 Jun 2008 22:41:03 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA06914; Fri, 20 Jun 2008 15:41:52 +1000 Message-ID: <485B431F.2070905@sgi.com> Date: Fri, 20 Jun 2008 15:41:51 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] check for invalid flags in xfs_attrlist_by_handle References: <20080531075829.GA5424@lst.de> In-Reply-To: <20080531075829.GA5424@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16448 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 Fair enough. Actually, I think we only use ATTR_ROOT and ATTR_SECURE for the namespace flags. So you could probably use: XFS_ATTR_NSP_ARGS xfs_attr_leaf.h:#define XFS_ATTR_NSP_ARGS_MASK (ATTR_ROOT | ATTR_SECURE) xfs_attr_leaf.h:#define XFS_ATTR_NSP_ARGS(flags) ((flags) & XFS_ATTR_NSP_ARGS_MASK) and something like: if (!XFS_ATTR_NSP_ARGS(al_hreq.flags)) return -XFS_ERROR(EINVAL); Though would probably then need to include the right header (xfs_attr_leaf.h) for it... --Tim Christoph Hellwig wrote: > xfs_attrlist_by_handle should only take the ATTR_ flags for the root > namespaces. The ATTR_KERN* flags may change at anytime and expect special > preconditions that can't be guaranteed for userspace-originating > requests. For example passing down ATTR_KERNNOVAL through > xfs_attrlist_by_handle will hit an assert in debug builds currently. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-05-28 17:37:02.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-05-28 17:42:18.000000000 +0200 > @@ -470,6 +470,12 @@ xfs_attrlist_by_handle( > if (al_hreq.buflen > XATTR_LIST_MAX) > return -XFS_ERROR(EINVAL); > > + /* > + * Reject flags, only allow namespaces. > + */ > + if (al_hreq.flags & ~(ATTR_ROOT|ATTR_TRUST|ATTR_SECURE)) > + return -XFS_ERROR(EINVAL); > + > error = xfs_vget_fsop_handlereq(mp, parinode, &al_hreq.hreq, &inode); > if (error) > goto out; > From owner-xfs@oss.sgi.com Thu Jun 19 22:44:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 22:44:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5K5iGxm015668 for ; Thu, 19 Jun 2008 22:44:16 -0700 X-ASG-Debug-ID: 1213940713-422e01130000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ku-gbr.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 553E4D014D3; Thu, 19 Jun 2008 22:45:14 -0700 (PDT) Received: from ku-gbr.de (mail.ku-gbr.de [81.3.11.18]) by cuda.sgi.com with ESMTP id xMTM8pcdaTWbGHbo; Thu, 19 Jun 2008 22:45:14 -0700 (PDT) Received: from dslc-082-082-173-007.pools.arcor-ip.net ([82.82.173.7]:38553 helo=keulator.homelinux.org) by mail.ku-gbr.de with esmtpsa (Exim 4.69 #1 (Debian)) id 1K9ZQr-0008TH-MI; Fri, 20 Jun 2008 07:45:09 +0200 Received: from anita ([10.10.0.18] helo=anita.doom) by keulator.homelinux.org with esmtp (Exim 4.69) (envelope-from ) id 1K9ZQo-0000Wh-Ty; Fri, 20 Jun 2008 07:45:06 +0200 Received: from konsti by anita.doom with local (Exim 4.69) (envelope-from ) id 1K9ZQm-0000Xa-O2; Fri, 20 Jun 2008 07:45:04 +0200 Date: Fri, 20 Jun 2008 07:45:04 +0200 From: Konstantin Kletschke To: Miquel van Smoorenburg , Oliver Pinter , linux-kernel@vger.kernel.org, Christoph Hellwig , xfs@oss.sgi.com, xfs-masters@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c Message-ID: <20080620054504.GA2075@anita> Mail-Followup-To: Miquel van Smoorenburg , Oliver Pinter , linux-kernel@vger.kernel.org, Christoph Hellwig , xfs@oss.sgi.com, xfs-masters@oss.sgi.com References: <20080612123031.21594jyk6rjc1lfk@imp.ku-gbr.de> <6101e8c40806120733m3c8647ccy149eb237e2c6d027@mail.gmail.com> <1213309629.29745.8.camel@localhost.localdomain> <20080613030841.GC3700@disturbed> <20080620052716.GA2022@anita> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080620052716.GA2022@anita> User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: mail.ku-gbr.de[81.3.11.18] X-Barracuda-Start-Time: 1213940715 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.53808 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: 16449 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lists@ku-gbr.de Precedence: bulk X-list: xfs Again. Before strace looks weird, this looks like the old one: ksymoops 2.4.11 on x86_64 2.6.26-rc6. Options used -V (default) -k /proc/ksyms (default) -l /proc/modules (default) -o /lib/modules/2.6.26-rc6/ (default) -m /usr/src/linux-2.6.26-rc6/System.map (specified) Error (regular_file): read_ksyms stat /proc/ksyms failed ksymoops: No such file or directory No modules in ksyms, skipping objects No ksyms, skipping lsmod Pid: 2137, comm: fetchnews Not tainted 2.6.26-rc6 #1 Call Trace: [] [] [] [] [] [] [] [] [] [] Warning (Oops_read): Code line not seen, dumping what data is available Trace; ffffffff802ffa42 Trace; ffffffff802fa35a Trace; ffffffff802ffa42 Trace; ffffffff80308a29 Trace; ffffffff80262799 Trace; ffffffff8026500a Trace; ffffffff80223506 Trace; ffffffff8023116c <__remove_hrtimer+6b/78> Trace; ffffffff8025a0fa Trace; ffffffff8020afab 1 warning and 1 error issued. Results may not be reliable. -- GPG KeyID EF62FCEF Fingerprint: 13C9 B16B 9844 EC15 CC2E A080 1E69 3FDA EF62 FCEF From owner-xfs@oss.sgi.com Thu Jun 19 22:44:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 22:44:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from 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 m5K5inhN015958 for ; Thu, 19 Jun 2008 22:44:50 -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 PAA07142; Fri, 20 Jun 2008 15:45:42 +1000 Message-ID: <485B4406.6060906@sgi.com> Date: Fri, 20 Jun 2008 15:45:42 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] attrmulti cleanup References: <20080531080121.GB5424@lst.de> In-Reply-To: <20080531080121.GB5424@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16450 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 Cool. I'll run thru qa and check it in. Funny how we had two versions. --Tim Christoph Hellwig wrote: > xfs_attrmulti_by_handle currently request the size based on > sizeof(attr_multiop_t) but should be using sizeof(xfs_attr_multiop_t) > because that is what it is dealing with. Despite beeing wrong this > actually harmless in practice because both structures are the same size > on all platforms. > > But this sizeof was the only user of struct attr_multiop so we can just > kill it. Also move the ATTR_OP_* defines xfs_attr.h into the > struct xfs_attr_multiop defintion in xfs_fs.h because they are only used > with that structure, and are part of the user ABI for the > XFS_IOC_ATTRMULTI_BY_HANDLE ioctl. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-05-28 17:42:18.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-05-28 17:42:36.000000000 +0200 > @@ -598,7 +598,7 @@ xfs_attrmulti_by_handle( > goto out; > > error = E2BIG; > - size = am_hreq.opcount * sizeof(attr_multiop_t); > + size = am_hreq.opcount * sizeof(xfs_attr_multiop_t); > if (!size || size > 16 * PAGE_SIZE) > goto out_vn_rele; > > Index: linux-2.6-xfs/fs/xfs/xfs_attr.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.h 2008-05-28 17:41:06.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_attr.h 2008-05-28 17:42:36.000000000 +0200 > @@ -100,22 +100,6 @@ typedef struct attrlist_ent { /* data fr > &((char *)buffer)[ ((attrlist_t *)(buffer))->al_offset[index] ]) > > /* > - * Multi-attribute operation vector. > - */ > -typedef struct attr_multiop { > - int am_opcode; /* operation to perform (ATTR_OP_GET, etc.) */ > - int am_error; /* [out arg] result of this sub-op (an errno) */ > - char *am_attrname; /* attribute name to work with */ > - char *am_attrvalue; /* [in/out arg] attribute value (raw bytes) */ > - int am_length; /* [in/out arg] length of value */ > - int am_flags; /* bitwise OR of attr API flags defined above */ > -} attr_multiop_t; > - > -#define ATTR_OP_GET 1 /* return the indicated attr's value */ > -#define ATTR_OP_SET 2 /* set/create the indicated attr/value pair */ > -#define ATTR_OP_REMOVE 3 /* remove the indicated attr */ > - > -/* > * Kernel-internal version of the attrlist cursor. > */ > typedef struct attrlist_cursor_kern { > Index: linux-2.6-xfs/fs/xfs/xfs_fs.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_fs.h 2008-05-28 17:41:06.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_fs.h 2008-05-28 17:42:36.000000000 +0200 > @@ -372,6 +372,9 @@ typedef struct xfs_fsop_attrlist_handler > > typedef struct xfs_attr_multiop { > __u32 am_opcode; > +#define ATTR_OP_GET 1 /* return the indicated attr's value */ > +#define ATTR_OP_SET 2 /* set/create the indicated attr/value pair */ > +#define ATTR_OP_REMOVE 3 /* remove the indicated attr */ > __s32 am_error; > void __user *am_attrname; > void __user *am_attrvalue; > From owner-xfs@oss.sgi.com Thu Jun 19 22:47:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 22:47:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5K5lOkS016551 for ; Thu, 19 Jun 2008 22:47:24 -0700 X-ASG-Debug-ID: 1213940901-169d03700000-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 396C0256125; Thu, 19 Jun 2008 22:48:22 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id zNdAHKMScei0xdMq; Thu, 19 Jun 2008 22:48:22 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5K5mDNW025295 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 20 Jun 2008 07:48:13 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5K5mDWt025293; Fri, 20 Jun 2008 07:48:13 +0200 Date: Fri, 20 Jun 2008 07:48:13 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] check for invalid flags in xfs_attrlist_by_handle Subject: Re: [PATCH] check for invalid flags in xfs_attrlist_by_handle Message-ID: <20080620054813.GA25244@lst.de> References: <20080531075829.GA5424@lst.de> <485B431F.2070905@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485B431F.2070905@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213940903 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.53809 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: 16451 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 20, 2008 at 03:41:51PM +1000, Timothy Shimmin wrote: > Fair enough. > Actually, I think we only use ATTR_ROOT and ATTR_SECURE for the > namespace flags. > So you could probably use: XFS_ATTR_NSP_ARGS > xfs_attr_leaf.h:#define XFS_ATTR_NSP_ARGS_MASK (ATTR_ROOT | ATTR_SECURE) > xfs_attr_leaf.h:#define XFS_ATTR_NSP_ARGS(flags) ((flags) & XFS_ATTR_NSP_ARGS_MASK) > and something like: > > if (!XFS_ATTR_NSP_ARGS(al_hreq.flags)) > return -XFS_ERROR(EINVAL); > > Though would probably then need to include the right header (xfs_attr_leaf.h) for it... Makes sense. I'll revise the patch and send an updated version after running it through QA. From owner-xfs@oss.sgi.com Thu Jun 19 23:19:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 19 Jun 2008 23:19:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5K6IxUX021116 for ; Thu, 19 Jun 2008 23:18:59 -0700 X-ASG-Debug-ID: 1213942797-34dc03450000-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 96D69D0200F for ; Thu, 19 Jun 2008 23:19:57 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 3kuGX0eDmprW08SZ for ; Thu, 19 Jun 2008 23:19:57 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5K6IiNW026854 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 20 Jun 2008 08:18:44 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5K6IfWe026845; Fri, 20 Jun 2008 08:18:41 +0200 Date: Fri, 20 Jun 2008 08:18:41 +0200 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] kill XFS_PURGE_INODE Subject: Re: [PATCH] kill XFS_PURGE_INODE Message-ID: <20080620061841.GA26777@lst.de> References: <20080616062634.GA5971@lst.de> <200806161015.12363.dchinner@agami.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806161015.12363.dchinner@agami.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1213942798 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0005 1.0000 -2.0181 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53810 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: 16452 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Mon, Jun 16, 2008 at 10:15:12AM -0700, Dave Chinner wrote: > On Sunday 15 June 2008 11:26 pm, Christoph Hellwig wrote: > > Just a useless alias for IRELE. > > Looks sane. Could someone of the SGI people commit this rather trivial patch? From owner-xfs@oss.sgi.com Fri Jun 20 00:31:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 20 Jun 2008 00:31:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5K7VM85004973 for ; Fri, 20 Jun 2008 00:31:24 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA08754; Fri, 20 Jun 2008 17:32:08 +1000 Message-ID: <485B5DD4.3020201@sgi.com> Date: Fri, 20 Jun 2008 17:35:48 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , Christoph Hellwig , xfs-dev , xfs-oss Subject: Re: [PATCH V2] Always reset btree cursor after an insert References: <4859F9EB.5050505@sgi.com> <20080619083544.GA19606@infradead.org> <485B0B04.80808@sgi.com> <20080620033710.GZ3700@disturbed> In-Reply-To: <20080620033710.GZ3700@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16453 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Fri, Jun 20, 2008 at 11:42:28AM +1000, Lachlan McIlroy wrote: >> Christoph Hellwig wrote: >>> On Thu, Jun 19, 2008 at 04:17:15PM +1000, Lachlan McIlroy wrote: >>>> After a btree insert operation a cursor can be invalid due to block >>>> splits and a maybe a new root block. We reset the cursor in >>>> xfs_bmbt_insert() in the cases where we think we need to but it >>>> isn't enough as we still see assertions. Just do what we do elsewhere >>>> and reset the cursor unconditionally. Version 2 adds >>>> XFS_WANT_CORRUPTED_GOTO checks throughout xfs_bmap.c and removes the >>>> fix to revalidate the original cursor in xfs_bmbt_insert(). >>> Can you commit the XFS_WANT_CORRUPTED_GOTO checks as a separate patch >>> before the cursor reset? ACK from me for those hunks. >>> >> Yeah, no problem, thanks. > > The rest of it looks ok as well, Lachlan. > Ta. From owner-xfs@oss.sgi.com Fri Jun 20 00:36:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 20 Jun 2008 00:36: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.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5K7aIjX005845 for ; Fri, 20 Jun 2008 00:36:19 -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 RAA08823; Fri, 20 Jun 2008 17:37:11 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 6730358C4C3F; Fri, 20 Jun 2008 17:37:11 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 983336 - Always reset btree cursor after an insert Message-Id: <20080620073711.6730358C4C3F@chook.melbourne.sgi.com> Date: Fri, 20 Jun 2008 17:37:11 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) 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: 16454 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Always reset btree cursor after an insert After a btree insert operation a cursor can be invalid due to block splits and a maybe a new root block. We reset the cursor in xfs_bmbt_insert() in the cases where we think we need to but it isn't enough as we still see assertions. Just do what we do elsewhere and reset the cursor unconditionally. Also remove the fix to revalidate the original cursor in xfs_bmbt_insert(). Date: Fri Jun 20 17:36:09 AEST 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-agno2 Inspected by: dgc Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31342a fs/xfs/xfs_bmap_btree.c - 1.170 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap_btree.c.diff?r1=text&tr1=1.170&r2=text&tr2=1.169&f=h fs/xfs/xfs_bmap.c - 1.394 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bmap.c.diff?r1=text&tr1=1.394&r2=text&tr2=1.393&f=h - Always reset btree cursor after an insert From owner-xfs@oss.sgi.com Fri Jun 20 06:03:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 20 Jun 2008 06:03:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5KD3tLo011900 for ; Fri, 20 Jun 2008 06:03:56 -0700 X-ASG-Debug-ID: 1213967094-531402660000-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 0A3C8258035 for ; Fri, 20 Jun 2008 06:04:54 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.248]) by cuda.sgi.com with ESMTP id BA1a0RgRyQqsJsy3 for ; Fri, 20 Jun 2008 06:04:54 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so5808199rvb.32 for ; Fri, 20 Jun 2008 06:04:54 -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=wSrG7v44Y3gMTfwYpmF5Ke+rbb7rtXdpauP34XjimOQ=; b=okkkq7ydDaktXjlvtmAsZIZn/axCqlFRt0pvE8kN19Bsj3Wy6YDrUbZMUb48Rs1r7d KE7AeXSDfifLXq8MwlQ7qIuBK7p3H7N1EFgrxo3qPdHnDsRzp7s+CdwgN/tAH1iuQ/fL WcuxKmQA08o8WIofqGkJUSLBVxmy2CMb3jNsY= 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=wnoSbMHapyLEPi5EROK5vJjS8yTZ//L1lm4kFZV88V6AGn3qGldM7ADqmFelkABHCg q3fITKrd3oTMVAoyEM24krLIA3RdV6nbvNXV1KBk4Xzz2+rOZL5ksUrCypmHeN66oP32 bwnKGj8tFgNKfKOpk4cl/OQz5owONDc21Yu3M= Received: by 10.141.175.5 with SMTP id c5mr7505244rvp.80.1213967094190; Fri, 20 Jun 2008 06:04:54 -0700 (PDT) Received: by 10.141.189.9 with HTTP; Fri, 20 Jun 2008 06:04:54 -0700 (PDT) Message-ID: <59a5c01d0806200604i65f8271ya371039ef30af731@mail.gmail.com> Date: Fri, 20 Jun 2008 13:04:54 +0000 From: "Ashley Oviatt" To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair taking a long time Subject: Re: xfs_repair taking a long time In-Reply-To: <485AD667.1060402@qwest.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <485AD667.1060402@qwest.net> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.248] X-Barracuda-Start-Time: 1213967095 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3161 1.0000 -0.2814 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.28 X-Barracuda-Spam-Status: No, SCORE=-0.28 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.53837 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: 16455 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: ashovi@gmail.com Precedence: bulk X-list: xfs I have run xfs_metadump on the array and here is the output: root@slax:~# xfs_metadump -V xfs_metadump version 2.9.7 root@slax:~# xfs_metadump /dev/sda /root xfs_metadump: unexpected XFS SB magic number 0x00000000 xfs_metadump: read failed: Invalid argument xfs_metadump: data size check failed cache_node_purge: refcount was 1, not zero (node=0x80e2670) xfs_metadump: cannot read root inode (22) xfs_metadump: bad superblock magic number 0, giving up It looks like the superblock got corrupted, and xfs_repair can't find another one to fix it. Any ideas on how to get it back? Ashley On 6/19/08, Ash wrote: > I am having the same problem as the person in this thread: > > > Which is xfs_repair has been running for 16 hours on a 1 TB raid array. > It gave the same errors as this thread, saying that it could not use any > of the super blocks it found. The last email in the thread says: > > ----------------------------------------- > > xfs-repair did find candidate secondary superblocks - it discarded them > for some reason or another. If they were ok, all repair would have done > is copied them to block zero and then continued. > > I'm suggesting that you manually do this step, and then see if repair > will run. > > > Before wrapping this up, if you could just clarify a couple > things. If I > > look at the bytes at the beginning of each physical part of the LVM's, > > what am I looking for? "XFSB"? > > yes. > > > If I do find that byte string, why > > couldn't xfs_repair find it when it did the scan and what do I do > with it > > if I do find one? > > As I said above, xfs-repair did find some, but rejected them for some > (unknown) reason. if you find one, copy it over block zero of the partition, > and see if repair will run. Like I said, though, you'll probably want to > back up th partition first, or at least run repair in no-modify mode. > > -------------------------------------- > > The poster, Dave Chinner, says to manually copy the superblock to the > right place, but not how to do it. I am familiar with dd, but would like > to know the exact command or steps to take to replace the primary > superblock manually with a secondary superblock. > > Ashley > > (I sent this earlier but I haven't seen it come over the list yet, so > I'll send it again. Please forgive the duplicate.) > > > From owner-xfs@oss.sgi.com Sun Jun 22 11:13:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 11:13:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=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 m5MIDsbx032288 for ; Sun, 22 Jun 2008 11:13:55 -0700 X-ASG-Debug-ID: 1214158490-40d500620000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gir.skynet.ie (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5F27B1B37903 for ; Sun, 22 Jun 2008 11:14:51 -0700 (PDT) Received: from gir.skynet.ie (gir.skynet.ie [193.1.99.77]) by cuda.sgi.com with ESMTP id tyMBo53tA4TiSJ7G for ; Sun, 22 Jun 2008 11:14:51 -0700 (PDT) Received: from skynet.skynet.ie (skynet.skynet.ie [193.1.99.74]) by gir.skynet.ie (Postfix) with ESMTP id 2ACD412316; Sun, 22 Jun 2008 19:14:50 +0100 (IST) Received: by skynet.skynet.ie (Postfix, from userid 2391) id 0B4FF100003; Sun, 22 Jun 2008 19:14:49 +0100 (IST) Date: Sun, 22 Jun 2008 19:14:49 +0100 From: Mel Gorman To: Daniel J Blueman Cc: Christoph Lameter , Linus Torvalds , Alexander Beregalov , Linux Kernel , david@fromorbit.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Subject: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Message-ID: <20080622181449.GD625@csn.ul.ie> References: <6278d2220806220256g674304ectb945c14e7e09fede@mail.gmail.com> <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> <20080622181011.GC625@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20080622181011.GC625@csn.ul.ie> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: gir.skynet.ie[193.1.99.77] X-Barracuda-Start-Time: 1214158492 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0102 1.0000 -1.9545 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.95 X-Barracuda-Spam-Status: No, SCORE=-1.95 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54044 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: 16456 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mel@csn.ul.ie Precedence: bulk X-list: xfs (Sorry for the resend, the wrong Dave Chinner's email address was used) On (22/06/08 10:58), Daniel J Blueman didst pronounce: > I'm seeing a similar issue [2] to what was recently reported [1] by > Alexander, but with another workload involving XFS and memory > pressure. > Is NFS involved or is this XFS only? It looks like XFS-only but no harm in being sure. I'm beginning to wonder if this is a problem where a lot of dirty inodes are being written back in this path and we stall while that happens. I'm still not getting why we are triggering this now and did not before 2.6.26-rc1 or why it bisects to the zonelist modifications. Diffing the reclaim and allocation paths between 2.6.25 and 2.6.26-rc1 has not yielded any candidates for me yet that would explain this. > SLUB allocator is in use and config is at http://quora.org/config-client-debug . > > Let me know if you'd like more details/vmlinux objdump etc. > > Thanks, > Daniel > > --- [1] > > http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/e673c9173d45a735/db9213ef39e4e11c > > --- [2] > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.26-rc7-210c #2 > ------------------------------------------------------- > AutopanoPro/4470 is trying to acquire lock: > (iprune_mutex){--..}, at: [] shrink_icache_memory+0x7d/0x290 > > but task is already holding lock: > (&mm->mmap_sem){----}, at: [] do_page_fault+0x255/0x890 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #2 (&mm->mmap_sem){----}: > [] __lock_acquire+0xbdd/0x1020 > [] lock_acquire+0x65/0x90 > [] down_read+0x3b/0x70 > [] do_page_fault+0x27c/0x890 > [] error_exit+0x0/0xa9 > [] 0xffffffffffffffff > > -> #1 (&(&ip->i_iolock)->mr_lock){----}: > [] __lock_acquire+0xbdd/0x1020 > [] lock_acquire+0x65/0x90 > [] down_write_nested+0x46/0x80 > [] xfs_ilock+0x99/0xa0 > [] xfs_ireclaim+0x3f/0x90 > [] xfs_finish_reclaim+0x59/0x1a0 > [] xfs_reclaim+0x109/0x110 > [] xfs_fs_clear_inode+0xe1/0x110 > [] clear_inode+0x7d/0x110 > [] dispose_list+0x2a/0x100 > [] shrink_icache_memory+0x22f/0x290 > [] shrink_slab+0x168/0x1d0 > [] kswapd+0x3b6/0x560 > [] kthread+0x4d/0x80 > [] child_rip+0xa/0x12 > [] 0xffffffffffffffff > > -> #0 (iprune_mutex){--..}: > [] __lock_acquire+0xa47/0x1020 > [] lock_acquire+0x65/0x90 > [] mutex_lock_nested+0xb5/0x300 > [] shrink_icache_memory+0x7d/0x290 > [] shrink_slab+0x168/0x1d0 > [] try_to_free_pages+0x268/0x3a0 > [] __alloc_pages_internal+0x206/0x4b0 > [] __alloc_pages_nodemask+0x9/0x10 > [] alloc_page_vma+0x72/0x1b0 > [] handle_mm_fault+0x462/0x7b0 > [] do_page_fault+0x30c/0x890 > [] error_exit+0x0/0xa9 > [] 0xffffffffffffffff > > other info that might help us debug this: > > 2 locks held by AutopanoPro/4470: > #0: (&mm->mmap_sem){----}, at: [] do_page_fault+0x255/0x890 > #1: (shrinker_rwsem){----}, at: [] shrink_slab+0x32/0x1d0 > > stack backtrace: > Pid: 4470, comm: AutopanoPro Not tainted 2.6.26-rc7-210c #2 > > Call Trace: > [] print_circular_bug_tail+0x83/0x90 > [] ? print_circular_bug_entry+0x49/0x60 > [] __lock_acquire+0xa47/0x1020 > [] lock_acquire+0x65/0x90 > [] ? shrink_icache_memory+0x7d/0x290 > [] mutex_lock_nested+0xb5/0x300 > [] ? shrink_icache_memory+0x7d/0x290 > [] shrink_icache_memory+0x7d/0x290 > [] ? shrink_slab+0x32/0x1d0 > [] shrink_slab+0x168/0x1d0 > [] try_to_free_pages+0x268/0x3a0 > [] ? isolate_pages_global+0x0/0x40 > [] __alloc_pages_internal+0x206/0x4b0 > [] __alloc_pages_nodemask+0x9/0x10 > [] alloc_page_vma+0x72/0x1b0 > [] handle_mm_fault+0x462/0x7b0 > [] ? trace_hardirqs_on+0xbf/0x150 > [] ? do_page_fault+0x255/0x890 > [] do_page_fault+0x30c/0x890 > [] error_exit+0x0/0xa9 > -- > Daniel J Blueman > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab From owner-xfs@oss.sgi.com Sun Jun 22 11:54:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 11:54:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5MIs3O6003568 for ; Sun, 22 Jun 2008 11:54:04 -0700 X-ASG-Debug-ID: 1214160900-40d502880000-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 D46901B37CAE for ; Sun, 22 Jun 2008 11:55:01 -0700 (PDT) Received: from rv-out-0708.google.com (rv-out-0708.google.com [209.85.198.247]) by cuda.sgi.com with ESMTP id Ww2qP9t12XbA70O5 for ; Sun, 22 Jun 2008 11:55:01 -0700 (PDT) Received: by rv-out-0708.google.com with SMTP id f25so6523412rvb.32 for ; Sun, 22 Jun 2008 11:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=aHFWqtNw3yCd3ETj+1pOTFdENoaprArcdSqvZIIr6yo=; b=e6m2Wls60r2EAatnSBZh7JVljRWNtlHSo/XFvr35d8dy3NR+aLS68+gPZoChH9GJlz Cd6rv12PJlEybWxZgthnxH20sDvDlqS14T1LYDCxLjjqdqq7XY+LWzSRzXhZ7V1U0R+9 7cqRly6TzuagMCpwCqU186piPnyOEMmJHM34g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=s7A77hBJcYP76sV/UsVU1f2pIhksK4BxAilj/poWEqUIKAs3+t66ROgb6wBgsIoRE+ 2gcalZlUwG1NrMTO4Cl5tCY0Jmg7/XD8fvSUKMuSVSo1X8N1FeePGkR5aJxzwmElbmTY fCfET98h1nILBu5k+pJfCWP3oF3NS2Q0FYcsQ= Received: by 10.141.15.19 with SMTP id s19mr11317750rvi.161.1214160899690; Sun, 22 Jun 2008 11:54:59 -0700 (PDT) Received: by 10.115.111.7 with HTTP; Sun, 22 Jun 2008 11:54:59 -0700 (PDT) Message-ID: <6278d2220806221154h7f06813bmc80909554169dbdc@mail.gmail.com> Date: Sun, 22 Jun 2008 19:54:59 +0100 From: "Daniel J Blueman" To: "Mel Gorman" X-ASG-Orig-Subj: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Subject: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Cc: "Christoph Lameter" , "Linus Torvalds" , "Alexander Beregalov" , "Linux Kernel" , david@fromorbit.com, xfs@oss.sgi.com In-Reply-To: <20080622181449.GD625@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6278d2220806220256g674304ectb945c14e7e09fede@mail.gmail.com> <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> <20080622181011.GC625@csn.ul.ie> <20080622181449.GD625@csn.ul.ie> X-Barracuda-Connect: rv-out-0708.google.com[209.85.198.247] X-Barracuda-Start-Time: 1214160901 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0098 1.0000 -1.9574 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.54046 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: 16457 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: daniel.blueman@gmail.com Precedence: bulk X-list: xfs On Sun, Jun 22, 2008 at 7:14 PM, Mel Gorman wrote: > On (22/06/08 10:58), Daniel J Blueman didst pronounce: >> I'm seeing a similar issue [2] to what was recently reported [1] by >> Alexander, but with another workload involving XFS and memory >> pressure. >> > > Is NFS involved or is this XFS only? It looks like XFS-only but no harm in > being sure. The application is reading a 10MB file from NFS around every few seconds, and writing back ~30MB every few seconds to local XFS; another thread in the same application is consuming that data and writing out ~2MB to NFS after circa 10 input files, so NFS isn't dominant but is involved. > I'm beginning to wonder if this is a problem where a lot of dirty inodes are > being written back in this path and we stall while that happens. I'm still > not getting why we are triggering this now and did not before 2.6.26-rc1 > or why it bisects to the zonelist modifications. Diffing the reclaim and > allocation paths between 2.6.25 and 2.6.26-rc1 has not yielded any candidates > for me yet that would explain this. > >> SLUB allocator is in use and config is at http://quora.org/config-client-debug . >> >> Let me know if you'd like more details/vmlinux objdump etc. >> >> Thanks, >> Daniel >> >> --- [1] >> >> http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/e673c9173d45a735/db9213ef39e4e11c >> >> --- [2] >> >> ======================================================= >> [ INFO: possible circular locking dependency detected ] >> 2.6.26-rc7-210c #2 >> ------------------------------------------------------- >> AutopanoPro/4470 is trying to acquire lock: >> (iprune_mutex){--..}, at: [] shrink_icache_memory+0x7d/0x290 >> >> but task is already holding lock: >> (&mm->mmap_sem){----}, at: [] do_page_fault+0x255/0x890 >> >> which lock already depends on the new lock. >> >> >> the existing dependency chain (in reverse order) is: >> >> -> #2 (&mm->mmap_sem){----}: >> [] __lock_acquire+0xbdd/0x1020 >> [] lock_acquire+0x65/0x90 >> [] down_read+0x3b/0x70 >> [] do_page_fault+0x27c/0x890 >> [] error_exit+0x0/0xa9 >> [] 0xffffffffffffffff >> >> -> #1 (&(&ip->i_iolock)->mr_lock){----}: >> [] __lock_acquire+0xbdd/0x1020 >> [] lock_acquire+0x65/0x90 >> [] down_write_nested+0x46/0x80 >> [] xfs_ilock+0x99/0xa0 >> [] xfs_ireclaim+0x3f/0x90 >> [] xfs_finish_reclaim+0x59/0x1a0 >> [] xfs_reclaim+0x109/0x110 >> [] xfs_fs_clear_inode+0xe1/0x110 >> [] clear_inode+0x7d/0x110 >> [] dispose_list+0x2a/0x100 >> [] shrink_icache_memory+0x22f/0x290 >> [] shrink_slab+0x168/0x1d0 >> [] kswapd+0x3b6/0x560 >> [] kthread+0x4d/0x80 >> [] child_rip+0xa/0x12 >> [] 0xffffffffffffffff >> >> -> #0 (iprune_mutex){--..}: >> [] __lock_acquire+0xa47/0x1020 >> [] lock_acquire+0x65/0x90 >> [] mutex_lock_nested+0xb5/0x300 >> [] shrink_icache_memory+0x7d/0x290 >> [] shrink_slab+0x168/0x1d0 >> [] try_to_free_pages+0x268/0x3a0 >> [] __alloc_pages_internal+0x206/0x4b0 >> [] __alloc_pages_nodemask+0x9/0x10 >> [] alloc_page_vma+0x72/0x1b0 >> [] handle_mm_fault+0x462/0x7b0 >> [] do_page_fault+0x30c/0x890 >> [] error_exit+0x0/0xa9 >> [] 0xffffffffffffffff >> >> other info that might help us debug this: >> >> 2 locks held by AutopanoPro/4470: >> #0: (&mm->mmap_sem){----}, at: [] do_page_fault+0x255/0x890 >> #1: (shrinker_rwsem){----}, at: [] shrink_slab+0x32/0x1d0 >> >> stack backtrace: >> Pid: 4470, comm: AutopanoPro Not tainted 2.6.26-rc7-210c #2 >> >> Call Trace: >> [] print_circular_bug_tail+0x83/0x90 >> [] ? print_circular_bug_entry+0x49/0x60 >> [] __lock_acquire+0xa47/0x1020 >> [] lock_acquire+0x65/0x90 >> [] ? shrink_icache_memory+0x7d/0x290 >> [] mutex_lock_nested+0xb5/0x300 >> [] ? shrink_icache_memory+0x7d/0x290 >> [] shrink_icache_memory+0x7d/0x290 >> [] ? shrink_slab+0x32/0x1d0 >> [] shrink_slab+0x168/0x1d0 >> [] try_to_free_pages+0x268/0x3a0 >> [] ? isolate_pages_global+0x0/0x40 >> [] __alloc_pages_internal+0x206/0x4b0 >> [] __alloc_pages_nodemask+0x9/0x10 >> [] alloc_page_vma+0x72/0x1b0 >> [] handle_mm_fault+0x462/0x7b0 >> [] ? trace_hardirqs_on+0xbf/0x150 >> [] ? do_page_fault+0x255/0x890 >> [] do_page_fault+0x30c/0x890 >> [] error_exit+0x0/0xa9 >> -- >> Daniel J Blueman >> > > -- > Mel Gorman > Part-time Phd Student Linux Technology Center > University of Limerick IBM Dublin Software Lab -- Daniel J Blueman From owner-xfs@oss.sgi.com Sun Jun 22 14:37:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 14:37:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5MLbLVL027337 for ; Sun, 22 Jun 2008 14:37:24 -0700 X-ASG-Debug-ID: 1214170699-719b010c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B2E8DD1641E for ; Sun, 22 Jun 2008 14:38:19 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id ldGo3h1QCzk5lFv7 for ; Sun, 22 Jun 2008 14:38:19 -0700 (PDT) Received: (qmail 15766 invoked from network); 22 Jun 2008 21:38:18 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Jun 2008 21:38:18 -0000 Message-ID: <485EC8F0.2080605@sauce.co.nz> Date: Mon, 23 Jun 2008 09:49:36 +1200 From: Richard Scobie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: INFO messages on resync Subject: INFO messages on resync Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1214170700 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4816 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54057 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 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: 16458 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Apologies for the probable off topic nature of this. Have just updated a Fedora 9 system from 2.6.25.4-30.fc9.x86_64 to 2.6.25.6-55.fc9.x86_64 and resyncs on an md RAID6 array containing an XFS filesystem now generates these messages for the duration of the resync. Resyncs on previous kernel did not cause this. INFO: task xfssyncd:30716 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. xfssyncd D ffff8101b5cd4008 0 30716 2 ffff8101c858dcb0 0000000000000046 0000000000000000 ffff81023d8ce6d8 ffff8101c858dc10 ffffffff814b4e00 ffffffff814b4e00 ffff81023d8ce6d8 ffff8101c858dc30 ffff8101b515c000 ffffffff813b9610 ffff8101b515c328 Call Trace: [] __down+0xc5/0xd9 [] ? default_wake_function+0x0/0xf [] __down_failed+0x35/0x3a [] ? :xfs:xfs_buf_lock+0x5b/0x60 [] :xfs:xfs_getsb+0x2d/0x3d [] :xfs:xfs_trans_getsb+0x4c/0x8b [] :xfs:xfs_mod_sb+0x24/0x76 [] :xfs:xfs_log_sbcount+0xa5/0xce [] :xfs:xfs_syncsub+0x14a/0x24a [] :xfs:xfs_sync+0x42/0x47 [] :xfs:xfs_sync_worker+0x1f/0x41 [] :xfs:xfssyncd+0x144/0x182 [] ? :xfs:xfssyncd+0x0/0x182 [] kthread+0x49/0x76 [] child_rip+0xa/0x12 [] ? kthread+0x0/0x76 [] ? child_rip+0x0/0x12 INFO: task pdflush:260 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. pdflush D ffff81023d493af0 0 260 2 ffff81023d493ae0 0000000000000046 0000000000000000 ffffffff81134771 ffff81023d493a60 ffffffff814b4e00 ffffffff814b4e00 0000000000000009 0000000000000000 ffff81023dc04000 ffff81023f10e000 ffff81023dc04328 Call Trace: [] ? list_add+0xc/0xf [] md_write_start+0x105/0x11d [] ? autoremove_wake_function+0x0/0x38 [] :raid456:make_request+0x61/0x5e6 [] ? find_get_pages_tag+0x3d/0x96 [] ? pagevec_lookup_tag+0x22/0x2b [] generic_make_request+0x37e/0x3b9 [] ? mempool_alloc+0x5b/0x113 [] submit_bio+0xe0/0xe9 [] :xfs:_xfs_buf_ioapply+0x203/0x231 [] :xfs:xfs_buf_iorequest+0x41/0x6f [] :xfs:xfs_bdstrat_cb+0x19/0x3b [] :xfs:xfs_bwrite+0x5f/0xc0 [] :xfs:xfs_syncsub+0x129/0x24a [] :xfs:xfs_sync+0x42/0x47 [] :xfs:xfs_fs_write_super+0x23/0x2c [] sync_supers+0x61/0xa6 [] wb_kupdate+0x35/0x119 [] pdflush+0x133/0x1db [] ? wb_kupdate+0x0/0x119 [] ? pdflush+0x0/0x1db [] kthread+0x49/0x76 [] child_rip+0xa/0x12 [] ? kthread+0x0/0x76 [] ? child_rip+0x0/0x12 I realise they are "INFO" and not ERROR, but I am curious as to whether this is just a situation that was normal before and is now being logged, or whether this is indicative of an issue elsewhere? Regards, Richard From owner-xfs@oss.sgi.com Sun Jun 22 15:18:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 15:18:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,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 m5MMIbEK031341 for ; Sun, 22 Jun 2008 15:18:38 -0700 X-ASG-Debug-ID: 1214173174-0b4103290000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 861F61B385AC for ; Sun, 22 Jun 2008 15:19:34 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id FP0TAMzCvPWUBdVR for ; Sun, 22 Jun 2008 15:19:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANNqXkh5LG+u/2dsb2JhbACtQg X-IronPort-AV: E=Sophos;i="4.27,686,1204464600"; d="scan'208";a="132492337" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 23 Jun 2008 07:49:32 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KAXuE-0003Ll-Lt; Mon, 23 Jun 2008 08:19:30 +1000 Date: Mon, 23 Jun 2008 08:19:30 +1000 From: Dave Chinner To: Daniel J Blueman Cc: Christoph Lameter , Mel Gorman , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Subject: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Message-ID: <20080622221930.GA11558@disturbed> Mail-Followup-To: Daniel J Blueman , Christoph Lameter , Mel Gorman , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com References: <6278d2220806220256g674304ectb945c14e7e09fede@mail.gmail.com> <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214173175 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.54060 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: 16459 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 [added xfs@oss.sgi.com to cc] On Sun, Jun 22, 2008 at 10:58:56AM +0100, Daniel J Blueman wrote: > I'm seeing a similar issue [2] to what was recently reported [1] by > Alexander, but with another workload involving XFS and memory > pressure. > > SLUB allocator is in use and config is at http://quora.org/config-client-debug . > > Let me know if you'd like more details/vmlinux objdump etc. > > Thanks, > Daniel > > --- [1] > > http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/e673c9173d45a735/db9213ef39e4e11c > > --- [2] > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.26-rc7-210c #2 > ------------------------------------------------------- > AutopanoPro/4470 is trying to acquire lock: > (iprune_mutex){--..}, at: [] shrink_icache_memory+0x7d/0x290 > > but task is already holding lock: > (&mm->mmap_sem){----}, at: [] do_page_fault+0x255/0x890 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #2 (&mm->mmap_sem){----}: > [] __lock_acquire+0xbdd/0x1020 > [] lock_acquire+0x65/0x90 > [] down_read+0x3b/0x70 > [] do_page_fault+0x27c/0x890 > [] error_exit+0x0/0xa9 > [] 0xffffffffffffffff > > -> #1 (&(&ip->i_iolock)->mr_lock){----}: > [] __lock_acquire+0xbdd/0x1020 > [] lock_acquire+0x65/0x90 > [] down_write_nested+0x46/0x80 > [] xfs_ilock+0x99/0xa0 > [] xfs_ireclaim+0x3f/0x90 > [] xfs_finish_reclaim+0x59/0x1a0 > [] xfs_reclaim+0x109/0x110 > [] xfs_fs_clear_inode+0xe1/0x110 > [] clear_inode+0x7d/0x110 > [] dispose_list+0x2a/0x100 > [] shrink_icache_memory+0x22f/0x290 > [] shrink_slab+0x168/0x1d0 > [] kswapd+0x3b6/0x560 > [] kthread+0x4d/0x80 > [] child_rip+0xa/0x12 > [] 0xffffffffffffffff You may as well ignore anything invlving this path in XFS until lockdep gets fixed. The kswapd reclaim path is inverted over the synchronous reclaim path that is xfs_ilock -> run out of memory -> prune_icache and then potentially another -> xfs_ilock. In this case, XFS can *never* deadlock because the second xfs_ilock is on a different, unreferenced, unlocked inode, but without turning off lockdep there is nothing in XFS that can be done to prevent this warning. Therxp eis a similar bug in the VM w.r.t the mmap_sem in that the mmap_sem is held across a call to put_filp() which can result in inversions between the xfs_ilock and mmap_sem. Both of these cases cannot be solved by changing XFS - lockdep needs to be made aware of paths that can invert normal locking order (like prune_icache) so it doesn't give false positives like this. > -> #0 (iprune_mutex){--..}: > [] __lock_acquire+0xa47/0x1020 > [] lock_acquire+0x65/0x90 > [] mutex_lock_nested+0xb5/0x300 > [] shrink_icache_memory+0x7d/0x290 > [] shrink_slab+0x168/0x1d0 > [] try_to_free_pages+0x268/0x3a0 > [] __alloc_pages_internal+0x206/0x4b0 > [] __alloc_pages_nodemask+0x9/0x10 > [] alloc_page_vma+0x72/0x1b0 > [] handle_mm_fault+0x462/0x7b0 > [] do_page_fault+0x30c/0x890 > [] error_exit+0x0/0xa9 > [] 0xffffffffffffffff This case is different in that it įs complaining about mmap_sem vs iprune_mutex, so I think that we can pretty much ignore the XFS side of things here - the problem is higher level code.... > [] try_to_free_pages+0x268/0x3a0 > [] ? isolate_pages_global+0x0/0x40 > [] __alloc_pages_internal+0x206/0x4b0 > [] __alloc_pages_nodemask+0x9/0x10 > [] alloc_page_vma+0x72/0x1b0 > [] handle_mm_fault+0x462/0x7b0 FWIW, should page allocation in a page fault be allowed to recurse into the filesystem? If I follow the spaghetti of inline and compiler inlined functions correctly, this is a GFP_HIGHUSER_MOVABLE allocation, right? Should we be allowing shrink_icache_memory() to be called at all in the page fault path? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 22 15:28:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 15:29:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5MMSvAB032587 for ; Sun, 22 Jun 2008 15:28:58 -0700 X-ASG-Debug-ID: 1214173795-409900e30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AD4BE2659C3 for ; Sun, 22 Jun 2008 15:29:55 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id kcNUGTCmz1zR2ea1 for ; Sun, 22 Jun 2008 15:29:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJNuXkh5LG+u/2dsb2JhbACtSw X-IronPort-AV: E=Sophos;i="4.27,686,1204464600"; d="scan'208";a="132497445" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 23 Jun 2008 07:59:53 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KAY4G-0003ZN-KX; Mon, 23 Jun 2008 08:29:52 +1000 Date: Mon, 23 Jun 2008 08:29:52 +1000 From: Dave Chinner To: Daniel J Blueman Cc: Arjan van de Ven , Mel Gorman , Christoph Lameter , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Subject: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Message-ID: <20080622222952.GB11558@disturbed> Mail-Followup-To: Daniel J Blueman , Arjan van de Ven , Mel Gorman , Christoph Lameter , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com References: <6278d2220806220256g674304ectb945c14e7e09fede@mail.gmail.com> <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> <20080622181011.GC625@csn.ul.ie> <20080622112100.794b1ae1@infradead.org> <6278d2220806221356o4c611e43n305ec9653d6d5359@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6278d2220806221356o4c611e43n305ec9653d6d5359@mail.gmail.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214173797 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.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54060 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 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: 16460 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 22, 2008 at 09:56:17PM +0100, Daniel J Blueman wrote: > On Sun, Jun 22, 2008 at 7:21 PM, Arjan van de Ven wrote: > > this sort of thing can easily be exposed with the latencytop tool... > > it will at least tell you WHAT the system is blocking on. > > (not so much the why, the tool isn't smart enough to automatically spit > > out kernel patches yet) > > Good plan. I reproduced this without NFS mounted, so pure XFS. I > wasn't able to capture the same process's (ie 5480) latencytop trace, > but it may have contributed to the list. > > A fair amount of debugging was turned on, hurting the latency some > (despite it being a 3.6GHz Penryn). > > Daniel > > --- [1] > > $ vmstat 1 > procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- > r b swpd free buff cache si so bi bo in cs us sy id wa > > 1 1 156 14424 12 2329672 0 0 0 110755 177 3820 57 6 36 0 > 2 1 156 14736 12 2348152 0 0 24 25172 204 26018 35 21 43 1 > 5 0 156 24252 12 2363800 0 0 59656 31 545 25292 35 14 28 23 > 4 0 156 14696 12 2317784 0 0 3824 0 38 23083 95 6 0 0 > 4 0 156 14440 12 2319304 0 0 4672 0 72 3372 93 3 3 2 > 2 0 156 14428 12 2318484 0 0 0 4 27 731 52 0 49 0 > 2 0 156 14480 12 2308512 0 0 0 12 32 36629 39 13 49 0 > 2 0 156 14572 12 2301220 0 0 3904 12316 117 10760 58 7 26 11 > > --- [2] > > Cause Maximum Percentage > down xfs_buf_lock _xfs_buf_find xfs_buf_get_flags 271.1 msec 0.4 % Waiting on I/O to complete. Your disk is busy. > down xfs_buf_iowait xfs_buf_iostart xfs_buf_read_f206.1 msec 1.3 % Waiting on I/O to complete. Your disk is busy. > down xfs_buf_lock xfs_getsb xfs_trans_getsb xfs_tr160.4 msec 0.5 % Waiting on a superblock I/O or a transaction to complete. Your disk is busy. (Note, this one can be avoided with lazy superblock counters). [snip reast of "busy disk trace"] But really, all latencytop is telling you here is that it takes time to wait for I/O to complete. It's mostly useless for tracking down locking issues when you've got I/O in progress... > 2.6.26-rc7-211c #2 > ------------------------------------------------------- > AutopanoPro/5480 is trying to acquire lock: > (iprune_mutex){--..}, at: [] shrink_icache_memory+0x7d/0x280 > > but task is already holding lock: > (&(&ip->i_iolock)->mr_lock){----}, at: [] > xfs_ilock+0xbf/0x110 > > which lock already depends on the new lock. > > the existing dependency chain (in reverse order) is: > > -> #1 (&(&ip->i_iolock)->mr_lock){----}: > [] __lock_acquire+0xbdd/0x1020 > [] lock_acquire+0x65/0x90 > [] down_write_nested+0x4b/0x90 > [] xfs_ilock+0xff/0x110 > [] xfs_ireclaim+0x3f/0x90 > [] xfs_finish_reclaim+0x59/0x220 > [] xfs_reclaim+0x185/0x190 > [] xfs_fs_clear_inode+0xe1/0x130 > [] clear_inode+0x87/0x120 > [] dispose_list+0x2a/0x100 > [] shrink_icache_memory+0x226/0x280 > [] shrink_slab+0x125/0x180 > [] try_to_free_pages+0x232/0x360 > [] __alloc_pages_internal+0x1ed/0x4a0 > [] __alloc_pages+0xb/0x10 > [] handle_mm_fault+0x46a/0x6d0 > [] do_page_fault+0x3ca/0x830 > [] error_exit+0x0/0xa9 > [] 0xffffffffffffffff mmap_sem -> iprune_mutex -> xfs_ilock > -> #0 (iprune_mutex){--..}: > [] __lock_acquire+0xa47/0x1020 > [] lock_acquire+0x65/0x90 > [] mutex_lock_nested+0xba/0x2b0 > [] shrink_icache_memory+0x7d/0x280 > [] shrink_slab+0x125/0x180 > [] try_to_free_pages+0x232/0x360 > [] __alloc_pages_internal+0x1ed/0x4a0 > [] __alloc_pages+0xb/0x10 > [] __do_page_cache_readahead+0x136/0x230 > [] ondemand_readahead+0x128/0x1f0 > [] page_cache_async_readahead+0x75/0xa0 > [] generic_file_aio_read+0x28a/0x610 > [] xfs_read+0x124/0x270 > [] __xfs_file_read+0x46/0x50 > [] xfs_file_aio_read+0x11/0x20 > [] do_sync_read+0xf1/0x130 > [] vfs_read+0xc4/0x160 > [] sys_read+0x50/0x90 > [] system_call_after_swapgs+0x7b/0x80 > [] 0xffffffffffffffff xfs_ilock -> iprune_mutex This is exactly the situation I mentioned in the previous email. There is no potential deadlock here between the xfs_ilock and iprune_mutex as the xfs_ilock that is held before and/or after iprune_mutex is guaranteed to be different (the first is in use so will never be found by shrink_icache_memory())... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 22 15:53:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 15:53: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.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 m5MMr0OB002165 for ; Sun, 22 Jun 2008 15:53:00 -0700 X-ASG-Debug-ID: 1214175238-20ce01690000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 39156D16B31; Sun, 22 Jun 2008 15:53:58 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id dGPAUsM8yrUnivuq; Sun, 22 Jun 2008 15:53:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABdyXkh5LG+u/2dsb2JhbACtTA X-IronPort-AV: E=Sophos;i="4.27,686,1204464600"; d="scan'208";a="132512119" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 23 Jun 2008 08:23:57 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KAYRY-00044k-1B; Mon, 23 Jun 2008 08:53:56 +1000 Date: Mon, 23 Jun 2008 08:53:56 +1000 From: Dave Chinner To: Miquel van Smoorenburg , Oliver Pinter , linux-kernel@vger.kernel.org, Christoph Hellwig , xfs@oss.sgi.com, xfs-masters@oss.sgi.com X-ASG-Orig-Subj: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c Subject: Re: XFS internal error xfs_trans_cancel at line 1163 of file fs/xfs/xfs_trans.c Message-ID: <20080622225355.GD11558@disturbed> Mail-Followup-To: Miquel van Smoorenburg , Oliver Pinter , linux-kernel@vger.kernel.org, Christoph Hellwig , xfs@oss.sgi.com, xfs-masters@oss.sgi.com References: <20080612123031.21594jyk6rjc1lfk@imp.ku-gbr.de> <6101e8c40806120733m3c8647ccy149eb237e2c6d027@mail.gmail.com> <1213309629.29745.8.camel@localhost.localdomain> <20080613030841.GC3700@disturbed> <20080620052716.GA2022@anita> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080620052716.GA2022@anita> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214175240 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.54061 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: 16461 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 20, 2008 at 07:27:17AM +0200, Konstantin Kletschke wrote: > Am 2008-06-13 13:08 +1000 schrieb Dave Chinner: > > > This commit in 2.6.26 will probably fix it. > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=75de2a91c98a6f486f261c1367fe59f5583e15a3 > > If I am correct, this fix is included in 2.6.26-rc6: Yes, so if you're seeing it again then there's a different problem. Please provide a pointer to a xfs_metadump image of the filesystem and the steps to reproduce the error from the image so we can get to the bottom of it... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 22 17:23:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 17:23:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (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 m5N0NLmJ015184 for ; Sun, 22 Jun 2008 17:23:21 -0700 X-ASG-Debug-ID: 1214180657-0ef901ab0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gir.skynet.ie (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5C773265DD7 for ; Sun, 22 Jun 2008 17:24:18 -0700 (PDT) Received: from gir.skynet.ie (gir.skynet.ie [193.1.99.77]) by cuda.sgi.com with ESMTP id CErfTJryR6S6CaXx for ; Sun, 22 Jun 2008 17:24:18 -0700 (PDT) Received: from skynet.skynet.ie (skynet.skynet.ie [193.1.99.74]) by gir.skynet.ie (Postfix) with ESMTP id E980112342; Mon, 23 Jun 2008 01:24:15 +0100 (IST) Received: by skynet.skynet.ie (Postfix, from userid 2391) id BE647100003; Mon, 23 Jun 2008 01:24:15 +0100 (IST) Date: Mon, 23 Jun 2008 01:24:15 +0100 From: Mel Gorman To: Daniel J Blueman , Christoph Lameter , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Subject: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Message-ID: <20080623002415.GB21597@csn.ul.ie> References: <6278d2220806220256g674304ectb945c14e7e09fede@mail.gmail.com> <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> <20080622221930.GA11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20080622221930.GA11558@disturbed> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: gir.skynet.ie[193.1.99.77] X-Barracuda-Start-Time: 1214180659 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.54068 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: 16462 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mel@csn.ul.ie Precedence: bulk X-list: xfs On (23/06/08 08:19), Dave Chinner didst pronounce: > [added xfs@oss.sgi.com to cc] > > On Sun, Jun 22, 2008 at 10:58:56AM +0100, Daniel J Blueman wrote: > > I'm seeing a similar issue [2] to what was recently reported [1] by > > Alexander, but with another workload involving XFS and memory > > pressure. > > > > SLUB allocator is in use and config is at http://quora.org/config-client-debug . > > > > Let me know if you'd like more details/vmlinux objdump etc. > > > > Thanks, > > Daniel > > > > --- [1] > > > > http://groups.google.com/group/fa.linux.kernel/browse_thread/thread/e673c9173d45a735/db9213ef39e4e11c > > > > --- [2] > > > > ======================================================= > > [ INFO: possible circular locking dependency detected ] > > 2.6.26-rc7-210c #2 > > ------------------------------------------------------- > > AutopanoPro/4470 is trying to acquire lock: > > (iprune_mutex){--..}, at: [] shrink_icache_memory+0x7d/0x290 > > > > but task is already holding lock: > > (&mm->mmap_sem){----}, at: [] do_page_fault+0x255/0x890 > > > > which lock already depends on the new lock. > > > > > > the existing dependency chain (in reverse order) is: > > > > -> #2 (&mm->mmap_sem){----}: > > [] __lock_acquire+0xbdd/0x1020 > > [] lock_acquire+0x65/0x90 > > [] down_read+0x3b/0x70 > > [] do_page_fault+0x27c/0x890 > > [] error_exit+0x0/0xa9 > > [] 0xffffffffffffffff > > > > -> #1 (&(&ip->i_iolock)->mr_lock){----}: > > [] __lock_acquire+0xbdd/0x1020 > > [] lock_acquire+0x65/0x90 > > [] down_write_nested+0x46/0x80 > > [] xfs_ilock+0x99/0xa0 > > [] xfs_ireclaim+0x3f/0x90 > > [] xfs_finish_reclaim+0x59/0x1a0 > > [] xfs_reclaim+0x109/0x110 > > [] xfs_fs_clear_inode+0xe1/0x110 > > [] clear_inode+0x7d/0x110 > > [] dispose_list+0x2a/0x100 > > [] shrink_icache_memory+0x22f/0x290 > > [] shrink_slab+0x168/0x1d0 > > [] kswapd+0x3b6/0x560 > > [] kthread+0x4d/0x80 > > [] child_rip+0xa/0x12 > > [] 0xffffffffffffffff > > You may as well ignore anything invlving this path in XFS until > lockdep gets fixed. The kswapd reclaim path is inverted over the > synchronous reclaim path that is xfs_ilock -> run out of memory -> > prune_icache and then potentially another -> xfs_ilock. > In that case, have you any theory as to why this circular dependency is being reported now but wasn't before 2.6.26-rc1? I'm beginning to wonder if the bisecting fingering the zonelist modifiation is just a co-incidence. Also, do you think the stalls were happening before but just not being noticed? > In this case, XFS can *never* deadlock because the second xfs_ilock > is on a different, unreferenced, unlocked inode, but without turning > off lockdep there is nothing in XFS that can be done to prevent > this warning. > > Therxp eis a similar bug in the VM w.r.t the mmap_sem in that the > mmap_sem is held across a call to put_filp() which can result in > inversions between the xfs_ilock and mmap_sem. > > Both of these cases cannot be solved by changing XFS - lockdep > needs to be made aware of paths that can invert normal locking > order (like prune_icache) so it doesn't give false positives > like this. > > > -> #0 (iprune_mutex){--..}: > > [] __lock_acquire+0xa47/0x1020 > > [] lock_acquire+0x65/0x90 > > [] mutex_lock_nested+0xb5/0x300 > > [] shrink_icache_memory+0x7d/0x290 > > [] shrink_slab+0x168/0x1d0 > > [] try_to_free_pages+0x268/0x3a0 > > [] __alloc_pages_internal+0x206/0x4b0 > > [] __alloc_pages_nodemask+0x9/0x10 > > [] alloc_page_vma+0x72/0x1b0 > > [] handle_mm_fault+0x462/0x7b0 > > [] do_page_fault+0x30c/0x890 > > [] error_exit+0x0/0xa9 > > [] 0xffffffffffffffff > > This case is different in that it ??s complaining about mmap_sem vs > iprune_mutex, so I think that we can pretty much ignore the XFS side > of things here - the problem is higher level code.... > > > [] try_to_free_pages+0x268/0x3a0 > > [] ? isolate_pages_global+0x0/0x40 > > [] __alloc_pages_internal+0x206/0x4b0 > > [] __alloc_pages_nodemask+0x9/0x10 > > [] alloc_page_vma+0x72/0x1b0 > > [] handle_mm_fault+0x462/0x7b0 > > FWIW, should page allocation in a page fault be allowed to recurse > into the filesystem? If I follow the spaghetti of inline and > compiler inlined functions correctly, this is a GFP_HIGHUSER_MOVABLE > allocation, right? Should we be allowing shrink_icache_memory() > to be called at all in the page fault path? > Well, the page fault path is able to go to sleep and can enter direct reclaim under low memory situations. Right now, I'm failing to see why a page fault should not be allowed to reclaim pages in use by a filesystem. It was allowed before so the question still is why the circular lock warning appears now but didn't before. > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab From owner-xfs@oss.sgi.com Sun Jun 22 17:53:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 17:53: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.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N0r2rh017842 for ; Sun, 22 Jun 2008 17:53:03 -0700 X-ASG-Debug-ID: 1214182441-2dea011a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B3FD2265F21 for ; Sun, 22 Jun 2008 17:54:01 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id sJBCRN7V3MyqTZ4c for ; Sun, 22 Jun 2008 17:54:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAACOXkh5LG+u/2dsb2JhbACuAA X-IronPort-AV: E=Sophos;i="4.27,686,1204464600"; d="scan'208";a="132610942" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 23 Jun 2008 10:24:00 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KAaJj-0006xt-2Q; Mon, 23 Jun 2008 10:53:59 +1000 Date: Mon, 23 Jun 2008 10:53:59 +1000 From: Dave Chinner To: Mel Gorman Cc: Daniel J Blueman , Christoph Lameter , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Subject: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Message-ID: <20080623005359.GC29319@disturbed> Mail-Followup-To: Mel Gorman , Daniel J Blueman , Christoph Lameter , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com References: <6278d2220806220256g674304ectb945c14e7e09fede@mail.gmail.com> <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> <20080622221930.GA11558@disturbed> <20080623002415.GB21597@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080623002415.GB21597@csn.ul.ie> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214182442 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.54070 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: 16463 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 23, 2008 at 01:24:15AM +0100, Mel Gorman wrote: > On (23/06/08 08:19), Dave Chinner didst pronounce: > > [added xfs@oss.sgi.com to cc] > > > > On Sun, Jun 22, 2008 at 10:58:56AM +0100, Daniel J Blueman wrote: > > > I'm seeing a similar issue [2] to what was recently reported [1] by > > > Alexander, but with another workload involving XFS and memory > > > pressure. [....] > > You may as well ignore anything invlving this path in XFS until > > lockdep gets fixed. The kswapd reclaim path is inverted over the > > synchronous reclaim path that is xfs_ilock -> run out of memory -> > > prune_icache and then potentially another -> xfs_ilock. > > > > In that case, have you any theory as to why this circular dependency is > being reported now but wasn't before 2.6.26-rc1? I'm beginning to wonder > if the bisecting fingering the zonelist modifiation is just a > co-incidence. Probably co-incidence. Perhaps it's simply changed the way reclaim is behaving and we are more likely to be trimming slab caches instead of getting free pages from the page lists? > Also, do you think the stalls were happening before but just not > being noticed? Entirely possible, I think, but I know of no evidence one way or another. [....] > > FWIW, should page allocation in a page fault be allowed to recurse > > into the filesystem? If I follow the spaghetti of inline and > > compiler inlined functions correctly, this is a GFP_HIGHUSER_MOVABLE > > allocation, right? Should we be allowing shrink_icache_memory() > > to be called at all in the page fault path? > > Well, the page fault path is able to go to sleep and can enter direct > reclaim under low memory situations. Right now, I'm failing to see why a > page fault should not be allowed to reclaim pages in use by a > filesystem. It was allowed before so the question still is why the > circular lock warning appears now but didn't before. Yeah, it's the fact that this is the first time that this lockdep warning has come up that prompted me to ask the question. I know that we are not allowed to lock an inode in the fault path as that can lead to deadlocks in the read and write paths, so what I was really wondering is if we can deadlock in a more convoluted manner by taking locks on *other inodes* in the page fault path.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 22 21:42:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 21:42:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from itchy (itchy.melbourne.sgi.com [134.14.55.96]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N4gJA0017141 for ; Sun, 22 Jun 2008 21:42:20 -0700 Received: by itchy (Postfix, from userid 16403) id 1651B42249; Mon, 23 Jun 2008 14:42:30 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Cc: Niv Sardi Subject: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Date: Mon, 23 Jun 2008 14:42:28 +1000 Message-Id: <1214196150-5427-3-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214196150-5427-2-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16468 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Move it from the attr code to the transaction code and make the attr code call the new function. We rolltrans is really usefull whenever we want to use rolling transaction, should be generic, it isn't dependent on any part of the attr code anyway. Signed-off-by: Niv Sardi --- fs/xfs/xfs_attr.c | 22 ++++++++------- fs/xfs/xfs_attr_leaf.c | 69 ++++------------------------------------------- fs/xfs/xfs_attr_leaf.h | 2 - fs/xfs/xfs_trans.c | 57 +++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_trans.h | 1 + 5 files changed, 76 insertions(+), 75 deletions(-) diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c index 0d19e90..be6bfc4 100644 --- a/fs/xfs/xfs_attr.c +++ b/fs/xfs/xfs_attr.c @@ -389,7 +389,9 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, * Commit the leaf transformation. We'll need another (linked) * transaction to add the new attribute to the leaf. */ - if ((error = xfs_attr_rolltrans(&args.trans, dp))) + + error = xfs_trans_roll(&args.trans, dp); + if (error) goto out; } @@ -1019,7 +1021,7 @@ xfs_attr_leaf_addname(xfs_da_args_t *args) * Commit the current trans (including the inode) and start * a new one. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + if ((error = xfs_trans_roll(&args->trans, dp))) return (error); /* @@ -1033,7 +1035,7 @@ xfs_attr_leaf_addname(xfs_da_args_t *args) * Commit the transaction that added the attr name so that * later routines can manage their own transactions. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + if ((error = xfs_trans_roll(&args->trans, dp))) return (error); /* @@ -1122,7 +1124,7 @@ xfs_attr_leaf_addname(xfs_da_args_t *args) /* * Commit the remove and start the next trans in series. */ - error = xfs_attr_rolltrans(&args->trans, dp); + error = xfs_trans_roll(&args->trans, dp); } else if (args->rmtblkno > 0) { /* @@ -1353,7 +1355,7 @@ restart: * Commit the node conversion and start the next * trans in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + if ((error = xfs_trans_roll(&args->trans, dp))) goto out; goto restart; @@ -1404,7 +1406,7 @@ restart: * Commit the leaf addition or btree split and start the next * trans in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + if ((error = xfs_trans_roll(&args->trans, dp))) goto out; /* @@ -1504,7 +1506,7 @@ restart: /* * Commit and start the next trans in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + if ((error = xfs_trans_roll(&args->trans, dp))) goto out; } else if (args->rmtblkno > 0) { @@ -1636,7 +1638,7 @@ xfs_attr_node_removename(xfs_da_args_t *args) /* * Commit the Btree join operation and start a new trans. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + if ((error = xfs_trans_roll(&args->trans, dp))) goto out; } @@ -2137,7 +2139,7 @@ xfs_attr_rmtval_set(xfs_da_args_t *args) /* * Start the next trans in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + if ((error = xfs_trans_roll(&args->trans, dp))) return (error); } @@ -2287,7 +2289,7 @@ xfs_attr_rmtval_remove(xfs_da_args_t *args) /* * Close out trans and start the next one in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, args->dp))) + if ((error = xfs_trans_roll(&args->trans, args->dp))) return (error); } return(0); diff --git a/fs/xfs/xfs_attr_leaf.c b/fs/xfs/xfs_attr_leaf.c index b08e2a2..9465807 100644 --- a/fs/xfs/xfs_attr_leaf.c +++ b/fs/xfs/xfs_attr_leaf.c @@ -2543,7 +2543,7 @@ xfs_attr_leaf_clearflag(xfs_da_args_t *args) /* * Commit the flag value change and start the next trans in series. */ - error = xfs_attr_rolltrans(&args->trans, args->dp); + error = xfs_trans_roll(&args->trans, args->dp); return(error); } @@ -2592,7 +2592,7 @@ xfs_attr_leaf_setflag(xfs_da_args_t *args) /* * Commit the flag value change and start the next trans in series. */ - error = xfs_attr_rolltrans(&args->trans, args->dp); + error = xfs_trans_roll(&args->trans, args->dp); return(error); } @@ -2710,7 +2710,7 @@ xfs_attr_leaf_flipflags(xfs_da_args_t *args) /* * Commit the flag value change and start the next trans in series. */ - error = xfs_attr_rolltrans(&args->trans, args->dp); + error = xfs_trans_roll(&args->trans, args->dp); return(error); } @@ -2768,7 +2768,7 @@ xfs_attr_root_inactive(xfs_trans_t **trans, xfs_inode_t *dp) /* * Commit the invalidate and start the next transaction. */ - error = xfs_attr_rolltrans(trans, dp); + error = xfs_trans_roll(trans, dp); return (error); } @@ -2870,7 +2870,7 @@ xfs_attr_node_inactive(xfs_trans_t **trans, xfs_inode_t *dp, xfs_dabuf_t *bp, /* * Atomically commit the whole invalidate stuff. */ - if ((error = xfs_attr_rolltrans(trans, dp))) + if ((error = xfs_trans_roll(trans, dp))) return (error); } @@ -3009,7 +3009,7 @@ xfs_attr_leaf_freextent(xfs_trans_t **trans, xfs_inode_t *dp, /* * Roll to next transaction. */ - if ((error = xfs_attr_rolltrans(trans, dp))) + if ((error = xfs_trans_roll(trans, dp))) return (error); } @@ -3019,60 +3019,3 @@ xfs_attr_leaf_freextent(xfs_trans_t **trans, xfs_inode_t *dp, return(0); } - - -/* - * Roll from one trans in the sequence of PERMANENT transactions to the next. - */ -int -xfs_attr_rolltrans(xfs_trans_t **transp, xfs_inode_t *dp) -{ - xfs_trans_t *trans; - unsigned int logres, count; - int error; - - /* - * Ensure that the inode is always logged. - */ - trans = *transp; - xfs_trans_log_inode(trans, dp, XFS_ILOG_CORE); - - /* - * Copy the critical parameters from one trans to the next. - */ - logres = trans->t_log_res; - count = trans->t_log_count; - *transp = xfs_trans_dup(trans); - - /* - * Commit the current transaction. - * If this commit failed, then it'd just unlock those items that - * are not marked ihold. That also means that a filesystem shutdown - * is in progress. The caller takes the responsibility to cancel - * the duplicate transaction that gets returned. - */ - if ((error = xfs_trans_commit(trans, 0))) - return (error); - - trans = *transp; - - /* - * Reserve space in the log for th next transaction. - * This also pushes items in the "AIL", the list of logged items, - * out to disk if they are taking up space at the tail of the log - * that we want to use. This requires that either nothing be locked - * across this call, or that anything that is locked be logged in - * the prior and the next transactions. - */ - error = xfs_trans_reserve(trans, 0, logres, 0, - XFS_TRANS_PERM_LOG_RES, count); - /* - * Ensure that the inode is in the new transaction and locked. - */ - if (!error) { - xfs_trans_ijoin(trans, dp, XFS_ILOCK_EXCL); - xfs_trans_ihold(trans, dp); - } - return (error); - -} diff --git a/fs/xfs/xfs_attr_leaf.h b/fs/xfs/xfs_attr_leaf.h index 040f732..698e078 100644 --- a/fs/xfs/xfs_attr_leaf.h +++ b/fs/xfs/xfs_attr_leaf.h @@ -301,6 +301,4 @@ int xfs_attr_leaf_order(struct xfs_dabuf *leaf1_bp, struct xfs_dabuf *leaf2_bp); int xfs_attr_leaf_newentsize(int namelen, int valuelen, int blocksize, int *local); -int xfs_attr_rolltrans(struct xfs_trans **transp, struct xfs_inode *dp); - #endif /* __XFS_ATTR_LEAF_H__ */ diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c index 1403864..9e5e0c2 100644 --- a/fs/xfs/xfs_trans.c +++ b/fs/xfs/xfs_trans.c @@ -43,6 +43,7 @@ #include "xfs_quota.h" #include "xfs_trans_priv.h" #include "xfs_trans_space.h" +#include "xfs_inode_item.h" STATIC void xfs_trans_apply_sb_deltas(xfs_trans_t *); @@ -1216,6 +1217,62 @@ xfs_trans_free( kmem_zone_free(xfs_trans_zone, tp); } +/* + * Roll from one trans in the sequence of PERMANENT transactions to the next. + */ +int +xfs_trans_roll( + xfs_trans_t **tpp, + xfs_inode_t *dp) +{ + xfs_trans_t *trans; + unsigned int logres, count; + int error; + + /* + * Ensure that the inode is always logged. + */ + trans = *tpp; + xfs_trans_log_inode(trans, dp, XFS_ILOG_CORE); + + /* + * Copy the critical parameters from one trans to the next. + */ + logres = trans->t_log_res; + count = trans->t_log_count; + *tpp = xfs_trans_dup(trans); + + /* + * Commit the current transaction. + * If this commit failed, then it'd just unlock those items that + * are not marked ihold. That also means that a filesystem shutdown + * is in progress. The caller takes the responsibility to cancel + * the duplicate transaction that gets returned. + */ + if ((error = xfs_trans_commit(trans, 0))) + return (error); + + trans = *tpp; + + /* + * Reserve space in the log for th next transaction. + * This also pushes items in the "AIL", the list of logged items, + * out to disk if they are taking up space at the tail of the log + * that we want to use. This requires that either nothing be locked + * across this call, or that anything that is locked be logged in + * the prior and the next transactions. + */ + error = xfs_trans_reserve(trans, 0, logres, 0, + XFS_TRANS_PERM_LOG_RES, count); + /* + * Ensure that the inode is in the new transaction and locked. + */ + if (!error) { + xfs_trans_ijoin(trans, dp, XFS_ILOCK_EXCL); + xfs_trans_ihold(trans, dp); + } + return (error); +} /* * THIS SHOULD BE REWRITTEN TO USE xfs_trans_next_item(). diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 7f40628..7b4299e 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -992,6 +992,7 @@ int _xfs_trans_commit(xfs_trans_t *, int *); #define xfs_trans_commit(tp, flags) _xfs_trans_commit(tp, flags, NULL) void xfs_trans_cancel(xfs_trans_t *, int); +int xfs_trans_roll(struct xfs_trans **, struct xfs_inode *); int xfs_trans_ail_init(struct xfs_mount *); void xfs_trans_ail_destroy(struct xfs_mount *); void xfs_trans_push_ail(struct xfs_mount *, xfs_lsn_t); -- 1.5.5.4 From owner-xfs@oss.sgi.com Sun Jun 22 21:42:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 21:42:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from itchy (itchy.melbourne.sgi.com [134.14.55.96]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N4gJ2A017142 for ; Sun, 22 Jun 2008 21:42:20 -0700 Received: by itchy (Postfix, from userid 16403) id 1F23E4224A; Mon, 23 Jun 2008 14:42:30 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Cc: Niv Sardi Subject: [PATCH] Introduce xfs_trans_bmap_add_attrfork. Date: Mon, 23 Jun 2008 14:42:29 +1000 Message-Id: <1214196150-5427-4-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214196150-5427-3-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16467 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs That takes a transaction and doesn't require everything to be locked anymore. this uses the roll trans call. Signed-off-by: Niv Sardi --- fs/xfs/xfs_bmap.c | 79 ++++++++++++++++++++++++++++++++++------------------- fs/xfs/xfs_bmap.h | 7 +++++ 2 files changed, 58 insertions(+), 28 deletions(-) diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c index 1c0a5a5..c5cfbcb 100644 --- a/fs/xfs/xfs_bmap.c +++ b/fs/xfs/xfs_bmap.c @@ -3941,12 +3941,22 @@ xfs_bunmap_trace( } #endif +int +xfs_bmap_add_attrfork( + xfs_inode_t *ip, /* incore inode pointer */ + int size, /* space new attribute needs */ + int rsvd) /* xact may use reserved blks */ +{ + return xfs_trans_bmap_add_attrfork(NULL, ip, size, rsvd); +} + /* * Convert inode from non-attributed to attributed. * Must not be in a transaction, ip must not be locked. */ int /* error code */ -xfs_bmap_add_attrfork( +xfs_trans_bmap_add_attrfork( + xfs_trans_t **tpp, /* transaction pointer */ xfs_inode_t *ip, /* incore inode pointer */ int size, /* space new attribute needs */ int rsvd) /* xact may use reserved blks */ @@ -3967,24 +3977,33 @@ xfs_bmap_add_attrfork( mp = ip->i_mount; ASSERT(!XFS_NOT_DQATTACHED(mp, ip)); - tp = xfs_trans_alloc(mp, XFS_TRANS_ADDAFORK); - blks = XFS_ADDAFORK_SPACE_RES(mp); - if (rsvd) - tp->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(tp, blks, XFS_ADDAFORK_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT))) - goto error0; - xfs_ilock(ip, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? - XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : - XFS_QMOPT_RES_REGBLKS); - if (error) { - xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES); - return error; + if (tpp) { + ASSERT(*tpp); + tp = *tpp; + } else { + tp = xfs_trans_alloc(mp, XFS_TRANS_ADDAFORK); + blks = XFS_ADDAFORK_SPACE_RES(mp); + if (rsvd) + tp->t_flags |= XFS_TRANS_RESERVE; + if ((error = xfs_trans_reserve(tp, blks, XFS_ADDAFORK_LOG_RES(mp), 0, + XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT))) + goto error0; + xfs_ilock(ip, XFS_ILOCK_EXCL); + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? + XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + XFS_QMOPT_RES_REGBLKS); + if (error) { + xfs_iunlock(ip, XFS_ILOCK_EXCL); + xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES); + return error; + } + if (XFS_IFORK_Q(ip)) + goto error1; + ASSERT(ip->i_d.di_anextents == 0); + VN_HOLD(XFS_ITOV(ip)); + xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); } - if (XFS_IFORK_Q(ip)) - goto error1; if (ip->i_d.di_aformat != XFS_DINODE_FMT_EXTENTS) { /* * For inodes coming from pre-6.2 filesystems. @@ -3992,10 +4011,7 @@ xfs_bmap_add_attrfork( ASSERT(ip->i_d.di_aformat == 0); ip->i_d.di_aformat = XFS_DINODE_FMT_EXTENTS; } - ASSERT(ip->i_d.di_anextents == 0); - VN_HOLD(XFS_ITOV(ip)); - xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); - xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); + switch (ip->i_d.di_format) { case XFS_DINODE_FMT_DEV: ip->i_d.di_forkoff = roundup(sizeof(xfs_dev_t), 8) >> 3; @@ -4060,23 +4076,30 @@ xfs_bmap_add_attrfork( XFS_SB_VERSION_ADDATTR2(&mp->m_sb); sbfields |= (XFS_SB_VERSIONNUM | XFS_SB_FEATURES2); } - if (sbfields) { - spin_unlock(&mp->m_sb_lock); + spin_unlock(&mp->m_sb_lock); + if (sbfields) xfs_mod_sb(tp, sbfields); - } else - spin_unlock(&mp->m_sb_lock); } if ((error = xfs_bmap_finish(&tp, &flist, &committed))) goto error2; - error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); + if (tpp) { + error = xfs_trans_roll(&tp, ip); + } else { + error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); + } ASSERT(ip->i_df.if_ext_max == XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); return error; error2: + if (tpp) + tpp = &tp; xfs_bmap_cancel(&flist); error1: ASSERT(ismrlocked(&ip->i_lock,MR_UPDATE)); - xfs_iunlock(ip, XFS_ILOCK_EXCL); + if (tpp) + tpp = &tp; + else + xfs_iunlock(ip, XFS_ILOCK_EXCL); error0: xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_ABORT); ASSERT(ip->i_df.if_ext_max == diff --git a/fs/xfs/xfs_bmap.h b/fs/xfs/xfs_bmap.h index 87224b7..7a21e41 100644 --- a/fs/xfs/xfs_bmap.h +++ b/fs/xfs/xfs_bmap.h @@ -166,6 +166,13 @@ xfs_bmap_add_attrfork( int size, /* space needed for new attribute */ int rsvd); /* flag for reserved block allocation */ +int /* error code */ +xfs_trans_bmap_add_attrfork( + struct xfs_trans **tpp, /* transaction */ + struct xfs_inode *ip, /* incore inode pointer */ + int size, /* space needed for new attribute */ + int rsvd); /* flag for reserved block allocation */ + /* * Add the extent to the list of extents to be free at transaction end. * The list is maintained sorted (by block number). -- 1.5.5.4 From owner-xfs@oss.sgi.com Sun Jun 22 21:42:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 21:42:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from itchy (itchy.melbourne.sgi.com [134.14.55.96]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N4gJEE017140 for ; Sun, 22 Jun 2008 21:42:20 -0700 Received: by itchy (Postfix, from userid 16403) id EB3F442248; Mon, 23 Jun 2008 14:42:30 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Cc: Niv Sardi , Niv Sardi Subject: [PATCH] Move attr log alloc size calculator to another function. Date: Mon, 23 Jun 2008 14:42:27 +1000 Message-Id: <1214196150-5427-2-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214196150-5427-1-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16465 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs From: Niv Sardi We will need that to be able to calculate the size of log we need for a specific attr (for parent pointers in create). We need the local so that we can fail if we run into ENOSPC when trying to alloc blocks Signed-off-by: Niv Sardi --- fs/xfs/xfs_attr.c | 78 +++++++++++++++++++++++++++++++--------------------- fs/xfs/xfs_attr.h | 2 +- 2 files changed, 47 insertions(+), 33 deletions(-) diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c index e58f321..0d19e90 100644 --- a/fs/xfs/xfs_attr.c +++ b/fs/xfs/xfs_attr.c @@ -185,6 +185,43 @@ xfs_attr_get( } int +xfs_attr_calc_size( + xfs_inode_t *ip, + int namelen, + int valuelen, + int *local) +{ + xfs_mount_t *mp = ip->i_mount; + int size; + int nblks; + + /* + * Determine space new attribute will use, and if it would be + * "local" or "remote" (note: local != inline). + */ + size = xfs_attr_leaf_newentsize(namelen, valuelen, + mp->m_sb.sb_blocksize, local); + + nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); + if (*local) { + if (size > (mp->m_sb.sb_blocksize >> 1)) { + /* Double split possible */ + nblks <<= 1; + } + } else { + /* + * Out of line attribute, cannot double split, but + * make room for the attribute value itself. + */ + uint dblocks = XFS_B_TO_FSB(mp, valuelen); + nblks += dblocks; + nblks += XFS_NEXTENTADD_SPACE_RES(mp, dblocks, XFS_ATTR_FORK); + } + + return nblks; +} + +int xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, char *value, int valuelen, int flags) { @@ -192,10 +229,9 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, xfs_fsblock_t firstblock; xfs_bmap_free_t flist; int error, err2, committed; - int local, size; - uint nblks; xfs_mount_t *mp = dp->i_mount; int rsvd = (flags & ATTR_ROOT) != 0; + int local; /* * Attach the dquots to the inode. @@ -232,30 +268,8 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, args.addname = 1; args.oknoent = 1; - /* - * Determine space new attribute will use, and if it would be - * "local" or "remote" (note: local != inline). - */ - size = xfs_attr_leaf_newentsize(namelen, valuelen, - mp->m_sb.sb_blocksize, &local); - - nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); - if (local) { - if (size > (mp->m_sb.sb_blocksize >> 1)) { - /* Double split possible */ - nblks <<= 1; - } - } else { - uint dblocks = XFS_B_TO_FSB(mp, valuelen); - /* Out of line attribute, cannot double split, but make - * room for the attribute value itself. - */ - nblks += dblocks; - nblks += XFS_NEXTENTADD_SPACE_RES(mp, dblocks, XFS_ATTR_FORK); - } - /* Size is now blocks for attribute data */ - args.total = nblks; + args.total = xfs_attr_calc_size(dp, namelen, valuelen, &local); /* * Start our first transaction of the day. @@ -277,18 +291,18 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, if (rsvd) args.trans->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(args.trans, (uint) nblks, - XFS_ATTRSET_LOG_RES(mp, nblks), - 0, XFS_TRANS_PERM_LOG_RES, - XFS_ATTRSET_LOG_COUNT))) { + if ((error = xfs_trans_reserve(args.trans, (uint) args.total, + XFS_ATTRSET_LOG_RES(mp, args.total), + 0, XFS_TRANS_PERM_LOG_RES, + XFS_ATTRSET_LOG_COUNT))) { xfs_trans_cancel(args.trans, 0); return(error); } xfs_ilock(dp, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, nblks, 0, - rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : - XFS_QMOPT_RES_REGBLKS); + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, args.total, 0, + rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + XFS_QMOPT_RES_REGBLKS); if (error) { xfs_iunlock(dp, XFS_ILOCK_EXCL); xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES); diff --git a/fs/xfs/xfs_attr.h b/fs/xfs/xfs_attr.h index 786eba3..b0b5405 100644 --- a/fs/xfs/xfs_attr.h +++ b/fs/xfs/xfs_attr.h @@ -158,11 +158,11 @@ struct xfs_da_args; /* * Overall external interface routines. */ +int xfs_attr_calc_size(struct xfs_inode *, int, int, int *); int xfs_attr_set_int(struct xfs_inode *, const char *, int, char *, int, int); int xfs_attr_remove_int(struct xfs_inode *, const char *, int, int); int xfs_attr_list_int(struct xfs_attr_list_context *); int xfs_attr_inactive(struct xfs_inode *dp); - int xfs_attr_shortform_getvalue(struct xfs_da_args *); int xfs_attr_fetch(struct xfs_inode *, const char *, int, char *, int *, int, struct cred *); -- 1.5.5.4 From owner-xfs@oss.sgi.com Sun Jun 22 21:42:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 21:42:27 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from itchy (itchy.melbourne.sgi.com [134.14.55.96]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N4gJ8C017139 for ; Sun, 22 Jun 2008 21:42:20 -0700 Received: by itchy (Postfix, from userid 16403) id C414842247; Mon, 23 Jun 2008 14:42:30 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Subject: [RFC] Create with EA initial work Date: Mon, 23 Jun 2008 14:42:26 +1000 Message-Id: <1214196150-5427-1-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.5.4 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: 16464 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Here's a dump of current work for Create+EA, this is buggy, it's dropped out as I'm a bit busy and some people out there might be interested in having a look. These set of patches will move things around to make it possible to pass a transaction down to the EA subsystem on create, but it seemed to need more love. Comments are welcome. From owner-xfs@oss.sgi.com Sun Jun 22 21:42:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 21:42:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_65 autolearn=no version=3.3.0-r574664 Received: from itchy (itchy.melbourne.sgi.com [134.14.55.96]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N4gJQL017143 for ; Sun, 22 Jun 2008 21:42:20 -0700 Received: by itchy (Postfix, from userid 16403) id 246C74224B; Mon, 23 Jun 2008 14:42:30 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Cc: Niv Sardi , Niv Sardi Subject: [PATCH] Give a transaction to xfs_attr_set_int Date: Mon, 23 Jun 2008 14:42:30 +1000 Message-Id: <1214196150-5427-5-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214196150-5427-4-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <1214196150-5427-4-git-send-email-xaiki@sgi.com> X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16466 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs From: Niv Sardi We introduce xfs_trans_attr_set_int that takes a transaction pointer as an argument (or creates one if NULL) and only finishes the transaction if it has created it. We use xfs_attr_rolltrans to do the tranS_dup dance. xfs_attr_set_int is changed to a wrapper that will only call xfs_trans_attr_set_int with a NULL transaction. make it use the new xfs_trans_bmap_add_attrfork(); This is needed for Create+EA/Parent Pointers Signed-off-by: Niv Sardi --- fs/xfs/xfs_attr.c | 140 +++++++++++++++++++++++++++++++++++----------------- fs/xfs/xfs_attr.h | 2 + 2 files changed, 96 insertions(+), 46 deletions(-) diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c index be6bfc4..a4787f7 100644 --- a/fs/xfs/xfs_attr.c +++ b/fs/xfs/xfs_attr.c @@ -209,7 +209,7 @@ xfs_attr_calc_size( nblks <<= 1; } } else { - /* + /* * Out of line attribute, cannot double split, but * make room for the attribute value itself. */ @@ -221,9 +221,20 @@ xfs_attr_calc_size( return nblks; } +/* + * So if the trans is given we don't have the right to dispose of it, + * we can't commit it either as we don't know if the upper class is + * done with it. + */ int -xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, - char *value, int valuelen, int flags) +xfs_trans_attr_set_int( + xfs_trans_t **tpp, + xfs_inode_t *dp, + const char *name, + int namelen, + char *value, + int valuelen, + int flags) { xfs_da_args_t args; xfs_fsblock_t firstblock; @@ -247,8 +258,9 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, int sf_size = sizeof(xfs_attr_sf_hdr_t) + XFS_ATTR_SF_ENTSIZE_BYNAME(namelen, valuelen); - if ((error = xfs_bmap_add_attrfork(dp, sf_size, rsvd))) - return(error); + error = xfs_trans_bmap_add_attrfork(tpp, dp, sf_size, rsvd); + if (error) + return error; } /* @@ -271,46 +283,53 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, /* Size is now blocks for attribute data */ args.total = xfs_attr_calc_size(dp, namelen, valuelen, &local); - /* - * Start our first transaction of the day. - * - * All future transactions during this code must be "chained" off - * this one via the trans_dup() call. All transactions will contain - * the inode, and the inode will always be marked with trans_ihold(). - * Since the inode will be locked in all transactions, we must log - * the inode in every transaction to let it float upward through - * the log. - */ - args.trans = xfs_trans_alloc(mp, XFS_TRANS_ATTR_SET); + if (tpp) { + ASSERT(*tpp); + args.trans = *tpp; + } else { + /* + * Start our first transaction of the day. + * + * All future transactions during this code must be "chained" off + * this one via the trans_dup() call. All transactions will contain + * the inode, and the inode will always be marked with trans_ihold(). + * Since the inode will be locked in all transactions, we must log + * the inode in every transaction to let it float upward through + * the log. + */ + args.trans = xfs_trans_alloc(mp, XFS_TRANS_ATTR_SET); - /* - * Root fork attributes can use reserved data blocks for this - * operation if necessary - */ + /* + * Root fork attributes can use reserved data blocks for this + * operation if necessary + */ - if (rsvd) - args.trans->t_flags |= XFS_TRANS_RESERVE; + if (rsvd) + args.trans->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(args.trans, (uint) args.total, - XFS_ATTRSET_LOG_RES(mp, args.total), - 0, XFS_TRANS_PERM_LOG_RES, - XFS_ATTRSET_LOG_COUNT))) { - xfs_trans_cancel(args.trans, 0); - return(error); - } - xfs_ilock(dp, XFS_ILOCK_EXCL); + error = xfs_trans_reserve(args.trans, args.total, + XFS_ATTRSET_LOG_RES(mp, args.total), + 0, XFS_TRANS_PERM_LOG_RES, + XFS_ATTRSET_LOG_COUNT); + if (error) { + xfs_trans_cancel(args.trans, 0); + return(error); + } + xfs_ilock(dp, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, args.total, 0, - rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, + args.total, 0, + rsvd?XFS_QMOPT_RES_REGBLKS|XFS_QMOPT_FORCE_RES: XFS_QMOPT_RES_REGBLKS); - if (error) { - xfs_iunlock(dp, XFS_ILOCK_EXCL); - xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES); - return (error); - } + if (error) { + xfs_iunlock(dp, XFS_ILOCK_EXCL); + xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES); + return (error); + } - xfs_trans_ijoin(args.trans, dp, XFS_ILOCK_EXCL); - xfs_trans_ihold(args.trans, dp); + xfs_trans_ijoin(args.trans, dp, XFS_ILOCK_EXCL); + xfs_trans_ihold(args.trans, dp); + } /* * If the attribute list is non-existent or a shortform list, @@ -346,8 +365,14 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, if (mp->m_flags & XFS_MOUNT_WSYNC) { xfs_trans_set_sync(args.trans); } - err2 = xfs_trans_commit(args.trans, - XFS_TRANS_RELEASE_LOG_RES); + + /* Only finish trans if it's ours */ + if (tpp) { + err2 = xfs_trans_roll(&args.trans, dp); + } else { + err2 = xfs_trans_commit(args.trans, + XFS_TRANS_RELEASE_LOG_RES); + } xfs_iunlock(dp, XFS_ILOCK_EXCL); /* @@ -356,6 +381,8 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, if (!error && (flags & ATTR_KERNOTIME) == 0) { xfs_ichgtime(dp, XFS_ICHGTIME_CHG); } + if (tpp) + tpp = &args.trans; return(error == 0 ? err2 : error); } @@ -401,13 +428,13 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, } else { error = xfs_attr_node_addname(&args); } - if (error) { + if (error) goto out; - } /* * If this is a synchronous mount, make sure that the - * transaction goes to disk before returning to the user. + * transaction goes to disk before returning to the user. If + * this is not our transaction, the allocator should do this. */ if (mp->m_flags & XFS_MOUNT_WSYNC) { xfs_trans_set_sync(args.trans); @@ -416,8 +443,12 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, /* * Commit the last in the sequence of transactions. */ - xfs_trans_log_inode(args.trans, dp, XFS_ILOG_CORE); - error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES); + if (tpp) { + xfs_trans_roll(&args.trans, dp); + } else { + xfs_trans_log_inode(args.trans, dp, XFS_ILOG_CORE); + error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES); + } xfs_iunlock(dp, XFS_ILOCK_EXCL); /* @@ -427,6 +458,8 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, xfs_ichgtime(dp, XFS_ICHGTIME_CHG); } + if (tpp) + tpp = &args.trans; return(error); out: @@ -434,10 +467,25 @@ out: xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_ABORT); xfs_iunlock(dp, XFS_ILOCK_EXCL); + if (tpp) + tpp = &args.trans; return(error); } int +xfs_attr_set_int( + xfs_inode_t *dp, + const char *name, + int namelen, + char *value, + int valuelen, + int flags) +{ + return xfs_trans_attr_set_int(NULL, dp, name, namelen, + value, valuelen, flags); +} + +int xfs_attr_set( xfs_inode_t *dp, const char *name, diff --git a/fs/xfs/xfs_attr.h b/fs/xfs/xfs_attr.h index b0b5405..c076c85 100644 --- a/fs/xfs/xfs_attr.h +++ b/fs/xfs/xfs_attr.h @@ -160,6 +160,8 @@ struct xfs_da_args; */ int xfs_attr_calc_size(struct xfs_inode *, int, int, int *); int xfs_attr_set_int(struct xfs_inode *, const char *, int, char *, int, int); + int xfs_trans_attr_set_int(struct xfs_trans **, struct xfs_inode *, const char *, + int, char *, int, int); int xfs_attr_remove_int(struct xfs_inode *, const char *, int, int); int xfs_attr_list_int(struct xfs_attr_list_context *); int xfs_attr_inactive(struct xfs_inode *dp); -- 1.5.5.4 From owner-xfs@oss.sgi.com Sun Jun 22 22:19:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 22:19:32 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_47 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 m5N5JVDC023950 for ; Sun, 22 Jun 2008 22:19:31 -0700 X-ASG-Debug-ID: 1214198429-0b4d01410000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 37FE3266580 for ; Sun, 22 Jun 2008 22:20:30 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id I4qmFrtWsKncSuKX for ; Sun, 22 Jun 2008 22:20:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAH/NXkh5LG+u/2dsb2JhbACuOw X-IronPort-AV: E=Sophos;i="4.27,687,1204464600"; d="scan'208";a="132822810" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 23 Jun 2008 14:50:26 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KAeTZ-0002q4-GK; Mon, 23 Jun 2008 15:20:25 +1000 Date: Mon, 23 Jun 2008 15:20:25 +1000 From: Dave Chinner To: Lachlan McIlroy , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080623052025.GF29319@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> <485A0AB2.4060009@sgi.com> <20080620052120.GA3700@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080620052120.GA3700@disturbed> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214198431 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.54087 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: 16469 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 20, 2008 at 03:21:20PM +1000, Dave Chinner wrote: > On Thu, Jun 19, 2008 at 05:28:50PM +1000, Lachlan McIlroy wrote: > > Dave Chinner wrote: > >> On Tue, Jun 17, 2008 at 11:58:47AM +1000, Lachlan McIlroy wrote: > >>> Dave Chinner wrote: > >>>> On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: > >>>>> I'm well aware of that particular deadlock involving the freelist - I > >>>>> hit it while testing. If you look closely at the code that deadlock > >>>>> can occur with or without the AG locking avoidance logic. This is > >>>>> because the rest of the transaction is unaware that an AG has been > >>>>> locked due to a freelist operation. > >>>> Yes, which is why you need to prevent freelist modifications occurring > >>>> when you can't allocate anything out of the AG. > >>> That sounds reasonable but it isn't consistent with the deadlock I saw. > >>> One of the threads that was deadlocked had tried to allocate a data extent > >>> in AG3 but didn't find the space. It had modified, and hence locked, AG3 > >>> due to modifying the freelist but since it didn't get the space it needed > >>> it had to go on to another AG. > >> > >> That sounds like an exact allocation failure - there is enough > >> space, a large enough extent but no free space at the exact block > >> required. This is exactly the case that occurred with the inode > >> allocation - and then allocation in the same AG failed because of > >> alignment that wasn't taken into account by the first exact > >> allocation attempt. Perhaps the minalignslop calculation in > >> xfs_bmap_btalloc() is incorrect... > > > > Okay I'll look into that. > > > > There's something else that looks suspicious to me - this code in > > xfs_bmap_btalloc() is setting minleft to 0. Doesn't this go against > > what you were saying about setting minleft to be the space we might > > need for the btree operations? > > > > if (args.fsbno == NULLFSBLOCK && nullfb) { > > args.fsbno = 0; > > args.type = XFS_ALLOCTYPE_FIRST_AG; > > args.total = ap->minlen; > > args.minleft = 0; > > if ((error = xfs_alloc_vextent(&args))) > > return error; > > ap->low = 1; > > } > > Hmmm - that looks suspicious. In xfs_bmapi(), when we are doing a > write and *firstblock == NULLFSBLOCK (which leads to nullfb being > set in the above code), we do: > > if (wr && *firstblock == NULLFSBLOCK) { > if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) > minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; > else > minleft = 1; > } else > minleft = 0; > > If we are in btree format we set the minleft to the number of blocks needed > for a split. If we are in extent or local format, change to extent of btree > format requires one extra block. > > The above code you point out definitely breaks this - we haven't done a > previous allocation so we can start from the first AG, but we sure as > hell still need minleft set to the number of blocks needed for a > format change or btree split. Just to point out yet another problem in this code (one that's just been tripped over @ agami) is unwritten extent conversion. Basically, we don't do an allocation here, so when we end up in xfs_bmap_add_extent_unwritten_real() with a null firstblock. Hence the cases where conversion can cause a split - case MASK(LEFT_FILLING), MASK(RIGHT_FILLING) and 0 (convert the middle of an extent) - we can select an AG that doesn't have enough space for the entire split as we've ignored the number of blocks we might need to allocate in the split (the minleft parameter) entirely. I suspect that xfs_bmbt_split() needs to handle the null first block case slightly differently - the minleft parameter passed to the allocation should not be zero - it should be the number of levels above the current level left in the tree. i.e: minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; If we've already got a firstblock set, then this should have already been taken into account (i.e. we still need to fix the low space case where it got ignored as we were discussing). Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 22 22:20:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 22:20:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_47,J_CHICKENPOX_48 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5N5K1cb024160 for ; Sun, 22 Jun 2008 22:20:03 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA10796; Mon, 23 Jun 2008 15:20:56 +1000 Message-ID: <485F339D.7090802@sgi.com> Date: Mon, 23 Jun 2008 15:24:45 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> <485A0AB2.4060009@sgi.com> <20080620052120.GA3700@disturbed> In-Reply-To: <20080620052120.GA3700@disturbed> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16470 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Thu, Jun 19, 2008 at 05:28:50PM +1000, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Tue, Jun 17, 2008 at 11:58:47AM +1000, Lachlan McIlroy wrote: >>>> Dave Chinner wrote: >>>>> On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: >>>>>> I'm well aware of that particular deadlock involving the freelist - I >>>>>> hit it while testing. If you look closely at the code that deadlock >>>>>> can occur with or without the AG locking avoidance logic. This is >>>>>> because the rest of the transaction is unaware that an AG has been >>>>>> locked due to a freelist operation. >>>>> Yes, which is why you need to prevent freelist modifications occurring >>>>> when you can't allocate anything out of the AG. >>>> That sounds reasonable but it isn't consistent with the deadlock I saw. >>>> One of the threads that was deadlocked had tried to allocate a data extent >>>> in AG3 but didn't find the space. It had modified, and hence locked, AG3 >>>> due to modifying the freelist but since it didn't get the space it needed >>>> it had to go on to another AG. >>> That sounds like an exact allocation failure - there is enough >>> space, a large enough extent but no free space at the exact block >>> required. This is exactly the case that occurred with the inode >>> allocation - and then allocation in the same AG failed because of >>> alignment that wasn't taken into account by the first exact >>> allocation attempt. Perhaps the minalignslop calculation in >>> xfs_bmap_btalloc() is incorrect... >> Okay I'll look into that. >> >> There's something else that looks suspicious to me - this code in >> xfs_bmap_btalloc() is setting minleft to 0. Doesn't this go against >> what you were saying about setting minleft to be the space we might >> need for the btree operations? >> >> if (args.fsbno == NULLFSBLOCK && nullfb) { >> args.fsbno = 0; >> args.type = XFS_ALLOCTYPE_FIRST_AG; >> args.total = ap->minlen; >> args.minleft = 0; >> if ((error = xfs_alloc_vextent(&args))) >> return error; >> ap->low = 1; >> } > > Hmmm - that looks suspicious. In xfs_bmapi(), when we are doing a > write and *firstblock == NULLFSBLOCK (which leads to nullfb being > set in the above code), we do: > > if (wr && *firstblock == NULLFSBLOCK) { > if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) > minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; > else > minleft = 1; > } else > minleft = 0; > > If we are in btree format we set the minleft to the number of blocks needed > for a split. If we are in extent or local format, change to extent of btree > format requires one extra block. > > The above code you point out definitely breaks this - we haven't done a > previous allocation so we can start from the first AG, but we sure as > hell still need minleft set to the number of blocks needed for a > format change or btree split. > >> I see it sets a lowspace indicator which filters back up and into >> some btree operations. It appears the purpose of this feature is to >> allow allocations to search for space in other AGs as in this example >> from xfs_bmap_extents_to_btree(): >> >> if (*firstblock == NULLFSBLOCK) { >> args.type = XFS_ALLOCTYPE_START_BNO; >> args.fsbno = XFS_INO_TO_FSB(mp, ip->i_ino); >> } else if (flist->xbf_low) { >> args.type = XFS_ALLOCTYPE_START_BNO; >> args.fsbno = *firstblock; >> } else { >> args.type = XFS_ALLOCTYPE_NEAR_BNO; >> args.fsbno = *firstblock; >> } > > Hmmm - the only place xbf_low is used in the extent-to-btree conversion. I > don't have access to the revision history anymore, so i can't find out what > bug the xbf_low condition was added for. It certainly looks like it is > allowing the btree block to be allocated in a different AG to data block. The lowspace algorithm was added way back in the early '90s and has been 'tweaked' many times since. > >> This is sort of what I was trying to do with my patch but without the >> special lowspace condition. This lowspace feature is probably broken >> because there was a similar special case in xfs_bmbt_split() that got >> removed with the changes that fixed the AG out-of-order locking problem. >> >> @@ -1569,12 +1569,11 @@ >> lbno = XFS_DADDR_TO_FSB(args.mp, XFS_BUF_ADDR(lbp)); >> left = XFS_BUF_TO_BMBT_BLOCK(lbp); >> args.fsbno = cur->bc_private.b.firstblock; >> + args.firstblock = args.fsbno; >> if (args.fsbno == NULLFSBLOCK) { >> args.fsbno = lbno; >> args.type = XFS_ALLOCTYPE_START_BNO; >> - } else if (cur->bc_private.b.flist->xbf_low) >> - args.type = XFS_ALLOCTYPE_FIRST_AG; >> - else >> + } else >> args.type = XFS_ALLOCTYPE_NEAR_BNO; >> args.mod = args.minleft = args.alignment = args.total = args.isfl = >> args.userdata = args.minalignslop = 0; >> >> This could be why we have allocations failing now. > > Hmmm - yes, could be. Well found, Lachlan. Was there an equivalent change > to the allocation of a new root block? Yeah but it got dropped 14 years ago in a code cleanup change! Looks like it was by mistake too. There used to be another special case for converting delayed allocations that had the same semantics as this low space trick - it used XFS_ALLOCTYPE_FIRST_AG instead - maybe to try a little harder to find space for cases where it is too late to return an error to the user. > >> Maybe it should >> have been left in and XFS_ALLOCTYPE_FIRST_AG changed to >> XFS_ALLOCTYPE_START_BNO. But even then it could still fail because the >> AG deadlock avoidance code may prevent us from searching the AG that has >> the space we need. > > Right. But it would definitely be more likely to find space than the current > code without re-introducing the deadlock. > >> Should we ditch this lowspace special condition (and the code in >> xfs_bmap_btalloc()) and insist that all the space we need (using minleft) >> should come from one AG? > > Well, we could, but I suspect that one condition that it is used it > is safe to do so. That is, the logic goes like this: > > - allocate the last extent in an AG. By definition, that has not > caused a AGF btree split as the trees are now empty. > - because we haven't split any AGF btrees, we still have an unused > transaction reservation for full AGF btree splits. > - seeing as we have a full reservation, we can safely allocate in a > different AG without overrunning a transaction reservation. > > However, we still need to obey the AGF locking order. > > Hmmmm - perhaps before allocating with minleft = 0 we need to > check if we can allocate the rest of the blocks from another AG and > lock both AGs in the correct order first, recheck we can allocate > from both of them after they are locked but before modifying anything > and only then proceed. If we can't find two AGs to allocate from then > we can safely ENOSPC without any problems. In this special case we'd then > be able to search the entire FS for space and hence only get an ENOSPC > if we are really at ENOSPC. Can you pick holes in this? Sounds like it should work. We may need to lock more than two AGs at once to find all the space we need. Since we can't lock AGs out of order then if we get to the last AG and we still don't have enough space then we will need to try again but start at an earlier AG (say AG 0 which should work). So the code in xfs_alloc_vextent() that uses XFS_ALLOCTYPE_FIRST_AG and sets minleft to 0 should work. If we start at AG 0 and we've done the proper reservations then we should eventually find all the space we need - as long as everything that needs to allocate space obeys the lowspace algorithm and we always kick off each search for space from the AG we last allocated from. > >>>>>> I'm worried with this approach that we could have delayed allocations and >>>>>> unwritten extents that need to be converted but we can't do it because we >>>>>> don't have the space we might need (but probably don't). >>>>> Delayed allocation is the issue - unwritten extent conversion failure will >>>>> simply return an error and leave the extent unwritten. >>>> That's still a problem though - if we can't convert unwritten extents then >>>> we can't clean dirty pages and we wont be able to unmount the filesystem. >>> There will be errors logged and the extents will remain unwritten. >>> The filesystem should still be able to be unmounted. >> So returning an error from unwritten extent conversion will not re-dirty the >> pages? So we effectively throw the user's data away? > > Yes, I think that can happen async writes. For anything that is sync the > error will be propagated back to application. Often there is nothing to > report errors back to on async writes - I'm not sure if the errors get > logged in that case, though... > > I suspect that this is a holdover from before we had ENOSPC checking on > mmap writes - that could result in mmap oversubscribing space and the > data could not ever be written. In low memory conditions this could > deadlock the machine if we did not throw the pages away. We probably > need to reevisit this now that ->page_mkwrite() prevents > oversubscription from occurring.... > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Sun Jun 22 22:52:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 22:52:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45 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 m5N5qcV5029101 for ; Sun, 22 Jun 2008 22:52:39 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA11277; Mon, 23 Jun 2008 15:53:33 +1000 Message-ID: <485F3B42.9050300@sgi.com> Date: Mon, 23 Jun 2008 15:57:22 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> <485A0AB2.4060009@sgi.com> <20080620052120.GA3700@disturbed> <20080623052025.GF29319@disturbed> In-Reply-To: <20080623052025.GF29319@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16471 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Fri, Jun 20, 2008 at 03:21:20PM +1000, Dave Chinner wrote: >> On Thu, Jun 19, 2008 at 05:28:50PM +1000, Lachlan McIlroy wrote: >>> Dave Chinner wrote: >>>> On Tue, Jun 17, 2008 at 11:58:47AM +1000, Lachlan McIlroy wrote: >>>>> Dave Chinner wrote: >>>>>> On Sunday 15 June 2008 11:11 pm, Lachlan McIlroy wrote: >>>>>>> I'm well aware of that particular deadlock involving the freelist - I >>>>>>> hit it while testing. If you look closely at the code that deadlock >>>>>>> can occur with or without the AG locking avoidance logic. This is >>>>>>> because the rest of the transaction is unaware that an AG has been >>>>>>> locked due to a freelist operation. >>>>>> Yes, which is why you need to prevent freelist modifications occurring >>>>>> when you can't allocate anything out of the AG. >>>>> That sounds reasonable but it isn't consistent with the deadlock I saw. >>>>> One of the threads that was deadlocked had tried to allocate a data extent >>>>> in AG3 but didn't find the space. It had modified, and hence locked, AG3 >>>>> due to modifying the freelist but since it didn't get the space it needed >>>>> it had to go on to another AG. >>>> That sounds like an exact allocation failure - there is enough >>>> space, a large enough extent but no free space at the exact block >>>> required. This is exactly the case that occurred with the inode >>>> allocation - and then allocation in the same AG failed because of >>>> alignment that wasn't taken into account by the first exact >>>> allocation attempt. Perhaps the minalignslop calculation in >>>> xfs_bmap_btalloc() is incorrect... >>> Okay I'll look into that. >>> >>> There's something else that looks suspicious to me - this code in >>> xfs_bmap_btalloc() is setting minleft to 0. Doesn't this go against >>> what you were saying about setting minleft to be the space we might >>> need for the btree operations? >>> >>> if (args.fsbno == NULLFSBLOCK && nullfb) { >>> args.fsbno = 0; >>> args.type = XFS_ALLOCTYPE_FIRST_AG; >>> args.total = ap->minlen; >>> args.minleft = 0; >>> if ((error = xfs_alloc_vextent(&args))) >>> return error; >>> ap->low = 1; >>> } >> Hmmm - that looks suspicious. In xfs_bmapi(), when we are doing a >> write and *firstblock == NULLFSBLOCK (which leads to nullfb being >> set in the above code), we do: >> >> if (wr && *firstblock == NULLFSBLOCK) { >> if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) >> minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; >> else >> minleft = 1; >> } else >> minleft = 0; >> >> If we are in btree format we set the minleft to the number of blocks needed >> for a split. If we are in extent or local format, change to extent of btree >> format requires one extra block. >> >> The above code you point out definitely breaks this - we haven't done a >> previous allocation so we can start from the first AG, but we sure as >> hell still need minleft set to the number of blocks needed for a >> format change or btree split. > > Just to point out yet another problem in this code (one that's just > been tripped over @ agami) is unwritten extent conversion. > > Basically, we don't do an allocation here, so when we end up in > xfs_bmap_add_extent_unwritten_real() with a null firstblock. Hence > the cases where conversion can cause a split - case > MASK(LEFT_FILLING), MASK(RIGHT_FILLING) and 0 (convert the middle of > an extent) - we can select an AG that doesn't have enough space for > the entire split as we've ignored the number of blocks we might > need to allocate in the split (the minleft parameter) entirely. > > I suspect that xfs_bmbt_split() needs to handle the null first block > case slightly differently - the minleft parameter passed to the > allocation should not be zero - it should be the number of levels > above the current level left in the tree. i.e: > > minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; > > If we've already got a firstblock set, then this should have already > been taken into account (i.e. we still need to fix the low space > case where it got ignored as we were discussing). > Funny. I tested the exact same change last week to try to fix the same problem. Seemed to work okay. In the case where we convert the middle of an existing unwritten extent we need to insert two new extents. I might be paranoid here but I'll assume the worst case scenario and that we'll need space for two complete tree splits. The first allocation for the first insert will set minleft correctly but what about the allocations for splits during the second insert? We could run out of space in the chosen AG because minleft wasn't enough. From owner-xfs@oss.sgi.com Sun Jun 22 23:13:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 23:13:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,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 m5N6DQ3m031957 for ; Sun, 22 Jun 2008 23:13:26 -0700 X-ASG-Debug-ID: 1214201664-34e400650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0DD6B180AEEF for ; Sun, 22 Jun 2008 23:14:25 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id N9wuRbF5Cxs473PX for ; Sun, 22 Jun 2008 23:14:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI/bXkh5LG+u/2dsb2JhbACucw X-IronPort-AV: E=Sophos;i="4.27,688,1204464600"; d="scan'208";a="132869158" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 23 Jun 2008 15:44:23 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KAfJl-0004Lb-VJ; Mon, 23 Jun 2008 16:14:21 +1000 Date: Mon, 23 Jun 2008 16:14:21 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080623061421.GG29319@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> <485A0AB2.4060009@sgi.com> <20080620052120.GA3700@disturbed> <20080623052025.GF29319@disturbed> <485F3B42.9050300@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485F3B42.9050300@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214201666 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.54090 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: 16472 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 23, 2008 at 03:57:22PM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: >> On Fri, Jun 20, 2008 at 03:21:20PM +1000, Dave Chinner wrote: >>> On Thu, Jun 19, 2008 at 05:28:50PM +1000, Lachlan McIlroy wrote: >>>> There's something else that looks suspicious to me - this code in >>>> xfs_bmap_btalloc() is setting minleft to 0. Doesn't this go against >>>> what you were saying about setting minleft to be the space we might >>>> need for the btree operations? >>>> >>>> if (args.fsbno == NULLFSBLOCK && nullfb) { >>>> args.fsbno = 0; >>>> args.type = XFS_ALLOCTYPE_FIRST_AG; >>>> args.total = ap->minlen; >>>> args.minleft = 0; >>>> if ((error = xfs_alloc_vextent(&args))) >>>> return error; >>>> ap->low = 1; >>>> } >>> Hmmm - that looks suspicious. In xfs_bmapi(), when we are doing a >>> write and *firstblock == NULLFSBLOCK (which leads to nullfb being >>> set in the above code), we do: >>> >>> if (wr && *firstblock == NULLFSBLOCK) { >>> if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) >>> minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; >>> else >>> minleft = 1; >>> } else >>> minleft = 0; >>> >>> If we are in btree format we set the minleft to the number of blocks needed >>> for a split. If we are in extent or local format, change to extent of btree >>> format requires one extra block. >>> >>> The above code you point out definitely breaks this - we haven't done a >>> previous allocation so we can start from the first AG, but we sure as >>> hell still need minleft set to the number of blocks needed for a >>> format change or btree split. >> >> Just to point out yet another problem in this code (one that's just >> been tripped over @ agami) is unwritten extent conversion. >> >> Basically, we don't do an allocation here, so when we end up in >> xfs_bmap_add_extent_unwritten_real() with a null firstblock. Hence >> the cases where conversion can cause a split - case >> MASK(LEFT_FILLING), MASK(RIGHT_FILLING) and 0 (convert the middle of >> an extent) - we can select an AG that doesn't have enough space for >> the entire split as we've ignored the number of blocks we might >> need to allocate in the split (the minleft parameter) entirely. >> >> I suspect that xfs_bmbt_split() needs to handle the null first block >> case slightly differently - the minleft parameter passed to the >> allocation should not be zero - it should be the number of levels >> above the current level left in the tree. i.e: >> >> minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; >> >> If we've already got a firstblock set, then this should have already >> been taken into account (i.e. we still need to fix the low space >> case where it got ignored as we were discussing). > > Funny. I tested the exact same change last week to try to fix the same > problem. Seemed to work okay. Cool. Got a patch for review? > In the case where we convert the middle of an existing unwritten extent > we need to insert two new extents. I might be paranoid here but I'll > assume the worst case scenario and that we'll need space for two complete > tree splits. Yes, I think so. Certainly, if you look at the block reservation in xfs_iomap_write_unwritten(): 892 resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0) << 1; #define XFS_DIOSTRAT_SPACE_RES(mp, v) \ (XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK) + (v)) #define XFS_EXTENTADD_SPACE_RES(mp,w) (XFS_BM_MAXLEVELS(mp,w) - 1) It reserves enough blocks for 2 bmbt splits so I think this is definitely a possibility we need to handle. > The first allocation for the first insert will set minleft > correctly but what about the allocations for splits during the second > insert? We could run out of space in the chosen AG because minleft wasn't > enough. Yeah, so we probably need pass a flag in the cursor to indicate it's a double split case when doing the first allocation in xfs_bmbt_split.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 22 23:21:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 23:21: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.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_47,J_CHICKENPOX_48 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 m5N6L1kI001050 for ; Sun, 22 Jun 2008 23:21:01 -0700 X-ASG-Debug-ID: 1214202120-77fa02f70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 55EB3D1D9E6 for ; Sun, 22 Jun 2008 23:22:00 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id 26KpanblBhk7PhPt for ; Sun, 22 Jun 2008 23:22:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI/bXkh5LG+u/2dsb2JhbACucw X-IronPort-AV: E=Sophos;i="4.27,688,1204464600"; d="scan'208";a="132877247" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 23 Jun 2008 15:51:58 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KAfR8-0004VI-2p; Mon, 23 Jun 2008 16:21:58 +1000 Date: Mon, 23 Jun 2008 16:21:58 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080623062157.GH29319@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> <485A0AB2.4060009@sgi.com> <20080620052120.GA3700@disturbed> <485F339D.7090802@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485F339D.7090802@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214202121 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.54091 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: 16473 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 23, 2008 at 03:24:45PM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: >> On Thu, Jun 19, 2008 at 05:28:50PM +1000, Lachlan McIlroy wrote: >>> I see it sets a lowspace indicator which filters back up and into >>> some btree operations. It appears the purpose of this feature is to >>> allow allocations to search for space in other AGs as in this example >>> from xfs_bmap_extents_to_btree(): >>> >>> if (*firstblock == NULLFSBLOCK) { >>> args.type = XFS_ALLOCTYPE_START_BNO; >>> args.fsbno = XFS_INO_TO_FSB(mp, ip->i_ino); >>> } else if (flist->xbf_low) { >>> args.type = XFS_ALLOCTYPE_START_BNO; >>> args.fsbno = *firstblock; >>> } else { >>> args.type = XFS_ALLOCTYPE_NEAR_BNO; >>> args.fsbno = *firstblock; >>> } >> >> Hmmm - the only place xbf_low is used in the extent-to-btree conversion. I >> don't have access to the revision history anymore, so i can't find out what >> bug the xbf_low condition was added for. It certainly looks like it is >> allowing the btree block to be allocated in a different AG to data block. > > The lowspace algorithm was added way back in the early '90s and has been > 'tweaked' many times since. It's good to have a complete revision history around somewhere. ;) >>> This is sort of what I was trying to do with my patch but without the >>> special lowspace condition. This lowspace feature is probably broken >>> because there was a similar special case in xfs_bmbt_split() that got >>> removed with the changes that fixed the AG out-of-order locking problem. >>> >>> @@ -1569,12 +1569,11 @@ >>> lbno = XFS_DADDR_TO_FSB(args.mp, XFS_BUF_ADDR(lbp)); >>> left = XFS_BUF_TO_BMBT_BLOCK(lbp); >>> args.fsbno = cur->bc_private.b.firstblock; >>> + args.firstblock = args.fsbno; >>> if (args.fsbno == NULLFSBLOCK) { >>> args.fsbno = lbno; >>> args.type = XFS_ALLOCTYPE_START_BNO; >>> - } else if (cur->bc_private.b.flist->xbf_low) >>> - args.type = XFS_ALLOCTYPE_FIRST_AG; >>> - else >>> + } else >>> args.type = XFS_ALLOCTYPE_NEAR_BNO; >>> args.mod = args.minleft = args.alignment = args.total = args.isfl = >>> args.userdata = args.minalignslop = 0; >>> >>> This could be why we have allocations failing now. >> >> Hmmm - yes, could be. Well found, Lachlan. Was there an equivalent change >> to the allocation of a new root block? > > Yeah but it got dropped 14 years ago in a code cleanup change! Looks like > it was by mistake too. Ouch. > There used to be another special case for converting > delayed allocations that had the same semantics as this low space trick - it > used XFS_ALLOCTYPE_FIRST_AG instead - maybe to try a little harder to find > space for cases where it is too late to return an error to the user. Interesting. Any idea why that was removed? Or another accident? [....] >> Hmmmm - perhaps before allocating with minleft = 0 we need to >> check if we can allocate the rest of the blocks from another AG and >> lock both AGs in the correct order first, recheck we can allocate >> from both of them after they are locked but before modifying anything >> and only then proceed. If we can't find two AGs to allocate from then >> we can safely ENOSPC without any problems. In this special case we'd then >> be able to search the entire FS for space and hence only get an ENOSPC >> if we are really at ENOSPC. Can you pick holes in this? > > Sounds like it should work. We may need to lock more than two AGs at once to > find all the space we need. Since we can't lock AGs out of order then if we get > to the last AG and we still don't have enough space then we will need to try > again but start at an earlier AG (say AG 0 which should work). In this case, I'd just start from XFS_ALLOCTYPE_FIRST_AG rather than doing multiple passes and having to undo between them.... > So the code in xfs_alloc_vextent() that uses XFS_ALLOCTYPE_FIRST_AG and sets > minleft to 0 should work. Yes, as long as the next selected AG has the original minleft blocks available in it. > If we start at AG 0 and we've done the proper reservations > then we should eventually find all the space we need - as long as everything that > needs to allocate space obeys the lowspace algorithm and we always kick off each > search for space from the AG we last allocated from. Yup. Seems sane to me. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 22 23:35:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 22 Jun 2008 23:35:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47, J_CHICKENPOX_48 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5N6Zgwt003102 for ; Sun, 22 Jun 2008 23:35:43 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA12129; Mon, 23 Jun 2008 16:36:37 +1000 Message-ID: <485F455A.9060701@sgi.com> Date: Mon, 23 Jun 2008 16:40:26 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] Prevent extent btree block allocation failures References: <485223E4.6030404@sgi.com> <20080613155708.GG3700@disturbed> <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> <485A0AB2.4060009@sgi.com> <20080620052120.GA3700@disturbed> <20080623052025.GF29319@disturbed> <485F3B42.9050300@sgi.com> <20080623061421.GG29319@disturbed> In-Reply-To: <20080623061421.GG29319@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16474 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Mon, Jun 23, 2008 at 03:57:22PM +1000, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Fri, Jun 20, 2008 at 03:21:20PM +1000, Dave Chinner wrote: >>>> On Thu, Jun 19, 2008 at 05:28:50PM +1000, Lachlan McIlroy wrote: >>>>> There's something else that looks suspicious to me - this code in >>>>> xfs_bmap_btalloc() is setting minleft to 0. Doesn't this go against >>>>> what you were saying about setting minleft to be the space we might >>>>> need for the btree operations? >>>>> >>>>> if (args.fsbno == NULLFSBLOCK && nullfb) { >>>>> args.fsbno = 0; >>>>> args.type = XFS_ALLOCTYPE_FIRST_AG; >>>>> args.total = ap->minlen; >>>>> args.minleft = 0; >>>>> if ((error = xfs_alloc_vextent(&args))) >>>>> return error; >>>>> ap->low = 1; >>>>> } >>>> Hmmm - that looks suspicious. In xfs_bmapi(), when we are doing a >>>> write and *firstblock == NULLFSBLOCK (which leads to nullfb being >>>> set in the above code), we do: >>>> >>>> if (wr && *firstblock == NULLFSBLOCK) { >>>> if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) >>>> minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; >>>> else >>>> minleft = 1; >>>> } else >>>> minleft = 0; >>>> >>>> If we are in btree format we set the minleft to the number of blocks needed >>>> for a split. If we are in extent or local format, change to extent of btree >>>> format requires one extra block. >>>> >>>> The above code you point out definitely breaks this - we haven't done a >>>> previous allocation so we can start from the first AG, but we sure as >>>> hell still need minleft set to the number of blocks needed for a >>>> format change or btree split. >>> Just to point out yet another problem in this code (one that's just >>> been tripped over @ agami) is unwritten extent conversion. >>> >>> Basically, we don't do an allocation here, so when we end up in >>> xfs_bmap_add_extent_unwritten_real() with a null firstblock. Hence >>> the cases where conversion can cause a split - case >>> MASK(LEFT_FILLING), MASK(RIGHT_FILLING) and 0 (convert the middle of >>> an extent) - we can select an AG that doesn't have enough space for >>> the entire split as we've ignored the number of blocks we might >>> need to allocate in the split (the minleft parameter) entirely. >>> >>> I suspect that xfs_bmbt_split() needs to handle the null first block >>> case slightly differently - the minleft parameter passed to the >>> allocation should not be zero - it should be the number of levels >>> above the current level left in the tree. i.e: >>> >>> minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; >>> >>> If we've already got a firstblock set, then this should have already >>> been taken into account (i.e. we still need to fix the low space >>> case where it got ignored as we were discussing). >> Funny. I tested the exact same change last week to try to fix the same >> problem. Seemed to work okay. > > Cool. Got a patch for review? I couldn't find the original patch that calculated minleft as above - instead here's a variant that addresses the double insert problem by retrieving the reservation amount from the transaction. It could very well be overkill though. --- fs/xfs/xfs_bmap_btree.c_1.169 2008-06-16 17:25:10.000000000 +1000 +++ fs/xfs/xfs_bmap_btree.c 2008-06-16 18:32:45.000000000 +1000 @@ -1496,9 +1496,12 @@ xfs_bmbt_split( if (args.fsbno == NULLFSBLOCK) { args.fsbno = lbno; args.type = XFS_ALLOCTYPE_START_BNO; - } else + args.minleft = xfs_trans_get_block_res(args.tp); + } else { args.type = XFS_ALLOCTYPE_NEAR_BNO; - args.mod = args.minleft = args.alignment = args.total = args.isfl = + args.minleft = 0; + } + args.mod = args.alignment = args.total = args.isfl = args.userdata = args.minalignslop = 0; args.minlen = args.maxlen = args.prod = 1; args.wasdel = cur->bc_private.b.flags & XFS_BTCUR_BPRV_WASDEL; > >> In the case where we convert the middle of an existing unwritten extent >> we need to insert two new extents. I might be paranoid here but I'll >> assume the worst case scenario and that we'll need space for two complete >> tree splits. > > Yes, I think so. Certainly, if you look at the block reservation in > xfs_iomap_write_unwritten(): > > 892 resblks = XFS_DIOSTRAT_SPACE_RES(mp, 0) << 1; > > #define XFS_DIOSTRAT_SPACE_RES(mp, v) \ > (XFS_EXTENTADD_SPACE_RES(mp, XFS_DATA_FORK) + (v)) > > #define XFS_EXTENTADD_SPACE_RES(mp,w) (XFS_BM_MAXLEVELS(mp,w) - 1) > > It reserves enough blocks for 2 bmbt splits so I think this is > definitely a possibility we need to handle. > >> The first allocation for the first insert will set minleft >> correctly but what about the allocations for splits during the second >> insert? We could run out of space in the chosen AG because minleft wasn't >> enough. > > Yeah, so we probably need pass a flag in the cursor to indicate > it's a double split case when doing the first allocation in > xfs_bmbt_split.... > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Mon Jun 23 00:21:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 00:21:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N7LWtG016054 for ; Mon, 23 Jun 2008 00:21:34 -0700 X-ASG-Debug-ID: 1214205751-55aa01ed0000-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 A360B180AD51; Mon, 23 Jun 2008 00:22:31 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id FUyxd3ut21WR36tl; Mon, 23 Jun 2008 00:22:31 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KAgNf-0003Sn-Ck; Mon, 23 Jun 2008 07:22:27 +0000 Date: Mon, 23 Jun 2008 03:22:27 -0400 From: Christoph Hellwig To: Mel Gorman Cc: Daniel J Blueman , Christoph Lameter , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Subject: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Message-ID: <20080623072227.GB11986@infradead.org> References: <6278d2220806220256g674304ectb945c14e7e09fede@mail.gmail.com> <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> <20080622221930.GA11558@disturbed> <20080623002415.GB21597@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080623002415.GB21597@csn.ul.ie> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214205751 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.54096 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: 16475 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 23, 2008 at 01:24:15AM +0100, Mel Gorman wrote: > In that case, have you any theory as to why this circular dependency is > being reported now but wasn't before 2.6.26-rc1? I'm beginning to wonder > if the bisecting fingering the zonelist modifiation is just a > co-incidence. I've seen this traces since lockdep was added when running xfsqa. From owner-xfs@oss.sgi.com Mon Jun 23 01:04:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 01:04:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_47 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 m5N84gKl021913 for ; Mon, 23 Jun 2008 01:04:42 -0700 X-ASG-Debug-ID: 1214208340-061e011f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 22110D1DC92 for ; Mon, 23 Jun 2008 01:05:41 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id ilg0Xdirki3L8qVT for ; Mon, 23 Jun 2008 01:05:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACr0Xkh5LG+u/2dsb2JhbACveg X-IronPort-AV: E=Sophos;i="4.27,688,1204464600"; d="scan'208";a="132963896" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 23 Jun 2008 17:35:36 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KAh3K-0006qy-Mp; Mon, 23 Jun 2008 18:05:30 +1000 Date: Mon, 23 Jun 2008 18:05:30 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Prevent extent btree block allocation failures Subject: Re: [PATCH] Prevent extent btree block allocation failures Message-ID: <20080623080530.GI29319@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <485603FD.2080204@sgi.com> <200806161010.22476.dchinner@agami.com> <48571A57.5090901@sgi.com> <20080617073949.GP3700@disturbed> <485A0AB2.4060009@sgi.com> <20080620052120.GA3700@disturbed> <20080623052025.GF29319@disturbed> <485F3B42.9050300@sgi.com> <20080623061421.GG29319@disturbed> <485F455A.9060701@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485F455A.9060701@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214208342 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.54099 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: 16476 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 23, 2008 at 04:40:26PM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: >> On Mon, Jun 23, 2008 at 03:57:22PM +1000, Lachlan McIlroy wrote: >>> Dave Chinner wrote: >>>> On Fri, Jun 20, 2008 at 03:21:20PM +1000, Dave Chinner wrote: >>>>> On Thu, Jun 19, 2008 at 05:28:50PM +1000, Lachlan McIlroy wrote: >>>>>> There's something else that looks suspicious to me - this code in >>>>>> xfs_bmap_btalloc() is setting minleft to 0. Doesn't this go against >>>>>> what you were saying about setting minleft to be the space we might >>>>>> need for the btree operations? >>>>>> >>>>>> if (args.fsbno == NULLFSBLOCK && nullfb) { >>>>>> args.fsbno = 0; >>>>>> args.type = XFS_ALLOCTYPE_FIRST_AG; >>>>>> args.total = ap->minlen; >>>>>> args.minleft = 0; >>>>>> if ((error = xfs_alloc_vextent(&args))) >>>>>> return error; >>>>>> ap->low = 1; >>>>>> } >>>>> Hmmm - that looks suspicious. In xfs_bmapi(), when we are doing a >>>>> write and *firstblock == NULLFSBLOCK (which leads to nullfb being >>>>> set in the above code), we do: >>>>> >>>>> if (wr && *firstblock == NULLFSBLOCK) { >>>>> if (XFS_IFORK_FORMAT(ip, whichfork) == XFS_DINODE_FMT_BTREE) >>>>> minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; >>>>> else >>>>> minleft = 1; >>>>> } else >>>>> minleft = 0; >>>>> >>>>> If we are in btree format we set the minleft to the number of blocks needed >>>>> for a split. If we are in extent or local format, change to extent of btree >>>>> format requires one extra block. >>>>> >>>>> The above code you point out definitely breaks this - we haven't done a >>>>> previous allocation so we can start from the first AG, but we sure as >>>>> hell still need minleft set to the number of blocks needed for a >>>>> format change or btree split. >>>> Just to point out yet another problem in this code (one that's just >>>> been tripped over @ agami) is unwritten extent conversion. >>>> >>>> Basically, we don't do an allocation here, so when we end up in >>>> xfs_bmap_add_extent_unwritten_real() with a null firstblock. Hence >>>> the cases where conversion can cause a split - case >>>> MASK(LEFT_FILLING), MASK(RIGHT_FILLING) and 0 (convert the middle of >>>> an extent) - we can select an AG that doesn't have enough space for >>>> the entire split as we've ignored the number of blocks we might >>>> need to allocate in the split (the minleft parameter) entirely. >>>> >>>> I suspect that xfs_bmbt_split() needs to handle the null first block >>>> case slightly differently - the minleft parameter passed to the >>>> allocation should not be zero - it should be the number of levels >>>> above the current level left in the tree. i.e: >>>> >>>> minleft = be16_to_cpu(ifp->if_broot->bb_level) + 1; >>>> >>>> If we've already got a firstblock set, then this should have already >>>> been taken into account (i.e. we still need to fix the low space >>>> case where it got ignored as we were discussing). >>> Funny. I tested the exact same change last week to try to fix the same >>> problem. Seemed to work okay. >> >> Cool. Got a patch for review? > > I couldn't find the original patch that calculated minleft as above - instead > here's a variant that addresses the double insert problem by retrieving the > reservation amount from the transaction. It could very well be overkill though. No, that seems valid; all allocations need to pass in a reservation for a number of blocks needed for the transaction to proceed. I did a quick check and everything appears to be reserving only what is necessary for a bmbt split (or two)... > --- fs/xfs/xfs_bmap_btree.c_1.169 2008-06-16 17:25:10.000000000 +1000 > +++ fs/xfs/xfs_bmap_btree.c 2008-06-16 18:32:45.000000000 +1000 > @@ -1496,9 +1496,12 @@ xfs_bmbt_split( > if (args.fsbno == NULLFSBLOCK) { > args.fsbno = lbno; > args.type = XFS_ALLOCTYPE_START_BNO; > - } else > + args.minleft = xfs_trans_get_block_res(args.tp); > + } else { Might be worth a comment ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Mon Jun 23 01:25:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 01:26: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=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 m5N8PuL9024770 for ; Mon, 23 Jun 2008 01:25:56 -0700 X-ASG-Debug-ID: 1214209614-286700cd0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pp1.tm.net.my (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3E8CDD1E2ED for ; Mon, 23 Jun 2008 01:26:54 -0700 (PDT) Received: from pp1.tm.net.my (pp-smtp.tm.net.my [202.188.0.210]) by cuda.sgi.com with ESMTP id skF6A9b6SU7CMpqW for ; Mon, 23 Jun 2008 01:26:54 -0700 (PDT) Received: from smtp-proxy.tm.net.my (smtp-proxy.tm.net.my [202.188.0.174]) by pp1.tm.net.my (8.14.1/8.14.1) with ESMTP id m5N89hdB021466 for ; Mon, 23 Jun 2008 16:09:43 +0800 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from SALES ([124.82.113.225]) by smtp-proxy3.tm.net.my (Sun Java(tm) System Messaging Server 6.3-0.15 (built Feb 9 2007)) with SMTP id <0K2W00KTLQ1I9AB0@smtp-proxy3.tm.net.my> for linux-xfs@oss.sgi.com; Mon, 23 Jun 2008 16:26:53 +0800 (MYT) X-Brightmail-Tracker: : $M Date: Mon, 23 Jun 2008 16:19:55 +0800 X-ASG-Orig-Subj: [News] 23 June 2008 - Olympic torch in Beijing sex scandal Subject: [News] 23 June 2008 - Olympic torch in Beijing sex scandal From: Datefinder To: linux-xfs Message-id: <6231619.PVGIQRWN@live.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.7160:2.4.4,1.2.40,4.0.166 definitions=2008-06-23_02:2008-06-19,2008-06-23,2008-06-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=16 classifier=spam adjust=0 reason=mlx engine=5.0.0-0805090000 definitions=main-0806230000 X-Barracuda-Connect: pp-smtp.tm.net.my[202.188.0.210] X-Barracuda-Start-Time: 1214209616 X-Barracuda-Bayes: INNOCENT GLOBAL 0.7279 1.0000 1.5884 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.59 X-Barracuda-Spam-Status: No, SCORE=1.59 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.54099 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: 16477 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: datefinderxdated@live.com Precedence: bulk X-list: xfs In Beijing...Need a date tonight...then try something very different >>> www.victoria-cherry-vip-escort.com From owner-xfs@oss.sgi.com Mon Jun 23 01:41:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 01:41:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63, J_CHICKENPOX_64 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 m5N8f3bm027002 for ; Mon, 23 Jun 2008 01:41:05 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA14569 for ; Mon, 23 Jun 2008 18:42:03 +1000 Date: Mon, 23 Jun 2008 18:44:58 +1000 To: "xfs@oss.sgi.com" Subject: REVIEW: Fix CI lookup in leaf-form directories 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 m5N8f6bm027007 X-archive-position: 16478 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 Along the same lines as the node-form directory patch last week, the leaf-form is not handling directory buffers properly and locks up. Instead of comparing buffer pointers, compare buffer block numbers and don't keep buffers hanging around. --- a/fs/xfs/xfs_dir2_leaf.c 2008-06-23 18:35:54.000000000 +1000 +++ b/fs/xfs/xfs_dir2_leaf.c 2008-06-23 18:27:38.214277630 +1000 @@ -1333,7 +1333,7 @@ xfs_dir2_leaf_lookup_int( xfs_mount_t *mp; /* filesystem mount point */ xfs_dir2_db_t newdb; /* new data block number */ xfs_trans_t *tp; /* transaction pointer */ - xfs_dabuf_t *cbp; /* case match data buffer */ + xfs_dir2_db_t cidb; /* case match data block no. */ enum xfs_dacmp cmp; /* name compare result */ dp = args->dp; @@ -1358,8 +1358,7 @@ xfs_dir2_leaf_lookup_int( * Loop over all the entries with the right hash value * looking to match the name. */ - cbp = NULL; - for (lep = &leaf->ents[index], dbp = NULL, curdb = -1; + for (lep = &leaf->ents[index], dbp = NULL, curdb = -1, cidb = -1; index < be16_to_cpu(leaf->hdr.count) && be32_to_cpu(lep->hashval) == args->hashval; lep++, index++) { @@ -1377,7 +1376,7 @@ xfs_dir2_leaf_lookup_int( * need to pitch the old one and read the new one. */ if (newdb != curdb) { - if (dbp != cbp) + if (dbp) xfs_da_brelse(tp, dbp); error = xfs_da_read_buf(tp, dp, xfs_dir2_db_to_da(mp, newdb), @@ -1403,35 +1402,39 @@ xfs_dir2_leaf_lookup_int( if (cmp != XFS_CMP_DIFFERENT && cmp != args->cmpresult) { args->cmpresult = cmp; *indexp = index; - /* - * case exact match: release the stored CI buffer if it - * exists and return the current buffer. - */ + /* case exact match: return the current buffer. */ if (cmp == XFS_CMP_EXACT) { - if (cbp && cbp != dbp) - xfs_da_brelse(tp, cbp); *dbpp = dbp; return 0; } - cbp = dbp; + cidb = curdb; } } ASSERT(args->op_flags & XFS_DA_OP_OKNOENT); /* - * Here, we can only be doing a lookup (not a rename or replace). - * If a case-insensitive match was found earlier, release the current - * buffer and return the stored CI matching buffer. + * Here, we can only be doing a lookup (not a rename or remove). + * If a case-insensitive match was found earlier, re-read the + * appropriate data block if required and return it. */ if (args->cmpresult == XFS_CMP_CASE) { - if (cbp != dbp) + ASSERT(cidb != -1); + if (cidb != curdb) { xfs_da_brelse(tp, dbp); - *dbpp = cbp; + error = xfs_da_read_buf(tp, dp, + xfs_dir2_db_to_da(mp, cidb), + -1, &dbp, XFS_DATA_FORK); + if (error) { + xfs_da_brelse(tp, lbp); + return error; + } + } + *dbpp = dbp; return 0; } /* * No match found, return ENOENT. */ - ASSERT(cbp == NULL); + ASSERT(cidb == -1); if (dbp) xfs_da_brelse(tp, dbp); xfs_da_brelse(tp, lbp); From owner-xfs@oss.sgi.com Mon Jun 23 02:04:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 02:04:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_64,J_CHICKENPOX_66,J_CHICKENPOX_72,J_CHICKENPOX_74, J_CHICKENPOX_81 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 m5N94JU2029953 for ; Mon, 23 Jun 2008 02:04: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 TAA14990 for ; Mon, 23 Jun 2008 19:05:18 +1000 Date: Mon, 23 Jun 2008 19:08:20 +1000 To: "xfs@oss.sgi.com" Subject: REVIEW: XFSQA test for CI testing 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 m5N94QU2029971 X-archive-position: 16479 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 Stresses create/unlink in multiple directory forms, including leaf-traversal testing by making sure all filenames have the same on-disk hash value. I added a CI function to nametest.c which randomly changes the case of a letter in the filename. genhashname.c generates the number of specified filenames of the optionally specified hashvalue (or a random one is chosen). =========================================================================== xfstests/188 =========================================================================== --- a/xfstests/188 2006-06-17 00:58:24.000000000 +1000 +++ b/xfstests/188 2008-06-23 18:53:52.603966583 +1000 @@ -0,0 +1,75 @@ +#! /bin/sh +# FS QA Test No. 188 +# +# drive the src/nametest program for CI mode +# which does a heap of open(create)/unlink/stat +# and checks that error codes make sense with its +# memory of the files created. +# +# All filenames generated map to the same hash +# value in XFS stressing leaf block traversal in +# node form directories as well. +# +#----------------------------------------------------------------------- +# Copyright (c) 2008 Silicon Graphics, Inc. All Rights Reserved. +#----------------------------------------------------------------------- +# +# creator +owner=bnaujok@sgi.com + +seq=`basename $0` +echo "QA output created by $seq" + +here=`pwd` +tmp=/tmp/$$ +status=0 # success is the default! +trap "_cleanup; exit \$status" 0 1 2 3 15 + +_cleanup() +{ + cd / + rm -f $tmp.* + rm -rf $SCRATCH_MNT/$seq +} + +# get standard environment, filters and checks +. ./common.rc +. ./common.filter + +# real QA test starts here +_supported_fs xfs +_supported_os Linux + +if [ $XFSPROGS_VERSION -lt 21000 ]; then + _notrun "this test required case-insensitive support" +fi + +_require_scratch +rm -f $seq.full + +_scratch_mkfs -n version=ci >/dev/null 2>&1 +_scratch_mount + +status=1 # default failure +sourcefile=$tmp.ci_nametest +seed=1 + +# need to create an input file with a list of filenames on each line +# do number of files for testing to try each directory format + +# start with small number of files and increase by 4x for each run +max_files=6144 +num_files=6 + +mkdir $SCRATCH_MNT/$seq +while [ $num_files -le $max_files ]; do + iterations=`expr $num_files \* 10` + $here/src/genhashnames $SCRATCH_MNT/$seq/$num_files $num_files $seed >>$sourcefile + mkdir $SCRATCH_MNT/$seq/$num_files + $here/src/nametest -l $sourcefile -s $seed -i $iterations -z -c + num_files=`expr $num_files \* 4` +done + +# success, all done +status=0 +exit =========================================================================== xfstests/188.out =========================================================================== --- a/xfstests/188.out 2006-06-17 00:58:24.000000000 +1000 +++ b/xfstests/188.out 2008-06-23 18:58:43.942490269 +1000 @@ -0,0 +1,65 @@ +QA output created by 188 +seed = 1, hash = 0x0aa84949 +.Seed = 1 (use "-s 1" to re-execute this test) + +creates: 15 OK, 5 EEXIST ( 20 total, 25% EEXIST) +removes: 13 OK, 17 ENOENT ( 30 total, 56% ENOENT) +lookups: 3 OK, 7 ENOENT ( 10 total, 70% ENOENT) +total : 31 OK, 29 w/error ( 60 total, 48% w/error) + +cleanup: 2 removes +seed = 1, hash = 0x0aa84949 +.Seed = 1 (use "-s 1" to re-execute this test) +.. +creates: 58 OK, 50 EEXIST ( 108 total, 46% EEXIST) +removes: 40 OK, 48 ENOENT ( 88 total, 54% ENOENT) +lookups: 20 OK, 24 ENOENT ( 44 total, 54% ENOENT) +total : 118 OK, 122 w/error ( 240 total, 50% w/error) + +cleanup: 18 removes +seed = 1, hash = 0x0aa84949 +.Seed = 1 (use "-s 1" to re-execute this test) +......... +creates: 216 OK, 185 EEXIST ( 401 total, 46% EEXIST) +removes: 152 OK, 179 ENOENT ( 331 total, 54% ENOENT) +lookups: 113 OK, 115 ENOENT ( 228 total, 50% ENOENT) +total : 481 OK, 479 w/error ( 960 total, 49% w/error) + +cleanup: 64 removes +seed = 1, hash = 0x0aa84949 +.Seed = 1 (use "-s 1" to re-execute this test) +....................................... +creates: 858 OK, 638 EEXIST ( 1496 total, 42% EEXIST) +removes: 595 OK, 830 ENOENT ( 1425 total, 58% ENOENT) +lookups: 414 OK, 505 ENOENT ( 919 total, 54% ENOENT) +total : 1867 OK, 1973 w/error ( 3840 total, 51% w/error) +. +cleanup: 263 removes +seed = 1, hash = 0x0aa84949 +.Seed = 1 (use "-s 1" to re-execute this test) +....................................................................... +......................................................................... +.......... +creates: 3511 OK, 2589 EEXIST ( 6100 total, 42% EEXIST) +removes: 2363 OK, 3132 ENOENT ( 5495 total, 56% ENOENT) +lookups: 1668 OK, 2097 ENOENT ( 3765 total, 55% ENOENT) +total : 7542 OK, 7818 w/error ( 15360 total, 50% w/error) +.......... +cleanup: 1148 removes +seed = 1, hash = 0x0aa84949 +.Seed = 1 (use "-s 1" to re-execute this test) +....................................................................... +......................................................................... +......................................................................... +......................................................................... +......................................................................... +......................................................................... +......................................................................... +......................................................................... +................................. +creates: 14155 OK, 10391 EEXIST ( 24546 total, 42% EEXIST) +removes: 9680 OK, 12484 ENOENT ( 22164 total, 56% ENOENT) +lookups: 6508 OK, 8222 ENOENT ( 14730 total, 55% ENOENT) +total : 30343 OK, 31097 w/error ( 61440 total, 50% w/error) +........................................... +cleanup: 4475 removes =========================================================================== xfstests/group =========================================================================== --- a/xfstests/group 2008-06-23 19:00:32.000000000 +1000 +++ b/xfstests/group 2008-06-23 17:31:24.239390417 +1000 @@ -86,6 +86,9 @@ dmapi # filestreams based tests filestreams dgc@sgi.com +# case-insensitive based tests +ci bnaujok@sgi.com + # test-group association ... one line per test # 001 rw dir udf auto @@ -275,3 +278,4 @@ filestreams dgc@sgi.com 185 dmapi auto 186 attr auto 187 attr auto +188 ci dir auto =========================================================================== xfstests/src/Makefile =========================================================================== --- a/xfstests/src/Makefile 2008-06-23 19:00:32.000000000 +1000 +++ b/xfstests/src/Makefile 2008-06-23 15:49:40.318538740 +1000 @@ -6,7 +6,7 @@ TOPDIR = .. include $(TOPDIR)/include/builddefs TARGETS = dirstress fill fill2 getpagesize holes lstat64 \ - nametest permname randholes runas truncfile usemem \ + genhashnames nametest permname randholes runas truncfile usemem \ mmapcat append_reader append_writer dirperf metaperf \ devzero feature alloc fault fstest t_access_root \ godown resvtest writemod makeextents itrash \ @@ -52,6 +52,9 @@ truncfile: truncfile.o $(LIBTEST) dbtest: dbtest.o $(LIBTEST) $(LINKTEST) $(LIBTEST) $(LIBGDBM) $(LDLIBS) +genhashnames: genhashnames.o + $(LINKTEST) + nametest: nametest.o $(LIBTEST) $(LINKTEST) $(LIBTEST) $(LDLIBS) =========================================================================== xfstests/src/genhashnames.c =========================================================================== --- a/xfstests/src/genhashnames.c 2006-06-17 00:58:24.000000000 +1000 +++ b/xfstests/src/genhashnames.c 2008-06-23 15:52:23.405528316 +1000 @@ -0,0 +1,178 @@ +/* + * Creates a bunch of files in the specified directory with the same + * hashvalue on-disk. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#define rol32(x,y) (((x) << (y)) | ((x) >> (32 - (y)))) + +/* + * Implement a simple hash on a character string. + * Rotate the hash value by 7 bits, then XOR each character in. + * This is implemented with some source-level loop unrolling. + */ +static uint32_t xfs_da_hashname(const char *name, int namelen) +{ + uint32_t hash; + + /* + * Do four characters at a time as long as we can. + */ + for (hash = 0; namelen >= 4; namelen -= 4, name += 4) + hash = (name[0] << 21) ^ (name[1] << 14) ^ (name[2] << 7) ^ + (name[3] << 0) ^ rol32(hash, 7 * 4); + + /* + * Now do the rest of the characters. + */ + switch (namelen) { + case 3: + return (name[0] << 14) ^ (name[1] << 7) ^ (name[2] << 0) ^ + rol32(hash, 7 * 3); + case 2: + return (name[0] << 7) ^ (name[1] << 0) ^ rol32(hash, 7 * 2); + case 1: + return (name[0] << 0) ^ rol32(hash, 7 * 1); + default: /* case 0: */ + return hash; + } +} + +static int is_invalid_char(char c) +{ + return (c <= ' ' || c > '~' || c == '/' || (c >= 'A' && c <= 'Z')); +} + +static char random_char(void) +{ + char c; + + /* get a character of "0"-"9" or "a"-"z" */ + + c = lrand48() % 36; + + return (c >= 10) ? c + 87 : c + 48; +} + +static int generate_names(const char *path, long amount, uint32_t desired_hash) +{ + char **names; + char fullpath[PATH_MAX]; + char *filename; + long count; + long i; + uint32_t base_hash; + uint32_t hash; + + names = malloc(amount * sizeof(char *)); + if (!names) { + fprintf(stderr, "genhashnames: malloc(%lu) failed!\n", + amount * sizeof(char *)); + return 1; + } + + strcpy(fullpath, path); + filename = fullpath + strlen(fullpath); + if (filename[-1] != '/') + *filename++ = '/'; + + for (count = 0; count < amount; count++) { + for (;;) { + base_hash = 0; + for (i = 0; i < 6; i++) { + filename[i] = random_char(); + base_hash = filename[i] ^ rol32(base_hash, 7); + } + while (i < 200) { + filename[i] = random_char(); + base_hash = filename[i] ^ rol32(base_hash, 7); + i++; + hash = rol32(base_hash, 3) ^ desired_hash; + + filename[i] = (hash >> 28) | + (random_char() & 0xf0); + if (is_invalid_char(filename[i])) + continue; + + filename[i + 1] = (hash >> 21) & 0x7f; + if (is_invalid_char(filename[i + 1])) + continue; + filename[i + 2] = (hash >> 14) & 0x7f; + if (is_invalid_char(filename[i + 2])) + continue; + filename[i + 3] = (hash >> 7) & 0x7f; + if (is_invalid_char(filename[i + 3])) + continue; + filename[i + 4] = (hash ^ (filename[i] >> 4)) + & 0x7f; + if (is_invalid_char(filename[i + 4])) + continue; + break; + } + if (i < NAME_MAX) + break; + } + filename[i + 5] = '\0'; + if (xfs_da_hashname(filename, i + 5) != desired_hash) { + fprintf(stderr, "genhashnames: Hash mismatch!\n"); + return 1; + } + + for (i = 0; i < count; i++) { + if (strcmp(fullpath, names[i]) == 0) + break; + } + if (i == count) { + names[count] = strdup(fullpath); + puts(fullpath); + } else + count--; + } + return 0; +} + +static void usage(void) +{ + fprintf(stderr, "Usage: genhashnames " + "[seed] [hashvalue]\n"); + exit(1); +} + +int main(int argc, char **argv) +{ + long seed; + uint32_t desired_hash; + + if (argc < 3 || argc > 5) + usage(); + + if (argc >= 4) + seed = strtol(argv[3], NULL, 0); + else { + struct timeval tv; + gettimeofday(&tv, NULL); + seed = tv.tv_usec / 1000 + (tv.tv_sec % 1000) * 1000; + } + srand48(seed); + + /* + * always generate hash from random so if hash is specified, random + * sequence is the same as a randomly generated hash of the same value. + */ + desired_hash = (uint32_t)mrand48(); + if (argc >= 5) + desired_hash = (uint32_t)strtoul(argv[4], NULL, 0); + + fprintf(stderr, "seed = %ld, hash = 0x%08x\n", seed, desired_hash); + + return generate_names(argv[1], strtol(argv[2], NULL, 0), desired_hash); +} =========================================================================== xfstests/src/nametest.c =========================================================================== --- a/xfstests/src/nametest.c 2008-06-23 19:00:32.000000000 +1000 +++ b/xfstests/src/nametest.c 2008-06-20 16:55:45.323213752 +1000 @@ -72,6 +72,7 @@ int good_adds, good_rms, good_looks, goo int bad_adds, bad_rms, bad_looks, bad_tot; /* ops that failed */ int verbose; +int mixcase; int auto_lookup(struct info *); int auto_create(struct info *); @@ -82,7 +83,7 @@ void usage(void); void usage(void) { - printf("usage: nametest [-l srcfile] [-i iterations] [-s seed] [-z] [-v]\n"); + printf("usage: nametest [-l srcfile] [-i iterations] [-s seed] [-z] [-v] [-c]\n"); exit(1); } @@ -96,17 +97,18 @@ main(int argc, char *argv[]) struct info *ip; int seed, linedots; - linedots = zeroout = verbose = 0; + linedots = zeroout = verbose = mixcase = 0; seed = (int)time(NULL) % 1000; iterations = 100000; sourcefile = "input"; - while ((ch = getopt(argc, argv, "l:i:s:zv")) != EOF) { + while ((ch = getopt(argc, argv, "l:i:s:zvc")) != EOF) { switch (ch) { case 'l': sourcefile = optarg; break; case 's': seed = atoi(optarg); break; case 'i': iterations = atoi(optarg); break; case 'z': zeroout++; break; case 'v': verbose++; break; + case 'c': mixcase++; break; default: usage(); break; } } @@ -303,13 +305,35 @@ main(int argc, char *argv[]) return 0; } +char *get_name(struct info *ip) +{ + static char path[PATH_MAX]; + int i; + char *p; + + if (!mixcase) + return ip->name; + + /* pick a random character to change case in path */ + strcpy(path, ip->name); + p = strrchr(path, '/'); + if (!p) + p = path; + p += random() % strlen(p); + if (islower(*p)) + *p = toupper(*p); + else + *p = tolower(*p); + return path; +} + int auto_lookup(struct info *ip) { struct stat64 statb; int retval; - retval = stat64(ip->name, &statb); + retval = stat64(get_name(ip), &statb); if (retval >= 0) { good_looks++; retval = 0; @@ -352,7 +376,7 @@ auto_create(struct info *ip) struct stat64 statb; int retval; - retval = open(ip->name, O_RDWR|O_EXCL|O_CREAT, 0666); + retval = open(get_name(ip), O_RDWR|O_EXCL|O_CREAT, 0666); if (retval >= 0) { close(retval); good_adds++; @@ -400,7 +424,7 @@ auto_remove(struct info *ip) { int retval; - retval = unlink(ip->name); + retval = unlink(get_name(ip)); if (retval >= 0) { good_rms++; retval = 0; From owner-xfs@oss.sgi.com Mon Jun 23 02:36:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 02:36:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N9aJL3001694 for ; Mon, 23 Jun 2008 02:36:21 -0700 X-ASG-Debug-ID: 1214213838-5c6801a70000-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 86D1DD1E8CB; Mon, 23 Jun 2008 02:37:18 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id ee2X0LiPffXGlMgv; Mon, 23 Jun 2008 02:37:18 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KAiUA-0005xZ-Fh; Mon, 23 Jun 2008 09:37:18 +0000 Date: Mon, 23 Jun 2008 05:37:18 -0400 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: Fix CI lookup in leaf-form directories Subject: Re: REVIEW: Fix CI lookup in leaf-form directories Message-ID: <20080623093718.GA21251@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.18 (2008-05-17) 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: 1214213839 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.54105 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: 16480 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 23, 2008 at 06:44:58PM +1000, Barry Naujok wrote: > Along the same lines as the node-form directory patch last week, > the leaf-form is not handling directory buffers properly and > locks up. > > Instead of comparing buffer pointers, compare buffer block numbers > and don't keep buffers hanging around. Which might be a small performance penalty, but I think that's fine for the CI lookup case. The patch looks good to me. But one things in the original xfs_dir2_leaf_lookup_int that barely touched by your patch really irks me: > - cbp = NULL; > - for (lep = &leaf->ents[index], dbp = NULL, curdb = -1; > + for (lep = &leaf->ents[index], dbp = NULL, curdb = -1, cidb = -1; > index < be16_to_cpu(leaf->hdr.count) && > be32_to_cpu(lep->hashval) == args->hashval; > lep++, index++) { I'd really prefer to have not too much rather unrelated bits in the for loop. In fact the use of the for construct here is more than odd because there is no such things as a loop variable at all. I think we'd be much better of in terms of readability with a simple while loop with where all the initialization is moved out of the loop. Probably not for this patch, though.. From owner-xfs@oss.sgi.com Mon Jun 23 02:38:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 02:38:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5N9cEq0002147 for ; Mon, 23 Jun 2008 02:38:14 -0700 X-ASG-Debug-ID: 1214213954-32e903520000-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 87729D1E8EB; Mon, 23 Jun 2008 02:39:14 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 8JPqxGKbD0Ye4Caz; Mon, 23 Jun 2008 02:39:14 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KAiW1-0005zv-SR; Mon, 23 Jun 2008 09:39:13 +0000 Date: Mon, 23 Jun 2008 05:39:13 -0400 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: XFSQA test for CI testing Subject: Re: REVIEW: XFSQA test for CI testing Message-ID: <20080623093913.GB21251@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.18 (2008-05-17) 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: 1214213954 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.54105 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: 16481 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 > +/* > + * Implement a simple hash on a character string. > + * Rotate the hash value by 7 bits, then XOR each character in. > + * This is implemented with some source-level loop unrolling. > + */ > +static uint32_t xfs_da_hashname(const char *name, int namelen) Shouldn't this be available from recent libxfs? Except for that the patch looks good to me. From owner-xfs@oss.sgi.com Mon Jun 23 04:38:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 04: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.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5NBcvSP024353 for ; Mon, 23 Jun 2008 04:38:58 -0700 X-ASG-Debug-ID: 1214221195-19c1039c0000-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 6C688D1F0F4; Mon, 23 Jun 2008 04:39:55 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id GRBaLPLQlJlxfJyK; Mon, 23 Jun 2008 04:39:55 -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 m5NBdkNW000483 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 23 Jun 2008 13:39:46 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5NBdkNH000481; Mon, 23 Jun 2008 13:39:46 +0200 Date: Mon, 23 Jun 2008 13:39:46 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] check for invalid flags in xfs_attrlist_by_handle Subject: Re: [PATCH] check for invalid flags in xfs_attrlist_by_handle Message-ID: <20080623113946.GA32665@lst.de> References: <20080531075829.GA5424@lst.de> <485B431F.2070905@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <485B431F.2070905@sgi.com> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1214221197 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.54112 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: 16482 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 20, 2008 at 03:41:51PM +1000, Timothy Shimmin wrote: > Fair enough. > Actually, I think we only use ATTR_ROOT and ATTR_SECURE for the > namespace flags. > So you could probably use: XFS_ATTR_NSP_ARGS > xfs_attr_leaf.h:#define XFS_ATTR_NSP_ARGS_MASK (ATTR_ROOT | ATTR_SECURE) > xfs_attr_leaf.h:#define XFS_ATTR_NSP_ARGS(flags) ((flags) & XFS_ATTR_NSP_ARGS_MASK) > and something like: > > if (!XFS_ATTR_NSP_ARGS(al_hreq.flags)) > return -XFS_ERROR(EINVAL); Actually a zero flags is of course valid too. So the check should be & ~(ATTR_ROOT | ATTR_SECURE). I could use XFS_ATTR_NSP_ARGS_MASK but that would pull in not just xfs_attr_leaf.h but also xfs_da_btree.h and that needs even more headers.. So I propose this simple version: Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-20 08:17:13.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-23 13:38:17.000000000 +0200 @@ -470,6 +470,12 @@ xfs_attrlist_by_handle( if (al_hreq.buflen > XATTR_LIST_MAX) return -XFS_ERROR(EINVAL); + /* + * Reject flags, only allow namespaces. + */ + if (al_hreq.flags & ~(ATTR_ROOT | ATTR_SECURE)) + return -XFS_ERROR(EINVAL); + error = xfs_vget_fsop_handlereq(mp, parinode, &al_hreq.hreq, &inode); if (error) goto out; From owner-xfs@oss.sgi.com Mon Jun 23 10:54:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 10:54:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: ** X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_50,KB_DATE_CONTAINS_TAB, KB_FAKED_THE_BAT 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 m5NHsNHK012323 for ; Mon, 23 Jun 2008 10:54:24 -0700 X-ASG-Debug-ID: 1214243684-1c4701120000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from cust.static.212-90-217-136.cybernet.ch (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 85731CE4E92; Mon, 23 Jun 2008 10:54:46 -0700 (PDT) Received: from cust.static.212-90-217-136.cybernet.ch (cust.static.212-90-217-136.cybernet.ch [212.90.217.136]) by cuda.sgi.com with ESMTP id WzEwisPgL9aWTiaA; Mon, 23 Jun 2008 10:54:46 -0700 (PDT) Received: from [212.90.217.136] by mailbackup.dotserv.com; Mon, 23 Jun 2008 18:54:48 +0100 Date: Mon, 23 Jun 2008 18:54:48 +0100 From: "Claudine dorn " X-Mailer: The Bat! (v2.00.8) Business Reply-To: gejlojjax@brandpassion.com X-Priority: 3 (Normal) Message-ID: <576752714.95611111238370@brandpassion.com> To: fam@oss.sgi.com X-ASG-Orig-Subj: Konto eroeffnet Subject: Konto eroeffnet MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------09F4DA9888F4677" X-Barracuda-Connect: cust.static.212-90-217-136.cybernet.ch[212.90.217.136] X-Barracuda-Start-Time: 1214243723 X-Barracuda-Bayes: INNOCENT GLOBAL 0.7481 1.0000 1.7568 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.76 X-Barracuda-Spam-Status: No, SCORE=1.76 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54132 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: 16483 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: gejlojjax@brandpassion.com Precedence: bulk X-list: xfs ------------09F4DA9888F4677 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Sehr geehrter Kunde, sehr geehrte Kundin! Ihr Abbuchungsauftrag Nr. 311053564424 wurde erfullt. Ein Betrag von 7128.00 EURO wurde abgebucht und wird in Ihrem Bankauszug als "Paypalabbuchung " angezeigt. Sie finden die Details zu der Rechnung im Anhang PayPal (Europe) S.224; r.l. & Cie, S.C.A. 22-24 Boulevard Royal L-2449 Luxembourg Vertretungsberechtigter: Brent Bellm Handelsregisternummer: R.C.S. Luxembourg B 118 349 ------------09F4DA9888F4677 Content-Type: application/rar; name="Rechnung.rar" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Rechnung.rar" UmFyIRoHAM+QcwAADQAAAAAAAAAd3XQgkDEAdwIBAEUKAQACGtfr0hd+1zgd MwwAIAAAAFJlY2hudW5nLmV4ZQCwhg5wFCWRFUiWGVQNnmtGgNIkGiFPgCiI CRqKTKQoiQIkyRpApGpLogU+AICgIoKAikSRpFogSBBQQEQSJPgaRpF3H9vf vvvOb2wb3vnOd7zvffcY7+/KvGbq6huqu7zd6zqr/5e6x5dXUN+V5jz/eVnN Z8zm7vOMZvGf06i8l54gOrmsv/YBWTv+NTECA/wOH+68UBYkhEB++bhIv7El gBL+wOfsv/K+Hv9UH8IIHf24HP9qJf7Xf7GSh/5M//Yf+CFYlD99tD/5WjhD 9/hKjn9wBOH/1god/fwx/ssXpp3VVE5T5iCepqmp/s1NvZGdTa2VyZHJ3TP9 KDQ6Kzk3syYzs7k0Obn/paa3J07bJ2f0ddGhmdP3WZ+zYYidiODh4YiU/p2R Cabbys2DrV/VtZ4Vg/pwGffyE7sd+xCYcN3SL9QVDRBT+qzm0iEcTXZo5rTH +FwH0E60v/i85fd/ZxFGJ0BP6Z8TMfP03//yhEWFZrwP/bINl0XhGlDKhEQW roriM2EuFv73nEJZwxJ/3/bEwyoS46d/CQy0SiM6GEEA10OvR+rnGOgrk/ik Azx4RmQA0cV+qrfpgdry7+k5ZCDkBXDsBXjufcwFkU581CZg8YJH6ztxYC04 bBZWN6hGIGBL0Q5mdr/TnsoFrmM/9WDBAG5i//rkfxSZQEuYq/q2SjXPa7aV 6c+8zOp/uHN/2/4bofsZ5xOfDMdOoTWueYRijXYvEnMw7/R37xPf6Y8UZvDz mPwG2+uv3FTI/79UQhahOA5staXYs+JC67Y9ClSeS3Vh99EzM0vx9w/cLMy/ 0Jy1bBfYbAP/ng/bWd/r0sOCX/n2eov6RqX68YP/G+6cRqYB/+4af6/6wHAE /7H69+RhJ/o0/Q//dOI/vgwh/8h/92rfsUH6gRT//GBoaf5udzP1u+IIf/ts /ozD/9F4l/2B0m/xq/ezj/Ic/vibEB/7cXz/kAZ/l9DBn+C/qn9Gv1UN/4P8 y24f6F/uv3r+qf0a/3f+2SC7jT/6Bj/3IqD/eP7L4f36/fDb/b1/TH/oT7f9 33+/7u36sxX7y7QTr+0D7S6/0kg/3sf/xb/eIL7ncMV+89592uFq/Re3+/P7 rZfex+3Zv2XZqitv9rFd5V2YJvff2iCdtmKb3X9j/g/rLQqDdtv9Pb/c+4bq 69z93/bp/qn8d3tQVFf2+4r+if+Nv/792/vCX3+1Gz+tJOv9xL/C/4790Kdf 6D962v81N/85K233U/2r/1p//5dY/0s73+6Ef/980P2Bv+hn7bAn9NArF/dC /1dBn+4lf0/GdDFiEMcVhKwEr1Ihkw24axgawh/NMyT32wOBO7ikl5K3ca9h weIBplYkhoX2SEIN9uPgZi7dLxq3A7e1boNxRUv3LoRqrKeoVPpAbjpkS/vu FbYD7FyKqOcL1UZ7YgnyTHja3X2+wEZzkXr0ZDpUgvqErcjYureKdcfhBWe/ D31jsIQUflYEjWT/Glgy57b2MVSfMQPJuQZg9oukJAzSYlKsKl8ugZujseww aSnNdYAL1cpekWFTUsgnuS8r+9RPHszc+4UjS8hS6c76QjJeW/XVYHt4Jq5h 8rQSr0ubFI4ggj2ZkqIb66+RXi92equrK+BGjm5pcdFG661EjFTLS29n9T1A CPnDr7Fh7JlfC7YEooXivF0n78krqblb3W8F/oAnHWj2H+2YfQErU4meW8R1 vtmWHi4s5yOvhbM48NpckFHjp1vjJSBXvrgGlgwA/bHA2kDA8p1S8JLzI4KJ hJiAZhFcmH19G2Pp6cQlINs7capEUVxWF5TTOzC77MNFa/ZvlnQxep2rttMS eXVxndloyaKt4yOfe/DafCY6rvX4k87V0f67BmGGUw5m+HD2PCdIHrnrwDaG Ytn0iaT3i7F7lPyw8xKhk3QEt+teX5EgpCElXKr1JPy6Ccl0wJKgmsFsWdvD AvlMRKMyRgbtV7RtSPMkbJS3rqMefDaYLDONF4VVT2YOOPFsHtnPEcCo6asm 1U5VhF/ZFiOcJjdrK9H3jfkHw671UBQp6ZN8RN5vdA5sCnRMmMZJCRF0zrLZ L2ivD3AiGYKwTUxj3tz+KEWveSQSfB0MGL8ZARct9sxRrPXPJPEcy6S/7DeF OAsBe8SsDSGO0J88aRMMqgs67rxfjGPNaCcuyWo4Ivl6AQRX5rgjXOt2gYHZ h9Ozr+3vpI5xhMWzXShYQYgWwEnohb+aSys/46xqAruiErcju57OELveqA28 fcTgy8275i8aTHLB54iHr3hGORQCUrtKKn6fQzBTzvkJvaVuyGI06ycxK4gS /zhwVroAqyoeMdx9vcgdVMm51mplQmckCuWo9DDLqC+NVxtB3JmNbdev0rsB amU8uJRZHwh8uOnlGGky/qe799LOK1mUkpfxeN4XSofxorF4t99X1k+W1y8H L8gPChIFUfdE56L5xfyCmergdjF7NPiBwgRrE40GwjBNtNHJlg5RJCHV83bD sLFu3NF26lQk39kyoFlBc8NYk5HIRENef4yPxa/ThMKAInjKoDAm3wMpAc4S Ksk00Ok9SyFSsyhKBoeZ7Hd+A5vLE5i3B+XlN31cviNJaQkl5/Ni2P8OZ4la EHhH01+TVDU/WbEFAuqtMmiccdCzomYzhFU5IwTrofReRWwPwFDBvueDCL7F N0pIX1uqlJvnf6QlvU+KvwRujeIm6sQ8MI9uwPubUPE+vpxCRBeB3DOybfP5 KCu+8wJdtbCS1o22JPqHgtz3CHkjJbXrE++hKzq7Fcwe9DySN9uMBdVjGae9 heGCUED22+hWkQlqQhOe8sHp0InsHEn6fg62vQNgYyj6Unq8S5zkPVfA2Skv YLX6yYR54XHE2qIzQKxDVMf5Jw0bjl3nFxR768+hF0vBi7ZfCy6CCosv0rec MiVijHxT3Fgj9PoSyjC66+XmSyURogO7Kx/EXMwfiDJJrxY8KVPV4rxj5bHP up7puLcwN9CgTnyQzfnTpozAX+uYd2zYRtQa06vE/ic5y3ehfNagcXxVBy55 9xHpnzcMIOzqb+TT8AoJHvRma4b07c8XPMFXI8lh7e3JoZl9rNmS1Bd8DdxG MPmcalJkqXdugaONDZ/RExHKB0olrirpp7yfUngQmSFvmxP5lqkZGMJjKP4f bXjn64KqZwdOcFK1SmauzQ7VB4vKlwPEn9MwCiIoB1N20luw7VMQSzn1yewM Nv7byhh7ryxqEQrRgGFXtddlre3CCrVPSDniuiyM77fffz1uMdcS7dH1dowP XBQZ2QOdPJ14s34bzFNRG26T8L9ysOv5sTbI/eCqHViendW4Q3ikBeRk6rPt trjNCVO0WtPANqNbF+35hl1JCZXrxy2ENe1JM9Zp9nfCVyyLdrvNU6Yd6Qsp lJkj4hHbRN6t/keyDgNVlg1v6RIfGKi9XcGOPsAnzMfkfbhd2MKhGWs9rpXJ 0K+3jQ4qqvPG4XdWt8zM5YhEmEzGO2D6Yth1wg9eEHCPJj013txTLj8nxELh gXlJ3QMTOpkJk43C0Nk6afezO3S3g+2nx2uCeunQumJ3OETy7ItaU2SxfJrF wI0jkVafO7hMLfnWpHxh8uk/flw5xpcpqXGsmubwqq6B7nrjjfQbA3l5R8ze 6WTwSuuGgyvgun62QuCbSrk5fy18X2HKDAyTYCL7SDzdQI66w6MTwrfIlZ33 pWdxz3ppvxDNuj5cyuwFqkWnO4USH+QdtVJJSoPUCGBCz7YzeZj20HAeSvkY FQPO0qXxOWF09Idy0SsE+p6bMB2ua6GOaVH7YpFSL7svPP8kqSqPKnkhi90A K7yu28XFdIgodcFIF64xHKeI1ENfjY3kERCn4MEyKrY0Eu/ALDRhPr5EFaVP wDWOJGskB5sZQeuE9GNi55ZUA50mQYjqQ8e8VorDpM1vRa2yApKoaiIz94Qs h19iYdeMtYwthjkltcWVxF2UAk2aK5sfgLYZx0A+JV32E/NEPdJMdYF/Kwan 6wiydmTwtCTvJ0oY4HFCRIFlILvVMy4ZHv5oxsNo4sdeQVLzl+Cnx1lDomdB AhW90rtm19i9xzC3YpShWa59gR5oQjTSLRFo2jZLl2/OXgMNTBt3aIWzcOSo 2XCanB+gAR9DeMK9r+aOHou5LGtK2yn3eRCuXIHkVlN7bcN0rW/Z8pza6iL8 d93CoHSSV7zTaeIGtBnmDwvJiXpTL6wkzcy5cLv5ocVE4IzV+hbWB1PUI+TU s2xqISFfloXWYe+x4aMBkgibHmkcV3DDc2h4aOE+ap6OkRYakssNogo7m/Cy 0sYMWzqmdPxBMwt9itn03Mq8nnvVkGcU221JLxuOPUMZ1sEpjGs/9Lww0Aa3 0MvZNfD3nZB5rVAyonqMeD5FjnHhJiVFjujFEk6PJ2TFyIfYNRyv3oSv5hIj 0sfQ7umC5DVrzrCYHNR+CVGHrEg+EuYNwSsmcEljZ3F0jJkA1uZiRHeD505m 5jKQZ1u9FI/JSwm73kRqljYEiFOt0ys/Vkm7BvUeLyHKIYOWESn1WYa2fYPQ 5ShY/BcN4FUBuKWj1MWi4ZwTOxBFUX1eoVhf8dTfmSK5uYG7xI927Vaxjweu eS+U0Lj4shwt2NG153C/z5Wf4S606qUTwkz8a7zy9F/JExx2Q7p0LdG2Ka8W jZHFf3jCPtCtLFsUi+MBAdw3v+4lzTuoxeicmqFL5XWKbTdwEhNYvnrcroCn pGOsmlY0JeymsMHTrnnt35qRgc/U4h0jAKXIM4z7TIsdiqSXHqaSqSW3ijb8 CWroM2fPRi+4AsYdl4ipSCwS8ChTLeeuQxLjpLfex8omAyeFVxJCCYmwshkS nNinENwURw10EaS16YOE95IzPo1sVkGFoqXF2M8udjSRAcEQ26n3GVo+I4cO sLq8PI0HaBgfqSqN8HejQHleAU0NyRRvkGIPyKfae+H3B6X3U5dbzu3+eN6K 0e+VvBpTBwOeOhfOHalczYLyBTPBXlSAZMbVxgv37UGHTv8mYG1N2/Ub3vPk 9xYBcYTKQqHSkvg9E4mkGm7jvkFdCOaFk5Y5TUQ6Eytx6cGlVfCPpicBs+Cs eqVmgviHQq5GunvGatsXNocGWCeeulzH5IrLtTRo69zEhCydDA9mduMpT2r4 RQRdT3WdQudTcFzfJrOifSsrfbHwcntD93zCGvygpF2mui/VAEoqrimT/ojY cmwRAZzRr+/sUc1qA9egewqzcgbIBPGWH8hbW55Iaq0Hs6KhWNMkMbd+gE3l S3DkDkQqi36kr4I0wecmL8+DdGSBLzDjI5BARSzRiQCPSZ2LVCF4UNoqOCI5 bjlBVvIROEhep1y/SJ1xRf2dEjE30zD6nso0TF70EL4ZnSMUtCtdvUNhUAYX YpGcIbpD+6DvX3iPj7iubh5/RIZhzHj5cB/LIpCZ5dl1Rd733DYY8nQ2ZLTS Z9iEolTm3+ZfLvTdQ8iHHeb6uRqmBIl86nIiP43dxqhThQzmosuJhnqupe9Q IKn3a17hnPNKizh9IXfxYE5aYQS3faEptacRS48dYJY2QrzAhvaKj9o5yCl4 8hnqjcPyPzGjnhngJLwMqmAmJLXohXOKGkcXTwTsPd5omY8PzN3QRhM/Jb3m d72gcag4iPhTj2rZXO5ya/98PDQ3W7XIIS0qH0G/hmnpFru9shP8dnIzM/0u 4L8vahSpLSfsT78YPOlT0Y5agZuzt/N5tjF5/MPQH4ug4xRXPSj+eskv1K9Y ocQW5+bZ9Nt3wIZ03PkkHvVXBGGzzLgHKn0bozrksIQLZt2jTMYdv0AxtJ1j ziP17oPEKiYiZkljhpyP8YaPVHs+qWUUCR4bF+hs04xCS9cpaVcgf/y4hJKP Af3aF1gZT7mJDvul6Wlcg/9c+MIy5x6A+V5gN0Q75cz1LFSBU59+plDTJ6wj hX9ej4mF5bxZIQ3PVAiU8QWsH366PlE/ZN0tSuL9G543HDW4phST3b92mH1i +h1On0n1a/kcKc8zgPJLQED+h7xC/oevHVs31GiC0EiFMXUAlrHFhHRkARL2 XNlCKw6Hcvwr265H9LRhRoqKF1Gu/q20UzL2FJm5jN3eVqzSTJ33d93a7K6Z Uo2zQlRw9PNDaIDmL28kzYRFGXU1XRKHlxO7ipk2EFz8PdlSMgvQh+nQ1wrR dIsn+GI8hvGS7f+jKEuTY/YHt4Kdmw8IPBbMDpmpKx6BNhck0vyGPFUqqgD7 gZivqck8fghGL6YPwFdVrQyTCGXh10nigqSYJ8fGuGnw+D4vPFDZ9vfvlwiR 9oOXhxuWsm/edBGnayxrSMsVqXcwBVE3HHwds0PgQW3lpzhJjf5L84DJ8Ds+ chzdlhFZXsUTiEAaaNR72iYhnPp1CMDpUTvHmAjO3Txk2j7jJnGBD3hgrAGV ZUlwqoPVJt4z9y/X0hkDmYyQai9dmUN881iKrYH2DmVi0n1ZE/IR3haC+odr 1Urx6DohkDzxwcFZM/nHUmVtvTbjHAGwmR2WTn9TfCWo1OqujbZPw8dMdRCX n/VOBvYdwf39fregLfRUuyT9O8LcUcElV07s+qr4sHWQ4X6Xjn3GOPCshN1G tmzipwIIWIuyx/iT5+yCTP6LIodZPvQZ9eUppWw5cGCPY8C/7YvPigrcVjxu SkPhgDI8WF/PKwv2g+yPab/TC2fCJjypP8sYO0Gv2ZMBFzNSj6mzv4X/EEBR oTSZZUd80k6nDLAORZYTY+Qe5M1cq95FkQuCZOVGBvUsG5UQiE0OK3Dw7ydu pYEgSgDOdBz5uzKOpqvQdWKnqLvlsA0CSXpMlHOKMr3ox7DA+1rRQtAvQRnc o2WMhD6a4/j5hbD+e/vYjeXkAOgpRPsXZ90yPyI2FJsIjql5BXwjutEwbPSn ZHj6g5R2p7fDXnx1iLneACGnRilw9aOHGqph5HztDWA0WXUUoGA19oGGGr2h ptuXv/xR1eH+d82OTMpwXPpdPaYHHw1kF6yuScuiOxBjm3rH+xO4rG177QZN iArQl1eharybuO6RvZB3ingdl7qWSOWSTozQzEMvH0lDly8xQK3agSATtjTN 6UGK0qsC1JONjnkXXQDtin/sj7fV0hUK5NKwrH8ZQJbcI6VPjrrnzi8Z1qGb cEgqkgZlBWa7x/N+AD3s+lvtfZkzg6pWSBB0Y2sqCYhelcLY5hNqvL2igFLn SsOuuq3g5j/DgXEuBjHnwlqsK+lIdO/7EFPhAwhti0W9tvfBhgkLOgnxkRsY 4SC80+ohbDd/DB1WgRbMLXkCb4dR57260X1HRbCXxsXZhx9jhB2SIffpZoyY +BxChVtzVldfio8r+CSDOeaXQd48PNmpxJJc9UmRPFtN8oWfcNW10+EDInib rUzTuQSnBnH6HpDU91hAxXJ29sRwEGnDC3fx7005pJ3chXe9rKjN2yAtWerh O609HO1YkIcs3SJvhiBECg7Fj7L7xIq4BNhJZjmQxY9/y29qYh42V2NFOvTO knnn5/1bjwDvf5Cqa0E1Rg+jqybM3siA9quMzYSfKScKHjvbCgU7FSBlykTN rXEuJME3tFTA01Y2Le4r8zpc7GNfULBpvohyJPjr9Rhb7IZUPw6A3N15vye7 VA++Jy3Nd7czIQlFx6p2JlnrBY4Ub3fK50/aIbRxHefAIUugjUWZS0lGoA0B y3gyAjVg1vl0SRFa/REPVqFocVpiIT7HjATnao11kLq+IUPw2LFb7HAqy/Qh gMhJRrqK3Kgezkp8X9oFY5QRqz2YKMqvdldztgSDnSbseHuGdIhOcF3NOmEe epLCXau/zYeJ7T4SVvQXaVLML+k1OW5KobBa6ndnd6x6GHbmREb7Pgi0hhZB jN5U+sUqF0cTIkS1hbzTS/yqIhthG0e+Sr1ENj3oYdCL9JV76VuEmwuPPZ/i eNL6sqPl7VMBrprEiwZHLxUrX/D5cXjvmtzZUEKyPMV+0sVOBl2vCSRUcR7o VOCX07Jnmf2Cy71eU8lF1P4Hc6TXtokP624JX3fa4ivDXWgGHi9PnylVg9YR nH7/G0HodzQ+xDfs7UftNOBFdwgvh+Aj9fgkU/TdkO1e26/Ewe2zujIBH5Qm FtBHlIbCfiCPfY9DQClkvDWkDU1nQZ3r9/ngEVGYwcDDl6kZ6ZiGDEwvCMHI 57ojiVM4wFOKllzzz7fTGJylx6XIUsC2vvDj66lSBwbFtfvjs4F4VnjTPmSd WTRwvW/Jr0iF3Ckc61/OuKY8sZ4hMZi5ZnSuC6hY+2yH5MUj0FmqUgii58wn nTLq71W4T5XTQcYe00Gai1XL9S2e62CiSvoEpjDxb8bsHaWIoXDOs/8heYjD dnF7HnHKz7CMBxmvBiMT2/RfDV8RBHNtoOwuNGNMezklEIFakK1PKUqNZmdg vJT2iP4zyrXFNmU36gjmesZ9drtUF5VZRje+OEQyRuT8hL4RfSLfTQJRhLIv tVcrEFjeUUQsvQDZWpxjfU5geZt+fArXEfdGzOjzgKuen+4vXQntLuID73en B08eB55bDf1MCulwkYlCgC74VJ+FEmvGOuKm6WBfu9peoDbK2OYdBzynUJ3H y9RMDifMdlGLxG8mKxiaW891KrNN0fsA45jpTJRELSA3UN/A+yfovQGokd9o HOfzEpg8HSFKcR1WnFg4mxtcq8AS2d4v9Eah/ETFxDdxPEx0Gh14kHbut/FU cJ86YGcxjJUgQd8UHVblfSWCrpF4Y7L7ujUnTxZhLZWYyHekZPQM/QVDnlOV gWmZ8XlSh0y5PP5CHKx4o8sT2RBTwvvRkbT9fHJNOyUj5MLDdkBtyrZVIRKv HAxQSScuJFq6gITk8Ck8WpZQDp73PUSRM1+IMMrdgH0w8ldjOoRqSyVXi8VE MjJRq5GWUC+i/L3HGrJk8MSOZXTrUXEQO4/Zd9nFOfO0Csz5UPcoktXuTz4h FbPi4/AbE00DbYcPZfc6SsgiHHC1VV8leqE1C1ukvba0XImaSDIMXeDY1UZP yNZV+pKvRRaAMSaP2wTxFY+zDrnFkQSE1+4e6QUJgVLMaEM7c/Bwr0KN8JFv S2M1IHvh89qQ84QFEvOdzikh/Y5TaxmsCKeXIs95C3G0BBjjS/CMe9exuF+t aFy0E59AcP5qJr7ykWuf4b5uzXcFPlvErgd9N7g8QLW1YqgxV31JjDBE4XZf sw3Lw03rj0sJ9XZJHJHPUY0V3sXieVZ21MeyJv4F1yMNO1Dfz3W34fwzPnrL BJI0IXhmuWx4hC8x6yGr7sA+FQSc+9ylC7viBbpJav9QN+19LVjIeT4gQ86o 7fN75yqBSsBSkmPv8ckJn6n0uRLl+GQ6o0Gt27Y91DnYKQ4Sjj/Fd+3NYUPy vQyOr9p/auXV9sQG2aNDahVMiOBSQvb5VqXEaCJ71LJshqqQZJkfEHOU4fNY NpoPBW3fa6aeRfTVM2sYjP1QRsx7EYKckhWGR0QCsHlSYqOls/nnp+QsfE4o Xkv5NXu7ED999QplO0i1Nb5iQsN4LxSzteuvMxU/5ghdpxI5tAX6cI35M6Dl 8utPQWjk/JUNkaedkSod1HYVvBh0qzF837fB5Y99mLWn3Ek8v4nxpjO8s487 UWO/SrWdQ2XxCPb1jUeaka0FGh/8vDaWheeD6lG8sl4VEQVm1LTNmMcWiyUB SPBuN8pZxlgU3LSrzdZXHbXZvt7rvP1Eyz/hVQolGtXw0gGW1E5H7rKX/5Bn THW7qsgXaWyAUKCVvbWgSuYNKtbQDYjq/tCa10mK5tZD1AW5Cwcev8kXfIbf 7hj1ZNnrdFzFCwnB6lQifa8+NsAwZGGez9BWTARinHJ9jFE+OJ9yr5kChoqD 0/OjEEvbbDuLYjq8/UtG79sy0+WZqrMk1IxI5hxreEHPzQeuX1yjUCofb7aw vn/0NTrviMk0bSRPcZM09n4lX9Pp53l3kzsAi1yN95p5kzyFiIR+rlakpuoJ aAqP0i+sb08nRyITz5UgNZj6nH5xk/03NS7uCwnnc6Qdrvm634uj8e6VcOBY ByzQTu0RxqPAM0Zoci+Y/azvQ+HkpdVFs5To3YKlx8rB+Ljk2B8IbrajG2Eu QqkoV19CloXUK1RajGLwutUgO5fs1viNhkkPlv+sTM857ls5rVp/1nwFaAWH vkuHT1BAxt2SMPwr+sDaLSqCYKrb8OCr1+W1e3zK1luTj3As7XFwhyqNu9md EOh1c6CKst/KxFG/cudbefwGmf2crzCs2/8VwqDaSczpAKVvRt8ngbef/Jpc KGddQR+XyMQGwb9Dz4C0yVC0camyJULDyUfH0BnUROKjr06+PqoG97+jQWaD ifx1gmxeQ2dchyQXSrdrOzd0zCSUnqXGhjyurQlcMCHUvcyZeDUuAMaVWkOP 0GOxC+9vqLnNM63iYN1RSo4G/Hqe1krXIBpm+9y3T3Th+CltDh9sE5InBV9x R9NF71X+YLRxEo0o36FbwXonG+jUgUFhK9hpOXeMYINNA8SNLrwsb2QnpvV6 p1kr72jFt6GobplJBde1DS8eN4NFw5+qI7haP0z18R2xb8wRcTTUvI/mMrQ0 zgeKAjrfsf+grNvOSMII3PkMNqkQTCBrxOxsew5CiL4f5uf15Q4Bxxumlspq oM4PaZyaPzdBP5nheRPtb+rJbRXqe9Xcg8mttqO7N8aC/MyYsV/YwlnAF9Ct blvfrhEvUmxFc87mGDwTXw1ueS37WagG76vRvTo0UTAQ6mTbIy6hGe5Tikio kzYwVj/C80uCC5Gkdt8ashRXqoFbt4Z/mXav5ANFkt6iVsmftBTp2fStuPoK giogDC97Lb3r5V2RTCv82jMQoZRkpUnrTSLEmcReDFVfVngqmAac8uZWYwx1 yNAzVEDqdezrIlDh+kxzsMOEka+ogePjP0nv2np0Qy62xghzXYK4K/mlVR3y VNeUa1TxhQ0z5qgl8eC102KaW/jtqBhTeZWSyIy7eXv8wz4WSEGkGvupC7AE M57DF9A8g2J/eVzqSoFUf2tyAmPoC1PyJtYEugWAZeov36LNevmxt/jNymOs hWMlJEihMfD5BScC/GCabMMKKnBjOj4xrZB9yxfXz5SkFLZXF1lNYXwKpHxI OZXXs7BYf4c5+2LtsrsjhwcXrqt7hNK2CJVJY461/w0xENUyvYiJFX1KLpmQ /SVUUvmKr45b09Dg22SAzI+BBJK3EeeHd0zwzTkWj96/FIwLcRR3d4iJCiGn GW3PXqRCsRJcsdef7DBilZNLifLNmfj+htaZvJ+/pUtZ12yzDM2hw+FLTZKK MWr8S9jKYEMQp1wVfgGbyy8Zv5stsh+QkW4qIUxWvFKDVTAq/r7TEHBR+cgs aODVEkEjO3GlY21+s3Z8GMjv9yMKu4dM5vOrhlLJMB/JEuh1cwlJCDiuhsxv tke86O/lvp+GENccD6xfXCaLIDfy7uDOhSPymS47rGb4md3gVeKt+uFRuFpF u0Q/L2K5sFyxFQ4zFvEd6RlY5fycwc9hEe5BIa4rLv80GAsrrEy3HhnC/UWS Bat6EqQ5+tJ1/CSD0yHhRkCa92VPCgXo0btS8D6NUHZ0ltyYSXUeDm6K/y8A /gJt1rNk3Cm9LoW8Vl/X/pcejWvXAWynq9yoMTxgzkuMKFUpN/ufg/LFR5OE MU4PdNmpaifTA3EQu4gJDxqr/jej8NOJYpHnVtrkgL3VMu0HxgxySAUXiREG 2RC9y0i47w2gXyX5ZLTP1zqgjwnOM3VDkPy26bvDyx1TROOHtbliZ8emUMDp cAo2cx7ut28ogDk0nvO7Ez41CKKE1AjZ4QidFp3n9dEJPEy83x8PfxV+1E9T c8Pevo/UoK/8bl3QrM8p5SAuhOCGq8+3S77sL9svMFDG/s76K1ANFSD5/Qu2 /j8WHZrlh8QM65tyzt23pSCnP+dyPVs9Ke0GsPFx0Kssh6pVwtVJEhervquX spMrvpnzR05aDyzigRVaH5EjfoZAmPgwDzmWgosMjd0ZkttOOspTJsL4z4sy gzToWGHpQQSu7gS/vwHJDH7tIx9zpMOiB1Zqfup8SlbBwXJXmKxfwm/040Ho 6WcSQ01Th1PvteO5R1WTs1CaBAqxuptkSVEBByTx8/Y7dLmhKclclZnVHvSJ sWRm8BFCyO9XZh/FuXvCT+dvv8uJ79aYdoj8iXxIfN1VjDPxasx8NpiGJP1p ANNmgoTJbw82g7QI5b2dDneIVDrvTeGMZOvsd3gtUKYZWhD5iLqogj50BK4p PYZxu1hAVPcrKTy3uWoUwjIf7y3oM4K1d5q+RQ3W4oDvh9WT70a6aUfLT4rq +NRS5YwX/V/MFOs7q9eN8alBkpci9d+n48ILHiahwUsjTVjMEipTpTTc1uOB b3e3YxSP2mkGVQH+7sPzi5pQ5LZWy5pnnGzU87o5XbjIss8SPYdqCcJIMK6f POyXsrcC9uu4ui37DH3VVB0noc9DFTbK9OjTT3Nojt/T2dHksxo4adkFtawz 30Cc7uZXhFe/Vk/51unL6z0ymRB7uhkSqp9nzYCeI6ml9r8oSAXRQjLJoTv5 gkx/zGR1TiyRf4515h0hw/HrPzDdMmFw8FXENdx2y/eLUqNSzRxT3y2xotmM scsFWDKHchJL6zr6gGfyQaN46udYhSOSdfnIyM8SMZsMvvxn6m+5xMIPq2TI VlN8DTZMWjHXXqwMVvpogtarcUzI4swGvjcNO5v8OT1BLKvI88kfhemS3Lli bypENf6dkh7Z24dEMDafvkpQnCbgm+axQJFdy/ECDV8b4jNvA3XX0EFZy7/g ivAzfVHL5rukPmIEA8rFsV1jmLIKpYwBRR61lDG6n1U1zzlD4fsAReXrWw/T CPM07C3FwaPkbqzTxWvCByF04mmudyloI+gZnNNab0U5MYQc3PjF5LYXUNyC QG0uht7hA/ODB+Qa/yW4gelEYR4fWzcN8cOyAZ4cs7hQ/G+UCfIA+6UgmYzp 2EkHEyuVbNwE0vEPbf87uCjSLQ5c4GhS7a4l7VqSgTjvczvPFid9FGe0Db1i o805teDGbsEqm1pN8A5NvkJ50pzCG9HoJilpE4pnsVoz43c9o04ws3nQFuFV PIs/8PU7HP4xo6s4iNmOrAH4XQy9qaTvA7eUOJFjIZvkWe7Aig2Fr9yA2dMO DWi3KYh/HPghv3vRWOi+y72/v9TSlTCjbArWPydojuYk9G+mEqeNQa0zwIno xsskW3535DG0MHKGSwDkCgeUn3vQVBsJKe8l1MtvgjuP1v0PLj++5kkcI/IH lKQW5EpCo65LQLTD2R0IpZ11Oz60pCgXUkst2InyRb6vihwYo/Vcx8ub1F7Z hgdSA7V+thHst+eE9ukUItCvk0iMWiB6PgnMxiiYg6iixI9/dGduBZYuP5Y8 BPoUfWhJSrNwgPAgGnwrT3gC0qvUU26aM+f8u1u+ZL+Hz0kRPEWrXKsQ9JYz QNtgSUsso0QXgppXv1/WwQw8nsi2stuidHmaRFbRi36ubr+l0RXPjiY8raHP rfLUr716Dey1gpUSCNOjZ7TPCChfuF17PzR6X2VtyvGfJ0Wu7S9sDVPWnoLL NplxIkYGgg3DLy3T6EWn7XWyileevDDhiWbT7TTt7G6HQRxHcYJN82knxPIx cOrubM5ThDjrzakJcTqeQeR31oPpsbcevXThV0pHBMI1dryDK7VfWNlQ9Hv/ mtqyLd/j+K88QM0aQspBNLfyCxcele+4lhPiFbaUlD1uiSM5I2cxLnFBj2JX iosF+B1z3JCjXwyqrfggua3zJqzMpDS65ip7XD7/sHJ0bPAbHmV0w1X7DrPV 4l7WAVIRsetrLad4vJFwFFbchjs0F17JoIxXzwpJ/NkDG9OgddbwPF3vNI9D K8H3uhkU26pxkwIG4543+DYqt2B5V6d4zefmMKQnSQwoG8OCpzp+ufz0HUvQ K4lKR0Sm6Vtedh/i0LnQoR1XOIm0UKNyLWWZ2v/uKPDcnwdF7M2KQ4o31GVo mH3LDMkeE8cO58/xGaF3ZgMjThKZ6aQaPqpN0ESr44HqfcLM7VJ8igF7rmGI cJAmcEKu4lbCIWWWpjy4ezpVJSzv3XwA10WwuerMfacCbY8rcVZGqmQ0F5Oh +jLzGGQaejz0QPOyqaj3f4ParfWlSenaA4nnZRHLsejbcDUCuwnaRnSxLgFK ocnSzKlMXAMs3iqcB3/qhCMk4JU0txi7F5VWGzKtJtz0ulTwPvZX1HxVFjVS cqjBisRbPvWvQEDzBaQHxnIhwSXFTXawRxfsS9M49O38tEDaGvBkr2sfoB8N YoNEJb3WJ03gwevd0q8TUw8CQRoxyv/brcqVpnczDpLdRWKlp5XrXsgkuMee h79jVemZSQ/JLPezdS4kd3rgQ4dRQ1S0qt975zAMLPI+Yh1CeO1emCCsu8l1 JdFyVFMSRJy+zOQ37cJ4KkPjScNbAep5IA0ZPoPY2uY90Ij2tvLK6x31wLoS DQbom8lUG6zdvprBEyewc53cVI3ZXRqHFV4cYcg/DQ9reUg8Uy3G5exclhC/ 7GW8U1pirmpZ4o0Qct+HMW61YsZx3QzXfgoI/xNXc0WNoIw9Bz0fL2CKhyhW YoIa5xrm4RYvkjpPMO6C9v252d7I5jQGbqq/H7jU38sHXFjPjB4XpNw257MP LXrOV0Jq+fgtkuXZAwy7ZxMlXw18McF4yUvDPo/evKVwpEu9s1FYX6UGYkQJ 0QemE8EOXHTYpmuR0QdtBryXFQ+FiAj16j555dApw+uRS3m9FYC4C22qrU6C 2bEChPlYtElKujA3lFJNzTjYRQPUzU2RAv/SXFLSEreerlek2w2kDzFUJqfS Hp1dL6iffNqURkeLNf7zFy/ML+CWRfET7hTQMbSuJCRgO6Z6GiOWoosWuY0p 8r87ZAKRHi3pKInFboMfwowWh3Riy8iqmkBfdRMCc3alDBXYMnp3HfaCIEW8 Pbs6nl1ND4/DdyOr5Ut7BJjuukFSnOWJlj1BCDl3N+39q0OLPgNhJYcpdr2J c9axskIjN+4V83IcU4CVeMKP4WHLNQ3J4kodYsuP5hA+ZvrbM/l338bsX13z 5weLlH1lAZdkenioXiZgriTEOoI483WAv6MZmu2zn1InjwZPKfTi3K8ZdFDc cgRWJltW+NFtR3ML/qDrme9mUY/m1AY3zN4iY775TCsfBcjKQY4yH09AR6sI tQ8UgYNqAFWiBKaJBpxsLNCot/oExN3noFNtKYl9sibvha5HcvTkolnckZFy z0wpYUy1PoHjLGutVEfE2RTVwPTLMZDsMXWb3qZI6kPxYBxO6RMxpev2xUmx CMi4iywhWFEVD/LoOSGywFhitqOkImYUge1CSsrdzJkT1eGBLfFgKExxrLUU 0YeDu9q5QXDTtzAxPMiqGwEZO2cEoglvL/yj7bUoEOOcbuLY3O5GAylm0o8z 7IY0Dbf11kot5XcDhmoqMN/c90YZTxYVvnhjj7ktjPkla7ytOJIMKi+EuE04 w1qbBpUEpurtYV4wjv0Rnl7l6w71LUDnMlR/n5NixxvHJDFkJiNMoqNC2h/e OycSQ/AX3uhoU/g1T4wzbSiifojjC2Jg8f7r8tSm1Tma8FIA6T9ESYsRRqAh 8Z1x65tirH+LmCC6GVcGh5XTP+T3BUq2QeAj3L4YGXnMa5+6gxA5OD6c1eoL c9hk07Bw8WJf97XRC/TGVhzhe2oga4Ick8zDkIbd3hcLjwHVy3yvi2vUQLFE nOuHm51x2C/mZAJ+llUpqYyBWHpKfbT7RIL5oe/qY3ZR18bkZy286Qd04uou W3/PbIz2ZmbZuAvXyvX+BqFSfPXPx5KqrX7OiBMPqfrQbyjkuDbA4yHW4XVp sc/12xszxYP69ViCM4l4KvaolkFJAghdyLh3wieBgQyVWGrg9QBcHlUqVY4t IU+MRbRHJ0Cpu+TgKqwyjxxQfUp72ADy29ghy7r3s4nV71NDdD7VQyVHVd/c LZI2Bgw+xMG0RUCpFQ6wcqEEMUlraVAhYtLd/tqKyGJY0Kn15iui7i0xg6fK xOh9NG3uzHqSJCCwOOibBxjB0WcHqmr9WsN4oCP1HMiY8ZIZAcfCSoM5JLH8 Toc1zNvlBTCn/Ipqb+vYvO9YMb5pINRf541sxo5RXOgDnpnLa9EEf3g9fM8l FAqXOO3adBdudNentT9dMeL3iYWiiPIrpEWMCAy/H2kJ6rkaLxUn0AYWhZZ3 hrhohJEm7su8j7dqqtCUskgTWaQu+ZkmOYB0aIcb7XATQAxO6h4MfDpJAOZb /SYZSb3yzALKQ/O3K0NmdbzCrz1sHPg6zUaNYjWMJ960LluuV76iI4o3vUq9 Du4KFQhMsDmQStc3kf5Mzr+maTJVhjfd9jclByjRKtneWyhD2SXd9O+7e1yG nMq+3LivYCGSdNGfq4EIZ4ybqIdt6TMdl8noQOxPMLGrVpj+HE7FSFMo+2EL +Tz7nESx9+og61lPQHtZX6xik8npC3f0dvujfljTs913IlSII9FDFjYp/gzD exfdLhMyCe5T+KW/zXiv7Uhia7Ba+c2VsGTS6sPcrgxySZGGsP15hKlbQoGT QGJEkoDXEOkMjYJkMQcyz9mvrGyinJoKe/wiZOmwQ3dnvQnua5sQH1qYlU25 2Ibu2yh2fakO08PF+WLHbng3D7yRPXY2vovN9+pSuPZdhiVyoN9ggywHfcBO 8Jg4MsDDo4nSTHZxYOTfY6LtuX5TM7irv0qiUtAT8Tf0HEotYvSeMEUU9lN8 FuzeaplXP2IGMpgoN3U0eOktLRyvKOQg6Hj9a7UwZn1XP8PfO3reX4y0QRW2 s0qHNecyE4ItyAcmM3bGv6Cz53dCf8tTROZJ07ACZGW/PTU9R9Awom7tmGEg iwJCzxbTNOX6NAZ6OVJ/CWTOEz78dTjHfG3mQwNQLJ7neRKI1wYkpG4/V8j0 eumJ35LVSDl8Z2sBmWWFxOnha20n23ofkZdJU3cNLyi6GGRKUIiLEL8HUcGw BIniRvE35laJOsutXq/lXw+Uv7gNZbv789SNP23BgVSlx97m3ZRlBjpx/LkW hqNulgmdYoXw0yn7qobjYCUrpOlLd0+8Ac4uvfQqlBHoBtV0N1evRkxTuGgO /FH4j16aZIhWPBK0qJuJgR0o2Bvn8A3130g6hGksFCfF0wjH+YU5D4RJsR1I OfyqPA35lB5jivo/z13zHKrUBG+uAJjfSiOyTpSvewpcO3RZy2P9nH54nmCf HseDFzPN8yRJbpgZ7572RO+ZFeVDGIudHBpdEK4/sYIhbKH8qJWMa4COHQPv v+lwCsTRtRBhRk9Lt/VFfuuDyR8MsdPtyYfiOYTudX7ndwgVBEC9qUV9PmCQ V7HLMr5oOgHaWMYMcq8WaI4qMXTV7g5mDvzgFrMP0/w4nfQtB+4KAJWvbbot THm2AyorxDzlM/sEO+4qnci0u6XmgVaDedqSPeBPieeUKj5fIRXv28yBHhtW L8IYPPyo9vpc64Qwv5QfN8JWqLJxZQ4/YRNBHy0O6Ei5YgWPYU4tZCiRMMNM NGdHtTCjqhHhD8kgJLMxXvTbXZfFME8a7YjFiNIT0v5sWkft+y/7GAK5pP3L RbO8+mN4+DoPUSOFKcKRG34jCfqRVfcj/2Bd2C23HuEmjgm9WBK/KN5pnt8Y M+Ta628XqAcCH3UHQRTx8bRfsnknOPiFj8pL3kPnByCeyaFdPL+uYlfCVe9a fJWJQD55Jt6lEO+2jX8y3TuXcmd3RBiRIjVMW+Xvg803SKuuzIO+CxxHyQ4y MefnlWMbfebZHamdTEEjRKQs+N8i6SDhg6MvQyHAdY26K1+aJKRVB47GgZyR lvL1x/JPvPDnvhA8xExNzC7hoYqlUijSydTTBlzST6wPHczUTEXfxrl7M55W DVoZfMYooQ/gNw/nT6lFp+QxwbrrWe+8eI97GtlXO2Q2aMFAfI/wsOCPtBag tKUEluT+a/TPBJ6evROjO8YgaklxTPmtua0qeHRgY2Jb9sYTPBJ5L24eNR0i MxENV6ls8BGJXxu1EroyD5uCKL8sSmCFZn4UKwdRKHCclN5jsNDiKyd0W/tO DIYMzog/m9e6FT8TYMnP6rynPD1vuh8HzzK2XulxvLxGk9rCXScYsS/TtfbK B0bFd+9fm+n1Cl9Mv11C2ch4UdRDtxGDU0Twi2ArkM7nedGWkeCmvvRXB+Aw hBdyvG7qaIFKerSECNA2VU4u5KNRpPWGF50g8HTEToRT1YMSIy5DmHoMFZoh Tw/yierU78O1Q+tczN0VhMHxUuWNqjQjLRTz1WfoHNB6WKlRXwfPc7fzAiYu 9XUnLAv01Kx9MslKmzwhOs8pxNmsbKYDNX42x33yk0/4xxZCB7sCeBCjZ8Dd 8cX1CMLgpgu5LUR02/cVxCGXDnwD9LGhz3fVwfXRHH0MO9FKTD2xsgal2NVs pW6jqmB4w8BB7rYJHQ9jzb7aWSBQ8QzLOMcac+JTB1Y9rKUjbPt6oZ8bLv1X mUyd944kik+IPvTAEoJYsdU22l+DNq6ZAjN1nbQi5tF5EVr70uGD6sOrhyE7 oA0MjRcEH3thrmQwVyEYKpN1MTFDkPTv6uZ3PqsggOpwVDVfglEjnDgh35r/ VFna3jmj/jiAru9snjlREqOcILdY7PLNusc/3pT2yBpID1yp8ZYBtqak4VnA bugEucYsXOWW/CCaEk5Ug3q2eg7XL0X7D/p7oLviyohzhvYmh60xlxHyRUsY MU4v+pOaGDAhDUww7rOG9sgrS35Nnm8/ERPwy3ZxZN8rsj4UiefyqTgKdu7p mdyQ6VrovMEvfXNBri1yrjT8pPgSrulv+ypcnAEmkVtE4lVzGYeXP4xL4MYf 9CUeAhiJC9fsewyAYM+4IL9nxCkOOxuu1EtPW9I1/m13MyDsPVSdB4aspxoQ Ybec8Jb2o98fCAB6+WqfDi4379Yr9a0l/dQyaJe/jXnnV1KcdlPSOZPWQrvO wUuJtIwM21cK/n+dhsRWygYVvZQvn/U3E1cX4IQQfH8x1BTN7FCfkfZnb5Kh ivTTnBbjGdGn9H2ppIjyHwGwXOF6iedP+oKm1/r+GRNG/inZ+FOwfbfHrq9J gQOwsin3GrtMRMuJO0yJIYDaO/CJpItioK1Jdg9y40HtTl6J0BJR21hzdfc1 HOzAmd23kOb5M4AsvSNLeGYeeP+OpAgqH9dzsln5wbeYky0KcwX5o0qzieCu pI/cA9JN01LWWF2xearqncxdbm0SKSBFSZ9X2d36uQHSmzzrNXbNP5LOsnfI PS5mziDoYHY7nnLh5BWsXpjq0fe/pRvAZzlDjJfM+bUne4sDI43sYhbG53pv 5O7+OkuO77oXzg5ypLwdHnMKWzP/uEKmV6rXqtiZY7FLuSIOOoU2dEg3MOCf zzbWZ5mkWhMkVRJ2Tk0q4bEqBs7wHh09FCOQaaGZITJBxR4Pn5+k7sNcW6Yc nm8yFey/02xnYqLjdrwLzNDv+Ndhyt8qsItbmfMSFeuqRppNtrEhywLSxNPu tYVVmOc5783NnemlofKlh18wMdhsLPwMZ2nMjASdCckvMMvII3LuwB/m0zXM pzB4A13Ka+XU+JE7hA1Y32RPwh/aK12TlL1UStn0O+kEHa5NcmHipsBWm/Rf 2KV+zACM662FSV0UkBp5Y7TL7mqfIM1LtsfpHvO6DATJZlEyCX27LmeW/ZBK lR+FFajHMXkKvEnzDcR2usjfXO3QPZgvzw9kJ7UFvS1hFgR/EhTLLFF0BMm0 l7hrtJ/bhxcMkCWx+mVd7FN4AOQ93x323QZCh62VityW9SmoRH1hTK4/RbtS g+JZZ+nu+XSwRSnTj7eSyYz3wlKuXwoihz3Rs0trp7XhDYHG1nsFDQ+p6mxc sBiuFp34Cdcx4cQqueDBMWLmeKrB4779p19ovaAS8n11tX8tLmhqSyP4Cjmf SjCdYJFz5Dtz9UMQ006h5nOGvMVOqzEsZBmCK09QDIkevFL8/4Su2QhMK8ct 9vBXlkH73wDVwVsQqhzR/nzprKNcaHXN7rYocTcTAJoZb9rmqknLJMyEPr64 ++08xmZivC4nR5XYBVIOp6MzSnDM2ouyNx/ifbJZygjqbrWllx7k8e91TgqZ GdnlDYfpFMGIZGibxss0ZQtY9SjnSfZ4wH3n5pPVag1ydbgzaXlYGY/f9yh6 qwQ1sCzNjOM2XP1gwLE0/zoJEKm0GuSy1TmOmprAodWiW4EtS+ESxaZ0iuP1 GSx3rh3LGL7Y6Y+UkeP45GrDiSPel1ccz4vo9gKMd3Nb4r4EPk2aNyVjmf8K UA8p6WocTfGsQ4UHbSJqMuuaHSsliQZ9a9NBFoWKsbtmNTqSRqCkd53oU2On UAPbiNKxzU9ZQCSb61E0Q+83aEYPXMQmK7lZpRpaHymghymYyPPh0PBbiYTn vA1Wl76H3XEke95K4DQ0eee7noOfWnsF+lXqlA+v69gFiS7j4rX4dEztPS8B yPlfcYgVwrUblNLogNqSjdqH33A4M/p6DQa4wNl2KXg1aMxVrtICeK5yYyrQ RDysVpl8HDXlL0xdtja/WGnlDTcy0BwIp6X8xdxecDE+H5enb5BFictB5jM2 j2Z091pB3WinA1vHKIgkfsmw/6FDQEMjpB4aS086S4ckyDjmpHe32gXswn6Q GGT+VblVR1lg8yhOCcd/+b4HqMOpE212ywA4kFHsVPbDYtFgfINIeKqXjaDm thHLrD9cWq5rEooTAI5iB9lda+mpD5AjcY4LjzkAesg20/XW0eEvG4mX1u1U BNnJrH7zFzukKTnZhHfzl5yQxLQmIh9fHmHYNErxD0UGF2E1/c1E2L3FEMmV LWZPpotw3gtNnK1SciwbAzOh3x/meI7CWSeYCkg4a7s178VA67Cb8h7cUvCF /q+pT7kGKxjCCpGgPdZeIgwkcKs3do7sLCKThsy5/9r9EtGQMPnHtsheRR/B P0FWOhQSVXahAZqPKZHSzrnKWzNDneobWQTLzq30fv/fXqscwXPiuxfhIcel Gc1YwRF+oS6ERVwH3Qla3rwLoOgaOs9Fa+43esVGDM/ytQaO+loQoQtJXyvI tyoHSJIjRhX0N0zAe5ZITospaOQE+3bFIyZbjcglQNHuL1R0ez+FJF0ILgy8 P4m88B3Zs45kmUgmLHZaonY8d+JTvWelnk+Opn5BuG5pHnmYyPDaQsG2Vjup MnyijRGyEPwKS0WxhccMPx8QImMqsmIv3RFq8Ji6zVWEcU+Itc8gVEMlo3NT gXrtrIgQ4e9FU+jLjx6wO0UIaspd+n1P/D0ArOHfjFIsG44pO0O8RtBL6MTg dGDI64Z/vbi/1JWGYU95HBR9pm7c8ivjsJFQ9865E5rVgxX86sJcfGiMPeXb R2RYgJUZ2MxbXvbIHtasr44IeSyOZu0NzlbRBsdUiE02+7UQOvZ8Kuv6PJ3u FAJqnyjL82bNIuYFqgnCF8f82eCaXZSDIBX0eEyaiK/kaAyXQ4vRIw2eJJln hYZdTzjYD/uU43359+hAj0e/uL9d+pkz4SFVbetzb2vAR1fQnKYvplIhfTZh vLRxKcU7F7CMFLZOevT/I2ihcdvt/MxZ70fP6i/xE/aBNJ8bK7IDKhPG0FT2 O0K9mostOExsUuTzYYsEmQyXPsyqFte+CNut35a4R+1nHzsuPGKcdHkXoTJs 2mWqxT8BwfQCqSpsxGwjhvDJWNVTiG3p3AZHDtLWDfzdk7zoomwIh8R8u4Pz RUl1AGCYU8qo1tOiApPuyJOaqOSA6eSn/Sl9XrcROmbPs1T8Sn2kViBfNZmF k4jAeBAx6ttOVE6Jo58l81cjIV1Oo11Q2i+kQLvruuVAcO9g0Hvd+0DGfFen 5jtU5YmY5H069uKmyAZFynuEdR/dVTXF5GKxTod/2Rz0kovmmRPIFPFZZPuZ kHuUCdj8TxmPC0zAWsLDKlFhqGYHiSuoWmSBTfnZyNZz16zYZk7n+V9QftEu J9lzkI/IrReSkHfI9aN+VhtIcm/1EULA1NEwS9qxNjMRCMWJqV+7hGlm1B4+ 8ycvjc0sIketef53EKco0+H0Cm9whkAncHyFXu2IxzEYreT3SxrFXhGIfUAO 5BQkwi1/DQFGJHrYTv/1RKAfziABkN4YA7G6TSZXYXaTNNXYTo6l1yKbTkuP oYh2cK6ZXY3YXHUypAQYGMdhNJvN59Ad/l/hGHqbz988PnpTx8/P54xSed6P a4OijXcdtdlf4IIYVddtJQ0R5Se8VB+TYGXkosJtKGowBhJ8LAuZZiJJuryD iF1N+GNJyYOpnLtwSQRUy8XyFkQ75CyUlfPj/hPstx2WFNhFfT7myCy65irq HSFImrQNNZz+Y+i0Gb3Ran0HWWyKracq2bE697Z3hd3LTWNUQOPzlI58vXAb Twegubu+ilHX0jENXQ4sD33vP8QmbeRAmfU6MjL5ZJQM0E59QlWaX3Al2GaI zprRl9SF0Onv6gzKnW+Cc88aG0ZMCp0PDIf4cbJeD2SdCZx6fNuCX8aoYWo3 w9Co2En/jRHH8+6h/0mR0Yd/RK1C65lG+Ba0lO0M1VirIFuQQzHulYSbMsyx 8VrlJwxfWctbKwnukLlCKmyRDxJhWd84Hftd7exwPWuqBVNLwX65+WJAmzYM isN5jBPCXBCR6ZhtzUScfgw6X33A92nZsfXZQrTKCcXio8NEGZ4Iud7p3LpY GvGoQZHOfBtF9Ux1NLqNcFvJ9Z0ZHVfw5qdLlV1s0BgHx5M6K0ly1EhZ4RSz XcljoYdf4Z7VLG218gVOfPreQK2Xl8qgd/Dgj997SGpMO5M6gy1WoZTlroxk XTYAyblYtsvwCvXbNjHIXNTA5l6hszl8f1fhD5WWd/WQdP6ly03QMCXWKP2E rNlrO/PnOkEA4K4/yMhN5czvoHI36/r9nPLWMOx8Dc8aYO43g7JTY08YIjqE VgEWQ4yeRxt3+801wTPzPJtW6DktB6Hl3jHuEuKhAgH3ohq5dom0sumorTCW VzsZMxDzdUpAen8+17tTeRCddSoinuHCTRjwZUFIt27NdHhQRnYnf0KXN7g9 YSiloDky8o0MGGZ0k52dvntIUOoVWNbZws8BStHlvXsvg8oOlRDLLNJ+YV/G 9w0gOvGuW6Ja67pMFLRzHK9L45NTHtb/CtDXs9bBWQyGL8XJ7sguuiJxiogl fv0N7TPnRLGWQy+uavZybWXM62d7PZ8NOM7q5UvJ6L08Vsnk/54Eb+EwKWBw e12Y9LHwWdfS4/aKVCxIVvGM9SjIIB1b2yQXWoxS7QiAr5ucCBVyhIE4fn7w dR/cGv39mXShUhwaG8+XVtGKDSZx9Eqp9aSTMK+lgX9oRPnroGEtB4pnuG5u /rZQSZsrcD0K80YI+Oj1ioegGG0IUtK4eoMI0QVYHk/YlO9i9GxDn/BMM/n5 MYQPiojCeX6/t+sXh25vS5yWT9f0CfselMNd9O6QU0+DGmjsvYkzjZASez3n f4OvU7YH0SRWDZrCewJu5nxG3xrZE1O28Pwhn2wykCFy8RmKFQJMS6mueN58 qfwZ8UZ/pIxvoiqAol0ScT4YmFVX72wiwfO/JepAKbmc9XxLXuzAYq/209K/ undAYqX7t31+58WdDifzKdlpyN+fkxqQezYqMVBf4NSaJR0C3BSfyDt9RCMe MIjMnFxNNR7+CDB/mjrV1Z5wclcEusbODlFLp4PKLv9l50/7W58vHvKYeg3t 4pG8jY0f11joHZDUUQiEIBtjODfFoNvxFyQs4UUy8pSNHFay7E0Freolj+GN +4BS45a/TMpCAhiP8hJJiROV4beVvdK/s9n+9mD0bc+ubnK5FXHx6cCZ2cqM J+XdHwozZ1rnc6TaYG1wbLJkl8v2iO9Bio1f7/13keSBNOMoTwJRiSibIn5s yyf0z3ZyqmP90MdmuYObsoxAVOK9d02M8jUEF1Ghh03zv4zyif0i/9yQyTx5 WB5SAouvvv9Hx5UEm8y4CmeKWD434jDtXP0j9u67LMJTD/tsNbPXXx3E0Ocn VI1lzaHWDjTCqJfK45bwdMKTJ8f5972hrImn0cWZ7T/qy4ph2m/h9Q13kMB1 J2egYw8ypHJaNQuH/dd/ncy9fNbssCFrqiS4vVF1Qzi+0cuFB73RBGMimQJe SL0wdvWReebaPSbBk2i/lwzVvThiwnI/3IMQdbpXD/Pa80+F+Q23HZ9P7JQd qBzt/69mx+5uMSzcPNcZLSXHivlT6SUgS1t4qcdpvgbara/yH6r4QVl+RMUa M09WH74AO7+KZGvTkjvwRGjxt1bqYHVEQOMYti0S3eZ4P/YYP2HZ9zznVYUZ MDiCS635jvMfMz/iN29L10Oee+8IqHQr3Z9P6dfXUd9L/nMayRcV+qJn6YIE 3cqzMu02AHWhF4VB/HD6O9OuH8DXOgnHqnPLbEElx1WX6jbwDAT2frRpS/fP zgxQ46VJTdjfwJQR8ogJsch9YelvQo3wD/x9n+Zt2IhVVjWjHpZuTdeXGFrT njv/sKEkUq2HnbHKoWSacvnsxCOJ7TM+PhoOmmPnKMU4lLKzD9IaUw8UJk7z eKT3X7etJA3YPgYdrE8FEKvPOVzMkn7T3yaIMPZ2LBAem5jcWj+y2Vrzlb6r OfIpQfhCPLS56Z1ucg+NZqiI6y8ggq9L2sTThemqB4PS6/+rWVuYd2gfG7tv OVPBSTBj8zj8cno3mkUVPey4phNK5Mv0gOJiTPY2M73xB7Qt/xU7RErRi8EI ysNxH1D3JaTMRZAWIZLh/uci9b7ALQgvuUiWldGvwdzOCfxVzT5r5r7aSodk Y9yu7TSiIyChkMh5eig+1BW9oH24zflXd3JSzL1FqYN6W54CUpnREL8cd7/K SqZBisiUDy22+ZPNQa9yfBiRPmco+HleUzqkrpKP0807xSSdZZk13wtoeLE3 Cv4GF5kgfN+NVHkaxe8Lz4I1JOctwfhjfYlY+dfVf3EbuWYoep0Epk5fSfHC S3hnVk3hO1OEPBkI4zqlU8gVNkrKfWf9isLlpyIfU9lbsEtEh4qNgs/RF8qa KzSroXprRlKesryXHtzAzEuS8JChLZE45ZEmVCr2DWPU2693lIGEHtpe/O4i 4kl4M2kaHaESYeafHNEVhYK/caV5xA/OCNn/Qn2XYroEozSo0HHlB3RBqdcN u/Xi/HkAlIlLM9BPfdrghStXZ/45PcL4289mI+ZUoj75DL7jMLJ98KKlvElt pbdQhjcizNq9AoZNnK5yYxB0CNZbTDiGF47lp5/G5mwFGvWCZnjl/ighs66Z MCIg7QcFw31nPR716HM+VL8D3MqfPPhqBWeIi7IDjae9MQ6BbqrDP4jGrBu2 jJbdttmPGIqVh9Ob8pudaN0dCk7Wm8/3xqW+xpJcZEw+KQh7MfdaCr5H5L0x +XGIELWfdexn5KKGUY/9dfvm0+iA5i1z0kwjRVMZ4KCUDO9/eve0bYaBeeEB C9j2mmM85F/Sji08XLzrIeBme/KmalKvR8IXyOhhinK31gxmW8s+olYBSmKn cGWnZMm94TSsz2MPUUelhXAqwObRO72AFRw7XpP5pGNwWrf4Lnt3tm1VR+wA SbZd8U/YWIQjTq1GcRSbgQ2Yd/Lc2iNrZR1/ab51bUYf8cGBoy15FwUkj/bW JsrMxUp6V5A7SvyUpqksTju+hD1dzPYK9vNgD9O4eR7ZSAQ6ygjr82vxUiSv Bi97VnVriaFCAtl2D0fy2PgfeG6OckXVYnAzWXrYiJ0kGEQpIm7CONVwXRYZ hXfQ3KZlBlW7+A6u6Ter11J+IuaxE6zos87TvP0LT2AXxsyXXYaecz1sJOLL dYX/Pz6Hn5AdTkVTxftVy6CK1zD4nsB4lEVvmalhUAQf395WIU3mk68/+LG0 4uyY8xtYk9/Oj85s5Xi7oICHA19sXdC4CYWI8ajZ2gYhrOmVfDj5k4oSLrFV E09OS6Hq83a7u92xfeD3KqvtZeLz6AVzqrxUjKTKR1+GIKbxzeR2jEyhyVGZ 0qDmCjTlNDzhKloz1yUC6cEiYByHMd77ZgpagL+6mLU030LxA4SXPnlnUz+g BrLWHI/KI6RghI8gUeQz+RWQ8zSdsYKqyO+W3DBVK7Wpbk2dBX0JXB3Ptg6J 1LIOLdjzhhoyeasc+DPIg2UjmYDBnj08BOji2uBphycZNZFk0KYXzEv+dtnH //WRqbIcjqsYw8g9wcNJ7jN0Bn51tS3DMO9Uw2SAfCMU2T9Ef2I/iq7mHFKg 1NRFa7+gSOD47lx8va6Ybn4Tn/t0vzNtfwiBZfdUZrfRTJu2YanoPPpIQHh0 4x2DVXPtnr6gfkAMOB8Oud+PmtTiPE5XVdwlHJpndaPPjVTXcY1cDXzbd374 /rI+nzQtMTT/GVMdryZ9+Hzq/E6p+/b2Qrqj7ZqrKeqNFM/BNb2d9N+PYjzZ 4v5aXoqZXtEg3B0+zXLHz83J43HtBxzvYGUFpK/oMDmE0dY9Br/nuiQMxfjJ XAjpRhSf93Bv+NdVMeXX3k83CQEtjSPkttCG9JDAphcE7nYxH3Kgm38ZUzTZ W+Ucil+F7RuzJ5UIjgw3EWavBZ8ewBXycFotUNspBpnyUfzIsneAZOduao/9 DpnBDHuI56R+hMZi8QvmG0xSpHFzru52AvRd/yqVnf8RHrdHI5Q7N9VJsRyG QVf6MfH3W8+WAu2fxc2GI1Pher4LdjlDSNo6Es/9lTmDerYRSOKup1ZmS7W/ OzzwgrI9Hgs+l+atRGl7WYsTkkjO7Iyn488wE1VGg/R521Dhso/iZk2cHr3R 64MMvXUmojIl2DG6dIqLuSEvA8BQ5zi/J2XjDAM2b5lJh55EIrM036oq7z+o E4rxcKkVx0Sk/mPCt6I6mLHuUAHIV+x3FB1J4fkXPq2zpiCFv3UStixizmWB cL09uIcLz3RYGpP6esWlBmS7kB2G4JW9pTT/5Nd37jk/DRKoA/uFv5LsTjbV 7LkwtZdKXBCS1gQUcD3Vb9IMSHnYtfayVQ18mvVivY0EUtpFCTza5OJWTJny Ecg+ruguKMPoz2nWmMbMK0goDl8mjfMnyXsHEqyNhnbqOiZl/Dihu/cjUiFp cMtJ8NWJoiV29ZxdM3ynxx4QUPo9S/UU2FyrfXDyqsOlI8S2EARHxkk42vO6 xg7bQlxX0wv8oP/ttp8dr6b6pEcnuYerbIojfwFj5BZQ18ZHHlqe69HQTqvq 6ked7cmXwmPnuG91F02JW/Ka6hP2/DT/VnDV4VUfYjilwiVI6lQ3MjXLjv2J wYUrspfkuGJcCvKqpOE0rAWhobXS+Yrw8zcERg7DjyjPfC67m+CzC2MfnXtB +35ldJ83IIaMyCMuXx+xv0sRO5yOy6UeZLcg4M4cu/Y2CmTcUCqUFhwiq5p7 QOWfDN8A6SosdSXZIPF2ElA9vqTZ4iLHyTw9RLGUncmljCorMJQ3tZZcguUh /t3TvO+ZyG31gQhPprD6XgvgJjZrKT5X1VDLLd584TNbHsmXzq7NsekZyO11 vavKR4BRyrEc9I5KB1JFSKvFkP0QOJXNydYkc2IBRFaIuUtrkSB3zb/3Tc0Q In8vq/fMIZDcFQNl8LN31fHW0LuxzX/8u/c+/8l5kvMFxa+YYhbKfUVNtMxx 9fKhZI+hWc7+Ns+9gPbl56ejEzvW3fr0LfBUP06BB4GuWUUJ+SETcpZUnJjF US2NUE5L3q0H3839gyawVY5vSy1CHjiHR+d00oJXXz4YOT3h0ocMz99a6y5v WH0ugrhW9uwIraXJPOYcxxvRtWTLAvuboX/W65BFHrwUApLe9dJJxg8oWaAP 59uQZZCEqrQCG5SlxWurhGdYO4cWerfOOBXf+Vrp69TM9NwBIYdGjdtdeF6P sBQXM+lU9qQ5v//hgFMPTmaQ2PYr9da/iihHJq8wdYL/bdZTv3s05Bkww6a9 zW+v7N7LEf/Qo8hVukccteZOBBHupU/klICesoMg3zsI2UidHn23+9D36Qxi L3aQDB/RHHLWlf/ujDy97/Ad/PSf8xLLx2ELZWtg5hzfh/+rT2Wv4uAqxSkB micef9uycbIqsRjprtvf7MuaJYXtcyMA/rdR/cuk1IANpDPQTpI9R9F7rFtF LItbHmfvIlWXYwfAHzueEiMXe9J7+I/sF8+Ur/B+Vw+YRKQjuMWX0VMSdZhR fR1B4C4bXLXOc+SxBRYMLYGP/Q+oSPY6OT9zN1Rl/05EaWyNABUh48Dz0f7e 0XzeGexSsTZEeUX67CrD4qYd0bALKF/T9LvLUafnQNLDmjDL51hEHrs8VgM0 9EFnxtjfAQKI/K1TeQl/+WXw3lToCtdsRVEgVSLIBM/nttIYMDiuzYXvip/l yqPVjkXGzwzkOh93OlHL3mWXXXgz0G7L0aD/2Wx5ftjvWF8GHTjafNW+tqC9 HWDsaaDgdD578GKyabBdEYmxLmYb3tMTN3/T9l5NRP776sxhHPXmslyqYYyG vIxqNBzRlnSSLz1Pq86N5N1KgqMZYuHrbnYYrkXjYehbTpGyloyvcbNHnXkm HuNWr7wkGTyYZ913vxDTXTVv2/Iw6LIaSx+HLWe+tRyu96INtqn+L56t5rhN pGLLWVvDo4kcXxp9kFEKydzxJBVMBue+dHUbvoQNXsVn/Xqbj+J+10zzbdjK h+/jkEcNzCQXRcEJgmd+VHbB0gmtONm/z74mzCmsWQ+9xR15EhsPw+f9F5lp ejOhTq13dSaAvM2n/q7JqsrrL5nC9zhgMX63d47ONorjCMOjszKxnjEB+3oc ns8ql/2FFcN4VZBvP19lbX09Ogie+yERANrf25cbItMh+zCNwHkdL0uHbO9S EA9xJvkNBMo/vdfTxxTFOaoHwXdmn6NFncQXQ7UR77bfo2FEtykPUndGuF+d 0FLyufmLMWt9gHu1bfZ0NPASA7NdifWvD0pAOKktyWHOvLGB13hvGtqgrThh N8nhGr0AW2Oe/keBw+8vGMWprUfo6eLtQX2V+lnjcRkrj0MRbTIB4LsAqBwd /LvtMthesPf4DomofGnZL+Xil15+nY1bopj1fC3lD+hxeBB93HnV9Jz6KB7+ xP5Hyghhzr3DuHnPTdh9LlBezTauScHdXPvlVLGWw9xGQRaZbUhjzy0RGeX/ HuKODroaz/ptrxV9T4k+IvitE3XLteZy+Z8dqyb1eRBkuTTpGGh3zcObRTag qGlevf0y5wn+uxu92g+Q9KW94+dP/b+KzW97K1+DtDmy7z9BId7IYMmYEsz9 dnSFEUdJvDVWP/hOVRfXzkfalAOZDAnPx4OtmhR+E9vCibto7P9QWM7wc8pl MtvWVjaTBG0zd1gX9SO1rRkXCUGjqYRPXQTgJEGD3m5XqS8nTpJgEdBx2vox Hv9gXxtqmDJiSd+GpPPc0WoZrkTGX3IETq2p9Hiv3tpMns/PEkRwdb7ZHoKk IhTQ24ZF/M+96uAB9h+Rttln088x+xJcCdPE7argzxZOha4Mt88qq7tyC6yJ +iqqU15gQ9KRdoiHM1cXLextYxD7BHwrijZUOX22Jb8chOZAI25ovfBHxUSE 0RKlTdoi7D6QyeUfh7zbykgnwwtMfTMh++jEc8SPV433S6UkBpVRdZ53lKBm RT3Mj0g10ApPl+G9TRzvVSXXLDvJW+dOkNwAJKNDqHvXuyMQvdy+J36taOeT bTZzgNc9Fhrq7U/3iho73yEeruHxZaXk5/y19ozVjJA9WXXZkUnLUA6hsfeG cPHtpD2wztf5Kuvk4LE/1831oGxLi/ecXf0ZFdivl86B2KFGQdGjy7AJPAQM 5+zUWmA5jvXruZBFlA7Of8yJ4dIuvM6G2xBhoOHHNMBA+5HhcpUZEAyysTOQ P4nrZBGmTS8Dr6HpzFXdy6/9vCY1jpP66a5yXfWwwtI4NadkzLErfpHu2ke6 YYNExzCcd331uHXgYnY/prQ4c3tFz0IzLEGLSP7Jn+vy+wPb9xe6pH4H5g+o 3wy9B49cJ/HSMkxlH2yqeYFut90/yL1Bv2MCDzTpHPTLwuRA7u8vmj3bUCAB wP/c78kMpWSRkKwXTsry6bHERPrkdeDnZ6bE3IoXrh6jDU/N3Hfs2SMWxm7h REBM7iyq/q8Mi5KH6IYvtLH3uor/39u+HCpYSMbnwePkbInuTeWKM/biMSen rHRLm/SD6QFrU/MxIN0KXoXd1zo+Q/AZHN64+oznfWQjESd9s0TN9AGbd939 bQlqOEx+YxkjpxkTl5A+ITpZzciTC72t6dKojD1uDnrhBZcifd+l8uBOYQsK Z3Y+6k4BXD9F1HKFJ2y1YnmZykb/Fk5XDoc6A9AKpJz11vsNoXwfAy5vqjxl n6Lq21vYGucKD1PaCO1hRp2XxYUZ1BAd4t/AuD1uiMSb9hBWa4tVQd1NBYPb ZIluUi7wYC3loCTlfg5CiEvnUb5BSMg6ff8VpENN7iCCZu3OenNjtYnsoD/7 MFDgpVrnf71o9g10775D4MhQd9GnpbkuCTcC1K7fDpEKRUIRj8VusqzAZ+vu rrx1txpnd976iMgR1SQxydhlIbe/uhysYLU1Ka0b4L5sTd35jES5l0uJ83b/ d5yUMTIp/i/FWC5tx5u4IfXWP4GZ/Y6rE+y1PGG88vitSbtPUDlDIHHfO9nI Rrrm8EuOP9NLJI/uQE2vWyDdfBxCpIVQebjE7538U3pZbtOJV8MZNhDFKnF2 e3X79HKCLtQyd2flVtk0PED0x3I7ywmkWpCPBB3re+oqr9OwhKz/jlJyzbKE xNTxpwRgtbk8Xw8QyGzrD0/ZuFwu30XnKn2LgT2HnEgUJPDzn57PrPAKsSk+ B/pxMeHybWIfnpNMhQGkvjLyHXK1czJ/QpDUd1g8XQXRSNH8+ytln3b3+xus hbGRvDDWr4IvPGqLHUnG3P5y8C4WKF64p/S9Y7+arMVVQalx91nivtsIv4rT S0mLWBBmviJrW9qH4DFB3OYEYSKpxz8VApvT+APfvvO01OBsyVfIds5Q26RI BbIiTL6yJX3Ktr+/jvgoHXc3b75h42Aj70685q4rqS6stXCSwhNXdJkUyfwG zoG0U4Z2b3sbWiU+POUJI0LNyoFZki3pyDvkEt06aJ7cUloo8M8o7axHBXCQ 8JrxDj+4cy5B1Oyf80XgzUZ1kwVtoxy43F1skEn3RLM8PXifgwLLqNo2nw/U DCJ8fk1vgZfTaugjZTAnZfqprUlpVxAGP4PUZJRUCYna8TR9A1XROhg+Tufs eSKd/UUrCNcA1/fz1DluTdfTcrjGHv60kWNHqkOaU+uir+KbQAnD468fY+7R 5B5/k4HdghUKwFFG2TiFvAOajkrlOl8aMR3NE+wJDq9AbBS4tFzoVGZNb3r1 KTbXNCxw11qjGkdXAsja1VP08F90KsdnDoC0bJrQ2O/3DFiVhPQoy8PTo5BN QlqZhAg3Hbab69nZMTfqKdWeqomMEf5A+utMi6ReKmMLix4/If21NXC/za2i dkDbxC/3lx0eKZtnxN7WH0oDOWT6Hw/gyNuHJxYYaYRXGbmdQEvwWbUaP3qK QwG1vjDWULIcOuvfbDIPhenmmhCKlms1eiL+7xZS2EH6IvYLT4kEkpypyeFk alB8bn+Y+3Pw6n3D9ivgm8pTSo2v9oAIXFHTKUpOwrhJXMXj2VVNIouRQUA0 GqY1bNYQEi2et47VXOgcCcIlLn2rVmz3ABTgr4pWaH6KP9p51rB8J84YwNZU z+45ocFQDDybPXZSOSogHflS4rVoelSAp2/qm7spz2RkI5S1si4WB0wE3sp7 cr/Tpugk9f1+YTfdk+EREuhx/fP5GxT8AXtOEKTdhyGqEgT9/SAoOcvvTh7S SIcEzqiTfbZu0LuF4mixzdIDjIYvD7hNFi082uewbXPEWKLezO/WNJrlEQ58 Gx+9uVXLekspW21wn0zHNRJTSl6hLj9sR1kTyVaSj2ifmzr6ya8UC8pwLWpf rta4hgHK/0el69jI27y9i7IJjGKKiwj1w442SeU/6oNUnL5oKr2dHuddXhWJ wBQwENLjH3i/iGN1mzQyyqONQNsq/73u5ED0GN6s9Y+4iV1nr8WRHSetoxjK 8wT7FpnT5zYhUmltg/EorS2UP2fzFabaYkujGPwnwLBKzqe1JVYiOxfVljrj kshlQ7WIYRLBjV2cfN3gg8hjKxSpkklGuE3vNpExF4A6sauRctEPEsoHNX92 BLgUXHe/4Ip79FzstJgNjSyBcWFzhpZ4Wz+zRBkVRkf0+xv54F3O+kXBix3z GDE1mT9WVox988UjwOFTpNl0RjVpP/PZ2ul4nAR3WlYvBer5TTCkhWHsrZRi zGbK++dDYZziB7pJeugRlHt1cpn3F89LAJBF7sDOSfj/7IVhJWnw9HRowxE7 bHdWt7JyDa1HvTGey6ixHyMucOLeHL4PjgAcZbG16dC5Pv/JVHvQ/sEF1MDU 47vqm3BItQ8C6teT0qZjBOvQB0L+k18bHNpI9DQa48z43lop4xOhVPxsh/vM 69bxQc1xYOj57Oo+e5IAbU7m7TvyeO8A46/rsZfivbIQUES6YzPN5mDFzuf2 wtDaN7qHVXv8mlKPedZyCZOaklvbih/GqptU9YyOg9m0qNr91mSQiQRc54YY jucV0TK/GmWY/PJTI5jllP7vKLQrJWCp8nU8PXZia3/lNcfIjyUjusBJ5n5r jPxf6BkOPl2n3zg463abnsvSVaUCV7udemw/Hg6+q8G+Iu5BZiylpVp1wet6 szx5QRfKep7u+DPotZaWzboiv6vjoUTE0EGyvzD7dLJCFuMJf1VEOdFfR7pK n7IobKVdFkjGs6AmSFWM9omjfq+OlhJ2YO1nmst45ZDPrSBPBKql/1DW+bzN TC0z0O317OW9guSfh4pErvhLDF6tMgl+fYgKafF5ZpepGnBgoXWUtTx5JNCB UvPUEkkapTGCsDv6EoVbSVepLQpPJdjpspcMrNdoOl5Cjg9UDzroqp+M1EEf 32ur09DJtezxEsYJfhedMt43Yh4vIEkYRPpzzMuhrUmD7+Wf66TQ9CnDTvF6 KKl961AuWbG6+XXv9SFn0ZD1GDOfISaZsocKnVI9+itITE1Aroyvj3FMV1kZ yUj4P7ckijhccHnc/RMNEGvxDou3Bg2RjQ9YGGV5znnkW0JBpci3YW7ejqyU WrnMPGhWD1JJKJIIY2W2xpR5i9r5JwPGSjDNjyyN6Bm+XT8TUFVRkO5zaV/G Xu30WTRCpaDxUtDRN4Apa67gjCBqzUGZ4+kS6KstMBG7Tkuefufe9EObr7fF zi1t+nYZCztB5XZv6t6p0iODYh+2Mfx6c6YgcIoK6dvEkMv0tyDqB9EG19fk lbj2Bqls5vNHgerr+IX/CTYGyf2Al/+qFLt3X8dmn6GhpA0RIxkw1kgoZG8f hZiO9xfoZlMGX9RrsNNd5Bkqwq9vC2RgimR8wqPubpm6C94GqsIzBv10lESZ GRJNO2nRLCpj1nTxNTzq6p497pKAV6tRNxy/vfYBbo4DA77j8tgzs7rGGQ6d JW3AlgXEvXp3KTnFvp2BB/FT21lc9aRM+6SMhrGFCvbegxv9cNsWgDao+JWU DMSocDrqudGJ3/nOcrxc3gujlGnuZg0L7noK3f6fI7gIP1/xaWx8BgiS0e1O 8pbmoUtdMbJ+4NfA8tgUUFeEH0Xv8R+EN0xwnfaOF9QhkgTucFJ/Xd9nkWem 0fI6MJT1wg9iMnSGs2LwxoS/KXCS1vtF4BWVloyD4Irtv+KHzQ5Cqb+asbQ5 zG3wl55XMnVHf8ZNQe1bJ74JAcmMo3Iw8CWxr7e16YQbMkL7rIVt2Mx5geDJ Dy9komUsn+b2bgu9T4OZ0uAPb8jbkr9xbwupgnbFGRdMk7CMq+I+C6f6tniV 71CoQ8+P25iyRks//uBB2o9OmWET5kve66mSTVmPj09f76iD8ZpPAZOZzkOP 6BYzNWvKmxKrQS4PpQCjUsz8CK3TEE1+Ce7SZRlIydJTWorDFK/YwyEb8jf5 iAG11vJfc2Ubo4Ef3S5Aie0iGiPRz3HFRofDcD/sh5yduT/FFfbZS+JJJVAo 2ApU100/cKp2dk8t81VEwre0g84eneXE/uwe39wiMI8snEqrV0V2Pkh9khTz T4Oz+DVffHBp1oYxAiQsOj1hLyf1GZOoijK5eWakqn5wQ115FtD5O6BNCHXw jCL2PAa29uXohiw/47FSBdhFo7GLAGvaVhNvpfYZ+yfzOE7hcM87leAO/v+a Yxemr1ACUjo6LPEGyaHbdq6EK/pZmYcaCPllX0Hh6DCoU8caOlpqf/Me3ZUm 2xrZwjMg67HrsuKQDtYRJUjfkrFgNk4vCHKfp4AIRqZvN4ZaSyXvFDRTaCRX sJ16yWb5oZyZ7rXVYf3Msdx36tY6H4k3bfueCE+G7Sm//QnNLE7CVcyVuwZh +/75bbyUQpUppJqrriAsl+GetJv1CWxV20hGvlGx+nZCwYmR7Nhj00BPEDx5 6OSrcINBmrt194up5gPPxXliDx2MmBXPuOdQOt8ng9PtduYlNupwgi+Eb2/Y 3ZiCjcqbb1QP3erGvmNNMCgs5NQpxJzrmQvsxo2SVtbl6qAJfDHjZFQz32wu vcPJA2y5L27aS5z/+MeZJr4AxdJafblUhTFydgjUvLetey5xtw2my+i7RyjL s5J822hwMZ6lFoX7YnfH8Om2xpY+Ap4jrK2OaoM38tTyr4nDPNm4dWZfepiJ ppgqvzxwKjZO6++mVInylH0gH1G2NHxZHoU9pDfzgURKSDDI8xc+30oRk700 un3UCJ9Hl3RQvv3Mj7RpObxHuCP8DDkTQ91LIE1yMc48SvbaAnRHY3xBBC0J C0eXmDwJS1jSI4Hqorux2LRzEhAWGEhFVfsvQRcMtefgyq7HcvSQmvc2FljG ZS79R1wM0LXzOEZbvk0jv6Awh8oRX2idxxN4z9Zmi+c+Cxb8E1YIAV9RzQ9x 3kO2bwHoM3nc47K56V6AjR0e7axrILF/XTXliz+J+HpMeyinw31HHsjHbuB0 2nZ4IZ0E3ovbtBbgMMVZNP5QraoWaI7bKFzyOJc/TxqFpak9eFZqSyuvehxW APzS+Ki1qXc7k0MqxBjkta8W2T5FYq6nKYlshpClQyM/d9KkUAT0mb8pZ5dL 5KUh6x5n5tpO5HIEf8MScbUlGunLYDXr/uOKs9W9v5/62/gnW3DAJ0E+wfc+ Y9QxZ/jFGKTT0DGadNWWUgHZgxsKo6kShg8bL2rksOOngW010Xo5un0kCqzP 1UKukQbnJ+AWbX4WK/+XrjEqPL4YuYJ9754HaLBCtdijdeH3DyaTASh7MvYa iJQwPA5Rrsdg84KHty5bcDQ7KypqjEYR6gCKkePWsJ5zNJHyAY7BnI+5TbYz ZfA3ElHrU8jub0HXWnZF2/Er/7I09x21LRHufESEZcwLxXXu8xyIaTSilIp7 UEAM0qaBGxy/Ja0ZkPGapdlz9ttnB4l636rq0bqoW5LafIOcxEjWvBNsjL4J FKSPC9g/85F4pwkztbP9oJWqb6F6+640RYNPWa+NHNEFrnRQmir8pnyV1vH2 TqnLv/WSqR9WwO3ejgMirFPQtQR/ZjTGR7u25qIYP5X03ENjvdSUk8GLzsR6 BSnZH9XwJ35eOroslwZXGIDHmFDCaGL1+AGQjtPfYRn2EmZ41NlmwUL81EKD v+cRghoDtzMk+0gquZICRxluCaXVrrZ+XIBhGN0msenzljmYilfzRSrFzG6y 03rSrTlGTJ+ztDSevIdXyok+Zb135P2vpPV70Rh7ThTdWGOoFmkPECDO2cBb rROM0XUPLuF7cbG/ZxAMzEt+SdzZh/Cs14G6LKjiZDBsu2JPpSSN+S/wBndi qOWvkWV0OGdPPnFUhMQOD2H0hKlN38bFqhGlJT50bbqWyNNAH14ua8D5/mVw dz2GlK3NN75wI1GWcOFiVjw+7bbxGLYn4DHofUpJ3UmfZ4I1ChlbRXB/HA0x p/OXmrcWBH0NaP8qp1p7DDfJ94J4mPUW6rao31sWSeB7EiGbfmQ+Y6ANtAWY lXeFSq4CAYCLzLHyGmcAD4j77k79g7jxo4412D3jICVWgGLwlKPMCI5lHHxq 4pa37CeEm12dtjUuohZy2F9g+O4HOokMX7AR0usYbWIOBNieGODFmkKf4qIG +t2ft12Ol872hArqON4Y1ld4wVf9F8e6ZZgtznqu0TgRQCKR8XphNEHsw/O2 uZ3wvRHgw1bAdiwdt+fAMA/Kh7CjZ6Md5KIE7p0wq9lbCtC78PFcUDjoo4Yh WWvEsqSce5ftq+Npy0+lv1PWwQiWIQOz+dJZYrnP7H+vM/KMbLxIUDvoBLVP SgEt8oZ4xR/aVDFzWe0Bm4Q71stwQ7GR7qGpQIkKRVBePhhfHjtejQ+haCfQ DVRzDEQShIjEX6Ph6cZoVbbZk+nNPDyEqTTCRaD7P8zPa1Pcn1Ytv1So4Skl lDSdqrweK0v/9cc1O05Z2q/vBPRxa8/N4R1QbRclNU5HwbtBtEKuDVFN0oaA VrHdieK9W8L+BbPNM3G78vhfS4Wq6eGVnO3RHF+NsfS/FgO8NelONHXDA5n4 7VsviNc0bzP0N+5hNrk4Mr0i+Oij4v2wGBT9fHJJP6KQOD+0tVTb7rOHA16C p9Yocmha7KtB5Zx7eTXMthVQMvHw/i9OTpaJ3DS/fS5d9OQyksWtyuuoDC+e Ej40lV4TYw/6JkJQiHx3EKQ5bqmWaDBmFVfQd1a1Gnk0mex+jgpdx/o3EdON XMGCyeeje/FNRohSOL1LAIYwPq+yrtVvEvR39Ct93M/tl72ZIvVHhPwzbBZg NGz00adBvMTOg8fpN0AL90MN6Lim00EsHC7JHgIBrz4+qWSCz/oBjKbw13pk uTbXDgMfHX9S0b+7bBb7hGNYlpNx4gcNmNx0tsbXllkG09wWbKVSY3EKhFFy SMzawtnXsJL4Rrgydum54pEJ+yM9BMk4+H+jGFg45P5Oa0tGzlhlCyER29tF OAJ6jM50dn3vp2Wwy3GVhGwaMt6AksAqh1f2cZ9RvwZ/RVEqZ6VpzTFhXjwb SNJPk63gDIMTvwtqFZHQWHXrhw0IIKeCptsTsoZw5mIXDYeQsyzJ+QJ8cXPP fS68jCPRKZ8bakQCec2CVP3rM7g8LPWotkl9vMCzodJRsTq9qA859M/VMTyB CS7TIGJGTzr+2abkGyZ3TTzE9OjhfeF24PX+pLJDkblz7Q5SZ1JKae0TGBBa Z3Z+sEBi8vD3/e+MroSJfW7geJGPojyYlUDMToJR52BMlQ2fN4ni0FkfqBC9 s10xmwRd0lZHG+lWSG6mGL/XIbBEVh01K26uaQQN5+c5GaXLrvyE4ugtOS5n mDIZ1xpMw6fW/f1OPkjYg9/9pys01wSoYw3xBq8CSKHWj8H5GcR7h5BlEjSF EwByl9I6ekzuCcBSk82Gds2uwJzafAdKLT/K50YGJ79H8Cq2WULGUEzVkxkO bPCO4VUGOY67NfUVP8XfTMHjQPKOJYbkZbvqz7ptIyMsZZr20yl33tOSLK/J znwn+QDvbf+qnKGcogaUi16VSAHEkRk/+o+Hdf7MgqEA76dARHSZ30B47QLB R9fMXZb3fvxeIck/6O9LvYWqNNoNtM+s8M4zHocxvoOgHPYoJIYeXA8GZ2w3 1Xu+Jv+0bFJVVI8gpMRFOE9DIhrNr9Qg3+G03uKpbgJj7NT6xwNZZhdmPj9d TaP0SDZbaVRm9WbuQJ6taPUrWiKZNNG0ZUzKxqmRJ9nzJFEVnK0k5GMHoPvi BBNncP0NQrQMpPMz8wJhnlnaV+8A0Hw57shYeloXw8g92ZVPqkNKCb0e/Eep 6j2EhMfikq4OBawfb/Ve4fwu+jQrqf/CfK9RxlZn2Z+zRFFKKUiYxYMMys1X lxk6NQB+8ViXc9AUb12GDFEVp34Dlju+G9bkMEmHzEXocnrN/+3467wqu58X Qx6Txm/duCCmYBIi58MnzVjGeeurHAQ6Ml4fQYcEoleU9SRUB3i/Uedrz691 TA8Nl/K5O27fX97INgNd6y8UUvwicpGRd98PLSum8dO1EgJAhKp/0xXbDK0G s/nSlYTA6C35Haue6OXBxSfvP+4zLC8Bx+1PywbfNKxxTVCXz/SrGrzfrPs2 JevvJYsE45CacdQh+byydFe20rfQoss7/1TBrlTjybO1oi6zcCD2ZVwxKgdF Rbw6aU9MWgiWXRVntw34dlA6ZfqNvi/Pzktu94EEgjynm4rITljPTvLdAFHW O75X4St1AvPARq/3yKgcLH3w8Ir4zirz9JuJLTjQyt3ppEJijxuU6rQKIjqz PT0eItJclySqBgGJze3ClanEENWdc/l9kDeSPzOeH/hfI0paNJLWxJrlmKcq nQZN1WV4b/sLE66H8bx431CrSF+CSj7i3/7/MoX3YbdvTaO5BguTPhHGxqiA VivxzzXb3b6WS3QSgth788GO3g6RbtkdJFn/+Lg0E3SDezRPohw9rHjE3NHO KZNwlFbLZ4XdLeuIdzZrRddi5+m9qgRngvN7QQEufDFmXHq/nbM74Ox7qfh2 TWYkTGqsGBPiZtUyjsvdveYU/mKAcWmAOPQdBx/k7tGeY8VyJte4/rQ1QqET 1JwRKaqV8X7GT7B4Ccq6rG8P1qIVi/oymzlPOZLYojPNjrvtsaPZ6D2ggHqx 7ah4foViYokUkDb0YxxyX4CJf7yWZRBe00ZgBI1eO7sjjM/1kHXLMuc/Ef0X dwE+jgm7v5FsjOt/MTjlqHHtxlcHfT63Scg86kaDFaLifeHM9HccUB0XuAIN T6CXusB2XJMtfjC0opn+9mjosNEPnB7KOuQvD/tZc7gewtHjpz9H7dB7bstI qkoOuQrpqnFu0ExRe6toNOuZ9UsVTwUHfj3+YVv4YIq/j+BwiK3W9bdAGnIW 52po436gtZR8lTFMgeMDPztBU6+1Vf4xaCB4r1YMZ6OHBcWpJSiyVP422dIF ZrW7SxyNWE5/IwYuuPJ4/GfG7yBoFyZVJOAwLWoGuWPx9YWjDXErYhRxBkFP o9MJQAcExzcC+PapDKAozFR0eywa3orlGmfMz8LgYeNpGEAXwzV/BqpoM5RF crYOJ64aOx66kmBj87YVu/B+BVBJhp759BdIUYzmkL5Bq/ZYljHRCV3D1gM6 Fmew3b/vpZo1ObsHW87oh/HGrsky3+yep8Sc9Skm9UOli6NMuZF7zwEtPqMn akghX7USGvBhW1aPyWL5vfHg1EtFM/gD8cFbejqkc7DhzIIavvEI2k/MQye0 yQVKt/bq2M93rw5n5foObLOdvSFYrtBv71mXk7UuuRj9feUjVH1+fK9CKIXu 3Ed1j6L8aLxUGZjNSNkzk90hL/eRWhwyH1kp5VHDKRoQXEy70u/8dfuAofmd op4nfFtV8CY8BfIVo3Xt/U14ElWSmXkIJlgFDdnf7UlGKeOm3AmawsM7n0C0 ILn/MFl4ThaKTOXhEUWfTmERhSnoRXNvBKIxhM2u60WPDSWQSXlF9dKf1UxF Oxh91H+hUBEt7hRkdrgEDENpvI/IbI4OcR81Uc+wfegljfLwJsxYnDYjI+dE PH8C+/MM4Si68CKDI/Hip/Rzdf+wqeVSMWjcRCQK272LZOUmWait6ojAN4Uj t7FEz3zwKqKrgjeZU7guEwEyCzg9SDOsiga7G4mva4E1c4XDEbZz8hcto+TU ZFgmy7r+seKB0hqYeklqGHqs0EYJGKi/0vHP/FATZKWJbs1wI5B8qnOzF0sf /OaSZke3zZMPhQ+jYUKNRR6QNoyPKJBpjg3Cgyqy5P87ZOQ93H01Mqay7RJZ JGMjYSxFD7aS+zWfwE6iGiRpfxUgaT7KVKRbZG73rlZH0doNdB1PobY4rud9 Dq9k0WzW7YicVavwDVHgoY64Bx12eL+vTaP+Lk4Spvd0rLfOGBMTT/9IRI/Q KTPY0zjnsf8oHsGWqOtDy/EEm0PzV6kKqtwVipLjaNEH/+9regx+05+fOs1E B0zdfEFrjL1BFLcQseBjUmWGGj+3i/zOa7kSWm/XfRxPQF9vgMeuk57IxvD0 Ivk/4XlT5mqgdgI6czeG5SNHmBnijGI0u2aEQXRrCe+Lobj8Uc8ORXaYjtXT shQ2HkJrcoG3ZdypuzvCCEUlr4rawpxEIx35tQv0ejezyyFadDrzYd5iXjLI v5PFTuqScCHFDXN5KIk/SekriCbYjPVFcTX2QNniGTPsga4oS29jToBhpTcj t3sCoKAZUQtsYRbwQGydXm3CRPdYDV1YpwVaKR0HZvWd2r6dR8GdO0Z2QycZ dkIU3uI937upIDv9HTbTzDs/9zF2vB1ro4oWL9uYGXKD+fh9f/u3L/mG8ij9 VyxRve5rRX+/SA7pcrxYZ1trghD80oyLyrU4hniCTalbqDuf+p+E2PQz9XAq SNFZIYW+XgT9Kp9icZg8uYZqGinwHEOMEzB2BZ2uL0guS77tw9m82gOMFLbD w2dCZF+O1iHazxPjz9lenxs0nIBfgyomja/mxQs6O0qTY6oaZ0bRy7RJSaiI ASJTmV3nyWPKo/6hcYa78hSaRiICeKI3w5fFY8yrBFNhBk7wfcWgUOnpCltw 0GbbwfISa7egdu6/jxOxsOnASQn16sL1i1myE7N/AJ/KiFHguvhSGW3+XBPn y6JjOZUgevbXJXlBDQgZNKwnmroFNiPVLl78M29w8CrKdSgqzFr2eIGh/0jV ci4W9Bppu/M+yqse2FaSyeplrrRD628izwLazebJYNFVoVFk+eYx5X41CpUN 302BBLpQurXcgfUdtxJMFbgGYwt/hG+Pmrqlyp/yVpwL2FhCi74rwU8VQdVM X5O62aJNBEmLHwvpFuxOe5hp7iOX/B4KqgPtvccZR9t5Ygoh9rbyR4PLQz+u P9Bgod85zwZJD6FyhF7oIzCrufmCIPcfOyJxctQzJC33dSGaFDM54ZUoWvRt fXtDp9sRFZyL4yT6t11D/8lle+rKVOw5lD4chGbs+QqeDFIRLOP0GlzLbM2m RuLN+E/4Me8p6RjsQ0tfMa+kL6DcIvlSARdsik9XFru9j6/OfAOM4sTGTWpu gExSGvK5Yy11AM/fwvL4zFn850tNW13CP1XIFVr89j8x4Ro7Fdi4k2aB4H2g T7q2L34FomiJ2ep5EjB8cC7W43m8Isg9FbP0lzHv42QQFJWhd0eTF69VPUNi /NrsyB3ujEljGS66Az/Yv0oX80sIDwYSnfsNaC9WikJZKzuAdqskEX2iuxTf vXE7fkhvFRK4FaNjzMgsTnVDGEuaZzUN+jhWtU+Lx/BCHvpK2KdihwfhJkMC U/X95ySCrz2B2hIwOk4qmV69zAbw7D8Y9xGndfyDjkpll2zdDISGIzBY0/pG 7Umy3ItuPoTZmLrQ9qDHBvpiI9E2p3zAO7K20pcdSKewLndiN87EIVYTukCi cun7T/K7pgvS4lAiKHtlzrygN7vmy1a5zU9KVPEMTL+6KaYw/g9XIbnVojfS k01wjJZy7sVPUc1HlrPI2DYyCbiAR8xNTpiZiqcFD8WrVGjTfVJfJSFPdBUY MT0+YNB5ME/PyNH+0dfe7xCzbL38QWppSICOmWR98OReZF1+D+7djUufgkG5 rAzdArfNM195YgUrrsIqOZVc+Nr2wqGPAow63jMk1JjGq4dtAIucJbP7VVEg GOtXFLz+yqatK3NyOiN1Lk9NfSXXT5P5waFCiuZJcMDazGE0ltcKOy6UUEME Lo6ljnw0xucjcKnznmmEuNnDrOigXJKWuuNq8bmmvmiHV58c/UVpWujgH2oU rtm3h374UOnNwlm5y9gM9cY+gOVGl5Mk42I8cylzAYnE8yMSp/IbsJwxSlcH HGFiTLgjEWBMAEoSTcwj9xNxzPhgrYrFBgPdeeO0uYI0axDPf0u56ZnqgYku Pc2E6a1gEfWrcB2LpUgIYP7Zj1+3o2Uwm4eCr+Voh7oiyxQdU3X0jch5YMSr raV6WcRdEcT/84sD4ZSJT69AZO2sYp/OjuNxKJ4D/umw9fQc0XglC+x2pJFW K0V0pT73BW4T3TfG/9xeZjgu6+zU+SyCb2T2YlND1RiKOFvDcLPatBq9f8v/ SLGmBsjCLMQPEDF6LWm3zkHm6+5zE5LhzIHvsldRS3u6kcVeJX7w16HyfKgd Yt8VxzeH6P3/a8P+Z64+1wfVt5JYgV03+PqU45EATtHQwBbMg1cAo4r/WQsk uWgd66bs0WZ6W4Kl/o0vRqNSZ6R54qZXjp34+bHbBHbybYFDmjhDeG65wBET 8iXRj9ftwSsdz12jz0TBDr+PsYUp9f065lWElSKK4XTjjPh+/mChRSDRWf5j dQw16u2PtC4UMVT5cf0W3psQsK6hj/1sQ8MSdFywSDvJlR+kv09aK+kBFGkO YENrM/y5fVcm3yqXtBrw1zROrLs+kPdhnKf4TxSXQTFk69+j4Em0J/ar1dXX CLc4HF6kOnAYRBk7WyeEHdq2UQpFihNpm/D5Hu5QgYTFMbPvIcQHyoqc/cDN eqAllxyZEFb99SZr+0RDbPD43uSFxjOEHyUCubIF3nGbuw+6zviRucJ3USic Pjz5ZNqlkzzgSbr0vVAmUa7GRKSvo8CcE6zgXX2Gdyc7b0DSoKZuzUvkswNk 7syRyavyIOfqwP4yV9Q3sDyuEA8bnb26S+XwNfeTU9RHl6CDPLSXYIfbZPgU CXNIH18vsqxPmOOita3oqILEjszXAffbTIcG7coQLxLoUlSnQN4W/1sE9Hx0 M9B7Wo5nKqb8fkMinHyVS46Q5BvPvu1O6uhfVz9CAmru+HUYnvykhEI0078K bGosNjEqWr2lWHPxy7NFs6QMVQaXzMKWYysIRfT+l1s6P9kOQuhr95YNxxrK CpVXVmAtV4E/7U8vr07vGGzJp5wyyzsomYMHngM3Ko5vnEMLeSk8Cwzd9uXj D6nm/Gk9UFeMJfx0FwIHmXY8tV6ByiF4n4zLy9tlwBpMRUAZhB0zdyKUPFDq DP1WOi1n24fanWDjbeIXqh+ZkgjMEt7qCEQ4Vxs29mJRkE85Fm2Qud/0xrpI u02zsauPZ4eHuEzJC9QuA6loxU7z66cpWVxrWBZPE1fzHoLBZsaqPz1f/M41 zTaw+5KcwH7H5MvJJyzvi6LRer5k1oxZTMMN+WVCg5eedXCKna5cUqab26xz Xg95X8bFNEQ5Sz+5twYctYDNeA0PYBeivF+9/cGExcRd2CPJpw6xNxwn2shD aL2vP3Y+YeWyFxDgIkcLC6Cm99QDqkaJJ1DLsZ3FKEv218/vZEfHUKQYAx81 8Yn/Wcz1X9yMDQ4WsHA93iQDtS9QaiqvrfVKAQUKdYLDP+mkFSjS7pQ+cZlh 1Loc5rOTGaWLYiC+mk/4zb0rxon2EZXE+Zg1qNkpOr3Q5DH8wlBnJ37w6fYc yIyx7pvfctK++iMUVOy48iJk3HX1SYOWfc7B3fI/NHE6k9tT7Eav5wy9Zxfj 9YFcy6Q5Z9R9vCWii2kne550lgl/krvwi38tA1fWayKEgKXvmWfvEd6PEJ3J 97f4opPdzRAE+SLS2s04g1oXnwKGgPZ5ZGAP5Ddwjn0p2MSslXjbH3ere0b1 UnvsnF190KW1NrjCds6AATKsY08ncvMypox9ubYhBrHFi0Q66tj/ThAdXEzr ZD6xSG6PG/CM/BnnmbP0IAjY9sE4h+GdJmUkPOgx24krUHLN1MBCJM7t1y/I Xe3isJg/WqPxgje+emEkboaK1/tGTgda2NhzgyP5bBexk5MlLfj3lG89MHcy cUSRVE80A1gNQVvlhtSh8u9Bx8+VcMM9KYOkw/kfvEwCAHsijGFpIS/Jnj2h mGfWwP1itPs4tcyUft4xurH8GQjWQpQeZ98Ut0wT3q4/x2Lo72Fv18h8nAUW 0yTNRtbyge0f8bTg+s/hHvE2Ssw0NZ7/YuftFOcUBHbvMJ/Vjjr+CCIHP/1E ncG83YHRFZgAgbrNtWU2VJwFBwBE0zgCzgkxJwBYnAEshhRDQANtm+iKJspv hNGO/IMPTfXl6+59x6X+O2h/j9jPSTnJR6plB6KvW7FbgfWJAlZLOn7PhOuI VdtjM6s89YfFdRxd8iv3S9MQL9/mySnpbALwvMeRL7cW6rYbMyty1V8qswkW kjfRnUiSnnm9y3iR7wfWllu5+fl/2lD4B+Ifx+HmP3luw1PXCTC3X2WyKUZD 05p4M9EM/XVOwhd9ssV5WEpTgCdaN0L3GP70APZQtMl1I58Xu8rcAZ3qOQy/ gegKvDExvmkzjkDuY1h9H2c5pqIWcXpORmgGOV2FPKpwJInn+Z74EsrE8n5h dDRsdeT97uFOa4nT8Z13Y8UVbI+zKA1UkCmNC0otuvaiOd9gnrOfzWcBl1z9 WdQ7V+M8fm3BFWqxYgyVcxX7nlGoVQv3ck6/YQjxaw/Ezei5sdQ7y2HXiWtA SU/ZWhGdTYdzjbdRcrPdBRPfflLHrMM4MW5nXZlItD9o+t3pL64IX12QdGaw BbNF9eFZR2Ef1P1ALRUKOavMRF4FJ/viPmu1PLl51Jch6NP/2CtszKQfzfA0 LAMsCsnUz8cenE71h023InrqAJ9O6WkPb/3t9GQMR2ZPgVf1eRd00z/pBg6l ZPG27zf61VKrHK0eB9tllgwxyOLNqBHS6UfLYx35MTKB1euMcx+21sAStafY v3tVJIAnV/1wz8jgQIHdXtpTxslP+0to32Uf16SyUZzdnt8MareX2BYc5bcE dkWKoPfQTZT5r92+xmu7zMBMYn/WjvwLzrbtGgxfbTjQYQIXc/WImudbQU8p pcarjzgjSefiHsQzrbcd7KF32VW7ZmbSVULrPalnlEZjlWHWH9F0Y6CnyhN0 mfv81incOlJM7hIDauMMB54yuVggmLUx5E4lRaJHskdcUXDlZ9D1T78sTQTg sFvp91rS2Wmo8FwJrCWNsX36a98OV77yurXouswafWjRTx4if/CB82nZpHRa 3DJ/Wuml4bDofkkzRND3ORY2RNPI9n7me7Eun7GSi/nMnDY8gMfcLnWa6WYU wVyA61Pe/VTJyTAX8037pqXdwtB056ak9Om4jEEpUtovFa+sXlk8s3IjvRo5 8s7T7UUAuWmsHMVlMSLuZX4IdlO3slGDWOOF0jQ9q42x2phtUARCE9p7uEl8 wMHs93GLSh+cAX2/qyhAN2lcO8ZlnBY8OJ/GjrzmnR+O+lfz7mdZbLGHSLoU PLjRuXa+Hd9odvU2vWwED69kS/pLeMM2Th4qGIJnbc9xZfcFHeD4PD8clNMv VjcQJi7mdv2EvcvgFQV377hwM5YKD8qbyncbd/HUYdHNIgtBjOBZsGjSv6s+ VPcuGShWPl4YvT48r0GGlonY1IT7vM8S8BHQ9gsVeZgT4LcpdW/DSphmDAv+ +R+BE8HoQKBsppD++xGAxejRG95txK4EviJHfg21WUA/6abioOdrE3+6G2LQ X1zunEhoAz/ZNQpFF1y78GHKz4CmCWXamYw7tvLL6V1o+nBhl7sWdlk6pgUY 1zz8hzZFEIzW3yuKmHfO/gXldFcU5t9sF44bEt3jg+sQ7EGeGRfcjEx2nQuO zFWikvZ9iJ+6W6FMiozzl0fqGHOefqkZkbLoLHBqX6gfxXC60hOhVzuF91lI 7MZQR4T+mnDOt1RvUwAiChNWyvY8m8DtFJ/POuxx0YQHqODRnTFDBYnTIMe6 tBkMVX2fyjmCSSfsYXbev+L7SB97W7Y4PQVNgzYY+eRwk1U96p4bvIR17iru tU+E1EL+HSDk7wisq3hhzx6tnjC7EbGiSQdJRlXu9kb20ShsAOjYtZu+zwE8 GDzDn9bT0rYYX8RvaMErmu4EysLfWmCVrOQhJ2ry/d3EKNzDR2IhSGi+X4SW ut0be1hS3/HBH85D48HAhyKkAL1So7mgSGRi02W7Te6WeZh/7GDkK6oXdTbl n1yFoWT4OXPyiJ2LXIK5EJWp3mMy97/jURuHYSZGqaor8oITj2Vj9esuewGf jL3bOps/QwmMjBsDfsmzroogbHMypazlOc9AX/mHwL3xncMHRNopbfInma5m xYrSl9y0SkNjKA2nSZlvuS372ZDflKDJXWFyHo9b+pfwYR2fsYzvJLgcZawX uV/sHpv5YtQBh83vK2AiBbIdHuUBPfQQMrfgpTRmbn5HZFHKCmvGL0mrVZIc xmyweraGIc3znZv/0aZq3DG1P1DOzc43lsVa7xoBOGld1LyWUvOoQVGh8iPN Irnf20YHVj9FOdz6KWAfVlHFeKOKYkRrvkboj+Bd8JB10NkHRjpEQvEnnSdw TY4odLX8pPpsujXNgss3kaIS9CjO0n2QCE8dAJuu9vBlpx+6i/goopD2eek5 WjnjojyeoQS1Vuneqd/HDN+8F9Biu68ZHx6pXYMbAE1tfuTtSIR7oJT3C6yS 8a/m+Ef/0VCa2PnroGZnyQPy6Hk5i9/fsRNqpGNqVKSW6xbZIRXPnUP9J61y h74HIWcyvVWhjgu3dKZBt86fb0G4+dub9DAxw2u3iSH+vvfl3Fp+l76e1g5N xHhaanQ6lHGT4xbX+uuWFZFEShkPmCHZiK8kgA/enIv2MbPv9M9wFXj3orRP 3BACXtvJVEXNe6AQ0/KvqazetcbaStOTM7Ek7o3m65zVk3TD3EOzvvPzQDwT 5dKyJJp8iDs10x78GnrlhEI5VRjayveFtzFkQJoK1CuxKgV06nXF2PXh8k9d K1podu0fylpCW8fylSuuXpICK1ctkvmBp6WtU7AyG8XA29m5qtw2P1QQpZT0 ZGEZEaaxVhJY9mNlytC74HN9yRMmk+WK/4uBqYzioWW4PNKYdOh4Nh6lI9LE qnQfiSMqDHmfFpsIvqKQ4umm2fqbU/g0numye6lXlAxMWC/h0O18XSe1mCa+ c5iun2De79Lp0SqiXQH5BQ4vLxyrRluQW3x0V/KgdjECkGeooZ+Ka24K1De1 0gnp9kbwE6TldgOr5iMwkNx1NQN1p2U6P6M1QZtXC633xRcpGL0Hu4AQPX6v 2w+lKbYaOlzUSzYO/8Q1e6UVi97NYyljveoXbTDM+L8NNmmBcP9YCGzSPXxr 1E2luP+O2u+SDnMnAiaN+Fw4hVZxWjsGlSb9ZqAi7Wv3CWnbH8W3RqXijca6 7NrNgIN1VmRCRcRwIeZTLbOnT2EjH5r4Ok1srsIo+dKNUuafsyC+qByeMz3v VQffqpyljxCAqimL07ZP+SXTwt5TEKnce8qH9uwf2zDxZHYWhFJHN2Dec4kZ fM5Dw9UVawuDdN0t+IMR5afJ7OvDFAptVWSta6c0b3EYK6c67fNwS7ORXk8I VKVtgvvCU8B6S+i75fy9DYDipV7J6c8tEEnF9fF8L/lNgSg1V74QaMt1vxpY /e7gCkJYSb7jyXgeNCZUb/VkG8FRATuphSSl+Qn4G7/TG74ZAKZ6su7pHTq1 nmqqjLPhhxUAykoiTIxKgRN6OXJV/wRdhk15bTA49BmOs9V7jCBXgYZgjTTF T2x8k+NC0YaCD99fv64N8AkrVHW8acYyAR3bV2aIwZewEOWmbRe0+83krJLr /gir/srcIN/V+BWsrKn+GINiN68KiEcOuhb+3sSfQVxmlBT4HXRaRJ7tZRQF 096GXqNGe4C4YlbY4b7IrBt6SBsgdTW9NvOTN3XBYo1c3tstppz3d9gsNbrN aLQlgSpgQFaSTIlKqvueHjsPJD8X39gMyQIyvUUnPaZaL1xGQQ6//X8sJGq7 RAbgCSS41i6wr1ssVdv+AH8WfGSvvcurwiyqsiDqiSerx6e5YDIaP+bVR3e7 /bDWQRoXsEx02rxgTA44+2IKujyksFAk8nBqI9aJ5078zk7QbnHic2sWge/j 0nE3UKX6GJi/dwNP58bai1IJKJf7LQfJyOj03iGGfQwR8htYUIbX7Wa5YTtA iRJkS9NOQKw5fEoMSM1l7NECXYV+0+wyNSnJ6t0WtGvCfkmlJ+iDD9DZ7hW7 PkMHqnbdalJX+NVich/TVd/b/MMLbl6SnISITS7AuYUKiQ1DNoEGJ72pNlKn k0XfIIw+BL0VIuj/kMdSNPCHIFMUT7rJshVWzTWwawmIIXmt3fU6PymrlHW6 aKKJb4l8bd6XquD5urFbD7MN2Rx39dhFr3eykWHpyT29yz6jLaqXYI/yiLjb TelN3UuAKP8OUrehBUyP6uYjoGdG6H/Cn6J7TS3eDk1EuOu9qD5bG+KWvUPn /+xyHDmOvz9Jj3tIRk7x4zucPwMrcXgnHM+UQItgUjFZNXJLkuk8Noy9EVPT fK5/JpYaR44cY1cVO3NeT/Fn1OZw4ZnWSrAjtLlwiS7IIzxP1+QKm1GeAWyx +oHvImE667AKL37mgnrKXBDnqU88R86vWebXIdbn4c4RJnH3KJK627yFohTy K9rfxzzY3c2YCI7cY0IvjgfwGEdaa7YIkTiJVV8xEGq7sDjisDZhAQ45nUEf xksf/Lqfrj1m4r7oZs28KvxxEh/sYuvIsmVz4uqBWxaM6hk0qQi0IiiHg0Rv cmsp2KVlOk/yUNdtDnAU3gMNtitfizgvN0z1oOFIcgTTd3o8oMtox65xkiNW xTAaOqDCYaYKQ8T4TJdlfbHdozKZg89N427qeHLXXbIMP1B/ZLoIB+b2GUD4 d9Sbci+i3kJk5wkWc6cCeBWJjjxYJ76iaQ94t3IrFmtO3db1Z83qTBkthfor fq6IYPmxRZLyRT1qxd8kCFINBhX/yMAsReYrIRMVGRgq+qfE0uip96sf47Ne DYMvEiXLr4W7JBUMstKGJkgvRJH9G8Jv878XzjggOaA9rsf1zecR8/b/AKqY sPx7gDu2SSHk+l1cU9yl6vjI55FcWQVs1MXppb7Pkw5AdaBPQ9czzi7uSPft weNLduVJioUYQPyVVt61pv6K5yBK+PQ7fpwCLzh1XjyWXqmIshMfvJaQ34DG HCL8cMYu0Ml96TPQhtcO/fbDAnFYIXzbbL8tRkwo5U5B2VChb0yk+R73Wb/k rLOyU5NlCJia+EF370lzeV0M/NfouFcD11B72GTzrG0oOYfQ7PmWlr0gpCGJ Id/7UKSpX/h4W/2XMQOLgeEhLfN8vn0/0Jx2Rwk/HN6JdHQD9ZwS4Q9t3KrI k0cyKsFn/xfQjDkgZn3j+BnfMxT4nrJakkdiFIuVE+6uTYuiJXRBE89qVUOY +PX8dQ/T9czjRn6rDvLNi4+1c5XGtnZcnoGJpZbLhxnYa9q9vsBTfczCP8Hj ICRqbLIDHEpepq9eVqg8hPslLh4dDe4V8SmZXsx9M+5KdpKqeA5XZsR3sZGO O4Ybis44Twl9bqtWRptI8b9iI4MC0j0wZnGvgAS28kwc+fYUQXmqf+IjXik8 HzG7qRWioCQetwOfuqerAq+/rBC4BXolqhhOQ4fk1RRx9yy0g6bBLbUoekkq RTgOUzF9vusNPhpVJTAsJFWe125pANmyI0Yprt4oc6l/MDCNKNeQTgduSg0p AzwTkAwoKz/YmnKQ2/zlDptaWJiwRiZJ8AlpSgsrz9wAzzOZ2rlWj3cD2jXF WEQPiYA9iM9Y6dh65MDmby6AyZ/jqBBEzDMfJeaM8GqAEYT7XqNpAoJFpD3p KBj2XULph8L4YyeTKiVc2p44b+XEykLALSG55Bv+6vWw6tdvcTUR1EKE4TMZ ahTGRmAmEuKUKPZK2kxNieWS/o4UegxnwpvbKo8NKdUmSoWHszZRi5M+6ogt qaqkfg3dXlf4dc6suPzvfyEnvJW8742sRR2H2HPDrrhD4MAbO0qUFDG2s2V5 e56w0YB2TyrY9GkIzospFdtr8RogzR67UdWTnBD4X7kETMi8IH3t2XmHf9La Y8ve6KwttmE1YcTkPHRLbrDucEk93+tBxpemPJHrxW8W4+/5F40pzfBs+Tjy B2P6l9BKYzpTcCnB17MyejPZ26MiLOhJGIwqGsWUjkNRHKvWDW/ZFKRQpKZb Xo/178EmlIB5XU2HfMNvE0PnMPv6gqJm4QvSyBWnAXVSRn0+ksQ7/WN+VD+Y gnQS37WUBf7OGYU22rAQ3c8Sjah1J3SJbw2VLguoLvbxjt3dZqrxt8wRWqPE 9dy8oLkt0X2XmO48hZyV/Fc8duO6GLsfbsDgmDkRX4lj9868NQ32Es5VK2o4 IPlGpXJY963Du3n5icDZvyus6oKHsjkFP1RGQBTwnSKMpTNNSIakGWDDpqo9 OVMBQBxWM10FG+6lQEF5qXBxUt1YjDTbU4a4DpFTfZQ0e0JtTy3wZfd3uq1l OfKpUpBR3GTxA2E2WRGGh2di9Hfh5fT1BWtRdvq35K8TmZy49BTPUtApyFcH Dh2N52FUspKwUrl0bUKO6BST8gXNNis/l1kMeAkMkT1dD5Rk4+woVKiwZDyx Ztt/DZFZb4nV9mAL8fmIvKlsep2/JyoznMmYSzOk7ljRZrzWzX5z6CMZtA/Y 1YH3sxLM8DI2SnXy/qi/9nwJk87uRyIJQh+AvJ1U4QvASOKx/AUuEapJm8Q9 sODkVfsZQpi9+gxfDdN6XYYf+LEpb0uaNhDggR2NOJkmGfeiud3a4SZow8na 8b9nsXiNmSdDT539y1mqLkwBeFz2gtPl8ZFaFuXIBfn33KVBEH2COdSbEyqm 86Zj/cVjQ0vcfWS/6j8vNI5Amh0HlrYvrJHyQIEdGkifxc/A6xnZNCQ3VqAW V/qT2aaBei6Dnx71ROodUeEeSJMe/5wmS9sfD6cTVQGX3XpB0TuOGsVr4AIz yteux6q4BSzfKxCaS+QHPw2hILZq32xvVY/H82Cp/6sb9ePvtyHVf+iYt4fK g8Sx2fAReGfXM0YRd7zqkSA634v4TK6+dRVbDD8ebmhXY8coJ7+H7rwexRtl 14nZMn9BSKChCLP7P7kMIuD7PSry2a5cDjgT4Pd8GvJ0bQFZ57jGwin7jwKE NDvTvpeA6Di8ikQfRP/NMBqf3WPudK3dx3A1Wd6+Azz5xTYCmasP/PzjTLnH B/CVM6aWnaTi4OiibyyWhJG6ji/LL2eckIHNsGL/cvj+j7/2TgZI2BQnyp+J AFA41UxW9qF9I7ItGbyG0Mkirk5UN8PWvViH09HLaRBRS++G2tyRynXiCTMf Xk+ZzTRAIyL4EKvax3jBHhdHXSBvESCO6dpiuKU4fXu0oUvfs8R9syFLn1dP SVPG4L5qmpIx7OjG1l1nP2En09ypET123r7/5wjoyNzprRUSMPi+4qF6bv1s QvmfTcQAHe09zmmB/DsOo6KFaN05dRXB8Bzi9eUwVVG/yAbzfQE/Arbu+Jiv P8vUxUUgXrTs8VoVz26Hf1KmrVCE/f8cq8WnbAwONmyj5l+iKBJf3EZ9VW3l QwUsoKpI8TTZ56obbX0owdlE+KEybPN7gj6Txxl9YIurqCQ/IUbnaf+a7jVd FxlLKuQ2PJo9XLUyq1A5hfq0SmohmYZpI57v0yOzzRJ/7eTMStHAQek6B45s vX8QcbpMdbX/lV8Q3dKmFaNyKzgQYCk2yo1UATzBnhd9fSlwr+NqQmmsXmRV /bYvWgiFEUFfS+PDhSBLVdQ2DDOzc0nn34fgCyh+pAp/oZZia1vKDPz4ty1d h326YVHxJNO/KeUYE1jCJYL4rxjDz22qv0APWDo8kBMim4hhfDK0ozE67eVc uRC5URZeydXZmVp78hLN8zDGQKC9jubMBgRiZ2U2eKpENX640scF53UioFFr WP75SGTfKFdI4Og7HxGUQb4XhlTHWf8b0Va6K+jSeXFeS77oWXgWEM36f2vX 5SD0qpOJw/brq3/OTXLd9Hn5iMCd9yO9xJh52SRYlOK/EMxpcerRvP2EglMs C7zlb8Ag0Ka76kUU3mDIH2SqTzr5u4qH/D96OdCbMfR6clZhqN5m0sKBXxQe 1l8g2UkJ3KA1gimgfaTMxzEi26kYV1iUfug/IG8tJAvfGbKC2YJIQI7hV3Vt kU4aEWiGPaLvP4M9JfDQRB2phqVsztrMAHXwqNzet76E6V2J0yFvYYiN9/TX 7Q8kFX6mKAYvZu7n/zK8fY1TENpVytYV+qTWCmGQQTGcXEQdJ/zAt4t2qM4y /2Qc0SNooZnY6skcb3m02V3Z9udvCJe0ul8mF6qNir0Qt6qk4rOz9wTd/NM8 q7T4kPtyUyJFX1RPgOlXzY+L6mAoSge1sc/wQT0P24IV58dRy8F0I3HYVwTh y3SKkmwvEBQ0rWJwXKjrAMIPJ7782tkbPIw0Z5OwFf6Yy6Coi/ZuIF717iTE j4ymn4NAPdXuhvV9DppbJY5YHTjhXXFNNfREGtdB/gqOGjN8K9PSty8hpvG0 nC2db/7qfwHRVUHL3cifLTrS416092tu+C3z+kqMhG2NH9y4Jp5cLFEGBguI +pPm7nCw20upV1voKnuC06vhYbuS8DkGHkYRgkSKNgwPH0Op2n4DYyK2HEdQ l38mqnAe9xwHC7KsFtUI7bB5ewTzld2m01BGUVaTWREN2/76ZCp0imuqiA4l MQwryvvzgZnmEH+ac1f/eWOjQ82TfBpkA9cFSmvJMX3//U7SAhEqXr2h7DYh nOFn+WmI3tkuln8+8OUSDQOG6D9cidUf5CGyOJFfbDtHxJncf0rWX61CjmJC E9aNaMtpZq5t9OfRL3+lXV8QVpXgug9FU1PnpiSJFL2uwCZMt7SwQaNVbaZK 2RNoG63L6XWtFGkUWHZM5Ssv6Fonp5KcNidBWvoFDwfWRIAmi063oGWb9xCr t2VGAuE52eu/OiZXdMCtLWYcjPbLsIL+uY+I5I6f4hv9XvC9R8ZPdAJQpa4V 9Vau+OjZx+cRebFB2l2U0no1eYYQeM8tHwkzx4iu0A02YgsxmSaPAi1+5NVb AbJHlZ+Vx3vLfoO+DDuPrlCdRr8+vWBFKWL8/YVoXCC6Y4ea7z7UnmFfuqqY 3GBsJXdghZWHIHeP5+4xshpW4smgEQ9fxeXOY+uVSCWE1aCTaeFEVPfnyTj0 orK9XeZbVh9uR/bZloOGneiP4woi+0IbR5UNuzfH+n/VSxHOe2Y7q3ylCBni 7nAjfVwB6ch4qMXXClRR1BU6Q14COp++ZDhLyDJ7mPRs4giHfXxlv1Kz+ez+ EhA6yLDhlcbztxFH0Bb5Rjx0WWQzA3hqd8+6+9e6F6S7swFWHSICO8d+4e9b qo4THtQGWFP0Y6bw91XuYG+/fNHNMkR1PIrk73SjKw3z+ZNx/2C+KZfSS5DB ygbotUW2RqO6oN9350kachXCClzL6YwcdPytxM2IVIfKsbxKNc1jxjB+kWkb 3vGwHkZGgmwiBIK9t3UnRIAPW9DxF6Vx04k0MHOXcp8kYn19ki7TWWd0hwBn sVKVXqQurG+keax9wmDQWx5qb+ZJX4htPxzH1KaLxuL1hrzVX90E91vc8SaI UjgQJtztGUPraBrwc6MZ7puuqmcFAc/fYu8S2VQa/rKc3uGLo8Egu41nIKix s7xnEeGgg7TmaZm6E2WDZN7E5J3tsslFrX6APGt5U8hXyKq59igCGJK6Y8aQ BwZ6m242S4xkHFL70hRA/0eamWnsV7wSIdo35qjTvSsfLgQPaFbsdm6lwaPe RrWA0vVJvzi99wDBQgWCs9fW3A72aNPbZ29XkDGdyjM5uHBzEg3j3xI9yhVx hjVrcF/5Yrz5RJWE+8DAx+RkSzC8odVAIuipNwgY7s011kZRGQgU2XVReQtY f42AvoXoepD/Klfme913YJg1Y3yhWAL2FKuafqJkRAYgZNvGneO5L1oFgnec 8vOekfERJlmROw30Qt694RXp/VQenevHdlutQT+qmQ2b0l/1hcLPdrMRH5Jl R6NESOTKoNnwW4at5uvC3toWO/D5zGDS6g8xKwb2SeVHmsDvj7gnMfA6fz6m o0easFBssEAoxKWWWKVL5hQRvlZnvoHLHXLmqwINH/UbCmuy5aZVcQkU90WR vRVryHsg1/p1h2C0U12PYOFkf874cy58L2WIIG1XzWUiBz/pIfnuJj0nq7Zw aiZl/rjEuA5ov3+qOIcH50P3eQWb01NuiSa1ci6gx/kLXu9kK3cJBVKx39uE 3zuB0hl3AO9YbP3Zif15AluJt+Vq/ewHXlSQ45+wvFWPqRvyIw3oBCmU6UqI jOliuay983Tl94C/G/RGKXJ77hOwQ/yNMx9fMhuXWm+L+b1ClB2fDDJPkvRn B4dUhok/5EW57zDJGVtcnKXOB+P2adoZJ4Iw4HC0onUxwccGHhttrddKcVmx sArASEuw1S9XHQoS0zVflQGevSEivUmddo6WNbIU0KLfn7/PTn9DsCIMCfLl qSgn974hudt9ZYv2Nn7Emjc+a0P5AbZhXYrufUU3Nwikgr1OxM7CUD9K89gn PqDsebaF+WsSzIDhyRPQSI6b+nn2f7e7Gc/H89vzhDSQsHVzcsYrexi7Szrr oKWY8eSHr4E5FVJN91zWytvcQkU7MOxGg99I+7SdUichXZKS/ItErEeQWg5P 2Wbg599PU7U5raMEZdw72Fe9xcqkT5vGsQ4oTmx8YP/B/CYukayUvT9rZi5M wPM2qvlF+vuhnH2ziY64by2uqCPTHufatoye0/ahA12/6zF1BkPQJWCnwTeQ a/p0jnTxGgj2W7Fw18r28qIOAK0SiecPtavIDpc2U/b7x5tBIofYezj6KxMF +/Ku50nq9iBFIy/c7htlmsrLNH6gQiYaTTHJL973KNDGfEk/Squybaw3vCE0 nH4doMCB+C2epRTbPxjBn98jlh9Wy9vXhgfVBu0CjNvNWnigN5rWjrLzJAkU TfAp8vMS1OY8HWF4q3EWjHZGRD35mQus/I4Yl/+oR0G6LmdedVaCkYMnQux6 bLAbfOsYbIwvVoFqJO0iz52b6UVwbgwy629aOWE+Vyukzt9BexkNyYMapMi3 3APWP+N0c5HB+gq43PEgUjorfdKZz0p5/YGIQk+XfoqiKOJ7NV3uTnmlAwBQ GBeIatPw1ApH37e4Uxk/BxHLJrkGVxmMsXCzdQmFErpg6Fosd/9agIttkVMA LeOBHLXEPr+UD1Ue3RIfu+wxy6jOpcZ09CaZgMIKEOZlGrP1a/8u/mdzO1eC 72wfvTLRns5O5F7NjIWpQYq1EJLjOGdhhUP3Akg1231/VHGfTVVQhEyN/ROh zJ1mrP/PqI6XTp2efQUYvMQNLcWmMK3tsxVQKZ2v/+Eda7ivbsTjCCopNAwN Mh+wWkWSJK9zVA1/qneIjjY50qy3XXa4V1+4bZKJK+DQyF0MkV2F+jmbiND8 0X2oM+rKJQLCVwUlYbFRbgVAF3hR4lu/AqkDr2UplOMw+joVnOznuMzyEzft wVZj3bl3gbsLupliTjs+g8wliQ3uP6COEjMnUdYfIM2WzKLhyqhgOjEvndZx N2cDMwbN9OskveWYDxFITh+3Yt78ON7/h7qLqsn7/MQE98bBZ6EHt7TpDkL9 gk3vGdilqDrWlk4Wcj1/swYwfX5Rx7KiD5QHEqRTpvICOPorBp6U+jhjb52Z OvU7z5v7RuwHaiPzwT5aiVaVDmzjWeJ00N0y1AvUBjgRZ/WtoNZYR0OkmKU0 +0QVlQfVygvxXUDmJ2ML9znLPgpcgqogcqfv/m5tgZmjE+WSXOGWIu1yP+d8 3aX2S0x//QMhB0VJFw/sZbfaE1MYbj7NG6LRSGcEQZqQE79JPm6Z+fIwUtaY dNFt8r3Cc71xKa2E8zHz0qJYQpDUo+EFSoMYZosH8Rr1VWbher4dnZQyU9Tc vAK4bCLTCN8CizJQ0t8TVcyH886FhVLHuozCFDpY9PpcF/rk4dUhoWv38yOw tEtEucLgGH+m2+UuUdNwjHn1vn5dU9b0QZhF5/qHusM7TUFkW0dIzQN50QVD 6YT5wbCagqGQbPtnM99kXnrRGYFxAfcbaZYeubvozTZtFjJSv7i3ropJrlXu QJjYB4Sg97t3OYf4fP+IE4+c1iC1qkslTeeH5rpHuJnUWhXyhbTHuJA2ZLfD BD8PXq+sPdTEAwHH57gtCL5dSClaMP6Uk8IDSRtTJ3yWiuw8G42u1n9aX1mJ 9UD41EvWfqS0wFSgR0YIa7ojDo97uqJ+Q+6kBeGQfaeY0n/hNAfQBkza3D33 0pD0XKRF9ipMCEGJcq/Dt7yyvB7uT9evxtBT5jETZVF1aVsPGqGv4ZuW5Wsf mE8Mc+ky2N74ivewxVlLa5YU8WsA3Rl8Vle14zM69IHQj7ChYHN8DCltqruR 4tkv4VeY7hT+36/+EpzqHK80V1s8Ue4vXUTj9WNQUWtcaP02HSa9as5NGlVg q6RIKa1q5tsRFvan/QMX7qqIeXdwpcvIvPwcEoQPVgD73mRE+kUt7GSKEezt 5OpmyBn/JTTowZ4djPAE7J1tWPU7MRL0soAcDvMriXsupi9M90jDI/OMJ+n/ X8IiEhpqhPy37YPEasHRRLtn/zWSxOq6kd2IIrlcjOA3K6qDXjYM/AJOs/aL sWB5TznR7jqpRSi9xXGFp/nPnqenAV2/dJFbpf3ZpCbSVacwbPVHOwL24G5B orVkhwGR/+zGdKrKLn7hO6HU+WAbvKHkzEdeGBYNV5DNjiIJrpxBXR9v8+II JTq9HzNBhjAuL7s2/crY058ewcudUM/dI0/aDTfEKdxtTk64Ujoy4ZVwNXOA pvoBkwukxmApaxZJ9UokYl8Z/P0RE30miqw4vqE1292BoT94EPufLqiqg11g uT46aMWYk7MInMcjkrWin9CEWo07hvxuX/TJQoV3R6ynZ7DiI18iuSUwpjRu lGCn9kqnzh1yynxj8BuLvwLpDss0Az0Wx5+Nj4F4lie0LK2sC5fe30wvIO0K Ee3lok9LYG5Cw6mw/saGHl88wce2VJ7UylizgGbFbCfZNKBPZiC+LQqCQSrI 0MJbujiXyV5nHsLYFjPRPsaslw2/41+1e3bfR7jAkOFpYcwK1BeabIMdGLqt WY26kA/oULO8pQvy4eHAplxixPdCEnNveZ0TTTbDIjTQV6XzVMdhr/88LWCA qDd1pCEVFDHb1w5pPcVDy9SXxWFGvPbO7I8lcyl6gbNN2Co2yvfe12giwQJ+ hgnnvE8oGN0sBgYh5vTcq+Do8jisV/LlDGNWS+iHqMdIGJo9ZSOqeg5vGz1v Dnm/gF9IybXAZWLjlX6oJ9/OR/jhEFxBI9qOPEqbGd//TWEkg2F7Rr9Ny/Vi DtXv5xTm1YNHYAtqPhHDfur4E+d6m08A8Ixx5e/6xNMOzFed6wy6ducEQMNR fxjtLmD1vYkxG/jKj09TeAkGCeKKg5L+gIo7mMyPX5FIBXadfhkeh3nAGlx5 mdrtyEQGHlOXUavNmenvj+HcFmsNNc+mVFEcqw8T901vtwRcFyr3hj1lVARA +vFDe450eqcBs+Npy+S+FTsBxliS/UIIR+j1ZYwVn9S1Z+pvn9lJKA0iy3Iu LMSgtS1usSXXHdjyvU/Y7+amG7wrw4eBmSbB8yxPx33WRaFCsenlH5Weo6ay ws8gn/1YNHcFUg2uYqsPHHja2zprJF6eGBHM3UmYCxhxrC24oW70b9qJ7q8e htfRYoqaAPLgDtxinebEeKJMayZXQsyI1fjK0Cc2xwsynrrpIovcKGT+s9zv wiYLzoA2u8B2rMhvFUO2wzpS5485/LvHmbch0f3lvur8hRov2gshGFcb3L7b 8wQDYxfBuYS3+8adWtcE959nwA7Y33OMNisvUGr2eYaVF9r9sHV5g/y6KvWu QNtFT8acN1CoDCSoSas9NF8BDJk9fYaRiOaO1kGGQYOLaUS6RBfEOOfdPvZ0 4PLQtzcUskqMOejq7LW+4CaoVptilui0GIhLyhkmVd1JteaINNglmiscvTTR b+UBfMCTGddS1CFgfidOfuV/oHVepsuo+9KGgjHWG0ml/vgXP0igqnLifkjw eaCDK4XbqUfr+N0AmfmUBJWE2+JGw+8VoaVtQ9wnUD0m/GURr0YMYHXaydfr FfqlAlfWkIES3x+UGaYTkyfwRR7TJyi2xLki8s8PuN0lxfxm7SenBa9wUBQL OvX52GKqxHP770wKixztFH+QIE9Uo3bkhmT/PM/0pC20Mr4JJxTd80Kmyq8p xBDtMaJXfsbnlfCNCLEsE1R2JpD/7/08Wxlw7jk+SoYbNPabq36PMM6D4UKW dV1JTDNenqAvUozk+Oee4UP0KIOvWj/f1A3EeYHbfq5H/hjIbs+Hxjgn7Cn/ JdWhRGnMtmiw5pB+8KEl4UmHaFQcDTiGVqxvYoR7uv7fRiqPuh4dxtXu/Vmd Y/wQGqwrbVbwysCVj2l8uQTLKsNRZUEyrROyUvhDpZh8v/TtB7N7sWw8TTc6 JOPfQxWnW1kybjjxda/EI7NIYPxU+qOJVitdmEdsjWTXLcD7EyisEE3d3i3d esRhOzajSZrCbHIeN04NyAivy1hxNNEPycrMOIEe9Uz6sne5ZWdzGjgTCyIk k3ZlowS65f6XK43GWd8XLzcbB8fO80WI9ihEFFlOjm/Z+ytZtCu8aJofF8vu JJPPoMt0GUwX3RMOZBV6vK+0Md4I/AwlwfvSQ7akktPzCmhPiKtM/RIGZzUE yIaFpa2MMpwt7wtD6fawfk4oNtYFtih2m7cG/JDBzO9o2y5C/XRdg+W3ZGUf RyQ0KyL4/Nu0UQoh4u/8jxGfEgqDn1OGf+NT50kHXWrlNcEKr8AJE+W7sRhX 1gqHg23yJS8C7/bmWFx10BYGzDoK/tsevTGMGSfmHIYQsn++suVz5TQOhwb2 DfkGUI/1NoY79Slh7SM64V6iSJh6ZOnCFNMSf79MrLQIn70s7Q049lbsLah8 JuuzqtZdboGuUczc/uMM7HLEaqNuOwjRz74IjYUHyFWHlzG+BEFNpcdkx97C HX8ivrpq7XEkAyZDYMz8FH+zvlnLrBhroSCfp8jblH8O1V344SibtghAOWn7 ZZF2dLt5RHJhmaTbI5R7BvQHatCPBZxDuQHS1/ZV0ZjvnIT3DBq5Ke7JcBeW ywpByB3GB2gUNQVpXyOINJEJ3B/L2E7+gPKLu4dYcdXPdARO+ddKGZYNoBTU pTo0krnEGroAadzFUaK7aG4O7AYZZwN+vbpJAOh39nMr/uR+IP3woLHS4WLQ hpORdyqT5tVhLLnUF1LhgUgkbZXj3MY+vq9pyrKoEjLu2b4ETZzctGSP9ZfF PyhRmdxuhn+sTY/1FkitExUhpkCpzGHmEodfqJNI3jKxR9CNfv94G3QPkhzf B8oMQMjLjt+RpWT9I2v/Gny9qqXXS53DWPV2SeIdeNUbl8ERiJgg+MaBI4To m02BLBQfzMQxQksejk8sUPakRuVrQCqK0xHq29qnruVDcAh8DjIDgwbskhRi zTGlpwh0i8cHfSIvtjI7/9ArtzjTSb05jlnn4YO8TwJBKZ35eVwTpViqb9Oz 16LRmnqqM8Jv3/+79iozOfCjdtIGThBmPstW+Yh6HfjF4Z9XPZ+s2ISXd1qU 1GVGbUxqa0BO9Thi+9k7LwCZVp/UqLiR7gLL+wxsS9GXdB54HzVbrCXrnfQ/ vuJh/TcofJWg5fo1wtYe8viz9ES8+9srlXiiJOpPQynQQoIfOp5AS7/WI7er AfdB85pglwc8+usVdFkLeZlvJ0xpFnOyOUvu/lNxYCfZxnD0pybvwyy6a+Da 6aPKIhfn9nW13rPGIxvdv2vhdAsBZ9ktxypCBGzu65/RtejlpfM4/IBuR9S3 XImRnDO0gEYai7Da06lYh6KQ/DnQoxJ39lNliPisC5rG8Roy9PYPj3fD1foj gEVC5tgFvmcl7VjmQkiPo3WrrOcyPGl+Vt4AS5xqqR2t3K4BylSlVnD8Bu/+ E9bPYbdbYPIBaFIbo1Jbw6N6J+szNuyRl8OFAstOh5xfZh3h33qtp11hLIdJ Uf6B8OQcsYWwsshks899P3V5d5PZcX7wa4SNmLa+07tV+RWBoa3FYf0HfDHv U7oaCKzb6J+KSharEJG+Ss89NQodogMtzZuPuF0xbdfA73zWQY6ki2Np4KDR 6PjGxiDZLq6Y8e8xaR4FR/9BTZNet6f6n1Vj2yb+XJH/7BEXJjokVQ5B60nd 9qG3dmQDw/Mo3io1q9AJ2P7mbUTw5rkkAcivAyt5rDO/xDoPHp0ByKVa4Ezt WeKyI0MkAozNbcNdosl5mvefJ9BeI6N+P8b7ttEHvYYm9rboyh4yQeo2AD5v DC/KPybb1eEMQXavaeVp/UsJE7s31C9H3qrnzRnkWsvNi06IyS5bqFWPhz/f /fmDCZaPDyrsR6SNe8t/lINvlTEabCs81PCt1dGbsNcqqR1ZEAy9Bq85Akdo C3DS8J9n+aSFfZaWYoeAQKs4gWhWB720BUYSdVTQvDMq0j6AWvGFpLHf47u8 byJQjfqvBTblTwVn34UKQ8Qadb7MTdWcyKDOI/1UqdeWufQjm3dDzXzDH9Qx DU4WKvXfvMaw8mUBHlk0P6Ut7NSvJEHqmZU/h7szgEjQFK6wHfuRRC4v3ZDQ QCbG7fPE4AlGxzKog3Cec0IvFLu0vTJi2dRa8nJpYhZsBoiZd6cesueBFUbI zlOEYppTocq3Od+VuXgUmKK7/A/jZAUu4JF3E/fV+QWLsS5fM5/QRBCgnn/E Q9lZsivNQpkXCzTW5DO85uDASPOeKVvVk1EZ0YgKL5VfYcGEINi3R0onX6CH 8NyqfBv0+fNBFRFWhOesvqAKv3a/S4ddM2wv7rE33dFWPV/JYfrHbKL/fYCf zm5Mg5Rt+AKFkiHrJ+mNeCSUcHtfTCYHTjUxLxodMsi2EaVQVoep81JCOdo3 MU+svH9w+orpkUNqKgsB9i7sJu6CCnGcHVqOjjjpVbyzr5xhyieiyDuTdovJ Q9+IskQlPtP8NjFzxcy+e+wFcVoM03C6ClyjAuvO6MAz5O9izqdveZe6vK19 FtmIFTf1jcSmDxlKDJ3afjyhegluz0h+qQZB2M0gSujaCIshtXzQ7Nj2HTPp H38KuAdg1W/JAwu4YhOvk1KYiW6oRYoeUqBM7p4N6uoPSbWZc7pBU8m6XE7a Z8/PaROdPrbFo1w22CkcOp0440pXFDbzoYWdL6lMoy0QNw4vLejX67kBd2tB JKfXscqE8eUFr9ZztjQh7hMo/FfuCqOR3Ayd+FihulxLQKSx5aFF9JkMll+U Sw9WAHwzXiVi6XejAL5nUOiVZ5vfBQxe56EZ6a0MVQ9qE+Y3KWCJqQQgowh4 UT+v3wHX2X1aIxS5/KFCsfhN1Rwc5TiNS1FT/qTy7+NEqFzFAVb5SKTYoyN1 b1fE/iWyEBe2rR4ymw2S1nT+DQJYZFluifrjPd7PMDZPfKY9v2SVKCQVFaQx G/CexEZHbKnMYVesbCkzI1Qfb73hm0G6bOnNmLAkXstbYQwrUTwL+iZaZyOD tWUuHMksr+YZD8uvbn/0WDFNRKz3pjNfRzQWeLxynLi7vMUOuJQ0XXqsm6aP DQ68gLGVsPZO+dTlhhZuO4WzHSjgwHWl6GQRbOMmNmAfj7zKdlIXKUGvH61M wQaeRgTlb2ZHp1BEIG9xzL1uM5LTBxi2THQBlpFBuSKZ4WVh4CoQv+I+8o7w y2B6sQSddOzvNGrGcRH39kcE5dzf1U0r3Mf0dgR4EUnmWLP1tugfw8nCvvHi +3jXgwVYW9FxLPwwdvzdn8Sf1rkaAQeDPAwvaE2gilJ2H1ZCmZ1J0TfLT+zX JSvseHlT843rI3TRTO/4feMZO9sbmu4hRZC/yfIm6jACuwn+1uw3WcwMid19 0Tj/QsDUaFdrRuBTUNncfu+ZVc3Pjl38VGtGnvnuArJNT2mVfMjko4la7EMy FDNTvrl9aImW/0Fvtmp7blzACqnRR/RJW5xMJRaihht5ZpA2Oh/DkQ6NcS8K /WLxfl8H7KTfzqyfhBy8gt/7F0asJFypVGCMK0qSyVgegLXjp/QNlNK4/yXJ 650W8W7jQHBx3Xc1nUdqHtbFtbma4KXTrxFmdIM791/b6L/pliGXNoztX/Hr EytDA/fEt31m+JI4SupvelufPBhdS4aZd3rYf+rXT5xNZosTKQboZXTWRPXC P/3nH7Cd4LWuJtdoEHRTtVF9CiO31o3pJP43jRpDYG0Vhkv0Z08rZ4HAB9Fy 6l4R3b+r9fCg98s43KbIU/dOK4N2dE/hnB559DIDmhveINVu7Tr1tf3ebhjA je8gsr0r9xYD8odJN9CXL24P2efKTWr2NuTPJP1kc1z7CpWboNW3TIAdKDm2 a7fz33gOc2A0Gs/vWIPF3cv3TXD57szMSxCTJ1oQDzuWtwZAqEaQ8q7ePG4g n53uMyWgWuFchQgWDo/VPyr05ERe9Ldu0riSFpyWFvsxLUUhBDh7WDl/k+6s 0HoLnT21f1SLzlm/Xi36hXjP6YfLDJwdbm0fwDyQYtum4axIJCfWcLWxwXWq 8wTlQ+w8HyM08mSZKOuhNApn+/6ZeeyzrQE93ENsGWd6wzO0QDJ1m+Mmq7r1 iYmSb3L0cmAKUtuAjgL/Kqa+b586oCb0G51USrCZAwHOLwWD6LOML617HPiY Qrfr2+Hx24DU9znOLmW010P2h6qIMgOh4q5j36YCfMF6/q+1itIi3HDNgxKv w5121/ETDiZGPDHYpDTfYBcizWBkYhoOuLZ8JLBGPJNA8z/KqaJ73PfD/WqL pwnvUtadd/oM9ZIp8VOgcoRBB65N0Yem7IX2yux7bLT58Co9FXVuOjnJxlG2 WJFuCgMyChJ1Y+BvHtpF81H6aolA6svZLdX1AYq3lTkHEt+aIw+/aRiN5oLG VY0HmbkDT2KhJVhW5PRES9QSzQdpu8M6ndRUYHxdCMK8C0aL2zeALMwz8sVx 1Dh0Pu4tQG2B66rO/ImY8nFEtDnr3sVkGGwYWKXwkpeMXEUTE8Ev5dqZkEGN /AMi7AefqW8UoBDP/CPxnqTIUd1F2ak0sZIPtLKBsYXYbeL3kZqDkfN2auSc GZg2VueLUVslQZ6fWDYEVVUlxhoLNiAUmUapzemacQPyrfJMYwqRgH5iMl1J 5wzygYrRgPzwsqxwO97Lg90N/o5TwPjgyTi3mWdPuvuPDwJgHPkJrDh5ypc6 vwMWzPQxhjaaERCM4d1SOqYcKd52FVg7AypRgVU3YLI5+8Nid0RYZU7A+jvH hpq8pNpKziZ4R0zV53qktq/CkXvhLz27xIQg3k+SJy3Rz4TMjFazzbHu6f0f nK8iBrJDDRLz6A2/cu+Cwp0wj9P0IpUrGm4H11wZM2/ocFAJfaHrODSol/RP E/AuQPhD3iaMoxG135gRU/dHTjZ/B5C4+nZ0L62/ZSZ2t4qjac7GSpxtB+KN 737hebaXp533yREbIPOAjHs7w05kDMiXzeopF2lB1qnxtbUxWGcZODnUCs1d hD8oY5c+5fVoYb35pByYPbAZT/5tEFOC9Pnl6QNzjdwlh/OrN1Ck8ACejxjA 0JOueU+fOvlGIUNCYV9W8bsDnJAuwoEZgGYyfpZ6qHDQzXTf334jwdJBcf3l KmZjgS4pNP0xT1VYB3rWy2d6RxjApC4kjb2chgQhJa4PECQKOmOKYtKZeNHt DDenU9uMnxRuRhLEW3zxCoOSVsVPjl/hYZ5ABXy2JpCf36WGN54jxc9Pe/GJ sYtrPsli14A80kla+gydJt39Oy5KBnuLR7PVHrS+KiSATz7KeIlmwUA6eW0Z 7s2sHKoYfa8ucYoai4LFdOYkWgsk4Eg6iWsr6P7GiIf3G/D6dHqM0Fvb6OEV Rr+E/tWRlgZoFvs+GSgfqGHubvSwGwreUX8Pwyj8HUsnstqxCbL9+qvX/u6e E6hfKGT5sF7tBAcTejZbgsxw6F6r2RfQEzn7B04HuybuIyENnT3ol9hhvdF6 dUBzWA5Hsba11+ue509ADkFMmwtF/pAraNMaBTY80rZ/4UWAFqzNnz7vxjfr lqYcLLkJjp7l7dC3Wpnxdi0qYeWcBRwjoFFw0+n+62ARKGKGbPmscq2vPKZe OHpBKXp/rR3vnzXwO6Yi5z8UXXrNqzG1PTe87EUxX8UIhrP7kFKigLFY48iB 4EvlmpZAvXOSUiD96HwsY823dqKobQPfSkuQ250mUh1Go4M8Z1/kBlZCMTDr P8hHFJ8+iedYSxflFZPRJDZwvGhBWtlFQ5KW9ZFNk0Z0+8x+IRnHQancu1Md 8Psp0SS0Si04g2dCyTTqQHfeqFmF7RphZmHk6WRX5U4W3QFRStNMw2SuqGFM lal9j08ZECbc8obwqxpzw+oxGbJMqvCF35VjbDW7Pr1e1fAIVpBrZdxu7IT0 L9tAmFz44DrwjvlFXfW+oEbJHeGpSGJ4DvdPwYf5WpgQIP4Qs537d2Dh/2Us XY3en42LuE44uin0+Wb5lTe8fv7MFvJMTY+YWsZpKh+IWAKYXmXqW969sC12 SSSnf3Mc8R1Z715ijjatzrrboJBJaos9brj94AKdzSfPqLx46hQO/VKj/HYy QLGly+u0aE5Qh7Fvn/anRXfhEvEup0vhUaPS6v/jZ9RBTehXjtwDQ8VODrWe rP5c2HifXVU6ZqzyYY6DcwsTZTnXA40Py72fOmc0IFjF5h+RQsEGfDM19X2R Lq/ieDKzUiNp/nYd8CIgT5dDUruYBQHhylti73FPKYeshNSHOp0RFX8umxp1 y8DO9zvoa4Z1dsSx5A5Cd6xrwuTgh4yER5/yHNsKhi9UST0KIpiXHTPwzTXZ vKuX3HIPBLSpAO+60/sPt0CkQq9Aoii1MfLqiWZUOauejVzitTUAVIx/n2Sp sKOWvTvp5I4Jzvid++HzOtD06RWfoNDm5vEaK9MZil6C9j2mAoo+W6isPah5 LSkBBBPpIFkj+lmxtCElD1KF0aQWBftYXvdQixSL1t11aUIZlp96Q6MizIhD 06/5DJvvFHGi5K0KQGUZMSIxpSOllBszbOpedhnbMIEbRtVyX1a6Auhvm1WL TH5I1qzh3rAvQxvzpDeXrHQkd8Rl/RB8sjbFn6h4DZl2Dz2MjeBJ2JBqnVxW OwrV/NVxNB9rRKfi0PrNcj013ciApvLMW25/TxwqX13jZxozCT+HdfxdvUW4 FxA8kpFdi+E9fh7rLi0RRQ1E0IQcMds+vEuDQx6apKDTwQZ6yYLhjznYgj4v GMIkTuWuUnqgYbhR4omDYvuCYo76reuOyrA9H8f5GXJ40sQgTBmZYrQa6etH EKmRex2EF05+onWzOxEVqST/gfDQ9CAYw7n9pYN3nLV6kwGWnGPDsFtlMUcL SsOmT6glZMnjTgMane6ztvpYkb3khLwXGDjc9YkgyvWwF0zUtCvYPb4v7TA5 3p3UTJXA83hmXCssdjsmHWps9S0zoZ4vrLG6AOEDN0rPfp8UbPcFEECS6k/E 9qbdQQXPuOTZWH0vWYALpE6entCHFEBSNLWn25GDbAXC6jQWD7HAsiMl/AdB hftFkBzw15R+j10oricLrVNUkdR6ptEzEHyHu0zVEtl2vtwhS9QSOLUa7Ckf p6PDDH+J0lQ0tgJhLEVjxSsYGydyPmD5kpd01LX5ohCT1+EtJaTxWBlr68KK 2yNBMq1Q1FJFNgcVLIExlKDwgToMd/pF8trnxCQ9nz8X9DilvbZvEDt7ysny s7sGgq4TzKMbUvB9m+OAhKz8vwdiPIwZOEos89H3MkFV5pr107b3OD+zROEW tCcaTZgPTkANU6n14/gESElwFJ/PfWFGfrhBm0RWu3c9QmyLq2R7/G33D8GT XBGbUW+k50TMgOeL7PCYLFMM/tA91Pz8q2ctiQni/m/pdT0jZyJgLUpw82Na CNoKGlom36uuD/9ARJ3dvNgZkRnYAahPAlmqEmiPAcLQ1WeBZNMJsmkm2bLI hCwaKyYMxTJZRvlIWGllmTdNMDZ8HbrvvrM09den+HHMWfzx949IZfuc5xZP sK9H8DKr1y0Hrqohzopo3AiZTmTSM5odA6Sa5MFmI5aSLvzSxZFJi9v1cRKZ Bfroq+0B/TWZZNL/NOI47patNqA1v9iTd6EBm8rU0jLOnaAnam4jvgt79AUT 0fhX30G3qTg90fcQIDBf2SxHIdYCV9s2Vetm3MNq25+Axz+0j8hu1/dPmWJ9 P9ZxZ3ocorPFW64yATaLSpjc2KL5SpXI5j6HxBbEjAvaMAZ9cOGwhU0gvie4 BcSB30Mvmwp/7uMESo8XsRZ81h8AhtPN9lxT3CaTeA16JkGa1REIPU393/FO 3zb6PjwgjECknaJDVJIYhCxPz9kPCsKdNnmG6OvERsDt46cG6yPmFnNrt+8K lRyHiQELmikeJtVWVOOtOdIiBtgsaHqMW7KA97F7E3XofB0RBUiaDzT+ji+L 1rNT4KMh+9r+NEsIR2/iyZHuuB+RqpTcXVMOcvMJtMuYSyVJasFUIbeCrnuq u7oXzirHcVA/Ms3XZSxdfpBfKtFM09j0Yvs8JtB20Kpy7utR5nl1Ez/kJqse YKz3tcU+HM+gqCPQWlzwlqMBYOO8nDnjj6dqXS+ZggK7tv8DD1coDyqTx93P WLb09IcQ/8mPH81o9kqmBsKE2vZ72+kv8AT9fkOsam2QuFxsRKh/s3jvUUDP DkGoiEA4v7FJQ/R4hIrzvI23FWiJqDqg+hwzFC4WcmkJ2bWhhDRQN2F0BzSM 1MsrN/e+zoIq6hcSW6ihifEFIdTKoKbuS2uJYJXTyUfYGYzXjlfkm3sQouez v8GtXpFSNAoukpyLmS87wWFx+FdPeqrziMGknr1rh+xwDqcGZVQB86+Yok0n jxOoNVuulyUrc7JBQQyPgz+SixAQamZUIkxpuiebP0Z9cKc2cpzMKjTxKjdD Wr58ZC2waehN/OoCrKJqOG3njg8a9QxBpIfPyTDPGfz5gy3v7uV95fMHMu9h nWxC+5ge0RtD4hO8oITG1K95yIfVVKGNqhaW97NeLKLgRCgvv1Ri82YEumiI lnzTNTE1Hn0y2b5VddPyGB/uoPCSrg+UiDP0wdWYS35z6eyQjdj9YbmOSunC 2irnuafLW3gT71z4BG1e+IecUkvwZcP6NZ4sekyN+7Te5S7la6P+zcihfLe7 /gXJdEujYMvS1nBk183mB1SY6jFqAHMahxdcVyBS3eyZQfJ5yHd0qL0zzRm5 W48hj2Q/9MxbiKoQX1Hbo1j3W/uwPYCN0rpZ0jlC8o9cwa5NQVM17LgyhgD3 P7iv5k/Ly5IhY/TTocw4g9dTitWlZ3+4GwR5HbHlF30hPVa8yxMzulNHGVCc h2NfsOD6DA6blW7tX1p3qhf32Zw/fP6BIUeWO5hRP9N3afmsbWzAbAlsgbpd gzSMvzHbNi3m3il93jS35Hrial8Fw7nVjfCw4oqL9UhhHsqv2ilW9n7LBb/U j/4Cvwd/7PE1JlQx1t54/cXhR3kSp84VsAUMSwkHi3UtCEjMcSIM/hN+7Bwz K+CC7/VutPLh/aHv/ENq9jdQNQXst9VnZxJFT9RdIeml7XZARV9ObltglDGp SN0Ij6/7RrML8eMnbCA6vs8wtAWfDUjC1UKnP8BKEUmf8Po96OGj96fxvEvS EAIYvrTRxWezp9R2gCHVqaJcJA5tlH7cUS+DtCqEVVtmypIfxr10GVFtl4vm P8hJa9dzb1ODhemIne9JfP4du++9l7l9XD5OnfUTmrqT4OXuZHYTHmEl4OZ/ 42msVpPL7jCGqe+PnYWQdJ4iBkvaqso50z6CwEFD/f7wt519kfghZsTIFiKI GdrSad45giqV0xPN14sw/acAzwUQVIJe/cYbwlSoYpGn+sH2VpEZm6SFaIk3 4cd7ya4G+BeTpJW2v6B1nak7+JQrxWG4ysEfUNMp5QXPMday19Ph1iBrg7Mf m4u8W8OVUiwMufSilZsSN9DpLeNUJA9NfU3ZfN8pzFuJ0xtVzyK3n9IIx04U k3IOsodnZexifUv9fqSeg7ZoCbU/6MvBFl5AzJvVNkMBc1rr2ZnIQ+dgICd9 8ZRFPHDfw1OHq51tgjxSKfq5oTRr1XuGscCG31NLyzt3BrQMIHkRCtHoYtWN v1sxg8BBuYGjBPQobgatPyu3a4g+aSMS6gzPyzbLf80ncvJ0q+4xAQaNFNr7 hQskN/tfRGhDVlsj/2aFgBbkZ2T4+w8OaaWJoyqfaxT/FR5A5tW+J1osFEaS nM50/3mbk8Yj47FygL/BppsUmedAD6XjHJEjRbPAR5Q7Qi/WIhwBCy7q4Vl0 jcAVGyg5ba+p54NrnzjuzySxsEPyrv2pfrx+4t6YMlK7TUR3nX8D5OsJiQOG 2fa5Esz1qoLj8bkjbxCK6VYD18tKNNIZaZxvNmDcMgzM2XHKOI+Rudqo2/yJ HyPjbBx31JN8UjeG+E4pLz+c/hNNA78U0uXq9uF0WNFtBDfuONOSpOfAyAa0 2iX/hnkjONpg0wQ7HV1FLiNQlOXk6amjkjGI3Fpn0lxdTMP3fYOKUSe46FeT FBqkECUWyoj89MrqaxfvWPdvizY9qOh3yMKoLbc9/ZM8FRcxEyUTQ1EVPXl3 vMDxS2hCPBXMVyfi6Yzpkjz3IZSiBTB1OREmZMvR5Q+lJseDExB2OvMApxxO Qdwvu083+82QiM+20TOswJmg0PcPT1RRYiJYjR4dvhEo7pAj3fqq0EiKMzSf ta7JBr83UKXW7SowMKUUFSWO26yeMYGOEkfxF5tV0hLwLxFE6YaVth7Hb4gd HWZLjXrSy8DQ/uO25+tIYU4doB0/Ml9mk3RI6dD2Q+/YrWGUyyE130CGAbd8 s4UYF9QpMaShYO4E8UfElMFujSzH9oZnz5njfvJ2vSEpLVnK9Xysq/+KQ1sz ZXY99IaQXmJBXzjF14Q2edUQdtuzcOT2TCGz4MMft3fVLXiBrh7ZLs3XXb8b Lp/vI7y777USvoHTh7Pg2ifni9iZ53pGeWNSAoCowztrH755AU4cX1v5TyZf QOnu6BM9DbGtR7bf1rpKnzQ8Lzp3dJZrszBiAlApLvVEW88PNGTBQGzHbO9z QuMj5djDra+LDzef7ycyRKzX/RPa89DxlbR7wU0RhxC91wmYLJr6XoPT/234 UWGaIT+qTDUNRFpLWG13F3FBD7Q70oJx/pobR43mZjR936iU7J9CU9YUm7qW ybzX+OmNEYJoDpUBs0dgtp67u5YYteexfvMxEcHJ70agz+0b9APXhNhyUuJi ohon56WK3EeXb5+pdv3XybF+ipsz9kUOt/o8j76QBsljQntuHJV2I8heFn8E LF99XUaxuQ9egl2La/ZezTtXclUEEt8kU4/UvBXJv1pvdyA1ZVg3583swmuh 16nGTZfaNE/q91SJuJgwv8xxQD6PY6NrIkoG2OXICC30vkA1q/TbRAvQuh50 JL7ig31rNaxyQlTkP3+fsfETk+wPEjd8eRXZdgRTueS85xz9QaWJIDVxWorV jnfIAve/p2mmZ3KYDPsmIr2NjySm6YiFwzR8xv4JXgNrafURus03zGfNwR9y vmhmm9zRCIHN89i5xjbDzd77op68013XOPgxi1o0h/lbXrC1ukApl85rJwEv 6LqvOMrsIux3Y1va/SQw5nJphxqwgaUg9NI5zYlIR6eFbKOm0dbPif10b17O c+Tz5uqG1AXWYzNjH+QT+TttE/WJv1f88IZWRTEb8CuMB+8LvQfei59mQbsL oLxuNzNtu84l0j2XDqZ6MOs4WGEQvl83/Fe+on01DHyyRE3LynXA/PPuH6pW TfYBX9TDfqnl6zd2cwGXsJ8Y5e78XKfn98MG8TZ+/UuUE7Xpgko7qVmCR5g8 Kj1jypkPnHAMbXBD+SwZv4gaQpXR+CJycGNcgKWJJ4ZuiN5qppxO55T4n1WG wW8+joeE10dtxG9zlN8b4I4envI271jwDPiltxFK7fsN1/hhlKfLPUJZf4Zt qZGmHaadZIMcX2unnwUd/yEsD9oedacNw1+wf4u/f/0Ffd5SPNB1Ga41xfQU wY0oHqVUtpnABL7KrMXkf8zzO1iYfFOzCXPxYM0M3zuAWpBU0yyYwg4E+JpY qq9nMKBBbO7aiPWmxgjo8BR1SP56p/K1NzNaoBqDKiKtt5AX3Wz5JAU1bZKK /1tRo3eNZ4NoaSGMRVBm4wuEgSnl4pfcmr6abw3w03R6UHMAtS3g8VLEximC abkc1tenkc/9fq/ZXtBl4VOhxqVC8TSA1ejIDS4hOAFIVQ2OTWr66BUkdnv9 m8HReWZdqMT9cbKkvcKroJmw6bKLIg6VDSK3x+5BMJ/K14vZND3E4FiNqeWB KzJGVnskReCigT6+GiG780QOwe1+5/iENbrsDzeaz8DAd+Hiub0YscdQ0TgJ VCkvFdChIrrDheC12/MIrtA+HnD4HDXxsBpeMv2Up7Jo7Yx9X/cd/Nh3oe9F VwwMGxVfvjQf47RRH83llQnC2B+pRieWE03rN+6Y2VcacwyDkoFyplLfwdr/ b5xVp8h1uvwJpWS23IhBGyfj4RdrF5n/QYJ3NOGg16Za9KX3FzkAkf7utMxV wq9mq0QN8VMQBfpgzJ7ZwUquY4u7jUpcFaQ5b3Pok3oBkKeVnX/s6C6KmZBG s/GBY943MNbVuL7aVyUAZTfLxGIs+hDnxpV/4RQQCKasiPEcaYBFb9OCuZaz aQ3VenVR+xb0dNbYM0nipS6mdyKShO+LDBckSJk4ey05pQb1zX3Tgt0k7MsQ wotFkTxdP4ARqY/sf51wS+Av/jB08PJS0VnpZP5DgkaN8rCFZhVjnczLuinx +iajwQucZ0iwUKsKo+qCAUcHnXlExR/eESkRsj2lZNA7r2qyYpDVYw8/ez3f LXkkYJUvIfwWg/XMfQOALv1c1WmufNzHxsWKMnCeh00cTs/4UFT4CzmMeB2l jjxv/QoqDU/B7afAbQsZmgc/J1X11CqZf0v1wVdGitaB/NtzwNFHz/p7zipt bkk7GQNGPflYfI09OfRPcDzxZIl3x2cdu404PzgQbrvKp+eSf0CKvDlX18u/ 9WnPBIFW5k8klavmEZDD0ogklCaD9XlFuEzWWwpr6lhXHhjAMC506rlp+nAE CVRG/d0oz6tcp5kszyrQFBu07XhDoAL6o0FPJZk7FErulud2QhhrRB3mwQCT bzJkmrEcZxvLmDT47OJpLfEhw5s+n9vd+yB+/24lmnJi3F70iD/5fNwhFAuw BuRZ8sL1jxYAbzl34CNTuxNyaapx/WpER12cfl0i+lb6NHBJfi2ezHWjG8eW LEwlpiHUrBOKDXuPnuGNsdg2eJfJd2thzO0Rd17QlAB+d7JK9M88ND0RE25J VylrSVSx38FLYCU2Nzrh7a9T1ew/wjGE752iCR+XkbQeCp+9bqmJhAApC2my 7L+ZfkLkjy4jmm2/UhycFsj81C6ROIHd7ajd3UdlKQQKmRDoYCj69fW+rUDz n+6h9PbX9p6rxTcddr598c+IfDOiFvDN56I6g8NLY5LYrYhHZ07LdsVSWlEr 3x0j7Y190veHabCJ/5jtmZRX1JRaEZyMSNLnavGGLozwYdvdCGX9eDdKSfnL Yun3UPmaIVthXR6KQBzVU7sz7qGUqIuPKpdvlbzjutJx6+w9SIg3W2LqWqLN YbgzaSLD/Ljvr/7JY8khJbLXKRz62A7n/m1fBc8CsCccFl91dfvrYXCnDjyD 6vS0Fk75fvoprZD/DuIsHe3JTYvoa2fLORirjisDarkDejUEI7AzZvfangnt 1gpMV9rptRxf3xX3w3+bvda4iuLkQpEIctA7uimMPMevIwXHxxokWV8J+E8z 025xVj73B6SULa3hahgG5fT7f2/ohUbMHooHz6txpNr/qGnCSyYnQ53Zsv46 dSrifbjlYCVNrFCzK7k8iB8aaIWBm9NfD2xMujEs3fz6iGT00dsaQ9LtNakl Zq5RMxIJQ+sGg1bPnQoq/lQscROyEWiqS/0UAgEfW+suxQVhuMrCeqt4zA7w M6iPZpFa08mEl1y5UlomF7IU31YiTXyXxGCYWMDWSYsqvQHuF1s5nEKY0Nim qZ/7Y0TnAp8zcfVDyaxUG6tGNKgPeBdASMsSqq/Ba9IfjM0q6ckNIKviwhDh 9ed+ddEivlfYLoph3mvosBGxp5wA/5regOYLMKQfuyW1MR7K6YFeuMp/gbHF KdZfvAo6VfH54p2LtZAA5cuSRpBVnfElp9qaZRne+ly8+7ZMEOXOOYaUIiiS 7ejmNZxLAWD2/5Gp8t5iBtfUyu8erxa+tFmC63rkIh3Ycdw+FNAfozqCCwfM 2OTPmaKFr07CPd+ilWRr7yX4zvPezgRis++vcHuOVEMCChUhzNHD+jH9woMO a1IlUFZ44ORW1KQHxb54B4yGZdJEkLuAmAzL8l5XWHBpF3Lyyk9luEe6sEuy 6sqqXmTM4hpxHeiC99z3wCPTh6IpzJ5GAbLFZ2fazVn/3H1LGz1IOeFibeK7 8fmRlsNec7tUgemtNj32m/oo1GNeA6V7c4it4FoQcm1f5FWWZsdz1f59N+WZ laJM8W8+gVUwxcK5jM4AdOfZ4SOxLyQIG5pT9UZ5uNNXKySshbSWiCAmTT8N 3T3uRhEoJ9z9kzu20Obi+bfDfGOiN/svfGGxWFMvtF8ilizNRhfmMYF6WIuQ +qweVE1nHt+q+qwTrmLh+vJcPcDF6PFIIRGce1RRyn1/AJzwEinZvn/KiZlJ hy8s2/QEld+/KsKFITRBpw7q2ZcBTjkCiFk3vGw6vhXTj0FzLxha60c10xuK tFu17P2vpasi7AHbp1HYjYbkIgjEyV5lT4BRtbVgASXnlKWIb8qmmRjn899Y uxnUHWSWeAiA53hVkvn3za8A9PhLpIrlgQ/2Uyso/CDqB4lFOp+LqhUQcEMa TzXYgZ8zFK610HkcIvOOHYomVRKfLAQp2vnj796eWvF7qeTnMijdGkU9yOsK K14ysDjBnupep/2pYQYCuwlUfp/QW8/5KhFvbYdnrAMs1l+ft92IlgbCzbdk medGoCvaJodrR6qKS8Zhhq7hUVvOotdw9xlhm9rDcoDOu+Tazq4eg28FZaIY s3ecEFRenWbkOFCPhXMCqWIO+ycAn382S8v2gJQ1ednqYARNLobhLVsrHJ+k KKEMzc2S5cyE+12/BiqI0zovc+FfpmkgcMhVoB2hrTY/eu4jYI2F4b+7nuxf CE4WZus3UO+4jiUzAnZ6T+9kocs7ubrcOf1StoTHgMOkjJO8zAIK/LzifZMk 02ItqBGe5iy6CU14BCBnufC7XeGapgOfWNId+4//QLM2RI6NY17SD4D3mw36 pJPmHO3zfET5LTXx2UHqz4Hwkiyrakm9QmcHjTCPg0z5yjgS5+BKR/76h4EB okGa75G8UQLaHvvzJ7b5VL/e632CTvT1DPzocf0sRPoIRT0KYVI/GuKJMeFn PReOI3ME478bRtf/nSmpT1TElQeUPTjkV7G5mCNCZLemd0S/1v4BWC+qvNBP 7VcKpq5sr5tk9ewH7PlqJX4J7Ke32p4xS3xfh/dalf6guBAjZI6dgvGpl2e+ gOOiQr1Smp/o+JZRbTlXyDeBKKjgpam84r4Uzx2YWH8HBXCJS0USIRpaAy1P IH2mtW6jyqsQrxaEAykbc6Zbmdnyf5S5+RyOEs+i9NL6OyEUwK9myIGF1D3j /rm7eVvQgc8I23MYSO0PX2cs91MkNdzUKvySTxdAndBcrnViQ0oWvkXNhB3y iSt0/7M6oODVBqk1oBLx4MmFd4xwQhObf7+zUth0UKfmZSyf4N6QW3kGq7cr JolJEkBxTtuW9cetd0VE/b4dfGF/M3qBt796jvYNEHFfnabefmm0hXNRHIrY PBGs4zBwT7ttwbkIX3a3F75Kd+9NohT0nrU/oVk39QVreEPGBbU6ECCxVPZT H34ZQmLwq2DRnT8wRq/nzdEn8lfhleuF49Tv0gpjgIzfN+bAEXKr536U8LfF +BEzNqgYZ5wGqt9vouqF1V8H8ySkNkWqfSD8Lehga/Y8ZUIS3gwhPU92+szF fZ+KfLf9BOrVQ+ivzUHlKoD6YTepfLujHz0OZYsm3K3h8VQMtO1xyS854nT5 Cg6fX5jPjEzYGU0stjitR1eQezovPaghij45V3EFvuyqr0rD1AjtjdDcVNiG zULQLgXk4S54X2OsUV+KWez+0UDF+Y59P2Aifu1kB7fXtEGL6R3qG2837hXU 6aI7VxSjHRbEg1TWuSEC178CfzIP4cFUPVLELdVuta+xmdAGx3Qp2SNbeQBR +nxnMEtWTdc58jNCuHzcyOHHA0qMjoHe/KRPrW01ZAk33uL1sCt9gJhLkVfr WpScB8qE/j02Y2hAQ+bHWQwV3y4Q+HmEVykNpad7lh7VHH25Nq8JmHIPtSog KrxeX/b59c53uIElsTejDDOYjXdnsNHgWH1TBHYEVr3qc1E5tr67/GVv67Fp XpMNXlWz1sAk8N7m48ss9YoXOji9f1qIxr731122v9Il7InnN5phS+3kRAcK bVqLT5N6ik3oH/iO7DlHn20wTlaIdx334F//ZPKyRGzlNchuRkCnl2ggpYbP W5ej52s6NAUKH3ExKyIjiludMMsUDn+ZNK+tC0Kj4mgDQyWiq8jfYKcUpYeU IZ8ktWfGqrEWHhw8p7HcRQCjprHmQsfungIi0X2Z/kfSsCUjvhBfarH1ETCr G29UNLPzl8+kfM8Fs44NGF3FXrI15BddGUQK9cFwHFTQrnpqToO66Ib0i5Nm OFPrY97uZfRe8uEYNy+ae71GdP/cdSi0r0mIUYWHPUCvqff3eRdCeKB618ai aOUCwCC5oRmxZpMH6yanakInqaUj3sjgrkC5cARdxykuT0fL7hcU1p8R/kQE aCKyjgpezRiPm7lllajSARzBJn11SXtcEib1h2IBZT6DYcQrCL4OmCVdoIrm Va/Nf3PMEt+6G81Qq2f8QaWuVTxb8ZOvUMcYKXCH6vzxzPLy23s/pq1LU5an uj0bCdTIWTzuvdTvqMj9p5L8I9DYvlbE2p4uDJtAJqpu29yC+aOG1Z/IySKV Y8QqDsmq9bnipr/GQB5pTpanGruMIGIQoKA89zXlRZNAbnnn9G3idLrBS9eQ xdrkMZqLSMjMvxrxpufa72zyQ0YZyz7s4kPDrYEBvAUpV0qD6cvm4WBp3vzh RH9EDyna0hNBFKaQmF3cNVl+TM5sluFYjC7Bo6DHlHHtFrbhFj12lsSs7mju 03gqSPiIczpOXnS0E+ET9RUpxLvXPN2TeGwk32A3l9bN++epgH1d2y7VVuyx RnDmHoBaadI5q00TkPwG7vDVIuLMAlpMa+YwJZKTrljYzAm07kmA+6JJ+Eap dDDHspX/XUq2S8XxefpTop3TeX1vH8Sb8RSV2QYB5q9ZzBd4BpbyN783RUm1 N1A98L8+rUa89NHOEcXcpEaG33NnrygffVhc3vchUtALD86uzXSd7kPmJr0+ HkTxmERzsK4u8l+7TlOYLie/g9HiGTD6zItuID8eVBo55wor55hlFG36+FGT UttfUzfCoLGw25Lyn+Zzd5pBWgF38xpi9KZu5KVEBJ1+2geCU6jD+AnzGAps W/Sf/1o2x9yCgtddvPFode5PI72u99ebgGrXQncq2Zp0LT+3fv0+PrKA97AD uSx31LK0goKhgJKP38+zVv+HmsbiQRgmBKEzqS/gi6G2bnfS8j9n2Dx8ASJg sRh+QROgFShxT0otXyNQ5MDiVjRzVabDb9cis79bR7oSDH5ifJXYhiEveAky ypkYjZ6USt2wVya+cKPtQPmBVPXNlNrs0zQ6IzqJUgZoXi1GcQXfU54e58mx Sr6PDTw65hs3Lno7SKHnZ19K1XiHUCrBQagGot/GtHoonEnmGQe+luFY94zZ usvRD1POVuAZ6qqVELP5FMcSi4A5dyw7Wsk+36Kn2cgLqNrh0FX/NaIrGP0d ZLuDdrbVQME05lDV5HfnwfFViUJbHwPoHjPaxkqbXS2JOJNOAgbhvQe+2ffH e/kvVJ9I6JVmLFQuSRzAlEQmbyv4nbP0X8K3ZpZD8m4dBV0RUa112wHeXK20 ps5g5QeWve2XQwyyKfn4DV2UT/UbkCPEvUEQMFHQ/4hE7NDeQnVIWY/hDurw RJSz1LrcEdDHjzIy8wFMAKmdXPk0c4fugqQQpt/Nz+5Wvt6k1OAws5wRx5ll RQm+qaTzK5Ln3M7/PF2veTDj0NwvEePKlcLI6fay+53z+w+lcKcUCbH2o4KV PoZAmnThr8XV1dIu1+nD3YJemeLZFI0ieECrN9gg9ZjE+wQl8phKIz1tvEJ2 brN9HlN4yEquiFK6m2PAeQhyk8ubwtfKgVpv0j0qTOWSlRVvA4dtedXuGA/J 3iz7+hqXQrfll8emh3U5np95prFH0VZ42L2zWk3rx5viDVp71q0bOvYTUXBm wxi/LPMaqyUWzLxeQbeuXP0faltGACYZpENCfXdrooCdgdGFDXncv/4sDY5x q1PdkKq+kfTRw1DPe9Wiq6hP6ug5n5T96koi40USjD3eu0PZDzkMgm4fD9Gg PvMsPyZInP8ARd1k7U2XHaH/Mvo7RWrXHVbAaP6LZbSZOMnClgg3/encOhkc g9EeDfDAsU1nH5gSPHKimW0fuQH3Ui/yc6onyH1mlmitoy2nfEqe3W/Q9Vwa fRC9VMCHqFuD9O4UWgq+vSkRoydIzpO8HIxLyd1KN4JUvt54zw+Iu6DHNIQd ky8cloO0p+spHzFNu/MuiGsEf+h+w2RlWnY//+1dvmQsWNFj4Gc777fKWtaD /6edASeFQvdVm9IV03KjRjy+sPynX4CjvwwPKxF7pAjlx/rL9bStgc8z7M5M syrdKBM6gWtXo6XFIn4IT4kz/Q7m3ICJaPOJlkUGUdQSKVvFiEw3yZ4PTBqT n8IqxeVEOErZFqoWMh//pNLUx0H1stdfHfg+gYMPLlcSl1MoC/64XOV++/9p +jDSmJU3fGKcg6eohKvMEoNx65H8hrMhVSfNUFZkjIYCCUH7Sk53rioLoBXu rBS7ZR5C82J9YWHRINLlwnzKKjmOq0MKy1xZbprtOLCbeOh2GGB0Bo6rzWac zAZ7CHniyjjLbTgg9ae6Skss9wjEEmIKXHOq4dwx2Q1+kiszvzru2AvV5BhH 5/8VYLa7vVvMJ0lkFpmFh1BxfR9T8EPqdNSNnr7KlGQGLSN8Pt6oahyPSDBl eUqEG+GiYu5rabx7bQLfnqTpDXX2/n04SdrQMlj2NgZhXeK9aeaaJm4H9q+p ZjPtZ2NEB/a3k/SpouGEoMwsQL7B3LSfdPbUATlksccx2odlcNcPsJcb7xXj aeixnHChvZwH0Vk+EMI7T4A1V3WKy4lbclP+42BEbk1g7PCzevWrKCEHljxf oq35+xdGW+LBB70ktMqcougOIhrr8LlkhyGPypXghI9i6+yegVvU9vmzG3YQ JBypGSu4q3dHkcxTdJblcpxHOR2uCC2JOl7b5kMiHXO0/4hSER5zaxR+FHv5 eVWp/0UxH361tXarll7+gFMLpPVQ55BIEv22xy99Ytu+l8z92WyA345IUeqV nzCCqm2n1opszkyCjrCZIKdQ3jRk/a8Jv+cENSe3DCpryE1Bn4zj1c73/nbA vI2J8J+u7xYP8eWdnlQBsRf9hQUlW+Qg0PmfR7tqzQARJ3y5h4S6/hepcB0L SmyMt/edejAShzFqZ40nMr0lVh3bbl9ignekShHRs9vMZTRL4ED4Peq0dWqp AledNshmcpUDZAZkEboL2Ldc90At60X/l9E6ZBieih9bciu2WCsOpHIp/JPM lBN6W1fg4F40dZ4fAKLrccPlcLFOKo9Q/JSwZlOnzZhTF9u92+tfOa7aJYKn ol4OT87kJY5wwD5LhMX+TG3hD362Jd+vcsXjp/IOg7+Gib5pVnQvdTSx4zmo 4gB94iyriGb+KHVaX72d6uv03T7iF0KPEE3PSIlmflz7xhUdnuzavP5BIHO8 T+vOeLstgGnCqws2XmT6mfZkGQP3ybL3+VDKD4/usIZy4cpv4IMzHkbxeWey 3Ad71zz0j6G2oEgPuJXj2l5uhtVWYKZpFRtwPaFLcM7tuYkH20McAQS/H4At LHm4vw4a+ZMl4Nxjo3i/4LC2AhStnozlMdUP/pD/umJ+bEqBr6VXI3zQdrYV Xs8aH1j2o/V5YfNJ+9245RI4zr5R9hf0auh/n3CzaEzjb4D9kbKX84dSGbum Hv8ancOQWUESRFqraXxE28KxJ6B9txmr4kI8q3Yv4bRe0hOMN7RJ3hmtcoZE jhe2tbzej5cw3O1Rphkw6hRuL7ijdF3siPlg1Alehvd0CTsE9YaiqJt/Xeew ZC+UQfJDKrkTQEMJPTlZ1KsX8STIGLop0Gwj2mt6lHSvHWZRv0mB42vW5Hp7 SiJkpY/IBdnUy/1rA5nUO8FrjnzlAS/hx2SGNon0DKriFPOO5vYDQUkkjF8l NEnsZpO4CNz7fGpLOAmEWDGddendfFc134DH5L68fc/G+MK0u0NNn2hmkDiO tebEWSojKFj+2cdCg8xb4HAIlc5aPBV0vJhq6Lou9AVxXGe7CWiBMDpgWdES NiWpBNqGPhBn4o86Vg0ALQr3HUckKxKGlAmd7hoqxzwaH3k6FeXd32hVrvA5 e9U5nkY83qlT1Kh9Ui2vPEJDE2JLqGHcKe2HkutTgc7StuAUctJmCjE09zRX 06osRk6cq2f6nnKAwrozqNhYe5L8xzMoEj6nqmwvjrV4S1Z3B67+s5CKPuTI sacW3ieEllZ7wU64RUt0r90CmxzGs7AWjn9+23LmatdIhHW5AHgTfAQWdf1k PeBOge99lJeyi3/ecDy74mip+ImZ9iR7yb15/mRP3dUY+Jmyh3d+AJ01Hkbe QCdBCNb9VRv7GG/6vXbtcZF+qD3xf1R+un2SD5VL5e6iYDS93V1a+0SLZxv3 5hlIF0KICs+N93in8UBQGlnJp6gI+8TCIzIXBQ/+PQ1zMUCDOCOrJEFkLBkl usqpUuX7Jp0GrY3RD6RFVzb2LX7F0lV3XpsAxNldaOhAbBUk3tPy/P9s+dZr uHh8kFC1r+hED51Zu6aodE/nkmiCSOx3hnCGo9GyrcsBl/MUb4aOddpxO3ia kwtsaFlq6A5WUJ5Z32OrgzdS3FEmldKlhueKazTt3OmTS/2OihCjOHwNdkia RBABSIximFpnF/+GB6bazN3aGHD4HOH4eLKz2x/kA+Ld6hhCh8BiB9jWHRsW Y6rBC3IE7dD/GXG22gDzgrMV4EU6XwIi1c3SP1RJsBNU8ZRKRSfTgtUdnAbc KdxCHSGXRBg13GntNgL3BYe5AP+3iC1BcIukOkLOw5RMoamQMdnAh2FUt9IS tG6C3nGVPyI+jmw0nXtm3Oz0v2xoXeLl99YzjfiCWfvyuHWVPl4N/sjc/D6r /7ntEPfTknQmyyHhFGufqQkuXvxXz8I8iZ1JPp0h9n0GM/R4Swf3hwfhJBjr brua5v5RqNd2MjL779F/uqrPlryQpasA9Of0+ufTbvsNz/IIAkYpKcus0adW 8vQmEO7zvo3spV7wFgK/AM+tEkFL+HMUsXYsz+swezbA3elFx8lK4YoGs5L6 ZITJv2hMOh1DXJEQVop83PFaxqJoHLJWCMSj9Axg26ngS2J6Mwd8dEhTxVtf vs+QCteV09lIZXI1BQY5ZmTKr772BCP25rnO8X3OXt24uihJ99zmJt7x5fZk 4dt4fcRymqJ32CfTbZSC6k1CKO0j3COIp+ZhNeI6x9fOCd+XNUzTq9q+Bq8t VKnOM5z4qbcS30MgDh43uQ9i4jnWn5Mm6DZ/PcVs7X9qUB/xdiUvSyBagL6E uguT6HTyg88vsHlf9fTaKDNpifjHTvwNKsjvvwbO4fT0WlStGFB/WvkcoTBW ttV/Iyftoz+vHy57dR3010EUdnUZ6/YOwXcSD0BVZot8+c9HETO17c+hAw8/ e8nqttePBpjjSZq5fn6JLB0KnjSUEOs6CmRZUVOoNUwJ1wLvvDyVt/Bd+beU e7n+qZHrf48Xgge6NrIagDgzSiAvq7pHYOUFQwKJe2PkD7xDnmvLZ8xQsX4F qh6+kkDLfDPpMRsN1F7CTp8OChRu42CTDXRzfWX/shtfDKiQ7JNzvL0B9zJR Cw3w59KJjcpbfV+UBAddCoNn4BW9Mv5Ld5yiXMtHoHHB96TsPRRbZ6l659f7 dod/2GG3JNJ1qFC2TBUxe5U6FKJ5VHKWSl2tf8S19pZPGpDJnqPya//F+ELP sh+dgvpnh5EkhZ09rm8I0QENDOTj9vQ8PvWDQoXdZRTesXA8s2WXzIq+00FS eXOurgO83KeyMHe+JbySi0LcBA0UfaLfOicqZ+AiOpXQ1SeDJdB1FcoZOxP4 aSqqZ3UdAx5D6Y3kxC2/Nl3WYmqBGqzmffGqaBJKKiKZkoqn3D7aBhi9Fbqd fC94UZFURuDo1iyHO6GN+TyV5Di+Vo7paWO1QBcXfRdN60atXNBSkn7XoZH7 phxIEuIlK9uHLiKXnYQr2Bl9puJ3aatEwMZnTTPu9DgvgN2Z4yXve7BAUPTG ipIzM51gyygpLz5hcXtbu+uzWAZ2PpwbDJ1PmAskZzxDjHWaBDIwTKv3Enn6 eluFHxMF3dKDQ4M/CbT8AIulX3a2Yv8saROIMnHjH5o7uAoLk1l+UZZrZ1RM DJGJSn9DyWA37Yrgl1X+ccs12TUFthhdas+lv1Xj5zydqMp1DSeG5HRGZfe+ tDNvIe7mcThB9TIfxY2pxcCg3nb7XX4rmMpoCVIpnLzjOVND241BmTrMgED4 hfsWlnLxZI5gnRS4hpMwOl0cUq2MsOw0OIuYlo2LDEh4lJwbqRawik7dSO7q wqqBoSMp5LOd5MQk6S9zXz94Oy/lN/aJZ7iBjxUf6nIr6IWsXytiwZLJzS9r 2jGpOiTCNjLYH633O+XPpxdhyJe6JIjj6PXFEsjiJR8M8ItW3QUOgXfC1TK+ 9ATkcuV5lFHvwe2RX0qxb6VcBW2ey45H3UDoM+XjY83hZ0uFeH7SZPaKWsZl tADy1IMCXxfydg2u/S8bu0disBMtz7oUMY4kwD/pnEFN5OohgyUycTuHrf9M fIFOlFxY2Q5aMmidjkVbD9JTPcDxuAsVrbhSkx7kBdN3UUUcRJXybn95vKvS eY79G5VvdoFOQL/O+FHOt0CrG5lsy8MiHNxIbrwi8LP8u0PXbTzp+3wm8UeK yTHRAFWHMbVd7/8qOPX/0W/58fUPuIh4aepT9gLmZrcJ9+XK5qfgfy9K7CMY d3g8v9dW3yT/M90fWBbd5lKVOfotf6BrPczRLth9gVVZf9WDe/TqjR2zTT3D gBYcldfKLa8pKFvq8tFK+ckZ4VJzXyK9oxU8EDY0DRsiqc+NE5d1yrnhx8RJ Hdm//YHIzjc13TT+8RvXou/WVJ4gibxxd6MZqUvGPecH0rkPWQTXR/Upfls4 O2WdvWTyRNgja1a8/jDoqzfNDLGzhLfX7B7fPv0kgSZCP+9txC6oVoJyG9TT vPvMIKXrAKZCXKhKIaX8A8Yxs1b1+WMuai/an0dP+GSGdq40f17kUUiLL3M1 T2ba+V/0s7SeSkK3F0D/sJ20DBARRvzx6rXuJCBGn5n1dX4rbGEJA5RHTpch 2gyz7waaGYWmeIVOJkuIEqk8+pPplx2dwPA+MHtJB3z1hXSTdSP5pxz57yf0 OGLDOJ7ZXvaQl62j+dW5jA2BpMbQIVkhcNb25VBUC1717FJzKm7gdWk8402J HucDOK/t85cZzHwXXJx1xT+X2yPnDgzJnrctt8sTgQK4FW+58jf4RDeG5xcl gz2s4uWSfqDbV+e6nT9v9YGjNGuPixHCmEtt3pQ91WSeuTYAFh3c51tOwDqB BxcHW9kF5/bBSgGt6XIkMbf6IUe9tCUIH39z4/0o13mFbDgkmWLKu+B2ox1N D9vMlgebDi+KkZEZIDCZuZBtRnpXQwu1eV82iqrKFUcYZU0eHO9AXNg5+LQN pGpCasu/3Ljj4UkO7YoK/OErMpBMQcuNXCxzOAHvpPkcnxmnKCLSqpYlcjQV k2+QDA95i/q7AeubrYbq8Hdewl5LP4u1fIVCJ+B/mdtMMpmLziYUudyk7SCZ fwfu4bNoj2WD+UdeVl1Os8IYjF1InUP81uayJpKVe8dxBHk7HTdj6tGiCso3 dHHmBjjKKVViAbNbxaOCQk7m9RAWl6AoMdB2FETrEmYN0aY1779kWYmE4LEZ 6nLVJdAO/bsz2kDiKcFm3mE8o1uF3p47W6LhmsA60CatJTL4XE7rn33C1nkz +u0dDDpx71T9xkwZw1209XVJeImzvCLBkF02vz4HZ2wFdvsuSzU+Jx3NkNan kCBlvahvk73NhgcuBAeGzA1jEV3Eg58cffGhDi/UVyCQgdbsZxbHPJhaPB2i ZPz89x6PcFyJ4kXBxkWFVARv8zzhfwn+360QO1RejK2OH2VR6QDLQJt173FE 2BuxbQ0DNutO0+Pxr94+8GilQkve/ODz+jQ6Ss95SiKY2F26uZo6lYxHT4sQ KrFNb6Jl/nsi2TV59HTF0iUBeQPw9/ZHI4nJRRDrbc0dQPBCmCloOgVXOXzy NiFUyf7pXuqQpg9HfDHMcZO6RCt+cNIkyNRSOOFiUbWoFt9BJsQYgx5K/Eog 6Texe5xClZQJzBPXVSYd6WD0+U9goV3pVsHUo8+/K7TA1Bw36ljdDmc7VTLy bjy2MSf1vwyvT8EGCuWfdvP4XC4QxR4iMZ+MxOmCp9GZse64l9AP0b9eSc5y ZAD1PpZTWUEbX2ClSBZ6W1oWPHHfvJn9or34A40wyD6MUfupNp1+kMr6W0CZ 7wxxz94nFAIu1dN3fxyyIJYpUJqTPzJzDzW6Kk3MRAVH7fV2db8RixPgl2rb 34Y5BS17dIpmKXCmXnHzvPoiM54IfH856s6zxXqpfYshlvw8Z4ZeFvBY593P SxHMWoeM4JTTyEyF3wiPKws6JVspd+89rtHPm5at0YK5BRT4hUj6czOxXpOC pNRmum+ZEWwPLESEibficg7/gs8YHb2vrpgGXT4xe8KrfgWCLDx6uwP0hCJF rqKfkIwklOQ48kWcRn6gho3JRj5SJDBfcDGWYy1FHQxhnjy04yY+jpVNMo0M scgadsaxnyj/zSnJf5kRTENSRT9yR2pJlj417iD9Uw0ZvMCk/P8eGFFMour/ AfxriX6utmCz9VFq5IiomcQilYhYeU8dR4U9ArJYdcby046a10BfPF9EmWmx biasZ1Tvlr/cfYZ9uTv/CRHTXlVxSq3MRyiwy65EK7ApsFORC7Ebw3OLuUmD gfkfROKfvwaXYjyQQ+EZ1L/V+0qKIh4rRyUb1h4842YSRWx3/Av/fcSRZZy2 LfXAR7ms5kl7+uyhSg8YihKbXcd3GDOH37sjSSHGe/3ZbJHDG/xaq/RZC4Yp qo4Rxzf5I9zqOcRcL4M7pnBRFQv5vXE51Js4SzjbOuupO+2/uMJJRIf/bqNK sLPKf/y6gi+7Kkk4Yn+9zKs5jH6OfZIp+uUiKcVrCmCSgcXuCyJ3uzh/yOtC 9E72zypfubUnpSoWxwKfuQIKVOmpjY4ydyF1mAp5ditaknyj3gbqAfglbTGx owyyhJT2RQ5HKJQ3KyNR40eGEJRAcXv2jM+TRrdCiUJvTiNcWGufEKA6IXqy 9ND81KTYQKdOs8uyI6o6Mhvjf97Mw6jvBNme5Jra8vKVAKat0DfrPa4tu7dI t6fYpT1rRSgwuQn/Xs7U3FxRilkV65WHGSnS23zDjK01LZq78ogNfFZdrqTL IciWoxhWhIeNcSiZ5xgl1CVXqn7slYEaG5+RQEjBH6bzDvnNBO55ElrG6ldZ O1uulbgI9+qdUUwx4PBMxKeLgZXgBEH9yDgN4RnBG8/BE3NdaUcK4gOUemtk L5pkAJEMaW/PJVA3FNF974P3T7BnkKl/2ZYzHe0Yl/YTEPi8ri/HkSQ9RNTq BC5kEQEBwCrnjZI98CEa2AmKPQkCQsvsREuFxpKAHRb9Z80EtZTQMH4YjjWp pZgurPaq3mlOpsNaqWdwYw6dkGSPibxfT/OIAhkE6Oei87uRIxZmypETKm79 Q4M2LjeSlx5QoCNad1CWHqNfTfCZ+TghRHDbvHspdSFQQuEQgE9WN/ykTi+T UN4zr3a0/DkTICAs4JDoYGpMCNVXxyQTpqnu/LkR7cSWUn6dB7gqQDuC8N1N C6nIk3/OCJ78KWtBIK4GfXllvEEyKhAabPx623JkIsU+EUNnGVSiThMXm/vd pEB/n4axRtDZyEAzss3D/FzrFIEeu9G7T4ev7ww1y/ieONTEUCip7dJpGPKs wWEG3j5E1+//UiDJ/DjRcgvgVEAh768Nvfqr/OmD1xj2k2E1GMuu1OG4iUWH y1SOT7xxG9AWFpmi62kVLUA7BGlDkqdcxgp6FpYISlPsqMNRY/GMBLCvxsHV IzhB0O+QSghGmiQ37HCJuY8jEeAqIV3ttdBl/GyDRupy75dtWE4UfjqcErkJ eOA7WHanOiRWVRMBNfQU55dKtY5M/jgmTt/M0YpxIMUQrEppFg6458Z1RNWP 6cNZf1m+0PwC/aOWMYRhJNgziZD1xyJ0WoSw5994bTkh50txrIfyfKANfPk7 g3MKOdQKyoBH7tOOo0XlR4DLOQ5si9GN+FAzZRkr+ljVTtgOd1RGdBAVvV1a JCB8E+Ec1xUaXfYoCIXTlRYCw7gRSOvXWyIHTtlIdRQI7iLhJuRQOZPxxNyI zYA1kIou0CtmbQ5Uyg2a12ZM/g0pRHMIyVbzws2O34QazW1Lbukl38SRo2l2 klfpfVJp/ZywWC/AO6pgzu8GO0sjs2u/56w86Fg+ZVfRa0Ph1f52Sq5rS7l8 WcHdTJ+INXa5E5bARcig2OTDS/CR94kyr6nRR3YEEpEj8cytaWHoPBNDTXPV krCBF5DK1y/tVWwIw9Z0Psj/MRxVqPMZ/3NbrFmkbCW3KjVKIuhS/KKZTAT7 V6796Hl9o38O15Iy1Xcrh94DvCWSnliuQYiM1V890QxvNOFk0D8fGtgsaiL0 MCyqJB5IykZYe+MJje7ui0rheNBQwM1B4hFdvhVESFyS12ie0R1Lv1xQxl1O wQK4YekJeXN/ZOED/zsfcIZxLG56gRx9hWwAys5FIdywrGKr6gQ2vwShc5CK 00LcJxO/CNnSJ8fAh9F6UljeeCEMUo7l/8da7Uc/dQpbKOQK7weQmwWL9mHB lGpcSVSMn3iS9akBJpEarD6A+oiE0R8c8TjJe5XPKaQ8oYSSI9MPl9ID0lGa PUia4bSfHDmYIDJH6FYRTUHngfRGuWV57DRhQW7ArFH13jGjSNreQ0KD5fE8 cB7JAl6eUPu0hBKICIvwUxTBziqDpGnonkDtzTfakVrSfZHtk4Tch+5wKhON NPegkN4An4R3I6Shsxj3GmqupocQVQ/guN7WeyBN/wGTzmPk+9Je8JKEXt+Z +0PjFkrXsqQiK7/ImPyrFLXfPgtcIqxXAfYppzIwZPzu6JA/tW5/iexTMMpJ 6BpRLE01+WuD31XO1gnInLiqIkW9l45UKhIUnmFX6w5tfGxWkubCzRK4JBSh IPqz92EPbupH5jLW3gz3aghEvvjCEe6dCbDy4TDmaPtBTx9PIsdupZWMcpBT D5odqp/k/zIQYhEJWXQkRTGA3m6jdc4sinvOzyGfEc3lO8SdrRNlX0u29ICK +wZQoHof+QcNM5r6mTRFl2ZPN6AFjqJNKdr9xmUKimQeI46yk80I8/d0TKFL aR4WNdN5QcMWy8jRTYab3MWKki8SVMj24Y9ViZ2GRzRzQTQ336gFa/IIlaqk 8f/hY4qHGj6D/YXfmZDkwj3Vff2s1m8hYouqvI3lkvDkyY/DwOKOPBqoD0rR L9tmQuvA6h3G0gVLR3i9N/FEDmxmciI5n7Fdx8hmYPi41xs3F3/czHfJk6MQ Jj1oEKNkEEq6bn/ckbKXVjvd1JtB45jYk+IycbZ7aEKOHmxUjXEGM5R6JeyT z/njO6TMG/ypMQGn3+aexN1LFg1a8HuIl1XDoKZCMdnuB/lfd8ZlS3sh5sQC dWfF6OTDjSEcv82VwxDHv558NkpwVYmFXZCJFIv2XAFqJuWEkb1D0Co1IyAi i29TJS5eUYMZvLMwJJzZzLCkPIaKo3mrCUikUNpUpNQJOQ1wpwzvhmKXi/p/ +IAn824EOghQ9kypdEQRpKfnnVCMqWLPSe+QX0pTq1aN2J2jTZnM/z0sTcND S1MwMdoixFrwS1g+58F+u/tAhLb5RHPRGPCxN4M78srU3fAg8PqsoqEVbQvw JXfKq0VrvZdZL2ls7i5NBxE0sj8/yDzKI/3wRDLtDrcpyEQ+W1RdY5sWjMHS +N9z70qCycMk7KXv1eUJWxNxQmz7cbP+LZmvsTFRlodQEGLjGcucwUEs9umM gTnuDJAJeKTRCpc0hQPCHGsG4QFHp/k5TTRki+P0GDkRO6NFqkR+yO06tfm4 LhSaQKhqQJfNwoTRPwg+aeEKvn+6+ECmA24ELP1sB7n+ILmO+b43GiAmBZ1J O4WSXnkQRA0pirX4mxCAiCnDS3H+F6zVND0rm3CT9iuWPaSHOTUBgRI7ycgP yXdQ3s9B/4Q1n3nF67IkaW8bgnmw+mPOHFuIZUvG2wRUgGDJImnRqQUVlize hVqmYFUpl5v9fZRn3aXBGQSXqr90LtXz2srB6gA0mEGf9Mi84bnZsiXdHvx4 gE8uHyfvKccCA+ql28n0S9Sh8TGC8ipdlXjEMuB3k1xRk+5vx8vo7QgFtDmp HOUvx04Sie/0B4Yaay6vMISEpdq8dz8JUCNsJn2wenXHoYLssGyDcliQI89K 0zRxBWtyPif4bAK9hfNqwLMdleuh217nn9xmMfzLhd9pt10sh0xl9k3Kk92/ THq1+V10q5SlZpEKayX3sBpHpXbLTmYSe8oJsGiPguE3Q5FDi+6eUiG4Ag4y jxyZS9E2Y16aD+8Jzo1zTle9aIMXnkvkUrIx5creVPwvNsRICIVCm16+/Ot2 +olj7Ou+jBIRnNOxJEhqEbmqGHVQhXfe+ECB6/GcwM+C4xLvVPs835QeMfM1 iQjPrEAMpizStpyRHB2Hp9bczC62WFncGRxzyaNhwmKr0XxSqeY0E7aurR8t q560lXgPTHfw89SclkKIkbkomVe6VBPtxUUvyaF9ddb3wYiqYALIm/0B7aws Qg244n2Li4bGtQhLOuB7Vl6UhaZKPEuIIxmWdOY7SZhf9bKRKngYTh8J/uqX cCr6PJN3JlcYoHV3Wamvyx6YBfQrCO0qedOlGcYQiFbgYHeBZw/CAQoiDrxt 8F/nyZUaJqysFZM4Ff/8CIDAI3Tgwex/FTJcODSf1r/lKSc8V4LBZIQQgwNo cTcH0T8LLQrmvJmqmQ/qr6uYnXQkwpDfNiSOFUu2Lgh+u7eyyCjXk50WbT/i eS7rJfPiaMnKv6lyfXSRS+bkx4jjFHEotTXUweLV1cjVubHsBDu7HHWebj0i lAsKs6Dn7Z848YEMYvuPW38pNBOblFv27csPAeudsOu7mO2J/fdptFVFg2Qs CkA5N+51VbqZVAUdDnI/bazNCbHU4T7FBD3oBGxH163PXTBCjnx6mxaOjZqy GQneBs69oqO4h/U4d++hhJY724BeljolZU26jygo8/2uQlclqJ46mZZnzi1r bY7KDeom//5ASJ/JDCIeDOAZvmybNpNDYoRmI3ITOGXpgbZNuwKmhaKY/x/Z WoJhbsgaY5GLCJVYIDsmwKwrTGDITgqzTTlDwm4hBkOJwO75tkzASbix3JCP gCEZDRxy6XK4JNG/voT8++jn0p99JXx3w3ekmXCh3UJXebz6t/UWRi4wsNq6 I+P9ewSZ4C/cSO/rdu57tBiQA+uJn1Hkd+EFQCw522+FOPvt0AXWnb2wH6kC lcuPAb46SveA5Nx6FFsf0lrJY6AGm+Y1h80s6Gdk1HRdfy7zC7cMVD1oNew3 2TEnHVINmGNFrgf/DOa3AfLF3uxNrXqpY0K7jwX9FmIC0E6Gb/MKp2jKS7hu 6E2alkJr3Yat50+5fd4/LWecFoRqLpmn4rQCXfpJ0M1uGYmPF+5Mr8ZSar7V zoqaHoIRV0DDOCFb1kROvwnwulr4BrgMJzgL1crsjaSFSvIwar7PA8jL6xMw eNi3AlaqORUH8VbPvLFPGSDgxEiVdmnb+abnRci6aJqoS3fJXMm9A9k/ZcTh 2bSx273D0eUf7VfleSuYRy15UJF9z21dsyoKzNtQVOeYz1S6zqsFO5pp6I4C OKyqNmLyVCFgQne++nLwkaWOZxmTEJsYVME9N9knVbQLd23Bo0flqD2VFoR2 JX6Ml6HNkGps4CzR1x8Yy0tdjx2vIfyUBhX5NIOHTCLRgfp+9MAD/IDEPXsA QAcA ------------09F4DA9888F4677-- From owner-xfs@oss.sgi.com Mon Jun 23 11:04:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 11:04:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_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 m5NI44XP013822 for ; Mon, 23 Jun 2008 11:04:04 -0700 X-ASG-Debug-ID: 1214244303-6a90004f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34506.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id B710626B686 for ; Mon, 23 Jun 2008 11:05:03 -0700 (PDT) Received: from web34506.mail.mud.yahoo.com (web34506.mail.mud.yahoo.com [66.163.178.172]) by cuda.sgi.com with SMTP id YqB5TFtYvkRM3YJ2 for ; Mon, 23 Jun 2008 11:05:03 -0700 (PDT) Received: (qmail 57381 invoked by uid 60001); 23 Jun 2008 18:05:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=scOail5JW7AZMXEWmKeJb5+v1iqKkZoX0mxJ3g5r08hXwRZ5bu3l4gnhsAZUI6RwmVOO6R2C9l9xBovdvqK4j+XYjH/AKu1JgsUCE6m9LZMnA4G9WtlVcWKUwupfi7S41uuyDLbtZxy3nuh/bvQ3PUMAhEVVC+9P9COAspIb4kQ=; Received: from [96.13.203.1] by web34506.mail.mud.yahoo.com via HTTP; Mon, 23 Jun 2008 11:05:02 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Mon, 23 Jun 2008 11:05:02 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: XFS mkfs/mount options (w/ better results this time) Subject: XFS mkfs/mount options (w/ better results this time) To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <574409.56108.qm@web34506.mail.mud.yahoo.com> X-Barracuda-Connect: web34506.mail.mud.yahoo.com[66.163.178.172] X-Barracuda-Start-Time: 1214244303 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54133 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: 16484 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs I have found that Dbench highlights the differences of various filesystems' throughput, and the results are surprising. (Summary: XFS is the clear winner, under pretty much all circumstances.) The basic test: # dbench -D /tester -t 60 {threads} The primary variable is the filesystem (ext3, XFS, and JFS), with CPU speed and disk elevator being secondary variables. The journal partition is on the first SATA controller, and the main data partition is on the second SATA controller, to exploit SMP capabilities. I'm running on an AMD64-X2 2.5GHz with 2G RAM. My kernel is custom-compiled for 1000Hz task scheduler and forced kernel preemption, including preempting the Big Kernel Lock. Per Martin Steigerwald's earlier advice, I also ran irqbalance (but more on this later). All tests were run in runlevel 1, which on Slackware means 6 VT's but no services (net, mouse, etc.). Aside: 60 seconds may not be a long time to run a disk benchmark, but I found that after about 15 seconds, the disk throughput had leveled off dramatically on my system. In the context of the final numbers, the actual intra-test variation became insignificant. I have kept all test output for review. I created and mounted filesystems with the following options: ext3: no options to mke2fs, so sparse_super,filetype,resize_inode,dir_index,ext_attr were all enabled mounted with "data=writeback" and noatime JFS: mounted with "noatime" XFS: mkfs.xfs -l size=64m,logdev=/dev/sda2,lazy-count=1 -d agcount=8 -f /dev/sdb5 mount -o noatime,logdev=/dev/sda2,logbufs=8 I ran a round of tests using 5 threads, to resemble 1 runnable and 1 waiting on each CPU, plus 1 more waiting. In other words, lightly overloaded. XFS was the clear winner, with 378 MB/sec using the "noop" scheduler. The "deadline" scheduler was a close second, with 371 MB/sec. Here was the first twist: The completely fair queueing (CFQ) scheduler seriously impeded XFS performance, so badly that even "noop" out-performed it when the CPU was running at 40% clock. After I un-mounted the XFS volume, I noticed I was not actually running irqbalance. Oops! It had been running under runlevel 4, but exited when I ran "telinit 1". The IRQs were left in the last "balanced" state, but there was no dynamic re-adjustment for the different conditions. If irqbalance could help the other two filesystems reach 378 MB/sec throughput, why not? So I launched it and continued. Running the same test on JFS gave a comparatively poor result, with 147 MB/sec using the "deadline" scheduler. ext3 was somewhat better, with 279 MB/sec also with "deadline." They didn't get nearly enough help from irqbalance to make a difference in rank. I re-ran all tests with 20 threads, to simulate severe process I/O overloading. Even on my 2-CPU system, XFS scaled somewhat, achieving 403 MB/sec with "deadline" and 401 MB/sec with "anticipatory." CFQ didn't hurt the throughput as much this time, but it still came in last (263 MB/sec). JFS suffered horribly under 20 threads. All throughput fell between 41 and 46 MB/sec, no matter the elevator or the CPU speed. ext3 fared somewhat better, with 256 MB/sec on the CFQ scheduler. Finally, a filesystem that CFQ can help. But it's still not as good as XFS on "deadline." For a final twist, I re-ran the 5-thread tests, but adding "sync" to the mount options. I hand-tuned the elevator according to the best for each filesystem. I ran dbench once, to warm disk buffers, then re-ran and captured the results. Once more, XFS is the hands-down winner: XFS+noop: 65 MB/sec JFS+deadline: 40 MB/sec ext3+CFQ: 37 MB/sec I am very impressed. If you want to see the test script and results for yourself, I can put a tarball on my website and send you the link. My testing may not be perfect, but I find these numbers very difficult to explain by test shortcomings. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Mon Jun 23 11:37:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 11:37:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5NIbjBD016502 for ; Mon, 23 Jun 2008 11:37:46 -0700 X-ASG-Debug-ID: 1214246324-1c9601dc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gir.skynet.ie (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1C467D29B5A for ; Mon, 23 Jun 2008 11:38:44 -0700 (PDT) Received: from gir.skynet.ie (gir.skynet.ie [193.1.99.77]) by cuda.sgi.com with ESMTP id u7x8dbemztD7Gjnq for ; Mon, 23 Jun 2008 11:38:44 -0700 (PDT) Received: from skynet.skynet.ie (skynet.skynet.ie [193.1.99.74]) by gir.skynet.ie (Postfix) with ESMTP id 6A49E1171E; Mon, 23 Jun 2008 19:38:41 +0100 (IST) Received: by skynet.skynet.ie (Postfix, from userid 2391) id 47D4A5035F; Mon, 23 Jun 2008 19:38:41 +0100 (IST) Date: Mon, 23 Jun 2008 19:38:41 +0100 From: Mel Gorman To: Christoph Hellwig Cc: Daniel J Blueman , Christoph Lameter , Linus Torvalds , Alexander Beregalov , Linux Kernel , xfs@oss.sgi.com, david@fromorbit.com X-ASG-Orig-Subj: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Subject: Re: [2.6.26-rc7] shrink_icache from pagefault locking (nee: nfsd hangs for a few sec)... Message-ID: <20080623183840.GA1824@csn.ul.ie> References: <6278d2220806220256g674304ectb945c14e7e09fede@mail.gmail.com> <6278d2220806220258p28de00c1x615ad7b2f708e3f8@mail.gmail.com> <20080622221930.GA11558@disturbed> <20080623002415.GB21597@csn.ul.ie> <20080623072227.GB11986@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20080623072227.GB11986@infradead.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: gir.skynet.ie[193.1.99.77] X-Barracuda-Start-Time: 1214246325 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.54136 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: 16485 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: mel@csn.ul.ie Precedence: bulk X-list: xfs On (23/06/08 03:22), Christoph Hellwig didst pronounce: > On Mon, Jun 23, 2008 at 01:24:15AM +0100, Mel Gorman wrote: > > In that case, have you any theory as to why this circular dependency is > > being reported now but wasn't before 2.6.26-rc1? I'm beginning to wonder > > if the bisecting fingering the zonelist modifiation is just a > > co-incidence. > > I've seen this traces since lockdep was added when running xfsqa. > Oh right, so this isn't even 2.6.26-rc1 as such. It's an older problem that seems to be happening in more cases now, right? At this point, I believe the bisection fingering the zonelist modification was a co-incidence as reclaim behaviour at least is equivilant although catching the memory leak early was a lucky positive outcome. It's still not clear why the circular warning is happening more regularly now but it's "something else". Considering the number of changes made to NFS, XFS, reclaim and other areas since, I'm not sure how to go about finding the real underlying problem or if it can be dealt with in a trivial manner. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab From owner-xfs@oss.sgi.com Mon Jun 23 12:19:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 12:19:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,BODY_SIR_MADAM, RCVD_IN_PSBL 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 m5NJJ9Zs025252 for ; Mon, 23 Jun 2008 12:19:10 -0700 X-ASG-Debug-ID: 1214248809-1ca602590000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ix3.inomial.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2F12411D5D3E for ; Mon, 23 Jun 2008 12:20:09 -0700 (PDT) Received: from ix3.inomial.com (ix3.inomial.com [202.62.137.13]) by cuda.sgi.com with ESMTP id uvawkB6zCG8Sel9q for ; Mon, 23 Jun 2008 12:20:09 -0700 (PDT) Received: by ix3.inomial.com (Postfix, from userid 33) id 765161E44F6; Tue, 24 Jun 2008 04:51:56 +1000 (EST) Received: from 172.16.0.47 (172.16.0.47 [172.16.0.47]) by webmail2.netserv.net.au (Horde MIME library) with HTTP as bundell@netserv.net.au@localhost; Tue, 24 Jun 2008 04:51:55 +1000 Message-ID: <20080624045155.mphmsypr4kkkkwwo@webmail2.netserv.net.au> Date: Tue, 24 Jun 2008 04:51:55 +1000 From: BHP BILLITON PLC Reply-To: karen_wood188@live.com To: undisclosed-recipients:; X-ASG-Orig-Subj: ENQUIRY!!! Subject: ENQUIRY!!! MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Barracuda-Connect: ix3.inomial.com[202.62.137.13] X-Barracuda-Start-Time: 1214248810 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.56 X-Barracuda-Spam-Status: No, SCORE=1.56 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=FROM_HAS_ULINE_NUMS, PLING_PLING, UNDISC_RECIPS X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54136 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.88 UNDISC_RECIPS Valid-looking To "undisclosed-recipients" 0.22 FROM_HAS_ULINE_NUMS From: contains an underline and numbers/letters 0.46 PLING_PLING Subject has lots of exclamation marks 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: 16486 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: karen_wood18@live.com Precedence: bulk X-list: xfs Dear:Sir/Madam, Our company BHP Billiton Plc Requires international agents. If you think you can handle this position please write back for more information on our enquiry.Best Regards. Karen Wood, Email:karen_wood188@live.com From owner-xfs@oss.sgi.com Mon Jun 23 14:49:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 14:49:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (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 m5NLnRqK009603 for ; Mon, 23 Jun 2008 14:49:27 -0700 X-ASG-Debug-ID: 1214257825-255702750000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4BEC826C772; Mon, 23 Jun 2008 14:50:26 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id 8QQEquZIWuFblS0x; Mon, 23 Jun 2008 14:50:26 -0700 (PDT) Received: from [10.0.0.21] (DSL01.83.171.174.112.ip-pool.NEFkom.net [83.171.174.112]) by mail.lichtvoll.de (Postfix) with ESMTP id EE3FA5ADE7; Mon, 23 Jun 2008 23:46:58 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com, MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options (w/ better results this time) Subject: Re: XFS mkfs/mount options (w/ better results this time) Date: Mon, 23 Jun 2008 23:50:20 +0200 User-Agent: KMail/1.9.9 Cc: xfs@oss.sgi.com References: <574409.56108.qm@web34506.mail.mud.yahoo.com> (sfid-20080623_221540_467113_1C5A2C42) In-Reply-To: <574409.56108.qm@web34506.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806232350.22161.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1214257827 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54148 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16487 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Am Montag 23 Juni 2008 schrieb Mark: > I ran a round of tests using 5 threads, to resemble 1 runnable and 1 > waiting on each CPU, plus 1 more waiting. In other words, lightly > overloaded. XFS was the clear winner, with 378 MB/sec using the "noop" > scheduler. The "deadline" scheduler was a close second, with 371 > MB/sec. > > Here was the first twist: The completely fair queueing (CFQ) scheduler > seriously impeded XFS performance, so badly that even "noop" > out-performed it when the CPU was running at 40% clock. [...] > I re-ran all tests with 20 threads, to simulate severe process I/O > overloading. Even on my 2-CPU system, XFS scaled somewhat, achieving > 403 MB/sec with "deadline" and 401 MB/sec with "anticipatory." CFQ > didn't hurt the throughput as much this time, but it still came in last > (263 MB/sec). Thats interesting. I was curious and thus switched from cfq to deadline scheduler during parallel I/O workload on my ThinkPad T42 (aptitude upgrade / kmail receiving mails from POP3 account). It subjectively feeled way faster with deadline. I always wondered about the slowness of my ThinkPad T42 at massive parallel I/O. Now it feels a lot more responsive. Its as if I bought a new super-seek harddisk or what (compared to before). I think I will try deadline for some days at least, also on my ThinkPad T23 and on my workstation at work. No objective performance measurements yet. ;) And not much time for them either. Have I/O schedulers been tested against different filesystems before? Maybe the default I/O scheduler cfq isn't the best one for XFS, but only for ext3? Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Mon Jun 23 15:09:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 15:09:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5NM9PQv012227 for ; Mon, 23 Jun 2008 15:09:25 -0700 X-ASG-Debug-ID: 1214259023-5b3b00770000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4AEF926BF3C for ; Mon, 23 Jun 2008 15:10:23 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id 0mlFfu8gLWMSDi8y for ; Mon, 23 Jun 2008 15:10:23 -0700 (PDT) Received: from [10.0.0.21] (DSL01.83.171.174.112.ip-pool.NEFkom.net [83.171.174.112]) by mail.lichtvoll.de (Postfix) with ESMTP id 71F415ADE7; Tue, 24 Jun 2008 00:06:57 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS mkfs/mount options (w/ better results this time) Subject: Re: XFS mkfs/mount options (w/ better results this time) Date: Tue, 24 Jun 2008 00:10:20 +0200 User-Agent: KMail/1.9.9 References: <574409.56108.qm@web34506.mail.mud.yahoo.com> <200806232350.22161.Martin@lichtvoll.de> (sfid-20080623_235557_453472_F9CE4644) In-Reply-To: <200806232350.22161.Martin@lichtvoll.de> Cc: MusicMan529@yahoo.com MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806240010.20950.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1214259025 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54148 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16488 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Am Montag 23 Juni 2008 schrieb Martin Steigerwald: > Am Montag 23 Juni 2008 schrieb Mark: > > I ran a round of tests using 5 threads, to resemble 1 runnable and 1 > > waiting on each CPU, plus 1 more waiting. In other words, lightly > > overloaded. XFS was the clear winner, with 378 MB/sec using the > > "noop" scheduler. The "deadline" scheduler was a close second, with > > 371 MB/sec. > > > > Here was the first twist: The completely fair queueing (CFQ) > > scheduler seriously impeded XFS performance, so badly that even > > "noop" out-performed it when the CPU was running at 40% clock. > > [...] > > > I re-ran all tests with 20 threads, to simulate severe process I/O > > overloading. Even on my 2-CPU system, XFS scaled somewhat, achieving > > 403 MB/sec with "deadline" and 401 MB/sec with "anticipatory." CFQ > > didn't hurt the throughput as much this time, but it still came in > > last (263 MB/sec). > > Thats interesting. I was curious and thus switched from cfq to deadline > scheduler during parallel I/O workload on my ThinkPad T42 (aptitude > upgrade / kmail receiving mails from POP3 account). > > It subjectively feeled way faster with deadline. I always wondered > about the slowness of my ThinkPad T42 at massive parallel I/O. Now it > feels a lot more responsive. Its as if I bought a new super-seek > harddisk or what (compared to before). It feels like I have a completely different system. Not only on massive parallel I/O. Starting OpenOffice... starting KDE apps... deadline seems to outperform cfq regarding subjectively perceived desktop performance to no end. That difference is absolutely astonishing for me. My ThinkPad *flies* compared to before. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Mon Jun 23 17:10:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 17:10: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.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 m5O0ANkR028885 for ; Mon, 23 Jun 2008 17:10:33 -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 KAA04158; Tue, 24 Jun 2008 10:11:09 +1000 Date: Tue, 24 Jun 2008 10:11:55 +1000 To: "Christoph Hellwig" Subject: Re: REVIEW: Fix CI lookup in leaf-form directories 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: <20080623093718.GA21251@infradead.org> Message-ID: In-Reply-To: <20080623093718.GA21251@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 m5O0AZkR028891 X-archive-position: 16489 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, 23 Jun 2008 19:37:18 +1000, Christoph Hellwig wrote: > On Mon, Jun 23, 2008 at 06:44:58PM +1000, Barry Naujok wrote: >> Along the same lines as the node-form directory patch last week, >> the leaf-form is not handling directory buffers properly and >> locks up. >> >> Instead of comparing buffer pointers, compare buffer block numbers >> and don't keep buffers hanging around. > > Which might be a small performance penalty, but I think that's fine > for the CI lookup case. The worst case performance hit is one extra read when there is a CI match where the data entry in is a different block to the last hash value in the leaf. > The patch looks good to me. > > But one things in the original xfs_dir2_leaf_lookup_int that barely > touched by your patch really irks me: > >> - cbp = NULL; >> - for (lep = &leaf->ents[index], dbp = NULL, curdb = -1; >> + for (lep = &leaf->ents[index], dbp = NULL, curdb = -1, cidb = -1; >> index < be16_to_cpu(leaf->hdr.count) && >> be32_to_cpu(lep->hashval) == args->hashval; >> lep++, index++) { > > I'd really prefer to have not too much rather unrelated bits in the > for loop. In fact the use of the for construct here is more than odd > because there is no such things as a loop variable at all. I think > we'd be much better of in terms of readability with a simple while > loop with where all the initialization is moved out of the loop. > > Probably not for this patch, though.. Too late :) --- a/fs/xfs/xfs_dir2_leaf.c 2008-06-24 10:09:38.000000000 +1000 +++ b/fs/xfs/xfs_dir2_leaf.c 2008-06-24 10:07:30.382990266 +1000 @@ -1321,8 +1321,8 @@ xfs_dir2_leaf_lookup_int( int *indexp, /* out: index in leaf block */ xfs_dabuf_t **dbpp) /* out: data buffer */ { - xfs_dir2_db_t curdb; /* current data block number */ - xfs_dabuf_t *dbp; /* data buffer */ + xfs_dir2_db_t curdb = -1; /* current data block number */ + xfs_dabuf_t *dbp = NULL; /* data buffer */ xfs_dir2_data_entry_t *dep; /* data entry */ xfs_inode_t *dp; /* incore directory inode */ int error; /* error return code */ @@ -1333,7 +1333,7 @@ xfs_dir2_leaf_lookup_int( xfs_mount_t *mp; /* filesystem mount point */ xfs_dir2_db_t newdb; /* new data block number */ xfs_trans_t *tp; /* transaction pointer */ - xfs_dabuf_t *cbp; /* case match data buffer */ + xfs_dir2_db_t cidb = -1; /* case match data block no. */ enum xfs_dacmp cmp; /* name compare result */ dp = args->dp; @@ -1358,9 +1357,7 @@ xfs_dir2_leaf_lookup_int( * Loop over all the entries with the right hash value * looking to match the name. */ - cbp = NULL; - for (lep = &leaf->ents[index], dbp = NULL, curdb = -1; - index < be16_to_cpu(leaf->hdr.count) && + for (lep = &leaf->ents[index]; index < be16_to_cpu(leaf->hdr.count) && be32_to_cpu(lep->hashval) == args->hashval; lep++, index++) { /* ... From owner-xfs@oss.sgi.com Mon Jun 23 18:37:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 18:37:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,SUBJ_ALL_CAPS autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5O1b8q6005255 for ; Mon, 23 Jun 2008 18:37:10 -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 LAA05965; Tue, 24 Jun 2008 11:38:01 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 4B00458C4C3F; Tue, 24 Jun 2008 11:38:01 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 983564 - Message-Id: <20080624013801.4B00458C4C3F@chook.melbourne.sgi.com> Date: Tue, 24 Jun 2008 11:38:01 +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: 16490 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 CI lookup in leaf-form directories Instead of comparing buffer pointers, compare buffer block numbers and don't keep buff Date: Tue Jun 24 11:37:29 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/2.6.x-xfs Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31346a fs/xfs/xfs_dir2_leaf.c - 1.65 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_dir2_leaf.c.diff?r1=text&tr1=1.65&r2=text&tr2=1.64&f=h - Fix CI lookup in leaf-form directories From owner-xfs@oss.sgi.com Mon Jun 23 19:04:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 19:04:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_46,J_CHICKENPOX_47, J_CHICKENPOX_48 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5O24JZ7008152 for ; Mon, 23 Jun 2008 19:04:21 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06575; Tue, 24 Jun 2008 12:05:16 +1000 Message-ID: <48605744.8070400@sgi.com> Date: Tue, 24 Jun 2008 12:09:08 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH 1/2] set minleft in xfs_bmbt_split() Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16491 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs The bmap btree split code relies on a previous data extent allocation (from xfs_bmap_btalloc()) to find an AG that has sufficient space to perform a full btree split, when inserting the extent. When converting unwritten extents we don't allocate a data extent so a btree split will be the first allocation. In this case we need to set minleft so the allocator will pick an AG that has space to complete the split(s). Lachlan --- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c +++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c @@ -1493,12 +1493,20 @@ xfs_bmbt_split( left = XFS_BUF_TO_BMBT_BLOCK(lbp); args.fsbno = cur->bc_private.b.firstblock; args.firstblock = args.fsbno; + args.minleft = 0; if (args.fsbno == NULLFSBLOCK) { args.fsbno = lbno; args.type = XFS_ALLOCTYPE_START_BNO; + /* + * Make sure there is sufficient room left in the AG to + * complete a full tree split for an extent insert. If + * we are converting the middle part of an extent then + * we may need space for two tree splits. + */ + args.minleft = xfs_trans_get_block_res(args.tp); } else args.type = XFS_ALLOCTYPE_NEAR_BNO; - args.mod = args.minleft = args.alignment = args.total = args.isfl = + args.mod = args.alignment = args.total = args.isfl = args.userdata = args.minalignslop = 0; args.minlen = args.maxlen = args.prod = 1; args.wasdel = cur->bc_private.b.flags & XFS_BTCUR_BPRV_WASDEL; From owner-xfs@oss.sgi.com Mon Jun 23 19:11:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 19:11: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.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_45,J_CHICKENPOX_47,J_CHICKENPOX_48 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5O2BWHY009095 for ; Mon, 23 Jun 2008 19:11:35 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA06726; Tue, 24 Jun 2008 12:12:27 +1000 Message-ID: <486058F3.3030305@sgi.com> Date: Tue, 24 Jun 2008 12:16:19 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH 2/2] Restore the lowspace extent allocator algorithm Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16492 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs When free space is running low the extent allocator may choose to allocate an extent from an AG without leaving sufficient space for a btree split when inserting the new extent (see where xfs_bmap_btalloc() sets minleft to 0). In this case the allocator will enable the lowspace algorithm which is supposed to allow further allocations (such as btree splits and newroots) to allocate from sequential AGs. This algorithm has been broken for a long time and this patch restores its behaviour. Lachlan --- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c +++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c @@ -1504,7 +1504,9 @@ xfs_bmbt_split( * we may need space for two tree splits. */ args.minleft = xfs_trans_get_block_res(args.tp); - } else + } else if (cur->bc_private.b.flist->xbf_low) + args.type = XFS_ALLOCTYPE_START_BNO; + else args.type = XFS_ALLOCTYPE_NEAR_BNO; args.mod = args.alignment = args.total = args.isfl = args.userdata = args.minalignslop = 0; @@ -2232,7 +2234,9 @@ xfs_bmbt_newroot( #endif args.fsbno = be64_to_cpu(*pp); args.type = XFS_ALLOCTYPE_START_BNO; - } else + } else if (cur->bc_private.b.flist->xbf_low) + args.type = XFS_ALLOCTYPE_START_BNO; + else args.type = XFS_ALLOCTYPE_NEAR_BNO; if ((error = xfs_alloc_vextent(&args))) { XFS_BMBT_TRACE_CURSOR(cur, ERROR); From owner-xfs@oss.sgi.com Mon Jun 23 19:22:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 19:22:17 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from 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 m5O2MDkX010811 for ; Mon, 23 Jun 2008 19:22:13 -0700 X-ASG-Debug-ID: 1214274192-2cb3021b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 789A512331B6 for ; Mon, 23 Jun 2008 19:23:13 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id EXaJM9S5yoqQhfix for ; Mon, 23 Jun 2008 19:23:13 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A05F5A84083; Mon, 23 Jun 2008 21:23:11 -0500 (CDT) Message-ID: <48605A8E.9070903@sandeen.net> Date: Mon, 23 Jun 2008 21:23:10 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: LinuxRaid , xfs-oss X-ASG-Orig-Subj: md raid1 passes barriers, but xfs doesn't use them? Subject: md raid1 passes barriers, but xfs doesn't use them? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214274193 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.54165 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: 16493 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs So md raid1 is happy to pass down any barrier writes that it sees, but this bit in xfs_mountfs_check_barriers() at mount time: if (mp->m_ddev_targp->bt_bdev->bd_disk->queue->ordered == QUEUE_ORDERED_NONE) { xfs_fs_cmn_err(CE_NOTE, mp, "Disabling barriers, not supported by the underlying device"); mp->m_flags &= ~XFS_MOUNT_BARRIER; return; } winds up with XFS disabling barriers on these devices. However, if this is simply commented out, XFS happily tests barriers, finds that they work, leaves them turned on and all subsequent barrier writes to the device succeed. Perhaps what we have here is a failure to communicate? :) I'm not sure; *should* XFS be looking for a QUEUE_ORDERED tag? Should MD be setting one? Maybe there should be a QUEUE_ORDERED_PASSTHRU flag? Or should XFS just stick with the test write and ignore the flag? I'm not sure of the queue->ordered flag details, but it seems that XFS & md raid1 both try hard to keep barriers in force, and there's a disconnect here somewhere. Thanks, -Eric From owner-xfs@oss.sgi.com Mon Jun 23 19:47:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 19:47:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from 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 m5O2lio2014186 for ; Mon, 23 Jun 2008 19:47:46 -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 MAA07469; Tue, 24 Jun 2008 12:47:40 +1000 Message-ID: <4860604C.4090109@sgi.com> Date: Tue, 24 Jun 2008 12:47:40 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] check for invalid flags in xfs_attrlist_by_handle References: <20080531075829.GA5424@lst.de> <485B431F.2070905@sgi.com> <20080623113946.GA32665@lst.de> In-Reply-To: <20080623113946.GA32665@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16494 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 20, 2008 at 03:41:51PM +1000, Timothy Shimmin wrote: >> Fair enough. >> Actually, I think we only use ATTR_ROOT and ATTR_SECURE for the >> namespace flags. >> So you could probably use: XFS_ATTR_NSP_ARGS >> xfs_attr_leaf.h:#define XFS_ATTR_NSP_ARGS_MASK (ATTR_ROOT | ATTR_SECURE) >> xfs_attr_leaf.h:#define XFS_ATTR_NSP_ARGS(flags) ((flags) & XFS_ATTR_NSP_ARGS_MASK) >> and something like: >> >> if (!XFS_ATTR_NSP_ARGS(al_hreq.flags)) >> return -XFS_ERROR(EINVAL); > > Actually a zero flags is of course valid too. > Ah, that would be why I used the phrase "something like" ;-)) Good pt. > So the check should be & ~(ATTR_ROOT | ATTR_SECURE). I could use > XFS_ATTR_NSP_ARGS_MASK but that would pull in not just xfs_attr_leaf.h > but also xfs_da_btree.h and that needs even more headers.. > > So I propose this simple version: > Cool. I was just thinking about centralising stuff in case we extend the namespaces. But that's fine. I'll check it in... --Tim > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-20 08:17:13.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-23 13:38:17.000000000 +0200 > @@ -470,6 +470,12 @@ xfs_attrlist_by_handle( > if (al_hreq.buflen > XATTR_LIST_MAX) > return -XFS_ERROR(EINVAL); > > + /* > + * Reject flags, only allow namespaces. > + */ > + if (al_hreq.flags & ~(ATTR_ROOT | ATTR_SECURE)) > + return -XFS_ERROR(EINVAL); > + > error = xfs_vget_fsop_handlereq(mp, parinode, &al_hreq.hreq, &inode); > if (error) > goto out; > From owner-xfs@oss.sgi.com Mon Jun 23 21:57:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 21:57:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_47 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 m5O4vj6v002224 for ; Mon, 23 Jun 2008 21:57:46 -0700 X-ASG-Debug-ID: 1214283524-069302a50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from build-svl-1.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F361C26DF90; Mon, 23 Jun 2008 21:58:44 -0700 (PDT) Received: from build-svl-1.agami.com (colo-nat-pool.agami.com [216.218.227.40]) by cuda.sgi.com with ESMTP id lFhRMQSRgHEvWchg; Mon, 23 Jun 2008 21:58:44 -0700 (PDT) Received: from build-svl-1.agami.com (localhost.localdomain [127.0.0.1]) by build-svl-1.agami.com (8.13.7/8.13.7) with ESMTP id m5O4wicG011887; Mon, 23 Jun 2008 21:58:44 -0700 Received: (from dchinner@localhost) by build-svl-1.agami.com (8.13.7/8.13.7/Submit) id m5O4wfB1011885; Mon, 23 Jun 2008 21:58:41 -0700 X-Authentication-Warning: build-svl-1.agami.com: dchinner set sender to dchinner@agami.com using -f Date: Mon, 23 Jun 2008 21:58:41 -0700 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() Subject: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() Message-ID: <20080624045841.GN16257@build-svl-1.agami.com> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <48605744.8070400@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48605744.8070400@sgi.com> User-Agent: Mutt/1.4.2.3i X-Barracuda-Connect: colo-nat-pool.agami.com[216.218.227.40] X-Barracuda-Start-Time: 1214283525 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.54176 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: 16495 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Tue, Jun 24, 2008 at 12:09:08PM +1000, Lachlan McIlroy wrote: > The bmap btree split code relies on a previous data extent allocation > (from xfs_bmap_btalloc()) to find an AG that has sufficient space > to perform a full btree split, when inserting the extent. When > converting unwritten extents we don't allocate a data extent so a > btree split will be the first allocation. In this case we need to > set minleft so the allocator will pick an AG that has space to > complete the split(s). looks good, execpt... > > Lachlan > > --- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c > +++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c > @@ -1493,12 +1493,20 @@ xfs_bmbt_split( > left = XFS_BUF_TO_BMBT_BLOCK(lbp); > args.fsbno = cur->bc_private.b.firstblock; > args.firstblock = args.fsbno; > + args.minleft = 0; > if (args.fsbno == NULLFSBLOCK) { > args.fsbno = lbno; > args.type = XFS_ALLOCTYPE_START_BNO; > + /* > + * Make sure there is sufficient room left in the AG to > + * complete a full tree split for an extent insert. If > + * we are converting the middle part of an extent then > + * we may need space for two tree splits. > + */ > + args.minleft = xfs_trans_get_block_res(args.tp); I'd mention in this comment that transaction reservation needs to take this specifically into account. It is probably also worth adding a matching comment to xfs_iomap_write_unwritten() where the double reservation is done (i.e. explain the magic "<< 1"). Cheers, Dave. -- Dave Chinner dchinner@agami.com From owner-xfs@oss.sgi.com Mon Jun 23 21:59:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 21:59:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 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 m5O4xuQ3002794 for ; Mon, 23 Jun 2008 21:59:57 -0700 X-ASG-Debug-ID: 1214283656-3bca00af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from build-svl-1.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0DF36180E516; Mon, 23 Jun 2008 22:00:56 -0700 (PDT) Received: from build-svl-1.agami.com (colo-nat-pool.agami.com [216.218.227.40]) by cuda.sgi.com with ESMTP id pZVSzXTmS3J1SsMs; Mon, 23 Jun 2008 22:00:56 -0700 (PDT) Received: from build-svl-1.agami.com (localhost.localdomain [127.0.0.1]) by build-svl-1.agami.com (8.13.7/8.13.7) with ESMTP id m5O50u6u011915; Mon, 23 Jun 2008 22:00:56 -0700 Received: (from dchinner@localhost) by build-svl-1.agami.com (8.13.7/8.13.7/Submit) id m5O50ufZ011914; Mon, 23 Jun 2008 22:00:56 -0700 X-Authentication-Warning: build-svl-1.agami.com: dchinner set sender to dchinner@agami.com using -f Date: Mon, 23 Jun 2008 22:00:56 -0700 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH 2/2] Restore the lowspace extent allocator algorithm Subject: Re: [PATCH 2/2] Restore the lowspace extent allocator algorithm Message-ID: <20080624050056.GO16257@build-svl-1.agami.com> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <486058F3.3030305@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <486058F3.3030305@sgi.com> User-Agent: Mutt/1.4.2.3i X-Barracuda-Connect: colo-nat-pool.agami.com[216.218.227.40] X-Barracuda-Start-Time: 1214283657 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.54176 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: 16496 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Tue, Jun 24, 2008 at 12:16:19PM +1000, Lachlan McIlroy wrote: > When free space is running low the extent allocator may choose to > allocate an extent from an AG without leaving sufficient space for > a btree split when inserting the new extent (see where > xfs_bmap_btalloc() sets minleft to 0). In this case the allocator > will enable the lowspace algorithm which is supposed to allow further > allocations (such as btree splits and newroots) to allocate from > sequential AGs. This algorithm has been broken for a long time > and this patch restores its behaviour. Looks ok to me. Perhaps add a comment to the definition of xbf_low that explains what it is used for so it doesn't get broken again in future? Cheers, Dave. -- Dave Chinner dchinner@agami.com From owner-xfs@oss.sgi.com Mon Jun 23 22:17:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 22:17:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, 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 m5O5HFrv005572 for ; Mon, 23 Jun 2008 22:17:18 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA09978; Tue, 24 Jun 2008 15:18:11 +1000 Message-ID: <4860847B.7070703@sgi.com> Date: Tue, 24 Jun 2008 15:22:03 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() References: <48605744.8070400@sgi.com> <20080624045841.GN16257@build-svl-1.agami.com> In-Reply-To: <20080624045841.GN16257@build-svl-1.agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16497 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Tue, Jun 24, 2008 at 12:09:08PM +1000, Lachlan McIlroy wrote: >> The bmap btree split code relies on a previous data extent allocation >> (from xfs_bmap_btalloc()) to find an AG that has sufficient space >> to perform a full btree split, when inserting the extent. When >> converting unwritten extents we don't allocate a data extent so a >> btree split will be the first allocation. In this case we need to >> set minleft so the allocator will pick an AG that has space to >> complete the split(s). > > looks good, execpt... > >> Lachlan >> >> --- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c >> +++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c >> @@ -1493,12 +1493,20 @@ xfs_bmbt_split( >> left = XFS_BUF_TO_BMBT_BLOCK(lbp); >> args.fsbno = cur->bc_private.b.firstblock; >> args.firstblock = args.fsbno; >> + args.minleft = 0; >> if (args.fsbno == NULLFSBLOCK) { >> args.fsbno = lbno; >> args.type = XFS_ALLOCTYPE_START_BNO; >> + /* >> + * Make sure there is sufficient room left in the AG to >> + * complete a full tree split for an extent insert. If >> + * we are converting the middle part of an extent then >> + * we may need space for two tree splits. >> + */ >> + args.minleft = xfs_trans_get_block_res(args.tp); > > I'd mention in this comment that transaction reservation needs to > take this specifically into account. How would transaction reservation take this into account? Are you implying they could do something different if they knew about this fix? > It is probably also worth > adding a matching comment to xfs_iomap_write_unwritten() where > the double reservation is done (i.e. explain the magic "<< 1"). > Will do. From owner-xfs@oss.sgi.com Mon Jun 23 22:24:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 22:25:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,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 m5O5OvlJ006863 for ; Mon, 23 Jun 2008 22:24:59 -0700 X-ASG-Debug-ID: 1214285157-466500e50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from build-svl-1.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C91B11BA699F; Mon, 23 Jun 2008 22:25:57 -0700 (PDT) Received: from build-svl-1.agami.com (colo-nat-pool.agami.com [216.218.227.40]) by cuda.sgi.com with ESMTP id 2he0IVBFpMZp7g1X; Mon, 23 Jun 2008 22:25:57 -0700 (PDT) Received: from build-svl-1.agami.com (localhost.localdomain [127.0.0.1]) by build-svl-1.agami.com (8.13.7/8.13.7) with ESMTP id m5O5PucV012097; Mon, 23 Jun 2008 22:25:57 -0700 Received: (from dchinner@localhost) by build-svl-1.agami.com (8.13.7/8.13.7/Submit) id m5O5Puoc012096; Mon, 23 Jun 2008 22:25:56 -0700 X-Authentication-Warning: build-svl-1.agami.com: dchinner set sender to dchinner@agami.com using -f Date: Mon, 23 Jun 2008 22:25:56 -0700 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() Subject: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() Message-ID: <20080624052556.GR16257@build-svl-1.agami.com> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <48605744.8070400@sgi.com> <20080624045841.GN16257@build-svl-1.agami.com> <4860847B.7070703@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4860847B.7070703@sgi.com> User-Agent: Mutt/1.4.2.3i X-Barracuda-Connect: colo-nat-pool.agami.com[216.218.227.40] X-Barracuda-Start-Time: 1214285157 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.54178 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: 16498 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Tue, Jun 24, 2008 at 03:22:03PM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: > >On Tue, Jun 24, 2008 at 12:09:08PM +1000, Lachlan McIlroy wrote: > >>The bmap btree split code relies on a previous data extent allocation > >>(from xfs_bmap_btalloc()) to find an AG that has sufficient space > >>to perform a full btree split, when inserting the extent. When > >>converting unwritten extents we don't allocate a data extent so a > >>btree split will be the first allocation. In this case we need to > >>set minleft so the allocator will pick an AG that has space to > >>complete the split(s). > > > >looks good, execpt... > > > >>Lachlan > >> > >>--- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c > >>+++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c > >>@@ -1493,12 +1493,20 @@ xfs_bmbt_split( > >> left = XFS_BUF_TO_BMBT_BLOCK(lbp); > >> args.fsbno = cur->bc_private.b.firstblock; > >> args.firstblock = args.fsbno; > >>+ args.minleft = 0; > >> if (args.fsbno == NULLFSBLOCK) { > >> args.fsbno = lbno; > >> args.type = XFS_ALLOCTYPE_START_BNO; > >>+ /* > >>+ * Make sure there is sufficient room left in the AG to > >>+ * complete a full tree split for an extent insert. If > >>+ * we are converting the middle part of an extent then > >>+ * we may need space for two tree splits. > >>+ */ > >>+ args.minleft = xfs_trans_get_block_res(args.tp); > > > >I'd mention in this comment that transaction reservation needs to > >take this specifically into account. > How would transaction reservation take this into account? Are you > implying they could do something different if they knew about this > fix? No, I'm implying that the transaction reservation better be correct. i.e. anywhere that unwritten extent conversion can take place needs to supply a reservation of enough blocks to allow a double split to occur. i.e. we are relying on the caller to get this right, so we need to ensure that a comment explaining the potential landmine is present.... Cheers, Dave. -- Dave Chinner dchinner@agami.com From owner-xfs@oss.sgi.com Mon Jun 23 23:12:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 23:12: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.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, 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 m5O6C22k013017 for ; Mon, 23 Jun 2008 23:12:03 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA10979; Tue, 24 Jun 2008 16:12:58 +1000 Message-ID: <48609152.7050208@sgi.com> Date: Tue, 24 Jun 2008 16:16:50 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() References: <48605744.8070400@sgi.com> <20080624045841.GN16257@build-svl-1.agami.com> <4860847B.7070703@sgi.com> <20080624052556.GR16257@build-svl-1.agami.com> In-Reply-To: <20080624052556.GR16257@build-svl-1.agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16499 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Tue, Jun 24, 2008 at 03:22:03PM +1000, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Tue, Jun 24, 2008 at 12:09:08PM +1000, Lachlan McIlroy wrote: >>>> The bmap btree split code relies on a previous data extent allocation >>>> (from xfs_bmap_btalloc()) to find an AG that has sufficient space >>>> to perform a full btree split, when inserting the extent. When >>>> converting unwritten extents we don't allocate a data extent so a >>>> btree split will be the first allocation. In this case we need to >>>> set minleft so the allocator will pick an AG that has space to >>>> complete the split(s). >>> looks good, execpt... >>> >>>> Lachlan >>>> >>>> --- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c >>>> +++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c >>>> @@ -1493,12 +1493,20 @@ xfs_bmbt_split( >>>> left = XFS_BUF_TO_BMBT_BLOCK(lbp); >>>> args.fsbno = cur->bc_private.b.firstblock; >>>> args.firstblock = args.fsbno; >>>> + args.minleft = 0; >>>> if (args.fsbno == NULLFSBLOCK) { >>>> args.fsbno = lbno; >>>> args.type = XFS_ALLOCTYPE_START_BNO; >>>> + /* >>>> + * Make sure there is sufficient room left in the AG to >>>> + * complete a full tree split for an extent insert. If >>>> + * we are converting the middle part of an extent then >>>> + * we may need space for two tree splits. >>>> + */ >>>> + args.minleft = xfs_trans_get_block_res(args.tp); >>> I'd mention in this comment that transaction reservation needs to >>> take this specifically into account. >> How would transaction reservation take this into account? Are you >> implying they could do something different if they knew about this >> fix? > > No, I'm implying that the transaction reservation better be correct. > i.e. anywhere that unwritten extent conversion can take place needs > to supply a reservation of enough blocks to allow a double split to > occur. i.e. we are relying on the caller to get this right, so we > need to ensure that a comment explaining the potential landmine is > present.... Okay. With the change above we can still have xfs_bmbt_split() fail to allocate btree blocks if it cannot find a single AG with enough free space. Although in my testing I haven't seen it fail yet. We really don't want to fail here because we have already partly modified the extent btree (ie for the case where we convert the middle part of an unwritten extent we do an xfs_bmbt_update before the insert) and we dont undo the damage. Also a failure to allocate in xfs_bmbt_split() will be caught by the XFS_WANT_CORRUPTED_GOTO() in xfs_bmbt_insert() and the error set to EFSCORRUPTED which is only going to create confusion. I have another patch that allows xfs_bmbt_split() and xfs_bmbt_newroot() to fall back to the lowspace algorithm - I'm just testing it now. From owner-xfs@oss.sgi.com Mon Jun 23 23:24:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 23:24:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_47 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 m5O6Oqei014927 for ; Mon, 23 Jun 2008 23:24:52 -0700 X-ASG-Debug-ID: 1214288751-7638012d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from build-svl-1.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 887F3D2CF75; Mon, 23 Jun 2008 23:25:51 -0700 (PDT) Received: from build-svl-1.agami.com (colo-nat-pool.agami.com [216.218.227.40]) by cuda.sgi.com with ESMTP id p1AYK5KsMryS3HBj; Mon, 23 Jun 2008 23:25:51 -0700 (PDT) Received: from build-svl-1.agami.com (localhost.localdomain [127.0.0.1]) by build-svl-1.agami.com (8.13.7/8.13.7) with ESMTP id m5O6PpNu013001; Mon, 23 Jun 2008 23:25:51 -0700 Received: (from dchinner@localhost) by build-svl-1.agami.com (8.13.7/8.13.7/Submit) id m5O6Pp1o013000; Mon, 23 Jun 2008 23:25:51 -0700 X-Authentication-Warning: build-svl-1.agami.com: dchinner set sender to dchinner@agami.com using -f Date: Mon, 23 Jun 2008 23:25:51 -0700 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() Subject: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() Message-ID: <20080624062551.GU16257@build-svl-1.agami.com> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <48605744.8070400@sgi.com> <20080624045841.GN16257@build-svl-1.agami.com> <4860847B.7070703@sgi.com> <20080624052556.GR16257@build-svl-1.agami.com> <48609152.7050208@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48609152.7050208@sgi.com> User-Agent: Mutt/1.4.2.3i X-Barracuda-Connect: colo-nat-pool.agami.com[216.218.227.40] X-Barracuda-Start-Time: 1214288752 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.54181 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: 16500 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Tue, Jun 24, 2008 at 04:16:50PM +1000, Lachlan McIlroy wrote: > Dave Chinner wrote: > >On Tue, Jun 24, 2008 at 03:22:03PM +1000, Lachlan McIlroy wrote: > >>Dave Chinner wrote: > >>>On Tue, Jun 24, 2008 at 12:09:08PM +1000, Lachlan McIlroy wrote: > >>>>The bmap btree split code relies on a previous data extent allocation > >>>>(from xfs_bmap_btalloc()) to find an AG that has sufficient space > >>>>to perform a full btree split, when inserting the extent. When > >>>>converting unwritten extents we don't allocate a data extent so a > >>>>btree split will be the first allocation. In this case we need to > >>>>set minleft so the allocator will pick an AG that has space to > >>>>complete the split(s). > >>>looks good, execpt... > >>> > >>>>Lachlan > >>>> > >>>>--- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c > >>>>+++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c > >>>>@@ -1493,12 +1493,20 @@ xfs_bmbt_split( > >>>> left = XFS_BUF_TO_BMBT_BLOCK(lbp); > >>>> args.fsbno = cur->bc_private.b.firstblock; > >>>> args.firstblock = args.fsbno; > >>>>+ args.minleft = 0; > >>>> if (args.fsbno == NULLFSBLOCK) { > >>>> args.fsbno = lbno; > >>>> args.type = XFS_ALLOCTYPE_START_BNO; > >>>>+ /* > >>>>+ * Make sure there is sufficient room left in the AG to > >>>>+ * complete a full tree split for an extent insert. If > >>>>+ * we are converting the middle part of an extent then > >>>>+ * we may need space for two tree splits. > >>>>+ */ > >>>>+ args.minleft = xfs_trans_get_block_res(args.tp); > >>>I'd mention in this comment that transaction reservation needs to > >>>take this specifically into account. > >>How would transaction reservation take this into account? Are you > >>implying they could do something different if they knew about this > >>fix? > > > >No, I'm implying that the transaction reservation better be correct. > >i.e. anywhere that unwritten extent conversion can take place needs > >to supply a reservation of enough blocks to allow a double split to > >occur. i.e. we are relying on the caller to get this right, so we > >need to ensure that a comment explaining the potential landmine is > >present.... > > Okay. With the change above we can still have xfs_bmbt_split() fail > to allocate btree blocks if it cannot find a single AG with enough > free space. Although in my testing I haven't seen it fail yet. Sure, but at that point you've most likely got a real ENOSPC condition. > We really don't want to fail here because we have already partly > modified the extent btree (ie for the case where we convert the middle > part of an unwritten extent we do an xfs_bmbt_update before the insert) > and we dont undo the damage. Yes, but lets deal with one problem at a time ;) > Also a failure to allocate in > xfs_bmbt_split() will be caught by the XFS_WANT_CORRUPTED_GOTO() in > xfs_bmbt_insert() and the error set to EFSCORRUPTED which is only going > to create confusion. For whom? Log an error message when allocation fails if you're worried that we won't be able to determine what went wrong... > I have another patch that allows xfs_bmbt_split() > and xfs_bmbt_newroot() to fall back to the lowspace algorithm - I'm > just testing it now. Cool - that should solve the corner cases you mention above... Cheers, Dave. -- Dave Chinner dchinner@agami.com From owner-xfs@oss.sgi.com Mon Jun 23 23:43:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 23:43:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5O6hnpS017271 for ; Mon, 23 Jun 2008 23:43:51 -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 QAA11650; Tue, 24 Jun 2008 16:44:44 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 9A07E58C4C3F; Tue, 24 Jun 2008 16:44:44 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 981526 - XFSQA - Add CI test Message-Id: <20080624064444.9A07E58C4C3F@chook.melbourne.sgi.com> Date: Tue, 24 Jun 2008 16:44:44 +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: 16501 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 Add CI stat/create/unlink test for multiple directory forms Date: Tue Jun 24 15:46:26 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31347a xfstests/src/genhashnames.c - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/genhashnames.c - Generate filenames with the same hash value xfstests/src/Makefile - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/Makefile.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h - Add genhashnames target xfstests/src/nametest.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/src/nametest.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h - Add case-changing option From owner-xfs@oss.sgi.com Mon Jun 23 23:50:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 23:50:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5O6oKFI018342 for ; Mon, 23 Jun 2008 23:50:22 -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 QAA11872; Tue, 24 Jun 2008 16:51:16 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 34BBA58C4C3F; Tue, 24 Jun 2008 16:51:16 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: PARTIAL TAKE 981526 - XFSQA - Add CI test Message-Id: <20080624065116.34BBA58C4C3F@chook.melbourne.sgi.com> Date: Tue, 24 Jun 2008 16:51:16 +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: 16502 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 Add CI stat/create/unlink test for multiple directory forms Date: Tue Jun 24 16:50:22 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31348a xfstests/188 - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/188 xfstests/188.out - 1.1 - new http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/188.out - Do CI stat/create/unlink test for multiple directory forms xfstests/group - 1.121 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/xfstests/group.diff?r1=text&tr1=1.121&r2=text&tr2=1.120&f=h - Add test 188 From owner-xfs@oss.sgi.com Mon Jun 23 23:58:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 23:58:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53 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 m5O6wira019551 for ; Mon, 23 Jun 2008 23:58:44 -0700 X-ASG-Debug-ID: 1214290783-30a1004c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 76BAED2ED37 for ; Mon, 23 Jun 2008 23:59:43 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id EXAZFe5RhgXPBijG for ; Mon, 23 Jun 2008 23:59:43 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate53D.nec.co.jp [10.7.69.160]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5O6xN9H028428; Tue, 24 Jun 2008 15:59:23 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5O6xMs13728; Tue, 24 Jun 2008 15:59:22 +0900 (JST) Received: from togyo.jp.nec.com (togyo.jp.nec.com [10.26.220.4]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5O6xM05014163; Tue, 24 Jun 2008 15:59:22 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Tue, 24 Jun 2008 15:59:19 +0900 To: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: [PATCH 0/3] freeze feature ver 1.6 Subject: [PATCH 0/3] freeze feature ver 1.6 Message-Id: <20080624155919t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Tue, 24 Jun 2008 15:59:19 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193] X-Barracuda-Start-Time: 1214290784 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.54183 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: 16503 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi Andrew and Alexander, I have implemented the ioctls for the filesystem freeze feature and discussed its implementation on the ML (linux-ext4, xfs, linux-fsdevel, linux-kernel) for five months. All of the comments are addressed in my patch-set. Could you consider merging it into Linux? The filesystem freeze feature can suspend accesses to the filesystem keeping the filesystem's consistency. We can take the consistent backup with it cooperating with the backup software. The patches are re-based from linux-2.6.26-rc3 to linux-2.6.26-rc7 There is no functional change from the previous version. The patch-set consists of the following three patches. [PATCH 1/3] Implement generic freeze feature I have modified to set the suitable error number (EOPNOTSUPP) in case the filesystem doesn't support the freeze feature. The ioctls for the generic freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, arg) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 o Unfreeze the filesystem int ioctl(int fd, int FITHAW, arg) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature It removes XFS specific ioctl interfaces and request codes for freeze feature. This patch has been supplied by David Chinner. [PATCH 3/3] Add timeout feature The timeout feature is added to freeze ioctl. And new ioctl to reset the timeout period is added. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, long *timeval) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze timeval: the timeout period in seconds If it's 0 or 1, the timeout isn't set. This special case of "1" is implemented to keep the compatibility with XFS applications. Return value: 0 if the operation succeeds. Otherwise, -1 o Reset the timeout period This is useful for the application to set the timeval more accurately. For example, the freezer resets the timeval to 10 seconds every 5 seconds. In this approach, even if the freezer causes a deadlock by accessing the frozen filesystem, it will be solved by the timeout in 10 seconds and the freezer can recognize that at the next reset of timeval. int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeval) fd:file descriptor of mountpoint FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period timeval: new timeout period in seconds Return value: 0 if the operation succeeds. Otherwise, -1 Error number: If the filesystem has already been unfrozen, errno is set to EINVAL. Any comments are very welcome. Cheers, Takashi From owner-xfs@oss.sgi.com Mon Jun 23 23:59:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 23:59:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_53,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 m5O6x74H019713 for ; Mon, 23 Jun 2008 23:59:07 -0700 X-ASG-Debug-ID: 1214290804-360c00730000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0DEC61BA6C2B for ; Tue, 24 Jun 2008 00:00:04 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id CZZfHTM9bW5VqRRm for ; Tue, 24 Jun 2008 00:00:04 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.193]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5O6xpll015640; Tue, 24 Jun 2008 15:59:51 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5O6xpl10564; Tue, 24 Jun 2008 15:59:51 +0900 (JST) Received: from yonosuke.jp.nec.com (yonosuke.jp.nec.com [10.26.220.15]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5O6xpto008332; Tue, 24 Jun 2008 15:59:51 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Tue, 24 Jun 2008 15:59:50 +0900 To: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: [PATCH 1/3] Implement generic freeze feature Subject: [PATCH 1/3] Implement generic freeze feature Message-Id: <20080624155950t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Tue, 24 Jun 2008 15:59:50 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1214290806 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54184 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16504 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs I have modified to set the suitable error number (EOPNOTSUPP) in case the filesystem doesn't support the freeze feature. This was pointed out by Andreas Dilger. The ioctls for the generic freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, arg) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 o Unfreeze the filesystem int ioctl(int fd, int FITHAW, arg) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 Signed-off-by: Takashi Sato Signed-off-by: Masayuki Hamaguchi --- fs/buffer.c | 30 ++++++++++++++++++++++++ fs/ioctl.c | 53 ++++++++++++++++++++++++++++++++++++++++++++ fs/super.c | 32 +++++++++++++++++++++++++- include/linux/buffer_head.h | 2 - include/linux/fs.h | 14 +++++++++++ 5 files changed, 128 insertions(+), 3 deletions(-) diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/fs/buffer.c linux-2.6.26-rc7-freeze/fs/bu ffer.c --- linux-2.6.26-rc7.org/fs/buffer.c 2008-06-21 08:19:44.000000000 +0900 +++ linux-2.6.26-rc7-freeze/fs/buffer.c 2008-06-23 11:54:48.000000000 +0900 @@ -201,6 +201,21 @@ struct super_block *freeze_bdev(struct b { struct super_block *sb; + if (test_and_set_bit(BD_FREEZE_OP, &bdev->bd_state)) + return ERR_PTR(-EBUSY); + + sb = get_super_without_lock(bdev); + + /* If super_block has been already frozen, return. */ + if (sb && sb->s_frozen != SB_UNFROZEN) { + put_super(sb); + clear_bit(BD_FREEZE_OP, &bdev->bd_state); + return sb; + } + + if (sb) + put_super(sb); + down(&bdev->bd_mount_sem); sb = get_super(bdev); if (sb && !(sb->s_flags & MS_RDONLY)) { @@ -219,6 +234,8 @@ struct super_block *freeze_bdev(struct b } sync_blockdev(bdev); + clear_bit(BD_FREEZE_OP, &bdev->bd_state); + return sb; /* thaw_bdev releases s->s_umount and bd_mount_sem */ } EXPORT_SYMBOL(freeze_bdev); @@ -230,8 +247,17 @@ EXPORT_SYMBOL(freeze_bdev); * * Unlocks the filesystem and marks it writeable again after freeze_bdev(). */ -void thaw_bdev(struct block_device *bdev, struct super_block *sb) +int thaw_bdev(struct block_device *bdev, struct super_block *sb) { + + if (test_and_set_bit(BD_FREEZE_OP, &bdev->bd_state)) + return -EBUSY; + + if (sb && sb->s_frozen == SB_UNFROZEN) { + clear_bit(BD_FREEZE_OP, &bdev->bd_state); + return 0; + } + if (sb) { BUG_ON(sb->s_bdev != bdev); @@ -244,6 +270,8 @@ void thaw_bdev(struct block_device *bdev } up(&bdev->bd_mount_sem); + clear_bit(BD_FREEZE_OP, &bdev->bd_state); + return 0; } EXPORT_SYMBOL(thaw_bdev); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/fs/ioctl.c linux-2.6.26-rc7-freeze/fs/ioc tl.c --- linux-2.6.26-rc7.org/fs/ioctl.c 2008-06-21 08:19:44.000000000 +0900 +++ linux-2.6.26-rc7-freeze/fs/ioctl.c 2008-06-23 11:54:48.000000000 +0900 @@ -13,6 +13,7 @@ #include #include #include +#include #include @@ -141,6 +142,49 @@ static int ioctl_fioasync(unsigned int f } /* + * ioctl_freeze - Freeze the filesystem. + * + * @filp: target file + * + * Call freeze_bdev() to freeze the filesystem. + */ +static int ioctl_freeze(struct file *filp) +{ + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + /* If filesystem doesn't support freeze feature, return. */ + if (sb->s_op->write_super_lockfs == NULL) + return -EOPNOTSUPP; + + /* Freeze */ + sb = freeze_bdev(sb->s_bdev); + if (IS_ERR(sb)) + return PTR_ERR(sb); + return 0; +} + +/* + * ioctl_thaw - Thaw the filesystem. + * + * @filp: target file + * + * Call thaw_bdev() to thaw the filesystem. + */ +static int ioctl_thaw(struct file *filp) +{ + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + /* Thaw */ + return thaw_bdev(sb->s_bdev, sb); +} + +/* * When you add any new common ioctls to the switches above and below * please update compat_sys_ioctl() too. * @@ -181,6 +225,15 @@ int do_vfs_ioctl(struct file *filp, unsi } else error = -ENOTTY; break; + + case FIFREEZE: + error = ioctl_freeze(filp); + break; + + case FITHAW: + error = ioctl_thaw(filp); + break; + default: if (S_ISREG(filp->f_path.dentry->d_inode->i_mode)) error = file_ioctl(filp, cmd, arg); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/fs/super.c linux-2.6.26-rc7-freeze/fs/sup er.c --- linux-2.6.26-rc7.org/fs/super.c 2008-06-21 08:19:44.000000000 +0900 +++ linux-2.6.26-rc7-freeze/fs/super.c 2008-06-23 11:54:48.000000000 +0900 @@ -156,7 +156,7 @@ int __put_super_and_need_restart(struct * Drops a temporary reference, frees superblock if there's no * references left. */ -static void put_super(struct super_block *sb) +void put_super(struct super_block *sb) { spin_lock(&sb_lock); __put_super(sb); @@ -509,6 +509,36 @@ rescan: EXPORT_SYMBOL(get_super); +/* + * get_super_without_lock - Get super_block from block_device without lock. + * @bdev: block device struct + * + * Scan the superblock list and finds the superblock of the file system + * mounted on the block device given. This doesn't lock anyone. + * %NULL is returned if no match is found. + */ +struct super_block *get_super_without_lock(struct block_device *bdev) +{ + struct super_block *sb; + + if (!bdev) + return NULL; + + spin_lock(&sb_lock); + list_for_each_entry(sb, &super_blocks, s_list) { + if (sb->s_bdev == bdev) { + if (sb->s_root) { + sb->s_count++; + spin_unlock(&sb_lock); + return sb; + } + } + } + spin_unlock(&sb_lock); + return NULL; +} +EXPORT_SYMBOL(get_super_without_lock); + struct super_block * user_get_super(dev_t dev) { struct super_block *sb; diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/include/linux/buffer_head.h linux-2.6.26- rc7-freeze/include/linux/buffer_head.h --- linux-2.6.26-rc7.org/include/linux/buffer_head.h 2008-06-21 08:19:44.000000000 +0900 +++ linux-2.6.26-rc7-freeze/include/linux/buffer_head.h 2008-06-23 11:54:48.000000000 +0900 @@ -171,7 +171,7 @@ void __wait_on_buffer(struct buffer_head wait_queue_head_t *bh_waitq_head(struct buffer_head *bh); int fsync_bdev(struct block_device *); struct super_block *freeze_bdev(struct block_device *); -void thaw_bdev(struct block_device *, struct super_block *); +int thaw_bdev(struct block_device *, struct super_block *); int fsync_super(struct super_block *); int fsync_no_super(struct block_device *); struct buffer_head *__find_get_block(struct block_device *bdev, sector_t block, diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/include/linux/fs.h linux-2.6.26-rc7-freez e/include/linux/fs.h --- linux-2.6.26-rc7.org/include/linux/fs.h 2008-06-21 08:19:44.000000000 +0900 +++ linux-2.6.26-rc7-freeze/include/linux/fs.h 2008-06-23 11:54:48.000000000 +0900 @@ -223,6 +223,8 @@ extern int dir_notify_enable; #define BMAP_IOCTL 1 /* obsolete - kept for compatibility */ #define FIBMAP _IO(0x00,1) /* bmap access */ #define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */ +#define FIFREEZE _IOWR('X', 119, int) /* Freeze */ +#define FITHAW _IOWR('X', 120, int) /* Thaw */ #define FS_IOC_GETFLAGS _IOR('f', 1, long) #define FS_IOC_SETFLAGS _IOW('f', 2, long) @@ -494,6 +496,13 @@ int pagecache_write_end(struct file *, s loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata); +/* + * Bits in block_device.bd_state. + */ +enum bd_state { + BD_FREEZE_OP /* In freeze operation */ +}; + struct backing_dev_info; struct address_space { struct inode *host; /* owner: inode, block_device */ @@ -547,6 +556,9 @@ struct block_device { * care to not mess up bd_private for that case. */ unsigned long bd_private; + + /* State of the block device. (Used by freeze feature) */ + unsigned long bd_state; }; /* @@ -1964,7 +1976,9 @@ extern int do_vfs_ioctl(struct file *fil extern void get_filesystem(struct file_system_type *fs); extern void put_filesystem(struct file_system_type *fs); extern struct file_system_type *get_fs_type(const char *name); +extern void put_super(struct super_block *sb); extern struct super_block *get_super(struct block_device *); +extern struct super_block *get_super_without_lock(struct block_device *); extern struct super_block *user_get_super(dev_t); extern void drop_super(struct super_block *sb); From owner-xfs@oss.sgi.com Mon Jun 23 23:59:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 23 Jun 2008 23:59:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5O6xdeC020126 for ; Mon, 23 Jun 2008 23:59:39 -0700 X-ASG-Debug-ID: 1214290838-360c00750000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 944BF1BA6C3D for ; Tue, 24 Jun 2008 00:00:38 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id awYMumfMaORmqbaW for ; Tue, 24 Jun 2008 00:00:38 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5O70Stp016473; Tue, 24 Jun 2008 16:00:28 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5O70Sr18713; Tue, 24 Jun 2008 16:00:28 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5O70RSp024054; Tue, 24 Jun 2008 16:00:27 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Tue, 24 Jun 2008 16:00:27 +0900 To: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature Subject: [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature Message-Id: <20080624160027t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Tue, 24 Jun 2008 16:00:26 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1214290839 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.54184 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: 16505 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs It removes XFS specific ioctl interfaces and request codes for freeze feature. This patch has been supplied by David Chinner. Signed-off-by: Dave Chinner Signed-off-by: Takashi Sato --- linux-2.6/xfs_ioctl.c | 15 --------------- linux-2.6/xfs_ioctl32.c | 2 -- xfs_fs.h | 4 ++-- 3 files changed, 2 insertions(+), 19 deletions(-) diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-freeze/fs/xfs/linux-2.6/xfs_ioctl.c linux-2.6 .26-rc7-xfs/fs/xfs/linux-2.6/xfs_ioctl.c --- linux-2.6.26-rc7-freeze/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-23 11:53:03.000000000 +0900 +++ linux-2.6.26-rc7-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-23 11:55:36.000000000 +0900 @@ -1233,21 +1233,6 @@ xfs_ioctl( return -error; } - case XFS_IOC_FREEZE: - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; - - if (inode->i_sb->s_frozen == SB_UNFROZEN) - freeze_bdev(inode->i_sb->s_bdev); - return 0; - - case XFS_IOC_THAW: - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; - if (inode->i_sb->s_frozen != SB_UNFROZEN) - thaw_bdev(inode->i_sb->s_bdev, inode->i_sb); - return 0; - case XFS_IOC_GOINGDOWN: { __uint32_t in; diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-freeze/fs/xfs/linux-2.6/xfs_ioctl32.c linux-2 .6.26-rc7-xfs/fs/xfs/linux-2.6/xfs_ioctl32.c --- linux-2.6.26-rc7-freeze/fs/xfs/linux-2.6/xfs_ioctl32.c 2008-06-23 11:53:03.000000000 +0900 +++ linux-2.6.26-rc7-xfs/fs/xfs/linux-2.6/xfs_ioctl32.c 2008-06-23 11:55:36.000000000 +0900 @@ -398,8 +398,6 @@ xfs_compat_ioctl( case XFS_IOC_FSGROWFSDATA: case XFS_IOC_FSGROWFSLOG: case XFS_IOC_FSGROWFSRT: - case XFS_IOC_FREEZE: - case XFS_IOC_THAW: case XFS_IOC_GOINGDOWN: case XFS_IOC_ERROR_INJECTION: case XFS_IOC_ERROR_CLEARALL: diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-freeze/fs/xfs/xfs_fs.h linux-2.6.26-rc7-xfs/f s/xfs/xfs_fs.h --- linux-2.6.26-rc7-freeze/fs/xfs/xfs_fs.h 2008-06-23 11:53:03.000000000 +0900 +++ linux-2.6.26-rc7-xfs/fs/xfs/xfs_fs.h 2008-06-23 11:55:36.000000000 +0900 @@ -473,8 +473,8 @@ typedef struct xfs_handle { #define XFS_IOC_ERROR_INJECTION _IOW ('X', 116, struct xfs_error_injection) #define XFS_IOC_ERROR_CLEARALL _IOW ('X', 117, struct xfs_error_injection) /* XFS_IOC_ATTRCTL_BY_HANDLE -- deprecated 118 */ -#define XFS_IOC_FREEZE _IOWR('X', 119, int) -#define XFS_IOC_THAW _IOWR('X', 120, int) +/* XFS_IOC_FREEZE -- FIFREEZE 119 */ +/* XFS_IOC_THAW -- FITHAW 120 */ #define XFS_IOC_FSSETDM_BY_HANDLE _IOW ('X', 121, struct xfs_fsop_setdm_handlereq) #define XFS_IOC_ATTRLIST_BY_HANDLE _IOW ('X', 122, struct xfs_fsop_attrlist_handlereq) #define XFS_IOC_ATTRMULTI_BY_HANDLE _IOW ('X', 123, struct xfs_fsop_attrmulti_handlereq) From owner-xfs@oss.sgi.com Tue Jun 24 00:00:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 00:01: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53 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 m5O70fIU022817 for ; Tue, 24 Jun 2008 00:00:42 -0700 X-ASG-Debug-ID: 1214290899-0e1700a40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1047526E8A0 for ; Tue, 24 Jun 2008 00:01:39 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id cpO1OGFR9mpEQrEy for ; Tue, 24 Jun 2008 00:01:39 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5O710N4017037; Tue, 24 Jun 2008 16:01:00 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5O710719630; Tue, 24 Jun 2008 16:01:00 +0900 (JST) Received: from yonosuke.jp.nec.com (yonosuke.jp.nec.com [10.26.220.15]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5O70xxQ015576; Tue, 24 Jun 2008 16:00:59 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Tue, 24 Jun 2008 16:00:56 +0900 To: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: [PATCH 3/3] Add timeout feature Subject: [PATCH 3/3] Add timeout feature Message-Id: <20080624160056t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Tue, 24 Jun 2008 16:00:56 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1214290901 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.54184 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: 16506 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs The timeout feature is added to freeze ioctl. And new ioctl to reset the timeout period is added. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, long *timeval) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze timeval: the timeout period in seconds If it's 0 or 1, the timeout isn't set. This special case of "1" is implemented to keep the compatibility with XFS applications. Return value: 0 if the operation succeeds. Otherwise, -1 o Reset the timeout period int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeval) fd:file descriptor of mountpoint FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period timeval: new timeout period in seconds Return value: 0 if the operation succeeds. Otherwise, -1 Error number: If the filesystem has already been unfrozen, errno is set to EINVAL. Signed-off-by: Takashi Sato Signed-off-by: Masayuki Hamaguchi --- drivers/md/dm.c | 2 - fs/block_dev.c | 2 + fs/buffer.c | 14 ++++++- fs/ioctl.c | 78 ++++++++++++++++++++++++++++++++++++++++++-- fs/super.c | 51 ++++++++++++++++++++++++++++ fs/xfs/xfs_fsops.c | 2 - include/linux/buffer_head.h | 2 - include/linux/fs.h | 8 ++++ 8 files changed, 151 insertions(+), 8 deletions(-) diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/drivers/md/dm.c linux-2.6.26-rc7-timeout/ drivers/md/dm.c --- linux-2.6.26-rc7-xfs/drivers/md/dm.c 2008-06-23 11:55:11.000000000 +0900 +++ linux-2.6.26-rc7-timeout/drivers/md/dm.c 2008-06-23 11:56:47.000000000 +0900 @@ -1407,7 +1407,7 @@ static int lock_fs(struct mapped_device WARN_ON(md->frozen_sb); - md->frozen_sb = freeze_bdev(md->suspended_bdev); + md->frozen_sb = freeze_bdev(md->suspended_bdev, 0); if (IS_ERR(md->frozen_sb)) { r = PTR_ERR(md->frozen_sb); md->frozen_sb = NULL; diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/block_dev.c linux-2.6.26-rc7-timeout/f s/block_dev.c --- linux-2.6.26-rc7-xfs/fs/block_dev.c 2008-06-23 11:55:15.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/block_dev.c 2008-06-23 11:56:47.000000000 +0900 @@ -285,6 +285,8 @@ static void init_once(struct kmem_cache INIT_LIST_HEAD(&bdev->bd_holder_list); #endif inode_init_once(&ei->vfs_inode); + /* Setup freeze timeout function. */ + INIT_DELAYED_WORK(&bdev->bd_freeze_timeout, freeze_timeout); } static inline void __bd_forget(struct inode *inode) diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/buffer.c linux-2.6.26-rc7-timeout/fs/b uffer.c --- linux-2.6.26-rc7-xfs/fs/buffer.c 2008-06-23 11:55:15.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/buffer.c 2008-06-23 11:56:47.000000000 +0900 @@ -190,14 +190,17 @@ int fsync_bdev(struct block_device *bdev /** * freeze_bdev -- lock a filesystem and force it into a consistent state - * @bdev: blockdevice to lock + * @bdev: blockdevice to lock + * @timeout_msec: timeout period * * This takes the block device bd_mount_sem to make sure no new mounts * happen on bdev until thaw_bdev() is called. * If a superblock is found on this device, we take the s_umount semaphore * on it to make sure nobody unmounts until the snapshot creation is done. + * If timeout_msec is bigger than 0, this registers the delayed work for + * timeout of the freeze feature. */ -struct super_block *freeze_bdev(struct block_device *bdev) +struct super_block *freeze_bdev(struct block_device *bdev, long timeout_msec) { struct super_block *sb; @@ -234,6 +237,10 @@ struct super_block *freeze_bdev(struct b } sync_blockdev(bdev); + /* Setup unfreeze timer. */ + if (timeout_msec > 0) + add_freeze_timeout(bdev, timeout_msec); + clear_bit(BD_FREEZE_OP, &bdev->bd_state); return sb; /* thaw_bdev releases s->s_umount and bd_mount_sem */ @@ -258,6 +265,9 @@ int thaw_bdev(struct block_device *bdev, return 0; } + /* Delete unfreeze timer. */ + del_freeze_timeout(bdev); + if (sb) { BUG_ON(sb->s_bdev != bdev); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/ioctl.c linux-2.6.26-rc7-timeout/fs/io ctl.c --- linux-2.6.26-rc7-xfs/fs/ioctl.c 2008-06-23 11:55:15.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/ioctl.c 2008-06-23 11:56:47.000000000 +0900 @@ -145,12 +145,16 @@ static int ioctl_fioasync(unsigned int f * ioctl_freeze - Freeze the filesystem. * * @filp: target file + * @argp: timeout value(sec) * * Call freeze_bdev() to freeze the filesystem. */ -static int ioctl_freeze(struct file *filp) +static int ioctl_freeze(struct file *filp, unsigned long arg) { + long timeout_sec; + long timeout_msec; struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + int error; if (!capable(CAP_SYS_ADMIN)) return -EPERM; @@ -159,8 +163,27 @@ static int ioctl_freeze(struct file *fil if (sb->s_op->write_super_lockfs == NULL) return -EOPNOTSUPP; + /* arg(sec) to tick value. */ + error = get_user(timeout_sec, (long __user *) arg); + if (error != 0) + return error; + /* + * If 1 is specified as the timeout period, + * it will be changed into 0 to keep the compatibility + * of XFS application(xfs_freeze). + */ + if (timeout_sec < 0) + return -EINVAL; + else if (timeout_sec < 2) + timeout_sec = 0; + + timeout_msec = timeout_sec * 1000; + /* overflow case */ + if (timeout_msec < 0) + return -EINVAL; + /* Freeze */ - sb = freeze_bdev(sb->s_bdev); + sb = freeze_bdev(sb->s_bdev, timeout_msec); if (IS_ERR(sb)) return PTR_ERR(sb); return 0; @@ -185,6 +208,51 @@ static int ioctl_thaw(struct file *filp) } /* + * ioctl_freeze_reset_timeout - Reset timeout for freeze. + * + * @filp: target file + * @argp: timeout value(sec) + * + * Rest timeout for freeze. + */ +static int +ioctl_freeze_reset_timeout(struct file *filp, unsigned long arg) +{ + long timeout_sec; + long timeout_msec; + struct super_block *sb + = filp->f_path.dentry->d_inode->i_sb; + int error; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + /* arg(sec) to tick value */ + error = get_user(timeout_sec, (long __user *) arg); + if (error) + return error; + timeout_msec = timeout_sec * 1000; + if (timeout_msec < 0) + return -EINVAL; + + if (sb) { + if (test_and_set_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state)) + return -EBUSY; + if (sb->s_frozen == SB_UNFROZEN) { + clear_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state); + return -EINVAL; + } + /* setup unfreeze timer */ + if (timeout_msec > 0) + add_freeze_timeout(sb->s_bdev, + timeout_msec); + clear_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state); + } + + return 0; +} + +/* * When you add any new common ioctls to the switches above and below * please update compat_sys_ioctl() too. * @@ -227,13 +295,17 @@ int do_vfs_ioctl(struct file *filp, unsi break; case FIFREEZE: - error = ioctl_freeze(filp); + error = ioctl_freeze(filp, arg); break; case FITHAW: error = ioctl_thaw(filp); break; + case FIFREEZE_RESET_TIMEOUT: + error = ioctl_freeze_reset_timeout(filp, arg); + break; + default: if (S_ISREG(filp->f_path.dentry->d_inode->i_mode)) error = file_ioctl(filp, cmd, arg); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/super.c linux-2.6.26-rc7-timeout/fs/su per.c --- linux-2.6.26-rc7-xfs/fs/super.c 2008-06-23 11:55:15.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/super.c 2008-06-23 11:56:47.000000000 +0900 @@ -1010,3 +1010,54 @@ struct vfsmount *kern_mount_data(struct } EXPORT_SYMBOL_GPL(kern_mount_data); + +/* + * freeze_timeout - Thaw the filesystem. + * + * @work: work queue (delayed_work.work) + * + * Called by the delayed work when elapsing the timeout period. + * Thaw the filesystem. + */ +void freeze_timeout(struct work_struct *work) +{ + struct block_device *bd = container_of(work, + struct block_device, bd_freeze_timeout.work); + struct super_block *sb = get_super_without_lock(bd); + + thaw_bdev(bd, sb); + + if (sb) + put_super(sb); +} +EXPORT_SYMBOL_GPL(freeze_timeout); + +/* + * add_freeze_timeout - Add timeout for freeze. + * + * @bdev: block device struct + * @timeout_msec: timeout period + * + * Add the delayed work for freeze timeout to the delayed work queue. + */ +void add_freeze_timeout(struct block_device *bdev, long timeout_msec) +{ + s64 timeout_jiffies = msecs_to_jiffies(timeout_msec); + + /* Set delayed work queue */ + cancel_delayed_work(&bdev->bd_freeze_timeout); + schedule_delayed_work(&bdev->bd_freeze_timeout, timeout_jiffies); +} + +/* + * del_freeze_timeout - Delete timeout for freeze. + * + * @bdev: block device struct + * + * Delete the delayed work for freeze timeout from the delayed work queue. + */ +void del_freeze_timeout(struct block_device *bdev) +{ + if (delayed_work_pending(&bdev->bd_freeze_timeout)) + cancel_delayed_work(&bdev->bd_freeze_timeout); +} diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/xfs/xfs_fsops.c linux-2.6.26-rc7-timeo ut/fs/xfs/xfs_fsops.c --- linux-2.6.26-rc7-xfs/fs/xfs/xfs_fsops.c 2008-06-23 11:55:15.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/xfs/xfs_fsops.c 2008-06-23 11:56:47.000000000 +0900 @@ -619,7 +619,7 @@ xfs_fs_goingdown( { switch (inflags) { case XFS_FSOP_GOING_FLAGS_DEFAULT: { - struct super_block *sb = freeze_bdev(mp->m_super->s_bdev); + struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, 0); if (sb && !IS_ERR(sb)) { xfs_force_shutdown(mp, SHUTDOWN_FORCE_UMOUNT); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/include/linux/buffer_head.h linux-2.6.26- rc7-timeout/include/linux/buffer_head.h --- linux-2.6.26-rc7-xfs/include/linux/buffer_head.h 2008-06-23 11:55:16.000000000 +0900 +++ linux-2.6.26-rc7-timeout/include/linux/buffer_head.h 2008-06-23 11:56:47.000000000 +0900 @@ -170,7 +170,7 @@ int sync_blockdev(struct block_device *b void __wait_on_buffer(struct buffer_head *); wait_queue_head_t *bh_waitq_head(struct buffer_head *bh); int fsync_bdev(struct block_device *); -struct super_block *freeze_bdev(struct block_device *); +struct super_block *freeze_bdev(struct block_device *, long timeout_msec); int thaw_bdev(struct block_device *, struct super_block *); int fsync_super(struct super_block *); int fsync_no_super(struct block_device *); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/include/linux/fs.h linux-2.6.26-rc7-timeo ut/include/linux/fs.h --- linux-2.6.26-rc7-xfs/include/linux/fs.h 2008-06-23 11:55:16.000000000 +0900 +++ linux-2.6.26-rc7-timeout/include/linux/fs.h 2008-06-23 11:56:47.000000000 +0900 @@ -8,6 +8,7 @@ #include #include +#include /* * It's silly to have NR_OPEN bigger than NR_FILE, but you can change @@ -225,6 +226,7 @@ extern int dir_notify_enable; #define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */ #define FIFREEZE _IOWR('X', 119, int) /* Freeze */ #define FITHAW _IOWR('X', 120, int) /* Thaw */ +#define FIFREEZE_RESET_TIMEOUT _IO(0x00, 3) /* Reset freeze timeout */ #define FS_IOC_GETFLAGS _IOR('f', 1, long) #define FS_IOC_SETFLAGS _IOW('f', 2, long) @@ -559,6 +561,8 @@ struct block_device { /* State of the block device. (Used by freeze feature) */ unsigned long bd_state; + /* Delayed work for freeze */ + struct delayed_work bd_freeze_timeout; }; /* @@ -2149,5 +2153,9 @@ int proc_nr_files(struct ctl_table *tabl int get_filesystem_list(char * buf); +extern void add_freeze_timeout(struct block_device *bdev, long timeout_msec); +extern void del_freeze_timeout(struct block_device *bdev); +extern void freeze_timeout(struct work_struct *work); + #endif /* __KERNEL__ */ #endif /* _LINUX_FS_H */ From owner-xfs@oss.sgi.com Tue Jun 24 00:01:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 00:01:59 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5O71ok3023306 for ; Tue, 24 Jun 2008 00:01:50 -0700 X-ASG-Debug-ID: 1214290969-0e1800b10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta01.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4360226E8D5 for ; Tue, 24 Jun 2008 00:02:49 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id DIKfXJVJSGhOGEWR for ; Tue, 24 Jun 2008 00:02:49 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id C4E7518900C1 for ; Tue, 24 Jun 2008 00:05:28 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta01.pmc-sierra.bc.ca (Postfix) with SMTP id 5F61A18900BF for ; Tue, 24 Jun 2008 00:05:28 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 00:03:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-ASG-Orig-Subj: Xfs Access to block zero exception and system crash Subject: Xfs Access to block zero exception and system crash Date: Tue, 24 Jun 2008 00:03:16 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: AcjVyF6rnI622uINTByuCfed3R20HA== From: "Sagar Borikar" To: Cc: "Sagar Borikar" X-OriginalArrivalTime: 24 Jun 2008 07:03:16.0320 (UTC) FILETIME=[6023E600:01C8D5C8] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.6.24.64344 X-PMC-SpamCheck: Gauge=IIIIIIIII, Probability=9%, Report='HASHBUSTER_BLOCK_V2 0.5, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HASHBUSTER_BLOCK_V2_1 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __OEM_PRICE 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0' X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1214290970 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.54184 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 m5O71pk3023316 X-archive-position: 16507 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Sagar_Borikar@pmc-sierra.com Precedence: bulk X-list: xfs Hello, I hope this is the right list to address this issue. If not please divert me to the right list. We are facing strange issue with xfs under heavy load. It's a NAS box with 2.6.18 kernel,128 MB of RAM, MIPS architecture and XFS version 2.8.11. NAS allows to create RAID1,RAID5 over XFS. The system is stable in general without any stress. We don't see any issues in day to day activities. But when it is exposed to stress with multiple iozone clients, it starts giving weird issues. The iozone stress test is ran with 15 CIFS clients, pumping data over 1GBps network, continuously for 48 hours as a part of calculating MTBF of the system, it crashes at different stages in different stimulus but in XFS only. A. Initially it used to give access to block zero exception and system used to crash for which I applied Nathan Scott's patch which removes the kernel panic when this situation is hit. http://oss.sgi.com/archives/xfs/2006-08/msg00073.html After back porting this patch, we observed that the system is not crashing but the warning messages are still coming. And after some time the system goes in soft lockup state and becomes non-responsive. I couldn't run the xfs_db or xfs_repair to check what is the state of the inode as console was not reachable after hitting the lockup state. Here is the log " Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 af Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 af Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 af Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 b0 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 b0 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 e7 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 e7 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 e7 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 8 20 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 8 20 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 68 extent-sta te: 1 lastx: 88d Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 68 extent-sta te: 1 lastx: 88d Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 68 extent-sta te: 1 lastx: 88d Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffc000000 blkcnt: 180 extent-st ate: 1 lastx: 88f Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffc000000 blkcnt: 180 extent-st ate: 1 lastx: 88f Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffc000000 blkcnt: 180 extent-st ate: 1 lastx: 88f Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 1a0 extent-st ate: 1 lastx: 891 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 1a0 extent-st " Once we hit the soft lockup, system has to be rebooted as it is completely stalled and we can't even check which processes are running. I could be wrong but it was surprising to me that the same inode was referring to different offsets and blkcnt. It took 48 hours to reach this state and system had to be rebooted. B. In another DUT, the system just rebooted after displaying couple of warning messages without entering in soft lockup state. " Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inï PMON2000 MIPS Initializing. Standby... ERRORPC=bfc00004 CONFIG=0042e4bb STATUS=00400000 CPU PRID 000034c1, MaskID 00001320 Initializing caches...done (CONFIG=0042e4bb) Switching to runtime address map...done Setting up SDRAM controller: Manual SDRAM setup drive strength 0x000073c7 output timing 0x00000fca general config 0x80010000 master clock 100 Mhz, MulFundBIU 0x02, DivXSDRAM 0x02 sdram freq 0x09ef21aa hz, sdram period: 0x06 nsec " It took 43 hours to come to this state. C. In another stimulus, device driver mentioned that it can't access the block. Which means that filesystem got corrupted. I inferred that Filesystem was trying to reach block which is not existing in the disk. After some time, it recovers itself and starts giving weird issue. Finally it hits the memory access exception and system crashes. " Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 8 Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 8 Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 1 Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 1 Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 1 attempt to access beyond end of device dm-1: rw=0, want=1003118956380168, limit=8388608 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x39054d5100001 ("xfs_trans_read_buf") error 5 buf count 512 attempt to access beyond end of device dm-1: rw=0, want=1003118956380168, limit=8388608 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x39054d5100001 ("xfs_trans_read_buf") error 5 buf count 512 attempt to access beyond end of device dm-1: rw=0, want=1003118956380168, limit=8388608 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x39054d5100001 ("xfs_trans_read_buf") error 5 buf count 512 attempt to access beyond end of device dm-1: rw=0, want=1003118956380168, limit=8388608 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x39054d5100001 ("xfs_trans_read_buf") error 5 buf count 512 attempt to access beyond end of device Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f e Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f e Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f f Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f f Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f f CPU 0 Unable to handle kernel paging request at virtual address 04e81080, epc == 802a90ac, ra == 802a9094 Oops[#1]: Cpu 0 $ 0 : 00000000 9000a001 84e81080 80000000 $ 4 : 82ce6dd0 00000000 ffffffff ffffffff $ 8 : 00086800 00000000 00086800 00000001 $12 : 00000004 34000000 82ce6c00 00000001 $16 : ffffffff 04e81080 34000000 81213978 $20 : 82ce6c00 82ce6dd0 00000000 34000000 $24 : 00086800 00000000 $28 : 81212000 81213878 00000000 802a9094 Hi : 00000000 Lo : 00036a20 epc : 802a90ac xfs_bmap_btalloc+0x33c/0x950 Not tainted ra : 802a9094 xfs_bmap_btalloc+0x324/0x950 Status: 9000a003 KERNEL EXL IE Cause : 00000008 BadVA : 04e81080 PrId : 000034c1 Modules linked in: aes autofs4 Process pdflush (pid: 66, threadinfo=81212000, task=8120b138) Stack : 81213880 811c9074 00000003 863af000 00000000 00000001 000000cb 805c1f90 812139b8 8616ece0 8538e6f8 82ce6c00 812139fc ffffffff 00086800 00000000 802aad9c 802aad80 8616ed30 00000001 8173c6f4 813cf200 812138d8 00000001 00000200 00000000 812139b8 00000004 81213a00 00000000 ffffffff ffffffff 00000000 00000000 00000001 00000000 00000000 81213a00 000002a3 81213ac0 ... Call Trace: [<802a90ac>] xfs_bmap_btalloc+0x33c/0x950 [<802a9700>] xfs_bmap_alloc+0x40/0x4c [<802acc9c>] xfs_bmapi+0x8d8/0x13e4 [<802d42d4>] xfs_iomap_write_allocate+0x3c0/0x5f4 [<802d2b28>] xfs_iomap+0x408/0x4dc [<802fe90c>] xfs_bmap+0x30/0x3c [<802f3cfc>] xfs_map_blocks+0x50/0x84 [<802f512c>] xfs_page_state_convert+0x3f4/0x840 [<802f565c>] xfs_vm_writepage+0xe4/0x140 [<80198758>] mpage_writepages+0x24c/0x45c [<802f56e8>] xfs_vm_writepages+0x30/0x3c [<801507b4>] do_writepages+0x44/0x84 [<80196628>] __sync_single_inode+0x68/0x234 [<80196980>] __writeback_single_inode+0x18c/0x1ac [<80196ba8>] sync_sb_inodes+0x208/0x2f0 [<80196d14>] writeback_inodes+0x84/0xd0 [<801503e0>] background_writeout+0xac/0xfc [<80151330>] __pdflush+0x130/0x228 [<80151458>] pdflush+0x30/0x3c [<801398bc>] kthread+0x98/0xe0 [<80104c38>] kernel_thread_helper+0x10/0x18 " In all the three cases, when I tried to perform the slower tests i.e. with 6 clients but with the same stimulus, there we re no exceptions and system was stable for 5 days. [root@Cousteau6 ~]# df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/scsibd2 41664 41664 0 100% / udev 62044 4 62040 0% /dev tmpfs 5120 3468 1652 68% /var tmpfs 62044 24 62020 0% /tmp tmpfs 128 4 124 3% /mnt /dev/mtdblock1 1664 436 1228 26% /linuxrwfs /dev/RAIDA/Volume1 10475520 624 10474896 0% /mnt/RAIDA/Volume1 /dev/RAIDA/Volume1 10475520 624 10474896 0% /mnt/ftp_dir/homes /dev/RAIDA/IOZONETEST 4184064 2479044 1705020 59% /mnt/RAIDA/IOZONETEST /dev/RAIDA/IOZONETEST 4184064 2479044 1705020 59% /mnt/ftp_dir/share1 /dev/RAIDA/Volume1 10475520 624 10474896 0% /mnt/ftp_dir/share2 Can anyone let me know what could be the probable cause of this issue. Thanks in advance Sagar From owner-xfs@oss.sgi.com Tue Jun 24 00:05:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 00:05:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, 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 m5O75KIq024155 for ; Tue, 24 Jun 2008 00:05:21 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA12380; Tue, 24 Jun 2008 17:06:15 +1000 Message-ID: <48609DD0.80604@sgi.com> Date: Tue, 24 Jun 2008 17:10:08 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() References: <48605744.8070400@sgi.com> <20080624045841.GN16257@build-svl-1.agami.com> <4860847B.7070703@sgi.com> <20080624052556.GR16257@build-svl-1.agami.com> <48609152.7050208@sgi.com> <20080624062551.GU16257@build-svl-1.agami.com> In-Reply-To: <20080624062551.GU16257@build-svl-1.agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16508 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Tue, Jun 24, 2008 at 04:16:50PM +1000, Lachlan McIlroy wrote: >> Dave Chinner wrote: >>> On Tue, Jun 24, 2008 at 03:22:03PM +1000, Lachlan McIlroy wrote: >>>> Dave Chinner wrote: >>>>> On Tue, Jun 24, 2008 at 12:09:08PM +1000, Lachlan McIlroy wrote: >>>>>> The bmap btree split code relies on a previous data extent allocation >>>>>> (from xfs_bmap_btalloc()) to find an AG that has sufficient space >>>>>> to perform a full btree split, when inserting the extent. When >>>>>> converting unwritten extents we don't allocate a data extent so a >>>>>> btree split will be the first allocation. In this case we need to >>>>>> set minleft so the allocator will pick an AG that has space to >>>>>> complete the split(s). >>>>> looks good, execpt... >>>>> >>>>>> Lachlan >>>>>> >>>>>> --- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c >>>>>> +++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c >>>>>> @@ -1493,12 +1493,20 @@ xfs_bmbt_split( >>>>>> left = XFS_BUF_TO_BMBT_BLOCK(lbp); >>>>>> args.fsbno = cur->bc_private.b.firstblock; >>>>>> args.firstblock = args.fsbno; >>>>>> + args.minleft = 0; >>>>>> if (args.fsbno == NULLFSBLOCK) { >>>>>> args.fsbno = lbno; >>>>>> args.type = XFS_ALLOCTYPE_START_BNO; >>>>>> + /* >>>>>> + * Make sure there is sufficient room left in the AG to >>>>>> + * complete a full tree split for an extent insert. If >>>>>> + * we are converting the middle part of an extent then >>>>>> + * we may need space for two tree splits. >>>>>> + */ >>>>>> + args.minleft = xfs_trans_get_block_res(args.tp); >>>>> I'd mention in this comment that transaction reservation needs to >>>>> take this specifically into account. >>>> How would transaction reservation take this into account? Are you >>>> implying they could do something different if they knew about this >>>> fix? >>> No, I'm implying that the transaction reservation better be correct. >>> i.e. anywhere that unwritten extent conversion can take place needs >>> to supply a reservation of enough blocks to allow a double split to >>> occur. i.e. we are relying on the caller to get this right, so we >>> need to ensure that a comment explaining the potential landmine is >>> present.... >> Okay. With the change above we can still have xfs_bmbt_split() fail >> to allocate btree blocks if it cannot find a single AG with enough >> free space. Although in my testing I haven't seen it fail yet. > > Sure, but at that point you've most likely got a real ENOSPC condition. > >> We really don't want to fail here because we have already partly >> modified the extent btree (ie for the case where we convert the middle >> part of an unwritten extent we do an xfs_bmbt_update before the insert) >> and we dont undo the damage. > > Yes, but lets deal with one problem at a time ;) > >> Also a failure to allocate in >> xfs_bmbt_split() will be caught by the XFS_WANT_CORRUPTED_GOTO() in >> xfs_bmbt_insert() and the error set to EFSCORRUPTED which is only going >> to create confusion. > > For whom? Log an error message when allocation fails if you're > worried that we won't be able to determine what went wrong... > >> I have another patch that allows xfs_bmbt_split() >> and xfs_bmbt_newroot() to fall back to the lowspace algorithm - I'm >> just testing it now. > > Cool - that should solve the corner cases you mention above... This is the fallback code. Do you think I also need to make the same minleft change above and this change below to xfs_bmbt_newroot()? I'm inclined to change both xfs_bmbt_split() and xfs_bmbt_newroot() and keep them as similar as possible. For the newroot case we know we only need one block and we know there will be no more allocations for this insert so using 'minleft = xfs_trans_get_block_res()' is silly but on the other hand we don't have any other way to detect the double insert case. --- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c +++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c @@ -1525,6 +1525,21 @@ xfs_bmbt_split( XFS_BMBT_TRACE_CURSOR(cur, ERROR); return error; } + if (args.fsbno == NULLFSBLOCK && args.minleft) { + /* + * Could not find an AG will enough free space to satisfy + * a full btree split. Try again without minleft and if + * successful activate the lowspace algorithm. + */ + args.fsbno = 0; + args.type = XFS_ALLOCTYPE_FIRST_AG; + args.minleft = 0; + if ((error = xfs_alloc_vextent(&args))) { + XFS_BMBT_TRACE_CURSOR(cur, ERROR); + return error; + } + cur->bc_private.b.flist->xbf_low = 1; + } if (args.fsbno == NULLFSBLOCK) { XFS_BMBT_TRACE_CURSOR(cur, EXIT); *stat = 0; From owner-xfs@oss.sgi.com Tue Jun 24 00:05:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 00:05:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 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 m5O75Qaw024191 for ; Tue, 24 Jun 2008 00:05:27 -0700 X-ASG-Debug-ID: 1214291185-488a00320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34508.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 92EB61BA6EC0 for ; Tue, 24 Jun 2008 00:06:25 -0700 (PDT) Received: from web34508.mail.mud.yahoo.com (web34508.mail.mud.yahoo.com [66.163.178.174]) by cuda.sgi.com with SMTP id CESiumIiCgkosGRV for ; Tue, 24 Jun 2008 00:06:25 -0700 (PDT) Received: (qmail 88478 invoked by uid 60001); 24 Jun 2008 07:06:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=DJYq4agmrIB6aYUtbWuCx+rteljD9a3iVVR05VZzuQ4YlgSxVKiFXGVKdI1ZH5isfveJcxXpzIEAcZLpwKLd5Oz8poTh/0Q7bBFvojaysq3dajwjaRH7RMcpXTcz9Q0Pi3bUfACAK1Ny1wM9lNYa7ss+dA8xjSQGPj5juIN2TaA=; Received: from [96.13.237.119] by web34508.mail.mud.yahoo.com via HTTP; Tue, 24 Jun 2008 00:06:25 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Tue, 24 Jun 2008 00:06:25 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: tests re-run with 1 CPU Subject: tests re-run with 1 CPU To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <504423.88343.qm@web34508.mail.mud.yahoo.com> X-Barracuda-Connect: web34508.mail.mud.yahoo.com[66.163.178.174] X-Barracuda-Start-Time: 1214291186 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0248 1.0000 -1.8599 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.86 X-Barracuda-Spam-Status: No, SCORE=-1.86 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.54184 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: 16509 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs Hi all, After booting with "nosmp", I re-ran my tests. XFS is still the winner, but the degree of its benefit from SMP is clear. Without SMP, the benchmark ran slightly better with 5 threads (229 MB/sec under "noop"), although the difference between "noop" and "deadline" was very slim. With SMP, the benchmark ran noticeably better with 20 threads (378 vs. 404 MB/sec). JFS took a small hit from the lack of SMP on 5 threads. Under 20 threads of load, it still suffered badly, stuck between 41.5 and 45.5 MB/sec throughput. ext3 is seems less predictable. It benefits well from SMP, but high I/O load degrades it. Mounting with "sync" showed a 21% degradation for XFS, but it still out-performed both JFS and ext3, with or without SMP. That is, JFS and ext3 lost nearly all SMP benefit with the "sync" mount option. On my system, XFS is the clear winner. I intend to convert my root partition to XFS with an external journal soon, probably tomorrow night. I am also considering posting my test observations to my website, with a story submission to LXer.com. Again, I have saved output from all dbench runs, if anyone wishes to review them. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Tue Jun 24 01:13:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 01:13:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65 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 m5O8D07n005226 for ; Tue, 24 Jun 2008 01:13:00 -0700 X-ASG-Debug-ID: 1214295239-2c84028a0000-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 481FDD2C85F for ; Tue, 24 Jun 2008 01:13:59 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id G607gdf3S4VmsgqG for ; Tue, 24 Jun 2008 01:13:59 -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 m5O8DmNW031237 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Jun 2008 10:13:48 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5O8DmCJ031234; Tue, 24 Jun 2008 10:13:48 +0200 Date: Tue, 24 Jun 2008 10:13:48 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Cc: mj@mjturner.net X-ASG-Orig-Subj: [PATCH] Subject: [PATCH] Message-ID: <20080624081348.GA31048@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: 1214295240 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.54189 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: 16510 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 As reported by Michael-John Turner XFS updates the mtime on the source inode of a rename call in case it's a directory and changes the parent. This doesn't make any sense, is not mentioned in the standards and not performed by any other Linux filesystems so remove it. (resending this as it might have been lost in the previous thread) Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/xfs_rename.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rename.c 2008-06-18 18:24:38.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_rename.c 2008-06-18 18:30:17.000000000 +0200 @@ -336,22 +336,18 @@ xfs_rename( ASSERT(error != EEXIST); if (error) goto abort_return; - xfs_ichgtime(src_ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); - - } else { - /* - * We always want to hit the ctime on the source inode. - * We do it in the if clause above for the 'new_parent && - * src_is_directory' case, and here we get all the other - * cases. This isn't strictly required by the standards - * since the source inode isn't really being changed, - * but old unix file systems did it and some incremental - * backup programs won't work without it. - */ - xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG); } /* + * We always want to hit the ctime on the source inode. + * + * This isn't strictly required by the standards since the source + * inode isn't really being changed, but old unix file systems did + * it and some incremental backup programs won't work without it. + */ + xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG); + + /* * Adjust the link count on src_dp. This is necessary when * renaming a directory, either within one parent when * the target existed, or across two parent directories. From owner-xfs@oss.sgi.com Tue Jun 24 01:16:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 01:16:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_65 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 m5O8GUkq006173 for ; Tue, 24 Jun 2008 01:16:30 -0700 X-ASG-Debug-ID: 1214295449-555100d60000-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 2B4AA26EBFB for ; Tue, 24 Jun 2008 01:17:30 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id GOLOfFtv2DPnDfIv for ; Tue, 24 Jun 2008 01:17:30 -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 m5O8HJNW031518 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Jun 2008 10:17:19 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5O8HJD7031516; Tue, 24 Jun 2008 10:17:19 +0200 Date: Tue, 24 Jun 2008 10:17:19 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com Cc: mj@mjturner.net X-ASG-Orig-Subj: Re: [PATCH] don't update mtime on rename source Subject: Re: [PATCH] don't update mtime on rename source Message-ID: <20080624081719.GA31440@lst.de> References: <20080624081348.GA31048@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080624081348.GA31048@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: 1214295451 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.54190 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: 16511 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 Sorry for the missing subject, should be the one in this mail On Tue, Jun 24, 2008 at 10:13:48AM +0200, Christoph Hellwig wrote: > As reported by Michael-John Turner XFS updates the mtime on the source > inode of a rename call in case it's a directory and changes the parent. > > This doesn't make any sense, is not mentioned in the standards and not > performed by any other Linux filesystems so remove it. > > > (resending this as it might have been lost in the previous thread) > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/xfs_rename.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_rename.c 2008-06-18 18:24:38.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_rename.c 2008-06-18 18:30:17.000000000 +0200 > @@ -336,22 +336,18 @@ xfs_rename( > ASSERT(error != EEXIST); > if (error) > goto abort_return; > - xfs_ichgtime(src_ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); > - > - } else { > - /* > - * We always want to hit the ctime on the source inode. > - * We do it in the if clause above for the 'new_parent && > - * src_is_directory' case, and here we get all the other > - * cases. This isn't strictly required by the standards > - * since the source inode isn't really being changed, > - * but old unix file systems did it and some incremental > - * backup programs won't work without it. > - */ > - xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG); > } > > /* > + * We always want to hit the ctime on the source inode. > + * > + * This isn't strictly required by the standards since the source > + * inode isn't really being changed, but old unix file systems did > + * it and some incremental backup programs won't work without it. > + */ > + xfs_ichgtime(src_ip, XFS_ICHGTIME_CHG); > + > + /* > * Adjust the link count on src_dp. This is necessary when > * renaming a directory, either within one parent when > * the target existed, or across two parent directories. ---end quoted text--- From owner-xfs@oss.sgi.com Tue Jun 24 02:30:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 02:30:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5O9UFaM018419 for ; Tue, 24 Jun 2008 02:30:16 -0700 X-ASG-Debug-ID: 1214299873-54e903510000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3CD5A26F3CD for ; Tue, 24 Jun 2008 02:31:14 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id xcoA0GE567tYTC0E for ; Tue, 24 Jun 2008 02:31:14 -0700 (PDT) Received: from nb27steigerwald.qs.de (unknown [212.204.70.254]) by mail.lichtvoll.de (Postfix) with ESMTP id A682B5ADEF for ; Tue, 24 Jun 2008 11:27:46 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: md raid1 passes barriers, but xfs doesn't use them? Subject: Re: md raid1 passes barriers, but xfs doesn't use them? Date: Tue, 24 Jun 2008 11:31:11 +0200 User-Agent: KMail/1.9.9 References: <48605A8E.9070903@sandeen.net> (sfid-20080624_084605_814814_B137A507) In-Reply-To: <48605A8E.9070903@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806241131.12112.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1214299875 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.54193 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: 16512 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Hi Eric! Am Dienstag 24 Juni 2008 schrieb Eric Sandeen: > So md raid1 is happy to pass down any barrier writes that it sees, but > this bit in xfs_mountfs_check_barriers() at mount time: Interesting. Since when? On my last test also ext3 disabled barries over device mapper / reiserfs[1]. well but I used it with LVM, maybe its different with RAID 1. I thought this to be a generic device mapper issue. Did you test with ext3 too? [1] http://bugzilla.kernel.org/show_bug.cgi?id=9554 Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Jun 24 06:33:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 06:33:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5ODXdpD011162 for ; Tue, 24 Jun 2008 06:33:41 -0700 X-ASG-Debug-ID: 1214314470-01b602550000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 74DDB1811135 for ; Tue, 24 Jun 2008 06:34:30 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id rhajC7I21ms9QHxD for ; Tue, 24 Jun 2008 06:34:30 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 4F9E8A9BF45; Tue, 24 Jun 2008 08:34:29 -0500 (CDT) Message-ID: <4860F7E4.2080106@sandeen.net> Date: Tue, 24 Jun 2008 08:34:28 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Martin Steigerwald CC: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: md raid1 passes barriers, but xfs doesn't use them? Subject: Re: md raid1 passes barriers, but xfs doesn't use them? References: <48605A8E.9070903@sandeen.net> (sfid-20080624_084605_814814_B137A507) <200806241131.12112.Martin@lichtvoll.de> In-Reply-To: <200806241131.12112.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214314476 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.54208 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: 16513 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Martin Steigerwald wrote: > Hi Eric! > > Am Dienstag 24 Juni 2008 schrieb Eric Sandeen: >> So md raid1 is happy to pass down any barrier writes that it sees, but >> this bit in xfs_mountfs_check_barriers() at mount time: > > Interesting. Since when? Which part? :) XFS has done the flag check for a very long time... > On my last test also ext3 disabled barries over device mapper / > reiserfs[1]. well but I used it with LVM, maybe its different with RAID > 1. I thought this to be a generic device mapper issue. > > Did you test with ext3 too? This is xfs-specific; ext3 does not look for the queue ordered flag so won't have this problem on md raid1. > [1] http://bugzilla.kernel.org/show_bug.cgi?id=9554 but that's for device-mapper, which has never supported barriers .... I'm talking about md raid1 here (not dm). -Eric > Ciao, From owner-xfs@oss.sgi.com Tue Jun 24 07:24:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 07:24:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5OEOJq3016400 for ; Tue, 24 Jun 2008 07:24:20 -0700 X-ASG-Debug-ID: 1214317519-20f303190000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 02CA1181153C for ; Tue, 24 Jun 2008 07:25:19 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id nDAP7uDmrNyhJlcM for ; Tue, 24 Jun 2008 07:25:19 -0700 (PDT) Received: from nb27steigerwald.qs.de (unknown [212.204.70.254]) by mail.lichtvoll.de (Postfix) with ESMTP id 9B3F95ADEF; Tue, 24 Jun 2008 16:21:51 +0200 (CEST) From: Martin Steigerwald To: linux-xfs@oss.sgi.com X-ASG-Orig-Subj: Re: md raid1 passes barriers, but xfs doesn't use them? Subject: Re: md raid1 passes barriers, but xfs doesn't use them? Date: Tue, 24 Jun 2008 16:25:17 +0200 User-Agent: KMail/1.9.9 Cc: Eric Sandeen References: <48605A8E.9070903@sandeen.net> <200806241131.12112.Martin@lichtvoll.de> <4860F7E4.2080106@sandeen.net> (sfid-20080624_161808_555876_E63DCB9F) In-Reply-To: <4860F7E4.2080106@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806241625.17511.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1214317520 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.54212 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: 16514 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Am Dienstag 24 Juni 2008 schrieb Eric Sandeen: > Martin Steigerwald wrote: > > Hi Eric! [...] > > Did you test with ext3 too? > > This is xfs-specific; ext3 does not look for the queue ordered flag so > won't have this problem on md raid1. > > > [1] http://bugzilla.kernel.org/show_bug.cgi?id=9554 > > but that's for device-mapper, which has never supported barriers .... > I'm talking about md raid1 here (not dm). Thanks for the info. My misunderstanding - I always thought and I thought I even read it somewhere - that md was a device mapper application. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Tue Jun 24 09:30:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 09:30:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,MIME_BOUND_MANY_HEX 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 m5OGU7aN005555 for ; Tue, 24 Jun 2008 09:30:07 -0700 X-ASG-Debug-ID: 1214325057-10ce00ce0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gmail2616.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 2D2BDD3BDAC for ; Tue, 24 Jun 2008 09:31:00 -0700 (PDT) Received: from gmail2616.com (tselnode-053.telkomsel.co.id [221.132.214.53]) by cuda.sgi.com with SMTP id 7DshGfAe68ZaU65v for ; Tue, 24 Jun 2008 09:31:00 -0700 (PDT) From: Bunga Papan untuk Ucapan To: linux-xfs@oss.sgi.com Reply-To: bungapapan@gmail.com X-ASG-Orig-Subj: PERKENALAN : 'Sakura Florist" = menerima pesanan khusus bunga papan Subject: PERKENALAN : 'Sakura Florist" = menerima pesanan khusus bunga papan Date: Tue, 24 Jun 2008 23:31:02 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1cd1e24e-b230-4a5b-aa15-9254b2d12194" X-Barracuda-Connect: tselnode-053.telkomsel.co.id[221.132.214.53] X-Barracuda-Start-Time: 1214325067 Message-Id: <20080624163100.2D2BDD3BDAC@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.2699 1.0000 -0.4815 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.22 X-Barracuda-Spam-Status: No, SCORE=0.22 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MIME_BOUND_MANY_HEX, MSGID_FROM_MTA_ID X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_BOUND_MANY_HEX Spam tool pattern in MIME boundary 0.70 MSGID_FROM_MTA_ID Message-Id for external message added locally 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: 16515 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bungapapan@gmail.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format --1cd1e24e-b230-4a5b-aa15-9254b2d12194 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable PERKENALAN : 'Sakura Florist" =3D menerima pesanan khusus bunga papan Menerima pesanan khusus "Bunga Papan'' untuk ucapan selamat pernikahan, uca= pan belasungkawa, ucapan untuk peresmian usaha, ulang tahun, dll untuk daer= ah jabodetabek. Harga mulai Rp.350.000,- Terimakasih, 021 93606390 0818745955 http://www.bungapapan.net/ email : bungapapan@gmail.com messenger : bungapapan@hotmail.com=20=20 --1cd1e24e-b230-4a5b-aa15-9254b2d12194-- From owner-xfs@oss.sgi.com Tue Jun 24 12:10:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 12:10: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=-0.5 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_MANY_HEX 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 m5OJALlw018763 for ; Tue, 24 Jun 2008 12:10:22 -0700 X-ASG-Debug-ID: 1214334655-390c00ec0001-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gmail1650.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 3CAE2D3D1DA for ; Tue, 24 Jun 2008 12:11:09 -0700 (PDT) Received: from gmail1650.com (tselnode-053.telkomsel.co.id [221.132.214.53]) by cuda.sgi.com with SMTP id 0TthfeMVFJnKTxzl for ; Tue, 24 Jun 2008 12:11:09 -0700 (PDT) From: Bunga Papan untuk Ucapan To: linux-xfs@oss.sgi.com Reply-To: bungapapan@gmail.com X-ASG-Orig-Subj: PERKENALAN : 'Sakura Florist" = menerima pesanan khusus bunga papan Subject: PERKENALAN : 'Sakura Florist" = menerima pesanan khusus bunga papan Date: Wed, 25 Jun 2008 02:11:15 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="d5951ffd-aa63-41c8-abcf-2061cc7c4632" X-Barracuda-Connect: tselnode-053.telkomsel.co.id[221.132.214.53] X-Barracuda-Start-Time: 1214334681 Message-Id: <20080624191109.3CAE2D3D1DA@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.2165 1.0000 -0.7421 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.04 X-Barracuda-Spam-Status: No, SCORE=-0.04 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MIME_BOUND_MANY_HEX, MSGID_FROM_MTA_ID X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54231 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_BOUND_MANY_HEX Spam tool pattern in MIME boundary 0.70 MSGID_FROM_MTA_ID Message-Id for external message added locally 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: 16516 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bungapapan@gmail.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format --d5951ffd-aa63-41c8-abcf-2061cc7c4632 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable PERKENALAN : 'Sakura Florist" =3D menerima pesanan khusus bunga papan Menerima pesanan khusus "Bunga Papan'' untuk ucapan selamat pernikahan, uca= pan belasungkawa, ucapan untuk peresmian usaha, ulang tahun, dll untuk daer= ah jabodetabek. Harga mulai Rp.350.000,- Terimakasih, 021 93606390 0818745955 http://www.bungapapan.net/ email : bungapapan@gmail.com messenger : bungapapan@hotmail.com=20=20 --d5951ffd-aa63-41c8-abcf-2061cc7c4632-- From owner-xfs@oss.sgi.com Tue Jun 24 14:37:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 14:37:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53 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 m5OLbmQ6002223 for ; Tue, 24 Jun 2008 14:37:48 -0700 X-ASG-Debug-ID: 1214343528-7dd502320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp1.linux-foundation.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2B1B6274EC2 for ; Tue, 24 Jun 2008 14:38:48 -0700 (PDT) Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by cuda.sgi.com with ESMTP id cy7lGWKweovJ27eY for ; Tue, 24 Jun 2008 14:38:48 -0700 (PDT) Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id m5OLcfZk005003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 14:38:42 -0700 Received: from akpm.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id m5OLce8f007461; Tue, 24 Jun 2008 14:38:40 -0700 Date: Tue, 24 Jun 2008 14:38:40 -0700 From: Andrew Morton To: Takashi Sato Cc: viro@ZenIV.linux.org.uk, linux-ext4@vger.kernel.org, xfs@oss.sgi.com, dm-devel@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: Re: [PATCH 0/3] freeze feature ver 1.6 Subject: Re: [PATCH 0/3] freeze feature ver 1.6 Message-Id: <20080624143840.c183d0d9.akpm@linux-foundation.org> In-Reply-To: <20080624155919t-sato@mail.jp.nec.com> References: <20080624155919t-sato@mail.jp.nec.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 X-Barracuda-Connect: smtp1.linux-foundation.org[140.211.169.13] X-Barracuda-Start-Time: 1214343529 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.54239 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: 16517 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: xfs On Tue, 24 Jun 2008 15:59:19 +0900 Takashi Sato wrote: > Hi Andrew and Alexander, > > I have implemented the ioctls for the filesystem freeze feature > and discussed its implementation on the ML (linux-ext4, xfs, > linux-fsdevel, linux-kernel) for five months. All of the comments are > addressed in my patch-set. > Could you consider merging it into Linux? > > The filesystem freeze feature can suspend accesses to the filesystem > keeping the filesystem's consistency. We can take the consistent backup > with it cooperating with the backup software. > > The patches are re-based from linux-2.6.26-rc3 to linux-2.6.26-rc7 > There is no functional change from the previous version. > The patch-set consists of the following three patches. > > [PATCH 1/3] Implement generic freeze feature > I have modified to set the suitable error number (EOPNOTSUPP) > in case the filesystem doesn't support the freeze feature. > > The ioctls for the generic freeze feature are below. > o Freeze the filesystem > int ioctl(int fd, int FIFREEZE, arg) > fd: The file descriptor of the mountpoint > FIFREEZE: request code for the freeze > arg: Ignored > Return value: 0 if the operation succeeds. Otherwise, -1 > > o Unfreeze the filesystem > int ioctl(int fd, int FITHAW, arg) > fd: The file descriptor of the mountpoint > FITHAW: request code for unfreeze > arg: Ignored > Return value: 0 if the operation succeeds. Otherwise, -1 > > [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature > It removes XFS specific ioctl interfaces and request codes > for freeze feature. > This patch has been supplied by David Chinner. > > [PATCH 3/3] Add timeout feature > The timeout feature is added to freeze ioctl. And new ioctl > to reset the timeout period is added. > o Freeze the filesystem > int ioctl(int fd, int FIFREEZE, long *timeval) > fd: The file descriptor of the mountpoint > FIFREEZE: request code for the freeze > timeval: the timeout period in seconds > If it's 0 or 1, the timeout isn't set. > This special case of "1" is implemented to keep > the compatibility with XFS applications. > Return value: 0 if the operation succeeds. Otherwise, -1 > > o Reset the timeout period > This is useful for the application to set the timeval more accurately. > For example, the freezer resets the timeval to 10 seconds every 5 > seconds. In this approach, even if the freezer causes a deadlock > by accessing the frozen filesystem, it will be solved by the timeout > in 10 seconds and the freezer can recognize that at the next reset > of timeval. > int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeval) > fd:file descriptor of mountpoint > FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period > timeval: new timeout period in seconds > Return value: 0 if the operation succeeds. Otherwise, -1 > Error number: If the filesystem has already been unfrozen, > errno is set to EINVAL. > > Any comments are very welcome. umm, OK, but nowhere in this patch series can I find a justification or reason for making these changes to Linux. Why do we want to do this? What is the benefit? What is the motivation. What are the use-cases, etc? Thanks. From owner-xfs@oss.sgi.com Tue Jun 24 14:47:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 14:47:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_53 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 m5OLlZuI003592 for ; Tue, 24 Jun 2008 14:47:36 -0700 X-ASG-Debug-ID: 1214344115-707803350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp1.linux-foundation.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 242A4274CAB for ; Tue, 24 Jun 2008 14:48:35 -0700 (PDT) Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by cuda.sgi.com with ESMTP id cae5pEvl7KW6gh8w for ; Tue, 24 Jun 2008 14:48:35 -0700 (PDT) Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id m5OLm3jH005624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 14:48:04 -0700 Received: from akpm.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id m5OLm30m007859; Tue, 24 Jun 2008 14:48:03 -0700 Date: Tue, 24 Jun 2008 14:48:03 -0700 From: Andrew Morton To: Takashi Sato Cc: viro@ZenIV.linux.org.uk, linux-ext4@vger.kernel.org, xfs@oss.sgi.com, dm-devel@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: Re: [PATCH 1/3] Implement generic freeze feature Subject: Re: [PATCH 1/3] Implement generic freeze feature Message-Id: <20080624144803.0135a84d.akpm@linux-foundation.org> In-Reply-To: <20080624155950t-sato@mail.jp.nec.com> References: <20080624155950t-sato@mail.jp.nec.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 X-Barracuda-Connect: smtp1.linux-foundation.org[140.211.169.13] X-Barracuda-Start-Time: 1214344116 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54241 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16518 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: xfs On Tue, 24 Jun 2008 15:59:50 +0900 Takashi Sato wrote: > I have modified to set the suitable error number (EOPNOTSUPP) > in case the filesystem doesn't support the freeze feature. > This was pointed out by Andreas Dilger. > > The ioctls for the generic freeze feature are below. > o Freeze the filesystem > int ioctl(int fd, int FIFREEZE, arg) > fd: The file descriptor of the mountpoint > FIFREEZE: request code for the freeze > arg: Ignored > Return value: 0 if the operation succeeds. Otherwise, -1 > > o Unfreeze the filesystem > int ioctl(int fd, int FITHAW, arg) > fd: The file descriptor of the mountpoint > FITHAW: request code for unfreeze > arg: Ignored > Return value: 0 if the operation succeeds. Otherwise, -1 > > ... > > +/* > + * get_super_without_lock - Get super_block from block_device without lock. > + * @bdev: block device struct > + * > + * Scan the superblock list and finds the superblock of the file system > + * mounted on the block device given. This doesn't lock anyone. > + * %NULL is returned if no match is found. > + */ This is not a terribly good comment. Which lock are we not taking? I _assume_ that it's referring to s_umount? If so, the text should describe that. It should also go to some lengths explaining why this dangerous-looking and rather nasty-looking function exists. Look at it this way: there is no way in which the reviewer of this patch (ie: me) can work out why this function exists. Hence there will be no way in which future readers of this code will be able to work out why this function exists either. This is bad. These things should be described in code comments and in the changelog (whichever is most appropriate). > +struct super_block *get_super_without_lock(struct block_device *bdev) > +{ > + struct super_block *sb; > + > + if (!bdev) > + return NULL; > + > + spin_lock(&sb_lock); > + list_for_each_entry(sb, &super_blocks, s_list) { > + if (sb->s_bdev == bdev) { > + if (sb->s_root) { > + sb->s_count++; > + spin_unlock(&sb_lock); > + return sb; > + } > + } > + } > + spin_unlock(&sb_lock); > + return NULL; > +} > +EXPORT_SYMBOL(get_super_without_lock); From owner-xfs@oss.sgi.com Tue Jun 24 15:09:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 15:09: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.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53 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 m5OM91cA005448 for ; Tue, 24 Jun 2008 15:09:01 -0700 X-ASG-Debug-ID: 1214345400-7dd4039c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp1.linux-foundation.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 537D5275213 for ; Tue, 24 Jun 2008 15:10:00 -0700 (PDT) Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by cuda.sgi.com with ESMTP id v94XBGzPEvQgRkFk for ; Tue, 24 Jun 2008 15:10:00 -0700 (PDT) Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id m5OM9P0K007769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 15:09:27 -0700 Received: from akpm.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id m5OM9PWP008754; Tue, 24 Jun 2008 15:09:25 -0700 Date: Tue, 24 Jun 2008 15:09:25 -0700 From: Andrew Morton To: Takashi Sato Cc: viro@ZenIV.linux.org.uk, linux-ext4@vger.kernel.org, xfs@oss.sgi.com, dm-devel@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature Message-Id: <20080624150925.765155f0.akpm@linux-foundation.org> In-Reply-To: <20080624160056t-sato@mail.jp.nec.com> References: <20080624160056t-sato@mail.jp.nec.com> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 X-Barracuda-Connect: smtp1.linux-foundation.org[140.211.169.13] X-Barracuda-Start-Time: 1214345401 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.54241 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: 16519 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: xfs On Tue, 24 Jun 2008 16:00:56 +0900 Takashi Sato wrote: > The timeout feature is added to freeze ioctl. And new ioctl > to reset the timeout period is added. > o Freeze the filesystem > int ioctl(int fd, int FIFREEZE, long *timeval) > fd: The file descriptor of the mountpoint > FIFREEZE: request code for the freeze > timeval: the timeout period in seconds > If it's 0 or 1, the timeout isn't set. > This special case of "1" is implemented to keep > the compatibility with XFS applications. > Return value: 0 if the operation succeeds. Otherwise, -1 > > o Reset the timeout period > int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeval) > fd:file descriptor of mountpoint > FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period > timeval: new timeout period in seconds > Return value: 0 if the operation succeeds. Otherwise, -1 > Error number: If the filesystem has already been unfrozen, > errno is set to EINVAL. > Please avoid the use of the term `timeval' here. That term is closely associated with `struct timeval', and these are not being used here. A better identifier would be timeout_secs - it tells the reader what it does, and it tells the reader what units it is in. And when it comes to "time", it is very useful to tell people which units are being used, because there are many different ones. > > ... > > --- linux-2.6.26-rc7-xfs/fs/buffer.c 2008-06-23 11:55:15.000000000 +0900 > +++ linux-2.6.26-rc7-timeout/fs/buffer.c 2008-06-23 11:56:47.000000000 +0900 > @@ -190,14 +190,17 @@ int fsync_bdev(struct block_device *bdev > > /** > * freeze_bdev -- lock a filesystem and force it into a consistent state > - * @bdev: blockdevice to lock > + * @bdev: blockdevice to lock > + * @timeout_msec: timeout period > * > * This takes the block device bd_mount_sem to make sure no new mounts > * happen on bdev until thaw_bdev() is called. > * If a superblock is found on this device, we take the s_umount semaphore > * on it to make sure nobody unmounts until the snapshot creation is done. > + * If timeout_msec is bigger than 0, this registers the delayed work for > + * timeout of the freeze feature. > */ > -struct super_block *freeze_bdev(struct block_device *bdev) > +struct super_block *freeze_bdev(struct block_device *bdev, long timeout_msec) timeout_msec is good. > { > struct super_block *sb; > > @@ -234,6 +237,10 @@ struct super_block *freeze_bdev(struct b > } > > sync_blockdev(bdev); > + /* Setup unfreeze timer. */ > + if (timeout_msec > 0) > + add_freeze_timeout(bdev, timeout_msec); > + > clear_bit(BD_FREEZE_OP, &bdev->bd_state); > > return sb; /* thaw_bdev releases s->s_umount and bd_mount_sem */ > @@ -258,6 +265,9 @@ int thaw_bdev(struct block_device *bdev, > return 0; > } > > + /* Delete unfreeze timer. */ > + del_freeze_timeout(bdev); > + > if (sb) { > BUG_ON(sb->s_bdev != bdev); > > diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/ioctl.c linux-2.6.26-rc7-timeout/fs/io > ctl.c > --- linux-2.6.26-rc7-xfs/fs/ioctl.c 2008-06-23 11:55:15.000000000 +0900 > +++ linux-2.6.26-rc7-timeout/fs/ioctl.c 2008-06-23 11:56:47.000000000 +0900 > @@ -145,12 +145,16 @@ static int ioctl_fioasync(unsigned int f > * ioctl_freeze - Freeze the filesystem. > * > * @filp: target file > + * @argp: timeout value(sec) > * > * Call freeze_bdev() to freeze the filesystem. > */ > -static int ioctl_freeze(struct file *filp) > +static int ioctl_freeze(struct file *filp, unsigned long arg) > { > + long timeout_sec; > + long timeout_msec; > struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; > + int error; > > if (!capable(CAP_SYS_ADMIN)) > return -EPERM; > @@ -159,8 +163,27 @@ static int ioctl_freeze(struct file *fil > if (sb->s_op->write_super_lockfs == NULL) > return -EOPNOTSUPP; > > + /* arg(sec) to tick value. */ > + error = get_user(timeout_sec, (long __user *) arg); uh-oh, compat problems. A 32-bit application running under a 32-bit kernel will need to provide a 32-bit quantity. A 32-bit application running under a 64-bit kernel will need to provide a 64-bit quantity. I suggest that you go through the entire patch and redo this part of the kernel ABI in terms of __u32, and avoid any mention of "long" in the kernel<->userspace interface. > + if (error != 0) > + return error; > + /* > + * If 1 is specified as the timeout period, > + * it will be changed into 0 to keep the compatibility > + * of XFS application(xfs_freeze). > + */ > + if (timeout_sec < 0) > + return -EINVAL; > + else if (timeout_sec < 2) > + timeout_sec = 0; The `else' is unneeded. It would be clearer to code this all as: if (timeout_sec < 0) return -EINVAL; if (timeout_sec == 1) { /* * If 1 is specified as the timeout period it is changed into 0 * to retain compatibility with XFS's xfs_freeze. */ timeout_sec = 0; } > + timeout_msec = timeout_sec * 1000; > + /* overflow case */ > + if (timeout_msec < 0) > + return -EINVAL; > + > /* Freeze */ > - sb = freeze_bdev(sb->s_bdev); > + sb = freeze_bdev(sb->s_bdev, timeout_msec); > if (IS_ERR(sb)) > return PTR_ERR(sb); > return 0; > @@ -185,6 +208,51 @@ static int ioctl_thaw(struct file *filp) > } > > /* > + * ioctl_freeze_reset_timeout - Reset timeout for freeze. > + * > + * @filp: target file > + * @argp: timeout value(sec) > + * > + * Rest timeout for freeze. typo > + */ > +static int > +ioctl_freeze_reset_timeout(struct file *filp, unsigned long arg) > +{ > + long timeout_sec; > + long timeout_msec; > + struct super_block *sb > + = filp->f_path.dentry->d_inode->i_sb; Unneeded linebreak there. > + int error; > + > + if (!capable(CAP_SYS_ADMIN)) > + return -EPERM; > + > + /* arg(sec) to tick value */ > + error = get_user(timeout_sec, (long __user *) arg); compat issues. > + if (error) > + return error; > + timeout_msec = timeout_sec * 1000; > + if (timeout_msec < 0) > + return -EINVAL; um, OK, but timeout_msec could have overflowed during the multiplication and could be complete garbage. I guess it doesn't matter much, but a cleaner approach might be: if (timeout_sec > LONG_MAX/1000) return -EINVAL; or something like that. But otoh, why do the multiplication at all? If we're able to handle the timeout down to the millisecond level, why not offer that resolution to userspace? Offer the increased time granularity to the application? > + if (sb) { Can this happen? > + if (test_and_set_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state)) > + return -EBUSY; > + if (sb->s_frozen == SB_UNFROZEN) { > + clear_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state); > + return -EINVAL; > + } > + /* setup unfreeze timer */ > + if (timeout_msec > 0) What does this test do? afacit it's special-casing the timeout_secs==0 case. Was this feature documented? What does it do? > + add_freeze_timeout(sb->s_bdev, > + timeout_msec); > + clear_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state); > + } > + > + return 0; > +} > + > > ... > > +void add_freeze_timeout(struct block_device *bdev, long timeout_msec) > +{ > + s64 timeout_jiffies = msecs_to_jiffies(timeout_msec); > + > + /* Set delayed work queue */ > + cancel_delayed_work(&bdev->bd_freeze_timeout); Should this have used cancel_delayed_work_sync()? > + schedule_delayed_work(&bdev->bd_freeze_timeout, timeout_jiffies); > +} > + > +/* > + * del_freeze_timeout - Delete timeout for freeze. > + * > + * @bdev: block device struct > + * > + * Delete the delayed work for freeze timeout from the delayed work queue. > + */ > +void del_freeze_timeout(struct block_device *bdev) > +{ > + if (delayed_work_pending(&bdev->bd_freeze_timeout)) Is this test needed? > + cancel_delayed_work(&bdev->bd_freeze_timeout); cancel_delayed_work_sync()? > +} > diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/xfs/xfs_fsops.c linux-2.6.26-rc7-timeo > ut/fs/xfs/xfs_fsops.c > --- linux-2.6.26-rc7-xfs/fs/xfs/xfs_fsops.c 2008-06-23 11:55:15.000000000 +0900 > +++ linux-2.6.26-rc7-timeout/fs/xfs/xfs_fsops.c 2008-06-23 11:56:47.000000000 +0900 > @@ -619,7 +619,7 @@ xfs_fs_goingdown( > { > switch (inflags) { > case XFS_FSOP_GOING_FLAGS_DEFAULT: { > - struct super_block *sb = freeze_bdev(mp->m_super->s_bdev); > + struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, 0); Using NULL here is clearer and will, I expect, avoid a sparse warning. > > ... > From owner-xfs@oss.sgi.com Tue Jun 24 15:44:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 15:44:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44, J_CHICKENPOX_45,J_CHICKENPOX_47 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 m5OMicap008802 for ; Tue, 24 Jun 2008 15:44:39 -0700 X-ASG-Debug-ID: 1214347537-228903cf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E115227547C for ; Tue, 24 Jun 2008 15:45:38 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id lEecNMB425yDIw5p for ; Tue, 24 Jun 2008 15:45:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FABkVYUh5LG+uWmdsb2JhbACSZwEdoEw+ X-IronPort-AV: E=Sophos;i="4.27,698,1204464600"; d="scan'208";a="134519317" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 25 Jun 2008 08:15:34 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBHGX-0006o2-DF; Wed, 25 Jun 2008 08:45:33 +1000 Date: Wed, 25 Jun 2008 08:45:33 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() Subject: Re: [PATCH 1/2] set minleft in xfs_bmbt_split() Message-ID: <20080624224533.GM29319@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <48605744.8070400@sgi.com> <20080624045841.GN16257@build-svl-1.agami.com> <4860847B.7070703@sgi.com> <20080624052556.GR16257@build-svl-1.agami.com> <48609152.7050208@sgi.com> <20080624062551.GU16257@build-svl-1.agami.com> <48609DD0.80604@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48609DD0.80604@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214347538 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.54242 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: 16520 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Tue, Jun 24, 2008 at 05:10:08PM +1000, Lachlan McIlroy wrote: [....] > This is the fallback code. Do you think I also need to make the same > minleft change above and this change below to xfs_bmbt_newroot()? > > I'm inclined to change both xfs_bmbt_split() and xfs_bmbt_newroot() > and keep them as similar as possible. For the newroot case we know we > only need one block and we know there will be no more allocations for > this insert so using 'minleft = xfs_trans_get_block_res()' is silly but > on the other hand we don't have any other way to detect the double > insert case. OTOH, if we do a double insert, is it even possible for that to trigger a full tree double split? i.e. after the first split that allocates a new root, the new root will only be partially full, so we should be able to insert there in all cases without a split on the second insert. The case of a second split occurring is when the second insert goes into a different leaf block to the first insert and that needs splitting as well. If it's a completely different path up to the root of the tree, then the place where they will join is the old root block (remember that the new root block contains the old contents of the inode fork - it's not really a split but a move operation) and so a second newroot allocation will not be necessary. Hence I think that the newroot allocation will never be triggered twice in the unwritten extent double insert case. *However*, if the newroot function is first allocation, it still may need to take into account the second insert which may split a leaf as well. I don't think this can happen - the only time we'll do a newroot allocation without having first done an allocation in xfs_bmbt_split() is when adding an attribute fork and we need to push the data fork root out to make room for the attr fork. In this case, we don't have a split occurring at all and so we only need one block for the new root. Hence I don't think the newroot case needs to reserve space for entire splits or multiple splits at all - if that is going to happen it should already have been taken into account by earlier allocations... > --- 2.6.x-agno2.orig/fs/xfs/xfs_bmap_btree.c > +++ 2.6.x-agno2/fs/xfs/xfs_bmap_btree.c > @@ -1525,6 +1525,21 @@ xfs_bmbt_split( > XFS_BMBT_TRACE_CURSOR(cur, ERROR); > return error; > } > + if (args.fsbno == NULLFSBLOCK && args.minleft) { > + /* > + * Could not find an AG will enough free space to satisfy > + * a full btree split. Try again without minleft and if > + * successful activate the lowspace algorithm. > + */ > + args.fsbno = 0; > + args.type = XFS_ALLOCTYPE_FIRST_AG; > + args.minleft = 0; > + if ((error = xfs_alloc_vextent(&args))) { > + XFS_BMBT_TRACE_CURSOR(cur, ERROR); > + return error; > + } > + cur->bc_private.b.flist->xbf_low = 1; > + } Yes, that change makes sense for the split case. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 24 15:56:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 15:56:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5OMuTuV010116 for ; Tue, 24 Jun 2008 15:56:30 -0700 X-ASG-Debug-ID: 1214348248-21e803170000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3319F1802087 for ; Tue, 24 Jun 2008 15:57:28 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id r63WJ28vdkrkZolz for ; Tue, 24 Jun 2008 15:57:28 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FAJwYYUh5LG+uWmdsb2JhbACSZwEdoDQ X-IronPort-AV: E=Sophos;i="4.27,698,1204464600"; d="scan'208";a="134526278" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 25 Jun 2008 08:27:26 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBHS0-00072u-SC; Wed, 25 Jun 2008 08:57:24 +1000 Date: Wed, 25 Jun 2008 08:57:24 +1000 From: Dave Chinner To: Eric Sandeen Cc: LinuxRaid , xfs-oss X-ASG-Orig-Subj: Re: md raid1 passes barriers, but xfs doesn't use them? Subject: Re: md raid1 passes barriers, but xfs doesn't use them? Message-ID: <20080624225724.GN29319@disturbed> Mail-Followup-To: Eric Sandeen , LinuxRaid , xfs-oss References: <48605A8E.9070903@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48605A8E.9070903@sandeen.net> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214348250 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.54245 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: 16521 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 23, 2008 at 09:23:10PM -0500, Eric Sandeen wrote: > So md raid1 is happy to pass down any barrier writes that it sees, but > this bit in xfs_mountfs_check_barriers() at mount time: > > if (mp->m_ddev_targp->bt_bdev->bd_disk->queue->ordered == > QUEUE_ORDERED_NONE) { > xfs_fs_cmn_err(CE_NOTE, mp, > "Disabling barriers, not supported by the underlying > device"); > mp->m_flags &= ~XFS_MOUNT_BARRIER; > return; > } > > winds up with XFS disabling barriers on these devices. However, if this > is simply commented out, XFS happily tests barriers, finds that they > work, leaves them turned on and all subsequent barrier writes to the > device succeed. > > Perhaps what we have here is a failure to communicate? :) What we have is MD doing something strange and non-standard to implement barriers on RAID1. All other devices that support barriers define the barrier implementation as something other than QUEUE_ORDERED_NONE. > I'm not sure; *should* XFS be looking for a QUEUE_ORDERED tag? It was put there for some reason - now lost in the mists of time, I think. I suspect it was for detecting volume managers that didn't support barriers properly and weren't returning the correct errors to barrier I/O.... > Should MD be setting one? If it supports barriers, then it probably should be. > Maybe there should be a QUEUE_ORDERED_PASSTHRU flag? > Or should XFS just stick with the test write and ignore the flag? I'm > not sure of the queue->ordered flag details, but it seems that XFS & md > raid1 both try hard to keep barriers in force, and there's a disconnect > here somewhere. Yeah, the problem was that last time this check was removed was that a bunch of existing hardware had barriers enabled on them when not necessary (e.g. had NVRAM) and they went 5x slower on MD raid1 devices. Having to change the root drive config on a wide install base was considered much more of support pain than leaving the check there. I guess that was more of a distro upgrade issue than a mainline problem, but that's the history. Hence I think we should probably do whatever everyone else is doing here.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jun 24 17:17:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 17:17:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5P0Hcbv021296 for ; Tue, 24 Jun 2008 17:17:38 -0700 X-ASG-Debug-ID: 1214353115-7e1303420000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id ACF0B275912 for ; Tue, 24 Jun 2008 17:18:36 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id LvsxDrTfEesHvOTR for ; Tue, 24 Jun 2008 17:18:36 -0700 (PDT) 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 KAA04309; Wed, 25 Jun 2008 10:18:29 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id B60BD58C4C3F; Wed, 25 Jun 2008 10:18:29 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com X-ASG-Orig-Subj: TAKE 983677 - check for invalid flags in xfs_attrlist_by_handle Subject: TAKE 983677 - check for invalid flags in xfs_attrlist_by_handle Message-Id: <20080625001829.B60BD58C4C3F@chook.melbourne.sgi.com> Date: Wed, 25 Jun 2008 10:18:29 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1214353118 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.54249 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: 16522 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 Check for invalid flags in xfs_attrlist_by_handle. xfs_attrlist_by_handle should only take the ATTR_ flags for the root namespaces. The ATTR_KERN* flags may change at anytime and expect special preconditions that can't be guaranteed for userspace-originating requests. For example passing down ATTR_KERNNOVAL through xfs_attrlist_by_handle will hit an assert in debug builds currently. Signed-off-by: Christoph Hellwig Date: Wed Jun 25 10:17:00 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31351a fs/xfs/linux-2.6/xfs_ioctl.c - 1.166 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.166&r2=text&tr2=1.165&f=h - check for invalid flags in xfs_attrlist_by_handle From owner-xfs@oss.sgi.com Tue Jun 24 17:45:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 17:45:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5P0jZks023834 for ; Tue, 24 Jun 2008 17:45:36 -0700 X-ASG-Debug-ID: 1214354793-4898015a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from larry.melbourne.sgi.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 03093181D0F0 for ; Tue, 24 Jun 2008 17:46:34 -0700 (PDT) Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by cuda.sgi.com with SMTP id C7GWoKRmBortJt9b for ; Tue, 24 Jun 2008 17:46:34 -0700 (PDT) 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 KAA04972; Wed, 25 Jun 2008 10:46:29 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id D88AB58C4C3F; Wed, 25 Jun 2008 10:46:28 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: TAKE 983508 - attrmulti cleanup Subject: TAKE 983508 - attrmulti cleanup Message-Id: <20080625004628.D88AB58C4C3F@chook.melbourne.sgi.com> Date: Wed, 25 Jun 2008 10:46:28 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Barracuda-Connect: larry.melbourne.sgi.com[134.14.52.130] X-Barracuda-Start-Time: 1214354796 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.54250 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: 16523 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 xfs_attrmulti_by_handle currently request the size based on sizeof(attr_multiop_t) but should be using sizeof(xfs_attr_multiop_t) because that is what it is dealing with. Despite beeing wrong this actually harmless in practice because both structures are the same size on all platforms. But this sizeof was the only user of struct attr_multiop so we can just kill it. Also move the ATTR_OP_* defines xfs_attr.h into the struct xfs_attr_multiop defintion in xfs_fs.h because they are only used with that structure, and are part of the user ABI for the XFS_IOC_ATTRMULTI_BY_HANDLE ioctl. Signed-off-by: Christoph Hellwig Date: Wed Jun 25 10:45:34 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31352a fs/xfs/xfs_fs.h - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_fs.h.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h - attrmulti cleanup fs/xfs/xfs_attr.h - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_attr.h.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h - attrmulti cleanup fs/xfs/linux-2.6/xfs_ioctl.c - 1.167 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_ioctl.c.diff?r1=text&tr1=1.167&r2=text&tr2=1.166&f=h - attrmulti cleanup From owner-xfs@oss.sgi.com Tue Jun 24 18:49:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 18:49:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5P1n5dd001595 for ; Tue, 24 Jun 2008 18:49:08 -0700 X-ASG-Debug-ID: 1214358601-09ef01370000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0FFED181D21F for ; Tue, 24 Jun 2008 18:50:02 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id yW6Ex8HsPWaugrtQ for ; Tue, 24 Jun 2008 18:50:02 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 14CECA84110; Tue, 24 Jun 2008 20:50:01 -0500 (CDT) Message-ID: <4861A447.5090208@sandeen.net> Date: Tue, 24 Jun 2008 20:49:59 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Eric Sandeen , LinuxRaid , xfs-oss X-ASG-Orig-Subj: Re: md raid1 passes barriers, but xfs doesn't use them? Subject: Re: md raid1 passes barriers, but xfs doesn't use them? References: <48605A8E.9070903@sandeen.net> <20080624225724.GN29319@disturbed> In-Reply-To: <20080624225724.GN29319@disturbed> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214358605 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.54255 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: 16524 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Dave Chinner wrote: > On Mon, Jun 23, 2008 at 09:23:10PM -0500, Eric Sandeen wrote: >> Maybe there should be a QUEUE_ORDERED_PASSTHRU flag? >> Or should XFS just stick with the test write and ignore the flag? I'm >> not sure of the queue->ordered flag details, but it seems that XFS & md >> raid1 both try hard to keep barriers in force, and there's a disconnect >> here somewhere. > > Yeah, the problem was that last time this check was removed was > that a bunch of existing hardware had barriers enabled on them when > not necessary (e.g. had NVRAM) and they went 5x slower on MD raid1 > devices. Hm, http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c#rev1.402, putting back what was removed in http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c#rev1.380 I guess. But this seems like a very weird argument to me. Whether a drive/raid has battery backed raid, is 1 spindle or 100, is connected to a UPS or whatnot really is orthogonal to what should be set on the queue flag... This should be an admin decision. Leaving it this way for this odd reason leaves smaller users w/ 2 raid1 spindles in the desktop box actually completely unable to use barriers even if they wanted to; removing the check at least lets the savvy admin mount with an option to turn them off. > Having to change the root drive config on a wide install > base was considered much more of support pain than leaving the > check there. I guess that was more of a distro upgrade issue than > a mainline problem, but that's the history. Hence I think we > should probably do whatever everyone else is doing here... I'll submit a patch to remove the check ;) -Eric > > Cheers, > > Dave. From owner-xfs@oss.sgi.com Tue Jun 24 20:01:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 20:01:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_50,SUBJ_FORWARDED 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 m5P31FS0012202 for ; Tue, 24 Jun 2008 20:01:15 -0700 X-ASG-Debug-ID: 1214362932-3ba103cd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ironport2.grupoeulen.cl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 879FB12CA3E6; Tue, 24 Jun 2008 20:02:13 -0700 (PDT) Received: from ironport2.grupoeulen.cl (201-236-78-85.static.tie.cl [201.236.78.85]) by cuda.sgi.com with ESMTP id 1dJsiKpHukdGxERJ; Tue, 24 Jun 2008 20:02:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowuAMdfOUjAqAkG/2dsb2JhbACMK59SfA X-IronPort-AV: E=Sophos;i="4.27,700,1204513200"; d="scan'208";a="2436713" Received: from stdm004.eulen.cl ([192.168.9.6]) by ironport2.grupoeulen.cl with ESMTP; 24 Jun 2008 23:00:19 -0400 Received: from ubbi.com.br ([201.95.226.42]) by stdm004.eulen.cl with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 23:07:52 -0400 Message-ID: <4115-220086325340906@ubbi.com.br> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #00F06206106618006920 X-Priority: 3 Reply-To: tudogratiswebsite@bol.com.br To: "undisclosed" From: "Martha G." X-ASG-Orig-Subj: Fw: Tudo Gratis Subject: Fw: Tudo Gratis Date: Wed, 25 Jun 2008 00:04:00 -0300 MIME-Version: 1.0 Content-type: text/plain; charset="windows-1252" X-OriginalArrivalTime: 25 Jun 2008 03:07:53.0272 (UTC) FILETIME=[A88F8B80:01C8D670] X-Barracuda-Connect: 201-236-78-85.static.tie.cl[201.236.78.85] X-Barracuda-Start-Time: 1214362935 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4984 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54258 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 m5P31GS0012209 X-archive-position: 16526 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: marthgds@ubbi.com.br Precedence: bulk X-list: xfs Pessoal, recebi este e-mail e estou repassando... --- Vocês sabiam que na internet existem sites que oferecem material de qualidade e de graça? Encontrei um site na internet que disponibiliza muito material de qualidade e de GRAÇA. O site é www.tudogratis.4d2.net Algumas apostilas oferecidas são: "Kit de Mágicas" "Guia de Sedução" "Curso de Auto-Hipnose" "Curso de Desenho" "Ringtones para celular" e várias outras... Esse é um material GRATUITO de qualidade que está praticamente esquecido na internet. Vamos repassar essa oportunidade aos nossos amigos e avisar o maior número de pessoas! Repetindo, o site é: www.tudogratis.4d2.net Abraços From owner-xfs@oss.sgi.com Tue Jun 24 20:00:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 20:00:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5P309U1011902 for ; Tue, 24 Jun 2008 20:00:09 -0700 X-ASG-Debug-ID: 1214362866-5b9100210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from itchy (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 88CD9181D56D for ; Tue, 24 Jun 2008 20:01:07 -0700 (PDT) Received: from itchy (itchy.melbourne.sgi.com [134.14.55.96]) by cuda.sgi.com with ESMTP id 1eB55DoGN3xi0ej0 for ; Tue, 24 Jun 2008 20:01:07 -0700 (PDT) Received: by itchy (Postfix, from userid 16403) id 973173A5D1; Wed, 25 Jun 2008 13:00:57 +1000 (EST) To: melbourne@sgi.com, local@sgi.com, xfs@sgi.com, guys@sgi.com, "p_bugpost.bug_groups.9:sgi.bugs.xfssgi.bugs.xfs"@engr.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: TAKE 976035 - streamline init/exit path Subject: TAKE 976035 - streamline init/exit path Message-Id: <20080625030057.973173A5D1@itchy> Date: Wed, 25 Jun 2008 13:00:57 +1000 (EST) From: xaiki@sgi.com (Niv Sardi) X-Barracuda-Connect: itchy.melbourne.sgi.com[134.14.55.96] X-Barracuda-Start-Time: 1214362869 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.54259 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: 16525 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs streamline init/exit path Currently the xfs module init/exit code is a mess. It's farmed out over a lot of function with very little error checking. This patch makes sure we propagate all initialization failures properly and clean up after them. Various runtime initializations are replaced with compile-time initializations where possible to make this easier. The exit path is similarly consolidated. There's now split out function to create/destroy the kmem zones and alloc/free the trace buffers. I've also changed the ktrace allocations to KM_MAYFAIL and handled errors resulting from that. And yes, we really should replace the XFS_*_TRACE ifdefs with a single XFS_TRACE.. Signed-off-by: Christoph Hellwig Signed-off-by: Niv Sardi Date: Wed Jun 25 12:59:48 AEST 2008 Workarea: itchy.melbourne.sgi.com:/home/xaiki/Wrk/git/pmod2git Inspected by: hch The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31354a fs/xfs/xfs_da_btree.c - 1.182 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_da_btree.c.diff?r1=text&tr1=1.182&r2=text&tr2=1.181&f=h fs/xfs/xfs_vfsops.c - 1.570 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_vfsops.c.diff?r1=text&tr1=1.570&r2=text&tr2=1.569&f=h fs/xfs/xfs_mount.h - 1.272 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.h.diff?r1=text&tr1=1.272&r2=text&tr2=1.271&f=h fs/xfs/xfs_error.c - 1.63 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.c.diff?r1=text&tr1=1.63&r2=text&tr2=1.62&f=h fs/xfs/xfs_error.h - 1.52 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_error.h.diff?r1=text&tr1=1.52&r2=text&tr2=1.51&f=h fs/xfs/support/uuid.h - 1.16 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/uuid.h.diff?r1=text&tr1=1.16&r2=text&tr2=1.15&f=h fs/xfs/support/uuid.c - 1.24 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/support/uuid.c.diff?r1=text&tr1=1.24&r2=text&tr2=1.23&f=h fs/xfs/linux-2.6/xfs_stats.c - 1.26 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_stats.c.diff?r1=text&tr1=1.26&r2=text&tr2=1.25&f=h fs/xfs/linux-2.6/xfs_stats.h - 1.18 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_stats.h.diff?r1=text&tr1=1.18&r2=text&tr2=1.17&f=h fs/xfs/linux-2.6/xfs_super.c - 1.432 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.432&r2=text&tr2=1.431&f=h fs/xfs/linux-2.6/xfs_sysctl.c - 1.46 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.c.diff?r1=text&tr1=1.46&r2=text&tr2=1.45&f=h fs/xfs/linux-2.6/xfs_sysctl.h - 1.31 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_sysctl.h.diff?r1=text&tr1=1.31&r2=text&tr2=1.30&f=h fs/xfs/xfs_mru_cache.c - 1.9 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mru_cache.c.diff?r1=text&tr1=1.9&r2=text&tr2=1.8&f=h fs/xfs/xfs_filestream.c - 1.8 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_filestream.c.diff?r1=text&tr1=1.8&r2=text&tr2=1.7&f=h From owner-xfs@oss.sgi.com Tue Jun 24 21:58:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 21: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.0 required=5.0 tests=BAYES_50,SUBJ_FORWARDED 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 m5P4wM1Q030759 for ; Tue, 24 Jun 2008 21:58:23 -0700 X-ASG-Debug-ID: 1214369961-4ee003c20000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ironport2.grupoeulen.cl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9C0EE276660 for ; Tue, 24 Jun 2008 21:59:21 -0700 (PDT) Received: from ironport2.grupoeulen.cl (201-236-78-85.static.tie.cl [201.236.78.85]) by cuda.sgi.com with ESMTP id QHVsT2J2tsW4DStl for ; Tue, 24 Jun 2008 21:59:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AowuAMdfOUjAqAkG/2dsb2JhbACMK59SfA X-IronPort-AV: E=Sophos;i="4.27,700,1204513200"; d="scan'208";a="2452570" Received: from stdm004.eulen.cl ([192.168.9.6]) by ironport2.grupoeulen.cl with ESMTP; 25 Jun 2008 00:57:28 -0400 Received: from ubbi.com.br ([201.95.226.42]) by stdm004.eulen.cl with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 01:05:02 -0400 Message-ID: <276806-2200863255138812@ubbi.com.br> X-EM-Version: 6, 0, 0, 4 X-EM-Registration: #00F06206106618006920 X-Priority: 3 Reply-To: tudogratiswebsite@bol.com.br To: "undisclosed" From: "Martha G." X-ASG-Orig-Subj: Fw: Tudo Gratis Subject: Fw: Tudo Gratis Date: Wed, 25 Jun 2008 02:01:38 -0300 MIME-Version: 1.0 Content-type: text/plain; charset="windows-1252" X-OriginalArrivalTime: 25 Jun 2008 05:05:02.0692 (UTC) FILETIME=[066BEA40:01C8D681] X-Barracuda-Connect: 201-236-78-85.static.tie.cl[201.236.78.85] X-Barracuda-Start-Time: 1214369962 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5013 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54267 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 m5P4wN1Q030761 X-archive-position: 16527 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: marthgds@ubbi.com.br Precedence: bulk X-list: xfs Pessoal, recebi este e-mail e estou repassando... --- Vocês sabiam que na internet existem sites que oferecem material de qualidade e de graça? Encontrei um site na internet que disponibiliza muito material de qualidade e de GRAÇA. O site é www.tudogratis.4d2.net Algumas apostilas oferecidas são: "Kit de Mágicas" "Guia de Sedução" "Curso de Auto-Hipnose" "Curso de Desenho" "Ringtones para celular" e várias outras... Esse é um material GRATUITO de qualidade que está praticamente esquecido na internet. Vamos repassar essa oportunidade aos nossos amigos e avisar o maior número de pessoas! Repetindo, o site é: www.tudogratis.4d2.net Abraços From owner-xfs@oss.sgi.com Tue Jun 24 23:35:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 23:36:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53,RDNS_NONE,STOX_REPLY_TYPE 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 m5P6ZvNv007155 for ; Tue, 24 Jun 2008 23:35:57 -0700 X-ASG-Debug-ID: 1214375815-08d3011b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5D66C181E19D for ; Tue, 24 Jun 2008 23:36:55 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id 6uVGMqSB3AQHGH53 for ; Tue, 24 Jun 2008 23:36:55 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.193]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5P6af3B027944; Wed, 25 Jun 2008 15:36:41 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5P6aeb28862; Wed, 25 Jun 2008 15:36:40 +0900 (JST) Received: from saigo.jp.nec.com (saigo.jp.nec.com [10.26.220.6]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5P6aesh003538; Wed, 25 Jun 2008 15:36:40 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Wed, 25 Jun 2008 15:36:40 +0900 Message-Id: <27A96BE5FB224E9A876DA3326A6A6B27@nsl.ad.nec.co.jp> From: "Takashi Sato" To: "Andrew Morton" Cc: , , , , , , , References: <20080624155919t-sato@mail.jp.nec.com> <20080624143840.c183d0d9.akpm@linux-foundation.org> In-Reply-To: <20080624143840.c183d0d9.akpm@linux-foundation.org> X-ASG-Orig-Subj: Re: [PATCH 0/3] freeze feature ver 1.6 Subject: Re: [PATCH 0/3] freeze feature ver 1.6 Date: Wed, 25 Jun 2008 15:36:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1214375817 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.54273 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: 16528 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi, > umm, OK, but nowhere in this patch series can I find a justification or > reason for making these changes to Linux. Why do we want to do this? > What is the benefit? What is the motivation. What are the use-cases, > etc? Currently, ext3 in mainline Linux doesn't have the freeze feature which suspends write requests. So, we cannot take a backup which keeps the filesystem's consistency with the storage device's features (snapshot and replication) while it is mounted. In many case, a commercial filesystem (e.g. VxFS) has the freeze feature and it would be used to get the consistent backup. If Linux's standard filesytem ext3 has the freeze feature, we can do it without a commercial filesystem. So I have implemented the ioctls of the freeze feature. I think we can take the consistent backup with the following steps. 1. Freeze the filesystem with the freeze ioctl. 2. Separate the replication volume or create the snapshot with the storage device's feature. 3. Unfreeze the filesystem with the unfreeze ioctl. 4. Take the backup from the separated replication volume or the snapshot. Cheers, Takashi > On Tue, 24 Jun 2008 15:59:19 +0900 > Takashi Sato wrote: > >> Hi Andrew and Alexander, >> >> I have implemented the ioctls for the filesystem freeze feature >> and discussed its implementation on the ML (linux-ext4, xfs, >> linux-fsdevel, linux-kernel) for five months. All of the comments are >> addressed in my patch-set. >> Could you consider merging it into Linux? >> >> The filesystem freeze feature can suspend accesses to the filesystem >> keeping the filesystem's consistency. We can take the consistent backup >> with it cooperating with the backup software. >> >> The patches are re-based from linux-2.6.26-rc3 to linux-2.6.26-rc7 >> There is no functional change from the previous version. >> The patch-set consists of the following three patches. >> >> [PATCH 1/3] Implement generic freeze feature >> I have modified to set the suitable error number (EOPNOTSUPP) >> in case the filesystem doesn't support the freeze feature. >> >> The ioctls for the generic freeze feature are below. >> o Freeze the filesystem >> int ioctl(int fd, int FIFREEZE, arg) >> fd: The file descriptor of the mountpoint >> FIFREEZE: request code for the freeze >> arg: Ignored >> Return value: 0 if the operation succeeds. Otherwise, -1 >> >> o Unfreeze the filesystem >> int ioctl(int fd, int FITHAW, arg) >> fd: The file descriptor of the mountpoint >> FITHAW: request code for unfreeze >> arg: Ignored >> Return value: 0 if the operation succeeds. Otherwise, -1 >> >> [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature >> It removes XFS specific ioctl interfaces and request codes >> for freeze feature. >> This patch has been supplied by David Chinner. >> >> [PATCH 3/3] Add timeout feature >> The timeout feature is added to freeze ioctl. And new ioctl >> to reset the timeout period is added. >> o Freeze the filesystem >> int ioctl(int fd, int FIFREEZE, long *timeval) >> fd: The file descriptor of the mountpoint >> FIFREEZE: request code for the freeze >> timeval: the timeout period in seconds >> If it's 0 or 1, the timeout isn't set. >> This special case of "1" is implemented to keep >> the compatibility with XFS applications. >> Return value: 0 if the operation succeeds. Otherwise, -1 >> >> o Reset the timeout period >> This is useful for the application to set the timeval more accurately. >> For example, the freezer resets the timeval to 10 seconds every 5 >> seconds. In this approach, even if the freezer causes a deadlock >> by accessing the frozen filesystem, it will be solved by the timeout >> in 10 seconds and the freezer can recognize that at the next reset >> of timeval. >> int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeval) >> fd:file descriptor of mountpoint >> FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period >> timeval: new timeout period in seconds >> Return value: 0 if the operation succeeds. Otherwise, -1 >> Error number: If the filesystem has already been unfrozen, >> errno is set to EINVAL. >> >> Any comments are very welcome. > > umm, OK, but nowhere in this patch series can I find a justification or > reason for making these changes to Linux. Why do we want to do this? > What is the benefit? What is the motivation. What are the use-cases, > etc? > > Thanks. > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" 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 Tue Jun 24 23:47:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 24 Jun 2008 23:47:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5P6lD0i008299 for ; Tue, 24 Jun 2008 23:47:13 -0700 X-ASG-Debug-ID: 1214376492-7fb0017f0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta02.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F25FBD47F0B; Tue, 24 Jun 2008 23:48:12 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id U9SbEWS6lVoXelXM; Tue, 24 Jun 2008 23:48:12 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id ACC1B8E0072; Tue, 24 Jun 2008 23:50:30 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta02.pmc-sierra.bc.ca (Postfix) with SMTP id 442658E0070; Tue, 24 Jun 2008 23:50:26 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jun 2008 23:48:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-ASG-Orig-Subj: RE: Xfs Access to block zero exception and system crash Subject: RE: Xfs Access to block zero exception and system crash Date: Tue, 24 Jun 2008 23:48:36 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266701323BDB@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: AcjVyF6rnI622uINTByuCfed3R20HAAxvmBw References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> From: "Sagar Borikar" To: Cc: X-OriginalArrivalTime: 25 Jun 2008 06:48:37.0871 (UTC) FILETIME=[7EF4F7F0:01C8D68F] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.6.25.63620 X-PMC-SpamCheck: Gauge=IIIIIIIII, Probability=9%, Report='HASHBUSTER_BLOCK_V2 0.5, SUPERLONG_LINE 0.05, BODY_SIZE_10000_PLUS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HASHBUSTER_BLOCK_V2_1 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __OEM_PRICE 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __SXL_FUR_TIMEOUT , __SXL_RIP_TIMEOUT , __SXL_SIG_TIMEOUT ' X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1214376492 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.54274 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 m5P6lD0i008303 X-archive-position: 16529 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Sagar_Borikar@pmc-sierra.com Precedence: bulk X-list: xfs Hello, Can anyone help me out here? Thanks Sagar -----Original Message----- From: Sagar Borikar Sent: Tuesday, June 24, 2008 12:33 PM To: 'xfs@oss.sgi.com' Cc: Sagar Borikar Subject: Xfs Access to block zero exception and system crash Hello, I hope this is the right list to address this issue. If not please divert me to the right list. We are facing strange issue with xfs under heavy load. It's a NAS box with 2.6.18 kernel,128 MB of RAM, MIPS architecture and XFS version 2.8.11. NAS allows to create RAID1,RAID5 over XFS. The system is stable in general without any stress. We don't see any issues in day to day activities. But when it is exposed to stress with multiple iozone clients, it starts giving weird issues. The iozone stress test is ran with 15 CIFS clients, pumping data over 1GBps network, continuously for 48 hours as a part of calculating MTBF of the system, it crashes at different stages in different stimulus but in XFS only. A. Initially it used to give access to block zero exception and system used to crash for which I applied Nathan Scott's patch which removes the kernel panic when this situation is hit. http://oss.sgi.com/archives/xfs/2006-08/msg00073.html After back porting this patch, we observed that the system is not crashing but the warning messages are still coming. And after some time the system goes in soft lockup state and becomes non-responsive. I couldn't run the xfs_db or xfs_repair to check what is the state of the inode as console was not reachable after hitting the lockup state. Here is the log " Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 af Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 af Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 af Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 b0 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 b0 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 e7 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 e7 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 7 e7 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 8 20 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 8 20 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 68 extent-sta te: 1 lastx: 88d Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 68 extent-sta te: 1 lastx: 88d Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 68 extent-sta te: 1 lastx: 88d Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffc000000 blkcnt: 180 extent-st ate: 1 lastx: 88f Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffc000000 blkcnt: 180 extent-st ate: 1 lastx: 88f Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffc000000 blkcnt: 180 extent-st ate: 1 lastx: 88f Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 1a0 extent-st ate: 1 lastx: 891 Filesystem "dm-0": Access to block zero in inode 33554565 start_block: 0 start_off: 3ffffffe000000 blkcnt: 1a0 extent-st " Once we hit the soft lockup, system has to be rebooted as it is completely stalled and we can't even check which processes are running. I could be wrong but it was surprising to me that the same inode was referring to different offsets and blkcnt. It took 48 hours to reach this state and system had to be rebooted. B. In another DUT, the system just rebooted after displaying couple of warning messages without entering in soft lockup state. " Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inode 2097283 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 46 d Filesystem "dm-1": Access to block zero in inï PMON2000 MIPS Initializing. Standby... ERRORPC=bfc00004 CONFIG=0042e4bb STATUS=00400000 CPU PRID 000034c1, MaskID 00001320 Initializing caches...done (CONFIG=0042e4bb) Switching to runtime address map...done Setting up SDRAM controller: Manual SDRAM setup drive strength 0x000073c7 output timing 0x00000fca general config 0x80010000 master clock 100 Mhz, MulFundBIU 0x02, DivXSDRAM 0x02 sdram freq 0x09ef21aa hz, sdram period: 0x06 nsec " It took 43 hours to come to this state. C. In another stimulus, device driver mentioned that it can't access the block. Which means that filesystem got corrupted. I inferred that Filesystem was trying to reach block which is not existing in the disk. After some time, it recovers itself and starts giving weird issue. Finally it hits the memory access exception and system crashes. " Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 8 Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 8 Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 1 Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 1 Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1a 1 attempt to access beyond end of device dm-1: rw=0, want=1003118956380168, limit=8388608 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x39054d5100001 ("xfs_trans_read_buf") error 5 buf count 512 attempt to access beyond end of device dm-1: rw=0, want=1003118956380168, limit=8388608 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x39054d5100001 ("xfs_trans_read_buf") error 5 buf count 512 attempt to access beyond end of device dm-1: rw=0, want=1003118956380168, limit=8388608 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x39054d5100001 ("xfs_trans_read_buf") error 5 buf count 512 attempt to access beyond end of device dm-1: rw=0, want=1003118956380168, limit=8388608 I/O error in filesystem ("dm-1") meta-data dev dm-1 block 0x39054d5100001 ("xfs_trans_read_buf") error 5 buf count 512 attempt to access beyond end of device Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f e Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f e Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f f Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f f Filesystem "dm-1": Access to block zero in inode 2097284 start_block: 0 start_off: 0 blkcnt: 0 extent-state: 0 lastx: 1f f CPU 0 Unable to handle kernel paging request at virtual address 04e81080, epc == 802a90ac, ra == 802a9094 Oops[#1]: Cpu 0 $ 0 : 00000000 9000a001 84e81080 80000000 $ 4 : 82ce6dd0 00000000 ffffffff ffffffff $ 8 : 00086800 00000000 00086800 00000001 $12 : 00000004 34000000 82ce6c00 00000001 $16 : ffffffff 04e81080 34000000 81213978 $20 : 82ce6c00 82ce6dd0 00000000 34000000 $24 : 00086800 00000000 $28 : 81212000 81213878 00000000 802a9094 Hi : 00000000 Lo : 00036a20 epc : 802a90ac xfs_bmap_btalloc+0x33c/0x950 Not tainted ra : 802a9094 xfs_bmap_btalloc+0x324/0x950 Status: 9000a003 KERNEL EXL IE Cause : 00000008 BadVA : 04e81080 PrId : 000034c1 Modules linked in: aes autofs4 Process pdflush (pid: 66, threadinfo=81212000, task=8120b138) Stack : 81213880 811c9074 00000003 863af000 00000000 00000001 000000cb 805c1f90 812139b8 8616ece0 8538e6f8 82ce6c00 812139fc ffffffff 00086800 00000000 802aad9c 802aad80 8616ed30 00000001 8173c6f4 813cf200 812138d8 00000001 00000200 00000000 812139b8 00000004 81213a00 00000000 ffffffff ffffffff 00000000 00000000 00000001 00000000 00000000 81213a00 000002a3 81213ac0 ... Call Trace: [<802a90ac>] xfs_bmap_btalloc+0x33c/0x950 [<802a9700>] xfs_bmap_alloc+0x40/0x4c [<802acc9c>] xfs_bmapi+0x8d8/0x13e4 [<802d42d4>] xfs_iomap_write_allocate+0x3c0/0x5f4 [<802d2b28>] xfs_iomap+0x408/0x4dc [<802fe90c>] xfs_bmap+0x30/0x3c [<802f3cfc>] xfs_map_blocks+0x50/0x84 [<802f512c>] xfs_page_state_convert+0x3f4/0x840 [<802f565c>] xfs_vm_writepage+0xe4/0x140 [<80198758>] mpage_writepages+0x24c/0x45c [<802f56e8>] xfs_vm_writepages+0x30/0x3c [<801507b4>] do_writepages+0x44/0x84 [<80196628>] __sync_single_inode+0x68/0x234 [<80196980>] __writeback_single_inode+0x18c/0x1ac [<80196ba8>] sync_sb_inodes+0x208/0x2f0 [<80196d14>] writeback_inodes+0x84/0xd0 [<801503e0>] background_writeout+0xac/0xfc [<80151330>] __pdflush+0x130/0x228 [<80151458>] pdflush+0x30/0x3c [<801398bc>] kthread+0x98/0xe0 [<80104c38>] kernel_thread_helper+0x10/0x18 " In all the three cases, when I tried to perform the slower tests i.e. with 6 clients but with the same stimulus, there we re no exceptions and system was stable for 5 days. [root@Cousteau6 ~]# df -k Filesystem 1k-blocks Used Available Use% Mounted on /dev/scsibd2 41664 41664 0 100% / udev 62044 4 62040 0% /dev tmpfs 5120 3468 1652 68% /var tmpfs 62044 24 62020 0% /tmp tmpfs 128 4 124 3% /mnt /dev/mtdblock1 1664 436 1228 26% /linuxrwfs /dev/RAIDA/Volume1 10475520 624 10474896 0% /mnt/RAIDA/Volume1 /dev/RAIDA/Volume1 10475520 624 10474896 0% /mnt/ftp_dir/homes /dev/RAIDA/IOZONETEST 4184064 2479044 1705020 59% /mnt/RAIDA/IOZONETEST /dev/RAIDA/IOZONETEST 4184064 2479044 1705020 59% /mnt/ftp_dir/share1 /dev/RAIDA/Volume1 10475520 624 10474896 0% /mnt/ftp_dir/share2 Can anyone let me know what could be the probable cause of this issue. Thanks in advance Sagar From owner-xfs@oss.sgi.com Wed Jun 25 01:48:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 01:48:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 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 m5P8matI026134 for ; Wed, 25 Jun 2008 01:48:37 -0700 X-ASG-Debug-ID: 1214383776-271800860000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from build-svl-1.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 37BD4181E833 for ; Wed, 25 Jun 2008 01:49:36 -0700 (PDT) Received: from build-svl-1.agami.com (colo-nat-pool.agami.com [216.218.227.40]) by cuda.sgi.com with ESMTP id p7pdEUrfCh11BA10 for ; Wed, 25 Jun 2008 01:49:36 -0700 (PDT) Received: from build-svl-1.agami.com (localhost.localdomain [127.0.0.1]) by build-svl-1.agami.com (8.13.7/8.13.7) with ESMTP id m5P8nVMe020569; Wed, 25 Jun 2008 01:49:31 -0700 Received: (from dchinner@localhost) by build-svl-1.agami.com (8.13.7/8.13.7/Submit) id m5P8nVP6020567; Wed, 25 Jun 2008 01:49:31 -0700 X-Authentication-Warning: build-svl-1.agami.com: dchinner set sender to dchinner@agami.com using -f Date: Wed, 25 Jun 2008 01:49:31 -0700 From: Dave Chinner To: Sagar Borikar Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080625084931.GI16257@build-svl-1.agami.com> Mail-Followup-To: Sagar Borikar , xfs@oss.sgi.com References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> User-Agent: Mutt/1.4.2.3i X-Barracuda-Connect: colo-nat-pool.agami.com[216.218.227.40] X-Barracuda-Start-Time: 1214383777 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.54282 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: 16530 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Tue, Jun 24, 2008 at 12:03:16AM -0700, Sagar Borikar wrote: > > Hello, > > I hope this is the right list to address this issue. If not please divert me to the right list. > > We are facing strange issue with xfs under heavy load. It's a NAS > box with 2.6.18 kernel,128 MB of RAM, MIPS architecture and XFS > version 2.8.11. [...] > Can anyone let me know what could be the probable cause of this issue. they are all from corrupted extent btrees. There are many possible causes of this that we've fixed over the past years since 2.6.18 was released. Indeed, we are currently discussing fixes for a bunch of problems that lead to corrupted extent btrees and problems like this. I'd suggest that you should probably start with a more recent kernel, make sure you have a serial console and set the xfs_error_level to 11 so that it gives as much information as possible on the console when the error it hit. if that doesn't give a stack trace, then you need to set the xfs_panic_mask to crash the machine on block zero accesses and report the stack straces that it outputs... Cheers, Dave. -- Dave Chinner dchinner@agami.com From owner-xfs@oss.sgi.com Wed Jun 25 06:56:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 06:56:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5PDuJMo030752 for ; Wed, 25 Jun 2008 06:56:20 -0700 X-ASG-Debug-ID: 1214402240-4e1a01e40000-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 B8A33278E32; Wed, 25 Jun 2008 06:57:20 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id F4IZ0ubPpDSGZA7v; Wed, 25 Jun 2008 06:57:20 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBVUu-00088J-04; Wed, 25 Jun 2008 13:57:20 +0000 Date: Wed, 25 Jun 2008 09:57:19 -0400 From: Christoph Hellwig To: Niv Sardi Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 976035 - streamline init/exit path Subject: Re: TAKE 976035 - streamline init/exit path Message-ID: <20080625135719.GA30735@infradead.org> References: <20080625030057.973173A5D1@itchy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080625030057.973173A5D1@itchy> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214402240 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.54302 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: 16531 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Wed, Jun 25, 2008 at 01:00:57PM +1000, Niv Sardi wrote: > streamline init/exit path > > Currently the xfs module init/exit code is a mess. It's farmed out > over a lot of function with very little error checking. This patch > makes sure we propagate all initialization failures properly and clean > up after them. Various runtime initializations are replaced with > compile-time initializations where possible to make this easier. The > exit path is similarly consolidated. Umm, this has been in for a long time. Did the mail leave your mail queue only now? :) From owner-xfs@oss.sgi.com Wed Jun 25 07:42:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 07:42:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,SUBJ_MILLIONS 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 m5PEgQcC003596 for ; Wed, 25 Jun 2008 07:42:27 -0700 X-ASG-Debug-ID: 1214405005-05f402af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from deliver.uni-koblenz.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 09F342797F5 for ; Wed, 25 Jun 2008 07:43:26 -0700 (PDT) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by cuda.sgi.com with ESMTP id BeYHp0nDOrEDe9rc for ; Wed, 25 Jun 2008 07:43:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 9A4FD789A3EB for ; Wed, 25 Jun 2008 16:43:25 +0200 (CEST) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29723-02 for ; Wed, 25 Jun 2008 16:43:24 +0200 (CEST) Received: from bruch.uni-koblenz.de (bruch.uni-koblenz.de [141.26.64.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id 3D09E789A119 for ; Wed, 25 Jun 2008 16:43:24 +0200 (CEST) Message-ID: <4862598B.80905@uni-koblenz.de> Date: Wed, 25 Jun 2008 16:43:23 +0200 From: Christoph Litauer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Performance problems with millions of inodes Subject: Performance problems with millions of inodes Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at uni-koblenz.de X-Barracuda-Connect: deliver.uni-koblenz.de[141.26.64.15] X-Barracuda-Start-Time: 1214405007 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54303 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Status: Clean X-archive-position: 16532 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: litauer@uni-koblenz.de Precedence: bulk X-list: xfs Hi, sorry if this has been asked before, I am new to this mailing list. I didn't find any hints in the FAQ or by googling ... I have a backup server driving two kinds of backup software: bacula and backuppc. bacula saves it's backups on raid1, backuppc on raid2 (different hardware, but both fast hardware raids). I have massive performance problems with backuppc which I tracked down to performance problems of the filesystem on raid2 (I think so). The main difference between the two backup systems is that backuppc uses millions of inodes for it's backup (in fact it duplicates the directory structure of the backup client). raid1 consists of 91675 inodes, raid2 of 143646439. The filesystems were created without any options. raid1 is about 7 TB, raid2 about 10TB. Both filesystems are mounted with options '(rw,noatime,nodiratime,ihashsize=65536)'. I used bonnie++ to benchmark both filesystems. Here are the results of 'bonnie++ -u root -f -n 10:0:0:1000': raid1: ------------------- Sequential Output: 82505 K/sec Sequential Input : 102192 K/sec Sequential file creation: 7184/sec Random file creation : 17277/sec raid2: ------------------- Sequential Output: 124802 K/sec Sequential Input : 109158 K/sec Sequential file creation: 123/sec Random file creation : 138/sec As you can see, raid2's throughput is higher than raid1's. But the file creation times are rather slow ... Maybe the 143 million inodes cause this effect? Any idea how to avoid it? -- Regards Christoph ________________________________________________________________________ Christoph Litauer litauer@uni-koblenz.de Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311 PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2 From owner-xfs@oss.sgi.com Wed Jun 25 07:45:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 07:45:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_00,SUBJ_MILLIONS 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 m5PEjW3W004223 for ; Wed, 25 Jun 2008 07:45:32 -0700 X-ASG-Debug-ID: 1214405191-0deb00be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from deliver.uni-koblenz.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CE05ED49067 for ; Wed, 25 Jun 2008 07:46:32 -0700 (PDT) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by cuda.sgi.com with ESMTP id GfhbkyFBQT1DBQTO for ; Wed, 25 Jun 2008 07:46:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 80985789A6A0 for ; Wed, 25 Jun 2008 16:46:31 +0200 (CEST) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30132-04 for ; Wed, 25 Jun 2008 16:46:30 +0200 (CEST) Received: from bruch.uni-koblenz.de (bruch.uni-koblenz.de [141.26.64.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id 3DBC1789A633 for ; Wed, 25 Jun 2008 16:46:30 +0200 (CEST) Message-ID: <48625A46.1060206@uni-koblenz.de> Date: Wed, 25 Jun 2008 16:46:30 +0200 From: Christoph Litauer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Performance problems with millions of inodes Subject: Re: Performance problems with millions of inodes References: <4862598B.80905@uni-koblenz.de> In-Reply-To: <4862598B.80905@uni-koblenz.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at uni-koblenz.de X-Barracuda-Connect: deliver.uni-koblenz.de[141.26.64.15] X-Barracuda-Start-Time: 1214405192 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54305 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Status: Clean X-archive-position: 16533 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: litauer@uni-koblenz.de Precedence: bulk X-list: xfs Christoph Litauer schrieb: > Hi, > > sorry if this has been asked before, I am new to this mailing list. I > didn't find any hints in the FAQ or by googling ... > > I have a backup server driving two kinds of backup software: bacula and > backuppc. bacula saves it's backups on raid1, backuppc on raid2 > (different hardware, but both fast hardware raids). > I have massive performance problems with backuppc which I tracked down > to performance problems of the filesystem on raid2 (I think so). The > main difference between the two backup systems is that backuppc uses > millions of inodes for it's backup (in fact it duplicates the directory > structure of the backup client). > > raid1 consists of 91675 inodes, raid2 of 143646439. The filesystems were > created without any options. raid1 is about 7 TB, raid2 about 10TB. Both > filesystems are mounted with options > '(rw,noatime,nodiratime,ihashsize=65536)'. > > I used bonnie++ to benchmark both filesystems. Here are the results of > 'bonnie++ -u root -f -n 10:0:0:1000': > > raid1: > ------------------- > Sequential Output: 82505 K/sec > Sequential Input : 102192 K/sec > Sequential file creation: 7184/sec > Random file creation : 17277/sec > > raid2: > ------------------- > Sequential Output: 124802 K/sec > Sequential Input : 109158 K/sec > Sequential file creation: 123/sec > Random file creation : 138/sec > > As you can see, raid2's throughput is higher than raid1's. But the file > creation times are rather slow ... > > Maybe the 143 million inodes cause this effect? Any idea how to avoid it? > Just another (xfs_)info about raid2: meta-data=/dev/backuppc/backuppc isize=256 agcount=32, agsize=79691776 blks = sectsz=512 attr=0 data = bsize=4096 blocks=2550136832, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, rtextents=0 -- Regards Christoph ________________________________________________________________________ Christoph Litauer litauer@uni-koblenz.de Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311 PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2 From owner-xfs@oss.sgi.com Wed Jun 25 09:01:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 09:01: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=-1.6 required=5.0 tests=AWL,BAYES_00,SUBJ_MILLIONS 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 m5PG1L44017992 for ; Wed, 25 Jun 2008 09:01:21 -0700 X-ASG-Debug-ID: 1214409736-0aa103a70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 894C5D4CEEC for ; Wed, 25 Jun 2008 09:02:16 -0700 (PDT) Received: from smtp8-g19.free.fr (smtp8-g19.free.fr [212.27.42.65]) by cuda.sgi.com with ESMTP id byNDvuI5VRG7nG6f for ; Wed, 25 Jun 2008 09:02:16 -0700 (PDT) Received: from smtp8-g19.free.fr (localhost [127.0.0.1]) by smtp8-g19.free.fr (Postfix) with ESMTP id 0D0A217F591; Wed, 25 Jun 2008 18:02:16 +0200 (CEST) Received: from harpe.intellique.com (labo.djinux.com [82.225.196.72]) by smtp8-g19.free.fr (Postfix) with ESMTP id BA8B217F597; Wed, 25 Jun 2008 18:02:15 +0200 (CEST) Date: Wed, 25 Jun 2008 18:02:22 +0200 From: Emmanuel Florac To: Christoph Litauer Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Performance problems with millions of inodes Subject: Re: Performance problems with millions of inodes Message-ID: <20080625180222.12885793@harpe.intellique.com> In-Reply-To: <48625A46.1060206@uni-koblenz.de> References: <4862598B.80905@uni-koblenz.de> <48625A46.1060206@uni-koblenz.de> Organization: Intellique X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.9; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Barracuda-Connect: smtp8-g19.free.fr[212.27.42.65] X-Barracuda-Start-Time: 1214409742 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.54309 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 m5PG1L44017995 X-archive-position: 16534 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: eflorac@intellique.com Precedence: bulk X-list: xfs Le Wed, 25 Jun 2008 16:46:30 +0200 Christoph Litauer écrivait: > > > > Maybe the 143 million inodes cause this effect? Any idea how to > > avoid it? Maybe you should try to add a "nobarrier" option at mount on the slowest machine. Barriers can slow down operation tremendously... -- ---------------------------------------- Emmanuel Florac | Intellique ---------------------------------------- From owner-xfs@oss.sgi.com Wed Jun 25 09:59:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 10:00:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_00,SUBJ_MILLIONS 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 m5PGxrtl024548 for ; Wed, 25 Jun 2008 09:59:57 -0700 X-ASG-Debug-ID: 1214413251-149300cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34505.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 408F6D4D5B9 for ; Wed, 25 Jun 2008 10:00:51 -0700 (PDT) Received: from web34505.mail.mud.yahoo.com (web34505.mail.mud.yahoo.com [66.163.178.171]) by cuda.sgi.com with SMTP id BMtAGRk8vm6yuQkx for ; Wed, 25 Jun 2008 10:00:51 -0700 (PDT) Received: (qmail 67175 invoked by uid 60001); 25 Jun 2008 17:00:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=5qDWS4FlPKaSSojfylY4WZsPDm++/aNmTNjU7sMUgs6l+sjsxRXJCTfVZvlJIiwV4uNhasFGMX/S7+CzoDvqoCYkzP6gc9NpUEb4uOTdTLavFg6QNh3191Stl4JKYjivXkyX2gyn1PQAmVox8qMdfmQmAro0FkimMjh5bLcJZDQ=; Received: from [96.14.157.158] by web34505.mail.mud.yahoo.com via HTTP; Wed, 25 Jun 2008 10:00:50 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Wed, 25 Jun 2008 10:00:50 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: Performance problems with millions of inodes Subject: Re: Performance problems with millions of inodes To: Christoph Litauer , Emmanuel Florac Cc: xfs@oss.sgi.com In-Reply-To: <20080625180222.12885793@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <889832.67139.qm@web34505.mail.mud.yahoo.com> X-Barracuda-Connect: web34505.mail.mud.yahoo.com[66.163.178.171] X-Barracuda-Start-Time: 1214413253 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0035 1.0000 -1.9981 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54313 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: 16535 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs What type of RAID? If striping is involved, perhaps you should investigate the "su" and "sw" suboptions. I also found some performance improvement with "-l lazy-count=1", although you may not wish to slow down repair times for a backup volume. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Wed Jun 25 16:11:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 16:11:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SUBJ_MILLIONS 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 m5PNBLqb000484 for ; Wed, 25 Jun 2008 16:11:23 -0700 X-ASG-Debug-ID: 1214435539-6934024f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C6C63D52E04 for ; Wed, 25 Jun 2008 16:12:20 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id BVA9aAFbv831i2a1 for ; Wed, 25 Jun 2008 16:12:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEDAIttYkh5LG+uZWdsb2JhbACSXRICHqBL X-IronPort-AV: E=Sophos;i="4.27,704,1204464600"; d="scan'208";a="135381142" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 08:42:15 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBe9q-00058Q-Nc; Thu, 26 Jun 2008 09:12:10 +1000 Date: Thu, 26 Jun 2008 09:12:10 +1000 From: Dave Chinner To: Christoph Litauer Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Performance problems with millions of inodes Subject: Re: Performance problems with millions of inodes Message-ID: <20080625231210.GF11558@disturbed> Mail-Followup-To: Christoph Litauer , xfs@oss.sgi.com References: <4862598B.80905@uni-koblenz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4862598B.80905@uni-koblenz.de> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214435541 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54339 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16536 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Wed, Jun 25, 2008 at 04:43:23PM +0200, Christoph Litauer wrote: > Hi, > > sorry if this has been asked before, I am new to this mailing list. I > didn't find any hints in the FAQ or by googling ... > > I have a backup server driving two kinds of backup software: bacula and > backuppc. bacula saves it's backups on raid1, backuppc on raid2 > (different hardware, but both fast hardware raids). > I have massive performance problems with backuppc which I tracked down > to performance problems of the filesystem on raid2 (I think so). The > main difference between the two backup systems is that backuppc uses > millions of inodes for it's backup (in fact it duplicates the directory > structure of the backup client). > > raid1 consists of 91675 inodes, raid2 of 143646439. The filesystems were > created without any options. raid1 is about 7 TB, raid2 about 10TB. Both > filesystems are mounted with options > '(rw,noatime,nodiratime,ihashsize=65536)'. > > I used bonnie++ to benchmark both filesystems. Here are the results of > 'bonnie++ -u root -f -n 10:0:0:1000': > > raid1: > ------------------- > Sequential Output: 82505 K/sec > Sequential Input : 102192 K/sec > Sequential file creation: 7184/sec > Random file creation : 17277/sec > > raid2: > ------------------- > Sequential Output: 124802 K/sec > Sequential Input : 109158 K/sec > Sequential file creation: 123/sec > Random file creation : 138/sec > > As you can see, raid2's throughput is higher than raid1's. But the file > creation times are rather slow ... > > Maybe the 143 million inodes cause this effect? Certain will be. You've got about 3 AGs that are holding inodes, so that's probably 35M+ inodes per AG. With the way allocation works, it's probably doing a dual-traversal of the AGI btree to find a free inode "near" to the parent and that is consuming lots and lots of CPU time. > Any idea how to avoid it? I had a protoype patch back when I was at SGI than stopped this search when the search reached a radius that was no longer "near". This greatly reduced CPU time for allocation on large inode count AGs and hence create rates increased significantly. [Mark - IIRC that patch was in the miscellaneous patch tarball I left behind...] The only other way of dealing with this is to use inode64 so that inodes get spread across the entire filesystem instead of just a few AGs at the start of the filesystem. It's too late to change the existing inodes, but new inodes would get spread around.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jun 25 17:56:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 17:56:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5Q0uJpx016061 for ; Wed, 25 Jun 2008 17:56:19 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id DFDFC304081; Wed, 25 Jun 2008 17:57:14 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5Q0v6jm2258196; Thu, 26 Jun 2008 10:57:08 +1000 (AEST) From: Niv Sardi To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: TAKE 976035 - streamline init/exit path References: <20080625030057.973173A5D1@itchy> <20080625135719.GA30735@infradead.org> Date: Thu, 26 Jun 2008 10:56:51 +1000 In-Reply-To: <20080625135719.GA30735@infradead.org> (Christoph Hellwig's message of "Wed, 25 Jun 2008 09:57:19 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16537 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig writes: > On Wed, Jun 25, 2008 at 01:00:57PM +1000, Niv Sardi wrote: >> streamline init/exit path >> >> Currently the xfs module init/exit code is a mess. It's farmed out >> over a lot of function with very little error checking. This patch >> makes sure we propagate all initialization failures properly and clean >> up after them. Various runtime initializations are replaced with >> compile-time initializations where possible to make this easier. The >> exit path is similarly consolidated. > > Umm, this has been in for a long time. Did the mail leave your mail > queue only now? :) Nah, it got into ptools with a bogus commit message and PV and all, and now is in master tottally broken, the plan is to let it die in master and cherry-pick the new one in for-linus. Sorry for the mess ! Cheers, -- Niv Sardi From owner-xfs@oss.sgi.com Wed Jun 25 19:51:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 19:51:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5Q2pqYO025668 for ; Wed, 25 Jun 2008 19:51:53 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA09260; Thu, 26 Jun 2008 12:52:47 +1000 Message-ID: <4863056D.3080209@sgi.com> Date: Thu, 26 Jun 2008 12:56:45 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] Don't assert if trying to mount with blocksize > pagesize Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16538 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs If we don't do the blocksize/PAGESIZE check before calling xfs_sb_validate_fsb_count() we can assert if we try to mount with a blocksize > pagesize. The assert is valid so leave it and just move the blocksize/pagesize check earlier. --- fs/xfs/xfs_mount.c_1.436 2008-06-26 12:44:06.000000000 +1000 +++ fs/xfs/xfs_mount.c 2008-06-26 12:48:15.000000000 +1000 @@ -258,6 +258,19 @@ xfs_mount_validate_sb( return XFS_ERROR(EFSCORRUPTED); } + /* + * Until this is fixed only page-sized or smaller data blocks work. + */ + if (unlikely(sbp->sb_blocksize > PAGE_SIZE)) { + xfs_fs_mount_cmn_err(flags, + "file system with blocksize %d bytes", + sbp->sb_blocksize); + xfs_fs_mount_cmn_err(flags, + "only pagesize (%ld) or less will currently work.", + PAGE_SIZE); + return XFS_ERROR(ENOSYS); + } + if (xfs_sb_validate_fsb_count(sbp, sbp->sb_dblocks) || xfs_sb_validate_fsb_count(sbp, sbp->sb_rblocks)) { xfs_fs_mount_cmn_err(flags, @@ -279,19 +292,6 @@ xfs_mount_validate_sb( return XFS_ERROR(ENOSYS); } - /* - * Until this is fixed only page-sized or smaller data blocks work. - */ - if (unlikely(sbp->sb_blocksize > PAGE_SIZE)) { - xfs_fs_mount_cmn_err(flags, - "file system with blocksize %d bytes", - sbp->sb_blocksize); - xfs_fs_mount_cmn_err(flags, - "only pagesize (%ld) or less will currently work.", - PAGE_SIZE); - return XFS_ERROR(ENOSYS); - } - return 0; } From owner-xfs@oss.sgi.com Wed Jun 25 20:02:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 20:02: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.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5Q32MdX026879 for ; Wed, 25 Jun 2008 20:02:22 -0700 X-ASG-Debug-ID: 1214449399-254b030e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B4EF2D55DF4 for ; Wed, 25 Jun 2008 20:03:22 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id BZbVimdZvxwQWhkk for ; Wed, 25 Jun 2008 20:03:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135556901" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 12:33:16 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBhlT-0000ui-Vz; Thu, 26 Jun 2008 13:03:16 +1000 Date: Thu, 26 Jun 2008 13:03:15 +1000 From: Dave Chinner To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Don't assert if trying to mount with blocksize > pagesize Subject: Re: [PATCH] Don't assert if trying to mount with blocksize > pagesize Message-ID: <20080626030315.GG11558@disturbed> Mail-Followup-To: Lachlan McIlroy , xfs-dev , xfs-oss References: <4863056D.3080209@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4863056D.3080209@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214449403 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.54352 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: 16539 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 Thu, Jun 26, 2008 at 12:56:45PM +1000, Lachlan McIlroy wrote: > If we don't do the blocksize/PAGESIZE check before > calling xfs_sb_validate_fsb_count() we can assert > if we try to mount with a blocksize > pagesize. > The assert is valid so leave it and just move the > blocksize/pagesize check earlier. Yes, looks like a problem. The fix looks ok. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jun 25 20:06:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 20:06:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5Q36Niv027522 for ; Wed, 25 Jun 2008 20:06:23 -0700 X-ASG-Debug-ID: 1214449643-37f102080000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4F351D55BED for ; Wed, 25 Jun 2008 20:07:23 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id kl3qhS9BdcS4RHRD for ; Wed, 25 Jun 2008 20:07:23 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 73F2BA9C52B; Wed, 25 Jun 2008 22:07:22 -0500 (CDT) Message-ID: <486307EA.7080007@sandeen.net> Date: Wed, 25 Jun 2008 22:07:22 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs-oss CC: LinuxRaid X-ASG-Orig-Subj: [PATCH] disable queue flag test in barrier check Subject: [PATCH] disable queue flag test in barrier check Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214449644 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.54354 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: 16540 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs md raid1 can pass down barriers, but does not set an ordered flag on the queue, so xfs does not even attempt a barrier write, and will never use barriers on these block devices. I propose removing the flag check and just let the barrier write test determine barrier support. The risk here, I suppose, is that if something does not set an ordered flag and also does not properly return an error on a barrier write... but if it's any consolation jbd/ext3/reiserfs never test the flag, and don't even do a test write, they just disable barriers the first time an actual journal barrier write fails. Signed-off-by: Eric Sandeen --- Index: linux-2.6.25.1/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6.25.1.orig/fs/xfs/linux-2.6/xfs_super.c +++ linux-2.6.25.1/fs/xfs/linux-2.6/xfs_super.c @@ -733,14 +733,6 @@ xfs_mountfs_check_barriers(xfs_mount_t * return; } - if (mp->m_ddev_targp->bt_bdev->bd_disk->queue->ordered == - QUEUE_ORDERED_NONE) { - xfs_fs_cmn_err(CE_NOTE, mp, - "Disabling barriers, not supported by the underlying device"); - mp->m_flags &= ~XFS_MOUNT_BARRIER; - return; - } - if (xfs_readonly_buftarg(mp->m_ddev_targp)) { xfs_fs_cmn_err(CE_NOTE, mp, "Disabling barriers, underlying device is readonly"); From owner-xfs@oss.sgi.com Wed Jun 25 20:37:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 20:37:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5Q3bf9Z002610 for ; Wed, 25 Jun 2008 20:37:42 -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 NAA10035; Thu, 26 Jun 2008 13:38:37 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 44625) id 3B48258C4C3F; Thu, 26 Jun 2008 13:38:37 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 983734 - Don't assert if trying to mount with blocksize > pagesize Message-Id: <20080626033837.3B48258C4C3F@chook.melbourne.sgi.com> Date: Thu, 26 Jun 2008 13:38:37 +1000 (EST) From: lachlan@sgi.com (Lachlan McIlroy) 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: 16541 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Don't assert if trying to mount with blocksize > pagesize If we don't do the blocksize/PAGESIZE check before calling xfs_sb_validate_fsb_count() we can assert if we try to mount with a blocksize > pagesize. The assert is valid so leave it and just move the blocksize/pagesize check earlier. Date: Thu Jun 26 13:37:19 AEST 2008 Workarea: redback.melbourne.sgi.com:/home/lachlan/isms/2.6.x-alloc Inspected by: dgc Author: lachlan The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31365a fs/xfs/xfs_mount.c - 1.437 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_mount.c.diff?r1=text&tr1=1.437&r2=text&tr2=1.436&f=h - Don't assert if trying to mount with blocksize > pagesize From owner-xfs@oss.sgi.com Wed Jun 25 21:40:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 21:40:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52, J_CHICKENPOX_92 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 m5Q4eNOu008317 for ; Wed, 25 Jun 2008 21:40:23 -0700 X-ASG-Debug-ID: 1214455282-25c6008e0001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 81FE0D5613D for ; Wed, 25 Jun 2008 21:41:23 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id UwQXkY3RzTablLdb for ; Wed, 25 Jun 2008 21:41:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135640721" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 14:11:23 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBjIQ-0001to-G3; Thu, 26 Jun 2008 14:41:22 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: matthew@wil.cx, linux-kernel@vger.kernel.org, Dave Chinner X-ASG-Orig-Subj: [PATCH 5/6] Remove the sema_t from XFS. Subject: [PATCH 5/6] Remove the sema_t from XFS. Date: Thu, 26 Jun 2008 14:41:16 +1000 Message-Id: <1214455277-6387-6-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214455277-6387-1-git-send-email-david@fromorbit.com> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214455284 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.54359 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: 16542 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 Now that all users of the sema_t are gone from XFS we can finally kill it. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/sema.h | 52 ------------------------------------------ fs/xfs/linux-2.6/xfs_linux.h | 2 +- 2 files changed, 1 insertions(+), 53 deletions(-) delete mode 100644 fs/xfs/linux-2.6/sema.h diff --git a/fs/xfs/linux-2.6/sema.h b/fs/xfs/linux-2.6/sema.h deleted file mode 100644 index 3abe7e9..0000000 --- a/fs/xfs/linux-2.6/sema.h +++ /dev/null @@ -1,52 +0,0 @@ -/* - * Copyright (c) 2000-2002,2005 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ -#ifndef __XFS_SUPPORT_SEMA_H__ -#define __XFS_SUPPORT_SEMA_H__ - -#include -#include -#include -#include - -/* - * sema_t structure just maps to struct semaphore in Linux kernel. - */ - -typedef struct semaphore sema_t; - -#define initnsema(sp, val, name) sema_init(sp, val) -#define psema(sp, b) down(sp) -#define vsema(sp) up(sp) -#define freesema(sema) do { } while (0) - -static inline int issemalocked(sema_t *sp) -{ - return down_trylock(sp) || (up(sp), 0); -} - -/* - * Map cpsema (try to get the sema) to down_trylock. We need to switch - * the return values since cpsema returns 1 (acquired) 0 (failed) and - * down_trylock returns the reverse 0 (acquired) 1 (failed). - */ -static inline int cpsema(sema_t *sp) -{ - return down_trylock(sp) ? 0 : 1; -} - -#endif /* __XFS_SUPPORT_SEMA_H__ */ diff --git a/fs/xfs/linux-2.6/xfs_linux.h b/fs/xfs/linux-2.6/xfs_linux.h index 4d45d93..4fb838f 100644 --- a/fs/xfs/linux-2.6/xfs_linux.h +++ b/fs/xfs/linux-2.6/xfs_linux.h @@ -45,13 +45,13 @@ #include #include #include -#include #include #include #include #include +#include #include #include #include -- 1.5.5.4 From owner-xfs@oss.sgi.com Wed Jun 25 21:40:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 21:41:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_48 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 m5Q4eOQ4008324 for ; Wed, 25 Jun 2008 21:40:24 -0700 X-ASG-Debug-ID: 1214455283-1e07016f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BB5462825EA for ; Wed, 25 Jun 2008 21:41:23 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id BbPctgKMRXI8UP2O for ; Wed, 25 Jun 2008 21:41:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135640710" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 14:11:22 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBjIO-0001tN-Hu; Thu, 26 Jun 2008 14:41:21 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: matthew@wil.cx, linux-kernel@vger.kernel.org, Dave Chinner X-ASG-Orig-Subj: [PATCH 3/6] Replace dquot flush semaphore with a completion Subject: [PATCH 3/6] Replace dquot flush semaphore with a completion Date: Thu, 26 Jun 2008 14:41:14 +1000 Message-Id: <1214455277-6387-4-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214455277-6387-1-git-send-email-david@fromorbit.com> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214455284 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.54357 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: 16546 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 Use the new completion flush code to implement the dquot flush lock. Removes one of the final users of semaphores in the XFS code base. Signed-off-by: Dave Chinner --- fs/xfs/quota/xfs_dquot.c | 18 +++++------------- fs/xfs/quota/xfs_dquot.h | 23 +++++++++++++---------- fs/xfs/quota/xfs_dquot_item.c | 6 +++--- 3 files changed, 21 insertions(+), 26 deletions(-) diff --git a/fs/xfs/quota/xfs_dquot.c b/fs/xfs/quota/xfs_dquot.c index fc9f3fb..c3e3080 100644 --- a/fs/xfs/quota/xfs_dquot.c +++ b/fs/xfs/quota/xfs_dquot.c @@ -101,7 +101,7 @@ xfs_qm_dqinit( if (brandnewdquot) { dqp->dq_flnext = dqp->dq_flprev = dqp; mutex_init(&dqp->q_qlock); - initnsema(&dqp->q_flock, 1, "fdq"); + init_completion_flush(&dqp->q_flush); sv_init(&dqp->q_pinwait, SV_DEFAULT, "pdq"); #ifdef XFS_DQUOT_TRACE @@ -150,7 +150,6 @@ xfs_qm_dqdestroy( ASSERT(! XFS_DQ_IS_ON_FREELIST(dqp)); mutex_destroy(&dqp->q_qlock); - freesema(&dqp->q_flock); sv_destroy(&dqp->q_pinwait); #ifdef XFS_DQUOT_TRACE @@ -1211,7 +1210,7 @@ xfs_qm_dqflush( int error; ASSERT(XFS_DQ_IS_LOCKED(dqp)); - ASSERT(XFS_DQ_IS_FLUSH_LOCKED(dqp)); + ASSERT(completion_flush_inprogress(&dqp->q_flush)); xfs_dqtrace_entry(dqp, "DQFLUSH"); /* @@ -1353,14 +1352,7 @@ int xfs_qm_dqflock_nowait( xfs_dquot_t *dqp) { - int locked; - - locked = cpsema(&((dqp)->q_flock)); - - /* XXX ifdef these out */ - if (locked) - (dqp)->dq_flags |= XFS_DQ_FLOCKED; - return (locked); + return completion_flush_start_nowait(&dqp->q_flush); } @@ -1368,14 +1360,14 @@ int xfs_qm_dqlock_nowait( xfs_dquot_t *dqp) { - return (mutex_trylock(&((dqp)->q_qlock))); + return mutex_trylock(&dqp->q_qlock); } void xfs_dqlock( xfs_dquot_t *dqp) { - mutex_lock(&(dqp->q_qlock)); + mutex_lock(&dqp->q_qlock); } void diff --git a/fs/xfs/quota/xfs_dquot.h b/fs/xfs/quota/xfs_dquot.h index f7393bb..c127a45 100644 --- a/fs/xfs/quota/xfs_dquot.h +++ b/fs/xfs/quota/xfs_dquot.h @@ -82,7 +82,7 @@ typedef struct xfs_dquot { xfs_qcnt_t q_res_icount; /* total inos allocd+reserved */ xfs_qcnt_t q_res_rtbcount;/* total realtime blks used+reserved */ mutex_t q_qlock; /* quota lock */ - sema_t q_flock; /* flush lock */ + struct completion q_flush; /* flush completion queue */ uint q_pincount; /* pin count for this dquot */ sv_t q_pinwait; /* sync var for pinning */ #ifdef XFS_DQUOT_TRACE @@ -113,17 +113,20 @@ XFS_DQ_IS_LOCKED(xfs_dquot_t *dqp) /* - * The following three routines simply manage the q_flock - * semaphore embedded in the dquot. This semaphore synchronizes - * processes attempting to flush the in-core dquot back to disk. + * Manage the q_flush completion queue embedded in the dquot. This completion + * queue synchronizes processes attempting to flush the in-core dquot back to + * disk. */ -#define xfs_dqflock(dqp) { psema(&((dqp)->q_flock), PINOD | PRECALC);\ - (dqp)->dq_flags |= XFS_DQ_FLOCKED; } -#define xfs_dqfunlock(dqp) { ASSERT(issemalocked(&((dqp)->q_flock))); \ - vsema(&((dqp)->q_flock)); \ - (dqp)->dq_flags &= ~(XFS_DQ_FLOCKED); } +static inline void xfs_dqflock(xfs_dquot_t *dqp) +{ + completion_flush_start(&dqp->q_flush); +} + +static inline void xfs_dqfunlock(xfs_dquot_t *dqp) +{ + complete(&dqp->q_flush); +} -#define XFS_DQ_IS_FLUSH_LOCKED(dqp) (issemalocked(&((dqp)->q_flock))) #define XFS_DQ_IS_ON_FREELIST(dqp) ((dqp)->dq_flnext != (dqp)) #define XFS_DQ_IS_DIRTY(dqp) ((dqp)->dq_flags & XFS_DQ_DIRTY) #define XFS_QM_ISUDQ(dqp) ((dqp)->dq_flags & XFS_DQ_USER) diff --git a/fs/xfs/quota/xfs_dquot_item.c b/fs/xfs/quota/xfs_dquot_item.c index 08d2fc8..a91efa8 100644 --- a/fs/xfs/quota/xfs_dquot_item.c +++ b/fs/xfs/quota/xfs_dquot_item.c @@ -151,7 +151,7 @@ xfs_qm_dquot_logitem_push( dqp = logitem->qli_dquot; ASSERT(XFS_DQ_IS_LOCKED(dqp)); - ASSERT(XFS_DQ_IS_FLUSH_LOCKED(dqp)); + ASSERT(completion_flush_inprogress(&dqp->q_flush)); /* * Since we were able to lock the dquot's flush lock and @@ -245,7 +245,7 @@ xfs_qm_dquot_logitem_pushbuf( * inode flush completed and the inode was taken off the AIL. * So, just get out. */ - if (!issemalocked(&(dqp->q_flock)) || + if (!completion_flush_inprogress(&dqp->q_flush) || ((qip->qli_item.li_flags & XFS_LI_IN_AIL) == 0)) { qip->qli_pushbuf_flag = 0; xfs_dqunlock(dqp); @@ -258,7 +258,7 @@ xfs_qm_dquot_logitem_pushbuf( if (bp != NULL) { if (XFS_BUF_ISDELAYWRITE(bp)) { dopush = ((qip->qli_item.li_flags & XFS_LI_IN_AIL) && - issemalocked(&(dqp->q_flock))); + completion_flush_inprogress(&dqp->q_flush)); qip->qli_pushbuf_flag = 0; xfs_dqunlock(dqp); -- 1.5.5.4 From owner-xfs@oss.sgi.com Wed Jun 25 21:40:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 21:41:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5Q4eMFS008309 for ; Wed, 25 Jun 2008 21:40:22 -0700 X-ASG-Debug-ID: 1214455282-25c6008e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7A23AD5613B for ; Wed, 25 Jun 2008 21:41:22 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id H7QWsVUplx5pU4nz for ; Wed, 25 Jun 2008 21:41:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135640688" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 14:11:20 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBjIN-0001tG-9v; Thu, 26 Jun 2008 14:41:19 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: matthew@wil.cx, linux-kernel@vger.kernel.org, Dave Chinner X-ASG-Orig-Subj: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: [PATCH 1/6] Extend completions to provide XFS object flush requirements Date: Thu, 26 Jun 2008 14:41:12 +1000 Message-Id: <1214455277-6387-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214455277-6387-1-git-send-email-david@fromorbit.com> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214455283 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.54359 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: 16547 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 XFS object flushing doesn't quite match existing completion semantics. It mixed exclusive access with completion. That is, we need to mark an object as being flushed before flushing it to disk, and then block any other attempt to flush it until the completion occurs. To do this we introduce: void init_completion_flush(struct completion *x) which initialises x->done = 1 void completion_flush_start(struct completion *x) which blocks if done == 0, otherwise decrements done to zero and allows the caller to continue. bool completion_flush_start_nowait(struct completion *x) returns a failure status if done == 0, otherwise decrements done to zero and returns a "flush started" status. This is provided to allow flushing to begin safely while holding object locks in inverted order. This replaces the use of semaphores for providing this exclusion and completion mechanism. Signed-off-by: Dave Chinner --- include/linux/completion.h | 65 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 65 insertions(+), 0 deletions(-) diff --git a/include/linux/completion.h b/include/linux/completion.h index d2961b6..82d9fa4 100644 --- a/include/linux/completion.h +++ b/include/linux/completion.h @@ -55,4 +55,69 @@ extern void complete_all(struct completion *); #define INIT_COMPLETION(x) ((x).done = 0) +/* + * Give completions flush lock semantics. + * + * A flush lock is a completion that allows only a single thread to be flushing + * a queue. That is, the first thread does not block on the completion, but + * forces all subsequent threads to block until the first thread issues a + * complete(). This allows only a single I/O at a time on an object protected + * by such a completion queue. + * + * Rather than make the code using this confusing by calling + * "wait_for_completion()", introduce a new interface that "starts + * a flush." In some cases, we may want to try to start a flush + * but not do so if it would involve sleeping, so allow those + * semantics as well. + */ + +static inline void init_completion_flush(struct completion *x) +{ + x->done = 1; + init_waitqueue_head(&x->wait); +} + + +static inline void completion_flush_start(struct completion *x) +{ + wait_for_completion(x); +} + +/* + * Start a flush without blocking if possible. + * + * Returns 0 if a completion is in progress without + * modifying the done counter. Otherwise, take a count + * so that others will see a completion in progress and + * return 1 to indicate a flush can be started. + */ +static inline bool completion_flush_start_nowait(struct completion *x) +{ + int ret = 1; + + spin_lock_irq(&x->wait.lock); + if (!x->done) + ret = 0; + else + x->done--; + spin_unlock_irq(&x->wait.lock); + return ret; +} + +/* + * Test to see if a flush is in progress. + * + * Returns 1 if a flush is in progress, otherwise 0. + */ +static inline bool completion_flush_inprogress(struct completion *x) +{ + int ret = 0; + + spin_lock_irq(&x->wait.lock); + if (!x->done) + ret = 1; + spin_unlock_irq(&x->wait.lock); + return ret; +} + #endif -- 1.5.5.4 From owner-xfs@oss.sgi.com Wed Jun 25 21:40:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 21:41:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (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 m5Q4eLlw008305 for ; Wed, 25 Jun 2008 21:40:22 -0700 X-ASG-Debug-ID: 1214455281-1e44013f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8073DD5613B for ; Wed, 25 Jun 2008 21:41:21 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id kzZngU078ANtcCPg for ; Wed, 25 Jun 2008 21:41:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135640682" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 14:11:20 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBjIL-0001tC-LX; Thu, 26 Jun 2008 14:41:17 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: [PATCH 0/6] Remove most users of semaphores from XFS. Subject: [PATCH 0/6] Remove most users of semaphores from XFS. Date: Thu, 26 Jun 2008 14:41:11 +1000 Message-Id: <1214455277-6387-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214455282 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.54359 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: 16548 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 This series aims to convert all but one of the remaining users of semaphores in the XFS code to use completions. Two of these semaphores don't quite match to completion semantics, but a small amount of additional code on top of the completions fixes this problem. I'm open to suggestions on different/better ways to implement this. The patch series does not touch the b_lock semaphore in the xfs_buf_t. At this point I'm not sure what we want to do with that semaphore so I've ignored that for now. Also, this lock uses linux primitives, not the xfs sema_t primitives so it doesn't need changing to allow me to remove the sema_t. From owner-xfs@oss.sgi.com Wed Jun 25 21:40:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 21:40:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_57 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 m5Q4eQq3008334 for ; Wed, 25 Jun 2008 21:40:26 -0700 X-ASG-Debug-ID: 1214455282-25c6008e0002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 40FDCD56144 for ; Wed, 25 Jun 2008 21:41:24 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id 4js2AmuoF0x5PLTW for ; Wed, 25 Jun 2008 21:41:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135640732" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 14:11:23 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBjIQ-0001tq-Mc; Thu, 26 Jun 2008 14:41:22 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: matthew@wil.cx, linux-kernel@vger.kernel.org, Dave Chinner X-ASG-Orig-Subj: [PATCH 6/6] Clean up stale references to semaphores Subject: [PATCH 6/6] Clean up stale references to semaphores Date: Thu, 26 Jun 2008 14:41:17 +1000 Message-Id: <1214455277-6387-7-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214455277-6387-1-git-send-email-david@fromorbit.com> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214455286 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.54359 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: 16544 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 A lot of code has been converted away from semaphores, but there are still comments that reference semaphore behaviour. The log code is the worst offender. Update the comments to reflect what the code really does now. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_vnode.c | 6 ++-- fs/xfs/xfs_log.c | 67 ++++++++++++++++++++---------------------- fs/xfs/xfs_log_priv.h | 12 ++++---- 3 files changed, 41 insertions(+), 44 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_vnode.c b/fs/xfs/linux-2.6/xfs_vnode.c index bc7afe0..1881c79 100644 --- a/fs/xfs/linux-2.6/xfs_vnode.c +++ b/fs/xfs/linux-2.6/xfs_vnode.c @@ -33,7 +33,7 @@ /* - * Dedicated vnode inactive/reclaim sync semaphores. + * Dedicated vnode inactive/reclaim sync wait queues. * Prime number of hash buckets since address is used as the key. */ #define NVSYNC 37 @@ -84,8 +84,8 @@ vn_ioerror( /* * Revalidate the Linux inode from the XFS inode. - * Note: i_size _not_ updated; we must hold the inode - * semaphore when doing that - callers responsibility. + * Note: i_size _not_ updated; we must hold the i_mutex when doing + * that - callers responsibility. */ int vn_revalidate( diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index 2497de8..760d543 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -357,11 +357,11 @@ xfs_log_done(xfs_mount_t *mp, * Asynchronous forces are implemented by setting the WANT_SYNC * bit in the appropriate in-core log and then returning. * - * Synchronous forces are implemented with a semaphore. All callers - * to force a given lsn to disk will wait on a semaphore attached to the + * Synchronous forces are implemented with a signal variable. All callers + * to force a given lsn to disk will wait on a the sv attached to the * specific in-core log. When given in-core log finally completes its * write to disk, that thread will wake up all threads waiting on the - * semaphore. + * sv. */ int _xfs_log_force( @@ -707,7 +707,7 @@ xfs_log_unmount_write(xfs_mount_t *mp) if (!(iclog->ic_state == XLOG_STATE_ACTIVE || iclog->ic_state == XLOG_STATE_DIRTY)) { if (!XLOG_FORCED_SHUTDOWN(log)) { - sv_wait(&iclog->ic_forcesema, PMEM, + sv_wait(&iclog->ic_force_wait, PMEM, &log->l_icloglock, s); } else { spin_unlock(&log->l_icloglock); @@ -748,7 +748,7 @@ xfs_log_unmount_write(xfs_mount_t *mp) || iclog->ic_state == XLOG_STATE_DIRTY || iclog->ic_state == XLOG_STATE_IOERROR) ) { - sv_wait(&iclog->ic_forcesema, PMEM, + sv_wait(&iclog->ic_force_wait, PMEM, &log->l_icloglock, s); } else { spin_unlock(&log->l_icloglock); @@ -838,7 +838,7 @@ xfs_log_move_tail(xfs_mount_t *mp, break; tail_lsn = 0; free_bytes -= tic->t_unit_res; - sv_signal(&tic->t_sema); + sv_signal(&tic->t_wait); tic = tic->t_next; } while (tic != log->l_write_headq); } @@ -859,7 +859,7 @@ xfs_log_move_tail(xfs_mount_t *mp, break; tail_lsn = 0; free_bytes -= need_bytes; - sv_signal(&tic->t_sema); + sv_signal(&tic->t_wait); tic = tic->t_next; } while (tic != log->l_reserve_headq); } @@ -1285,8 +1285,8 @@ xlog_alloc_log(xfs_mount_t *mp, ASSERT(XFS_BUF_ISBUSY(iclog->ic_bp)); ASSERT(XFS_BUF_VALUSEMA(iclog->ic_bp) <= 0); - sv_init(&iclog->ic_forcesema, SV_DEFAULT, "iclog-force"); - sv_init(&iclog->ic_writesema, SV_DEFAULT, "iclog-write"); + sv_init(&iclog->ic_force_wait, SV_DEFAULT, "iclog-force"); + sv_init(&iclog->ic_write_wait, SV_DEFAULT, "iclog-write"); iclogp = &iclog->ic_next; } @@ -1565,8 +1565,8 @@ xlog_dealloc_log(xlog_t *log) iclog = log->l_iclog; for (i=0; il_iclog_bufs; i++) { - sv_destroy(&iclog->ic_forcesema); - sv_destroy(&iclog->ic_writesema); + sv_destroy(&iclog->ic_force_wait); + sv_destroy(&iclog->ic_write_wait); xfs_buf_free(iclog->ic_bp); #ifdef XFS_LOG_TRACE if (iclog->ic_trace != NULL) { @@ -1976,7 +1976,7 @@ xlog_write(xfs_mount_t * mp, /* Clean iclogs starting from the head. This ordering must be * maintained, so an iclog doesn't become ACTIVE beyond one that * is SYNCING. This is also required to maintain the notion that we use - * a counting semaphore to hold off would be writers to the log when every + * a ordered wait queue to hold off would be writers to the log when every * iclog is trying to sync to disk. * * State Change: DIRTY -> ACTIVE @@ -2240,7 +2240,7 @@ xlog_state_do_callback( xlog_state_clean_log(log); /* wake up threads waiting in xfs_log_force() */ - sv_broadcast(&iclog->ic_forcesema); + sv_broadcast(&iclog->ic_force_wait); iclog = iclog->ic_next; } while (first_iclog != iclog); @@ -2302,8 +2302,7 @@ xlog_state_do_callback( * the second completion goes through. * * Callbacks could take time, so they are done outside the scope of the - * global state machine log lock. Assume that the calls to cvsema won't - * take a long time. At least we know it won't sleep. + * global state machine log lock. */ STATIC void xlog_state_done_syncing( @@ -2339,7 +2338,7 @@ xlog_state_done_syncing( * iclog buffer, we wake them all, one will get to do the * I/O, the others get to wait for the result. */ - sv_broadcast(&iclog->ic_writesema); + sv_broadcast(&iclog->ic_write_wait); spin_unlock(&log->l_icloglock); xlog_state_do_callback(log, aborted, iclog); /* also cleans log */ } /* xlog_state_done_syncing */ @@ -2347,11 +2346,9 @@ xlog_state_done_syncing( /* * If the head of the in-core log ring is not (ACTIVE or DIRTY), then we must - * sleep. The flush semaphore is set to the number of in-core buffers and - * decremented around disk syncing. Therefore, if all buffers are syncing, - * this semaphore will cause new writes to sleep until a sync completes. - * Otherwise, this code just does p() followed by v(). This approximates - * a sleep/wakeup except we can't race. + * sleep. We wait on the flush queue on the head iclog as that should be + * the first iclog to complete flushing. Hence if all iclogs are syncing, + * we will wait here and all new writes will sleep until a sync completes. * * The in-core logs are used in a circular fashion. They are not used * out-of-order even when an iclog past the head is free. @@ -2501,7 +2498,7 @@ xlog_grant_log_space(xlog_t *log, goto error_return; XFS_STATS_INC(xs_sleep_logspace); - sv_wait(&tic->t_sema, PINOD|PLTWAIT, &log->l_grant_lock, s); + sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); /* * If we got an error, and the filesystem is shutting down, * we'll catch it down below. So just continue... @@ -2527,7 +2524,7 @@ redo: xlog_trace_loggrant(log, tic, "xlog_grant_log_space: sleep 2"); XFS_STATS_INC(xs_sleep_logspace); - sv_wait(&tic->t_sema, PINOD|PLTWAIT, &log->l_grant_lock, s); + sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); if (XLOG_FORCED_SHUTDOWN(log)) { spin_lock(&log->l_grant_lock); @@ -2626,7 +2623,7 @@ xlog_regrant_write_log_space(xlog_t *log, if (free_bytes < ntic->t_unit_res) break; free_bytes -= ntic->t_unit_res; - sv_signal(&ntic->t_sema); + sv_signal(&ntic->t_wait); ntic = ntic->t_next; } while (ntic != log->l_write_headq); @@ -2637,7 +2634,7 @@ xlog_regrant_write_log_space(xlog_t *log, xlog_trace_loggrant(log, tic, "xlog_regrant_write_log_space: sleep 1"); XFS_STATS_INC(xs_sleep_logspace); - sv_wait(&tic->t_sema, PINOD|PLTWAIT, + sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); /* If we're shutting down, this tic is already @@ -2666,7 +2663,7 @@ redo: if ((tic->t_flags & XLOG_TIC_IN_Q) == 0) xlog_ins_ticketq(&log->l_write_headq, tic); XFS_STATS_INC(xs_sleep_logspace); - sv_wait(&tic->t_sema, PINOD|PLTWAIT, &log->l_grant_lock, s); + sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); /* If we're shutting down, this tic is already off the queue */ if (XLOG_FORCED_SHUTDOWN(log)) { @@ -2909,7 +2906,7 @@ xlog_state_switch_iclogs(xlog_t *log, * 2. the current iclog is drity, and the previous iclog is in the * active or dirty state. * - * We may sleep (call psema) if: + * We may sleep if: * * 1. the current iclog is not in the active nor dirty state. * 2. the current iclog dirty, and the previous iclog is not in the @@ -3006,7 +3003,7 @@ maybe_sleep: return XFS_ERROR(EIO); } XFS_STATS_INC(xs_log_force_sleep); - sv_wait(&iclog->ic_forcesema, PINOD, &log->l_icloglock, s); + sv_wait(&iclog->ic_force_wait, PINOD, &log->l_icloglock, s); /* * No need to grab the log lock here since we're * only deciding whether or not to return EIO @@ -3089,7 +3086,7 @@ try_again: XLOG_STATE_SYNCING))) { ASSERT(!(iclog->ic_state & XLOG_STATE_IOERROR)); XFS_STATS_INC(xs_log_force_sleep); - sv_wait(&iclog->ic_prev->ic_writesema, PSWP, + sv_wait(&iclog->ic_prev->ic_write_wait, PSWP, &log->l_icloglock, s); *log_flushed = 1; already_slept = 1; @@ -3109,7 +3106,7 @@ try_again: !(iclog->ic_state & (XLOG_STATE_ACTIVE | XLOG_STATE_DIRTY))) { /* - * Don't wait on the forcesema if we know that we've + * Don't wait on completion if we know that we've * gotten a log write error. */ if (iclog->ic_state & XLOG_STATE_IOERROR) { @@ -3117,7 +3114,7 @@ try_again: return XFS_ERROR(EIO); } XFS_STATS_INC(xs_log_force_sleep); - sv_wait(&iclog->ic_forcesema, PSWP, &log->l_icloglock, s); + sv_wait(&iclog->ic_force_wait, PSWP, &log->l_icloglock, s); /* * No need to grab the log lock here since we're * only deciding whether or not to return EIO @@ -3173,7 +3170,7 @@ STATIC void xlog_ticket_put(xlog_t *log, xlog_ticket_t *ticket) { - sv_destroy(&ticket->t_sema); + sv_destroy(&ticket->t_wait); kmem_zone_free(xfs_log_ticket_zone, ticket); } /* xlog_ticket_put */ @@ -3263,7 +3260,7 @@ xlog_ticket_get(xlog_t *log, tic->t_trans_type = 0; if (xflags & XFS_LOG_PERM_RESERV) tic->t_flags |= XLOG_TIC_PERM_RESERV; - sv_init(&(tic->t_sema), SV_DEFAULT, "logtick"); + sv_init(&(tic->t_wait), SV_DEFAULT, "logtick"); xlog_tic_reset_res(tic); @@ -3550,14 +3547,14 @@ xfs_log_force_umount( */ if ((tic = log->l_reserve_headq)) { do { - sv_signal(&tic->t_sema); + sv_signal(&tic->t_wait); tic = tic->t_next; } while (tic != log->l_reserve_headq); } if ((tic = log->l_write_headq)) { do { - sv_signal(&tic->t_sema); + sv_signal(&tic->t_wait); tic = tic->t_next; } while (tic != log->l_write_headq); } diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h index 6245913..7dcf11e 100644 --- a/fs/xfs/xfs_log_priv.h +++ b/fs/xfs/xfs_log_priv.h @@ -241,7 +241,7 @@ typedef struct xlog_res { } xlog_res_t; typedef struct xlog_ticket { - sv_t t_sema; /* sleep on this semaphore : 20 */ + sv_t t_wait; /* ticket wait queue : 20 */ struct xlog_ticket *t_next; /* :4|8 */ struct xlog_ticket *t_prev; /* :4|8 */ xlog_tid_t t_tid; /* transaction identifier : 4 */ @@ -314,7 +314,7 @@ typedef struct xlog_rec_ext_header { * xlog_rec_header_t into the reserved space. * - ic_data follows, so a write to disk can start at the beginning of * the iclog. - * - ic_forcesema is used to implement synchronous forcing of the iclog to disk. + * - ic_forcewait is used to implement synchronous forcing of the iclog to disk. * - ic_next is the pointer to the next iclog in the ring. * - ic_bp is a pointer to the buffer used to write this incore log to disk. * - ic_log is a pointer back to the global log structure. @@ -339,8 +339,8 @@ typedef struct xlog_rec_ext_header { * and move everything else out to subsequent cachelines. */ typedef struct xlog_iclog_fields { - sv_t ic_forcesema; - sv_t ic_writesema; + sv_t ic_force_wait; + sv_t ic_write_wait; struct xlog_in_core *ic_next; struct xlog_in_core *ic_prev; struct xfs_buf *ic_bp; @@ -377,8 +377,8 @@ typedef struct xlog_in_core { /* * Defines to save our code from this glop. */ -#define ic_forcesema hic_fields.ic_forcesema -#define ic_writesema hic_fields.ic_writesema +#define ic_force_wait hic_fields.ic_force_wait +#define ic_write_wait hic_fields.ic_write_wait #define ic_next hic_fields.ic_next #define ic_prev hic_fields.ic_prev #define ic_bp hic_fields.ic_bp -- 1.5.5.4 From owner-xfs@oss.sgi.com Wed Jun 25 21:40:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 21:40: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5Q4eOP8008322 for ; Wed, 25 Jun 2008 21:40:24 -0700 X-ASG-Debug-ID: 1214455281-1e44013f0002-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BA5F2D56141 for ; Wed, 25 Jun 2008 21:41:24 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id N2uBWB8RzgnvWnaj for ; Wed, 25 Jun 2008 21:41:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135640729" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 14:11:23 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBjIQ-0001tf-0o; Thu, 26 Jun 2008 14:41:22 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: matthew@wil.cx, linux-kernel@vger.kernel.org, Dave Chinner X-ASG-Orig-Subj: [PATCH 4/6] Replace the XFS buf iodone semaphore with a completion Subject: [PATCH 4/6] Replace the XFS buf iodone semaphore with a completion Date: Thu, 26 Jun 2008 14:41:15 +1000 Message-Id: <1214455277-6387-5-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214455277-6387-1-git-send-email-david@fromorbit.com> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214455284 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.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54359 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 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: 16545 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 The xfs_buf_t b_iodonesema is really just a semaphore that wants to be a completion. Change it to a completion and remove the last user of the sema_t from XFS. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_buf.c | 6 +++--- fs/xfs/linux-2.6/xfs_buf.h | 4 ++-- fs/xfs/xfs_buf_item.c | 2 +- fs/xfs/xfs_rw.c | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c index 9cc8f02..9438c90 100644 --- a/fs/xfs/linux-2.6/xfs_buf.c +++ b/fs/xfs/linux-2.6/xfs_buf.c @@ -253,7 +253,7 @@ _xfs_buf_initialize( memset(bp, 0, sizeof(xfs_buf_t)); atomic_set(&bp->b_hold, 1); - init_MUTEX_LOCKED(&bp->b_iodonesema); + init_completion(&bp->b_iowait); INIT_LIST_HEAD(&bp->b_list); INIT_LIST_HEAD(&bp->b_hash_list); init_MUTEX_LOCKED(&bp->b_sema); /* held, no waiters */ @@ -1037,7 +1037,7 @@ xfs_buf_ioend( xfs_buf_iodone_work(&bp->b_iodone_work); } } else { - up(&bp->b_iodonesema); + complete(&bp->b_iowait); } } @@ -1275,7 +1275,7 @@ xfs_buf_iowait( XB_TRACE(bp, "iowait", 0); if (atomic_read(&bp->b_io_remaining)) blk_run_address_space(bp->b_target->bt_mapping); - down(&bp->b_iodonesema); + wait_for_completion(&bp->b_iowait); XB_TRACE(bp, "iowaited", (long)bp->b_error); return bp->b_error; } diff --git a/fs/xfs/linux-2.6/xfs_buf.h b/fs/xfs/linux-2.6/xfs_buf.h index 29d1d4a..fe01099 100644 --- a/fs/xfs/linux-2.6/xfs_buf.h +++ b/fs/xfs/linux-2.6/xfs_buf.h @@ -157,7 +157,7 @@ typedef struct xfs_buf { xfs_buf_iodone_t b_iodone; /* I/O completion function */ xfs_buf_relse_t b_relse; /* releasing function */ xfs_buf_bdstrat_t b_strat; /* pre-write function */ - struct semaphore b_iodonesema; /* Semaphore for I/O waiters */ + struct completion b_iowait; /* queue for I/O waiters */ void *b_fspriv; void *b_fspriv2; void *b_fspriv3; @@ -352,7 +352,7 @@ extern void xfs_buf_trace(xfs_buf_t *, char *, void *, void *); #define XFS_BUF_CPSEMA(bp) (xfs_buf_cond_lock(bp) == 0) #define XFS_BUF_VSEMA(bp) xfs_buf_unlock(bp) #define XFS_BUF_PSEMA(bp,x) xfs_buf_lock(bp) -#define XFS_BUF_V_IODONESEMA(bp) up(&bp->b_iodonesema); +#define XFS_BUF_FINISH_IOWAIT(bp) complete(&bp->b_iowait); #define XFS_BUF_SET_TARGET(bp, target) ((bp)->b_target = (target)) #define XFS_BUF_TARGET(bp) ((bp)->b_target) diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c index d86ca2c..215c36d 100644 --- a/fs/xfs/xfs_buf_item.c +++ b/fs/xfs/xfs_buf_item.c @@ -1056,7 +1056,7 @@ xfs_buf_iodone_callbacks( anyway. */ XFS_BUF_SET_BRELSE_FUNC(bp,xfs_buf_error_relse); XFS_BUF_DONE(bp); - XFS_BUF_V_IODONESEMA(bp); + XFS_BUF_FINISH_IOWAIT(bp); } return; } diff --git a/fs/xfs/xfs_rw.c b/fs/xfs/xfs_rw.c index b0f31c0..3a82576 100644 --- a/fs/xfs/xfs_rw.c +++ b/fs/xfs/xfs_rw.c @@ -314,7 +314,7 @@ xfs_bioerror_relse( * ASYNC buffers. */ XFS_BUF_ERROR(bp, EIO); - XFS_BUF_V_IODONESEMA(bp); + XFS_BUF_FINISH_IOWAIT(bp); } else { xfs_buf_relse(bp); } -- 1.5.5.4 From owner-xfs@oss.sgi.com Wed Jun 25 21:40:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 21:40:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5Q4eNoA008313 for ; Wed, 25 Jun 2008 21:40:23 -0700 X-ASG-Debug-ID: 1214455281-1e44013f0001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BF8C5D5613F for ; Wed, 25 Jun 2008 21:41:22 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id hzYsX8kb5IzdwM5L for ; Wed, 25 Jun 2008 21:41:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135640696" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 14:11:21 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBjIO-0001tK-2r; Thu, 26 Jun 2008 14:41:20 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: matthew@wil.cx, linux-kernel@vger.kernel.org, Dave Chinner X-ASG-Orig-Subj: [PATCH 2/6] Replace inode flush semaphore with a completion Subject: [PATCH 2/6] Replace inode flush semaphore with a completion Date: Thu, 26 Jun 2008 14:41:13 +1000 Message-Id: <1214455277-6387-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214455277-6387-1-git-send-email-david@fromorbit.com> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214455283 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.54359 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: 16543 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 Use the new completion flush code to implement the inode flush lock. Removes one of the final users of semaphores in the XFS code base. Signed-off-by: Dave Chinner --- fs/xfs/xfs_iget.c | 15 +++++++-------- fs/xfs/xfs_inode.c | 11 +++++------ fs/xfs/xfs_inode.h | 2 +- fs/xfs/xfs_inode_item.c | 11 +++++------ 4 files changed, 18 insertions(+), 21 deletions(-) diff --git a/fs/xfs/xfs_iget.c b/fs/xfs/xfs_iget.c index b07604b..5eed054 100644 --- a/fs/xfs/xfs_iget.c +++ b/fs/xfs/xfs_iget.c @@ -216,7 +216,7 @@ finish_inode: mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); init_waitqueue_head(&ip->i_ipin_wait); atomic_set(&ip->i_pincount, 0); - initnsema(&ip->i_flock, 1, "xfsfino"); + init_completion_flush(&ip->i_flush); if (lock_flags) xfs_ilock(ip, lock_flags); @@ -776,25 +776,24 @@ xfs_isilocked( #endif /* - * The following three routines simply manage the i_flock - * semaphore embedded in the inode. This semaphore synchronizes - * processes attempting to flush the in-core inode back to disk. + * Manage the i_flush queue embedded in the inode. This completion + * queue synchronizes processes attempting to flush the in-core + * inode back to disk. */ void xfs_iflock(xfs_inode_t *ip) { - psema(&(ip->i_flock), PINOD|PLTWAIT); + completion_flush_start(&ip->i_flush); } int xfs_iflock_nowait(xfs_inode_t *ip) { - return (cpsema(&(ip->i_flock))); + return completion_flush_start_nowait(&ip->i_flush); } void xfs_ifunlock(xfs_inode_t *ip) { - ASSERT(issemalocked(&(ip->i_flock))); - vsema(&(ip->i_flock)); + complete(&ip->i_flush); } diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index bedc661..81e2040 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -2630,7 +2630,6 @@ xfs_idestroy( xfs_idestroy_fork(ip, XFS_ATTR_FORK); mrfree(&ip->i_lock); mrfree(&ip->i_iolock); - freesema(&ip->i_flock); #ifdef XFS_INODE_TRACE ktrace_free(ip->i_trace); @@ -3048,10 +3047,10 @@ cluster_corrupt_out: /* * xfs_iflush() will write a modified inode's changes out to the * inode's on disk home. The caller must have the inode lock held - * in at least shared mode and the inode flush semaphore must be - * held as well. The inode lock will still be held upon return from + * in at least shared mode and the inode flush completion must be + * active as well. The inode lock will still be held upon return from * the call and the caller is free to unlock it. - * The inode flush lock will be unlocked when the inode reaches the disk. + * The inode flush will be completed when the inode reaches the disk. * The flags indicate how the inode's buffer should be written out. */ int @@ -3070,7 +3069,7 @@ xfs_iflush( XFS_STATS_INC(xs_iflush_count); ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); - ASSERT(issemalocked(&(ip->i_flock))); + ASSERT(completion_flush_inprogress(&ip->i_flush)); ASSERT(ip->i_d.di_format != XFS_DINODE_FMT_BTREE || ip->i_d.di_nextents > ip->i_df.if_ext_max); @@ -3233,7 +3232,7 @@ xfs_iflush_int( #endif ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); - ASSERT(issemalocked(&(ip->i_flock))); + ASSERT(completion_flush_inprogress(&ip->i_flush)); ASSERT(ip->i_d.di_format != XFS_DINODE_FMT_BTREE || ip->i_d.di_nextents > ip->i_df.if_ext_max); diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h index 17a04b6..caaec3c 100644 --- a/fs/xfs/xfs_inode.h +++ b/fs/xfs/xfs_inode.h @@ -223,7 +223,7 @@ typedef struct xfs_inode { struct xfs_inode_log_item *i_itemp; /* logging information */ mrlock_t i_lock; /* inode lock */ mrlock_t i_iolock; /* inode IO lock */ - sema_t i_flock; /* inode flush lock */ + struct completion i_flush; /* inode flush completion q */ atomic_t i_pincount; /* inode pin count */ wait_queue_head_t i_ipin_wait; /* inode pinning wait queue */ spinlock_t i_flags_lock; /* inode i_flags lock */ diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c index 0eee08a..7c54046 100644 --- a/fs/xfs/xfs_inode_item.c +++ b/fs/xfs/xfs_inode_item.c @@ -779,11 +779,10 @@ xfs_inode_item_pushbuf( ASSERT(iip->ili_push_owner == current_pid()); /* - * If flushlock isn't locked anymore, chances are that the - * inode flush completed and the inode was taken off the AIL. - * So, just get out. + * If a flush is not in progress anymore, chances are that the + * inode was taken off the AIL. So, just get out. */ - if (!issemalocked(&(ip->i_flock)) || + if (!completion_flush_inprogress(&ip->i_flush) || ((iip->ili_item.li_flags & XFS_LI_IN_AIL) == 0)) { iip->ili_pushbuf_flag = 0; xfs_iunlock(ip, XFS_ILOCK_SHARED); @@ -805,7 +804,7 @@ xfs_inode_item_pushbuf( * If not, we can flush it async. */ dopush = ((iip->ili_item.li_flags & XFS_LI_IN_AIL) && - issemalocked(&(ip->i_flock))); + completion_flush_inprogress(&ip->i_flush)); iip->ili_pushbuf_flag = 0; xfs_iunlock(ip, XFS_ILOCK_SHARED); xfs_buftrace("INODE ITEM PUSH", bp); @@ -858,7 +857,7 @@ xfs_inode_item_push( ip = iip->ili_inode; ASSERT(xfs_isilocked(ip, XFS_ILOCK_SHARED)); - ASSERT(issemalocked(&(ip->i_flock))); + ASSERT(completion_flush_inprogress(&ip->i_flush)); /* * Since we were able to lock the inode's flush lock and * we found it on the AIL, the inode must be dirty. This -- 1.5.5.4 From owner-xfs@oss.sgi.com Wed Jun 25 21:49:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 21:49:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 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 m5Q4nBQs011251 for ; Wed, 25 Jun 2008 21:49:12 -0700 X-ASG-Debug-ID: 1214455812-047403450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34508.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 9C0E8D5634C for ; Wed, 25 Jun 2008 21:50:12 -0700 (PDT) Received: from web34508.mail.mud.yahoo.com (web34508.mail.mud.yahoo.com [66.163.178.174]) by cuda.sgi.com with SMTP id nRFxQBXb0GEMkwME for ; Wed, 25 Jun 2008 21:50:12 -0700 (PDT) Received: (qmail 14477 invoked by uid 60001); 26 Jun 2008 04:50:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Message-ID; b=Z5XNcKtXQj35PLl4/ORiEnDMi/xhcDU9DX6NBt0RYXlbn3Y5zHSRi7K2uqa5F7hBpVly92531FiJ/IeZ9yOHitVdP1xtFT0TEiJX/4v0oUfjueRzwW+/29x88pr9xxgTlWFfGbbHtYpVmz8o89ZnAfTtfOz/W1q5E1O5CQLmvHc=; Received: from [96.14.164.210] by web34508.mail.mud.yahoo.com via HTTP; Wed, 25 Jun 2008 21:50:11 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Wed, 25 Jun 2008 21:50:11 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: XFS w/ extern journal as root on Linux? Subject: XFS w/ extern journal as root on Linux? To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <732501.9968.qm@web34508.mail.mud.yahoo.com> X-Barracuda-Connect: web34508.mail.mud.yahoo.com[66.163.178.174] X-Barracuda-Start-Time: 1214455812 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.54359 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: 16549 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs Well, I tried to convert my non-/home space to XFS with an external journal, but Linux consistently choked on it. I passed "rootfstype=xfs root=/dev/sdb5 rootflags=logdev=/dev/sda2" on the kernel command line (via GRUB) but it panicked every time. Here is a transcript of the boot panic from an unmodified kernel: ~~~~~~~~~~~~~~~~~ md: Autodetecting RAID arrays. md: Scanned 0 and added 0 devices. md: autorun ... md: ... autorun DONE. XFS: Invalid device [/dev/sda2], error=-2 VFS: Cannot open root device "sdb5" or unknown-block(8,21) Please append a correct "root=" boot option; here are the available partitions: 0800 390711384 sda driver: sd 0801 1005448 sda1 0802 3008880 sda2 0803 30005640 sda3 0804 1 sda4 0805 356688328 sda5 0b00 1048575 sr0 driver: sr 0810 488386584 sdb driver: sd 0811 146488671 sdb1 0812 4008217 sdb2 0813 3004155 sdb3 0814 1 sdb4 0815 334882926 sdb5 Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,21) ~~~~~~~~~~~~~~~~~ Judging from the output, it seems not to be able to open the log device /dev/sda2. I slipped in a couple statements in xfs_vfsops.c to watch for function entries and successful exits. I saw where xfs_blkdev_get() was called twice, the first time successfully (probably corresponding to /dev/sdb5), the second time unsuccessfully (/dev/sda2). Yet, the partition list at the end of the panic shows /dev/sda2 as recognized and available. Is this a known issue? As an acceptable substitute, I moved /usr to XFS with an external journal. Staying with the deadline scheduler, it's a noticeable difference. OOo launches in about 4 seconds. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Wed Jun 25 22:13:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 22:13: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.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5Q5DXx7013552 for ; Wed, 25 Jun 2008 22:13:35 -0700 X-ASG-Debug-ID: 1214457273-1e0702dd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E257228281B for ; Wed, 25 Jun 2008 22:14:33 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id WjPh30b2JNcHkAcb for ; Wed, 25 Jun 2008 22:14:33 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 1D3B7A84113; Thu, 26 Jun 2008 00:14:33 -0500 (CDT) Message-ID: <486325B8.5010505@sandeen.net> Date: Thu, 26 Jun 2008 00:14:32 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: MusicMan529@yahoo.com CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS w/ extern journal as root on Linux? Subject: Re: XFS w/ extern journal as root on Linux? References: <732501.9968.qm@web34508.mail.mud.yahoo.com> In-Reply-To: <732501.9968.qm@web34508.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214457273 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.54359 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: 16550 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark wrote: > Well, I tried to convert my non-/home space to XFS with an external journal, but Linux consistently choked on it. I passed "rootfstype=xfs root=/dev/sdb5 rootflags=logdev=/dev/sda2" on the kernel command line (via GRUB) but it panicked every time. > > Here is a transcript of the boot panic from an unmodified kernel: > > ~~~~~~~~~~~~~~~~~ > md: Autodetecting RAID arrays. > md: Scanned 0 and added 0 devices. > md: autorun ... > md: ... autorun DONE. > XFS: Invalid device [/dev/sda2], error=-2 Hm, xfs wants to open it by name ("/dev/sda2") but if we look at the early mount stuff it's doing essentially: root_device_name = saved_root_name; /* from root= */ ROOT_DEV = name_to_dev_t(root_device_name); create_dev("/dev/root", ROOT_DEV); mount_block_root("/dev/root", root_mountflags); so it's creating its own dev to open, and this isn't done for the logdev. I wonder if xfs can do similar tricks, or maybe do name_to_dev_t and do the open by dev_t not path? This is probably where somebody tells me I'm wrong for the following reasons: a, b, c, ... :) -Eric From owner-xfs@oss.sgi.com Wed Jun 25 23:28:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 23:28:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5Q6SiUQ019930 for ; Wed, 25 Jun 2008 23:28:45 -0700 X-ASG-Debug-ID: 1214461783-543d010b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from zimbra.vpac.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E3E30182A439 for ; Wed, 25 Jun 2008 23:29:44 -0700 (PDT) Received: from zimbra.vpac.org (zimbra.vpac.org [202.158.218.6]) by cuda.sgi.com with ESMTP id pyoiocyE7QrlNXE8 for ; Wed, 25 Jun 2008 23:29:44 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.vpac.org (Postfix) with ESMTP id A776646D0194; Thu, 26 Jun 2008 16:29:42 +1000 (EST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at Received: from zimbra.vpac.org ([127.0.0.1]) by localhost (zimbra.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNVhpswRlmCZ; Thu, 26 Jun 2008 16:29:40 +1000 (EST) Received: from [172.25.10.11] (firewall.vpac.org [202.158.218.253]) by zimbra.vpac.org (Postfix) with ESMTP id D8D2B46D0182; Thu, 26 Jun 2008 16:29:40 +1000 (EST) Message-ID: <48633754.6070709@vpac.org> Date: Thu, 26 Jun 2008 16:29:40 +1000 From: Brian May User-Agent: Icedove 1.5.0.14eol (X11/20080509) MIME-Version: 1.0 To: Brian May CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: open sleeps Subject: Re: open sleeps References: <4859EE54.6050801@vpac.org> <20080619062118.GY3700@disturbed> <4859FF40.8010206@vpac.org> <20080619084311.GA16736@infradead.org> <485B0C47.5060001@vpac.org> <485B2DE4.2080907@vpac.org> In-Reply-To: <485B2DE4.2080907@vpac.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: zimbra.vpac.org[202.158.218.6] X-Barracuda-Start-Time: 1214461784 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.54365 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16551 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brian@vpac.org Precedence: bulk X-list: xfs Hello, Thanks for your help. Just a followup: Every indication seems to be that it is the firewall in the virus scanner we use, F-Secure, that prevents Windows from releasing oplocks properly. After turning off the firewall, the oplocks get released and there is no problem. Possibly related to the timing of wpkg being invoked before system logons too. Might be time to consider another virus scanner/firewall solution. Brian May From owner-xfs@oss.sgi.com Wed Jun 25 23:45:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 25 Jun 2008 23:45:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 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 m5Q6jURO021763 for ; Wed, 25 Jun 2008 23:45:31 -0700 X-ASG-Debug-ID: 1214462790-606202e30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta01.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AFAB3282E1C for ; Wed, 25 Jun 2008 23:46:30 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id UtQwCoid5PjRUVJe for ; Wed, 25 Jun 2008 23:46:30 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 3177C1890092; Wed, 25 Jun 2008 23:49:16 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta01.pmc-sierra.bc.ca (Postfix) with SMTP id 0B411189008F; Wed, 25 Jun 2008 23:49:16 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Jun 2008 23:47:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-ASG-Orig-Subj: RE: Xfs Access to block zero exception and system crash Subject: RE: Xfs Access to block zero exception and system crash Date: Wed, 25 Jun 2008 23:46:59 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <20080625084931.GI16257@build-svl-1.agami.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: AcjWoHzZdt/yFnu+SPeMBnqVvfPNWQAp11BA References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> From: "Sagar Borikar" To: "Dave Chinner" Cc: X-OriginalArrivalTime: 26 Jun 2008 06:47:00.0022 (UTC) FILETIME=[6F0C2560:01C8D758] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.6.26.62832 X-PMC-SpamCheck: Gauge=IIIIIII, Probability=7%, Report='SUPERLONG_LINE 0.05, BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1214462791 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0012 1.0000 -2.0129 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54364 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by oss.sgi.com id m5Q6jVRO021765 X-archive-position: 16552 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Sagar_Borikar@pmc-sierra.com Precedence: bulk X-list: xfs Thanks Dave. >> with 2.6.18 kernel,128 MB of RAM, MIPS architecture and XFS version >> 2.8.11. > [...] >> Can anyone let me know what could be the probable cause of this issue. > they are all from corrupted extent btrees. > There are many possible causes of this that we've fixed over the past years since 2.6.18 was released. Indeed, we are currently discussing fixes for a > bunch of problems that lead to corrupted extent btrees and problems like this. I'd suggest that you should probably start with a more recent kernel, > make sure you have a serial console and set the xfs_error_level to 11 so that it gives as much information as possible on the console when the error it > hit. > if that doesn't give a stack trace, then you need to set the xfs_panic_mask to crash the machine on block zero accesses and report the stack straces > that it outputs... Yes, I went through the changes between 2.6.24 and 2.6.18 and they are quite a few. But as this is production system and on field, its not viable to upgrade the kernel. I do understand that there could be many places which can cause the corruption. Unfortunately, three different systems have given three different places of corruption as stated. Now I am sleeping in the access to block zero exception and rescheduling so that it won't stall the system and I can monitor the state of the filesystem. As the frequency of landing the error is once in 2.5 days under extreme stress, if you could point me to the probable place to look at, I can narrow down the debugging path. Thanks in advance Sagar From owner-xfs@oss.sgi.com Thu Jun 26 00:01:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 00:01:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5Q71IxF025555 for ; Thu, 26 Jun 2008 00:01:19 -0700 X-ASG-Debug-ID: 1214463738-0b5701270000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 663D5282F9A for ; Thu, 26 Jun 2008 00:02:18 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id A5rqGyUMHKVfsVuh for ; Thu, 26 Jun 2008 00:02:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQDAEOGYkh5LG+uZWdsb2JhbACSXhICHqAH X-IronPort-AV: E=Sophos;i="4.27,706,1204464600"; d="scan'208";a="135755261" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 16:32:16 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBlUl-0007LZ-BY; Thu, 26 Jun 2008 17:02:15 +1000 Date: Thu, 26 Jun 2008 17:02:15 +1000 From: Dave Chinner To: Sagar Borikar Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080626070215.GI11558@disturbed> Mail-Followup-To: Sagar Borikar , xfs@oss.sgi.com References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214463739 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.54367 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: 16553 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 [please wrap your replies at 72 columns] On Wed, Jun 25, 2008 at 11:46:59PM -0700, Sagar Borikar wrote: > >> with 2.6.18 kernel,128 MB of RAM, MIPS architecture and XFS version > >> 2.8.11. > > > [...] > > >> Can anyone let me know what could be the probable cause of this issue. > > > they are all from corrupted extent btrees. There are many > > possible causes of this that we've fixed over the past years > > since 2.6.18 was released. Indeed, we are currently discussing > > fixes for a bunch of problems that lead to corrupted extent > > btrees and problems like this. I'd suggest that you should > > probably start with a more recent kernel, make sure you have a > > serial console and set the xfs_error_level to 11 so that it > > gives as much information as possible on the console when the > > error it > hit. if that doesn't give a stack trace, then you > > need to set the xfs_panic_mask to crash the machine on block > > zero accesses and report the stack straces that it outputs... > > Yes, I went through the changes between 2.6.24 and 2.6.18 and they > are quite a few. But as this is production system and on field, > its not viable to upgrade the kernel. Well, you're pretty much on your own then :/ > I do understand that there > could be many places which can cause the corruption. > Unfortunately, three different systems have given three different > places of corruption as stated. Yes, but all the same pattern of corruption, so it is likely that it is one problem. > Now I am sleeping in the access to > block zero exception and rescheduling so that it won't stall the > system and I can monitor the state of the filesystem. As the > frequency of landing the error is once in 2.5 days under extreme > stress, if you could point me to the probable place to look at, I > can narrow down the debugging path. Like I said - it's a corrupt bmap btree. It could be a bug in the bmap btree code, the alloc btree code, the inode data fork manipulation code, it could be a block device bug returning bad data to XFS on on a cancelled btree readahead, etc. IOWs, there are so many possible causes of a corrupted btree that a bug report by itself is mostly useless. All I can suggest is working out a reproducable test case in your development environment, attaching a debugger and start digging around in memory when the problem is hit and try to find out exactly what is corrupted. If you can't reproduce it or work out what is occurring to trigger the problem, then we're not going to be able to find the cause... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 00:28:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 00:28:15 -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.7 required=5.0 tests=AWL,BAYES_00,SUBJ_MILLIONS 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 m5Q7SBBA000898 for ; Thu, 26 Jun 2008 00:28:11 -0700 X-ASG-Debug-ID: 1214465350-06ff02b30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from deliver.uni-koblenz.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0FB99D56E74 for ; Thu, 26 Jun 2008 00:29:10 -0700 (PDT) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by cuda.sgi.com with ESMTP id McU0E6UNOoA6IAFd for ; Thu, 26 Jun 2008 00:29:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 48E36789A134; Thu, 26 Jun 2008 09:29:10 +0200 (CEST) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22091-06; Thu, 26 Jun 2008 09:29:08 +0200 (CEST) Received: from bruch.uni-koblenz.de (bruch.uni-koblenz.de [141.26.64.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id B6593789A13B; Thu, 26 Jun 2008 09:29:08 +0200 (CEST) Message-ID: <48634544.3020107@uni-koblenz.de> Date: Thu, 26 Jun 2008 09:29:08 +0200 From: Christoph Litauer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Dave Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Performance problems with millions of inodes Subject: Re: Performance problems with millions of inodes References: <4862598B.80905@uni-koblenz.de> <20080625231210.GF11558@disturbed> In-Reply-To: <20080625231210.GF11558@disturbed> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at uni-koblenz.de X-Barracuda-Connect: deliver.uni-koblenz.de[141.26.64.15] X-Barracuda-Start-Time: 1214465352 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54368 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Status: Clean X-archive-position: 16554 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: litauer@uni-koblenz.de Precedence: bulk X-list: xfs Dave Chinner schrieb: > On Wed, Jun 25, 2008 at 04:43:23PM +0200, Christoph Litauer wrote: >> Hi, >> >> sorry if this has been asked before, I am new to this mailing list. I >> didn't find any hints in the FAQ or by googling ... >> >> I have a backup server driving two kinds of backup software: bacula and >> backuppc. bacula saves it's backups on raid1, backuppc on raid2 >> (different hardware, but both fast hardware raids). >> I have massive performance problems with backuppc which I tracked down >> to performance problems of the filesystem on raid2 (I think so). The >> main difference between the two backup systems is that backuppc uses >> millions of inodes for it's backup (in fact it duplicates the directory >> structure of the backup client). >> >> raid1 consists of 91675 inodes, raid2 of 143646439. The filesystems were >> created without any options. raid1 is about 7 TB, raid2 about 10TB. Both >> filesystems are mounted with options >> '(rw,noatime,nodiratime,ihashsize=65536)'. >> >> I used bonnie++ to benchmark both filesystems. Here are the results of >> 'bonnie++ -u root -f -n 10:0:0:1000': >> >> raid1: >> ------------------- >> Sequential Output: 82505 K/sec >> Sequential Input : 102192 K/sec >> Sequential file creation: 7184/sec >> Random file creation : 17277/sec >> >> raid2: >> ------------------- >> Sequential Output: 124802 K/sec >> Sequential Input : 109158 K/sec >> Sequential file creation: 123/sec >> Random file creation : 138/sec >> >> As you can see, raid2's throughput is higher than raid1's. But the file >> creation times are rather slow ... >> >> Maybe the 143 million inodes cause this effect? > > Certain will be. You've got about 3 AGs that are holding inodes, so > that's probably 35M+ inodes per AG. With the way allocation works, > it's probably doing a dual-traversal of the AGI btree to find a free > inode "near" to the parent and that is consuming lots and lots of > CPU time. So, would more AGs improve performance? As backuppc is still in testing state (for me) it would be no problem to create a new xfs filesystem with a "better" configuration. I am afraid that the number of inodes will increase very much if I backup more clients and filesystems. So, what configuration would you recommend? > >> Any idea how to avoid it? > > I had a protoype patch back when I was at SGI than stopped this > search when the search reached a radius that was no longer "near". > This greatly reduced CPU time for allocation on large inode count > AGs and hence create rates increased significantly. > > [Mark - IIRC that patch was in the miscellaneous patch tarball I > left behind...] > > The only other way of dealing with this is to use inode64 so that > inodes get spread across the entire filesystem instead of just a > few AGs at the start of the filesystem. It's too late to change the > existing inodes, but new inodes would get spread around.... Unfortunatly my backup server is a 32 bit system ... -- Regards Christoph ________________________________________________________________________ Christoph Litauer litauer@uni-koblenz.de Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311 PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2 From owner-xfs@oss.sgi.com Thu Jun 26 00:40:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 00:40:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5Q7eL68002380 for ; Thu, 26 Jun 2008 00:40:21 -0700 X-ASG-Debug-ID: 1214466081-527d00340000-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 4E18E283283 for ; Thu, 26 Jun 2008 00:41:22 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id O2zYFo1LfJYdFyDG for ; Thu, 26 Jun 2008 00:41:22 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBm6T-00033q-G6; Thu, 26 Jun 2008 07:41:13 +0000 Date: Thu, 26 Jun 2008 03:41:13 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 4/6] Replace the XFS buf iodone semaphore with a completion Subject: Re: [PATCH 4/6] Replace the XFS buf iodone semaphore with a completion Message-ID: <20080626074113.GA7064@infradead.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-5-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214455277-6387-5-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214466082 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.54368 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: 16555 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 Thu, Jun 26, 2008 at 02:41:15PM +1000, Dave Chinner wrote: > The xfs_buf_t b_iodonesema is really just a semaphore > that wants to be a completion. Change it to a completion > and remove the last user of the sema_t from XFS. Looks good and I've been running with an equivalent patch in my tree for a while. From owner-xfs@oss.sgi.com Thu Jun 26 00:45:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 00:45:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5Q7jbgv003159 for ; Thu, 26 Jun 2008 00:45:37 -0700 X-ASG-Debug-ID: 1214466398-0a7303920000-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 7ECCB2832D3 for ; Thu, 26 Jun 2008 00:46:38 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id EZOzfq18SKzROMMH for ; Thu, 26 Jun 2008 00:46:38 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBmBg-0003Un-Kz; Thu, 26 Jun 2008 07:46:36 +0000 Date: Thu, 26 Jun 2008 03:46:36 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626074636.GB7064@infradead.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214455277-6387-2-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214466398 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.54368 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: 16556 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 Thu, Jun 26, 2008 at 02:41:12PM +1000, Dave Chinner wrote: > XFS object flushing doesn't quite match existing completion semantics. It > mixed exclusive access with completion. That is, we need to mark an object as > being flushed before flushing it to disk, and then block any other attempt to > flush it until the completion occurs. > > To do this we introduce: > > void init_completion_flush(struct completion *x) > which initialises x->done = 1 > > void completion_flush_start(struct completion *x) > which blocks if done == 0, otherwise decrements done to zero and > allows the caller to continue. > > bool completion_flush_start_nowait(struct completion *x) > returns a failure status if done == 0, otherwise decrements done > to zero and returns a "flush started" status. This is provided > to allow flushing to begin safely while holding object locks in > inverted order. > > This replaces the use of semaphores for providing this exclusion > and completion mechanism. Given that the only API call shared with normal completions is complete() I'd rather make this a primitive of it's own, even if internally implemented as completions. Also please add kerneldoc comments for all new APIs eported to modules. From owner-xfs@oss.sgi.com Thu Jun 26 00:46:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 00:46:15 -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 m5Q7kBoL003453 for ; Thu, 26 Jun 2008 00:46:12 -0700 X-ASG-Debug-ID: 1214466432-3ce801fa0000-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 0ADC82830C4 for ; Thu, 26 Jun 2008 00:47:12 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id J9Rh6cRcWmQHWbqB for ; Thu, 26 Jun 2008 00:47:12 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBmCF-0003VE-9K; Thu, 26 Jun 2008 07:47:11 +0000 Date: Thu, 26 Jun 2008 03:47:11 -0400 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 6/6] Clean up stale references to semaphores Subject: Re: [PATCH 6/6] Clean up stale references to semaphores Message-ID: <20080626074711.GC7064@infradead.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-7-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214455277-6387-7-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214466433 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.54371 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: 16557 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 Thu, Jun 26, 2008 at 02:41:17PM +1000, Dave Chinner wrote: > A lot of code has been converted away from semaphores, > but there are still comments that reference semaphore > behaviour. The log code is the worst offender. Update > the comments to reflect what the code really does now. Looks good. From owner-xfs@oss.sgi.com Thu Jun 26 01:19:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 01:19:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 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 m5Q8JN0o007164 for ; Thu, 26 Jun 2008 01:19:24 -0700 X-ASG-Debug-ID: 1214468423-350b03be0000-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 2AADA2836A8; Thu, 26 Jun 2008 01:20:23 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id LFuTT6Qbx3vy3gTu; Thu, 26 Jun 2008 01:20:23 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBmiN-0001zF-Ct; Thu, 26 Jun 2008 08:20:23 +0000 Date: Thu, 26 Jun 2008 04:20:23 -0400 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Don't assert if trying to mount with blocksize > pagesize Subject: Re: [PATCH] Don't assert if trying to mount with blocksize > pagesize Message-ID: <20080626082023.GA23954@infradead.org> References: <4863056D.3080209@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4863056D.3080209@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214468424 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.54373 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: 16558 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 Thu, Jun 26, 2008 at 12:56:45PM +1000, Lachlan McIlroy wrote: > If we don't do the blocksize/PAGESIZE check before > calling xfs_sb_validate_fsb_count() we can assert > if we try to mount with a blocksize > pagesize. > The assert is valid so leave it and just move the > blocksize/pagesize check earlier. The patch looks good, but the subject is rather misleading, it should rather be something like: "move check for blocksize > pagesize later in the mount path" From owner-xfs@oss.sgi.com Thu Jun 26 01:23:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 01:23:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5Q8Nch9007927 for ; Thu, 26 Jun 2008 01:23:38 -0700 X-ASG-Debug-ID: 1214468678-3ce803a80000-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 16C2928370D; Thu, 26 Jun 2008 01:24:38 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id PN0HOeH1QRETMMsV; Thu, 26 Jun 2008 01:24:38 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBmmU-0002aX-6L; Thu, 26 Jun 2008 08:24:38 +0000 Date: Thu, 26 Jun 2008 04:24:38 -0400 From: Christoph Hellwig To: Niv Sardi Cc: xfs@oss.sgi.com, Niv Sardi X-ASG-Orig-Subj: Re: [PATCH] Move attr log alloc size calculator to another function. Subject: Re: [PATCH] Move attr log alloc size calculator to another function. Message-ID: <20080626082438.GB23954@infradead.org> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214196150-5427-2-git-send-email-xaiki@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214468679 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.54373 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: 16559 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 23, 2008 at 02:42:27PM +1000, Niv Sardi wrote: > From: Niv Sardi > > We will need that to be able to calculate the size of log we need for > a specific attr (for parent pointers in create). We need the local so > that we can fail if we run into ENOSPC when trying to alloc blocks > > Signed-off-by: Niv Sardi > --- > fs/xfs/xfs_attr.c | 78 +++++++++++++++++++++++++++++++--------------------- > fs/xfs/xfs_attr.h | 2 +- > 2 files changed, 47 insertions(+), 33 deletions(-) > > diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c > index e58f321..0d19e90 100644 > --- a/fs/xfs/xfs_attr.c > +++ b/fs/xfs/xfs_attr.c > @@ -185,6 +185,43 @@ xfs_attr_get( > } > > int > +xfs_attr_calc_size( should be marked STATIC, and a little comment describing what the function does would help, too. > + xfs_inode_t *ip, please use struct xfs_inode instead of the typedef for new code. > + int namelen, > + int valuelen, > + int *local) > +{ > + xfs_mount_t *mp = ip->i_mount; Same here, should be struct xfs_mount > + nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); > + if (*local) { > + if (size > (mp->m_sb.sb_blocksize >> 1)) { > + /* Double split possible */ > + nblks <<= 1; > + } The comment cold be a little more verbose, and using a *= 2 would be more descriptive (the compiler will optimize it to a shift anyway) > - if ((error = xfs_trans_reserve(args.trans, (uint) nblks, > - XFS_ATTRSET_LOG_RES(mp, nblks), > - 0, XFS_TRANS_PERM_LOG_RES, > - XFS_ATTRSET_LOG_COUNT))) { > + if ((error = xfs_trans_reserve(args.trans, (uint) args.total, > + XFS_ATTRSET_LOG_RES(mp, args.total), > + 0, XFS_TRANS_PERM_LOG_RES, > + XFS_ATTRSET_LOG_COUNT))) { When you touch this anyway please rewrite it to the canonical form: error = xfs_trans_reserve(args.trans, args.total, XFS_ATTRSET_LOG_RES(mp, args.total), 0, XFS_TRANS_PERM_LOG_RES, XFS_ATTRSET_LOG_COUNT); if (error) { With these little tidyups this looks good enough as a cleanup that can go in anytime. From owner-xfs@oss.sgi.com Thu Jun 26 01:24:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 01:24:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from 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 m5Q8OpNG008355 for ; Thu, 26 Jun 2008 01:24:52 -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 SAA16378; Thu, 26 Jun 2008 18:25:40 +1000 Message-ID: <48635284.3060001@sgi.com> Date: Thu, 26 Jun 2008 18:25:40 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss , LinuxRaid , NeilBrown , jeremy@sgi.comwe Subject: Re: [PATCH] disable queue flag test in barrier check References: <486307EA.7080007@sandeen.net> In-Reply-To: <486307EA.7080007@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16560 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > md raid1 can pass down barriers, but does not set an ordered flag > on the queue, so xfs does not even attempt a barrier write, and > will never use barriers on these block devices. > > I propose removing the flag check and just let the barrier write > test determine barrier support. > > The risk here, I suppose, is that if something does not set an ordered > flag and also does not properly return an error on a barrier write... > but if it's any consolation jbd/ext3/reiserfs never test the flag, > and don't even do a test write, they just disable barriers the first > time an actual journal barrier write fails. > > Signed-off-by: Eric Sandeen > --- > > Index: linux-2.6.25.1/fs/xfs/linux-2.6/xfs_super.c > =================================================================== > --- linux-2.6.25.1.orig/fs/xfs/linux-2.6/xfs_super.c > +++ linux-2.6.25.1/fs/xfs/linux-2.6/xfs_super.c > @@ -733,14 +733,6 @@ xfs_mountfs_check_barriers(xfs_mount_t * > return; > } > > - if (mp->m_ddev_targp->bt_bdev->bd_disk->queue->ordered == > - QUEUE_ORDERED_NONE) { > - xfs_fs_cmn_err(CE_NOTE, mp, > - "Disabling barriers, not supported by the underlying device"); > - mp->m_flags &= ~XFS_MOUNT_BARRIER; > - return; > - } > - > if (xfs_readonly_buftarg(mp->m_ddev_targp)) { > xfs_fs_cmn_err(CE_NOTE, mp, > "Disabling barriers, underlying device is readonly"); > > Yeah, okay so we are revisiting this stuff again. Fair enough. (Groan;-) So it was brought to our attention by Neil a while ago: 1. > To: xfs@xxxxxxxxxxx > Subject: XFS and write barriers. > From: Neil Brown > Date: Fri, 23 Mar 2007 12:26:31 +1100 > > Hi, > I have two concerns related to XFS and write barrier support that I'm > hoping can be resolved. > > Firstly in xfs_mountfs_check_barriers in fs/xfs/linux-2.6/xfs_super.c, > it tests ....->queue->ordered to see if that is QUEUE_ORDERED_NONE. > If it is, then barriers are disabled. > > I think this is a layering violation - xfs really has no business > looking that deeply into the device. > For dm and md devices, ->ordered is never used and so never set, so > xfs will never use barriers on those devices (as the default value is > 0 or NONE). It is true that md and dm could set ->ordered to some > non-zero value just to please XFS, but that would be telling a lie and > there is no possible value that is relevant to a layered devices. > > I think this test should just be removed and the xfs_barrier_test > should be the main mechanism for seeing if barriers work. Looking back, we agreed at the time that this seemed reasonable. (some mails from dgc and hch) 2. > To: Neil Brown > Subject: Re: XFS and write barriers. > From: David Chinner > Date: Fri, 23 Mar 2007 16:30:43 +1100 > Cc: xfs@xxxxxxxxxxx, hch@xxxxxxxxxxxxx > > On Fri, Mar 23, 2007 at 12:26:31PM +1100, Neil Brown wrote: >> >> Hi, >> I have two concerns related to XFS and write barrier support that I'm >> hoping can be resolved. >> >> Firstly in xfs_mountfs_check_barriers in fs/xfs/linux-2.6/xfs_super.c, >> it tests ....->queue->ordered to see if that is QUEUE_ORDERED_NONE. >> If it is, then barriers are disabled. >> >> I think this is a layering violation - xfs really has no business >> looking that deeply into the device. > > Except that the device behaviour determines what XFS needs to do > and there used to be no other way to find out. > > Christoph, any reason for needing this check anymore? I can't see > any particular reason for needing to do this as __make_request() > will check it for us when we test now. > >> I think this test should just be removed and the xfs_barrier_test >> should be the main mechanism for seeing if barriers work. > > Yup. 3. > To: David Chinner > Subject: Re: XFS and write barriers. > From: Christoph Hellwig > Date: Fri, 23 Mar 2007 09:50:55 +0000 > Cc: Neil Brown , xfs@xxxxxxxxxxx, hch@xxxxxxxxxxxxx > > On Fri, Mar 23, 2007 at 04:30:43PM +1100, David Chinner wrote: >> On Fri, Mar 23, 2007 at 12:26:31PM +1100, Neil Brown wrote: >> > >> > Hi, >> > I have two concerns related to XFS and write barrier support that I'm >> > hoping can be resolved. >> > >> > Firstly in xfs_mountfs_check_barriers in fs/xfs/linux-2.6/xfs_super.c, >> > it tests ....->queue->ordered to see if that is QUEUE_ORDERED_NONE. >> > If it is, then barriers are disabled. >> > >> > I think this is a layering violation - xfs really has no business >> > looking that deeply into the device. >> >> Except that the device behaviour determines what XFS needs to do >> and there used to be no other way to find out. >> >> Christoph, any reason for needing this check anymore? I can't see >> any particular reason for needing to do this as __make_request() >> will check it for us when we test now. > > When I first implemented it I really dislike the idea of having request > fail asynchrnously due to the lack of barriers. Then someone (Jens?) > told me we need to do this check anyway because devices might lie to > us, at which point I implemented the test superblock writeback to > check if it actually works. > > So yes, we could probably get rid of the check now, although I'd > prefer the block layer exporting an API to the filesystem to tell > it whether there is any point in trying to use barriers. 4. > review: handle barriers being switched off dynamically. > > * To: xfs-dev > * Subject: review: handle barriers being switched off dynamically. > * From: David Chinner > * Date: Thu, 19 Apr 2007 17:37:14 +1000 > * Cc: xfs-oss > > As pointed out by Neil Brown, MD can switch barriers off > dynamically underneath a mounted filesystem. If this happens > to XFS, it will shutdown the filesystem immediately. > > Handle this more sanely by yelling into the syslog, retrying > the I/O without barriers and if that is successful, turn > off barriers. > > Also remove an unnecessary check when first checking to > see if the underlying device supports barriers. > > Cheers, > > Dave. Looking at our xfs ptools logs... 5. > ---------------------------- > revision 1.402 > date: 2007/10/15 01:33:50; author: tes; state: Exp; lines: +8 -0 > modid: xfs-linux-melb:xfs-kern:29882a > Put back the QUEUE_ORDERED_NONE test in the barrier check. > > Put back the QUEUE_ORDERED_NONE test which caused us grief in sles when it was taken out > as, IIRC, it allowed md/lvm to be thought of as supporting barriers when they weren't > in some configurations. > This patch will be reverting what went in as part of a change for > the SGI-pv 964544 (SGI-Modid: xfs-linux-melb:xfs-kern:28568a). > Put back the QUEUE_ORDERED_NONE test in the barrier check. > ---------------------------- > ---------------------------- > revision 1.380 > date: 2007/05/11 05:35:19; author: dgc; state: Exp; lines: +0 -8 > modid: xfs-linux-melb:xfs-kern:28568a > Barriers need to be dynamically checked and switched off > > If the underlying block device sudden stops supporting barriers, > we need to handle the -EOPNOTSUPP error in a sane manner rather > than shutting downteh filesystem. If we get this error, clear the > barrier flag, reissue the I/O, and tell the world bad things are > occurring. > We shouldn't peer down into the backing device to see if barriers > are supported or not - the test I/O is sufficient to tell us > this. > ---------------------------- Also from memory, I believe Neil checked this removal into the SLES10sp1 tree and some sgi boxes started having slow downs (looking at Dave's email below - we were not wanting to tell them to use nobarrier but needed it to work by default - I forget now). 6. > Date: Wed, 25 Jun 2008 08:57:24 +1000 > From: Dave Chinner > To: Eric Sandeen > Cc: LinuxRaid , xfs-oss > Subject: Re: md raid1 passes barriers, but xfs doesn't use them? > > Yeah, the problem was that last time this check was removed was > that a bunch of existing hardware had barriers enabled on them when > not necessary (e.g. had NVRAM) and they went 5x slower on MD raid1 > devices. Having to change the root drive config on a wide install > base was considered much more of support pain than leaving the > check there. I guess that was more of a distro upgrade issue than > a mainline problem, but that's the history. Hence I think we > should probably do whatever everyone else is doing here.... > > Cheers, > > Dave. So I guess my question is whether there are cases where we are going to be in trouble again. Jeremy, do you see some problems? --Tim From owner-xfs@oss.sgi.com Thu Jun 26 01:27:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 01:27:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 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 m5Q8RRAS008925 for ; Thu, 26 Jun 2008 01:27:27 -0700 X-ASG-Debug-ID: 1214468907-5cf8011e0000-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 67CBAD57375; Thu, 26 Jun 2008 01:28:28 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id sSurp77qOcB4ImLJ; Thu, 26 Jun 2008 01:28:28 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBmqB-0001aD-Kq; Thu, 26 Jun 2008 08:28:27 +0000 Date: Thu, 26 Jun 2008 04:28:27 -0400 From: Christoph Hellwig To: Niv Sardi Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Subject: Re: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Message-ID: <20080626082827.GC23954@infradead.org> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214196150-5427-3-git-send-email-xaiki@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214468908 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.54372 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: 16561 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 > - if ((error = xfs_attr_rolltrans(&args.trans, dp))) > + > + error = xfs_trans_roll(&args.trans, dp); > + if (error) > goto out; > > } > @@ -1019,7 +1021,7 @@ xfs_attr_leaf_addname(xfs_da_args_t *args) > * Commit the current trans (including the inode) and start > * a new one. > */ > - if ((error = xfs_attr_rolltrans(&args->trans, dp))) > + if ((error = xfs_trans_roll(&args->trans, dp))) Please do the transformation to move all assignments out of the coditionals everywhere. > index b08e2a2..9465807 100644 > --- a/fs/xfs/xfs_attr_leaf.c > +++ b/fs/xfs/xfs_attr_leaf.c > @@ -2543,7 +2543,7 @@ xfs_attr_leaf_clearflag(xfs_da_args_t *args) > /* > * Commit the flag value change and start the next trans in series. > */ > - error = xfs_attr_rolltrans(&args->trans, args->dp); > + error = xfs_trans_roll(&args->trans, args->dp); > > return(error); return xfs_trans_roll(&args->trans, args->dp); > +/* > + * Roll from one trans in the sequence of PERMANENT transactions to the next. > + */ The comment could be a little more verbose :) > +int > +xfs_trans_roll( > + xfs_trans_t **tpp, > + xfs_inode_t *dp) > +{ > + xfs_trans_t *trans; > + unsigned int logres, count; > + int error; Please convert this to the struct types and canonical variable names for the given types: int xfs_trans_roll( struct xfs_trans *tpp, struct xfs_inode *ip) { struct xfs_trans *tp; > + if ((error = xfs_trans_commit(trans, 0))) > + return (error); error = xfs_trans_commit(trans, 0); if (error) return error; > + error = xfs_trans_reserve(trans, 0, logres, 0, > + XFS_TRANS_PERM_LOG_RES, count); > + /* > + * Ensure that the inode is in the new transaction and locked. > + */ > + if (!error) { > + xfs_trans_ijoin(trans, dp, XFS_ILOCK_EXCL); > + xfs_trans_ihold(trans, dp); > + } > + return (error); if (error) return error; xfs_trans_ijoin(trans, ip, XFS_ILOCK_EXCL); xfs_trans_ihold(trans, ip); return 0; From owner-xfs@oss.sgi.com Thu Jun 26 02:28:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 02:28:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,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 m5Q9RwjM016076 for ; Thu, 26 Jun 2008 02:28:00 -0700 X-ASG-Debug-ID: 1214472536-5eda03410000-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 B5189182ADFA; Thu, 26 Jun 2008 02:28:56 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id SeCwdTtWMB3Da13C; Thu, 26 Jun 2008 02:28:56 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBnmi-0001TV-JZ; Thu, 26 Jun 2008 09:28:56 +0000 Date: Thu, 26 Jun 2008 05:28:56 -0400 From: Christoph Hellwig To: Niv Sardi Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] Introduce xfs_trans_bmap_add_attrfork. Subject: Re: [PATCH] Introduce xfs_trans_bmap_add_attrfork. Message-ID: <20080626092856.GA27069@infradead.org> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <1214196150-5427-4-git-send-email-xaiki@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214196150-5427-4-git-send-email-xaiki@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214472538 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.54377 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: 16562 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 > +int > +xfs_bmap_add_attrfork( > + xfs_inode_t *ip, /* incore inode pointer */ > + int size, /* space new attribute needs */ > + int rsvd) /* xact may use reserved blks */ > +{ > + return xfs_trans_bmap_add_attrfork(NULL, ip, size, rsvd); > +} Care to add this below xfs_trans_bmap_add_attrfork? Also please us struct xfs_inode instead of the typedef. > + if (tpp) { > + ASSERT(*tpp); > + tp = *tpp; > + } else { > + tp = xfs_trans_alloc(mp, XFS_TRANS_ADDAFORK); > + blks = XFS_ADDAFORK_SPACE_RES(mp); > + if (rsvd) > + tp->t_flags |= XFS_TRANS_RESERVE; > + if ((error = xfs_trans_reserve(tp, blks, XFS_ADDAFORK_LOG_RES(mp), 0, > + XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT))) > + goto error0; > + xfs_ilock(ip, XFS_ILOCK_EXCL); > + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? > + XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : > + XFS_QMOPT_RES_REGBLKS); > + if (error) { > + xfs_iunlock(ip, XFS_ILOCK_EXCL); > + xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES); > + return error; > + } > + if (XFS_IFORK_Q(ip)) > + goto error1; > + ASSERT(ip->i_d.di_anextents == 0); > + VN_HOLD(XFS_ITOV(ip)); > + xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); > + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > + if (tpp) { > + error = xfs_trans_roll(&tp, ip); > + } else { > + error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); > + } I think it would be much cleaner if all the transaction setup, joining etc was done in xfs_bmap_add_attrfork, and xfs_trans_bmap_add_attrfork just gets an always non-NULL xfs_trans pointer. That would mean the common code would become just a helper, and xfs_trans_bmap_add_attrfork would be a small wrapper including the xfs_trans_roll. Alternatively the caller could always do the roll. > - if (XFS_IFORK_Q(ip)) > - goto error1; > + if (tpp) { > + error = xfs_trans_roll(&tp, ip); > + } else { > + error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); > + } Why is this check made conditional? > - ASSERT(ip->i_d.di_anextents == 0); > - VN_HOLD(XFS_ITOV(ip)); > - xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); > - xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > + > switch (ip->i_d.di_format) { > case XFS_DINODE_FMT_DEV: > ip->i_d.di_forkoff = roundup(sizeof(xfs_dev_t), 8) >> 3; > @@ -4060,23 +4076,30 @@ xfs_bmap_add_attrfork( > XFS_SB_VERSION_ADDATTR2(&mp->m_sb); > sbfields |= (XFS_SB_VERSIONNUM | XFS_SB_FEATURES2); > } > - if (sbfields) { > - spin_unlock(&mp->m_sb_lock); > + spin_unlock(&mp->m_sb_lock); > + if (sbfields) > xfs_mod_sb(tp, sbfields); > - } else > - spin_unlock(&mp->m_sb_lock); I don't think this change belongs into this patch. > ASSERT(ip->i_df.if_ext_max == > XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); > return error; > error2: > + if (tpp) > + tpp = &tp; > xfs_bmap_cancel(&flist); > error1: > ASSERT(ismrlocked(&ip->i_lock,MR_UPDATE)); > - xfs_iunlock(ip, XFS_ILOCK_EXCL); > + if (tpp) > + tpp = &tp; > + else > + xfs_iunlock(ip, XFS_ILOCK_EXCL); > error0: > xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_ABORT); > ASSERT(ip->i_df.if_ext_max == > diff --git a/fs/xfs/xfs_bmap.h b/fs/xfs/xfs_bmap.h > index 87224b7..7a21e41 100644 > --- a/fs/xfs/xfs_bmap.h > +++ b/fs/xfs/xfs_bmap.h > @@ -166,6 +166,13 @@ xfs_bmap_add_attrfork( > int size, /* space needed for new attribute */ > int rsvd); /* flag for reserved block allocation */ > > +int /* error code */ > +xfs_trans_bmap_add_attrfork( > + struct xfs_trans **tpp, /* transaction */ > + struct xfs_inode *ip, /* incore inode pointer */ > + int size, /* space needed for new attribute */ > + int rsvd); /* flag for reserved block allocation */ > + > /* > * Add the extent to the list of extents to be free at transaction end. > * The list is maintained sorted (by block number). > -- > 1.5.5.4 > > ---end quoted text--- From owner-xfs@oss.sgi.com Thu Jun 26 02:50:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 02:50: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=-1.8 required=5.0 tests=BAYES_00,MIME_BOUND_MANY_HEX 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 m5Q9ouAW019423 for ; Thu, 26 Jun 2008 02:50:56 -0700 X-ASG-Debug-ID: 1214473907-208d02150000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gmail2860.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 38565283ACE for ; Thu, 26 Jun 2008 02:51:50 -0700 (PDT) Received: from gmail2860.com (tselnode-112.telkomsel.co.id [221.132.232.112]) by cuda.sgi.com with SMTP id LTakZ1gPiE7FGL9r for ; Thu, 26 Jun 2008 02:51:50 -0700 (PDT) From: Genset Spesializt To: linux-xfs@oss.sgi.com Reply-To: jeruk32@gmail.com X-ASG-Orig-Subj: Jasa Maintenance Genset / Jasa pemeliharaan Genset anda Subject: Jasa Maintenance Genset / Jasa pemeliharaan Genset anda Date: Thu, 26 Jun 2008 16:51:50 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7efb9f05-e23e-4a76-9825-b9d01381a7ca" X-Barracuda-Connect: tselnode-112.telkomsel.co.id[221.132.232.112] X-Barracuda-Start-Time: 1214473917 Message-Id: <20080626095150.38565283ACE@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.1813 1.0000 -0.9280 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.22 X-Barracuda-Spam-Status: No, SCORE=-0.22 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MIME_BOUND_MANY_HEX, MSGID_FROM_MTA_ID X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54379 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_BOUND_MANY_HEX Spam tool pattern in MIME boundary 0.70 MSGID_FROM_MTA_ID Message-Id for external message added locally 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: 16563 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeruk32@gmail.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format --7efb9f05-e23e-4a76-9825-b9d01381a7ca Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Dengan Hormat, Bersama email ini, kami ingin memperkenalkan usaha kami bergerak di bidang = pemeliharaan Genset untuk Gedung, Hotel, Kantor, Pabrik dan Rumah anda. Untuk informasi lebih lanjut, silahkan menghubungi 0816902892 Terimakasih Salam =20=20 --7efb9f05-e23e-4a76-9825-b9d01381a7ca-- From owner-xfs@oss.sgi.com Thu Jun 26 04:18:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 04:18:48 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_MANY_HEX,MIME_QP_LONG_LINE,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 m5QBIheV000657 for ; Thu, 26 Jun 2008 04:18:44 -0700 X-ASG-Debug-ID: 1214479162-131100970000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gmail1482.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 3AE2B1829B80 for ; Thu, 26 Jun 2008 04:19:28 -0700 (PDT) Received: from gmail1482.com (tselnode-057.telkomsel.co.id [221.132.231.57]) by cuda.sgi.com with SMTP id Ox5HjgyeOWiXR22E for ; Thu, 26 Jun 2008 04:19:28 -0700 (PDT) From: Bunga Papan Utk Ucapan To: linux-xfs@oss.sgi.com Reply-To: bungapapan@gmail.com X-ASG-Orig-Subj: PERKENALAN : 'Sakura Florist" = menerima pesanan khusus pembuatan bunga papan Subject: PERKENALAN : 'Sakura Florist" = menerima pesanan khusus pembuatan bunga papan Date: Thu, 26 Jun 2008 18:19:32 +0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b323dbd6-61d5-46d9-95d4-477be938b430" X-Barracuda-Connect: tselnode-057.telkomsel.co.id[221.132.231.57] X-Barracuda-Start-Time: 1214479184 Message-Id: <20080626111928.3AE2B1829B80@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.3368 1.0000 -0.2006 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.50 X-Barracuda-Spam-Status: No, SCORE=0.50 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MIME_BOUND_MANY_HEX, MSGID_FROM_MTA_ID X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54385 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MIME_BOUND_MANY_HEX Spam tool pattern in MIME boundary 0.70 MSGID_FROM_MTA_ID Message-Id for external message added locally 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: 16564 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bungapapan@gmail.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format --b323dbd6-61d5-46d9-95d4-477be938b430 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Menerima pesanan khusus pembuatan "Bunga Papan'' untuk ucapan selamat perni= kahan, ucapan belasungkawa, ucapan untuk peresmian usaha, ulang tahun, dll = untuk daerah jabodetabek. Harga mulai Rp.350.000,- Terimakasih, 021 93606390 0818745955 http://www.bungapapan.net/ email : bungapapan@gmail.com messenger : bungapapan@hotmail.com =20=20 --b323dbd6-61d5-46d9-95d4-477be938b430-- From owner-xfs@oss.sgi.com Thu Jun 26 04:20:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 04:20:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5QBKfDX005686 for ; Thu, 26 Jun 2008 04:20:41 -0700 X-ASG-Debug-ID: 1214479299-5e5801e60000-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 15498286E1F for ; Thu, 26 Jun 2008 04:21:40 -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 ipdNIdDVGiY2LjG7 for ; Thu, 26 Jun 2008 04:21:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGANexXkh5LG+uZWdsb2JhbACSahICHpsi X-IronPort-AV: E=Sophos;i="4.27,708,1204464600"; d="scan'208";a="143488518" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail04.adl2.internode.on.net with ESMTP; 26 Jun 2008 20:51:35 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBpXh-0004Ww-Tk; Thu, 26 Jun 2008 21:21:33 +1000 Date: Thu, 26 Jun 2008 21:21:33 +1000 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626112133.GJ11558@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626074636.GB7064@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626074636.GB7064@infradead.org> 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: 1214479302 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.54384 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: 16565 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 Thu, Jun 26, 2008 at 03:46:36AM -0400, Christoph Hellwig wrote: > On Thu, Jun 26, 2008 at 02:41:12PM +1000, Dave Chinner wrote: > > XFS object flushing doesn't quite match existing completion semantics. It > > mixed exclusive access with completion. That is, we need to mark an object as > > being flushed before flushing it to disk, and then block any other attempt to > > flush it until the completion occurs. > > > > To do this we introduce: > > > > void init_completion_flush(struct completion *x) > > which initialises x->done = 1 > > > > void completion_flush_start(struct completion *x) > > which blocks if done == 0, otherwise decrements done to zero and > > allows the caller to continue. > > > > bool completion_flush_start_nowait(struct completion *x) > > returns a failure status if done == 0, otherwise decrements done > > to zero and returns a "flush started" status. This is provided > > to allow flushing to begin safely while holding object locks in > > inverted order. > > > > This replaces the use of semaphores for providing this exclusion > > and completion mechanism. > > Given that the only API call shared with normal completions is > complete() I'd rather make this a primitive of it's own, even if > internally implemented as completions. Ok, so that involves exactly what? A new header file, a new API name (ideas anyone?) and kerneldoc comments? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 04:25:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 04:25:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5QBPPK9006738 for ; Thu, 26 Jun 2008 04:25:25 -0700 X-ASG-Debug-ID: 1214479585-5a4a01c60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.parisc-linux.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6B71711D63DD for ; Thu, 26 Jun 2008 04:26:26 -0700 (PDT) Received: from mail.parisc-linux.org (palinux.external.hp.com [192.25.206.14]) by cuda.sgi.com with ESMTP id hIt4jkGloz52dyfe for ; Thu, 26 Jun 2008 04:26:26 -0700 (PDT) Received: by mail.parisc-linux.org (Postfix, from userid 26919) id 3E45B494005; Thu, 26 Jun 2008 05:26:13 -0600 (MDT) Date: Thu, 26 Jun 2008 05:26:12 -0600 From: Matthew Wilcox To: Dave Chinner Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626112612.GW4392@parisc-linux.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214455277-6387-2-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: palinux.external.hp.com[192.25.206.14] X-Barracuda-Start-Time: 1214479586 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.54384 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: 16566 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: xfs On Thu, Jun 26, 2008 at 02:41:12PM +1000, Dave Chinner wrote: > XFS object flushing doesn't quite match existing completion semantics. It > mixed exclusive access with completion. That is, we need to mark an object as > being flushed before flushing it to disk, and then block any other attempt to > flush it until the completion occurs. This sounds like mutex semantics. Why are the existing mutexes not appropriate for your needs? -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." From owner-xfs@oss.sgi.com Thu Jun 26 04:28:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 04:28: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=-0.7 required=5.0 tests=AWL,BAYES_00,SUBJ_MILLIONS 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 m5QBSidE007488 for ; Thu, 26 Jun 2008 04:28:44 -0700 X-ASG-Debug-ID: 1214479783-5a4901f70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from deliver.uni-koblenz.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DBFBF11D6412 for ; Thu, 26 Jun 2008 04:29:44 -0700 (PDT) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by cuda.sgi.com with ESMTP id PPNoq84TgG0UEbWH for ; Thu, 26 Jun 2008 04:29:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 89171789A0FE; Thu, 26 Jun 2008 13:29:43 +0200 (CEST) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28134-04; Thu, 26 Jun 2008 13:29:42 +0200 (CEST) Received: from bruch.uni-koblenz.de (bruch.uni-koblenz.de [141.26.64.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id ADFB8789A0FC; Thu, 26 Jun 2008 13:29:42 +0200 (CEST) Message-ID: <48637DA6.8040300@uni-koblenz.de> Date: Thu, 26 Jun 2008 13:29:42 +0200 From: Christoph Litauer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Emmanuel Florac CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Performance problems with millions of inodes Subject: Re: Performance problems with millions of inodes References: <4862598B.80905@uni-koblenz.de> <48625A46.1060206@uni-koblenz.de> <20080625180222.12885793@harpe.intellique.com> In-Reply-To: <20080625180222.12885793@harpe.intellique.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at uni-koblenz.de X-Barracuda-Connect: deliver.uni-koblenz.de[141.26.64.15] X-Barracuda-Start-Time: 1214479784 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.54384 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16567 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: litauer@uni-koblenz.de Precedence: bulk X-list: xfs Emmanuel Florac schrieb: > Le Wed, 25 Jun 2008 16:46:30 +0200 > Christoph Litauer écrivait: > >>> Maybe the 143 million inodes cause this effect? Any idea how to >>> avoid it? > > Maybe you should try to add a "nobarrier" option at mount on the > slowest machine. Barriers can slow down operation tremendously... > Thanks for this hint. nobarrier improved file creation performance significantly (about 50 times). -- Regards Christoph ________________________________________________________________________ Christoph Litauer litauer@uni-koblenz.de Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311 PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2 From owner-xfs@oss.sgi.com Thu Jun 26 04:31:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 04:31:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5QBVDFq008202 for ; Thu, 26 Jun 2008 04:31:13 -0700 X-ASG-Debug-ID: 1214479932-130e00ef0000-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 56AB9182B66E for ; Thu, 26 Jun 2008 04:32:13 -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 CqiDS4AFf4nvRUsW for ; Thu, 26 Jun 2008 04:32:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmEGANexXkh5LG+uZWdsb2JhbACSahICHpsi X-IronPort-AV: E=Sophos;i="4.27,708,1204464600"; d="scan'208";a="143496978" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail04.adl2.internode.on.net with ESMTP; 26 Jun 2008 21:02:11 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBphx-0004m5-S3; Thu, 26 Jun 2008 21:32:09 +1000 Date: Thu, 26 Jun 2008 21:32:09 +1000 From: Dave Chinner To: Matthew Wilcox Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626113209.GK11558@disturbed> Mail-Followup-To: Matthew Wilcox , xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626112612.GW4392@parisc-linux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626112612.GW4392@parisc-linux.org> 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: 1214479934 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.54385 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: 16568 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 Thu, Jun 26, 2008 at 05:26:12AM -0600, Matthew Wilcox wrote: > On Thu, Jun 26, 2008 at 02:41:12PM +1000, Dave Chinner wrote: > > XFS object flushing doesn't quite match existing completion semantics. It > > mixed exclusive access with completion. That is, we need to mark an object as > > being flushed before flushing it to disk, and then block any other attempt to > > flush it until the completion occurs. > > This sounds like mutex semantics. Why are the existing mutexes not > appropriate for your needs? Different threads doing wait and complete. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 04:41:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 04:41:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 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 m5QBfrV6009976 for ; Thu, 26 Jun 2008 04:41:53 -0700 X-ASG-Debug-ID: 1214480573-786401400000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.parisc-linux.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D6AEF11D5A71 for ; Thu, 26 Jun 2008 04:42:53 -0700 (PDT) Received: from mail.parisc-linux.org (palinux.external.hp.com [192.25.206.14]) by cuda.sgi.com with ESMTP id 78BR6XQFRJSxIvmH for ; Thu, 26 Jun 2008 04:42:53 -0700 (PDT) Received: by mail.parisc-linux.org (Postfix, from userid 26919) id 0A225494007; Thu, 26 Jun 2008 05:42:42 -0600 (MDT) Date: Thu, 26 Jun 2008 05:42:42 -0600 From: Matthew Wilcox To: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626114242.GX4392@parisc-linux.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626112612.GW4392@parisc-linux.org> <20080626113209.GK11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626113209.GK11558@disturbed> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: palinux.external.hp.com[192.25.206.14] X-Barracuda-Start-Time: 1214480573 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.54386 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: 16569 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: xfs On Thu, Jun 26, 2008 at 09:32:09PM +1000, Dave Chinner wrote: > On Thu, Jun 26, 2008 at 05:26:12AM -0600, Matthew Wilcox wrote: > > On Thu, Jun 26, 2008 at 02:41:12PM +1000, Dave Chinner wrote: > > > XFS object flushing doesn't quite match existing completion semantics. It > > > mixed exclusive access with completion. That is, we need to mark an object as > > > being flushed before flushing it to disk, and then block any other attempt to > > > flush it until the completion occurs. > > > > This sounds like mutex semantics. Why are the existing mutexes not > > appropriate for your needs? > > Different threads doing wait and complete. Then let's leave it as a semaphore. You can get rid of the sema_t if you like, but I don't think that turning completions into semaphores is a good idea (because it's confusing). -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." From owner-xfs@oss.sgi.com Thu Jun 26 05:20:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 05:20:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 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 m5QCKFhQ015980 for ; Thu, 26 Jun 2008 05:20:16 -0700 X-ASG-Debug-ID: 1214482875-510a03db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 74C7112CBC02 for ; Thu, 26 Jun 2008 05:21:15 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id MVCsAdtNA3Gmeuor for ; Thu, 26 Jun 2008 05:21:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIDAMwmY0h5LG+uZWdsb2JhbACSYBICHp9T X-IronPort-AV: E=Sophos;i="4.27,708,1204464600"; d="scan'208";a="135838271" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 21:51:13 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBqTQ-0005op-JO; Thu, 26 Jun 2008 22:21:12 +1000 Date: Thu, 26 Jun 2008 22:21:12 +1000 From: Dave Chinner To: Matthew Wilcox Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626122112.GL11558@disturbed> Mail-Followup-To: Matthew Wilcox , xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626112612.GW4392@parisc-linux.org> <20080626113209.GK11558@disturbed> <20080626114242.GX4392@parisc-linux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626114242.GX4392@parisc-linux.org> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214482876 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.54386 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: 16570 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 Thu, Jun 26, 2008 at 05:42:42AM -0600, Matthew Wilcox wrote: > On Thu, Jun 26, 2008 at 09:32:09PM +1000, Dave Chinner wrote: > > On Thu, Jun 26, 2008 at 05:26:12AM -0600, Matthew Wilcox wrote: > > > On Thu, Jun 26, 2008 at 02:41:12PM +1000, Dave Chinner wrote: > > > > XFS object flushing doesn't quite match existing completion semantics. It > > > > mixed exclusive access with completion. That is, we need to mark an object as > > > > being flushed before flushing it to disk, and then block any other attempt to > > > > flush it until the completion occurs. > > > > > > This sounds like mutex semantics. Why are the existing mutexes not > > > appropriate for your needs? > > > > Different threads doing wait and complete. > > Then let's leave it as a semaphore. You can get rid of the sema_t if > you like, but I don't think that turning completions into semaphores is > a good idea (because it's confusing). So remind me what the point of the semaphore removal tree is again? As Christoph suggested, I can put this under another API that is implemented using completions. If I have to do that in XFS, so be it.... The main reason for this that we've just uncovered the fact that the way XFS uses semaphores is completely unsafe [*] on x86/x86_64 for kernels prior to the new generic semaphores. [*] 2.6.20 panics in up() because of this race when I/O completion (the up call) races with a simultaneous down() (iowaiter): T1 T2 up() down() kmem_free() When the down() call completes, the up() call can still be referencing the semaphore, and hence if we free the structure after the down call then the up() will reference freed memory. This is probably the cause of many unexplained log replay or unmount panics that we've been hitting for years with buffers that been freed while apparently still in use.... Hence I'd prefer just to move completely away from semaphores for this flush interface. I'd like to start with getting the upstream code fixed in a sane manner so all the backports to older kernels start from the same series of commits. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 05:31:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 05:31:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,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 m5QCVKTH017617 for ; Thu, 26 Jun 2008 05:31:20 -0700 X-ASG-Debug-ID: 1214483540-130702360000-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 4F94E182BA28 for ; Thu, 26 Jun 2008 05:32:20 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by cuda.sgi.com with ESMTP id hIrCB1xG3uWKRkQv for ; Thu, 26 Jun 2008 05:32:20 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so4730fgb.8 for ; Thu, 26 Jun 2008 05:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:mime-version:content-type:content-transfer-encoding :content-disposition; bh=C5yEeXjqdk4kh45p4/RM7lI2lLw3h8xI7HOZF9pzlCs=; b=f8lPEhdWYQjdkWEiL4BFN+oM7lGuTenOWmE1r4ZB9zy4Q2LDUiAE2h+kvPRuMiMeMN Dz4IH89B+7/PKbhACQVvVEURllHPGEwIMQ/v6uo46riQLc3jhp5X8xlodi1OOaWVgjuw j5z3J7FtQwd2joXbnyd+4LV4oVToQOduMDEs0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:mime-version:content-type :content-transfer-encoding:content-disposition; b=fBD3bupBWw6zZkJev2H+BXFl9R6iedvDDPmsd1doo2wBmbRHWWyDDR/a7/oENiw1U0 llEtFyda0sdzZOHnoe1JfJj/XkuDTE4sOFniuBPjT9cDYKQGcCkuRMFlZQZRktEEadN5 nIOmJHNQ7LmeMnxjE80NtPZ1jIBv2YR0emPZs= Received: by 10.86.80.17 with SMTP id d17mr47371fgb.24.1214483539888; Thu, 26 Jun 2008 05:32:19 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Thu, 26 Jun 2008 05:32:19 -0700 (PDT) Message-ID: <6101e8c40806260532j3bed1c7k9a60c41ea297549f@mail.gmail.com> Date: Thu, 26 Jun 2008 14:32:19 +0200 From: "Oliver Pinter" To: "Christoph Hellwig" , "Dave Chinner" X-ASG-Orig-Subj: [XFS] kernel panic on halt (2.6.26-rc7) Subject: [XFS] kernel panic on halt (2.6.26-rc7) Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org, "Eric Sandeen" , "Matthew Wilcox" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.152] X-Barracuda-Start-Time: 1214483541 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.54388 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: 16571 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs Hi Christoph, Dave, a similar problem came out the with 2.6.26, than the was in post early with 2.6.25[1][2] http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00807.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00808.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00809.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00810.jpg http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00811.jpg the git head is on 2.6.26-rc7, was an any kind of bigger load however here, only desktop usage the compiler is GCC-4.3.1 gcc (Debian 4.3.1-2) 4.3.1 pc: i386 (Pentium 4 HT Northwood, with enabled HT ) fs usage: 88% -- [1] http://archives.free.net.ph/thread/20080616.100122.14303e7a.en.html [2] http://students.zipernowsky.hu/~oliverp/upload/xfs_error/ -- Thanks, Oliver From owner-xfs@oss.sgi.com Thu Jun 26 05:39:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 05:39:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,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 m5QCd9ZT019025 for ; Thu, 26 Jun 2008 05:39:09 -0700 X-ASG-Debug-ID: 1214484010-1303025a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.parisc-linux.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BE1DE182BB0B for ; Thu, 26 Jun 2008 05:40:10 -0700 (PDT) Received: from mail.parisc-linux.org (palinux.external.hp.com [192.25.206.14]) by cuda.sgi.com with ESMTP id P9JbgbcGFPgJCuS4 for ; Thu, 26 Jun 2008 05:40:10 -0700 (PDT) Received: by mail.parisc-linux.org (Postfix, from userid 26919) id D9D77494005; Thu, 26 Jun 2008 06:40:09 -0600 (MDT) Date: Thu, 26 Jun 2008 06:40:09 -0600 From: Matthew Wilcox To: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626124009.GY4392@parisc-linux.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626112612.GW4392@parisc-linux.org> <20080626113209.GK11558@disturbed> <20080626114242.GX4392@parisc-linux.org> <20080626122112.GL11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626122112.GL11558@disturbed> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: palinux.external.hp.com[192.25.206.14] X-Barracuda-Start-Time: 1214484010 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.54388 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: 16572 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: xfs On Thu, Jun 26, 2008 at 10:21:12PM +1000, Dave Chinner wrote: > On Thu, Jun 26, 2008 at 05:42:42AM -0600, Matthew Wilcox wrote: > > Then let's leave it as a semaphore. You can get rid of the sema_t if > > you like, but I don't think that turning completions into semaphores is > > a good idea (because it's confusing). > > So remind me what the point of the semaphore removal tree is again? To remove the semaphores which don't need to be semaphores any more. > As Christoph suggested, I can put this under another API that > is implemented using completions. If I have to do that in XFS, > so be it.... You could, yes. But you could just use completions directly ... > The main reason for this that we've just uncovered the fact that the > way XFS uses semaphores is completely unsafe [*] on x86/x86_64 for > kernels prior to the new generic semaphores. > > [*] 2.6.20 panics in up() because of this race when I/O completion > (the up call) races with a simultaneous down() (iowaiter): > > T1 T2 > up() down() > kmem_free() > > When the down() call completes, the up() call can still be > referencing the semaphore, and hence if we free the structure after > the down call then the up() will reference freed memory. This is > probably the cause of many unexplained log replay or unmount panics > that we've been hitting for years with buffers that been freed while > apparently still in use.... This is exactly the kind of thing completions were supposed to be used for. T1 should be calling complete() and T2 should be calling wait_for_completion(). > Hence I'd prefer just to move completely away from semaphores for > this flush interface. I'd like to start with getting the upstream > code fixed in a sane manner so all the backports to older kernels > start from the same series of commits. That's sane. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." From owner-xfs@oss.sgi.com Thu Jun 26 05:48:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 05:48:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5QCmAYH020453 for ; Thu, 26 Jun 2008 05:48:11 -0700 X-ASG-Debug-ID: 1214484551-131002840000-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 D8925182BCDF for ; Thu, 26 Jun 2008 05:49:11 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id aAMGIuD0UI5AkXFI for ; Thu, 26 Jun 2008 05:49:11 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBquV-0000Pl-Kl; Thu, 26 Jun 2008 12:49:11 +0000 Date: Thu, 26 Jun 2008 08:49:11 -0400 From: Christoph Hellwig To: Matthew Wilcox Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626124911.GA19285@infradead.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626112612.GW4392@parisc-linux.org> <20080626113209.GK11558@disturbed> <20080626114242.GX4392@parisc-linux.org> <20080626122112.GL11558@disturbed> <20080626124009.GY4392@parisc-linux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626124009.GY4392@parisc-linux.org> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214484551 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.54388 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: 16573 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 Thu, Jun 26, 2008 at 06:40:09AM -0600, Matthew Wilcox wrote: > On Thu, Jun 26, 2008 at 10:21:12PM +1000, Dave Chinner wrote: > > On Thu, Jun 26, 2008 at 05:42:42AM -0600, Matthew Wilcox wrote: > > > Then let's leave it as a semaphore. You can get rid of the sema_t if > > > you like, but I don't think that turning completions into semaphores is > > > a good idea (because it's confusing). > > > > So remind me what the point of the semaphore removal tree is again? > > To remove the semaphores which don't need to be semaphores any more. > > > As Christoph suggested, I can put this under another API that > > is implemented using completions. If I have to do that in XFS, > > so be it.... > > You could, yes. But you could just use completions directly ... > > > The main reason for this that we've just uncovered the fact that the > > way XFS uses semaphores is completely unsafe [*] on x86/x86_64 for > > kernels prior to the new generic semaphores. > > > > [*] 2.6.20 panics in up() because of this race when I/O completion > > (the up call) races with a simultaneous down() (iowaiter): > > > > T1 T2 > > up() down() > > kmem_free() > > > > When the down() call completes, the up() call can still be > > referencing the semaphore, and hence if we free the structure after > > the down call then the up() will reference freed memory. This is > > probably the cause of many unexplained log replay or unmount panics > > that we've been hitting for years with buffers that been freed while > > apparently still in use.... > > This is exactly the kind of thing completions were supposed to be used > for. T1 should be calling complete() and T2 should be calling > wait_for_completion(). Please read Dave's introductionary mail. What XFS wants if completions with a little bit extra, so he implemented the little bit extra. This little bit extra is pretty well described in the mail starting this thread. From owner-xfs@oss.sgi.com Thu Jun 26 05:48:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 05:49:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5QCmu3I020801 for ; Thu, 26 Jun 2008 05:48:56 -0700 X-ASG-Debug-ID: 1214484595-60a203b00000-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 09AF6287211 for ; Thu, 26 Jun 2008 05:49:56 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by cuda.sgi.com with ESMTP id UshRNuw754NZoKhk for ; Thu, 26 Jun 2008 05:49:56 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so7853fgb.8 for ; Thu, 26 Jun 2008 05:49:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=xkksoHS9qsGpL353XffHzTbU9Q+tmRHG5LO15TDWcyU=; b=m5s310k97s6xc66NjsTvjBKqQe7LBm5EEveJ+Sd3arEWhsKPhuUpYj5vpBYhijiumV 4xXLbHA0DEvzKjgH4xe42VNjxxPTYDdigkYNbO/VBNs1ErBSBa1QA4o7I4dm47voBgX5 SNzYVoM7RZEKVt4RFgHm16NJ9Ziia38kFK4ZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=qFi/BkvJl6VHRPkpLdIeWZEjN64fFo/cI5L3jgV5J+nRbnb5LXVlcm2ep5A4BOLwYK X3S6ofwAvVhwY87pguq4RSeV68pn8Vr/EI98Qc+s3W/4FXIXhXG202D1k6y3PdhSTbSB WYWCHQ8wDd3snB7AsE1ClqLfw1XXkeF3eNgPk= Received: by 10.86.93.17 with SMTP id q17mr72581fgb.25.1214484594574; Thu, 26 Jun 2008 05:49:54 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Thu, 26 Jun 2008 05:49:54 -0700 (PDT) Message-ID: <6101e8c40806260549m63ca2899hd1d13de0bd36a6d4@mail.gmail.com> Date: Thu, 26 Jun 2008 14:49:54 +0200 From: "Oliver Pinter" To: "Christoph Hellwig" , "Dave Chinner" X-ASG-Orig-Subj: Re: [XFS] kernel panic on halt (2.6.26-rc7) Subject: Re: [XFS] kernel panic on halt (2.6.26-rc7) Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org, "Eric Sandeen" , "Matthew Wilcox" In-Reply-To: <6101e8c40806260532j3bed1c7k9a60c41ea297549f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806260532j3bed1c7k9a60c41ea297549f@mail.gmail.com> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.158] X-Barracuda-Start-Time: 1214484597 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.54391 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: 16574 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs (this an other machine, than the earlier) and same problem[1] [1] http://archives.free.net.ph/message/20080616.045221.1905ae63.en.html [2] http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00807.jpg On 6/26/08, Oliver Pinter wrote: > Hi Christoph, Dave, > > a similar problem came out the with 2.6.26, than the was in post early > with 2.6.25[1][2] > > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00807.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00808.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00809.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00810.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00811.jpg > > the git head is on 2.6.26-rc7, > was an any kind of bigger load however here, only desktop usage > > the compiler is GCC-4.3.1 gcc (Debian 4.3.1-2) 4.3.1 > pc: i386 (Pentium 4 HT Northwood, with enabled HT ) > > fs usage: 88% > > > -- > [1] http://archives.free.net.ph/thread/20080616.100122.14303e7a.en.html > [2] http://students.zipernowsky.hu/~oliverp/upload/xfs_error/ > -- > Thanks, > Oliver > -- Thanks, Oliver From owner-xfs@oss.sgi.com Thu Jun 26 06:01:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 06:01:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 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 m5QD1946022860 for ; Thu, 26 Jun 2008 06:01:09 -0700 X-ASG-Debug-ID: 1214485327-615d013c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 911C712CC3A8 for ; Thu, 26 Jun 2008 06:02:07 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id GjgwwG8ECVjbGEma for ; Thu, 26 Jun 2008 06:02:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIDANQtY0h5LG+uZWdsb2JhbACSYRICHp9e X-IronPort-AV: E=Sophos;i="4.27,708,1204464600"; d="scan'208";a="135860174" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 22:32:05 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBr6y-0006jN-Gy; Thu, 26 Jun 2008 23:02:04 +1000 Date: Thu, 26 Jun 2008 23:02:04 +1000 From: Dave Chinner To: Matthew Wilcox Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626130204.GR29319@disturbed> Mail-Followup-To: Matthew Wilcox , xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626112612.GW4392@parisc-linux.org> <20080626113209.GK11558@disturbed> <20080626114242.GX4392@parisc-linux.org> <20080626122112.GL11558@disturbed> <20080626124009.GY4392@parisc-linux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626124009.GY4392@parisc-linux.org> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214485329 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.54386 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: 16575 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 Thu, Jun 26, 2008 at 06:40:09AM -0600, Matthew Wilcox wrote: > On Thu, Jun 26, 2008 at 10:21:12PM +1000, Dave Chinner wrote: > > On Thu, Jun 26, 2008 at 05:42:42AM -0600, Matthew Wilcox wrote: > > > Then let's leave it as a semaphore. You can get rid of the sema_t if > > > you like, but I don't think that turning completions into semaphores is > > > a good idea (because it's confusing). > > > > So remind me what the point of the semaphore removal tree is again? > > To remove the semaphores which don't need to be semaphores any more. Or shouldn't be semaphores in the first place? > > As Christoph suggested, I can put this under another API that > > is implemented using completions. If I have to do that in XFS, > > so be it.... > > You could, yes. But you could just use completions directly ... Not that I can see. > > The main reason for this that we've just uncovered the fact that the > > way XFS uses semaphores is completely unsafe [*] on x86/x86_64 for > > kernels prior to the new generic semaphores. > > > > [*] 2.6.20 panics in up() because of this race when I/O completion > > (the up call) races with a simultaneous down() (iowaiter): > > > > T1 T2 > > up() down() > > kmem_free() > > > > When the down() call completes, the up() call can still be > > referencing the semaphore, and hence if we free the structure after > > the down call then the up() will reference freed memory. This is > > probably the cause of many unexplained log replay or unmount panics > > that we've been hitting for years with buffers that been freed while > > apparently still in use.... > > This is exactly the kind of thing completions were supposed to be used > for. T1 should be calling complete() and T2 should be calling > wait_for_completion(). Yes, certainly. But as should be obvious by now completions don't quite fit the bill for XFS - they only work for *synchronisation* after the I/O. XFS needs *exclusion* during the I/O as well as *synchronisation* after the I/O. The completion extensions provided the exclusion part of the deal. How else do you suggest I implement this? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 06:06:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 06:06: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=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 m5QD5xpD023893 for ; Thu, 26 Jun 2008 06:06:00 -0700 X-ASG-Debug-ID: 1214485620-130403250000-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 DC2FF182C03B for ; Thu, 26 Jun 2008 06:07:00 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id bXuo455AIIrDlTBA for ; Thu, 26 Jun 2008 06:07:00 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KBrBk-0002H3-LR; Thu, 26 Jun 2008 13:07:00 +0000 Date: Thu, 26 Jun 2008 09:07:00 -0400 From: Christoph Hellwig To: Christoph Hellwig , xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626130700.GA24325@infradead.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626074636.GB7064@infradead.org> <20080626112133.GJ11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626112133.GJ11558@disturbed> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214485620 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.86 X-Barracuda-Spam-Status: No, SCORE=0.86 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RATWARE_EFROM X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54391 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 2.88 RATWARE_EFROM Bulk email fingerprint (envfrom) found 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: 16576 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 Thu, Jun 26, 2008 at 09:21:33PM +1000, Dave Chinner wrote: > Ok, so that involves exactly what? A new header file, a new API name > (ideas anyone?) and kerneldoc comments? Yes, probably just a new header with properly documented functions. Thew two non-trivial ones you added should probably not be inlines, btw. flush_lock_init/flush_lock/flush_trylock/flush_done/flush_is_locked? From owner-xfs@oss.sgi.com Thu Jun 26 06:17:33 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 06:17:36 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (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 m5QDHXtI025872 for ; Thu, 26 Jun 2008 06:17:33 -0700 X-ASG-Debug-ID: 1214486312-653902200000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 36BC611D6622 for ; Thu, 26 Jun 2008 06:18:33 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id voRNgeicES5cvQnK for ; Thu, 26 Jun 2008 06:18:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIDANQtY0h5LG+uZWdsb2JhbACSYRICHp9e X-IronPort-AV: E=Sophos;i="4.27,708,1204464600"; d="scan'208";a="135867909" Received: from ppp121-44-111-174.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.111.174]) by ipmail01.adl6.internode.on.net with ESMTP; 26 Jun 2008 22:48:30 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KBrMr-00075Y-U1; Thu, 26 Jun 2008 23:18:29 +1000 Date: Thu, 26 Jun 2008 23:18:29 +1000 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080626131829.GT29319@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <20080626074636.GB7064@infradead.org> <20080626112133.GJ11558@disturbed> <20080626130700.GA24325@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080626130700.GA24325@infradead.org> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214486314 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.54392 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: 16577 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 Thu, Jun 26, 2008 at 09:07:00AM -0400, Christoph Hellwig wrote: > On Thu, Jun 26, 2008 at 09:21:33PM +1000, Dave Chinner wrote: > > Ok, so that involves exactly what? A new header file, a new API name > > (ideas anyone?) and kerneldoc comments? > > Yes, probably just a new header with properly documented functions. > Thew two non-trivial ones you added should probably not be inlines, > btw. Yeah, they grew a little bigger than expected... > flush_lock_init/flush_lock/flush_trylock/flush_done/flush_is_locked? Ok, I was thinking along those lines. I'll redo the patch series using that interface tomorrow. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 06:24:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 06:24:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5QDODSE027022 for ; Thu, 26 Jun 2008 06:24:13 -0700 X-ASG-Debug-ID: 1214486713-1a1300bb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6570028795A for ; Thu, 26 Jun 2008 06:25:13 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 5Mz2HyP0xXDkdcv4 for ; Thu, 26 Jun 2008 06:25:13 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id CBCA8A84093; Thu, 26 Jun 2008 08:25:12 -0500 (CDT) Message-ID: <486398B7.50306@sandeen.net> Date: Thu, 26 Jun 2008 08:25:11 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Timothy Shimmin CC: xfs-oss , LinuxRaid , NeilBrown , jeremy@sgi.comwe X-ASG-Orig-Subj: Re: [PATCH] disable queue flag test in barrier check Subject: Re: [PATCH] disable queue flag test in barrier check References: <486307EA.7080007@sandeen.net> <48635284.3060001@sgi.com> In-Reply-To: <48635284.3060001@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214486714 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.54393 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: 16578 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Timothy Shimmin wrote: > Also from memory, I believe Neil checked this removal into the SLES10sp1 tree > and some sgi boxes started having slow downs > (looking at Dave's email below - we were not wanting to tell them > to use nobarrier but needed it to work by default - I forget now). But that's an admin issue. The way it is now, for example a home user of md raid1 (me!) can't run barriers even if they wanted to. Until there is a way to know if a write cache is non-volatile the only safe option is to enable barriers when possible. > 6. >> Date: Wed, 25 Jun 2008 08:57:24 +1000 >> From: Dave Chinner >> To: Eric Sandeen >> Cc: LinuxRaid , xfs-oss >> Subject: Re: md raid1 passes barriers, but xfs doesn't use them? >> >> Yeah, the problem was that last time this check was removed was >> that a bunch of existing hardware had barriers enabled on them when >> not necessary (e.g. had NVRAM) and they went 5x slower on MD raid1 >> devices. Having to change the root drive config on a wide install >> base was considered much more of support pain than leaving the >> check there. I guess that was more of a distro upgrade issue than >> a mainline problem, but that's the history. Hence I think we >> should probably do whatever everyone else is doing here.... >> >> Cheers, >> >> Dave. > > So I guess my question is whether there are cases where we are > going to be in trouble again. > Jeremy, do you see some problems? FWIW, the problem *I* foresee is that some people are going to slow down when using the defaults, yes, because barriers will start working again. But I don't see any other safe way around it. Education would be in order, I suppose. :) -Eric > --Tim > > > From owner-xfs@oss.sgi.com Thu Jun 26 07:48:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 07:48:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5QEm4U8005843 for ; Thu, 26 Jun 2008 07:48:04 -0700 X-ASG-Debug-ID: 1214491744-489402450000-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 2277611D7315 for ; Thu, 26 Jun 2008 07:49:04 -0700 (PDT) Received: from server515.appriver.com (server515i.exghost.com [72.32.253.75]) by cuda.sgi.com with ESMTP id n8RWxALNiKaOYLAx for ; Thu, 26 Jun 2008 07:49:04 -0700 (PDT) Received: by server515.appriver.com (CommuniGate Pro PIPE 5.2.0) with PIPE id 47202023; Thu, 26 Jun 2008 09:49:02 -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 47202016; Thu, 26 Jun 2008 09:48:58 -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); Thu, 26 Jun 2008 09:48:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: RE: [PATCH] disable queue flag test in barrier check Subject: RE: [PATCH] disable queue flag test in barrier check Date: Thu, 26 Jun 2008 09:47:19 -0500 Message-ID: In-Reply-To: <486398B7.50306@sandeen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] disable queue flag test in barrier check Thread-Index: AcjXmmk5/1pKARn0SJeYqGkv09DhYAAAD1iQ References: <486307EA.7080007@sandeen.net> <48635284.3060001@sgi.com> <486398B7.50306@sandeen.net> From: "David Lethe" To: "Eric Sandeen" , "Timothy Shimmin" Cc: "xfs-oss" , "LinuxRaid" , "NeilBrown" , X-OriginalArrivalTime: 26 Jun 2008 14:48:57.0747 (UTC) FILETIME=[C35ACE30:01C8D79B] X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Primary: david@santools.com X-Note: This Email was scanned by AppRiver SecureTide X-ALLOW: david@santools.com ALLOWED X-Virus-Scan: V- X-Note: Spam Tests Failed: X-Country-Path: PRIVATE->UNITED STATES->UNITED STATES X-Note-Sending-IP: 72.32.49.5 X-Note-Reverse-DNS: fe1.exchange.rackspace.com X-Note-WHTLIST: david@santools.com X-Note: User Rule Hits: X-Note: Global Rule Hits: 81 82 83 84 150 X-Note: Mail Class: ALLOWEDSENDER X-Barracuda-Connect: server515i.exghost.com[72.32.253.75] X-Barracuda-Start-Time: 1214491745 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.54398 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 m5QEm4U8005852 X-archive-position: 16579 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 Fyi - related problem is seen with solaris & zfs when users attach them to hardware-based RAID subsystems. The vendors had to make firmware tweaks to address solaris's flush-to-disk-after-all-writes. Not sure what you mean about non-volatile vs. volatile write cache, however. If you want to see if write cache is enabled on a disk drive, or Even a logical disk on a hardware-based RAId, under Linux, then google "mode page editor" for lots of choices. Also look up zfs write cache raid and you'll get information that you can just as easily apply to Linux implementations of md. -----Original Message----- From: linux-raid-owner@vger.kernel.org [mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Eric Sandeen Sent: Thursday, June 26, 2008 8:25 AM To: Timothy Shimmin Cc: xfs-oss; LinuxRaid; NeilBrown; jeremy@sgi.comwe Subject: Re: [PATCH] disable queue flag test in barrier check Timothy Shimmin wrote: > Also from memory, I believe Neil checked this removal into the SLES10sp1 tree > and some sgi boxes started having slow downs > (looking at Dave's email below - we were not wanting to tell them > to use nobarrier but needed it to work by default - I forget now). But that's an admin issue. The way it is now, for example a home user of md raid1 (me!) can't run barriers even if they wanted to. Until there is a way to know if a write cache is non-volatile the only safe option is to enable barriers when possible. > 6. >> Date: Wed, 25 Jun 2008 08:57:24 +1000 >> From: Dave Chinner >> To: Eric Sandeen >> Cc: LinuxRaid , xfs-oss >> Subject: Re: md raid1 passes barriers, but xfs doesn't use them? >> >> Yeah, the problem was that last time this check was removed was >> that a bunch of existing hardware had barriers enabled on them when >> not necessary (e.g. had NVRAM) and they went 5x slower on MD raid1 >> devices. Having to change the root drive config on a wide install >> base was considered much more of support pain than leaving the >> check there. I guess that was more of a distro upgrade issue than >> a mainline problem, but that's the history. Hence I think we >> should probably do whatever everyone else is doing here.... >> >> Cheers, >> >> Dave. > > So I guess my question is whether there are cases where we are > going to be in trouble again. > Jeremy, do you see some problems? FWIW, the problem *I* foresee is that some people are going to slow down when using the defaults, yes, because barriers will start working again. But I don't see any other safe way around it. Education would be in order, I suppose. :) -Eric > --Tim > > > -- 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 Thu Jun 26 07:56:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 07:56:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5QEuJ8k007228 for ; Thu, 26 Jun 2008 07:56:19 -0700 X-ASG-Debug-ID: 1214492238-4968019c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A6D31288C9C for ; Thu, 26 Jun 2008 07:57:19 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id aJZ7YB8gO7r2FaRD for ; Thu, 26 Jun 2008 07:57:19 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A3DAAA84103; Thu, 26 Jun 2008 09:57:18 -0500 (CDT) Message-ID: <4863AE4E.5060908@sandeen.net> Date: Thu, 26 Jun 2008 09:57:18 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: David Lethe CC: Timothy Shimmin , xfs-oss , LinuxRaid , NeilBrown , jeremy@sgi.comwe X-ASG-Orig-Subj: Re: [PATCH] disable queue flag test in barrier check Subject: Re: [PATCH] disable queue flag test in barrier check References: <486307EA.7080007@sandeen.net> <48635284.3060001@sgi.com> <486398B7.50306@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214492240 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.54399 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: 16580 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs David Lethe wrote: > Fyi - related problem is seen with solaris & zfs when users attach them > to hardware-based RAID subsystems. The vendors had > to make firmware tweaks to address solaris's > flush-to-disk-after-all-writes. > > Not sure what you mean about non-volatile vs. volatile write cache, > however. If you want to see if write cache is enabled on a disk drive, > or > Even a logical disk on a hardware-based RAId, under Linux, then google > "mode page editor" for lots of choices. Also look up zfs write cache > raid and you'll get information that you can just as easily apply to > Linux implementations of md. I'm not so interested in whether it is enabled; I'd like to know if it is safe (to varying degrees) in the event of a power failure, and I don't think there's any way we can know that. So the administrator, if she's sure that all cached writes will hit disk even if a breaker pops, can disable barriers. If it's just a 32MB cache seagate drive plugged into the wall, you probably had better be sure barriers are enabled or you may well have a scrambled filesystem post-power-outage. -Eric From owner-xfs@oss.sgi.com Thu Jun 26 08:23:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 08:24:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5QFNtZi014527 for ; Thu, 26 Jun 2008 08:23:55 -0700 X-ASG-Debug-ID: 1214493894-489503d10000-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 34ACF1233969 for ; Thu, 26 Jun 2008 08:24:54 -0700 (PDT) Received: from server515.appriver.com (server515a.exghost.com [72.32.253.70]) by cuda.sgi.com with ESMTP id BXJH6gIEFnseNh3s for ; Thu, 26 Jun 2008 08:24:54 -0700 (PDT) Received: by server515.appriver.com (CommuniGate Pro PIPE 5.2.0) with PIPE id 47221258; Thu, 26 Jun 2008 10:24:53 -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 47221229; Thu, 26 Jun 2008 10:24:49 -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); Thu, 26 Jun 2008 10:24:49 -0500 Received: from 192.168.1.146 ([192.168.1.146]) by 34093-C3-EVS3.exchange.rackspace.com ([192.168.1.78]) with Microsoft Exchange Server HTTP-DAV ; Thu, 26 Jun 2008 15:24:48 +0000 To: "Eric Sandeen" Reply-To: Message-ID: <22f301c8d7a0$c5e87fc0$9201a8c0@exchange.rackspace.com> Cc: "Timothy Shimmin" , "xfs-oss" , "LinuxRaid" , "NeilBrown" , X-ASG-Orig-Subj: Re: [PATCH] disable queue flag test in barrier check Subject: Re: [PATCH] disable queue flag test in barrier check Thread-Topic: [PATCH] disable queue flag test in barrier check Thread-Index: AcjXoMXoKyBbG0zmRzejZU2NS3WVIg== From: "David Lethe" Date: Thu, 26 Jun 2008 10:24: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: 26 Jun 2008 15:24:49.0971 (UTC) FILETIME=[C62E2030:01C8D7A0] X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com X-Policy: GLOBAL - santools.com 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 83 84 150 X-Note: Mail Class: ALLOWEDSENDER X-Barracuda-Connect: server515a.exghost.com[72.32.253.70] X-Barracuda-Start-Time: 1214493895 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.54400 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: 16581 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 Unflushed writes are 100% effective for losing data and corrupting file systems. Data isn't saved until it is on the magnetic media. Batterybackup modules for disk controllers help, but there is no substitute for a ups. Even with a bbu on disk controller, if the kernel hasn't flushed write to the controller, and system crashes or loses power, the kernel io queue will never reach the controllers bbu. You have a moral obligation to use a ups... And if you work for a US company, then Sarbox pretty much makes this a legal obligation and a criminal offense if you don't protect certain databases with something as reasonable and cheap as a ups -----Original Message----- From: "Eric Sandeen" Subj: Re: [PATCH] disable queue flag test in barrier check Date: Thu Jun 26, 2008 9:57 am Size: 1K To: "David Lethe" cc: "Timothy Shimmin" ; "xfs-oss" ; "LinuxRaid" ; "NeilBrown" ; "jeremy@sgi.comwe" David Lethe wrote: > Fyi - related problem is seen with solaris & zfs when users attach them > to hardware-based RAID subsystems. The vendors had > to make firmware tweaks to address solaris's > flush-to-disk-after-all-writes. > > Not sure what you mean about non-volatile vs. volatile write cache, > however. If you want to see if write cache is enabled on a disk drive, > or > Even a logical disk on a hardware-based RAId, under Linux, then google > "mode page editor" for lots of choices. Also look up zfs write cache > raid and you'll get information that you can just as easily apply to > Linux implementations of md. I'm not so interested in whether it is enabled; I'd like to know if it is safe (to varying degrees) in the event of a power failure, and I don't think there's any way we can know that. So the administrator, if she's sure that all cached writes will hit disk even if a breaker pops, can disable barriers. If it's just a 32MB cache seagate drive plugged into the wall, you probably had better be sure barriers are enabled or you may well have a scrambled filesystem post-power-outage. -Eric From owner-xfs@oss.sgi.com Thu Jun 26 08:28:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 08:28:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.1 required=5.0 tests=BAYES_50,J_CHICKENPOX_62, KB_DATE_CONTAINS_TAB,RCVD_IN_PSBL 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 m5QFSfu8015255 for ; Thu, 26 Jun 2008 08:28:41 -0700 X-ASG-Debug-ID: 1214494181-4d6303bb0000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from farizej.centrum.cz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EAF4512339F1 for ; Thu, 26 Jun 2008 08:29:42 -0700 (PDT) Received: from farizej.centrum.cz (farizej.centrum.cz [90.183.38.130]) by cuda.sgi.com with ESMTP id DuEr8buJqpCureJ0 for ; Thu, 26 Jun 2008 08:29:42 -0700 (PDT) Received: by mail255.centrum.cz id S369488640AbYFZP3N (ORCPT ); Thu, 26 Jun 2008 17:29:13 +0200 Received: from 41.207.20.210 by mail08-sk.centrum.cz (Centrum Mail) with HTTP Date: Thu, 26 Jun 2008 17:29:12 +0200 From: X-Mailer: Centrum Mail 1.0 MIME-Version: 1.0 X-Priority: 3 Message-ID: <200806261729.25173@centrum.cz> X-ASG-Orig-Subj: Hi Subject: Hi Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 8bit To: unlisted-recipients:; (no To-header on input) X-Barracuda-Connect: farizej.centrum.cz[90.183.38.130] X-Barracuda-Start-Time: 1214494182 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5000 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.30 X-Barracuda-Spam-Status: No, SCORE=1.30 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=ADVANCE_FEE_1, NO_REAL_NAME, UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54400 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.00 ADVANCE_FEE_1 Appears to be advance fee fraud (Nigerian 419) 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: 16582 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hcoleman86@centrum.sk Precedence: bulk X-list: xfs Hi Please let me make a brief presentation of myself to you, I am Ms. Hannah Coleman, 46 years. I wish to entrust you to receive my deceased husband funds (U.S. $ 45millions dollars). In your account abroad and help me invest.if you are interested please leave me; 1- your telephone number, 2- your name, 3- your work, 4- your address, 5- your country. Can I trust you? Hannah From owner-xfs@oss.sgi.com Thu Jun 26 13:32:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 13:32:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5QKWWhR015386 for ; Thu, 26 Jun 2008 13:32:34 -0700 X-ASG-Debug-ID: 1214512411-697700140000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gateway-1237.mvista.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E33DB182F6BB for ; Thu, 26 Jun 2008 13:33:31 -0700 (PDT) Received: from gateway-1237.mvista.com (gateway-1237.mvista.com [63.81.120.158]) by cuda.sgi.com with ESMTP id OS0ZGckuG100V4js for ; Thu, 26 Jun 2008 13:33:31 -0700 (PDT) Received: from [10.0.4.38] (dwalker.mvista.com [10.0.4.38]) by hermes.mvista.com (Postfix) with ESMTP id 10D51181ED; Thu, 26 Jun 2008 13:33:29 -0700 (PDT) X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements From: Daniel Walker To: Dave Chinner Cc: xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org In-Reply-To: <1214455277-6387-2-git-send-email-david@fromorbit.com> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> Content-Type: text/plain Date: Thu, 26 Jun 2008 13:33:25 -0700 Message-Id: <1214512405.21035.110.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: gateway-1237.mvista.com[63.81.120.158] X-Barracuda-Start-Time: 1214512412 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.54421 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: 16583 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dwalker@mvista.com Precedence: bulk X-list: xfs On Thu, 2008-06-26 at 14:41 +1000, Dave Chinner wrote: > XFS object flushing doesn't quite match existing completion semantics. It > mixed exclusive access with completion. That is, we need to mark an object as > being flushed before flushing it to disk, and then block any other attempt to > flush it until the completion occurs. > > To do this we introduce: > > void init_completion_flush(struct completion *x) > which initialises x->done = 1 > > void completion_flush_start(struct completion *x) > which blocks if done == 0, otherwise decrements done to zero and > allows the caller to continue. > > bool completion_flush_start_nowait(struct completion *x) > returns a failure status if done == 0, otherwise decrements done > to zero and returns a "flush started" status. This is provided > to allow flushing to begin safely while holding object locks in > inverted order. > > This replaces the use of semaphores for providing this exclusion > and completion mechanism. I think there is some basis to make the changes that you have here. Specifically this email and thread, http://lkml.org/lkml/2008/4/15/232 However, I don't like how your implementing this as specifically a "flush" mechanism for XFS, and the count is limited to just 1 .. There are several other places that do this kind of counting with semaphores, and have counts above 1.. > + > +static inline void completion_flush_start(struct completion *x) > +{ > + wait_for_completion(x); > +} Above seems completely pointless.. I would just call wait_for_completion(), and make the rest of the interface generic. Daniel From owner-xfs@oss.sgi.com Thu Jun 26 14:08:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 14:08:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5QL8CNS018767 for ; Thu, 26 Jun 2008 14:08:12 -0700 X-ASG-Debug-ID: 1214514549-2a6500fd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bob.dscon.sk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 96E1C123508F for ; Thu, 26 Jun 2008 14:09:12 -0700 (PDT) Received: from bob.dscon.sk (bob.dscon.sk [88.86.113.10]) by cuda.sgi.com with ESMTP id DKvcBdP7VTH4G1XV for ; Thu, 26 Jun 2008 14:09:12 -0700 (PDT) Received: by bob.dscon.sk (Postfix, from userid 1007) id C4BB3DC33F; Thu, 26 Jun 2008 23:09:04 +0200 (CEST) Date: Thu, 26 Jun 2008 23:09:04 +0200 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: is the flush-on-close-after-truncate still needed? Subject: Re: is the flush-on-close-after-truncate still needed? Message-ID: <20080626210904.GA15920@bob.dscon.sk> References: <4859415B.3000009@sandeen.net> <200806181049.07812.dchinner@agami.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200806181049.07812.dchinner@agami.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: xfs@bob.dscon.sk (DS) X-Barracuda-Connect: bob.dscon.sk[88.86.113.10] X-Barracuda-Start-Time: 1214514553 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.54424 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: 16584 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xfs@bob.dscon.sk Precedence: bulk X-list: xfs Hmm, but file overwrite in perl/php is slow, very slow. Which FS is best for me? XFS - perl/php overwrite problem EXT3 - 32000 subdirs limit REISER - no future JFS - ? DS On Wed, Jun 18, 2008 at 10:49:07AM -0700, Dave Chinner wrote: > On Wednesday 18 June 2008 10:09 am, Eric Sandeen wrote: > > After Lachlan's fix to separate on-disk and in-memory sizes, and only > > update on-disk when data is on-disk > > (http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the > > XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed? > > Yes, because waiting 30s before writing back /etc/fstab after it > has been modified will result in lots of bug reports of /etc/fstab > being zero length after a crash instead of being full of NULLs. > We have had very few reports of zero length files or files with > NULLs since this change was made (regardless of the file size > update ordering changes). i.e. if we remove this code then the > common case where NULL files occurred will return - only this > time as zero length files. > > Cheers, > > Dave. > > From owner-xfs@oss.sgi.com Thu Jun 26 14:18:43 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 14:18:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.7 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 m5QLIhlG020146 for ; Thu, 26 Jun 2008 14:18:43 -0700 X-ASG-Debug-ID: 1214515183-471803150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DA1F728BD8E for ; Thu, 26 Jun 2008 14:19:44 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id fx9y4UcVGKMMbWPr for ; Thu, 26 Jun 2008 14:19:44 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5QLJfBb030103; Thu, 26 Jun 2008 17:19:41 -0400 Received: from file.rdu.redhat.com (file.rdu.redhat.com [10.11.255.147]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5QLJecM002197; Thu, 26 Jun 2008 17:19:41 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by file.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id m5QLJdEn001466; Thu, 26 Jun 2008 17:19:40 -0400 Message-ID: <486407EB.70703@sandeen.net> Date: Thu, 26 Jun 2008 16:19:39 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: DS CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: is the flush-on-close-after-truncate still needed? Subject: Re: is the flush-on-close-after-truncate still needed? References: <4859415B.3000009@sandeen.net> <200806181049.07812.dchinner@agami.com> <20080626210904.GA15920@bob.dscon.sk> In-Reply-To: <20080626210904.GA15920@bob.dscon.sk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1214515184 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16585 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs DS wrote: > Hmm, but file overwrite in perl/php is slow, very slow. If you have control over your perl/php, perhaps you can change it to do unlink/create/write instead of truncate/write? -Eric > Which FS is best for me? > XFS - perl/php overwrite problem > EXT3 - 32000 subdirs limit > REISER - no future > JFS - ? > > DS > > On Wed, Jun 18, 2008 at 10:49:07AM -0700, Dave Chinner wrote: >> On Wednesday 18 June 2008 10:09 am, Eric Sandeen wrote: >>> After Lachlan's fix to separate on-disk and in-memory sizes, and only >>> update on-disk when data is on-disk >>> (http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the >>> XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed? >> Yes, because waiting 30s before writing back /etc/fstab after it >> has been modified will result in lots of bug reports of /etc/fstab >> being zero length after a crash instead of being full of NULLs. >> We have had very few reports of zero length files or files with >> NULLs since this change was made (regardless of the file size >> update ordering changes). i.e. if we remove this code then the >> common case where NULL files occurred will return - only this >> time as zero length files. >> >> Cheers, >> >> Dave. >> >> > > From owner-xfs@oss.sgi.com Thu Jun 26 14:23:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 14:23:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44 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 m5QLNirc020757 for ; Thu, 26 Jun 2008 14:23:44 -0700 X-ASG-Debug-ID: 1214515485-6fb303870000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3BACCD609FC for ; Thu, 26 Jun 2008 14:24:45 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id d3Kh55xFl4IVyepp for ; Thu, 26 Jun 2008 14:24:45 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5QLOhf6031565; Thu, 26 Jun 2008 17:24:43 -0400 Received: from file.rdu.redhat.com (file.rdu.redhat.com [10.11.255.147]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5QLOhBO005546; Thu, 26 Jun 2008 17:24:43 -0400 Received: from neon.msp.redhat.com (neon.msp.redhat.com [10.15.80.10]) by file.rdu.redhat.com (8.13.1/8.13.1) with ESMTP id m5QLOgnG002376; Thu, 26 Jun 2008 17:24:42 -0400 Message-ID: <4864091A.9010206@sandeen.net> Date: Thu, 26 Jun 2008 16:24:42 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: DS CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: is the flush-on-close-after-truncate still needed? Subject: Re: is the flush-on-close-after-truncate still needed? References: <4859415B.3000009@sandeen.net> <200806181049.07812.dchinner@agami.com> <20080626210904.GA15920@bob.dscon.sk> <486407EB.70703@sandeen.net> In-Reply-To: <486407EB.70703@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1214515486 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16586 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Eric Sandeen wrote: > DS wrote: >> Hmm, but file overwrite in perl/php is slow, very slow. > > If you have control over your perl/php, perhaps you can change it to do > unlink/create/write instead of truncate/write? Or even: --- test.perl.orig 2008-06-26 16:22:48.163869293 -0500 +++ test.perl 2008-06-26 16:23:25.426869060 -0500 @@ -3,7 +3,7 @@ $time=time(); for ($i=1;$i<100;$i++) { -open (SUBOR,">$i.txt"); +open (SUBOR,"+<$i.txt"); print SUBOR "aaaaaaaaaaaaaaaaaaa\n"; close (SUBOR); print "WRITE $i. FILE\n"; which gives you RW access, but does not do the truncate. Or use sysopen. Or ... -Eric From owner-xfs@oss.sgi.com Thu Jun 26 16:55:33 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 16:55: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 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 m5QNtVGV003284 for ; Thu, 26 Jun 2008 16:55:33 -0700 X-ASG-Debug-ID: 1214524587-646d01ce0000-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 594FF28F305 for ; Thu, 26 Jun 2008 16:56:31 -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 ZX9q0H3l5y2NeIoE for ; Thu, 26 Jun 2008 16:56:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,711,1204464600"; d="scan'208";a="143903946" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 09:26:15 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC1IX-00045x-Ao; Fri, 27 Jun 2008 09:54:41 +1000 Date: Fri, 27 Jun 2008 09:54:41 +1000 From: Dave Chinner To: Niv Sardi Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: TAKE 976035 - streamline init/exit path Subject: Re: TAKE 976035 - streamline init/exit path Message-ID: <20080626235441.GU29319@disturbed> Mail-Followup-To: Niv Sardi , xfs@oss.sgi.com References: <20080625030057.973173A5D1@itchy> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080625030057.973173A5D1@itchy> 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: 1214524592 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.54435 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: 16587 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Wed, Jun 25, 2008 at 01:00:57PM +1000, Niv Sardi wrote: > streamline init/exit path > > Currently the xfs module init/exit code is a mess. It's farmed out > over a lot of function with very little error checking. This patch > makes sure we propagate all initialization failures properly and clean > up after them. Various runtime initializations are replaced with > compile-time initializations where possible to make this easier. The > exit path is similarly consolidated. > > There's now split out function to create/destroy the kmem zones and > alloc/free the trace buffers. I've also changed the ktrace > allocations to KM_MAYFAIL and handled errors resulting from that. > > And yes, we really should replace the XFS_*_TRACE ifdefs with a single > XFS_TRACE.. > > Signed-off-by: Christoph Hellwig > Signed-off-by: Niv Sardi Niv, can you now do another checkin that fixes the compilation error when CONFIG_PROCFS=N in fs/xfs/linux-2.6/xfs_stats.h that was reported on linux-next (i.e. fix the bug that led up to everyone discovering the busted commit)? BTW, your script is still busted - look at the wacky cc list on the take message. Please be a little more careful... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 17:58:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 17:58:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5R0wE9o007682 for ; Thu, 26 Jun 2008 17:58:16 -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 KAA08853; Fri, 27 Jun 2008 10:59:10 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 640EC58C4C29; Fri, 27 Jun 2008 10:59:10 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 982343 - fix up the _ACL_TYPE refs when CONFIG_XFS_POSIX_ACL not set. Message-Id: <20080627005910.640EC58C4C29@chook.melbourne.sgi.com> Date: Fri, 27 Jun 2008 10:59:10 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16588 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 Fix up problem when CONFIG_XFS_POSIX_ACL is not set and yet we still can use the _ACL_TYPE_* definitions in linux-2.6/xfs_xattr.c. The forthcoming generic acl code will also fix this problem. --Tim Date: Fri Jun 27 10:58:01 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: lachlan@sgi.com,hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31369a fs/xfs/xfs_acl.h - 1.38 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_acl.h.diff?r1=text&tr1=1.38&r2=text&tr2=1.37&f=h - Fix up problem when CONFIG_XFS_POSIX_ACL is not set and yet we still can use the _ACL_TYPE_* definitions in linux-2.6/xfs_xattr.c. Move the definitions further up before the #ifdef config stuff. From owner-xfs@oss.sgi.com Thu Jun 26 18:51:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 18:51:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5R1plCP012710 for ; Thu, 26 Jun 2008 18:51:48 -0700 X-ASG-Debug-ID: 1214531566-5620021c0000-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 BD0D91830C63 for ; Thu, 26 Jun 2008 18:52:46 -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 2VfFbosQyFLMytLW for ; Thu, 26 Jun 2008 18:52:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,712,1204464600"; d="scan'208";a="143990837" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 11:22:42 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC38j-0006b7-89; Fri, 27 Jun 2008 11:52:41 +1000 Date: Fri, 27 Jun 2008 11:52:41 +1000 From: Dave Chinner To: Daniel Walker Cc: xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080627015241.GX29319@disturbed> Mail-Followup-To: Daniel Walker , xfs@oss.sgi.com, matthew@wil.cx, linux-kernel@vger.kernel.org References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <1214512405.21035.110.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214512405.21035.110.camel@localhost.localdomain> 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: 1214531567 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.54442 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: 16589 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 Thu, Jun 26, 2008 at 01:33:25PM -0700, Daniel Walker wrote: > > On Thu, 2008-06-26 at 14:41 +1000, Dave Chinner wrote: > > XFS object flushing doesn't quite match existing completion semantics. It > > mixed exclusive access with completion. That is, we need to mark an object as > > being flushed before flushing it to disk, and then block any other attempt to > > flush it until the completion occurs. > > > > To do this we introduce: > > > > void init_completion_flush(struct completion *x) > > which initialises x->done = 1 > > > > void completion_flush_start(struct completion *x) > > which blocks if done == 0, otherwise decrements done to zero and > > allows the caller to continue. > > > > bool completion_flush_start_nowait(struct completion *x) > > returns a failure status if done == 0, otherwise decrements done > > to zero and returns a "flush started" status. This is provided > > to allow flushing to begin safely while holding object locks in > > inverted order. > > > > This replaces the use of semaphores for providing this exclusion > > and completion mechanism. > > I think there is some basis to make the changes that you have here. > Specifically this email and thread, > > http://lkml.org/lkml/2008/4/15/232 > > However, I don't like how your implementing this as specifically a > "flush" mechanism for XFS, and the count is limited to just 1 .. There > are several other places that do this kind of counting with semaphores, > and have counts above 1.. Agreed - but the extension has to start somewhere. So, do I simply add a "init_completion_count()" that passes a count value for the completion (i.e. replaces init_completion_flush())? > > + > > +static inline void completion_flush_start(struct completion *x) > > +{ > > + wait_for_completion(x); > > +} > > Above seems completely pointless.. I would just call > wait_for_completion(), and make the rest of the interface generic. Except then wait_for_completion_nowait() makes absolutely no sense ;) If i use wait_for_completion() for this, then perhaps the non-blocking version becomes "try_wait_for_completion()". Would this be acceptible? i.e. the extra functions in the completion API would be: void init_completion_count(struct completion *x, int count); int try_wait_for_completion(struct completion *x); int completion_in_progress(struct completion *x); Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 19:23:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 19:23:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5R2N8XZ015300 for ; Thu, 26 Jun 2008 19:23:09 -0700 X-ASG-Debug-ID: 1214533448-044d021f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.parisc-linux.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 23E5028FB32 for ; Thu, 26 Jun 2008 19:24:08 -0700 (PDT) Received: from mail.parisc-linux.org (palinux.external.hp.com [192.25.206.14]) by cuda.sgi.com with ESMTP id kJZzinrB6GcF9wlg for ; Thu, 26 Jun 2008 19:24:08 -0700 (PDT) Received: by mail.parisc-linux.org (Postfix, from userid 26919) id 18E5B494005; Thu, 26 Jun 2008 20:24:07 -0600 (MDT) Date: Thu, 26 Jun 2008 20:24:07 -0600 From: Matthew Wilcox To: Daniel Walker Cc: Dave Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080627022407.GB7703@parisc-linux.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <1214512405.21035.110.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214512405.21035.110.camel@localhost.localdomain> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: palinux.external.hp.com[192.25.206.14] X-Barracuda-Start-Time: 1214533450 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.54443 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: 16590 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: xfs On Thu, Jun 26, 2008 at 01:33:25PM -0700, Daniel Walker wrote: > I think there is some basis to make the changes that you have here. > Specifically this email and thread, > > http://lkml.org/lkml/2008/4/15/232 You've completely missed the point. The current semaphore code is _more_ efficient than the current completion code. I'm very comfortable having two APIs here, one for completion-like semantics and one for mutex-like semantics. Confusing them like this makes no sense at all. > However, I don't like how your implementing this as specifically a > "flush" mechanism for XFS, and the count is limited to just 1 .. There > are several other places that do this kind of counting with semaphores, > and have counts above 1.. Then leave them as semaphores. Really. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." From owner-xfs@oss.sgi.com Thu Jun 26 19:29:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 19:29:14 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5R2TCKB016027 for ; Thu, 26 Jun 2008 19:29:12 -0700 X-ASG-Debug-ID: 1214533812-4f79023a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.parisc-linux.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4095512CCA13 for ; Thu, 26 Jun 2008 19:30:12 -0700 (PDT) Received: from mail.parisc-linux.org (palinux.external.hp.com [192.25.206.14]) by cuda.sgi.com with ESMTP id 2QiiRcpZZdLhep2G for ; Thu, 26 Jun 2008 19:30:12 -0700 (PDT) Received: by mail.parisc-linux.org (Postfix, from userid 26919) id 53DB1494005; Thu, 26 Jun 2008 20:30:12 -0600 (MDT) Date: Thu, 26 Jun 2008 20:30:11 -0600 From: Matthew Wilcox To: Dave Chinner Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 2/6] Replace inode flush semaphore with a completion Subject: Re: [PATCH 2/6] Replace inode flush semaphore with a completion Message-ID: <20080627023011.GC7703@parisc-linux.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-3-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214455277-6387-3-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Barracuda-Connect: palinux.external.hp.com[192.25.206.14] X-Barracuda-Start-Time: 1214533813 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.54443 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: 16591 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: matthew@wil.cx Precedence: bulk X-list: xfs On Thu, Jun 26, 2008 at 02:41:13PM +1000, Dave Chinner wrote: > Use the new completion flush code to implement the inode > flush lock. Removes one of the final users of semaphores > in the XFS code base. Let's demonstrate converting this one to completions ... > --- a/fs/xfs/xfs_iget.c > +++ b/fs/xfs/xfs_iget.c > @@ -216,7 +216,7 @@ finish_inode: > mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); > init_waitqueue_head(&ip->i_ipin_wait); > atomic_set(&ip->i_pincount, 0); > - initnsema(&ip->i_flock, 1, "xfsfino"); > + init_completion_flush(&ip->i_flush); + init_completion(&ip->i_flush); + complete(&ip->i_flush); > > if (lock_flags) > xfs_ilock(ip, lock_flags); > @@ -776,25 +776,24 @@ xfs_isilocked( > #endif > > /* > - * The following three routines simply manage the i_flock > - * semaphore embedded in the inode. This semaphore synchronizes > - * processes attempting to flush the in-core inode back to disk. > + * Manage the i_flush queue embedded in the inode. This completion > + * queue synchronizes processes attempting to flush the in-core > + * inode back to disk. > */ > void > xfs_iflock(xfs_inode_t *ip) > { > - psema(&(ip->i_flock), PINOD|PLTWAIT); > + completion_flush_start(&ip->i_flush); + wait_for_completion(&ip->i_flush); > } > > int > xfs_iflock_nowait(xfs_inode_t *ip) > { > - return (cpsema(&(ip->i_flock))); > + return completion_flush_start_nowait(&ip->i_flush); This is where you need a new function ... + return nowait_for_completion(&ip->i_flush); Yes, we probably need a better name for the down_trylock() equivalent. > } > > void > xfs_ifunlock(xfs_inode_t *ip) > { > - ASSERT(issemalocked(&(ip->i_flock))); > - vsema(&(ip->i_flock)); > + complete(&ip->i_flush); Yep. > } > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c > index bedc661..81e2040 100644 > --- a/fs/xfs/xfs_inode.c > +++ b/fs/xfs/xfs_inode.c > @@ -2630,7 +2630,6 @@ xfs_idestroy( > xfs_idestroy_fork(ip, XFS_ATTR_FORK); > mrfree(&ip->i_lock); > mrfree(&ip->i_iolock); > - freesema(&ip->i_flock); > > #ifdef XFS_INODE_TRACE > ktrace_free(ip->i_trace); > @@ -3048,10 +3047,10 @@ cluster_corrupt_out: > /* > * xfs_iflush() will write a modified inode's changes out to the > * inode's on disk home. The caller must have the inode lock held > - * in at least shared mode and the inode flush semaphore must be > - * held as well. The inode lock will still be held upon return from > + * in at least shared mode and the inode flush completion must be > + * active as well. The inode lock will still be held upon return from > * the call and the caller is free to unlock it. > - * The inode flush lock will be unlocked when the inode reaches the disk. > + * The inode flush will be completed when the inode reaches the disk. > * The flags indicate how the inode's buffer should be written out. > */ > int > @@ -3070,7 +3069,7 @@ xfs_iflush( > XFS_STATS_INC(xs_iflush_count); > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); > - ASSERT(issemalocked(&(ip->i_flock))); > + ASSERT(completion_flush_inprogress(&ip->i_flush)); is_complete()? > ASSERT(ip->i_d.di_format != XFS_DINODE_FMT_BTREE || > ip->i_d.di_nextents > ip->i_df.if_ext_max); -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." From owner-xfs@oss.sgi.com Thu Jun 26 20:25:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 20:25:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=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 m5R3PgYL026291 for ; Thu, 26 Jun 2008 20:25:42 -0700 X-ASG-Debug-ID: 1214537201-3b8a01df0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gateway-1237.mvista.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FEC81834AA6 for ; Thu, 26 Jun 2008 20:26:41 -0700 (PDT) Received: from gateway-1237.mvista.com (gateway-1237.mvista.com [63.81.120.158]) by cuda.sgi.com with ESMTP id F3wjuuzidnLXNQoX for ; Thu, 26 Jun 2008 20:26:41 -0700 (PDT) Received: from [10.0.4.38] (dwalker.mvista.com [10.0.4.38]) by hermes.mvista.com (Postfix) with ESMTP id 1C5C618179; Thu, 26 Jun 2008 20:26:40 -0700 (PDT) X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements From: Daniel Walker To: Matthew Wilcox Cc: Dave Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20080627022407.GB7703@parisc-linux.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <1214512405.21035.110.camel@localhost.localdomain> <20080627022407.GB7703@parisc-linux.org> Content-Type: text/plain Date: Thu, 26 Jun 2008 20:26:39 -0700 Message-Id: <1214537199.21035.179.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: gateway-1237.mvista.com[63.81.120.158] X-Barracuda-Start-Time: 1214537202 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.54446 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: 16592 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dwalker@mvista.com Precedence: bulk X-list: xfs On Thu, 2008-06-26 at 20:24 -0600, Matthew Wilcox wrote: > > Then leave them as semaphores. Really. > Are you saying you want to keep semaphores? Cause I think that goes against the overall agenda that I've seen, which is complete semaphore removal .. If you have issues with the removal method then we could change that .. Daniel From owner-xfs@oss.sgi.com Thu Jun 26 21:12:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 21:13: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.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 m5R4Ctsj001274 for ; Thu, 26 Jun 2008 21:12:55 -0700 X-ASG-Debug-ID: 1214540035-3b9001310000-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 5C1C7D63698 for ; Thu, 26 Jun 2008 21:13:55 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id Ngs1AMMWazh0BcRK for ; Thu, 26 Jun 2008 21:13:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,713,1204464600"; d="scan'208";a="144183943" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 13:43:52 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC5LL-0001At-9V; Fri, 27 Jun 2008 14:13:51 +1000 Date: Fri, 27 Jun 2008 14:13:51 +1000 From: Dave Chinner To: Matthew Wilcox Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 2/6] Replace inode flush semaphore with a completion Subject: Re: [PATCH 2/6] Replace inode flush semaphore with a completion Message-ID: <20080627041351.GY29319@disturbed> Mail-Followup-To: Matthew Wilcox , xfs@oss.sgi.com, linux-kernel@vger.kernel.org References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-3-git-send-email-david@fromorbit.com> <20080627023011.GC7703@parisc-linux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080627023011.GC7703@parisc-linux.org> 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: 1214540036 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.54451 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: 16593 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 Thu, Jun 26, 2008 at 08:30:11PM -0600, Matthew Wilcox wrote: > On Thu, Jun 26, 2008 at 02:41:13PM +1000, Dave Chinner wrote: > > Use the new completion flush code to implement the inode > > flush lock. Removes one of the final users of semaphores > > in the XFS code base. > > Let's demonstrate converting this one to completions ... Great. I need all the help I can get. ;) > > --- a/fs/xfs/xfs_iget.c > > +++ b/fs/xfs/xfs_iget.c > > @@ -216,7 +216,7 @@ finish_inode: > > mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); > > init_waitqueue_head(&ip->i_ipin_wait); > > atomic_set(&ip->i_pincount, 0); > > - initnsema(&ip->i_flock, 1, "xfsfino"); > > + init_completion_flush(&ip->i_flush); > > + init_completion(&ip->i_flush); > + complete(&ip->i_flush); Ok, that would work. Need commenting, though. > > int > > xfs_iflock_nowait(xfs_inode_t *ip) > > { > > - return (cpsema(&(ip->i_flock))); > > + return completion_flush_start_nowait(&ip->i_flush); > > This is where you need a new function ... > > + return nowait_for_completion(&ip->i_flush); > > Yes, we probably need a better name for the down_trylock() equivalent. I suggested try_wait_for_completion() in a different email - it's a difficult on to say "a wait_for_completion() call that doesn't wait".... I think I'll stick with the try_.... version to match other "try" operations. > > int > > @@ -3070,7 +3069,7 @@ xfs_iflush( > > XFS_STATS_INC(xs_iflush_count); > > > > ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); > > - ASSERT(issemalocked(&(ip->i_flock))); > > + ASSERT(completion_flush_inprogress(&ip->i_flush)); > > is_complete()? That's a little to general for my liking - I note that there are already an existing is_complete() function in a driver. completion_done() perhaps? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 21:30:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 21:30:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5R4UKWa006024 for ; Thu, 26 Jun 2008 21:30:22 -0700 X-ASG-Debug-ID: 1214541080-3b9001ce0000-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 09CC6D63C8D for ; Thu, 26 Jun 2008 21:31:20 -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 ztvOWRE2zc55C5wL for ; Thu, 26 Jun 2008 21:31:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,713,1204464600"; d="scan'208";a="144217243" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 14:01:17 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC5c9-0001aZ-Fa; Fri, 27 Jun 2008 14:31:13 +1000 Date: Fri, 27 Jun 2008 14:31:13 +1000 From: Dave Chinner To: Oliver Pinter Cc: Christoph Hellwig , xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Eric Sandeen , Matthew Wilcox X-ASG-Orig-Subj: Re: [XFS] kernel panic on halt (2.6.26-rc7) Subject: Re: [XFS] kernel panic on halt (2.6.26-rc7) Message-ID: <20080627043113.GZ29319@disturbed> Mail-Followup-To: Oliver Pinter , Christoph Hellwig , xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Eric Sandeen , Matthew Wilcox References: <6101e8c40806260532j3bed1c7k9a60c41ea297549f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6101e8c40806260532j3bed1c7k9a60c41ea297549f@mail.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: 1214541082 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.54451 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: 16594 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 Thu, Jun 26, 2008 at 02:32:19PM +0200, Oliver Pinter wrote: > Hi Christoph, Dave, > > a similar problem came out the with 2.6.26, than the was in post early > with 2.6.25[1][2] > > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00807.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00808.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00809.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00810.jpg > http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00811.jpg http://lkml.org/lkml/2008/3/7/356 Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jun 26 21:41:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 21:41: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 relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5R4foNM007829 for ; Thu, 26 Jun 2008 21:41:50 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay1.corp.sgi.com (Postfix) with ESMTP id 350D18F811F; Thu, 26 Jun 2008 21:42:46 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5R4gfjm2208626; Fri, 27 Jun 2008 14:42:43 +1000 (AEST) From: Niv Sardi To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] Introduce xfs_trans_bmap_add_attrfork. References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <1214196150-5427-4-git-send-email-xaiki@sgi.com> <20080626092856.GA27069@infradead.org> Date: Fri, 27 Jun 2008 14:42:17 +1000 In-Reply-To: <20080626092856.GA27069@infradead.org> (Christoph Hellwig's message of "Thu, 26 Jun 2008 05:28:56 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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: 16595 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs --=-=-= Updated patch attached, Moved case where there is no transaction back into xfs_bmap_add_attrfork() and rely on caller to call xfs_trans_roll(), Christoph Hellwig writes: >> +xfs_bmap_add_attrfork( [...] > Care to add this below xfs_trans_bmap_add_attrfork? Also please > us struct xfs_inode instead of the typedef. Done, >> + if (tpp) { >> + ASSERT(*tpp); >> + tp = *tpp; >> + } else { [...] > > I think it would be much cleaner if all the transaction setup, joining > etc was done in xfs_bmap_add_attrfork, and xfs_trans_bmap_add_attrfork > just gets an always non-NULL xfs_trans pointer. That would mean > the common code would become just a helper, and > xfs_trans_bmap_add_attrfork would be a small wrapper including the > xfs_trans_roll. Alternatively the caller could always do the roll. I think I got it right, but error handeling is a bit weird this way, looks logically identical. --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0003-Introduce-xfs_trans_bmap_add_attrfork.patch From 8409ab9129b788ec9b1c2fb81131f70de0f4bf65 Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Thu, 22 May 2008 16:18:00 +1000 Subject: [PATCH] Introduce xfs_trans_bmap_add_attrfork. That takes a transaction and doesn't require everything to be locked anymore. This doesn't commit the transaction ! so direct callers, willing to use xfs_trans_roll() should do it themselves. Change xfs_bmap_add_attrfork to do the initialization/allocation of the transaction and commit arround xfs_trans_bmap_add_attrfork. Signed-off-by: Niv Sardi --- fs/xfs/xfs_bmap.c | 100 ++++++++++++++++++++++++++++++++++------------------ fs/xfs/xfs_bmap.h | 7 ++++ 2 files changed, 72 insertions(+), 35 deletions(-) diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c index 1c0a5a5..d4bd6e7 100644 --- a/fs/xfs/xfs_bmap.c +++ b/fs/xfs/xfs_bmap.c @@ -3946,16 +3946,16 @@ xfs_bunmap_trace( * Must not be in a transaction, ip must not be locked. */ int /* error code */ -xfs_bmap_add_attrfork( - xfs_inode_t *ip, /* incore inode pointer */ +xfs_trans_bmap_add_attrfork( + struct xfs_trans **tpp, /* transaction pointer */ + struct xfs_inode *ip, /* incore inode pointer */ int size, /* space new attribute needs */ int rsvd) /* xact may use reserved blks */ { xfs_fsblock_t firstblock; /* 1st block/ag allocated */ - xfs_bmap_free_t flist; /* freed extent records */ - xfs_mount_t *mp; /* mount structure */ - xfs_trans_t *tp; /* transaction pointer */ - int blks; /* space reservation */ + struct xfs_bmap_free flist; /* freed extent records */ + struct xfs_mount *mp; /* mount structure */ + struct xfs_trans *tp; /* transaction pointer */ int version = 1; /* superblock attr version */ int committed; /* xaction was committed */ int logflags; /* logging flags */ @@ -3967,24 +3967,8 @@ xfs_bmap_add_attrfork( mp = ip->i_mount; ASSERT(!XFS_NOT_DQATTACHED(mp, ip)); - tp = xfs_trans_alloc(mp, XFS_TRANS_ADDAFORK); - blks = XFS_ADDAFORK_SPACE_RES(mp); - if (rsvd) - tp->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(tp, blks, XFS_ADDAFORK_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT))) - goto error0; - xfs_ilock(ip, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? - XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : - XFS_QMOPT_RES_REGBLKS); - if (error) { - xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES); - return error; - } - if (XFS_IFORK_Q(ip)) - goto error1; + ASSERT(*tpp); + tp = *tpp; if (ip->i_d.di_aformat != XFS_DINODE_FMT_EXTENTS) { /* * For inodes coming from pre-6.2 filesystems. @@ -3992,10 +3976,7 @@ xfs_bmap_add_attrfork( ASSERT(ip->i_d.di_aformat == 0); ip->i_d.di_aformat = XFS_DINODE_FMT_EXTENTS; } - ASSERT(ip->i_d.di_anextents == 0); - VN_HOLD(XFS_ITOV(ip)); - xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); - xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); + switch (ip->i_d.di_format) { case XFS_DINODE_FMT_DEV: ip->i_d.di_forkoff = roundup(sizeof(xfs_dev_t), 8) >> 3; @@ -4015,7 +3996,7 @@ xfs_bmap_add_attrfork( default: ASSERT(0); error = XFS_ERROR(EINVAL); - goto error1; + goto error0; } ip->i_df.if_ext_max = XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t); @@ -4046,7 +4027,7 @@ xfs_bmap_add_attrfork( if (logflags) xfs_trans_log_inode(tp, ip, logflags); if (error) - goto error2; + goto error1; if (!XFS_SB_VERSION_HASATTR(&mp->m_sb) || (!XFS_SB_VERSION_HASATTR2(&mp->m_sb) && version == 2)) { __int64_t sbfields = 0; @@ -4066,14 +4047,63 @@ xfs_bmap_add_attrfork( } else spin_unlock(&mp->m_sb_lock); } - if ((error = xfs_bmap_finish(&tp, &flist, &committed))) - goto error2; - error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); + error = xfs_bmap_finish(tpp, &flist, &committed); + if (error) + goto error1; ASSERT(ip->i_df.if_ext_max == XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); - return error; -error2: + return 0; +error1: xfs_bmap_cancel(&flist); + ASSERT(ismrlocked(&ip->i_lock, MR_UPDATE)); +error0: + xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_ABORT); + ASSERT(ip->i_df.if_ext_max == + XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); + return error; +} + +int +xfs_bmap_add_attrfork( + struct xfs_inode *ip, /* incore inode pointer */ + int size, /* space new attribute needs */ + int rsvd) /* xact may use reserved blks */ +{ + struct xfs_trans *tp; /* transaction pointer */ + struct xfs_mount *mp; /* mount structure */ + int blks; /* space reservation */ + int error; /* error return value */ + + mp = ip->i_mount; + tp = xfs_trans_alloc(mp, XFS_TRANS_ADDAFORK); + blks = XFS_ADDAFORK_SPACE_RES(mp); + + if (rsvd) + tp->t_flags |= XFS_TRANS_RESERVE; + error = xfs_trans_reserve(tp, blks, XFS_ADDAFORK_LOG_RES(mp), 0, + XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT); + if (error) + goto error0; + + xfs_ilock(ip, XFS_ILOCK_EXCL); + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? + XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + XFS_QMOPT_RES_REGBLKS); + if (error) + goto error1; + + if (XFS_IFORK_Q(ip)) + goto error1; + + ASSERT(ip->i_d.di_anextents == 0); + VN_HOLD(XFS_ITOV(ip)); + xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); + + error = xfs_trans_bmap_add_attrfork(NULL, ip, size, rsvd); + if (error) + return error; + return xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); error1: ASSERT(ismrlocked(&ip->i_lock,MR_UPDATE)); xfs_iunlock(ip, XFS_ILOCK_EXCL); diff --git a/fs/xfs/xfs_bmap.h b/fs/xfs/xfs_bmap.h index 87224b7..7a21e41 100644 --- a/fs/xfs/xfs_bmap.h +++ b/fs/xfs/xfs_bmap.h @@ -166,6 +166,13 @@ xfs_bmap_add_attrfork( int size, /* space needed for new attribute */ int rsvd); /* flag for reserved block allocation */ +int /* error code */ +xfs_trans_bmap_add_attrfork( + struct xfs_trans **tpp, /* transaction */ + struct xfs_inode *ip, /* incore inode pointer */ + int size, /* space needed for new attribute */ + int rsvd); /* flag for reserved block allocation */ + /* * Add the extent to the list of extents to be free at transaction end. * The list is maintained sorted (by block number). -- 1.5.6 --=-=-= Thanks for this extensive review =) -- Niv Sardi --=-=-=-- From owner-xfs@oss.sgi.com Thu Jun 26 21:44:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 21:44:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5R4i7TN008337 for ; Thu, 26 Jun 2008 21:44:07 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 1B7E79089E; Thu, 26 Jun 2008 21:45:04 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5R4j1jm2275608; Fri, 27 Jun 2008 14:45:02 +1000 (AEST) From: Niv Sardi To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <20080626082827.GC23954@infradead.org> Date: Fri, 27 Jun 2008 14:44:37 +1000 In-Reply-To: <20080626082827.GC23954@infradead.org> (Christoph Hellwig's message of "Thu, 26 Jun 2008 04:28:27 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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: 16596 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs --=-=-= New patch attached, assignemnts out of conditionals, updated comments and types. -- Niv Sardi --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Move-attr-log-alloc-size-calculator-to-another-funct.patch From 1ca0cbca566944d8d26027d4b877be11b2ebaad0 Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Thu, 8 May 2008 16:34:32 +1000 Subject: [PATCH] Move attr log alloc size calculator to another function. We will need that to be able to calculate the size of log we need for a specific attr (for Create+EA). The local flag is needed so that we can fail if we run into ENOSPC when trying to alloc blocks. Signed-off-by: Niv Sardi --- fs/xfs/xfs_attr.c | 80 +++++++++++++++++++++++++++++++--------------------- fs/xfs/xfs_attr.h | 1 + 2 files changed, 49 insertions(+), 32 deletions(-) diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c index e58f321..ca3cabf 100644 --- a/fs/xfs/xfs_attr.c +++ b/fs/xfs/xfs_attr.c @@ -184,6 +184,46 @@ xfs_attr_get( return(error); } +/* + * Calculate how many blocks we need for the new attribute, + */ +int +xfs_attr_calc_size( + struct xfs_inode *ip, + int namelen, + int valuelen, + int *local) +{ + struct xfs_mount *mp = ip->i_mount; + int size; + int nblks; + + /* + * Determine space new attribute will use, and if it would be + * "local" or "remote" (note: local != inline). + */ + size = xfs_attr_leaf_newentsize(namelen, valuelen, + mp->m_sb.sb_blocksize, local); + + nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); + if (*local) { + if (size > (mp->m_sb.sb_blocksize >> 1)) { + /* Double split possible */ + nblks *= 2; + } + } else { + /* + * Out of line attribute, cannot double split, but + * make room for the attribute value itself. + */ + uint dblocks = XFS_B_TO_FSB(mp, valuelen); + nblks += dblocks; + nblks += XFS_NEXTENTADD_SPACE_RES(mp, dblocks, XFS_ATTR_FORK); + } + + return nblks; +} + int xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, char *value, int valuelen, int flags) @@ -192,10 +232,9 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, xfs_fsblock_t firstblock; xfs_bmap_free_t flist; int error, err2, committed; - int local, size; - uint nblks; xfs_mount_t *mp = dp->i_mount; int rsvd = (flags & ATTR_ROOT) != 0; + int local; /* * Attach the dquots to the inode. @@ -232,30 +271,8 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, args.addname = 1; args.oknoent = 1; - /* - * Determine space new attribute will use, and if it would be - * "local" or "remote" (note: local != inline). - */ - size = xfs_attr_leaf_newentsize(namelen, valuelen, - mp->m_sb.sb_blocksize, &local); - - nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); - if (local) { - if (size > (mp->m_sb.sb_blocksize >> 1)) { - /* Double split possible */ - nblks <<= 1; - } - } else { - uint dblocks = XFS_B_TO_FSB(mp, valuelen); - /* Out of line attribute, cannot double split, but make - * room for the attribute value itself. - */ - nblks += dblocks; - nblks += XFS_NEXTENTADD_SPACE_RES(mp, dblocks, XFS_ATTR_FORK); - } - /* Size is now blocks for attribute data */ - args.total = nblks; + args.total = xfs_attr_calc_size(dp, namelen, valuelen, &local); /* * Start our first transaction of the day. @@ -277,18 +294,17 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, if (rsvd) args.trans->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(args.trans, (uint) nblks, - XFS_ATTRSET_LOG_RES(mp, nblks), - 0, XFS_TRANS_PERM_LOG_RES, - XFS_ATTRSET_LOG_COUNT))) { + if ((error = xfs_trans_reserve(args.trans, args.total, + XFS_ATTRSET_LOG_RES(mp, args.total), 0, + XFS_TRANS_PERM_LOG_RES, XFS_ATTRSET_LOG_COUNT))) { xfs_trans_cancel(args.trans, 0); return(error); } xfs_ilock(dp, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, nblks, 0, - rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : - XFS_QMOPT_RES_REGBLKS); + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, args.total, 0, + rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + XFS_QMOPT_RES_REGBLKS); if (error) { xfs_iunlock(dp, XFS_ILOCK_EXCL); xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES); diff --git a/fs/xfs/xfs_attr.h b/fs/xfs/xfs_attr.h index 786eba3..ea457f5 100644 --- a/fs/xfs/xfs_attr.h +++ b/fs/xfs/xfs_attr.h @@ -158,6 +158,7 @@ struct xfs_da_args; /* * Overall external interface routines. */ +int xfs_attr_calc_size(struct xfs_inode *, int, int, int *); int xfs_attr_set_int(struct xfs_inode *, const char *, int, char *, int, int); int xfs_attr_remove_int(struct xfs_inode *, const char *, int, int); int xfs_attr_list_int(struct xfs_attr_list_context *); -- 1.5.6 --=-=-=-- From owner-xfs@oss.sgi.com Thu Jun 26 21:48:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 21:49:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5R4mxZv009115 for ; Thu, 26 Jun 2008 21:48:59 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id C6A139089E; Thu, 26 Jun 2008 21:49:59 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m5R4ntjm2279375; Fri, 27 Jun 2008 14:49:56 +1000 (AEST) From: Niv Sardi To: Christoph Hellwig Cc: xfs@oss.sgi.com Subject: Re: [PATCH] Move attr log alloc size calculator to another function. References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <20080626082438.GB23954@infradead.org> Date: Fri, 27 Jun 2008 14:49:31 +1000 In-Reply-To: <20080626082438.GB23954@infradead.org> (Christoph Hellwig's message of "Thu, 26 Jun 2008 04:24:38 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" 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: 16597 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs --=-=-= Attached updated patch. Christoph Hellwig writes: > On Mon, Jun 23, 2008 at 02:42:27PM +1000, Niv Sardi wrote: >> From: Niv Sardi >> >> We will need that to be able to calculate the size of log we need for >> a specific attr (for parent pointers in create). We need the local so >> that we can fail if we run into ENOSPC when trying to alloc blocks Updated Comments, structs instead of typdefs >> Signed-off-by: Niv Sardi >> --- >> fs/xfs/xfs_attr.c | 78 +++++++++++++++++++++++++++++++--------------------- >> fs/xfs/xfs_attr.h | 2 +- >> 2 files changed, 47 insertions(+), 33 deletions(-) >> >> diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c >> index e58f321..0d19e90 100644 >> --- a/fs/xfs/xfs_attr.c >> +++ b/fs/xfs/xfs_attr.c >> @@ -185,6 +185,43 @@ xfs_attr_get( >> } >> >> int >> +xfs_attr_calc_size( > > should be marked STATIC, The whole idea is to be able to use it in xfs_create(). --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=0001-Move-attr-log-alloc-size-calculator-to-another-funct.patch From 1ca0cbca566944d8d26027d4b877be11b2ebaad0 Mon Sep 17 00:00:00 2001 From: Niv Sardi Date: Thu, 8 May 2008 16:34:32 +1000 Subject: [PATCH] Move attr log alloc size calculator to another function. We will need that to be able to calculate the size of log we need for a specific attr (for Create+EA). The local flag is needed so that we can fail if we run into ENOSPC when trying to alloc blocks. Signed-off-by: Niv Sardi --- fs/xfs/xfs_attr.c | 80 +++++++++++++++++++++++++++++++--------------------- fs/xfs/xfs_attr.h | 1 + 2 files changed, 49 insertions(+), 32 deletions(-) diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c index e58f321..ca3cabf 100644 --- a/fs/xfs/xfs_attr.c +++ b/fs/xfs/xfs_attr.c @@ -184,6 +184,46 @@ xfs_attr_get( return(error); } +/* + * Calculate how many blocks we need for the new attribute, + */ +int +xfs_attr_calc_size( + struct xfs_inode *ip, + int namelen, + int valuelen, + int *local) +{ + struct xfs_mount *mp = ip->i_mount; + int size; + int nblks; + + /* + * Determine space new attribute will use, and if it would be + * "local" or "remote" (note: local != inline). + */ + size = xfs_attr_leaf_newentsize(namelen, valuelen, + mp->m_sb.sb_blocksize, local); + + nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); + if (*local) { + if (size > (mp->m_sb.sb_blocksize >> 1)) { + /* Double split possible */ + nblks *= 2; + } + } else { + /* + * Out of line attribute, cannot double split, but + * make room for the attribute value itself. + */ + uint dblocks = XFS_B_TO_FSB(mp, valuelen); + nblks += dblocks; + nblks += XFS_NEXTENTADD_SPACE_RES(mp, dblocks, XFS_ATTR_FORK); + } + + return nblks; +} + int xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, char *value, int valuelen, int flags) @@ -192,10 +232,9 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, xfs_fsblock_t firstblock; xfs_bmap_free_t flist; int error, err2, committed; - int local, size; - uint nblks; xfs_mount_t *mp = dp->i_mount; int rsvd = (flags & ATTR_ROOT) != 0; + int local; /* * Attach the dquots to the inode. @@ -232,30 +271,8 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, args.addname = 1; args.oknoent = 1; - /* - * Determine space new attribute will use, and if it would be - * "local" or "remote" (note: local != inline). - */ - size = xfs_attr_leaf_newentsize(namelen, valuelen, - mp->m_sb.sb_blocksize, &local); - - nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); - if (local) { - if (size > (mp->m_sb.sb_blocksize >> 1)) { - /* Double split possible */ - nblks <<= 1; - } - } else { - uint dblocks = XFS_B_TO_FSB(mp, valuelen); - /* Out of line attribute, cannot double split, but make - * room for the attribute value itself. - */ - nblks += dblocks; - nblks += XFS_NEXTENTADD_SPACE_RES(mp, dblocks, XFS_ATTR_FORK); - } - /* Size is now blocks for attribute data */ - args.total = nblks; + args.total = xfs_attr_calc_size(dp, namelen, valuelen, &local); /* * Start our first transaction of the day. @@ -277,18 +294,17 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, if (rsvd) args.trans->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(args.trans, (uint) nblks, - XFS_ATTRSET_LOG_RES(mp, nblks), - 0, XFS_TRANS_PERM_LOG_RES, - XFS_ATTRSET_LOG_COUNT))) { + if ((error = xfs_trans_reserve(args.trans, args.total, + XFS_ATTRSET_LOG_RES(mp, args.total), 0, + XFS_TRANS_PERM_LOG_RES, XFS_ATTRSET_LOG_COUNT))) { xfs_trans_cancel(args.trans, 0); return(error); } xfs_ilock(dp, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, nblks, 0, - rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : - XFS_QMOPT_RES_REGBLKS); + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, args.total, 0, + rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + XFS_QMOPT_RES_REGBLKS); if (error) { xfs_iunlock(dp, XFS_ILOCK_EXCL); xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES); diff --git a/fs/xfs/xfs_attr.h b/fs/xfs/xfs_attr.h index 786eba3..ea457f5 100644 --- a/fs/xfs/xfs_attr.h +++ b/fs/xfs/xfs_attr.h @@ -158,6 +158,7 @@ struct xfs_da_args; /* * Overall external interface routines. */ +int xfs_attr_calc_size(struct xfs_inode *, int, int, int *); int xfs_attr_set_int(struct xfs_inode *, const char *, int, char *, int, int); int xfs_attr_remove_int(struct xfs_inode *, const char *, int, int); int xfs_attr_list_int(struct xfs_attr_list_context *); -- 1.5.6 --=-=-= Cheers, -- Niv Sardi --=-=-=-- From owner-xfs@oss.sgi.com Thu Jun 26 21:50:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 21:51: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.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 m5R4opRL009576 for ; Thu, 26 Jun 2008 21:50:55 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id OAA13399; Fri, 27 Jun 2008 14:51:41 +1000 Message-ID: <486471DD.8010604@sgi.com> Date: Fri, 27 Jun 2008 14:51:41 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss , LinuxRaid , NeilBrown , jeremy@sgi.comwe Subject: Re: [PATCH] disable queue flag test in barrier check References: <486307EA.7080007@sandeen.net> <48635284.3060001@sgi.com> <486398B7.50306@sandeen.net> In-Reply-To: <486398B7.50306@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16598 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Timothy Shimmin wrote: > >> Also from memory, I believe Neil checked this removal into the SLES10sp1 tree >> and some sgi boxes started having slow downs >> (looking at Dave's email below - we were not wanting to tell them >> to use nobarrier but needed it to work by default - I forget now). > > But that's an admin issue. > > The way it is now, for example a home user of md raid1 (me!) can't run > barriers even if they wanted to. > I understand what you are saying. I agree. And I agreed when it went out last time. But as it has: -> gone in <- gone out -> gone in I want to make sure that everyone is happy for it to go back out again. (Cut the string of the yoyo :-) > Until there is a way to know if a write cache is non-volatile the only > safe option is to enable barriers when possible. > >> 6. >>> Date: Wed, 25 Jun 2008 08:57:24 +1000 >>> From: Dave Chinner >>> To: Eric Sandeen >>> Cc: LinuxRaid , xfs-oss >>> Subject: Re: md raid1 passes barriers, but xfs doesn't use them? >>> >>> Yeah, the problem was that last time this check was removed was >>> that a bunch of existing hardware had barriers enabled on them when >>> not necessary (e.g. had NVRAM) and they went 5x slower on MD raid1 >>> devices. Having to change the root drive config on a wide install >>> base was considered much more of support pain than leaving the >>> check there. I guess that was more of a distro upgrade issue than >>> a mainline problem, but that's the history. Hence I think we >>> should probably do whatever everyone else is doing here.... >>> >>> Cheers, >>> >>> Dave. >> So I guess my question is whether there are cases where we are >> going to be in trouble again. >> Jeremy, do you see some problems? > > FWIW, the problem *I* foresee is that some people are going to slow down > when using the defaults, yes, because barriers will start working again. > But I don't see any other safe way around it. > > Education would be in order, I suppose. :) > Well that's an ongoing problem. (Tell 'em to use laptop drives ;-)) --Tim From owner-xfs@oss.sgi.com Thu Jun 26 22:09:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 22:09: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.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m5R59lV6012248 for ; Thu, 26 Jun 2008 22:09:48 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA13726; Fri, 27 Jun 2008 15:10:45 +1000 Message-ID: <48647746.5010007@sgi.com> Date: Fri, 27 Jun 2008 15:14:46 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs-dev , xfs-oss Subject: [PATCH] Fix use after free when closing log/rt devices Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16599 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs The call to xfs_free_buftarg() will free the memory used by it's argument so we need to save the bdev to pass to xfs_blkdev_put() Lachlan --- fs/xfs/linux-2.6/xfs_super.c_1.432 2008-06-27 14:51:17.000000000 +1000 +++ fs/xfs/linux-2.6/xfs_super.c 2008-06-27 14:59:26.000000000 +1000 @@ -781,13 +781,17 @@ STATIC void xfs_close_devices( struct xfs_mount *mp) { + struct block_device *bdev; + if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { + bdev = mp->m_logdev_targp->bt_bdev; xfs_free_buftarg(mp->m_logdev_targp); - xfs_blkdev_put(mp->m_logdev_targp->bt_bdev); + xfs_blkdev_put(bdev); } if (mp->m_rtdev_targp) { + bdev = mp->m_rtdev_targp->bt_bdev; xfs_free_buftarg(mp->m_rtdev_targp); - xfs_blkdev_put(mp->m_rtdev_targp->bt_bdev); + xfs_blkdev_put(bdev); } xfs_free_buftarg(mp->m_ddev_targp); } From owner-xfs@oss.sgi.com Thu Jun 26 23:31:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 23:31:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5R6VJed026490 for ; Thu, 26 Jun 2008 23:31:20 -0700 X-ASG-Debug-ID: 1214548339-513003a90000-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 BD0D9D64581; Thu, 26 Jun 2008 23:32:19 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id E8n6P7WUhyldjEdA; Thu, 26 Jun 2008 23:32:19 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KC7VL-0008Pj-AD; Fri, 27 Jun 2008 06:32:19 +0000 Date: Fri, 27 Jun 2008 02:32:19 -0400 From: Christoph Hellwig To: Lachlan McIlroy Cc: xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Fix use after free when closing log/rt devices Subject: Re: [PATCH] Fix use after free when closing log/rt devices Message-ID: <20080627063219.GA25015@infradead.org> References: <48647746.5010007@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48647746.5010007@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214548340 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54459 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16600 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 03:14:46PM +1000, Lachlan McIlroy wrote: > The call to xfs_free_buftarg() will free the memory used by it's argument > so we need to save the bdev to pass to xfs_blkdev_put() > > Lachlan > > --- fs/xfs/linux-2.6/xfs_super.c_1.432 2008-06-27 14:51:17.000000000 +1000 > +++ fs/xfs/linux-2.6/xfs_super.c 2008-06-27 14:59:26.000000000 +1000 > @@ -781,13 +781,17 @@ STATIC void > xfs_close_devices( > struct xfs_mount *mp) > { > + struct block_device *bdev; > + > if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { > + bdev = mp->m_logdev_targp->bt_bdev; > xfs_free_buftarg(mp->m_logdev_targp); > - xfs_blkdev_put(mp->m_logdev_targp->bt_bdev); > + xfs_blkdev_put(bdev); > } > if (mp->m_rtdev_targp) { > + bdev = mp->m_rtdev_targp->bt_bdev; > xfs_free_buftarg(mp->m_rtdev_targp); > - xfs_blkdev_put(mp->m_rtdev_targp->bt_bdev); > + xfs_blkdev_put(bdev); > } Looks good, alhough two local variables inside the ifs might be cleaner: if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { struct block_device *logdev = mp->m_logdev_targp->bt_bdev; xfs_free_buftarg(mp->m_logdev_targp); xfs_blkdev_put(logdev); } ... From owner-xfs@oss.sgi.com Thu Jun 26 23:38:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 26 Jun 2008 23:38:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from 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 m5R6cndg028161 for ; Thu, 26 Jun 2008 23:38:51 -0700 Received: from [134.14.55.22] (dhcp22.melbourne.sgi.com [134.14.55.22]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA15688; Fri, 27 Jun 2008 16:39:39 +1000 Message-ID: <48648B2B.3080709@sgi.com> Date: Fri, 27 Jun 2008 16:39:39 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] Fix use after free when closing log/rt devices References: <48647746.5010007@sgi.com> <20080627063219.GA25015@infradead.org> In-Reply-To: <20080627063219.GA25015@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16601 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 27, 2008 at 03:14:46PM +1000, Lachlan McIlroy wrote: >> The call to xfs_free_buftarg() will free the memory used by it's argument >> so we need to save the bdev to pass to xfs_blkdev_put() >> >> Lachlan >> >> --- fs/xfs/linux-2.6/xfs_super.c_1.432 2008-06-27 14:51:17.000000000 +1000 >> +++ fs/xfs/linux-2.6/xfs_super.c 2008-06-27 14:59:26.000000000 +1000 >> @@ -781,13 +781,17 @@ STATIC void >> xfs_close_devices( >> struct xfs_mount *mp) >> { >> + struct block_device *bdev; >> + >> if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { >> + bdev = mp->m_logdev_targp->bt_bdev; >> xfs_free_buftarg(mp->m_logdev_targp); >> - xfs_blkdev_put(mp->m_logdev_targp->bt_bdev); >> + xfs_blkdev_put(bdev); >> } >> if (mp->m_rtdev_targp) { >> + bdev = mp->m_rtdev_targp->bt_bdev; >> xfs_free_buftarg(mp->m_rtdev_targp); >> - xfs_blkdev_put(mp->m_rtdev_targp->bt_bdev); >> + xfs_blkdev_put(bdev); >> } > > Looks good, alhough two local variables inside the ifs might be cleaner: > > if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { > struct block_device *logdev = mp->m_logdev_targp->bt_bdev; > > xfs_free_buftarg(mp->m_logdev_targp); > xfs_blkdev_put(logdev); > } > > ... do we have any QA tests that test external log? -- Mark From owner-xfs@oss.sgi.com Fri Jun 27 00:12:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 00:12: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.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 m5R7CDgD004260 for ; Fri, 27 Jun 2008 00:12:13 -0700 X-ASG-Debug-ID: 1214550793-5e5300640000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bob.dscon.sk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 92015D645FE for ; Fri, 27 Jun 2008 00:13:14 -0700 (PDT) Received: from bob.dscon.sk (bob.dscon.sk [88.86.113.10]) by cuda.sgi.com with ESMTP id goATRVc99NbTPR8h for ; Fri, 27 Jun 2008 00:13:14 -0700 (PDT) Received: by bob.dscon.sk (Postfix, from userid 1007) id A1494DC364; Fri, 27 Jun 2008 09:13:12 +0200 (CEST) Date: Fri, 27 Jun 2008 09:13:12 +0200 To: Eric Sandeen Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: is the flush-on-close-after-truncate still needed? Subject: Re: is the flush-on-close-after-truncate still needed? Message-ID: <20080627071312.GB15920@bob.dscon.sk> References: <4859415B.3000009@sandeen.net> <200806181049.07812.dchinner@agami.com> <20080626210904.GA15920@bob.dscon.sk> <486407EB.70703@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <486407EB.70703@sandeen.net> User-Agent: Mutt/1.5.13 (2006-08-11) From: xfs@bob.dscon.sk (DS) X-Barracuda-Connect: bob.dscon.sk[88.86.113.10] X-Barracuda-Start-Time: 1214550794 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0034 1.0000 -1.9990 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.00 X-Barracuda-Spam-Status: No, SCORE=-2.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54463 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: 16602 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xfs@bob.dscon.sk Precedence: bulk X-list: xfs Thanx for interest. There is no chance to change all scripts (too many customers and thousands and thousands perl/php skripts). I think it isn't right way compiling own perl/php libs with needed changes on open/fopen function. DS On Thu, Jun 26, 2008 at 04:19:39PM -0500, Eric Sandeen wrote: > DS wrote: > > Hmm, but file overwrite in perl/php is slow, very slow. > > If you have control over your perl/php, perhaps you can change it to do > unlink/create/write instead of truncate/write? > > -Eric > > > Which FS is best for me? > > XFS - perl/php overwrite problem > > EXT3 - 32000 subdirs limit > > REISER - no future > > JFS - ? > > > > DS > > > > On Wed, Jun 18, 2008 at 10:49:07AM -0700, Dave Chinner wrote: > >> On Wednesday 18 June 2008 10:09 am, Eric Sandeen wrote: > >>> After Lachlan's fix to separate on-disk and in-memory sizes, and only > >>> update on-disk when data is on-disk > >>> (http://www.linux.sgi.com/archives/xfs/2007-05/msg00020.html) is the > >>> XFS_ITRUNCATED flag / flush-on-close-after-truncate still needed? > >> Yes, because waiting 30s before writing back /etc/fstab after it > >> has been modified will result in lots of bug reports of /etc/fstab > >> being zero length after a crash instead of being full of NULLs. > >> We have had very few reports of zero length files or files with > >> NULLs since this change was made (regardless of the file size > >> update ordering changes). i.e. if we remove this code then the > >> common case where NULL files occurred will return - only this > >> time as zero length files. > >> > >> Cheers, > >> > >> Dave. > >> > >> > > > > > From owner-xfs@oss.sgi.com Fri Jun 27 00:27:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 00:27: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_53, 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 m5R7Rnu6013355 for ; Fri, 27 Jun 2008 00:27:49 -0700 X-ASG-Debug-ID: 1214551728-363100860000-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 C73C6183A224 for ; Fri, 27 Jun 2008 00:28:49 -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 2DYkcWVE13jeIZPv for ; Fri, 27 Jun 2008 00:28:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,714,1204464600"; d="scan'208";a="144374542" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 16:58:02 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC8NE-0007Rn-Sf; Fri, 27 Jun 2008 17:28:00 +1000 Date: Fri, 27 Jun 2008 17:28:00 +1000 From: Dave Chinner To: DS Cc: Eric Sandeen , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: is the flush-on-close-after-truncate still needed? Subject: Re: is the flush-on-close-after-truncate still needed? Message-ID: <20080627072800.GA29319@disturbed> Mail-Followup-To: DS , Eric Sandeen , xfs@oss.sgi.com References: <4859415B.3000009@sandeen.net> <200806181049.07812.dchinner@agami.com> <20080626210904.GA15920@bob.dscon.sk> <486407EB.70703@sandeen.net> <20080627071312.GB15920@bob.dscon.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080627071312.GB15920@bob.dscon.sk> 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: 1214551730 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0530 1.0000 -1.6813 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.68 X-Barracuda-Spam-Status: No, SCORE=-1.68 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.54464 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: 16603 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 09:13:12AM +0200, DS wrote: > Thanx for interest. > > There is no chance to change all scripts (too many customers and > thousands and thousands perl/php skripts). > > I think it isn't right way compiling own perl/php libs with needed changes on > open/fopen function. Overwriting files by truncating then first and then not fsync'ing the file is a sure way to lose data if the system crashes. That's an application bug, not a filesystem bug, because the filesystem is only doing what it is told to do. XFS is ensuring that lazy application writers are unlikely to lose data when they carelessly overwriting data. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Fri Jun 27 01:43:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 01:44: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.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52, J_CHICKENPOX_92,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 m5R8hlW8025161 for ; Fri, 27 Jun 2008 01:43:48 -0700 X-ASG-Debug-ID: 1214556286-3636021e0000-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 5AF2D148A05C for ; Fri, 27 Jun 2008 01:44:47 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id Kcxc9B4BHYeQ0hz3 for ; Fri, 27 Jun 2008 01:44:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,714,1204464600"; d="scan'208";a="144433133" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 18:14:45 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC9ZU-00016S-LI; Fri, 27 Jun 2008 18:44:44 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org, matthew@wil.cx, dwalker@mvista.com, Dave Chinner X-ASG-Orig-Subj: [PATCH 6/6] Remove the sema_t from XFS. Subject: [PATCH 6/6] Remove the sema_t from XFS. Date: Fri, 27 Jun 2008 18:44:44 +1000 Message-Id: <1214556284-4160-7-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214556284-4160-1-git-send-email-david@fromorbit.com> References: <1214556284-4160-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214556288 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.54468 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: 16608 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 Now that all users of the sema_t are gone from XFS we can finally kill it. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/sema.h | 52 ------------------------------------------ fs/xfs/linux-2.6/xfs_linux.h | 2 +- 2 files changed, 1 insertions(+), 53 deletions(-) delete mode 100644 fs/xfs/linux-2.6/sema.h diff --git a/fs/xfs/linux-2.6/sema.h b/fs/xfs/linux-2.6/sema.h deleted file mode 100644 index 3abe7e9..0000000 --- a/fs/xfs/linux-2.6/sema.h +++ /dev/null @@ -1,52 +0,0 @@ -/* - * Copyright (c) 2000-2002,2005 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ -#ifndef __XFS_SUPPORT_SEMA_H__ -#define __XFS_SUPPORT_SEMA_H__ - -#include -#include -#include -#include - -/* - * sema_t structure just maps to struct semaphore in Linux kernel. - */ - -typedef struct semaphore sema_t; - -#define initnsema(sp, val, name) sema_init(sp, val) -#define psema(sp, b) down(sp) -#define vsema(sp) up(sp) -#define freesema(sema) do { } while (0) - -static inline int issemalocked(sema_t *sp) -{ - return down_trylock(sp) || (up(sp), 0); -} - -/* - * Map cpsema (try to get the sema) to down_trylock. We need to switch - * the return values since cpsema returns 1 (acquired) 0 (failed) and - * down_trylock returns the reverse 0 (acquired) 1 (failed). - */ -static inline int cpsema(sema_t *sp) -{ - return down_trylock(sp) ? 0 : 1; -} - -#endif /* __XFS_SUPPORT_SEMA_H__ */ diff --git a/fs/xfs/linux-2.6/xfs_linux.h b/fs/xfs/linux-2.6/xfs_linux.h index 4d45d93..4fb838f 100644 --- a/fs/xfs/linux-2.6/xfs_linux.h +++ b/fs/xfs/linux-2.6/xfs_linux.h @@ -45,13 +45,13 @@ #include #include #include -#include #include #include #include #include +#include #include #include #include -- 1.5.5.4 From owner-xfs@oss.sgi.com Fri Jun 27 01:43:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 01:44:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,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 m5R8hn86025183 for ; Fri, 27 Jun 2008 01:43:49 -0700 X-ASG-Debug-ID: 1214556286-3636021e0001-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 241F6148A05C for ; Fri, 27 Jun 2008 01:44:48 -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 zRmLw8HoA10wtur0 for ; Fri, 27 Jun 2008 01:44:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,714,1204464600"; d="scan'208";a="144433136" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 18:14:45 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC9ZU-00016M-IT; Fri, 27 Jun 2008 18:44:44 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org, matthew@wil.cx, dwalker@mvista.com, Dave Chinner X-ASG-Orig-Subj: [PATCH 4/6] Replace inode flush semaphore with a completion Subject: [PATCH 4/6] Replace inode flush semaphore with a completion Date: Fri, 27 Jun 2008 18:44:42 +1000 Message-Id: <1214556284-4160-5-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214556284-4160-1-git-send-email-david@fromorbit.com> References: <1214556284-4160-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214556290 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.54468 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: 16607 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 Use the new completion flush code to implement the inode flush lock. Removes one of the final users of semaphores in the XFS code base. Version 2: o make flock functions static inlines o use new completion interfaces Signed-off-by: Dave Chinner --- fs/xfs/xfs_iget.c | 32 ++++++++------------------------ fs/xfs/xfs_inode.c | 11 +++++------ fs/xfs/xfs_inode.h | 25 +++++++++++++++++++++---- fs/xfs/xfs_inode_item.c | 11 +++++------ 4 files changed, 39 insertions(+), 40 deletions(-) diff --git a/fs/xfs/xfs_iget.c b/fs/xfs/xfs_iget.c index b07604b..eb4db18 100644 --- a/fs/xfs/xfs_iget.c +++ b/fs/xfs/xfs_iget.c @@ -216,7 +216,14 @@ finish_inode: mrlock_init(&ip->i_iolock, MRLOCK_BARRIER, "xfsio", ip->i_ino); init_waitqueue_head(&ip->i_ipin_wait); atomic_set(&ip->i_pincount, 0); - initnsema(&ip->i_flock, 1, "xfsfino"); + + /* + * Because we want to use a counting completion, complete + * the flush completion once to allow a single access to + * the flush completion without blocking. + */ + init_completion(&ip->i_flush); + complete(&ip->i_flush); if (lock_flags) xfs_ilock(ip, lock_flags); @@ -775,26 +782,3 @@ xfs_isilocked( } #endif -/* - * The following three routines simply manage the i_flock - * semaphore embedded in the inode. This semaphore synchronizes - * processes attempting to flush the in-core inode back to disk. - */ -void -xfs_iflock(xfs_inode_t *ip) -{ - psema(&(ip->i_flock), PINOD|PLTWAIT); -} - -int -xfs_iflock_nowait(xfs_inode_t *ip) -{ - return (cpsema(&(ip->i_flock))); -} - -void -xfs_ifunlock(xfs_inode_t *ip) -{ - ASSERT(issemalocked(&(ip->i_flock))); - vsema(&(ip->i_flock)); -} diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c index bedc661..1047bdc 100644 --- a/fs/xfs/xfs_inode.c +++ b/fs/xfs/xfs_inode.c @@ -2630,7 +2630,6 @@ xfs_idestroy( xfs_idestroy_fork(ip, XFS_ATTR_FORK); mrfree(&ip->i_lock); mrfree(&ip->i_iolock); - freesema(&ip->i_flock); #ifdef XFS_INODE_TRACE ktrace_free(ip->i_trace); @@ -3048,10 +3047,10 @@ cluster_corrupt_out: /* * xfs_iflush() will write a modified inode's changes out to the * inode's on disk home. The caller must have the inode lock held - * in at least shared mode and the inode flush semaphore must be - * held as well. The inode lock will still be held upon return from + * in at least shared mode and the inode flush completion must be + * active as well. The inode lock will still be held upon return from * the call and the caller is free to unlock it. - * The inode flush lock will be unlocked when the inode reaches the disk. + * The inode flush will be completed when the inode reaches the disk. * The flags indicate how the inode's buffer should be written out. */ int @@ -3070,7 +3069,7 @@ xfs_iflush( XFS_STATS_INC(xs_iflush_count); ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); - ASSERT(issemalocked(&(ip->i_flock))); + ASSERT(!completion_done(&ip->i_flush)); ASSERT(ip->i_d.di_format != XFS_DINODE_FMT_BTREE || ip->i_d.di_nextents > ip->i_df.if_ext_max); @@ -3233,7 +3232,7 @@ xfs_iflush_int( #endif ASSERT(xfs_isilocked(ip, XFS_ILOCK_EXCL|XFS_ILOCK_SHARED)); - ASSERT(issemalocked(&(ip->i_flock))); + ASSERT(!completion_done(&ip->i_flush)); ASSERT(ip->i_d.di_format != XFS_DINODE_FMT_BTREE || ip->i_d.di_nextents > ip->i_df.if_ext_max); diff --git a/fs/xfs/xfs_inode.h b/fs/xfs/xfs_inode.h index 17a04b6..086282d 100644 --- a/fs/xfs/xfs_inode.h +++ b/fs/xfs/xfs_inode.h @@ -223,7 +223,7 @@ typedef struct xfs_inode { struct xfs_inode_log_item *i_itemp; /* logging information */ mrlock_t i_lock; /* inode lock */ mrlock_t i_iolock; /* inode IO lock */ - sema_t i_flock; /* inode flush lock */ + struct completion i_flush; /* inode flush completion q */ atomic_t i_pincount; /* inode pin count */ wait_queue_head_t i_ipin_wait; /* inode pinning wait queue */ spinlock_t i_flags_lock; /* inode i_flags lock */ @@ -473,11 +473,8 @@ int xfs_ilock_nowait(xfs_inode_t *, uint); void xfs_iunlock(xfs_inode_t *, uint); void xfs_ilock_demote(xfs_inode_t *, uint); int xfs_isilocked(xfs_inode_t *, uint); -void xfs_iflock(xfs_inode_t *); -int xfs_iflock_nowait(xfs_inode_t *); uint xfs_ilock_map_shared(xfs_inode_t *); void xfs_iunlock_map_shared(xfs_inode_t *, uint); -void xfs_ifunlock(xfs_inode_t *); void xfs_ireclaim(xfs_inode_t *); int xfs_finish_reclaim(xfs_inode_t *, int, int); int xfs_finish_reclaim_all(struct xfs_mount *, int); @@ -570,6 +567,26 @@ extern struct kmem_zone *xfs_ifork_zone; extern struct kmem_zone *xfs_inode_zone; extern struct kmem_zone *xfs_ili_zone; +/* + * Manage the i_flush queue embedded in the inode. This completion + * queue synchronizes processes attempting to flush the in-core + * inode back to disk. + */ +static inline void xfs_iflock(xfs_inode_t *ip) +{ + wait_for_completion(&ip->i_flush); +} + +static inline int xfs_iflock_nowait(xfs_inode_t *ip) +{ + return try_wait_for_completion(&ip->i_flush); +} + +static inline void xfs_ifunlock(xfs_inode_t *ip) +{ + complete(&ip->i_flush); +} + #endif /* __KERNEL__ */ #endif /* __XFS_INODE_H__ */ diff --git a/fs/xfs/xfs_inode_item.c b/fs/xfs/xfs_inode_item.c index 0eee08a..97c7452 100644 --- a/fs/xfs/xfs_inode_item.c +++ b/fs/xfs/xfs_inode_item.c @@ -779,11 +779,10 @@ xfs_inode_item_pushbuf( ASSERT(iip->ili_push_owner == current_pid()); /* - * If flushlock isn't locked anymore, chances are that the - * inode flush completed and the inode was taken off the AIL. - * So, just get out. + * If a flush is not in progress anymore, chances are that the + * inode was taken off the AIL. So, just get out. */ - if (!issemalocked(&(ip->i_flock)) || + if (completion_done(&ip->i_flush) || ((iip->ili_item.li_flags & XFS_LI_IN_AIL) == 0)) { iip->ili_pushbuf_flag = 0; xfs_iunlock(ip, XFS_ILOCK_SHARED); @@ -805,7 +804,7 @@ xfs_inode_item_pushbuf( * If not, we can flush it async. */ dopush = ((iip->ili_item.li_flags & XFS_LI_IN_AIL) && - issemalocked(&(ip->i_flock))); + !completion_done(&ip->i_flush)); iip->ili_pushbuf_flag = 0; xfs_iunlock(ip, XFS_ILOCK_SHARED); xfs_buftrace("INODE ITEM PUSH", bp); @@ -858,7 +857,7 @@ xfs_inode_item_push( ip = iip->ili_inode; ASSERT(xfs_isilocked(ip, XFS_ILOCK_SHARED)); - ASSERT(issemalocked(&(ip->i_flock))); + ASSERT(!completion_done(&ip->i_flush)); /* * Since we were able to lock the inode's flush lock and * we found it on the AIL, the inode must be dirty. This -- 1.5.5.4 From owner-xfs@oss.sgi.com Fri Jun 27 01:43:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 01:43: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_57, 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 m5R8hpG4025213 for ; Fri, 27 Jun 2008 01:43:51 -0700 X-ASG-Debug-ID: 1214556286-3636021e0002-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 2E18B148A39B for ; Fri, 27 Jun 2008 01:44:50 -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 gFdsAalGWVcWNCpz for ; Fri, 27 Jun 2008 01:44:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,714,1204464600"; d="scan'208";a="144433142" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 18:14:45 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC9ZU-00016G-Ec; Fri, 27 Jun 2008 18:44:44 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org, matthew@wil.cx, dwalker@mvista.com, Dave Chinner X-ASG-Orig-Subj: [PATCH 1/6] Clean up stale references to semaphores Subject: [PATCH 1/6] Clean up stale references to semaphores Date: Fri, 27 Jun 2008 18:44:39 +1000 Message-Id: <1214556284-4160-2-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214556284-4160-1-git-send-email-david@fromorbit.com> References: <1214556284-4160-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214556292 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.54468 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: 16606 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 A lot of code has been converted away from semaphores, but there are still comments that reference semaphore behaviour. The log code is the worst offender. Update the comments to reflect what the code really does now. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_vnode.c | 6 ++-- fs/xfs/xfs_log.c | 67 ++++++++++++++++++++---------------------- fs/xfs/xfs_log_priv.h | 12 ++++---- 3 files changed, 41 insertions(+), 44 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_vnode.c b/fs/xfs/linux-2.6/xfs_vnode.c index bc7afe0..1881c79 100644 --- a/fs/xfs/linux-2.6/xfs_vnode.c +++ b/fs/xfs/linux-2.6/xfs_vnode.c @@ -33,7 +33,7 @@ /* - * Dedicated vnode inactive/reclaim sync semaphores. + * Dedicated vnode inactive/reclaim sync wait queues. * Prime number of hash buckets since address is used as the key. */ #define NVSYNC 37 @@ -84,8 +84,8 @@ vn_ioerror( /* * Revalidate the Linux inode from the XFS inode. - * Note: i_size _not_ updated; we must hold the inode - * semaphore when doing that - callers responsibility. + * Note: i_size _not_ updated; we must hold the i_mutex when doing + * that - callers responsibility. */ int vn_revalidate( diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index 2497de8..760d543 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -357,11 +357,11 @@ xfs_log_done(xfs_mount_t *mp, * Asynchronous forces are implemented by setting the WANT_SYNC * bit in the appropriate in-core log and then returning. * - * Synchronous forces are implemented with a semaphore. All callers - * to force a given lsn to disk will wait on a semaphore attached to the + * Synchronous forces are implemented with a signal variable. All callers + * to force a given lsn to disk will wait on a the sv attached to the * specific in-core log. When given in-core log finally completes its * write to disk, that thread will wake up all threads waiting on the - * semaphore. + * sv. */ int _xfs_log_force( @@ -707,7 +707,7 @@ xfs_log_unmount_write(xfs_mount_t *mp) if (!(iclog->ic_state == XLOG_STATE_ACTIVE || iclog->ic_state == XLOG_STATE_DIRTY)) { if (!XLOG_FORCED_SHUTDOWN(log)) { - sv_wait(&iclog->ic_forcesema, PMEM, + sv_wait(&iclog->ic_force_wait, PMEM, &log->l_icloglock, s); } else { spin_unlock(&log->l_icloglock); @@ -748,7 +748,7 @@ xfs_log_unmount_write(xfs_mount_t *mp) || iclog->ic_state == XLOG_STATE_DIRTY || iclog->ic_state == XLOG_STATE_IOERROR) ) { - sv_wait(&iclog->ic_forcesema, PMEM, + sv_wait(&iclog->ic_force_wait, PMEM, &log->l_icloglock, s); } else { spin_unlock(&log->l_icloglock); @@ -838,7 +838,7 @@ xfs_log_move_tail(xfs_mount_t *mp, break; tail_lsn = 0; free_bytes -= tic->t_unit_res; - sv_signal(&tic->t_sema); + sv_signal(&tic->t_wait); tic = tic->t_next; } while (tic != log->l_write_headq); } @@ -859,7 +859,7 @@ xfs_log_move_tail(xfs_mount_t *mp, break; tail_lsn = 0; free_bytes -= need_bytes; - sv_signal(&tic->t_sema); + sv_signal(&tic->t_wait); tic = tic->t_next; } while (tic != log->l_reserve_headq); } @@ -1285,8 +1285,8 @@ xlog_alloc_log(xfs_mount_t *mp, ASSERT(XFS_BUF_ISBUSY(iclog->ic_bp)); ASSERT(XFS_BUF_VALUSEMA(iclog->ic_bp) <= 0); - sv_init(&iclog->ic_forcesema, SV_DEFAULT, "iclog-force"); - sv_init(&iclog->ic_writesema, SV_DEFAULT, "iclog-write"); + sv_init(&iclog->ic_force_wait, SV_DEFAULT, "iclog-force"); + sv_init(&iclog->ic_write_wait, SV_DEFAULT, "iclog-write"); iclogp = &iclog->ic_next; } @@ -1565,8 +1565,8 @@ xlog_dealloc_log(xlog_t *log) iclog = log->l_iclog; for (i=0; il_iclog_bufs; i++) { - sv_destroy(&iclog->ic_forcesema); - sv_destroy(&iclog->ic_writesema); + sv_destroy(&iclog->ic_force_wait); + sv_destroy(&iclog->ic_write_wait); xfs_buf_free(iclog->ic_bp); #ifdef XFS_LOG_TRACE if (iclog->ic_trace != NULL) { @@ -1976,7 +1976,7 @@ xlog_write(xfs_mount_t * mp, /* Clean iclogs starting from the head. This ordering must be * maintained, so an iclog doesn't become ACTIVE beyond one that * is SYNCING. This is also required to maintain the notion that we use - * a counting semaphore to hold off would be writers to the log when every + * a ordered wait queue to hold off would be writers to the log when every * iclog is trying to sync to disk. * * State Change: DIRTY -> ACTIVE @@ -2240,7 +2240,7 @@ xlog_state_do_callback( xlog_state_clean_log(log); /* wake up threads waiting in xfs_log_force() */ - sv_broadcast(&iclog->ic_forcesema); + sv_broadcast(&iclog->ic_force_wait); iclog = iclog->ic_next; } while (first_iclog != iclog); @@ -2302,8 +2302,7 @@ xlog_state_do_callback( * the second completion goes through. * * Callbacks could take time, so they are done outside the scope of the - * global state machine log lock. Assume that the calls to cvsema won't - * take a long time. At least we know it won't sleep. + * global state machine log lock. */ STATIC void xlog_state_done_syncing( @@ -2339,7 +2338,7 @@ xlog_state_done_syncing( * iclog buffer, we wake them all, one will get to do the * I/O, the others get to wait for the result. */ - sv_broadcast(&iclog->ic_writesema); + sv_broadcast(&iclog->ic_write_wait); spin_unlock(&log->l_icloglock); xlog_state_do_callback(log, aborted, iclog); /* also cleans log */ } /* xlog_state_done_syncing */ @@ -2347,11 +2346,9 @@ xlog_state_done_syncing( /* * If the head of the in-core log ring is not (ACTIVE or DIRTY), then we must - * sleep. The flush semaphore is set to the number of in-core buffers and - * decremented around disk syncing. Therefore, if all buffers are syncing, - * this semaphore will cause new writes to sleep until a sync completes. - * Otherwise, this code just does p() followed by v(). This approximates - * a sleep/wakeup except we can't race. + * sleep. We wait on the flush queue on the head iclog as that should be + * the first iclog to complete flushing. Hence if all iclogs are syncing, + * we will wait here and all new writes will sleep until a sync completes. * * The in-core logs are used in a circular fashion. They are not used * out-of-order even when an iclog past the head is free. @@ -2501,7 +2498,7 @@ xlog_grant_log_space(xlog_t *log, goto error_return; XFS_STATS_INC(xs_sleep_logspace); - sv_wait(&tic->t_sema, PINOD|PLTWAIT, &log->l_grant_lock, s); + sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); /* * If we got an error, and the filesystem is shutting down, * we'll catch it down below. So just continue... @@ -2527,7 +2524,7 @@ redo: xlog_trace_loggrant(log, tic, "xlog_grant_log_space: sleep 2"); XFS_STATS_INC(xs_sleep_logspace); - sv_wait(&tic->t_sema, PINOD|PLTWAIT, &log->l_grant_lock, s); + sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); if (XLOG_FORCED_SHUTDOWN(log)) { spin_lock(&log->l_grant_lock); @@ -2626,7 +2623,7 @@ xlog_regrant_write_log_space(xlog_t *log, if (free_bytes < ntic->t_unit_res) break; free_bytes -= ntic->t_unit_res; - sv_signal(&ntic->t_sema); + sv_signal(&ntic->t_wait); ntic = ntic->t_next; } while (ntic != log->l_write_headq); @@ -2637,7 +2634,7 @@ xlog_regrant_write_log_space(xlog_t *log, xlog_trace_loggrant(log, tic, "xlog_regrant_write_log_space: sleep 1"); XFS_STATS_INC(xs_sleep_logspace); - sv_wait(&tic->t_sema, PINOD|PLTWAIT, + sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); /* If we're shutting down, this tic is already @@ -2666,7 +2663,7 @@ redo: if ((tic->t_flags & XLOG_TIC_IN_Q) == 0) xlog_ins_ticketq(&log->l_write_headq, tic); XFS_STATS_INC(xs_sleep_logspace); - sv_wait(&tic->t_sema, PINOD|PLTWAIT, &log->l_grant_lock, s); + sv_wait(&tic->t_wait, PINOD|PLTWAIT, &log->l_grant_lock, s); /* If we're shutting down, this tic is already off the queue */ if (XLOG_FORCED_SHUTDOWN(log)) { @@ -2909,7 +2906,7 @@ xlog_state_switch_iclogs(xlog_t *log, * 2. the current iclog is drity, and the previous iclog is in the * active or dirty state. * - * We may sleep (call psema) if: + * We may sleep if: * * 1. the current iclog is not in the active nor dirty state. * 2. the current iclog dirty, and the previous iclog is not in the @@ -3006,7 +3003,7 @@ maybe_sleep: return XFS_ERROR(EIO); } XFS_STATS_INC(xs_log_force_sleep); - sv_wait(&iclog->ic_forcesema, PINOD, &log->l_icloglock, s); + sv_wait(&iclog->ic_force_wait, PINOD, &log->l_icloglock, s); /* * No need to grab the log lock here since we're * only deciding whether or not to return EIO @@ -3089,7 +3086,7 @@ try_again: XLOG_STATE_SYNCING))) { ASSERT(!(iclog->ic_state & XLOG_STATE_IOERROR)); XFS_STATS_INC(xs_log_force_sleep); - sv_wait(&iclog->ic_prev->ic_writesema, PSWP, + sv_wait(&iclog->ic_prev->ic_write_wait, PSWP, &log->l_icloglock, s); *log_flushed = 1; already_slept = 1; @@ -3109,7 +3106,7 @@ try_again: !(iclog->ic_state & (XLOG_STATE_ACTIVE | XLOG_STATE_DIRTY))) { /* - * Don't wait on the forcesema if we know that we've + * Don't wait on completion if we know that we've * gotten a log write error. */ if (iclog->ic_state & XLOG_STATE_IOERROR) { @@ -3117,7 +3114,7 @@ try_again: return XFS_ERROR(EIO); } XFS_STATS_INC(xs_log_force_sleep); - sv_wait(&iclog->ic_forcesema, PSWP, &log->l_icloglock, s); + sv_wait(&iclog->ic_force_wait, PSWP, &log->l_icloglock, s); /* * No need to grab the log lock here since we're * only deciding whether or not to return EIO @@ -3173,7 +3170,7 @@ STATIC void xlog_ticket_put(xlog_t *log, xlog_ticket_t *ticket) { - sv_destroy(&ticket->t_sema); + sv_destroy(&ticket->t_wait); kmem_zone_free(xfs_log_ticket_zone, ticket); } /* xlog_ticket_put */ @@ -3263,7 +3260,7 @@ xlog_ticket_get(xlog_t *log, tic->t_trans_type = 0; if (xflags & XFS_LOG_PERM_RESERV) tic->t_flags |= XLOG_TIC_PERM_RESERV; - sv_init(&(tic->t_sema), SV_DEFAULT, "logtick"); + sv_init(&(tic->t_wait), SV_DEFAULT, "logtick"); xlog_tic_reset_res(tic); @@ -3550,14 +3547,14 @@ xfs_log_force_umount( */ if ((tic = log->l_reserve_headq)) { do { - sv_signal(&tic->t_sema); + sv_signal(&tic->t_wait); tic = tic->t_next; } while (tic != log->l_reserve_headq); } if ((tic = log->l_write_headq)) { do { - sv_signal(&tic->t_sema); + sv_signal(&tic->t_wait); tic = tic->t_next; } while (tic != log->l_write_headq); } diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h index 6245913..7dcf11e 100644 --- a/fs/xfs/xfs_log_priv.h +++ b/fs/xfs/xfs_log_priv.h @@ -241,7 +241,7 @@ typedef struct xlog_res { } xlog_res_t; typedef struct xlog_ticket { - sv_t t_sema; /* sleep on this semaphore : 20 */ + sv_t t_wait; /* ticket wait queue : 20 */ struct xlog_ticket *t_next; /* :4|8 */ struct xlog_ticket *t_prev; /* :4|8 */ xlog_tid_t t_tid; /* transaction identifier : 4 */ @@ -314,7 +314,7 @@ typedef struct xlog_rec_ext_header { * xlog_rec_header_t into the reserved space. * - ic_data follows, so a write to disk can start at the beginning of * the iclog. - * - ic_forcesema is used to implement synchronous forcing of the iclog to disk. + * - ic_forcewait is used to implement synchronous forcing of the iclog to disk. * - ic_next is the pointer to the next iclog in the ring. * - ic_bp is a pointer to the buffer used to write this incore log to disk. * - ic_log is a pointer back to the global log structure. @@ -339,8 +339,8 @@ typedef struct xlog_rec_ext_header { * and move everything else out to subsequent cachelines. */ typedef struct xlog_iclog_fields { - sv_t ic_forcesema; - sv_t ic_writesema; + sv_t ic_force_wait; + sv_t ic_write_wait; struct xlog_in_core *ic_next; struct xlog_in_core *ic_prev; struct xfs_buf *ic_bp; @@ -377,8 +377,8 @@ typedef struct xlog_in_core { /* * Defines to save our code from this glop. */ -#define ic_forcesema hic_fields.ic_forcesema -#define ic_writesema hic_fields.ic_writesema +#define ic_force_wait hic_fields.ic_force_wait +#define ic_write_wait hic_fields.ic_write_wait #define ic_next hic_fields.ic_next #define ic_prev hic_fields.ic_prev #define ic_bp hic_fields.ic_bp -- 1.5.5.4 From owner-xfs@oss.sgi.com Fri Jun 27 01:43:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 01:43: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5R8hn9m025189 for ; Fri, 27 Jun 2008 01:43:49 -0700 X-ASG-Debug-ID: 1214556287-5e4202820002-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 D0C44D64446 for ; Fri, 27 Jun 2008 01:44:50 -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 h5VxEHBaXBDbH7fc for ; Fri, 27 Jun 2008 01:44:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,714,1204464600"; d="scan'208";a="144433138" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 18:14:45 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC9ZU-00016I-Ft; Fri, 27 Jun 2008 18:44:44 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org, matthew@wil.cx, dwalker@mvista.com, Dave Chinner X-ASG-Orig-Subj: [PATCH 2/6] Replace the XFS buf iodone semaphore with a completion Subject: [PATCH 2/6] Replace the XFS buf iodone semaphore with a completion Date: Fri, 27 Jun 2008 18:44:40 +1000 Message-Id: <1214556284-4160-3-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214556284-4160-1-git-send-email-david@fromorbit.com> References: <1214556284-4160-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214556290 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.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54469 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 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: 16605 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 The xfs_buf_t b_iodonesema is really just a semaphore that wants to be a completion. Change it to a completion and remove the last user of the sema_t from XFS. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_buf.c | 6 +++--- fs/xfs/linux-2.6/xfs_buf.h | 4 ++-- fs/xfs/xfs_buf_item.c | 2 +- fs/xfs/xfs_rw.c | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c index 9cc8f02..9438c90 100644 --- a/fs/xfs/linux-2.6/xfs_buf.c +++ b/fs/xfs/linux-2.6/xfs_buf.c @@ -253,7 +253,7 @@ _xfs_buf_initialize( memset(bp, 0, sizeof(xfs_buf_t)); atomic_set(&bp->b_hold, 1); - init_MUTEX_LOCKED(&bp->b_iodonesema); + init_completion(&bp->b_iowait); INIT_LIST_HEAD(&bp->b_list); INIT_LIST_HEAD(&bp->b_hash_list); init_MUTEX_LOCKED(&bp->b_sema); /* held, no waiters */ @@ -1037,7 +1037,7 @@ xfs_buf_ioend( xfs_buf_iodone_work(&bp->b_iodone_work); } } else { - up(&bp->b_iodonesema); + complete(&bp->b_iowait); } } @@ -1275,7 +1275,7 @@ xfs_buf_iowait( XB_TRACE(bp, "iowait", 0); if (atomic_read(&bp->b_io_remaining)) blk_run_address_space(bp->b_target->bt_mapping); - down(&bp->b_iodonesema); + wait_for_completion(&bp->b_iowait); XB_TRACE(bp, "iowaited", (long)bp->b_error); return bp->b_error; } diff --git a/fs/xfs/linux-2.6/xfs_buf.h b/fs/xfs/linux-2.6/xfs_buf.h index 29d1d4a..fe01099 100644 --- a/fs/xfs/linux-2.6/xfs_buf.h +++ b/fs/xfs/linux-2.6/xfs_buf.h @@ -157,7 +157,7 @@ typedef struct xfs_buf { xfs_buf_iodone_t b_iodone; /* I/O completion function */ xfs_buf_relse_t b_relse; /* releasing function */ xfs_buf_bdstrat_t b_strat; /* pre-write function */ - struct semaphore b_iodonesema; /* Semaphore for I/O waiters */ + struct completion b_iowait; /* queue for I/O waiters */ void *b_fspriv; void *b_fspriv2; void *b_fspriv3; @@ -352,7 +352,7 @@ extern void xfs_buf_trace(xfs_buf_t *, char *, void *, void *); #define XFS_BUF_CPSEMA(bp) (xfs_buf_cond_lock(bp) == 0) #define XFS_BUF_VSEMA(bp) xfs_buf_unlock(bp) #define XFS_BUF_PSEMA(bp,x) xfs_buf_lock(bp) -#define XFS_BUF_V_IODONESEMA(bp) up(&bp->b_iodonesema); +#define XFS_BUF_FINISH_IOWAIT(bp) complete(&bp->b_iowait); #define XFS_BUF_SET_TARGET(bp, target) ((bp)->b_target = (target)) #define XFS_BUF_TARGET(bp) ((bp)->b_target) diff --git a/fs/xfs/xfs_buf_item.c b/fs/xfs/xfs_buf_item.c index d86ca2c..215c36d 100644 --- a/fs/xfs/xfs_buf_item.c +++ b/fs/xfs/xfs_buf_item.c @@ -1056,7 +1056,7 @@ xfs_buf_iodone_callbacks( anyway. */ XFS_BUF_SET_BRELSE_FUNC(bp,xfs_buf_error_relse); XFS_BUF_DONE(bp); - XFS_BUF_V_IODONESEMA(bp); + XFS_BUF_FINISH_IOWAIT(bp); } return; } diff --git a/fs/xfs/xfs_rw.c b/fs/xfs/xfs_rw.c index b0f31c0..3a82576 100644 --- a/fs/xfs/xfs_rw.c +++ b/fs/xfs/xfs_rw.c @@ -314,7 +314,7 @@ xfs_bioerror_relse( * ASYNC buffers. */ XFS_BUF_ERROR(bp, EIO); - XFS_BUF_V_IODONESEMA(bp); + XFS_BUF_FINISH_IOWAIT(bp); } else { xfs_buf_relse(bp); } -- 1.5.5.4 From owner-xfs@oss.sgi.com Fri Jun 27 01:43:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 01:44: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.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 m5R8hmUK025173 for ; Fri, 27 Jun 2008 01:43:48 -0700 X-ASG-Debug-ID: 1214556287-5e4202820001-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 0FB54D64442 for ; Fri, 27 Jun 2008 01:44:49 -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 EoUjvsfhuDVgsN5Y for ; Fri, 27 Jun 2008 01:44:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,714,1204464600"; d="scan'208";a="144433140" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 18:14:45 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC9ZU-00016E-D9; Fri, 27 Jun 2008 18:44:44 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org, matthew@wil.cx, dwalker@mvista.com X-ASG-Orig-Subj: [PATCH 0/6] Remove most users of semaphores from XFS V2. Subject: [PATCH 0/6] Remove most users of semaphores from XFS V2. Date: Fri, 27 Jun 2008 18:44:38 +1000 Message-Id: <1214556284-4160-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214556290 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.54469 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: 16609 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 This series aims to convert all but one of the remaining users of semaphores in the XFS code to use completions. Two of these semaphores don't quite match to completion semantics, but a small amount of additional code on top of the completions fixes this problem. I'm open to suggestions on different/better ways to implement this. The patch series does not touch the b_lock semaphore in the xfs_buf_t. At this point I'm not sure what we want to do with that semaphore so I've ignored that for now. Also, this lock uses linux primitives, not the xfs sema_t primitives so it doesn't need changing to allow me to remove the sema_t. Version 2: o remove "flush" based API and just add the minimum necessary extensions to allow counting completions to do what is needed by XFS. o change XFS patches to make use of new API o clean up the XFS APIs using the new completion API a little. From owner-xfs@oss.sgi.com Fri Jun 27 01:43:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 01:43: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 m5R8hl6I025165 for ; Fri, 27 Jun 2008 01:43:48 -0700 X-ASG-Debug-ID: 1214556287-5e4202820000-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 F037DD64442 for ; Fri, 27 Jun 2008 01:44:48 -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 ktfnpDsVrFJUP9Op for ; Fri, 27 Jun 2008 01:44:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,714,1204464600"; d="scan'208";a="144433134" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 18:14:45 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC9ZU-00016K-HB; Fri, 27 Jun 2008 18:44:44 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org, matthew@wil.cx, dwalker@mvista.com, Dave Chinner X-ASG-Orig-Subj: [PATCH 3/6] Extend completions to provide XFS object flush requirements Subject: [PATCH 3/6] Extend completions to provide XFS object flush requirements Date: Fri, 27 Jun 2008 18:44:41 +1000 Message-Id: <1214556284-4160-4-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214556284-4160-1-git-send-email-david@fromorbit.com> References: <1214556284-4160-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214556288 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.54469 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: 16604 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 XFS object flushing doesn't quite match existing completion semantics. It mixed exclusive access with completion. That is, we need to mark an object as being flushed before flushing it to disk, and then block any other attempt to flush it until the completion occurs. We do this but adding an extra count to the completion before we start using them. However, we still need to determine if there is a completion in progress, and allow no-blocking attempts fo completions to decrement the count. To do this we introduce: int try_wait_for_completion(struct completion *x) returns a failure status if done == 0, otherwise decrements done to zero and returns a "started" status. This is provided to allow counted completions to begin safely while holding object locks in inverted order. int completion_done(struct completion *x) returns 1 if there is no waiter, 0 if there is a waiter (i.e. a completion in progress). This replaces the use of semaphores for providing this exclusion and completion mechanism. Version 2: o remove "flush" based API and just add the minimum necessary extensions to allow counting completions to do what is needed by XFS. o docbook format comments Signed-off-by: Dave Chinner --- include/linux/completion.h | 45 ++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 45 insertions(+), 0 deletions(-) diff --git a/include/linux/completion.h b/include/linux/completion.h index d2961b6..57faa60 100644 --- a/include/linux/completion.h +++ b/include/linux/completion.h @@ -55,4 +55,49 @@ extern void complete_all(struct completion *); #define INIT_COMPLETION(x) ((x).done = 0) + +/** + * try_wait_for_completion - try to decrement a completion without blocking + * @x: completion structure + * + * Returns: 0 if a decrement cannot be done without blocking + * 1 if a decrement succeeded. + * + * If a completion is being used as a counting completion, + * attempt to decrement the counter without blocking. This + * enables us to avoid waiting if the resource the completion + * is protecting is not available. + */ +static inline bool try_wait_for_completion(struct completion *x) +{ + int ret = 1; + + spin_lock_irq(&x->wait.lock); + if (!x->done) + ret = 0; + else + x->done--; + spin_unlock_irq(&x->wait.lock); + return ret; +} + +/** + * completion_done - Test to see if a completion has any waiters + * @x: completion structure + * + * Returns: 0 if there are waiters (wait_for_completion() in progress) + * 1 if there are no waiters. + * + */ +static inline bool completion_done(struct completion *x) +{ + int ret = 1; + + spin_lock_irq(&x->wait.lock); + if (!x->done) + ret = 0; + spin_unlock_irq(&x->wait.lock); + return ret; +} + #endif -- 1.5.5.4 From owner-xfs@oss.sgi.com Fri Jun 27 01:43:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 01:44:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_48 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 m5R8hnjJ025181 for ; Fri, 27 Jun 2008 01:43:49 -0700 X-ASG-Debug-ID: 1214556288-0df303560000-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 42788290DCE for ; Fri, 27 Jun 2008 01:44:49 -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 cfQhgYo9AfvzJKxZ for ; Fri, 27 Jun 2008 01:44:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,714,1204464600"; d="scan'208";a="144433137" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 27 Jun 2008 18:14:45 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KC9ZU-00016P-Jn; Fri, 27 Jun 2008 18:44:44 +1000 From: Dave Chinner To: xfs@oss.sgi.com Cc: linux-kernel@vger.kernel.org, matthew@wil.cx, dwalker@mvista.com, Dave Chinner X-ASG-Orig-Subj: [PATCH 5/6] Replace dquot flush semaphore with a completion Subject: [PATCH 5/6] Replace dquot flush semaphore with a completion Date: Fri, 27 Jun 2008 18:44:43 +1000 Message-Id: <1214556284-4160-6-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.5.5.4 In-Reply-To: <1214556284-4160-1-git-send-email-david@fromorbit.com> References: <1214556284-4160-1-git-send-email-david@fromorbit.com> X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214556290 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.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54467 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 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: 16610 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 Use the new completion flush code to implement the dquot flush lock. Removes one of the final users of semaphores in the XFS code base. Version 2: o make xfs_qm_dqflock_nowait() a static inline and rename to match xfs_dqflock/xfs_dqfunlock operations. o use new completion interface. Signed-off-by: Dave Chinner --- fs/xfs/quota/xfs_dquot.c | 34 ++++++++++++---------------------- fs/xfs/quota/xfs_dquot.h | 29 ++++++++++++++++++----------- fs/xfs/quota/xfs_dquot_item.c | 8 ++++---- fs/xfs/quota/xfs_qm.c | 8 ++++---- 4 files changed, 38 insertions(+), 41 deletions(-) diff --git a/fs/xfs/quota/xfs_dquot.c b/fs/xfs/quota/xfs_dquot.c index fc9f3fb..4a2194d 100644 --- a/fs/xfs/quota/xfs_dquot.c +++ b/fs/xfs/quota/xfs_dquot.c @@ -101,9 +101,16 @@ xfs_qm_dqinit( if (brandnewdquot) { dqp->dq_flnext = dqp->dq_flprev = dqp; mutex_init(&dqp->q_qlock); - initnsema(&dqp->q_flock, 1, "fdq"); sv_init(&dqp->q_pinwait, SV_DEFAULT, "pdq"); + /* + * Because we want to use a counting completion, complete + * the flush completion once to allow a single access to + * the flush completion without blocking. + */ + init_completion(&dqp->q_flush); + complete(&dqp->q_flush); + #ifdef XFS_DQUOT_TRACE dqp->q_trace = ktrace_alloc(DQUOT_TRACE_SIZE, KM_SLEEP); xfs_dqtrace_entry(dqp, "DQINIT"); @@ -150,7 +157,6 @@ xfs_qm_dqdestroy( ASSERT(! XFS_DQ_IS_ON_FREELIST(dqp)); mutex_destroy(&dqp->q_qlock); - freesema(&dqp->q_flock); sv_destroy(&dqp->q_pinwait); #ifdef XFS_DQUOT_TRACE @@ -1211,7 +1217,7 @@ xfs_qm_dqflush( int error; ASSERT(XFS_DQ_IS_LOCKED(dqp)); - ASSERT(XFS_DQ_IS_FLUSH_LOCKED(dqp)); + ASSERT(!completion_done(&dqp->q_flush)); xfs_dqtrace_entry(dqp, "DQFLUSH"); /* @@ -1348,34 +1354,18 @@ xfs_qm_dqflush_done( xfs_dqfunlock(dqp); } - -int -xfs_qm_dqflock_nowait( - xfs_dquot_t *dqp) -{ - int locked; - - locked = cpsema(&((dqp)->q_flock)); - - /* XXX ifdef these out */ - if (locked) - (dqp)->dq_flags |= XFS_DQ_FLOCKED; - return (locked); -} - - int xfs_qm_dqlock_nowait( xfs_dquot_t *dqp) { - return (mutex_trylock(&((dqp)->q_qlock))); + return mutex_trylock(&dqp->q_qlock); } void xfs_dqlock( xfs_dquot_t *dqp) { - mutex_lock(&(dqp->q_qlock)); + mutex_lock(&dqp->q_qlock); } void @@ -1468,7 +1458,7 @@ xfs_qm_dqpurge( * if we're turning off quotas. Basically, we need this flush * lock, and are willing to block on it. */ - if (! xfs_qm_dqflock_nowait(dqp)) { + if (!xfs_dqflock_nowait(dqp)) { /* * Block on the flush lock after nudging dquot buffer, * if it is incore. diff --git a/fs/xfs/quota/xfs_dquot.h b/fs/xfs/quota/xfs_dquot.h index f7393bb..8958d0f 100644 --- a/fs/xfs/quota/xfs_dquot.h +++ b/fs/xfs/quota/xfs_dquot.h @@ -82,7 +82,7 @@ typedef struct xfs_dquot { xfs_qcnt_t q_res_icount; /* total inos allocd+reserved */ xfs_qcnt_t q_res_rtbcount;/* total realtime blks used+reserved */ mutex_t q_qlock; /* quota lock */ - sema_t q_flock; /* flush lock */ + struct completion q_flush; /* flush completion queue */ uint q_pincount; /* pin count for this dquot */ sv_t q_pinwait; /* sync var for pinning */ #ifdef XFS_DQUOT_TRACE @@ -113,17 +113,25 @@ XFS_DQ_IS_LOCKED(xfs_dquot_t *dqp) /* - * The following three routines simply manage the q_flock - * semaphore embedded in the dquot. This semaphore synchronizes - * processes attempting to flush the in-core dquot back to disk. + * Manage the q_flush completion queue embedded in the dquot. This completion + * queue synchronizes processes attempting to flush the in-core dquot back to + * disk. */ -#define xfs_dqflock(dqp) { psema(&((dqp)->q_flock), PINOD | PRECALC);\ - (dqp)->dq_flags |= XFS_DQ_FLOCKED; } -#define xfs_dqfunlock(dqp) { ASSERT(issemalocked(&((dqp)->q_flock))); \ - vsema(&((dqp)->q_flock)); \ - (dqp)->dq_flags &= ~(XFS_DQ_FLOCKED); } +static inline void xfs_dqflock(xfs_dquot_t *dqp) +{ + wait_for_completion(&dqp->q_flush); +} + +static inline int xfs_dqflock_nowait(xfs_dquot_t *dqp) +{ + return try_wait_for_completion(&dqp->q_flush); +} + +static inline void xfs_dqfunlock(xfs_dquot_t *dqp) +{ + complete(&dqp->q_flush); +} -#define XFS_DQ_IS_FLUSH_LOCKED(dqp) (issemalocked(&((dqp)->q_flock))) #define XFS_DQ_IS_ON_FREELIST(dqp) ((dqp)->dq_flnext != (dqp)) #define XFS_DQ_IS_DIRTY(dqp) ((dqp)->dq_flags & XFS_DQ_DIRTY) #define XFS_QM_ISUDQ(dqp) ((dqp)->dq_flags & XFS_DQ_USER) @@ -167,7 +175,6 @@ extern int xfs_qm_dqflush(xfs_dquot_t *, uint); extern int xfs_qm_dqpurge(xfs_dquot_t *); extern void xfs_qm_dqunpin_wait(xfs_dquot_t *); extern int xfs_qm_dqlock_nowait(xfs_dquot_t *); -extern int xfs_qm_dqflock_nowait(xfs_dquot_t *); extern void xfs_qm_dqflock_pushbuf_wait(xfs_dquot_t *dqp); extern void xfs_qm_adjust_dqtimers(xfs_mount_t *, xfs_disk_dquot_t *); diff --git a/fs/xfs/quota/xfs_dquot_item.c b/fs/xfs/quota/xfs_dquot_item.c index 08d2fc8..f028644 100644 --- a/fs/xfs/quota/xfs_dquot_item.c +++ b/fs/xfs/quota/xfs_dquot_item.c @@ -151,7 +151,7 @@ xfs_qm_dquot_logitem_push( dqp = logitem->qli_dquot; ASSERT(XFS_DQ_IS_LOCKED(dqp)); - ASSERT(XFS_DQ_IS_FLUSH_LOCKED(dqp)); + ASSERT(!completion_done(&dqp->q_flush)); /* * Since we were able to lock the dquot's flush lock and @@ -245,7 +245,7 @@ xfs_qm_dquot_logitem_pushbuf( * inode flush completed and the inode was taken off the AIL. * So, just get out. */ - if (!issemalocked(&(dqp->q_flock)) || + if (completion_done(&dqp->q_flush) || ((qip->qli_item.li_flags & XFS_LI_IN_AIL) == 0)) { qip->qli_pushbuf_flag = 0; xfs_dqunlock(dqp); @@ -258,7 +258,7 @@ xfs_qm_dquot_logitem_pushbuf( if (bp != NULL) { if (XFS_BUF_ISDELAYWRITE(bp)) { dopush = ((qip->qli_item.li_flags & XFS_LI_IN_AIL) && - issemalocked(&(dqp->q_flock))); + !completion_done(&dqp->q_flush)); qip->qli_pushbuf_flag = 0; xfs_dqunlock(dqp); @@ -317,7 +317,7 @@ xfs_qm_dquot_logitem_trylock( return (XFS_ITEM_LOCKED); retval = XFS_ITEM_SUCCESS; - if (! xfs_qm_dqflock_nowait(dqp)) { + if (!xfs_dqflock_nowait(dqp)) { /* * The dquot is already being flushed. It may have been * flushed delayed write, however, and we don't want to diff --git a/fs/xfs/quota/xfs_qm.c b/fs/xfs/quota/xfs_qm.c index 26370a3..234b6d1 100644 --- a/fs/xfs/quota/xfs_qm.c +++ b/fs/xfs/quota/xfs_qm.c @@ -484,7 +484,7 @@ again: xfs_dqtrace_entry(dqp, "FLUSHALL: DQDIRTY"); /* XXX a sentinel would be better */ recl = XFS_QI_MPLRECLAIMS(mp); - if (! xfs_qm_dqflock_nowait(dqp)) { + if (!xfs_dqflock_nowait(dqp)) { /* * If we can't grab the flush lock then check * to see if the dquot has been flushed delayed @@ -1062,7 +1062,7 @@ xfs_qm_sync( /* XXX a sentinel would be better */ recl = XFS_QI_MPLRECLAIMS(mp); - if (! xfs_qm_dqflock_nowait(dqp)) { + if (!xfs_dqflock_nowait(dqp)) { if (nowait) { xfs_dqunlock(dqp); continue; @@ -2079,7 +2079,7 @@ xfs_qm_shake_freelist( * Try to grab the flush lock. If this dquot is in the process of * getting flushed to disk, we don't want to reclaim it. */ - if (! xfs_qm_dqflock_nowait(dqp)) { + if (!xfs_dqflock_nowait(dqp)) { xfs_dqunlock(dqp); dqp = dqp->dq_flnext; continue; @@ -2257,7 +2257,7 @@ xfs_qm_dqreclaim_one(void) * Try to grab the flush lock. If this dquot is in the process of * getting flushed to disk, we don't want to reclaim it. */ - if (! xfs_qm_dqflock_nowait(dqp)) { + if (!xfs_dqflock_nowait(dqp)) { xfs_dqunlock(dqp); continue; } -- 1.5.5.4 From owner-xfs@oss.sgi.com Fri Jun 27 02:07:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 02:07:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,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 m5R97MoC031739 for ; Fri, 27 Jun 2008 02:07:23 -0700 X-ASG-Debug-ID: 1214557702-2be3034f0000-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 D3C93147E2E5; Fri, 27 Jun 2008 02:08:23 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 2IS5o4LEqjR7d2EF; Fri, 27 Jun 2008 02:08:23 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KC9wM-00084r-Pm; Fri, 27 Jun 2008 09:08:22 +0000 Date: Fri, 27 Jun 2008 05:08:22 -0400 From: Christoph Hellwig To: Mark Goodwin Cc: Christoph Hellwig , Lachlan McIlroy , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Fix use after free when closing log/rt devices Subject: Re: [PATCH] Fix use after free when closing log/rt devices Message-ID: <20080627090822.GA17374@infradead.org> References: <48647746.5010007@sgi.com> <20080627063219.GA25015@infradead.org> <48648B2B.3080709@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48648B2B.3080709@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214557703 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54470 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16611 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 04:39:39PM +1000, Mark Goodwin wrote: > do we have any QA tests that test external log? Most QA tests will use the external log if you set it up that way. But ithout slab poisoning this won't be noticed either. From owner-xfs@oss.sgi.com Fri Jun 27 02:14:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 02:14:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5R9Edrh001073 for ; Fri, 27 Jun 2008 02:14:39 -0700 X-ASG-Debug-ID: 1214558140-363802cb0000-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 24C89E4FCE2 for ; Fri, 27 Jun 2008 02:15:41 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id hmykF2AJlTfrxpWp for ; Fri, 27 Jun 2008 02:15:41 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KCA2w-0002KI-0N; Fri, 27 Jun 2008 09:15:10 +0000 Date: Fri, 27 Jun 2008 05:15:09 -0400 From: Christoph Hellwig To: Daniel Walker Cc: Matthew Wilcox , Dave Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Message-ID: <20080627091509.GA31148@infradead.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <1214512405.21035.110.camel@localhost.localdomain> <20080627022407.GB7703@parisc-linux.org> <1214537199.21035.179.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214537199.21035.179.camel@localhost.localdomain> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214558141 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.54470 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: 16612 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 Thu, Jun 26, 2008 at 08:26:39PM -0700, Daniel Walker wrote: > Are you saying you want to keep semaphores? Cause I think that goes > against the overall agenda that I've seen, Which overall agenda? From owner-xfs@oss.sgi.com Fri Jun 27 03:12:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 03:12:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 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 m5RACqK9009670 for ; Fri, 27 Jun 2008 03:12:54 -0700 X-ASG-Debug-ID: 1214561632-7e03005e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta02.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1DD3DD64D52 for ; Fri, 27 Jun 2008 03:13:52 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id jorJNRJ5bmlDfvln for ; Fri, 27 Jun 2008 03:13:52 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 060288E00BE for ; Fri, 27 Jun 2008 03:16:16 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta02.pmc-sierra.bc.ca (Postfix) with SMTP id E7B618E00B1 for ; Fri, 27 Jun 2008 03:16:15 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 03:14:24 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Fri, 27 Jun 2008 03:14:23 -0700 Message-ID: <4864BD5D.1050202@pmc-sierra.com> Date: Fri, 27 Jun 2008 15:43:49 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> In-Reply-To: <20080626070215.GI11558@disturbed> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2008 10:14:24.0205 (UTC) FILETIME=[92C587D0:01C8D83E] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1214561633 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0470 1.0000 -1.7187 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.72 X-Barracuda-Spam-Status: No, SCORE=-1.72 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.54475 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: 16613 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Dave Chinner wrote: > [please wrap your replies at 72 columns] > > On Wed, Jun 25, 2008 at 11:46:59PM -0700, Sagar Borikar wrote: > > > Yes, but all the same pattern of corruption, so it is likely > that it is one problem. > > > All I can suggest is working out a reproducable test case in your > development environment, attaching a debugger and start digging around > in memory when the problem is hit and try to find out exactly what > is corrupted. If you can't reproduce it or work out what is > occurring to trigger the problem, then we're not going to be able to > find the cause... > > Cheers, > > Dave. > Thanks Dave I did some experiments today with the corrupted filesystem. setup : NAS box contains one volume /share and 10 subdirectories. In first subdirectory sh1, I kept 512MB file. Through a script I continuously copy this file simultaneously from sh2 to sh10 subdirectories. The script looks like .... while [ 1 ] do cp $1 $2 done And when I check the process status using top, almost all the cp processes are in uninterruptible sleep state continuously. Ran xfs_repair with -n option on filesystem mounted on JBOD Here is the output : Fri Jun 27 02:13:01 2008 Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 0 - agno = 1 bad nblocks 8788 for inode 33554562, would reset to 15461 bad nextents 18 for inode 33554562, would reset to 32 - agno = 2 entry "iozone_68.tst" in shortform directory 67108993 references free inode 67108995 would have junked entry "iozone_68.tst" in directory inode 67108993 data fork in ino 67108995 claims dup extent, off - 252, start - 14711445, cnt 576 bad data fork in inode 67108995 would have cleared inode 67108995 - agno = 3 entry "iozone_68.tst" in shortform directory 100663425 references free inode 100663427 would have junked entry "iozone_68.tst" in directory inode 100663425 inode 100663427 - bad extent starting block number 906006917242880, offset 2533274882670609 bad data fork in inode 100663427 would have cleared inode 100663427 - agno = 4 bad nblocks 10214 for inode 134217859, would reset to 16761 bad nextents 22 for inode 134217859, would reset to 34 - agno = 5 bad nblocks 23581 for inode 167772290, would reset to 27557 bad nextents 39 for inode 167772290, would reset to 45 - agno = 6 bad nblocks 14527 for inode 201326722, would reset to 15697 bad nextents 31 for inode 201326722, would reset to 34 bad nblocks 12633 for inode 201326723, would reset to 16647 bad nextents 23 for inode 201326723, would reset to 35 - agno = 7 bad nblocks 26638 for inode 234881154, would reset to 27557 bad nextents 53 for inode 234881154, would reset to 54 bad nblocks 85653 for inode 234881155, would reset to 85664 bad nextents 310 for inode 234881155, would reset to 311 - agno = 8 bad nblocks 23241 for inode 268640387, would reset to 27565 bad nextents 32 for inode 268640387, would reset to 42 bad nblocks 81766 for inode 268640388, would reset to 86012 bad nextents 332 for inode 268640388, would reset to 344 - agno = 9 entry "iozone_68.tst" in shortform directory 301990016 references free inode 301990019 would have junked entry "iozone_68.tst" in directory inode 301990016 data fork in ino 301990019 claims dup extent, off - 26402, start - 19129002, cnt 450 bad data fork in inode 301990019 would have cleared inode 301990019 bad nblocks 70282 for inode 301990020, would reset to 71793 bad nextents 281 for inode 301990020, would reset to 294 - agno = 10 entry "iozone_68.tst" in shortform directory 335544448 references free inode 335544451 would have junked entry "iozone_68.tst" in directory inode 335544448 bad nblocks 11261 for inode 335544451, would reset to 19853 bad nextents 24 for inode 335544451, would reset to 41 imap claims in-use inode 335544451 is free, correcting imap bad nblocks 119952 for inode 335544452, would reset to 121178 bad nextents 301 for inode 335544452, would reset to 312 - agno = 11 bad nblocks 24361 for inode 369098883, would reset to 29553 bad nextents 51 for inode 369098883, would reset to 57 bad nblocks 3173 for inode 369098884, would reset to 5851 bad nextents 10 for inode 369098884, would reset to 18 - agno = 12 entry "iozone_68.tst" in shortform directory 402653313 references free inode 402653318 would have junked entry "iozone_68.tst" in directory inode 402653313 bad nblocks 16348 for inode 402653317, would reset to 21485 bad nextents 28 for inode 402653317, would reset to 37 data fork in ino 402653318 claims dup extent, off - 124142, start - 29379669, cnt 2 bad data fork in inode 402653318 would have cleared inode 402653318 - agno = 13 bad nblocks 18374 for inode 436207747, would reset to 19991 bad nextents 43 for inode 436207747, would reset to 47 bad nblocks 38390 for inode 436207748, would reset to 38914 bad nextents 300 for inode 436207748, would reset to 304 - agno = 14 bad nblocks 20267 for inode 469762178, would reset to 23089 bad nextents 41 for inode 469762178, would reset to 45 - agno = 15 entry "iozone_68.tst" in shortform directory 503316608 references free inode 503316609 would have junked entry "iozone_68.tst" in directory inode 503316608 imap claims in-use inode 503316609 is free, correcting imap libxfs_bcache: 0x100020b0 Max supported entries = 524288 Max utilized entries = 562 Active entries = 562 Hash table size = 65536 Hits = 1009 Misses = 564 Hit ratio = 64.00 Hash buckets with 0 entries 65116 ( 0%) Hash buckets with 1 entries 391 ( 69%) Hash buckets with 2 entries 20 ( 7%) Hash buckets with 3 entries 1 ( 0%) Hash buckets with 15 entries 1 ( 2%) Hash buckets with 16 entries 6 ( 17%) Hash buckets with 17 entries 1 ( 3%) Fri Jun 27 02:13:08 2008 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem starting at / ... - agno = 0 - agno = 1 - agno = 2 entry "iozone_68.tst" in shortform directory inode 67108993 points to free inode 67108995 would junk entry "iozone_68.tst" - agno = 3 entry "iozone_68.tst" in shortform directory inode 100663425 points to free inode 100663427 would junk entry "iozone_68.tst" - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 entry "iozone_68.tst" in shortform directory inode 301990016 points to free inode 301990019 would junk entry "iozone_68.tst" - agno = 10 - agno = 11 - agno = 12 entry "iozone_68.tst" in shortform directory inode 402653313 points to free inode 402653318 would junk entry "iozone_68.tst" - agno = 13 - agno = 14 - agno = 15 - traversal finished ... - traversing all unattached subtrees ... - traversals finished ... - moving disconnected inodes to lost+found ... libxfs_icache: 0x10002050 Max supported entries = 524288 Max utilized entries = 42 Active entries = 42 Hash table size = 65536 Hits = 0 Misses = 42 Hit ratio = 0.00 Hash buckets with 0 entries 65524 ( 0%) Hash buckets with 1 entries 9 ( 21%) Hash buckets with 6 entries 1 ( 14%) Hash buckets with 12 entries 1 ( 28%) Hash buckets with 15 entries 1 ( 35%) libxfs_bcache: 0x100020b0 Max supported entries = 524288 Max utilized entries = 562 Active entries = 17 Hash table size = 65536 Hits = 1035 Misses = 581 Hit ratio = 64.00 Hash buckets with 0 entries 65533 ( 0%) Hash buckets with 1 entries 2 ( 11%) Hash buckets with 15 entries 1 ( 88%) Fri Jun 27 02:13:10 2008 Phase 7 - verify link counts... - agno = 0 - agno = 1 - agno = 2 - agno = 3 - agno = 4 - agno = 5 - agno = 6 - agno = 7 - agno = 8 - agno = 9 - agno = 10 - agno = 11 - agno = 12 - agno = 13 - agno = 14 - agno = 15 libxfs_icache: 0x10002050 Max supported entries = 524288 Max utilized entries = 42 Active entries = 42 Hash table size = 65536 Hits = 0 Misses = 42 Hit ratio = 0.00 Hash buckets with 0 entries 65524 ( 0%) Hash buckets with 1 entries 9 ( 21%) Hash buckets with 6 entries 1 ( 14%) Hash buckets with 12 entries 1 ( 28%) Hash buckets with 15 entries 1 ( 35%) libxfs_bcache: 0x100020b0 Max supported entries = 524288 Max utilized entries = 562 Active entries = 16 Hash table size = 65536 Hits = 1051 Misses = 597 Hit ratio = 63.00 Hash buckets with 0 entries 65534 ( 0%) Hash buckets with 1 entries 1 ( 6%) Hash buckets with 15 entries 1 ( 93%) Fri Jun 27 02:13:17 2008 No modify flag set, skipping filesystem flush and exiting. So there are several bad blocks and extents present in all ag, which are causing the problem. top output reveals that all cp are in D state PID USER STATUS RSS PPID %CPU %MEM COMMAND 7455 root R 984 1892 7.4 0.7 top 6100 root D 524 1973 2.9 0.4 cp 6799 root R 524 1983 2.9 0.4 cp 6796 root D 524 2125 2.9 0.4 cp 6074 root D 524 2109 1.4 0.4 cp 6097 root D 524 1979 1.4 0.4 cp 6076 root D 524 1975 1.4 0.4 cp 6738 root D 524 2123 1.4 0.4 cp 6759 root D 524 2115 1.4 0.4 cp 7035 root D 524 1977 1.4 0.4 cp 7440 root D 520 1985 1.4 0.4 cp 73 root SW< 0 6 1.4 0.0 xfsdatad/0 67 root SW 0 6 1.4 0.0 pdflush ... .. This means that they are waiting for an IO and sleeping in system call but not able to come out as several inodes are corrupted. And hence the script never gets completed. Thanks Sagar From owner-xfs@oss.sgi.com Fri Jun 27 03:24:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 03:24:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 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 m5RAO8av012124 for ; Fri, 27 Jun 2008 03:24:08 -0700 X-ASG-Debug-ID: 1214562308-57ec033c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta01.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6138212CD4F2 for ; Fri, 27 Jun 2008 03:25:09 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id a9dCk7c9zOLozzYv for ; Fri, 27 Jun 2008 03:25:09 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id D82C318900C7 for ; Fri, 27 Jun 2008 03:27:58 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta01.pmc-sierra.bc.ca (Postfix) with SMTP id C432D18900C6 for ; Fri, 27 Jun 2008 03:27:58 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Fri, 27 Jun 2008 03:25:40 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Fri, 27 Jun 2008 03:25:39 -0700 Message-ID: <4864C001.2010308@pmc-sierra.com> Date: Fri, 27 Jun 2008 15:55:05 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> In-Reply-To: <4864BD5D.1050202@pmc-sierra.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jun 2008 10:25:40.0029 (UTC) FILETIME=[259816D0:01C8D840] X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1214562309 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.54475 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: 16614 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Dave, I also got continuous exceptions XFS internal error XFS_WANT_CORRUPTED_RETURN at line 296 of file fs/xfs/xfs_alloc.c. Caller 0x802962c0 Call Trace: [<80109888>] dump_stack+0x18/0x44 [<802c3550>] xfs_error_report+0x58/0x64 [<802965a0>] xfs_alloc_fixup_trees+0x39c/0x3dc [<80297850>] xfs_alloc_ag_vextent_size+0x3ec/0x4f4 [<80296708>] xfs_alloc_ag_vextent+0x5c/0x15c [<8029910c>] xfs_alloc_vextent+0x430/0x604 [<802a9420>] xfs_bmap_btalloc+0x6b0/0x950 [<802a9700>] xfs_bmap_alloc+0x40/0x4c [<802acc80>] xfs_bmapi+0x8d8/0x13e4 [<802d4230>] xfs_iomap_write_allocate+0x340/0x5d8 [<802d2b18>] xfs_iomap+0x408/0x4dc [<802fe8bc>] xfs_bmap+0x30/0x3c [<802f3cac>] xfs_map_blocks+0x50/0x84 [<802f50dc>] xfs_page_state_convert+0x3f4/0x840 [<802f560c>] xfs_vm_writepage+0xe4/0x140 [<80198758>] mpage_writepages+0x24c/0x45c [<802f5698>] xfs_vm_writepages+0x30/0x3c [<801507b4>] do_writepages+0x44/0x84 [<80196628>] __sync_single_inode+0x68/0x234 [<80196980>] __writeback_single_inode+0x18c/0x1ac [<80196ba8>] sync_sb_inodes+0x208/0x2f0 [<80196d14>] writeback_inodes+0x84/0xd0 [<80150160>] balance_dirty_pages+0xd8/0x1d4 [<801502a8>] balance_dirty_pages_ratelimited_nr+0x4c/0x58 [<8014c0a4>] generic_file_buffered_write+0x534/0x650 [<802fe4c8>] xfs_write+0x768/0xaac [<802f8c30>] xfs_file_aio_write+0x88/0x94 [<8016d8d4>] do_sync_write+0xcc/0x124 [<8016d9e4>] vfs_write+0xb8/0x1a0 [<8016dbb8>] sys_write+0x54/0x98 [<8010c180>] stack_done+0x20/0x3c So memory was also not available for pdflush threads to flush the data back to disks. But when I checked memory stats, around 260KB of buffers were available with sufficient free memory We are running 8k kernel stack with MIPS architecture. Also pdflush threads were stalled in uninterruptible state. Do you see any issues in the available memory as well? Thanks Sagar Sagar Borikar wrote: > > Dave Chinner wrote: >> [please wrap your replies at 72 columns] >> >> On Wed, Jun 25, 2008 at 11:46:59PM -0700, Sagar Borikar wrote: >> >> Yes, but all the same pattern of corruption, so it is likely >> that it is one problem. >> >> All I can suggest is working out a reproducable test case in your >> development environment, attaching a debugger and start digging around >> in memory when the problem is hit and try to find out exactly what >> is corrupted. If you can't reproduce it or work out what is >> occurring to trigger the problem, then we're not going to be able to >> find the cause... >> >> Cheers, >> >> Dave. >> > Thanks Dave > I did some experiments today with the corrupted filesystem. > setup : NAS box contains one volume /share and 10 subdirectories. > In first subdirectory sh1, I kept 512MB file. Through a script I > continuously copy this file > simultaneously from sh2 to sh10 subdirectories. > The script looks like > .... > while [ 1 ] > do > cp $1 $2 > done > > > And when I check the process status using top, almost all the cp > processes are in > uninterruptible sleep state continuously. Ran xfs_repair with -n > option on filesystem mounted on JBOD > Here is the output : > > > > Fri Jun 27 02:13:01 2008 > Phase 4 - check for duplicate blocks... > - setting up duplicate extent list... > - check for inodes claiming duplicate blocks... > - agno = 0 > - agno = 1 > bad nblocks 8788 for inode 33554562, would reset to 15461 > bad nextents 18 for inode 33554562, would reset to 32 > - agno = 2 > entry "iozone_68.tst" in shortform directory 67108993 references free > inode 67108995 > would have junked entry "iozone_68.tst" in directory inode 67108993 > data fork in ino 67108995 claims dup extent, off - 252, start - > 14711445, cnt 576 > bad data fork in inode 67108995 > would have cleared inode 67108995 > - agno = 3 > entry "iozone_68.tst" in shortform directory 100663425 references free > inode 100663427 > would have junked entry "iozone_68.tst" in directory inode 100663425 > inode 100663427 - bad extent starting block number 906006917242880, > offset 2533274882670609 > bad data fork in inode 100663427 > would have cleared inode 100663427 > - agno = 4 > bad nblocks 10214 for inode 134217859, would reset to 16761 > bad nextents 22 for inode 134217859, would reset to 34 > - agno = 5 > bad nblocks 23581 for inode 167772290, would reset to 27557 > bad nextents 39 for inode 167772290, would reset to 45 > - agno = 6 > bad nblocks 14527 for inode 201326722, would reset to 15697 > bad nextents 31 for inode 201326722, would reset to 34 > bad nblocks 12633 for inode 201326723, would reset to 16647 > bad nextents 23 for inode 201326723, would reset to 35 > - agno = 7 > bad nblocks 26638 for inode 234881154, would reset to 27557 > bad nextents 53 for inode 234881154, would reset to 54 > bad nblocks 85653 for inode 234881155, would reset to 85664 > bad nextents 310 for inode 234881155, would reset to 311 > - agno = 8 > bad nblocks 23241 for inode 268640387, would reset to 27565 > bad nextents 32 for inode 268640387, would reset to 42 > bad nblocks 81766 for inode 268640388, would reset to 86012 > bad nextents 332 for inode 268640388, would reset to 344 > - agno = 9 > entry "iozone_68.tst" in shortform directory 301990016 references free > inode 301990019 > would have junked entry "iozone_68.tst" in directory inode 301990016 > data fork in ino 301990019 claims dup extent, off - 26402, start - > 19129002, cnt 450 > bad data fork in inode 301990019 > would have cleared inode 301990019 > bad nblocks 70282 for inode 301990020, would reset to 71793 > bad nextents 281 for inode 301990020, would reset to 294 > - agno = 10 > entry "iozone_68.tst" in shortform directory 335544448 references free > inode 335544451 > would have junked entry "iozone_68.tst" in directory inode 335544448 > bad nblocks 11261 for inode 335544451, would reset to 19853 > bad nextents 24 for inode 335544451, would reset to 41 > imap claims in-use inode 335544451 is free, correcting imap > bad nblocks 119952 for inode 335544452, would reset to 121178 > bad nextents 301 for inode 335544452, would reset to 312 > - agno = 11 > bad nblocks 24361 for inode 369098883, would reset to 29553 > bad nextents 51 for inode 369098883, would reset to 57 > bad nblocks 3173 for inode 369098884, would reset to 5851 > bad nextents 10 for inode 369098884, would reset to 18 > - agno = 12 > entry "iozone_68.tst" in shortform directory 402653313 references free > inode 402653318 > would have junked entry "iozone_68.tst" in directory inode 402653313 > bad nblocks 16348 for inode 402653317, would reset to 21485 > bad nextents 28 for inode 402653317, would reset to 37 > data fork in ino 402653318 claims dup extent, off - 124142, start - > 29379669, cnt 2 > bad data fork in inode 402653318 > would have cleared inode 402653318 > - agno = 13 > bad nblocks 18374 for inode 436207747, would reset to 19991 > bad nextents 43 for inode 436207747, would reset to 47 > bad nblocks 38390 for inode 436207748, would reset to 38914 > bad nextents 300 for inode 436207748, would reset to 304 > - agno = 14 > bad nblocks 20267 for inode 469762178, would reset to 23089 > bad nextents 41 for inode 469762178, would reset to 45 > - agno = 15 > entry "iozone_68.tst" in shortform directory 503316608 references free > inode 503316609 > would have junked entry "iozone_68.tst" in directory inode 503316608 > imap claims in-use inode 503316609 is free, correcting imap > libxfs_bcache: 0x100020b0 > Max supported entries = 524288 > Max utilized entries = 562 > Active entries = 562 > Hash table size = 65536 > Hits = 1009 > Misses = 564 > Hit ratio = 64.00 > Hash buckets with 0 entries 65116 ( 0%) > Hash buckets with 1 entries 391 ( 69%) > Hash buckets with 2 entries 20 ( 7%) > Hash buckets with 3 entries 1 ( 0%) > Hash buckets with 15 entries 1 ( 2%) > Hash buckets with 16 entries 6 ( 17%) > Hash buckets with 17 entries 1 ( 3%) > Fri Jun 27 02:13:08 2008 > No modify flag set, skipping phase 5 > Phase 6 - check inode connectivity... > - traversing filesystem starting at / ... > - agno = 0 > - agno = 1 > - agno = 2 > entry "iozone_68.tst" in shortform directory inode 67108993 points to > free inode 67108995 > would junk entry "iozone_68.tst" > - agno = 3 > entry "iozone_68.tst" in shortform directory inode 100663425 points to > free inode 100663427 > would junk entry "iozone_68.tst" > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > - agno = 8 > - agno = 9 > entry "iozone_68.tst" in shortform directory inode 301990016 points to > free inode 301990019 > would junk entry "iozone_68.tst" > - agno = 10 > - agno = 11 > - agno = 12 > entry "iozone_68.tst" in shortform directory inode 402653313 points to > free inode 402653318 > would junk entry "iozone_68.tst" > - agno = 13 > - agno = 14 > - agno = 15 > - traversal finished ... > - traversing all unattached subtrees ... > - traversals finished ... > - moving disconnected inodes to lost+found ... > libxfs_icache: 0x10002050 > Max supported entries = 524288 > Max utilized entries = 42 > Active entries = 42 > Hash table size = 65536 > Hits = 0 > Misses = 42 > Hit ratio = 0.00 > Hash buckets with 0 entries 65524 ( 0%) > Hash buckets with 1 entries 9 ( 21%) > Hash buckets with 6 entries 1 ( 14%) > Hash buckets with 12 entries 1 ( 28%) > Hash buckets with 15 entries 1 ( 35%) > libxfs_bcache: 0x100020b0 > Max supported entries = 524288 > Max utilized entries = 562 > Active entries = 17 > Hash table size = 65536 > Hits = 1035 > Misses = 581 > Hit ratio = 64.00 > Hash buckets with 0 entries 65533 ( 0%) > Hash buckets with 1 entries 2 ( 11%) > Hash buckets with 15 entries 1 ( 88%) > Fri Jun 27 02:13:10 2008 > Phase 7 - verify link counts... > - agno = 0 > - agno = 1 > - agno = 2 > - agno = 3 > - agno = 4 > - agno = 5 > - agno = 6 > - agno = 7 > - agno = 8 > - agno = 9 > - agno = 10 > - agno = 11 > - agno = 12 > - agno = 13 > - agno = 14 > - agno = 15 > libxfs_icache: 0x10002050 > Max supported entries = 524288 > Max utilized entries = 42 > Active entries = 42 > Hash table size = 65536 > Hits = 0 > Misses = 42 > Hit ratio = 0.00 > Hash buckets with 0 entries 65524 ( 0%) > Hash buckets with 1 entries 9 ( 21%) > Hash buckets with 6 entries 1 ( 14%) > Hash buckets with 12 entries 1 ( 28%) > Hash buckets with 15 entries 1 ( 35%) > libxfs_bcache: 0x100020b0 > Max supported entries = 524288 > Max utilized entries = 562 > Active entries = 16 > Hash table size = 65536 > Hits = 1051 > Misses = 597 > Hit ratio = 63.00 > Hash buckets with 0 entries 65534 ( 0%) > Hash buckets with 1 entries 1 ( 6%) > Hash buckets with 15 entries 1 ( 93%) > Fri Jun 27 02:13:17 2008 > No modify flag set, skipping filesystem flush and exiting. > > So there are several bad blocks and extents present in all ag, > which are causing the problem. > top output reveals that all cp are in D state > PID USER STATUS RSS PPID %CPU %MEM COMMAND > 7455 root R 984 1892 7.4 0.7 top > 6100 root D 524 1973 2.9 0.4 cp > 6799 root R 524 1983 2.9 0.4 cp > 6796 root D 524 2125 2.9 0.4 cp > 6074 root D 524 2109 1.4 0.4 cp > 6097 root D 524 1979 1.4 0.4 cp > 6076 root D 524 1975 1.4 0.4 cp > 6738 root D 524 2123 1.4 0.4 cp > 6759 root D 524 2115 1.4 0.4 cp > 7035 root D 524 1977 1.4 0.4 cp > 7440 root D 520 1985 1.4 0.4 cp > 73 root SW< 0 6 1.4 0.0 xfsdatad/0 > 67 root SW 0 6 1.4 0.0 pdflush > ... > .. > This means that they are waiting for an IO and sleeping in system > call but not able > to come out as several inodes are corrupted. And hence the script > never gets completed. > > Thanks > Sagar > > > From owner-xfs@oss.sgi.com Fri Jun 27 04:32:43 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 04:32:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,STOX_REPLY_TYPE 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 m5RBWgxv026980 for ; Fri, 27 Jun 2008 04:32:42 -0700 X-ASG-Debug-ID: 1214566422-4b7801a10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8EA772918E9 for ; Fri, 27 Jun 2008 04:33:42 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id pxWmCIHk9wVuz33G for ; Fri, 27 Jun 2008 04:33:42 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.192]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5RBXSrG005723; Fri, 27 Jun 2008 20:33:28 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5RBXS922466; Fri, 27 Jun 2008 20:33:28 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5RBXSr8013029; Fri, 27 Jun 2008 20:33:28 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Fri, 27 Jun 2008 20:33:27 +0900 Message-Id: <2B8295B5761847BCB9831DB3ADE96B49@nsl.ad.nec.co.jp> From: "Takashi Sato" To: "Andrew Morton" Cc: , , , , , , , References: <20080624155950t-sato@mail.jp.nec.com> <20080624144803.0135a84d.akpm@linux-foundation.org> In-Reply-To: <20080624144803.0135a84d.akpm@linux-foundation.org> X-ASG-Orig-Subj: Re: [PATCH 1/3] Implement generic freeze feature Subject: Re: [PATCH 1/3] Implement generic freeze feature Date: Fri, 27 Jun 2008 20:33:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1214566423 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54479 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16615 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi, >> +/* >> + * get_super_without_lock - Get super_block from block_device without lock. >> + * @bdev: block device struct >> + * >> + * Scan the superblock list and finds the superblock of the file system >> + * mounted on the block device given. This doesn't lock anyone. >> + * %NULL is returned if no match is found. >> + */ > > This is not a terribly good comment. > > Which lock are we not taking? I _assume_ that it's referring to > s_umount? If so, the text should describe that. > > It should also go to some lengths explaining why this dangerous-looking > and rather nasty-looking function exists. > > Look at it this way: there is no way in which the reviewer of this > patch (ie: me) can work out why this function exists. Hence there will > be no way in which future readers of this code will be able to work out > why this function exists either. This is bad. These things should be > described in code comments and in the changelog (whichever is most > appropriate). Thank you for your comment. I will write comments appropriately. I was wrong. I thought we didn't need to lock s_umount because this ioctl required to open a regular file or a directory and we cannot unmount a target filesystem. So I created get_super_without_lock() used in freeze_bdev(). But, I have found that the ioctl (DM_DEV_SUSPEND_CMD in drivers/md/dm-ioctl.c) requires to open a logical volume (not a file or a directory) and calls freeze_bdev(), so we can unmount a filesystem. So I will replace get_super_without_lock with get_super to get s_umount. Cheers, Takashi From owner-xfs@oss.sgi.com Fri Jun 27 04:33:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 04:33:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53,STOX_REPLY_TYPE 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 m5RBX6we027071 for ; Fri, 27 Jun 2008 04:33:06 -0700 X-ASG-Debug-ID: 1214566446-27ee01be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B8F6412CD7CD for ; Fri, 27 Jun 2008 04:34:06 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id w7Dd79eVRCPvxj1o for ; Fri, 27 Jun 2008 04:34:06 -0700 (PDT) Received: from mailgate4.nec.co.jp (mailgate53.nec.co.jp [10.7.69.184]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5RBY0p8005964; Fri, 27 Jun 2008 20:34:00 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5RBY0326566; Fri, 27 Jun 2008 20:34:00 +0900 (JST) Received: from togyo.jp.nec.com (togyo.jp.nec.com [10.26.220.4]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5RBXxPw002402; Fri, 27 Jun 2008 20:33:59 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Fri, 27 Jun 2008 20:33:59 +0900 Message-Id: <7B349EFCD35842D4ADAEB402D2BDCA4E@nsl.ad.nec.co.jp> From: "Takashi Sato" To: "Andrew Morton" Cc: , , , , , , , References: <20080624160056t-sato@mail.jp.nec.com> <20080624150925.765155f0.akpm@linux-foundation.org> In-Reply-To: <20080624150925.765155f0.akpm@linux-foundation.org> X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature Date: Fri, 27 Jun 2008 20:33:58 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1214566447 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.54479 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: 16616 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi, >> o Reset the timeout period >> int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeval) >> fd:file descriptor of mountpoint >> FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period >> timeval: new timeout period in seconds >> Return value: 0 if the operation succeeds. Otherwise, -1 >> Error number: If the filesystem has already been unfrozen, >> errno is set to EINVAL. > > Please avoid the use of the term `timeval' here. That term is closely > associated with `struct timeval', and these are not being used here. A > better identifier would be timeout_secs - it tells the reader what it > does, and it tells the reader what units it is in. And when it comes > to "time", it is very useful to tell people which units are being used, > because there are many different ones. OK. I will use "timeout_secs" in the next version to match the source code. >> -static int ioctl_freeze(struct file *filp) >> +static int ioctl_freeze(struct file *filp, unsigned long arg) >> { >> + long timeout_sec; >> + long timeout_msec; >> struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; >> + int error; >> >> if (!capable(CAP_SYS_ADMIN)) >> return -EPERM; >> @@ -159,8 +163,27 @@ static int ioctl_freeze(struct file *fil >> if (sb->s_op->write_super_lockfs == NULL) >> return -EOPNOTSUPP; >> >> + /* arg(sec) to tick value. */ >> + error = get_user(timeout_sec, (long __user *) arg);> > uh-oh, compat problems. > > A 32-bit application running under a 32-bit kernel will need to provide > a 32-bit quantity. > > A 32-bit application running under a 64-bit kernel will need to provide > a 64-bit quantity. > > I suggest that you go through the entire patch and redo this part of > the kernel ABI in terms of __u32, and avoid any mention of "long" in > the kernel<->userspace interface. I agree. I will replace long with a 32bit integer type. >> + /* arg(sec) to tick value. */ >> + error = get_user(timeout_sec, (long __user *) arg); >> + if (timeout_sec < 0) >> + return -EINVAL; >> + else if (timeout_sec < 2) >> + timeout_sec = 0;> The `else' is unneeded. > > It would be clearer to code this all as: > > if (timeout_sec < 0) > return -EINVAL; > > if (timeout_sec == 1) { > /* > * If 1 is specified as the timeout period it is changed into 0 > * to retain compatibility with XFS's xfs_freeze. > */ > timeout_sec = 0; > } OK. >> + if (error) >> + return error; >> + timeout_msec = timeout_sec * 1000; >> + if (timeout_msec < 0) >> + return -EINVAL; > > um, OK, but timeout_msec could have overflowed during the > multiplication and could be complete garbage. I guess it doesn't > matter much, but a cleaner approach might be: > > if (timeout_sec > LONG_MAX/1000) > return -EINVAL; > > or something like that. OK. > But otoh, why do the multiplication at all? If we're able to handle > the timeout down to the millisecond level, why not offer that > resolution to userspace? Offer the increased time granularity to the > application? I think there is no case the user specifies it in millisecond, so the second granularity is more comfortable. >> + if (sb) { > > Can this happen? I have found that sb == NULL never happen but sb->s_bdev == NULL can happen when we call this ioctl for a device file (not a directory or a regular file). So I will add the following check. if (sb->s_bdev == NULL) return -EINVAL; >> + if (test_and_set_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state)) >> + return -EBUSY; >> + if (sb->s_frozen == SB_UNFROZEN) { >> + clear_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state); >> + return -EINVAL; >> + } >> + /* setup unfreeze timer */ >> + if (timeout_msec > 0) > > What does this test do? afacit it's special-casing the timeout_secs==0 > case. Was this feature documented? What does it do? There is no special case of timeout_secs==0. I will remove this check. >> +void add_freeze_timeout(struct block_device *bdev, long timeout_msec) >> +{ >> + s64 timeout_jiffies = msecs_to_jiffies(timeout_msec); >> + >> + /* Set delayed work queue */ >> + cancel_delayed_work(&bdev->bd_freeze_timeout); > > Should this have used cancel_delayed_work_sync()? Exactly. I will replace cancel_delayed_work with cancel_delayed_work_sync. >> +void del_freeze_timeout(struct block_device *bdev) >> +{ >> + if (delayed_work_pending(&bdev->bd_freeze_timeout)) > > Is this test needed? It's not necessary because cancel_delayed_work_sync checks it itself. I will remove it. >> --- linux-2.6.26-rc7-xfs/fs/xfs/xfs_fsops.c 2008-06-23 11:55:15.000000000 +0900 >> +++ linux-2.6.26-rc7-timeout/fs/xfs/xfs_fsops.c 2008-06-23 11:56:47.000000000 +0900 >> @@ -619,7 +619,7 @@ xfs_fs_goingdown( >> { >> switch (inflags) { >> case XFS_FSOP_GOING_FLAGS_DEFAULT: { >> - struct super_block *sb = freeze_bdev(mp->m_super->s_bdev); >> + struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, 0); > > Using NULL here is clearer and will, I expect, avoid a sparse warning. I checked it but I couldn't find a sparse warning in xfs_fsops.c. Can you tell me how to use NULL? Cheers, Takashi From owner-xfs@oss.sgi.com Fri Jun 27 04:56:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 04:56:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_64, 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 m5RBug8n029899 for ; Fri, 27 Jun 2008 04:56:42 -0700 X-ASG-Debug-ID: 1214567862-688503060000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ag.ohio-state.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6F446183B448 for ; Fri, 27 Jun 2008 04:57:42 -0700 (PDT) Received: from ag.ohio-state.edu (smtp.cfaes.ohio-state.edu [140.254.85.32]) by cuda.sgi.com with ESMTP id NpDvElrfjG1DjFgA for ; Fri, 27 Jun 2008 04:57:42 -0700 (PDT) X-ASG-Orig-Subj: Undeliverable mail: Mail System Error - Returned Mail Subject: Undeliverable mail: Mail System Error - Returned Mail From: To: Date: Fri, 27 Jun 2008 08:04:51 -0400 Message-ID: X-MAPI-Message-Class: REPORT.IPM.Note.NDR MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===49719331====ag.ohio-state.edu===_" X-Barracuda-Connect: smtp.cfaes.ohio-state.edu[140.254.85.32] X-Barracuda-Start-Time: 1214567863 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1258 1.0000 -1.2404 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.69 X-Barracuda-Spam-Status: No, SCORE=-0.69 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=ANY_BOUNCE_MESSAGE, BOUNCE_MESSAGE, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54482 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.00 BOUNCE_MESSAGE MTA bounce message 0.00 ANY_BOUNCE_MESSAGE Message is some kind of bounce message 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: 16617 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@ag.ohio-state.edu Precedence: bulk X-list: xfs --_===49719331====ag.ohio-state.edu===_ Content-Type: text/plain; charset="utf-8" Failed to deliver to '' LIST module(list devfinance) reports: You cannot post messages because you are not subscribed to this list --_===49719331====ag.ohio-state.edu===_ Content-Type: message/delivery-status Reporting-MTA: dns; ag.ohio-state.edu Original-Recipient: rfc822; Final-Recipient: LIST; Action: failed Status: 5.0.0 --_===49719331====ag.ohio-state.edu===_ Content-Type: text/rfc822-headers Received: from [155.212.117.233] (HELO oss.sgi.com) by ag.ohio-state.edu (CommuniGate Pro SMTP 5.2.2) with ESMTP id 49719333 for devfinance@ag.ohio-state.edu; Fri, 27 Jun 2008 08:04:50 -0400 From: linux-xfs@oss.sgi.com To: devfinance@ag.ohio-state.edu Subject: Mail System Error - Returned Mail Date: Fri, 27 Jun 2008 07:57:37 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0011_B4BB7E44.9660100C" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: --_===49719331====ag.ohio-state.edu===_-- From owner-xfs@oss.sgi.com Fri Jun 27 05:42:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 05:43: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.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5RCgvE5002216 for ; Fri, 27 Jun 2008 05:42:58 -0700 X-ASG-Debug-ID: 1214570638-08f000c60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7A69312CE055; Fri, 27 Jun 2008 05:43:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id nPkJpuQDTsaezCve; Fri, 27 Jun 2008 05:43:58 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5RChuAe018760; Fri, 27 Jun 2008 08:43:56 -0400 Received: from pobox.devel.redhat.com (pobox.devel.redhat.com [10.11.255.8]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5RChtji020662; Fri, 27 Jun 2008 08:43:55 -0400 Received: from warthog.cambridge.redhat.com (devserv.devel.redhat.com [10.10.36.72]) by pobox.devel.redhat.com (8.13.1/8.13.1) with ESMTP id m5RChsUW014756; Fri, 27 Jun 2008 08:43:55 -0400 Received: from [127.0.0.1] (helo=warthog.procyon.org.uk) by warthog.cambridge.redhat.com with esmtp (Exim 4.68 #1 (Red Hat Linux)) id 1KCDIw-0004wY-QJ; Fri, 27 Jun 2008 13:43:54 +0100 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells X-ASG-Orig-Subj: [PATCH] Fix disabled XFS POSIX ACL handling Subject: [PATCH] Fix disabled XFS POSIX ACL handling To: hch@infradead.org, tes@sgi.com, lachlan@sgi.com Cc: xfs-masters@oss.sgi.com, xfs@oss.sgi.com, dhowells@redhat.com Date: Fri, 27 Jun 2008 13:43:54 +0100 Message-ID: <20080627124354.18978.72867.stgit@warthog.procyon.org.uk> User-Agent: StGIT/0.14.1 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1214570639 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16618 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dhowells@redhat.com Precedence: bulk X-list: xfs Fix XFS POSIX ACL handling when it's not enabled. xfs_decode_acl() refers to return types that aren't defined under those circumstances. Signed-off-by: David Howells --- fs/xfs/linux-2.6/xfs_xattr.c | 14 -------------- fs/xfs/xfs_acl.c | 13 +++++++++++++ fs/xfs/xfs_acl.h | 2 ++ 3 files changed, 15 insertions(+), 14 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_xattr.c b/fs/xfs/linux-2.6/xfs_xattr.c index b4acb68..fe93f41 100644 --- a/fs/xfs/linux-2.6/xfs_xattr.c +++ b/fs/xfs/linux-2.6/xfs_xattr.c @@ -30,20 +30,6 @@ /* - * ACL handling. Should eventually be moved into xfs_acl.c - */ - -static int -xfs_decode_acl(const char *name) -{ - if (strcmp(name, "posix_acl_access") == 0) - return _ACL_TYPE_ACCESS; - else if (strcmp(name, "posix_acl_default") == 0) - return _ACL_TYPE_DEFAULT; - return -EINVAL; -} - -/* * Get system extended attributes which at the moment only * includes Posix ACLs. */ diff --git a/fs/xfs/xfs_acl.c b/fs/xfs/xfs_acl.c index 93057af..24bcbf5 100644 --- a/fs/xfs/xfs_acl.c +++ b/fs/xfs/xfs_acl.c @@ -51,6 +51,19 @@ kmem_zone_t *xfs_acl_zone; /* + * ACL handling. + */ +int +xfs_decode_acl(const char *name) +{ + if (strcmp(name, "posix_acl_access") == 0) + return _ACL_TYPE_ACCESS; + else if (strcmp(name, "posix_acl_default") == 0) + return _ACL_TYPE_DEFAULT; + return -EINVAL; +} + +/* * Test for existence of access ACL attribute as efficiently as possible. */ int diff --git a/fs/xfs/xfs_acl.h b/fs/xfs/xfs_acl.h index 332a772..7bf8ef5 100644 --- a/fs/xfs/xfs_acl.h +++ b/fs/xfs/xfs_acl.h @@ -57,6 +57,7 @@ extern struct kmem_zone *xfs_acl_zone; (zone) = kmem_zone_init(sizeof(xfs_acl_t), (name)) #define xfs_acl_zone_destroy(zone) kmem_zone_destroy(zone) +extern int xfs_decode_acl(const char *); extern int xfs_acl_inherit(bhv_vnode_t *, mode_t mode, xfs_acl_t *); extern int xfs_acl_iaccess(struct xfs_inode *, mode_t, cred_t *); extern int xfs_acl_vtoacl(bhv_vnode_t *, xfs_acl_t *, xfs_acl_t *); @@ -80,6 +81,7 @@ extern int xfs_acl_vremove(bhv_vnode_t *, int); #define _ACL_FREE(a) ((a)? kmem_zone_free(xfs_acl_zone, (a)):(void)0) #else +#define xfs_decode_acl(name) (-EINVAL) #define xfs_acl_zone_init(zone,name) #define xfs_acl_zone_destroy(zone) #define xfs_acl_vset(v,p,sz,t) (-EOPNOTSUPP) From owner-xfs@oss.sgi.com Fri Jun 27 06:02:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 06:02:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5RD2A7t004330 for ; Fri, 27 Jun 2008 06:02:10 -0700 X-ASG-Debug-ID: 1214571790-023401cd0000-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 BFE1212CE3B0; Fri, 27 Jun 2008 06:03:11 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 3Cu6GLKltof7M3WV; Fri, 27 Jun 2008 06:03:11 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KCDba-0007zG-NP; Fri, 27 Jun 2008 13:03:10 +0000 Date: Fri, 27 Jun 2008 09:03:10 -0400 From: Christoph Hellwig To: Niv Sardi Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Subject: Re: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Message-ID: <20080627130310.GA4659@infradead.org> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <20080626082827.GC23954@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214571791 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.54485 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: 16619 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 Looks good except for a tiny nitpick: > +/* > + * Calculate how many blocks we need for the new attribute, > + */ > +int > +xfs_attr_calc_size( > + struct xfs_inode *ip, > + int namelen, > + int valuelen, > + int *local) > +{ > + struct xfs_mount *mp = ip->i_mount; Add another tab before the variable names so that it aligns nicely. From owner-xfs@oss.sgi.com Fri Jun 27 06:02:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 06:02:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5RD2iGG004575 for ; Fri, 27 Jun 2008 06:02:44 -0700 X-ASG-Debug-ID: 1214571824-4d6f001f0000-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 95A59292992; Fri, 27 Jun 2008 06:03:45 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 0czZfR3F74mthl2T; Fri, 27 Jun 2008 06:03:45 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KCDc8-000164-I0; Fri, 27 Jun 2008 13:03:44 +0000 Date: Fri, 27 Jun 2008 09:03:44 -0400 From: Christoph Hellwig To: Niv Sardi Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Subject: Re: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Message-ID: <20080627130344.GA1327@infradead.org> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <20080626082827.GC23954@infradead.org> <20080627130310.GA4659@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080627130310.GA4659@infradead.org> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214571825 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.54486 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: 16620 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 But this isn't actually the patch described by the subject.. On Fri, Jun 27, 2008 at 09:03:10AM -0400, Christoph Hellwig wrote: > Looks good except for a tiny nitpick: > > > +/* > > + * Calculate how many blocks we need for the new attribute, > > + */ > > +int > > +xfs_attr_calc_size( > > + struct xfs_inode *ip, > > + int namelen, > > + int valuelen, > > + int *local) > > +{ > > + struct xfs_mount *mp = ip->i_mount; > > Add another tab before the variable names so that it aligns nicely. From owner-xfs@oss.sgi.com Fri Jun 27 06:05:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 06:05:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62, 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 m5RD4vVM005236 for ; Fri, 27 Jun 2008 06:04:59 -0700 X-ASG-Debug-ID: 1214571956-038101470000-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 7C0BE183BF7C for ; Fri, 27 Jun 2008 06:05:56 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id lYpUmzXDwleHiJVH for ; Fri, 27 Jun 2008 06:05: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 m5RD5kNW023503 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Jun 2008 15:05:46 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5RD5klp023501 for xfs@oss.sgi.com; Fri, 27 Jun 2008 15:05:46 +0200 Date: Fri, 27 Jun 2008 15:05:46 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] sanitize xfs_initialize_vnode Subject: Re: [PATCH] sanitize xfs_initialize_vnode Message-ID: <20080627130546.GA23431@lst.de> References: <20080502105215.GA17870@lst.de> <20080520063622.GA8869@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080520063622.GA8869@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: 1214571957 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.54486 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: 16621 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 Tue, May 20, 2008 at 08:36:22AM +0200, Christoph Hellwig wrote: > ping? > > On Fri, May 02, 2008 at 12:52:15PM +0200, Christoph Hellwig wrote: > > Sanitize setting up the Linux indode. > > > > Setting up the xfs_inode <-> inode link is opencoded in xfs_iget_core > > now because that's the only place it needs to be done, > > xfs_initialize_vnode is renamed to xfs_setup_inode and loses all > > superflous paramaters. The check for I_NEW is removed because it always > > is true and the di_mode check moves into xfs_iget_core because it's only > > needed there. > > > > xfs_set_inodeops and xfs_revalidate_inode are merged into > > xfs_setup_inode and the whole things is moved into xfs_iops.c where it > > belongs. > > > > > > Signed-off-by: Christoph Hellwig > > > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-05-02 08:41:27.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-05-02 08:51:46.000000000 +0200 > > @@ -777,7 +777,7 @@ out_error: > > return error; > > } > > > > -const struct inode_operations xfs_inode_operations = { > > +static const struct inode_operations xfs_inode_operations = { > > .permission = xfs_vn_permission, > > .truncate = xfs_vn_truncate, > > .getattr = xfs_vn_getattr, > > @@ -789,7 +789,7 @@ const struct inode_operations xfs_inode_ > > .fallocate = xfs_vn_fallocate, > > }; > > > > -const struct inode_operations xfs_dir_inode_operations = { > > +static const struct inode_operations xfs_dir_inode_operations = { > > .create = xfs_vn_create, > > .lookup = xfs_vn_lookup, > > .link = xfs_vn_link, > > @@ -808,7 +808,7 @@ const struct inode_operations xfs_dir_in > > .listxattr = xfs_vn_listxattr, > > }; > > > > -const struct inode_operations xfs_symlink_inode_operations = { > > +static const struct inode_operations xfs_symlink_inode_operations = { > > .readlink = generic_readlink, > > .follow_link = xfs_vn_follow_link, > > .put_link = xfs_vn_put_link, > > @@ -820,3 +820,95 @@ const struct inode_operations xfs_symlin > > .removexattr = generic_removexattr, > > .listxattr = xfs_vn_listxattr, > > }; > > + > > +STATIC void > > +xfs_diflags_to_iflags( > > + struct inode *inode, > > + struct xfs_inode *ip) > > +{ > > + if (ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) > > + inode->i_flags |= S_IMMUTABLE; > > + else > > + inode->i_flags &= ~S_IMMUTABLE; > > + if (ip->i_d.di_flags & XFS_DIFLAG_APPEND) > > + inode->i_flags |= S_APPEND; > > + else > > + inode->i_flags &= ~S_APPEND; > > + if (ip->i_d.di_flags & XFS_DIFLAG_SYNC) > > + inode->i_flags |= S_SYNC; > > + else > > + inode->i_flags &= ~S_SYNC; > > + if (ip->i_d.di_flags & XFS_DIFLAG_NOATIME) > > + inode->i_flags |= S_NOATIME; > > + else > > + inode->i_flags &= ~S_NOATIME; > > +} > > + > > +/* > > + * Initialize the Linux inode, set up the operation vectors and > > + * unlock the inode. > > + * > > + * When reading existing inodes from disk this is called directly > > + * from xfs_iget, when creating a new inode it is called from > > + * xfs_ialloc after setting up the inode. > > + */ > > +void > > +xfs_setup_inode( > > + struct xfs_inode *ip) > > +{ > > + struct inode *inode = ip->i_vnode; > > + > > + inode->i_mode = ip->i_d.di_mode; > > + inode->i_nlink = ip->i_d.di_nlink; > > + inode->i_uid = ip->i_d.di_uid; > > + inode->i_gid = ip->i_d.di_gid; > > + > > + switch (inode->i_mode & S_IFMT) { > > + case S_IFBLK: > > + case S_IFCHR: > > + inode->i_rdev = > > + MKDEV(sysv_major(ip->i_df.if_u2.if_rdev) & 0x1ff, > > + sysv_minor(ip->i_df.if_u2.if_rdev)); > > + break; > > + default: > > + inode->i_rdev = 0; > > + break; > > + } > > + > > + inode->i_generation = ip->i_d.di_gen; > > + i_size_write(inode, ip->i_d.di_size); > > + inode->i_atime.tv_sec = ip->i_d.di_atime.t_sec; > > + inode->i_atime.tv_nsec = ip->i_d.di_atime.t_nsec; > > + inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; > > + inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; > > + inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; > > + inode->i_ctime.tv_nsec = ip->i_d.di_ctime.t_nsec; > > + xfs_diflags_to_iflags(inode, ip); > > + xfs_iflags_clear(ip, XFS_IMODIFIED); > > + > > + switch (inode->i_mode & S_IFMT) { > > + case S_IFREG: > > + inode->i_op = &xfs_inode_operations; > > + inode->i_fop = &xfs_file_operations; > > + inode->i_mapping->a_ops = &xfs_address_space_operations; > > + break; > > + case S_IFDIR: > > + inode->i_op = &xfs_dir_inode_operations; > > + inode->i_fop = &xfs_dir_file_operations; > > + break; > > + case S_IFLNK: > > + inode->i_op = &xfs_symlink_inode_operations; > > + if (!(ip->i_df.if_flags & XFS_IFINLINE)) > > + inode->i_mapping->a_ops = &xfs_address_space_operations; > > + break; > > + default: > > + inode->i_op = &xfs_inode_operations; > > + init_special_inode(inode, inode->i_mode, inode->i_rdev); > > + break; > > + } > > + > > + xfs_iflags_clear(ip, XFS_INEW); > > + barrier(); > > + > > + unlock_new_inode(inode); > > +} > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.h > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.h 2008-05-02 08:41:27.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.h 2008-05-02 08:41:35.000000000 +0200 > > @@ -18,9 +18,7 @@ > > #ifndef __XFS_IOPS_H__ > > #define __XFS_IOPS_H__ > > > > -extern const struct inode_operations xfs_inode_operations; > > -extern const struct inode_operations xfs_dir_inode_operations; > > -extern const struct inode_operations xfs_symlink_inode_operations; > > +struct xfs_inode; > > > > extern const struct file_operations xfs_file_operations; > > extern const struct file_operations xfs_dir_file_operations; > > @@ -28,10 +26,11 @@ extern const struct file_operations xfs_ > > > > extern ssize_t xfs_vn_listxattr(struct dentry *, char *data, size_t size); > > > > -struct xfs_inode; > > extern void xfs_ichgtime(struct xfs_inode *, int); > > extern void xfs_ichgtime_fast(struct xfs_inode *, struct inode *, int); > > > > +extern void xfs_setup_inode(struct xfs_inode *); > > + > > #define xfs_vtoi(vp) \ > > ((struct xfs_inode *)vn_to_inode(vp)->i_private) > > > > 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-05-02 08:41:27.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2008-05-02 08:41:35.000000000 +0200 > > @@ -155,12 +155,9 @@ EXPORT_SYMBOL(kmem_zone_free); > > EXPORT_SYMBOL(kmem_zone_init); > > EXPORT_SYMBOL(kmem_zone_zalloc); > > EXPORT_SYMBOL(xfs_address_space_operations); > > -EXPORT_SYMBOL(xfs_dir_inode_operations); > > EXPORT_SYMBOL(xfs_dir_file_operations); > > -EXPORT_SYMBOL(xfs_inode_operations); > > EXPORT_SYMBOL(xfs_file_operations); > > EXPORT_SYMBOL(xfs_invis_file_operations); > > -EXPORT_SYMBOL(xfs_symlink_inode_operations); > > EXPORT_SYMBOL(xfs_buf_delwri_dequeue); > > EXPORT_SYMBOL(_xfs_buf_find); > > EXPORT_SYMBOL(xfs_buf_iostart); > > 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-02 08:41:34.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-05-02 08:51:43.000000000 +0200 > > @@ -558,115 +558,6 @@ xfs_max_file_offset( > > return (((__uint64_t)pagefactor) << bitshift) - 1; > > } > > > > -STATIC_INLINE void > > -xfs_set_inodeops( > > - struct inode *inode) > > -{ > > - switch (inode->i_mode & S_IFMT) { > > - case S_IFREG: > > - inode->i_op = &xfs_inode_operations; > > - inode->i_fop = &xfs_file_operations; > > - inode->i_mapping->a_ops = &xfs_address_space_operations; > > - break; > > - case S_IFDIR: > > - inode->i_op = &xfs_dir_inode_operations; > > - inode->i_fop = &xfs_dir_file_operations; > > - break; > > - case S_IFLNK: > > - inode->i_op = &xfs_symlink_inode_operations; > > - if (!(XFS_I(inode)->i_df.if_flags & XFS_IFINLINE)) > > - inode->i_mapping->a_ops = &xfs_address_space_operations; > > - break; > > - default: > > - inode->i_op = &xfs_inode_operations; > > - init_special_inode(inode, inode->i_mode, inode->i_rdev); > > - break; > > - } > > -} > > - > > -STATIC_INLINE void > > -xfs_revalidate_inode( > > - xfs_mount_t *mp, > > - bhv_vnode_t *vp, > > - xfs_inode_t *ip) > > -{ > > - struct inode *inode = vn_to_inode(vp); > > - > > - inode->i_mode = ip->i_d.di_mode; > > - inode->i_nlink = ip->i_d.di_nlink; > > - inode->i_uid = ip->i_d.di_uid; > > - inode->i_gid = ip->i_d.di_gid; > > - > > - switch (inode->i_mode & S_IFMT) { > > - case S_IFBLK: > > - case S_IFCHR: > > - inode->i_rdev = > > - MKDEV(sysv_major(ip->i_df.if_u2.if_rdev) & 0x1ff, > > - sysv_minor(ip->i_df.if_u2.if_rdev)); > > - break; > > - default: > > - inode->i_rdev = 0; > > - break; > > - } > > - > > - inode->i_generation = ip->i_d.di_gen; > > - i_size_write(inode, ip->i_d.di_size); > > - inode->i_atime.tv_sec = ip->i_d.di_atime.t_sec; > > - inode->i_atime.tv_nsec = ip->i_d.di_atime.t_nsec; > > - inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; > > - inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; > > - inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; > > - inode->i_ctime.tv_nsec = ip->i_d.di_ctime.t_nsec; > > - if (ip->i_d.di_flags & XFS_DIFLAG_IMMUTABLE) > > - inode->i_flags |= S_IMMUTABLE; > > - else > > - inode->i_flags &= ~S_IMMUTABLE; > > - if (ip->i_d.di_flags & XFS_DIFLAG_APPEND) > > - inode->i_flags |= S_APPEND; > > - else > > - inode->i_flags &= ~S_APPEND; > > - if (ip->i_d.di_flags & XFS_DIFLAG_SYNC) > > - inode->i_flags |= S_SYNC; > > - else > > - inode->i_flags &= ~S_SYNC; > > - if (ip->i_d.di_flags & XFS_DIFLAG_NOATIME) > > - inode->i_flags |= S_NOATIME; > > - else > > - inode->i_flags &= ~S_NOATIME; > > - xfs_iflags_clear(ip, XFS_IMODIFIED); > > -} > > - > > -void > > -xfs_initialize_vnode( > > - struct xfs_mount *mp, > > - bhv_vnode_t *vp, > > - struct xfs_inode *ip) > > -{ > > - struct inode *inode = vn_to_inode(vp); > > - > > - if (!ip->i_vnode) { > > - ip->i_vnode = vp; > > - inode->i_private = ip; > > - } > > - > > - /* > > - * We need to set the ops vectors, and unlock the inode, but if > > - * we have been called during the new inode create process, it is > > - * too early to fill in the Linux inode. We will get called a > > - * second time once the inode is properly set up, and then we can > > - * finish our work. > > - */ > > - if (ip->i_d.di_mode != 0 && (inode->i_state & I_NEW)) { > > - xfs_revalidate_inode(mp, vp, ip); > > - xfs_set_inodeops(inode); > > - > > - xfs_iflags_clear(ip, XFS_INEW); > > - barrier(); > > - > > - unlock_new_inode(inode); > > - } > > -} > > - > > int > > xfs_blkdev_get( > > xfs_mount_t *mp, > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.h > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.h 2008-05-02 08:41:27.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.h 2008-05-02 08:41:35.000000000 +0200 > > @@ -72,9 +72,6 @@ struct block_device; > > > > extern __uint64_t xfs_max_file_offset(unsigned int); > > > > -extern void xfs_initialize_vnode(struct xfs_mount *mp, bhv_vnode_t *vp, > > - struct xfs_inode *ip); > > - > > extern void xfs_flush_inode(struct xfs_inode *); > > extern void xfs_flush_device(struct xfs_inode *); > > > > Index: linux-2.6-xfs/fs/xfs/xfs_iget.c > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/xfs_iget.c 2008-05-02 08:41:27.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/xfs_iget.c 2008-05-02 08:53:18.000000000 +0200 > > @@ -288,10 +288,17 @@ finish_inode: > > *ipp = ip; > > > > /* > > + * Set up the Linux with the Linux inode. > > + */ > > + ip->i_vnode = inode; > > + inode->i_private = ip; > > + > > + /* > > * If we have a real type for an on-disk inode, we can set ops(&unlock) > > * now. If it's a new inode being created, xfs_ialloc will handle it. > > */ > > - xfs_initialize_vnode(mp, inode, ip); > > + if (ip->i_d.di_mode != 0) > > + xfs_setup_inode(ip); > > return 0; > > } > > > > Index: linux-2.6-xfs/fs/xfs/xfs_inode.c > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2008-05-02 08:41:27.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2008-05-02 08:41:35.000000000 +0200 > > @@ -1046,7 +1046,6 @@ xfs_ialloc( > > { > > xfs_ino_t ino; > > xfs_inode_t *ip; > > - bhv_vnode_t *vp; > > uint flags; > > int error; > > > > @@ -1077,7 +1076,6 @@ xfs_ialloc( > > } > > ASSERT(ip != NULL); > > > > - vp = XFS_ITOV(ip); > > ip->i_d.di_mode = (__uint16_t)mode; > > ip->i_d.di_onlink = 0; > > ip->i_d.di_nlink = nlink; > > @@ -1220,7 +1218,7 @@ xfs_ialloc( > > xfs_trans_log_inode(tp, ip, flags); > > > > /* now that we have an i_mode we can setup inode ops and unlock */ > > - xfs_initialize_vnode(tp->t_mountp, vp, ip); > > + xfs_setup_inode(ip); > > > > *ipp = ip; > > return 0; > ---end quoted text--- ---end quoted text--- From owner-xfs@oss.sgi.com Fri Jun 27 06:05:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 06:05:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5RD5auY005420 for ; Fri, 27 Jun 2008 06:05:36 -0700 X-ASG-Debug-ID: 1214571996-38f900320000-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 A5B4012CDF83 for ; Fri, 27 Jun 2008 06:06:36 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id Cui4naCm1apAWt8I for ; Fri, 27 Jun 2008 06:06:36 -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 m5RD6RNW023565 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Jun 2008 15:06:27 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5RD6RIh023563 for xfs@oss.sgi.com; Fri, 27 Jun 2008 15:06:27 +0200 Date: Fri, 27 Jun 2008 15:06:27 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/2] kill xfs_lock_dir_and_entry Subject: Re: [PATCH 2/2] kill xfs_lock_dir_and_entry Message-ID: <20080627130627.GC23431@lst.de> References: <20080502105803.GC17870@lst.de> <20080520063639.GC8869@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080520063639.GC8869@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: 1214571997 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.54487 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: 16622 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 Tue, May 20, 2008 at 08:36:39AM +0200, Christoph Hellwig wrote: > ping? > > On Fri, May 02, 2008 at 12:58:03PM +0200, Christoph Hellwig wrote: > > When multiple inodes are locked in XFS it happens in order of the inode > > number, with the everything but the first inode trylocked if any of > > the previous inodes is in the AIL. > > > > Except for the sorting of the inodes this logic is implemented in > > xfs_lock_inodes, but also partially duplicated in xfs_lock_dir_and_entry > > in a particularly stupid way adds a lock roundtrip if the inode ordering > > is not optimal. > > > > This patch adds a new helper xfs_lock_two_inodes that takes two inodes > > and locks them in the most optimal way according to the above locking > > protocol and uses it for all places that want to lock two inodes. > > > > The only caller of xfs_lock_inodes is xfs_rename which might lock up to > > four inodes. > > > > > > Signed-off-by: Christoph Hellwig > > > > Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-05-02 08:30:24.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-05-02 08:30:30.000000000 +0200 > > @@ -1897,111 +1897,6 @@ std_return: > > } > > > > #ifdef DEBUG > > -/* > > - * Some counters to see if (and how often) we are hitting some deadlock > > - * prevention code paths. > > - */ > > - > > -int xfs_rm_locks; > > -int xfs_rm_lock_delays; > > -int xfs_rm_attempts; > > -#endif > > - > > -/* > > - * The following routine will lock the inodes associated with the > > - * directory and the named entry in the directory. The locks are > > - * acquired in increasing inode number. > > - * > > - * If the entry is "..", then only the directory is locked. The > > - * vnode ref count will still include that from the .. entry in > > - * this case. > > - * > > - * There is a deadlock we need to worry about. If the locked directory is > > - * in the AIL, it might be blocking up the log. The next inode we lock > > - * could be already locked by another thread waiting for log space (e.g > > - * a permanent log reservation with a long running transaction (see > > - * xfs_itruncate_finish)). To solve this, we must check if the directory > > - * is in the ail and use lock_nowait. If we can't lock, we need to > > - * drop the inode lock on the directory and try again. xfs_iunlock will > > - * potentially push the tail if we were holding up the log. > > - */ > > -STATIC int > > -xfs_lock_dir_and_entry( > > - xfs_inode_t *dp, > > - xfs_inode_t *ip) /* inode of entry 'name' */ > > -{ > > - int attempts; > > - xfs_ino_t e_inum; > > - xfs_inode_t *ips[2]; > > - xfs_log_item_t *lp; > > - > > -#ifdef DEBUG > > - xfs_rm_locks++; > > -#endif > > - attempts = 0; > > - > > -again: > > - xfs_ilock(dp, XFS_ILOCK_EXCL | XFS_ILOCK_PARENT); > > - > > - e_inum = ip->i_ino; > > - > > - xfs_itrace_ref(ip); > > - > > - /* > > - * We want to lock in increasing inum. Since we've already > > - * acquired the lock on the directory, we may need to release > > - * if if the inum of the entry turns out to be less. > > - */ > > - if (e_inum > dp->i_ino) { > > - /* > > - * We are already in the right order, so just > > - * lock on the inode of the entry. > > - * We need to use nowait if dp is in the AIL. > > - */ > > - > > - lp = (xfs_log_item_t *)dp->i_itemp; > > - if (lp && (lp->li_flags & XFS_LI_IN_AIL)) { > > - if (!xfs_ilock_nowait(ip, XFS_ILOCK_EXCL)) { > > - attempts++; > > -#ifdef DEBUG > > - xfs_rm_attempts++; > > -#endif > > - > > - /* > > - * Unlock dp and try again. > > - * xfs_iunlock will try to push the tail > > - * if the inode is in the AIL. > > - */ > > - > > - xfs_iunlock(dp, XFS_ILOCK_EXCL); > > - > > - if ((attempts % 5) == 0) { > > - delay(1); /* Don't just spin the CPU */ > > -#ifdef DEBUG > > - xfs_rm_lock_delays++; > > -#endif > > - } > > - goto again; > > - } > > - } else { > > - xfs_ilock(ip, XFS_ILOCK_EXCL); > > - } > > - } else if (e_inum < dp->i_ino) { > > - xfs_iunlock(dp, XFS_ILOCK_EXCL); > > - > > - ips[0] = ip; > > - ips[1] = dp; > > - xfs_lock_inodes(ips, 2, XFS_ILOCK_EXCL); > > - } > > - /* else e_inum == dp->i_ino */ > > - /* This can happen if we're asked to lock /x/.. > > - * the entry is "..", which is also the parent directory. > > - */ > > - > > - return 0; > > -} > > - > > -#ifdef DEBUG > > int xfs_locked_n; > > int xfs_small_retries; > > int xfs_middle_retries; > > @@ -2135,6 +2030,45 @@ again: > > #endif > > } > > > > +void > > +xfs_lock_two_inodes( > > + xfs_inode_t *ip0, > > + xfs_inode_t *ip1, > > + uint lock_mode) > > +{ > > + xfs_inode_t *temp; > > + int attempts = 0; > > + xfs_log_item_t *lp; > > + > > + ASSERT(ip0->i_ino != ip1->i_ino); > > + > > + if (ip0->i_ino > ip1->i_ino) { > > + temp = ip0; > > + ip0 = ip1; > > + ip1 = temp; > > + } > > + > > + again: > > + xfs_ilock(ip0, xfs_lock_inumorder(lock_mode, 0)); > > + > > + /* > > + * If the first lock we have locked is in the AIL, we must TRY to get > > + * the second lock. If we can't get it, we must release the first one > > + * and try again. > > + */ > > + lp = (xfs_log_item_t *)ip0->i_itemp; > > + if (lp && (lp->li_flags & XFS_LI_IN_AIL)) { > > + if (!xfs_ilock_nowait(ip1, xfs_lock_inumorder(lock_mode, 1))) { > > + xfs_iunlock(ip0, lock_mode); > > + if ((++attempts % 5) == 0) > > + delay(1); /* Don't just spin the CPU */ > > + goto again; > > + } > > + } else { > > + xfs_ilock(ip1, xfs_lock_inumorder(lock_mode, 1)); > > + } > > +} > > + > > int > > xfs_remove( > > xfs_inode_t *dp, > > @@ -2210,9 +2144,7 @@ xfs_remove( > > goto out_trans_cancel; > > } > > > > - error = xfs_lock_dir_and_entry(dp, ip); > > - if (error) > > - goto out_trans_cancel; > > + xfs_lock_two_inodes(dp, ip, XFS_ILOCK_EXCL); > > > > /* > > * At this point, we've gotten both the directory and the entry > > @@ -2239,9 +2171,6 @@ xfs_remove( > > } > > } > > > > - /* > > - * Entry must exist since we did a lookup in xfs_lock_dir_and_entry. > > - */ > > XFS_BMAP_INIT(&free_list, &first_block); > > error = xfs_dir_removename(tp, dp, name, ip->i_ino, > > &first_block, &free_list, resblks); > > @@ -2347,7 +2276,6 @@ xfs_link( > > { > > xfs_mount_t *mp = tdp->i_mount; > > xfs_trans_t *tp; > > - xfs_inode_t *ips[2]; > > int error; > > xfs_bmap_free_t free_list; > > xfs_fsblock_t first_block; > > @@ -2395,15 +2323,7 @@ xfs_link( > > goto error_return; > > } > > > > - if (sip->i_ino < tdp->i_ino) { > > - ips[0] = sip; > > - ips[1] = tdp; > > - } else { > > - ips[0] = tdp; > > - ips[1] = sip; > > - } > > - > > - xfs_lock_inodes(ips, 2, XFS_ILOCK_EXCL); > > + xfs_lock_two_inodes(sip, tdp, XFS_ILOCK_EXCL); > > > > /* > > * Increment vnode ref counts since xfs_trans_commit & > > Index: linux-2.6-xfs/fs/xfs/xfs_dfrag.c > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/xfs_dfrag.c 2008-04-26 17:43:14.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/xfs_dfrag.c 2008-05-02 08:30:30.000000000 +0200 > > @@ -128,7 +128,6 @@ xfs_swap_extents( > > xfs_swapext_t *sxp) > > { > > xfs_mount_t *mp; > > - xfs_inode_t *ips[2]; > > xfs_trans_t *tp; > > xfs_bstat_t *sbp = &sxp->sx_stat; > > bhv_vnode_t *vp, *tvp; > > @@ -153,16 +152,7 @@ xfs_swap_extents( > > vp = XFS_ITOV(ip); > > tvp = XFS_ITOV(tip); > > > > - /* Lock in i_ino order */ > > - if (ip->i_ino < tip->i_ino) { > > - ips[0] = ip; > > - ips[1] = tip; > > - } else { > > - ips[0] = tip; > > - ips[1] = ip; > > - } > > - > > - xfs_lock_inodes(ips, 2, lock_flags); > > + xfs_lock_two_inodes(ip, tip, lock_flags); > > locked = 1; > > > > /* Verify that both files have the same format */ > > @@ -265,7 +255,7 @@ xfs_swap_extents( > > locked = 0; > > goto error0; > > } > > - xfs_lock_inodes(ips, 2, XFS_ILOCK_EXCL); > > + xfs_lock_two_inodes(ip, tip, XFS_ILOCK_EXCL); > > > > /* > > * Count the number of extended attribute blocks > > Index: linux-2.6-xfs/fs/xfs/xfs_inode.h > > =================================================================== > > --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2008-05-01 22:56:57.000000000 +0200 > > +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2008-05-02 08:30:30.000000000 +0200 > > @@ -522,6 +522,7 @@ void xfs_iflush_all(struct xfs_mount *) > > void xfs_ichgtime(xfs_inode_t *, int); > > xfs_fsize_t xfs_file_last_byte(xfs_inode_t *); > > void xfs_lock_inodes(xfs_inode_t **, int, uint); > > +void xfs_lock_two_inodes(xfs_inode_t *, xfs_inode_t *, uint); > > > > void xfs_synchronize_atime(xfs_inode_t *); > > void xfs_mark_inode_dirty_sync(xfs_inode_t *); > ---end quoted text--- ---end quoted text--- From owner-xfs@oss.sgi.com Fri Jun 27 06:10:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 06:10:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5RDAiQJ006395 for ; Fri, 27 Jun 2008 06:10:44 -0700 X-ASG-Debug-ID: 1214572304-62c603800000-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 1D8D1D66728 for ; Fri, 27 Jun 2008 06:11:45 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id l5sTPQUd4E6mBHkk for ; Fri, 27 Jun 2008 06:11:45 -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 m5RDBaNW023820 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Jun 2008 15:11:36 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5RDBaP3023818 for xfs@oss.sgi.com; Fri, 27 Jun 2008 15:11:36 +0200 Date: Fri, 27 Jun 2008 15:11:36 +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: <20080627131136.GD23431@lst.de> References: <20080518153539.GA5218@lst.de> <20080603080019.GB19608@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080603080019.GB19608@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: 1214572306 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.54487 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: 16623 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 Tue, Jun 03, 2008 at 10:00:19AM +0200, Christoph Hellwig wrote: > 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--- ---end quoted text--- From owner-xfs@oss.sgi.com Fri Jun 27 07:36:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 07:36:19 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,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 m5REaEtO015787 for ; Fri, 27 Jun 2008 07:36:14 -0700 X-ASG-Debug-ID: 1214577434-340d01e80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gateway-1237.mvista.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A7148183C661 for ; Fri, 27 Jun 2008 07:37:14 -0700 (PDT) Received: from gateway-1237.mvista.com (homer.mvista.com [63.81.120.158]) by cuda.sgi.com with ESMTP id oRoD0KyKvjZPPNMe for ; Fri, 27 Jun 2008 07:37:14 -0700 (PDT) Received: from [10.0.4.38] (dwalker.mvista.com [10.0.4.38]) by hermes.mvista.com (Postfix) with ESMTP id 727CA1820D; Fri, 27 Jun 2008 07:37:13 -0700 (PDT) X-ASG-Orig-Subj: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements Subject: Re: [PATCH 1/6] Extend completions to provide XFS object flush requirements From: Daniel Walker To: Christoph Hellwig Cc: Matthew Wilcox , Dave Chinner , xfs@oss.sgi.com, linux-kernel@vger.kernel.org In-Reply-To: <20080627091509.GA31148@infradead.org> References: <1214455277-6387-1-git-send-email-david@fromorbit.com> <1214455277-6387-2-git-send-email-david@fromorbit.com> <1214512405.21035.110.camel@localhost.localdomain> <20080627022407.GB7703@parisc-linux.org> <1214537199.21035.179.camel@localhost.localdomain> <20080627091509.GA31148@infradead.org> Content-Type: text/plain Date: Fri, 27 Jun 2008 07:37:12 -0700 Message-Id: <1214577432.21035.181.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-Barracuda-Connect: homer.mvista.com[63.81.120.158] X-Barracuda-Start-Time: 1214577435 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.54492 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: 16624 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dwalker@mvista.com Precedence: bulk X-list: xfs On Fri, 2008-06-27 at 05:15 -0400, Christoph Hellwig wrote: > On Thu, Jun 26, 2008 at 08:26:39PM -0700, Daniel Walker wrote: > > Are you saying you want to keep semaphores? Cause I think that goes > > against the overall agenda that I've seen, > > Which overall agenda? Semaphore removal .. Daniel From owner-xfs@oss.sgi.com Fri Jun 27 07:48:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 07:48:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5REmgeh017328 for ; Fri, 27 Jun 2008 07:48:42 -0700 X-ASG-Debug-ID: 1214578182-26a003640000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 87AA2292C63 for ; Fri, 27 Jun 2008 07:49:43 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id ppC2yX5iiJDWDbSb for ; Fri, 27 Jun 2008 07:49:43 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 1E94FA81F3B; Fri, 27 Jun 2008 09:49:42 -0500 (CDT) Message-ID: <4864FE05.9000706@sandeen.net> Date: Fri, 27 Jun 2008 09:49:41 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] fix mount option parsing in remount Subject: Re: [PATCH] fix mount option parsing in remount References: <20080518153539.GA5218@lst.de> <20080603080019.GB19608@lst.de> <20080627131136.GD23431@lst.de> In-Reply-To: <20080627131136.GD23431@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214578183 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.54494 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: 16625 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Christoph Hellwig wrote: > ping^2 > > On Tue, Jun 03, 2008 at 10:00:19AM +0200, Christoph Hellwig wrote: >> 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? I sorta reviewed it earlier but I'll give it my formal ACK. -Eric From owner-xfs@oss.sgi.com Fri Jun 27 08:24:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 08:24:35 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64, J_CHICKENPOX_66 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 m5RFOUEO026015 for ; Fri, 27 Jun 2008 08:24:31 -0700 X-ASG-Debug-ID: 1214580327-5475008a0000-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 7E021D68825 for ; Fri, 27 Jun 2008 08:25:27 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 8ER0jGAWWBdoKQot for ; Fri, 27 Jun 2008 08:25: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 m5RFPGNW030680 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Jun 2008 17:25:16 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5RFPGIY030678 for xfs@oss.sgi.com; Fri, 27 Jun 2008 17:25:16 +0200 Date: Fri, 27 Jun 2008 17:25:15 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] use generic posix ACL code, enable ACL caching Subject: Re: [PATCH] use generic posix ACL code, enable ACL caching Message-ID: <20080627152515.GB30216@lst.de> References: <20080614160127.GA15404@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080614160127.GA15404@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: 1214580329 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54495 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16626 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Sat, Jun 14, 2008 at 06:01:27PM +0200, Christoph Hellwig wrote: > Switch XFS to use the generic ACL code and enable caching the ACL values > in the XFS inode. > > Compared to the last post various bugs have been fixed and a locking > strategy has been designed and implemented. This now passes XFSQA. > > You'll need my various attr-related patches applies before this one. The required attr patches are in now, but needed a fix for which I had to rediff this patch. Updated version below: Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c =================================================================== --- /dev/null 1970-01-01 00:00:00.000000000 +0000 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c 2008-06-27 16:56:52.000000000 +0200 @@ -0,0 +1,517 @@ +/* + * Copyright (C) 2008 Christoph Hellwig. + * Released under GPL v2. + */ +#include "xfs.h" +#include "xfs_acl.h" +#include "xfs_attr.h" +#include "xfs_bmap_btree.h" +#include "xfs_inode.h" +#include "xfs_vnodeops.h" +#include +#include + + +#define XFS_ACL_NOT_CACHED ((void *)-1) + +/* + * Locking scheme: + * - all ACL updates are protected by inode->i_mutex, which is taken before + * calling into this file. + * - access and updates to the ip->i_acl and ip->i_default_acl pointers are + * protected by inode->i_lock. + */ + +static struct posix_acl * +xfs_acl_from_disk(struct xfs_acl *aclp) +{ + struct posix_acl_entry *acl_e; + struct posix_acl *acl; + struct xfs_acl_entry *ace; + int count, i; + + count = be32_to_cpu(aclp->acl_cnt); + + acl = posix_acl_alloc(count, GFP_KERNEL); + if (!acl) + return ERR_PTR(-ENOMEM); + + for (i = 0; i < count; i++) { + acl_e = &acl->a_entries[i]; + ace = &aclp->acl_entry[i]; + + /* + * The tag is 32 bits on disk and 16 bits in core. + * + * Because every access to it goes through the core + * format first this is not a problem. + */ + acl_e->e_tag = be32_to_cpu(ace->ae_tag); + acl_e->e_perm = be16_to_cpu(ace->ae_perm); + + switch (acl_e->e_tag) { + case ACL_USER: + case ACL_GROUP: + acl_e->e_id = be32_to_cpu(ace->ae_id); + break; + case ACL_USER_OBJ: + case ACL_GROUP_OBJ: + case ACL_MASK: + case ACL_OTHER: + acl_e->e_id = ACL_UNDEFINED_ID; + break; + default: + goto fail; + } + } + return acl; + +fail: + posix_acl_release(acl); + return ERR_PTR(-EINVAL); +} + +static void +xfs_acl_to_disk(struct xfs_acl *aclp, const struct posix_acl *acl) +{ + const struct posix_acl_entry *acl_e; + struct xfs_acl_entry *ace; + int i; + + aclp->acl_cnt = cpu_to_be32(acl->a_count); + for (i = 0; i < acl->a_count; i++) { + ace = &aclp->acl_entry[i]; + acl_e = &acl->a_entries[i]; + + ace->ae_tag = cpu_to_be32(acl_e->e_tag); + ace->ae_id = cpu_to_be32(acl_e->e_id); + ace->ae_perm = cpu_to_be16(acl_e->e_perm); + } +} + +/* + * Update the cached ACL pointer in the inode. + * + * Because we don't hold any locks while reading/writing the attribute + * from/to disk another thread could have raced and updated the cached + * ACL value before us. In that case we release the previous cached value + * and update it with our new value. + */ +static void +xfs_update_cached_acl(struct inode *inode, struct posix_acl **p_acl, + struct posix_acl *acl) +{ + spin_lock(&inode->i_lock); + if (*p_acl && *p_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(*p_acl); + *p_acl = posix_acl_dup(acl); + spin_unlock(&inode->i_lock); +} + +struct posix_acl * +xfs_get_acl(struct inode *inode, int type) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl *acl = NULL, **p_acl; + struct xfs_acl *xfs_acl; + int len = sizeof(struct xfs_acl); + char *ea_name; + int error; + + switch (type) { + case ACL_TYPE_ACCESS: + ea_name = SGI_ACL_FILE; + p_acl = &ip->i_acl; + break; + case ACL_TYPE_DEFAULT: + ea_name = SGI_ACL_DEFAULT; + p_acl = &ip->i_default_acl; + break; + default: + return ERR_PTR(-EINVAL); + } + + spin_lock(&inode->i_lock); + if (*p_acl != XFS_ACL_NOT_CACHED) + acl = posix_acl_dup(*p_acl); + spin_unlock(&inode->i_lock); + + /* + * If we have a cached ACLs value just return it, not need to + * go out to the disk. + */ + if (acl) + return acl; + + xfs_acl = kzalloc(sizeof(struct xfs_acl), GFP_KERNEL); + if (!xfs_acl) + return ERR_PTR(-ENOMEM); + + error = -xfs_attr_get(ip, ea_name, (char *)xfs_acl, &len, ATTR_ROOT); + if (error) { + /* + * If the attribute doesn't exist make sure we have a negative + * cache entry, for any other error assume it is transient and + * leave the cache entry as XFS_ACL_NOT_CACHED. + */ + if (error == -ENOATTR) { + acl = NULL; + goto out_update_cache; + } + goto out; + } + + acl = xfs_acl_from_disk(xfs_acl); + if (IS_ERR(acl)) + goto out; + + out_update_cache: + xfs_update_cached_acl(inode, p_acl, acl); + out: + kfree(xfs_acl); + return acl; +} + +static int +xfs_set_acl(struct inode *inode, int type, struct posix_acl *acl) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl **p_acl; + char *ea_name; + int error; + + if (S_ISLNK(inode->i_mode)) + return -EOPNOTSUPP; + + switch (type) { + case ACL_TYPE_ACCESS: + ea_name = SGI_ACL_FILE; + p_acl = &ip->i_acl; + break; + case ACL_TYPE_DEFAULT: + if (!S_ISDIR(inode->i_mode)) + return acl ? -EACCES : 0; + ea_name = SGI_ACL_DEFAULT; + p_acl = &ip->i_default_acl; + break; + default: + return -EINVAL; + } + + if (acl) { + struct xfs_acl *xfs_acl; + int len; + + xfs_acl = kzalloc(sizeof(struct xfs_acl), GFP_KERNEL); + if (!xfs_acl) + return -ENOMEM; + + xfs_acl_to_disk(xfs_acl, acl); + len = sizeof(struct xfs_acl) - + (sizeof(struct xfs_acl_entry) * + (XFS_ACL_MAX_ENTRIES - acl->a_count)); + + error = -xfs_attr_set(ip, ea_name, (char *)xfs_acl, + len, ATTR_ROOT); + + kfree(xfs_acl); + } else { + /* + * A NULL ACL argument means we want to remove the ACL. + */ + error = -xfs_attr_remove(ip, ea_name, ATTR_ROOT); + + /* + * If the attribute didn't exist to start with that's fine. + */ + if (error == -ENOATTR) + error = 0; + } + + if (!error) + xfs_update_cached_acl(inode, p_acl, acl); + return error; +} + +static int +xfs_check_acl(struct inode *inode, int mask) +{ + struct xfs_inode *ip = XFS_I(inode); + struct posix_acl *acl; + int error = -EAGAIN; + + xfs_itrace_entry(ip); + + /* + * If there is no attribute fork no ACL exists on this inode and + * we can skip the whole exercise. + */ + if (!XFS_IFORK_Q(ip)) + return -EAGAIN; + + acl = xfs_get_acl(inode, ACL_TYPE_ACCESS); + if (IS_ERR(acl)) + return PTR_ERR(acl); + if (acl) { + error = posix_acl_permission(inode, acl, mask); + posix_acl_release(acl); + } + + return error; +} + +int +xfs_vn_permission(struct inode *inode, int mask, struct nameidata *nd) +{ + return generic_permission(inode, mask, xfs_check_acl); +} + +static int +xfs_set_mode(struct inode *inode, mode_t mode) +{ + int error = 0; + + if (mode != inode->i_mode) { + struct bhv_vattr va; + + va.va_mask = XFS_AT_MODE; + va.va_mode = mode; + + error = -xfs_setattr(XFS_I(inode), &va, 0, sys_cred); + inode->i_mode = mode; + } + + return error; +} + +static int +xfs_acl_exists(struct inode *inode, char *name) +{ + int len = sizeof(struct xfs_acl); + + return (xfs_attr_get(XFS_I(inode), name, NULL, &len, + ATTR_ROOT|ATTR_KERNOVAL) == 0); +} + +int +posix_acl_access_exists(struct inode *inode) +{ + return xfs_acl_exists(inode, SGI_ACL_FILE); +} + +int +posix_acl_default_exists(struct inode *inode) +{ + if (!S_ISDIR(inode->i_mode)) + return 0; + return xfs_acl_exists(inode, SGI_ACL_DEFAULT); +} + +/* + * No need for i_mutex because the inode is not yet exposed to the VFS. + */ +int +xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl) +{ + struct posix_acl *clone; + mode_t mode; + int error = 0, inherit = 0; + + if (S_ISDIR(inode->i_mode)) { + error = xfs_set_acl(inode, ACL_TYPE_DEFAULT, default_acl); + if (error) + return error; + } + + clone = posix_acl_clone(default_acl, GFP_KERNEL); + if (!clone) + return -ENOMEM; + + mode = inode->i_mode; + error = posix_acl_create_masq(clone, &mode); + if (error < 0) + goto out_release_clone; + + /* + * If posix_acl_create_masq returns a positive value we need to + * inherit a permission that can't be represented using the Unix + * mode bits and we actually need to set an ACL. + */ + if (error > 0) + inherit = 1; + + error = xfs_set_mode(inode, mode); + if (error) + goto out_release_clone; + + if (inherit) + error = xfs_set_acl(inode, ACL_TYPE_ACCESS, clone); + + out_release_clone: + posix_acl_release(clone); + return error; +} + +int +xfs_acl_chmod(struct inode *inode) +{ + struct posix_acl *acl, *clone; + int error; + + if (S_ISLNK(inode->i_mode)) + return -EOPNOTSUPP; + + acl = xfs_get_acl(inode, ACL_TYPE_ACCESS); + if (IS_ERR(acl) || !acl) + return PTR_ERR(acl); + + clone = posix_acl_clone(acl, GFP_KERNEL); + posix_acl_release(acl); + if (!clone) + return -ENOMEM; + + error = posix_acl_chmod_masq(clone, inode->i_mode); + if (!error) + error = xfs_set_acl(inode, ACL_TYPE_ACCESS, clone); + + posix_acl_release(clone); + return error; +} + +void +xfs_inode_init_acls(struct xfs_inode *ip) +{ + /* + * No need for locking, inode is not live yet. + */ + ip->i_acl = XFS_ACL_NOT_CACHED; + ip->i_default_acl = XFS_ACL_NOT_CACHED; +} + +void +xfs_inode_clear_acls(struct xfs_inode *ip) +{ + /* + * No need for locking here, the inode is not live anymore + * and just about to be freed. + */ + if (ip->i_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(ip->i_acl); + if (ip->i_default_acl != XFS_ACL_NOT_CACHED) + posix_acl_release(ip->i_default_acl); +} + + +/* + * System xattr handlers. + * + * Currently Posix ACLs are the only system namespace extended attribute + * handlers supported by XFS, so we just implement the handlers here. + * If we ever support other system extended attributes this will need + * some refactoring. + */ + +static int +xfs_decode_acl(const char *name) +{ + if (strcmp(name, "posix_acl_access") == 0) + return ACL_TYPE_ACCESS; + else if (strcmp(name, "posix_acl_default") == 0) + return ACL_TYPE_DEFAULT; + return -EINVAL; +} + +static int +xfs_xattr_system_get(struct inode *inode, const char *name, + void *value, size_t size) +{ + struct posix_acl *acl; + int type, error; + + type = xfs_decode_acl(name); + if (type < 0) + return type; + + acl = xfs_get_acl(inode, type); + if (IS_ERR(acl)) + return PTR_ERR(acl); + if (acl == NULL) + return -ENODATA; + + error = posix_acl_to_xattr(acl, value, size); + posix_acl_release(acl); + + return error; +} + +static int +xfs_xattr_system_set(struct inode *inode, const char *name, + const void *value, size_t size, int flags) +{ + struct posix_acl *acl = NULL; + int error = 0, type; + + type = xfs_decode_acl(name); + if (type < 0) + return type; + if (flags & XATTR_CREATE) + return -EINVAL; + if (type == ACL_TYPE_DEFAULT && !S_ISDIR(inode->i_mode)) + return value ? -EACCES : 0; + if ((current->fsuid != inode->i_uid) && !capable(CAP_FOWNER)) + return -EPERM; + + if (!value) + goto set_acl; + + acl = posix_acl_from_xattr(value, size); + if (!acl) { + /* + * acl_set_file(3) may request that we set default ACLs with + * zero length -- defend (gracefully) against that here. + */ + goto out; + } + if (IS_ERR(acl)) { + error = PTR_ERR(acl); + goto out; + } + + error = posix_acl_valid(acl); + if (error) + goto out_release; + + error = -EINVAL; + if (acl->a_count > XFS_ACL_MAX_ENTRIES) + goto out_release; + + if (type == ACL_TYPE_ACCESS) { + mode_t mode = inode->i_mode; + error = posix_acl_equiv_mode(acl, &mode); + + if (error <= 0) { + posix_acl_release(acl); + acl = NULL; + + if (error < 0) + return error; + } + + error = xfs_set_mode(inode, mode); + if (error) + goto out_release; + } + + set_acl: + error = xfs_set_acl(inode, type, acl); + out_release: + posix_acl_release(acl); + out: + return error; +} + +struct xattr_handler xfs_xattr_system_handler = { + .prefix = XATTR_SYSTEM_PREFIX, + .get = xfs_xattr_system_get, + .set = xfs_xattr_system_set, +}; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-27 16:56:52.000000000 +0200 @@ -51,6 +51,7 @@ #include #include #include +#include #include #include @@ -259,9 +260,8 @@ xfs_vn_mknod( { struct inode *inode; struct xfs_inode *ip = NULL; - xfs_acl_t *default_acl = NULL; + struct posix_acl *default_acl = NULL; struct xfs_name name; - int (*test_default_acl)(struct inode *) = _ACL_DEFAULT_EXISTS; int error; /* @@ -271,21 +271,17 @@ xfs_vn_mknod( if (unlikely(!sysv_valid_dev(rdev) || MAJOR(rdev) & ~0x1ff)) return -EINVAL; - if (test_default_acl && test_default_acl(dir)) { - if (!_ACL_ALLOC(default_acl)) { - return -ENOMEM; - } - if (!_ACL_GET_DEFAULT(dir, default_acl)) { - _ACL_FREE(default_acl); - default_acl = NULL; - } + if (IS_POSIXACL(dir)) { + default_acl = xfs_get_acl(dir, ACL_TYPE_DEFAULT); + if (IS_ERR(default_acl)) + return -PTR_ERR(default_acl); + + if (!default_acl) + mode &= ~current->fs->umask; } xfs_dentry_to_name(&name, dentry); - if (IS_POSIXACL(dir) && !default_acl) - mode &= ~current->fs->umask; - switch (mode & S_IFMT) { case S_IFCHR: case S_IFBLK: @@ -313,11 +309,11 @@ xfs_vn_mknod( goto out_cleanup_inode; if (default_acl) { - error = _ACL_INHERIT(inode, mode, default_acl); + error = -xfs_inherit_acl(inode, default_acl); if (unlikely(error)) goto out_cleanup_inode; xfs_iflags_set(ip, XFS_IMODIFIED); - _ACL_FREE(default_acl); + posix_acl_release(default_acl); } @@ -327,8 +323,7 @@ xfs_vn_mknod( out_cleanup_inode: xfs_cleanup_inode(dir, inode, dentry); out_free_acl: - if (default_acl) - _ACL_FREE(default_acl); + posix_acl_release(default_acl); return -error; } @@ -562,38 +557,6 @@ xfs_vn_put_link( kfree(s); } -#ifdef CONFIG_XFS_POSIX_ACL -STATIC int -xfs_check_acl( - struct inode *inode, - int mask) -{ - struct xfs_inode *ip = XFS_I(inode); - int error; - - xfs_itrace_entry(ip); - - if (XFS_IFORK_Q(ip)) { - error = xfs_acl_iaccess(ip, mask, NULL); - if (error != -1) - return -error; - } - - return -EAGAIN; -} - -STATIC int -xfs_vn_permission( - struct inode *inode, - int mask, - struct nameidata *nd) -{ - return generic_permission(inode, mask, xfs_check_acl); -} -#else -#define xfs_vn_permission NULL -#endif - STATIC int xfs_vn_getattr( struct vfsmount *mnt, @@ -706,6 +669,9 @@ xfs_vn_setattr( error = xfs_setattr(XFS_I(inode), &vattr, flags, NULL); if (likely(!error)) vn_revalidate(vn_from_inode(inode)); + + if (!error && (attr->ia_valid & ATTR_MODE)) + error = -xfs_acl_chmod(inode); return -error; } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.h 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.h 2008-06-27 16:56:52.000000000 +0200 @@ -29,6 +29,12 @@ extern void xfs_ichgtime_fast(struct xfs extern void xfs_setup_inode(struct xfs_inode *); +#ifdef CONFIG_XFS_POSIX_ACL +int xfs_vn_permission(struct inode *inode, int mask, struct nameidata *nd); +#else +#define xfs_vn_permission NULL +#endif + #define xfs_vtoi(vp) \ ((struct xfs_inode *)vn_to_inode(vp)->i_private) Index: linux-2.6-xfs/fs/xfs/xfs_acl.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.h 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.h 2008-06-27 16:56:52.000000000 +0200 @@ -18,82 +18,84 @@ #ifndef __XFS_ACL_H__ #define __XFS_ACL_H__ -/* - * Access Control Lists - */ -typedef __uint16_t xfs_acl_perm_t; -typedef __int32_t xfs_acl_type_t; -typedef __int32_t xfs_acl_tag_t; -typedef __int32_t xfs_acl_id_t; +struct inode; +struct posix_acl; +struct xfs_inode; + #define XFS_ACL_MAX_ENTRIES 25 #define XFS_ACL_NOT_PRESENT (-1) -typedef struct xfs_acl_entry { - xfs_acl_tag_t ae_tag; - xfs_acl_id_t ae_id; - xfs_acl_perm_t ae_perm; -} xfs_acl_entry_t; - -typedef struct xfs_acl { - __int32_t acl_cnt; - xfs_acl_entry_t acl_entry[XFS_ACL_MAX_ENTRIES]; -} xfs_acl_t; +struct xfs_acl { + __be32 acl_cnt; + struct xfs_acl_entry { + __be32 ae_tag; + __be32 ae_id; + __be16 ae_perm; + } acl_entry[XFS_ACL_MAX_ENTRIES]; +}; /* On-disk XFS extended attribute names */ -#define SGI_ACL_FILE "SGI_ACL_FILE" -#define SGI_ACL_DEFAULT "SGI_ACL_DEFAULT" +#define SGI_ACL_FILE "SGI_ACL_FILE" +#define SGI_ACL_DEFAULT "SGI_ACL_DEFAULT" #define SGI_ACL_FILE_SIZE (sizeof(SGI_ACL_FILE)-1) #define SGI_ACL_DEFAULT_SIZE (sizeof(SGI_ACL_DEFAULT)-1) -#define _ACL_TYPE_ACCESS 1 -#define _ACL_TYPE_DEFAULT 2 #ifdef CONFIG_XFS_POSIX_ACL -struct vattr; -struct xfs_inode; - -extern struct kmem_zone *xfs_acl_zone; -#define xfs_acl_zone_init(zone, name) \ - (zone) = kmem_zone_init(sizeof(xfs_acl_t), (name)) -#define xfs_acl_zone_destroy(zone) kmem_zone_destroy(zone) - -extern int xfs_acl_inherit(bhv_vnode_t *, mode_t mode, xfs_acl_t *); -extern int xfs_acl_iaccess(struct xfs_inode *, mode_t, cred_t *); -extern int xfs_acl_vtoacl(bhv_vnode_t *, xfs_acl_t *, xfs_acl_t *); -extern int xfs_acl_vhasacl_access(bhv_vnode_t *); -extern int xfs_acl_vhasacl_default(bhv_vnode_t *); -extern int xfs_acl_vset(bhv_vnode_t *, void *, size_t, int); -extern int xfs_acl_vget(bhv_vnode_t *, void *, size_t, int); -extern int xfs_acl_vremove(bhv_vnode_t *, int); - -#define _ACL_PERM_INVALID(perm) ((perm) & ~(ACL_READ|ACL_WRITE|ACL_EXECUTE)) - -#define _ACL_INHERIT(c,m,d) (xfs_acl_inherit(c,m,d)) -#define _ACL_GET_ACCESS(pv,pa) (xfs_acl_vtoacl(pv,pa,NULL) == 0) -#define _ACL_GET_DEFAULT(pv,pd) (xfs_acl_vtoacl(pv,NULL,pd) == 0) -#define _ACL_ACCESS_EXISTS xfs_acl_vhasacl_access -#define _ACL_DEFAULT_EXISTS xfs_acl_vhasacl_default +struct posix_acl *xfs_get_acl(struct inode *inode, int type); +int xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl); +int xfs_acl_chmod(struct inode *inode); +void xfs_inode_init_acls(struct xfs_inode *ip); +void xfs_inode_clear_acls(struct xfs_inode *ip); +int posix_acl_access_exists(struct inode *inode); +int posix_acl_default_exists(struct inode *inode); -#define _ACL_ALLOC(a) ((a) = kmem_zone_alloc(xfs_acl_zone, KM_SLEEP)) -#define _ACL_FREE(a) ((a)? kmem_zone_free(xfs_acl_zone, (a)):(void)0) +extern struct xattr_handler xfs_xattr_system_handler; #else -#define xfs_acl_zone_init(zone,name) -#define xfs_acl_zone_destroy(zone) -#define xfs_acl_vset(v,p,sz,t) (-EOPNOTSUPP) -#define xfs_acl_vget(v,p,sz,t) (-EOPNOTSUPP) -#define xfs_acl_vremove(v,t) (-EOPNOTSUPP) -#define xfs_acl_vhasacl_access(v) (0) -#define xfs_acl_vhasacl_default(v) (0) -#define _ACL_ALLOC(a) (1) /* successfully allocate nothing */ -#define _ACL_FREE(a) ((void)0) -#define _ACL_INHERIT(c,m,d) (0) -#define _ACL_GET_ACCESS(pv,pa) (0) -#define _ACL_GET_DEFAULT(pv,pd) (0) -#define _ACL_ACCESS_EXISTS (NULL) -#define _ACL_DEFAULT_EXISTS (NULL) -#endif +static inline struct posix_acl * +xfs_get_acl(struct inode *inode, int type) +{ + BUG(); + return NULL; +} + +static inline int +xfs_inherit_acl(struct inode *inode, struct posix_acl *default_acl) +{ + BUG(); + return 0; +} + +static inline int +xfs_acl_chmod(struct inode *inode) +{ + return 0; +} + +static inline void +xfs_inode_init_acls(struct xfs_inode *ip) +{ +} + +static inline void +xfs_inode_clear_acls(struct xfs_inode *ip) +{ +} + +static inline int +posix_acl_access_exists(struct inode *inode) +{ + return 0; +} + +static inline int +posix_acl_default_exists(struct inode *inode) +{ + return 0; +} +#endif /* CONFIG_XFS_POSIX_ACL */ #endif /* __XFS_ACL_H__ */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-27 16:56:52.000000000 +0200 @@ -51,7 +51,6 @@ #include "xfs_dir2_block.h" #include "xfs_dir2_node.h" #include "xfs_dir2_trace.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_attr_leaf.h" #include "xfs_inode_item.h" @@ -179,10 +178,6 @@ EXPORT_SYMBOL(uuid_table_remove); EXPORT_SYMBOL(vn_hold); EXPORT_SYMBOL(vn_revalidate); -#if defined(CONFIG_XFS_POSIX_ACL) -EXPORT_SYMBOL(xfs_acl_vtoacl); -EXPORT_SYMBOL(xfs_acl_inherit); -#endif EXPORT_SYMBOL(xfs_alloc_buftarg); EXPORT_SYMBOL(xfs_flush_buftarg); EXPORT_SYMBOL(xfs_free_buftarg); Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-06-27 15:15:46.000000000 +0200 +++ /dev/null 1970-01-01 00:00:00.000000000 +0000 @@ -1,881 +0,0 @@ -/* - * Copyright (c) 2001-2002,2005 Silicon Graphics, Inc. - * All Rights Reserved. - * - * This program is free software; you can redistribute it and/or - * modify it under the terms of the GNU General Public License as - * published by the Free Software Foundation. - * - * This program is distributed in the hope that it would be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write the Free Software Foundation, - * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA - */ -#include "xfs.h" -#include "xfs_fs.h" -#include "xfs_types.h" -#include "xfs_bit.h" -#include "xfs_inum.h" -#include "xfs_ag.h" -#include "xfs_dir2.h" -#include "xfs_bmap_btree.h" -#include "xfs_alloc_btree.h" -#include "xfs_ialloc_btree.h" -#include "xfs_dir2_sf.h" -#include "xfs_attr_sf.h" -#include "xfs_dinode.h" -#include "xfs_inode.h" -#include "xfs_btree.h" -#include "xfs_acl.h" -#include "xfs_attr.h" -#include "xfs_vnodeops.h" - -#include -#include - -STATIC int xfs_acl_setmode(bhv_vnode_t *, xfs_acl_t *, int *); -STATIC void xfs_acl_filter_mode(mode_t, xfs_acl_t *); -STATIC void xfs_acl_get_endian(xfs_acl_t *); -STATIC int xfs_acl_access(uid_t, gid_t, xfs_acl_t *, mode_t, cred_t *); -STATIC int xfs_acl_invalid(xfs_acl_t *); -STATIC void xfs_acl_sync_mode(mode_t, xfs_acl_t *); -STATIC void xfs_acl_get_attr(bhv_vnode_t *, xfs_acl_t *, int, int, int *); -STATIC void xfs_acl_set_attr(bhv_vnode_t *, xfs_acl_t *, int, int *); -STATIC int xfs_acl_allow_set(bhv_vnode_t *, int); - -kmem_zone_t *xfs_acl_zone; - - -/* - * Test for existence of access ACL attribute as efficiently as possible. - */ -int -xfs_acl_vhasacl_access( - bhv_vnode_t *vp) -{ - int error; - - xfs_acl_get_attr(vp, NULL, _ACL_TYPE_ACCESS, ATTR_KERNOVAL, &error); - return (error == 0); -} - -/* - * Test for existence of default ACL attribute as efficiently as possible. - */ -int -xfs_acl_vhasacl_default( - bhv_vnode_t *vp) -{ - int error; - - if (!S_ISDIR(vp->i_mode)) - return 0; - xfs_acl_get_attr(vp, NULL, _ACL_TYPE_DEFAULT, ATTR_KERNOVAL, &error); - return (error == 0); -} - -/* - * Convert from extended attribute representation to in-memory for XFS. - */ -STATIC int -posix_acl_xattr_to_xfs( - posix_acl_xattr_header *src, - size_t size, - xfs_acl_t *dest) -{ - posix_acl_xattr_entry *src_entry; - xfs_acl_entry_t *dest_entry; - int n; - - if (!src || !dest) - return EINVAL; - - if (size < sizeof(posix_acl_xattr_header)) - return EINVAL; - - if (src->a_version != cpu_to_le32(POSIX_ACL_XATTR_VERSION)) - return EOPNOTSUPP; - - memset(dest, 0, sizeof(xfs_acl_t)); - dest->acl_cnt = posix_acl_xattr_count(size); - if (dest->acl_cnt < 0 || dest->acl_cnt > XFS_ACL_MAX_ENTRIES) - return EINVAL; - - /* - * acl_set_file(3) may request that we set default ACLs with - * zero length -- defend (gracefully) against that here. - */ - if (!dest->acl_cnt) - return 0; - - src_entry = (posix_acl_xattr_entry *)((char *)src + sizeof(*src)); - dest_entry = &dest->acl_entry[0]; - - for (n = 0; n < dest->acl_cnt; n++, src_entry++, dest_entry++) { - dest_entry->ae_perm = le16_to_cpu(src_entry->e_perm); - if (_ACL_PERM_INVALID(dest_entry->ae_perm)) - return EINVAL; - dest_entry->ae_tag = le16_to_cpu(src_entry->e_tag); - switch(dest_entry->ae_tag) { - case ACL_USER: - case ACL_GROUP: - dest_entry->ae_id = le32_to_cpu(src_entry->e_id); - break; - case ACL_USER_OBJ: - case ACL_GROUP_OBJ: - case ACL_MASK: - case ACL_OTHER: - dest_entry->ae_id = ACL_UNDEFINED_ID; - break; - default: - return EINVAL; - } - } - if (xfs_acl_invalid(dest)) - return EINVAL; - - return 0; -} - -/* - * Comparison function called from xfs_sort(). - * Primary key is ae_tag, secondary key is ae_id. - */ -STATIC int -xfs_acl_entry_compare( - const void *va, - const void *vb) -{ - xfs_acl_entry_t *a = (xfs_acl_entry_t *)va, - *b = (xfs_acl_entry_t *)vb; - - if (a->ae_tag == b->ae_tag) - return (a->ae_id - b->ae_id); - return (a->ae_tag - b->ae_tag); -} - -/* - * Convert from in-memory XFS to extended attribute representation. - */ -STATIC int -posix_acl_xfs_to_xattr( - xfs_acl_t *src, - posix_acl_xattr_header *dest, - size_t size) -{ - int n; - size_t new_size = posix_acl_xattr_size(src->acl_cnt); - posix_acl_xattr_entry *dest_entry; - xfs_acl_entry_t *src_entry; - - if (size < new_size) - return -ERANGE; - - /* Need to sort src XFS ACL by */ - xfs_sort(src->acl_entry, src->acl_cnt, sizeof(src->acl_entry[0]), - xfs_acl_entry_compare); - - dest->a_version = cpu_to_le32(POSIX_ACL_XATTR_VERSION); - dest_entry = &dest->a_entries[0]; - src_entry = &src->acl_entry[0]; - for (n = 0; n < src->acl_cnt; n++, dest_entry++, src_entry++) { - dest_entry->e_perm = cpu_to_le16(src_entry->ae_perm); - if (_ACL_PERM_INVALID(src_entry->ae_perm)) - return -EINVAL; - dest_entry->e_tag = cpu_to_le16(src_entry->ae_tag); - switch (src_entry->ae_tag) { - case ACL_USER: - case ACL_GROUP: - dest_entry->e_id = cpu_to_le32(src_entry->ae_id); - break; - case ACL_USER_OBJ: - case ACL_GROUP_OBJ: - case ACL_MASK: - case ACL_OTHER: - dest_entry->e_id = cpu_to_le32(ACL_UNDEFINED_ID); - break; - default: - return -EINVAL; - } - } - return new_size; -} - -int -xfs_acl_vget( - bhv_vnode_t *vp, - void *acl, - size_t size, - int kind) -{ - int error; - xfs_acl_t *xfs_acl = NULL; - posix_acl_xattr_header *ext_acl = acl; - int flags = 0; - - VN_HOLD(vp); - if(size) { - if (!(_ACL_ALLOC(xfs_acl))) { - error = ENOMEM; - goto out; - } - memset(xfs_acl, 0, sizeof(xfs_acl_t)); - } else - flags = ATTR_KERNOVAL; - - xfs_acl_get_attr(vp, xfs_acl, kind, flags, &error); - if (error) - goto out; - - if (!size) { - error = -posix_acl_xattr_size(XFS_ACL_MAX_ENTRIES); - } else { - if (xfs_acl_invalid(xfs_acl)) { - error = EINVAL; - goto out; - } - if (kind == _ACL_TYPE_ACCESS) - xfs_acl_sync_mode(xfs_vtoi(vp)->i_d.di_mode, xfs_acl); - error = -posix_acl_xfs_to_xattr(xfs_acl, ext_acl, size); - } -out: - VN_RELE(vp); - if(xfs_acl) - _ACL_FREE(xfs_acl); - return -error; -} - -int -xfs_acl_vremove( - bhv_vnode_t *vp, - int kind) -{ - int error; - - VN_HOLD(vp); - error = xfs_acl_allow_set(vp, kind); - if (!error) { - error = xfs_attr_remove(xfs_vtoi(vp), - kind == _ACL_TYPE_DEFAULT? - SGI_ACL_DEFAULT: SGI_ACL_FILE, - ATTR_ROOT); - if (error == ENOATTR) - error = 0; /* 'scool */ - } - VN_RELE(vp); - return -error; -} - -int -xfs_acl_vset( - bhv_vnode_t *vp, - void *acl, - size_t size, - int kind) -{ - posix_acl_xattr_header *ext_acl = acl; - xfs_acl_t *xfs_acl; - int error; - int basicperms = 0; /* more than std unix perms? */ - - if (!acl) - return -EINVAL; - - if (!(_ACL_ALLOC(xfs_acl))) - return -ENOMEM; - - error = posix_acl_xattr_to_xfs(ext_acl, size, xfs_acl); - if (error) { - _ACL_FREE(xfs_acl); - return -error; - } - if (!xfs_acl->acl_cnt) { - _ACL_FREE(xfs_acl); - return 0; - } - - VN_HOLD(vp); - error = xfs_acl_allow_set(vp, kind); - - /* Incoming ACL exists, set file mode based on its value */ - if (!error && kind == _ACL_TYPE_ACCESS) - error = xfs_acl_setmode(vp, xfs_acl, &basicperms); - - if (error) - goto out; - - /* - * If we have more than std unix permissions, set up the actual attr. - * Otherwise, delete any existing attr. This prevents us from - * having actual attrs for permissions that can be stored in the - * standard permission bits. - */ - if (!basicperms) { - xfs_acl_set_attr(vp, xfs_acl, kind, &error); - } else { - error = -xfs_acl_vremove(vp, _ACL_TYPE_ACCESS); - } - -out: - VN_RELE(vp); - _ACL_FREE(xfs_acl); - return -error; -} - -int -xfs_acl_iaccess( - xfs_inode_t *ip, - mode_t mode, - cred_t *cr) -{ - xfs_acl_t *acl; - int rval; - struct xfs_name acl_name = {SGI_ACL_FILE, SGI_ACL_FILE_SIZE}; - - if (!(_ACL_ALLOC(acl))) - return -1; - - /* If the file has no ACL return -1. */ - rval = sizeof(xfs_acl_t); - if (xfs_attr_fetch(ip, &acl_name, (char *)acl, &rval, ATTR_ROOT)) { - _ACL_FREE(acl); - return -1; - } - xfs_acl_get_endian(acl); - - /* If the file has an empty ACL return -1. */ - if (acl->acl_cnt == XFS_ACL_NOT_PRESENT) { - _ACL_FREE(acl); - return -1; - } - - /* Synchronize ACL with mode bits */ - xfs_acl_sync_mode(ip->i_d.di_mode, acl); - - rval = xfs_acl_access(ip->i_d.di_uid, ip->i_d.di_gid, acl, mode, cr); - _ACL_FREE(acl); - return rval; -} - -STATIC int -xfs_acl_allow_set( - bhv_vnode_t *vp, - int kind) -{ - if (vp->i_flags & (S_IMMUTABLE|S_APPEND)) - return EPERM; - if (kind == _ACL_TYPE_DEFAULT && !S_ISDIR(vp->i_mode)) - return ENOTDIR; - if (vp->i_sb->s_flags & MS_RDONLY) - return EROFS; - if (xfs_vtoi(vp)->i_d.di_uid != current->fsuid && !capable(CAP_FOWNER)) - return EPERM; - return 0; -} - -/* - * Note: cr is only used here for the capability check if the ACL test fails. - * It is not used to find out the credentials uid or groups etc, as was - * done in IRIX. It is assumed that the uid and groups for the current - * thread are taken from "current" instead of the cr parameter. - */ -STATIC int -xfs_acl_access( - uid_t fuid, - gid_t fgid, - xfs_acl_t *fap, - mode_t md, - cred_t *cr) -{ - xfs_acl_entry_t matched; - int i, allows; - int maskallows = -1; /* true, but not 1, either */ - int seen_userobj = 0; - - matched.ae_tag = 0; /* Invalid type */ - matched.ae_perm = 0; - - for (i = 0; i < fap->acl_cnt; i++) { - /* - * Break out if we've got a user_obj entry or - * a user entry and the mask (and have processed USER_OBJ) - */ - if (matched.ae_tag == ACL_USER_OBJ) - break; - if (matched.ae_tag == ACL_USER) { - if (maskallows != -1 && seen_userobj) - break; - if (fap->acl_entry[i].ae_tag != ACL_MASK && - fap->acl_entry[i].ae_tag != ACL_USER_OBJ) - continue; - } - /* True if this entry allows the requested access */ - allows = ((fap->acl_entry[i].ae_perm & md) == md); - - switch (fap->acl_entry[i].ae_tag) { - case ACL_USER_OBJ: - seen_userobj = 1; - if (fuid != current->fsuid) - continue; - matched.ae_tag = ACL_USER_OBJ; - matched.ae_perm = allows; - break; - case ACL_USER: - if (fap->acl_entry[i].ae_id != current->fsuid) - continue; - matched.ae_tag = ACL_USER; - matched.ae_perm = allows; - break; - case ACL_GROUP_OBJ: - if ((matched.ae_tag == ACL_GROUP_OBJ || - matched.ae_tag == ACL_GROUP) && !allows) - continue; - if (!in_group_p(fgid)) - continue; - matched.ae_tag = ACL_GROUP_OBJ; - matched.ae_perm = allows; - break; - case ACL_GROUP: - if ((matched.ae_tag == ACL_GROUP_OBJ || - matched.ae_tag == ACL_GROUP) && !allows) - continue; - if (!in_group_p(fap->acl_entry[i].ae_id)) - continue; - matched.ae_tag = ACL_GROUP; - matched.ae_perm = allows; - break; - case ACL_MASK: - maskallows = allows; - break; - case ACL_OTHER: - if (matched.ae_tag != 0) - continue; - matched.ae_tag = ACL_OTHER; - matched.ae_perm = allows; - break; - } - } - /* - * First possibility is that no matched entry allows access. - * The capability to override DAC may exist, so check for it. - */ - switch (matched.ae_tag) { - case ACL_OTHER: - case ACL_USER_OBJ: - if (matched.ae_perm) - return 0; - break; - case ACL_USER: - case ACL_GROUP_OBJ: - case ACL_GROUP: - if (maskallows && matched.ae_perm) - return 0; - break; - case 0: - break; - } - - /* EACCES tells generic_permission to check for capability overrides */ - return EACCES; -} -EXPORT_SYMBOL(xfs_acl_access); - -/* - * ACL validity checker. - * This acl validation routine checks each ACL entry read in makes sense. - */ -STATIC int -xfs_acl_invalid( - xfs_acl_t *aclp) -{ - xfs_acl_entry_t *entry, *e; - int user = 0, group = 0, other = 0, mask = 0; - int mask_required = 0; - int i, j; - - if (!aclp) - goto acl_invalid; - - if (aclp->acl_cnt > XFS_ACL_MAX_ENTRIES) - goto acl_invalid; - - for (i = 0; i < aclp->acl_cnt; i++) { - entry = &aclp->acl_entry[i]; - switch (entry->ae_tag) { - case ACL_USER_OBJ: - if (user++) - goto acl_invalid; - break; - case ACL_GROUP_OBJ: - if (group++) - goto acl_invalid; - break; - case ACL_OTHER: - if (other++) - goto acl_invalid; - break; - case ACL_USER: - case ACL_GROUP: - for (j = i + 1; j < aclp->acl_cnt; j++) { - e = &aclp->acl_entry[j]; - if (e->ae_id == entry->ae_id && - e->ae_tag == entry->ae_tag) - goto acl_invalid; - } - mask_required++; - break; - case ACL_MASK: - if (mask++) - goto acl_invalid; - break; - default: - goto acl_invalid; - } - } - if (!user || !group || !other || (mask_required && !mask)) - goto acl_invalid; - else - return 0; -acl_invalid: - return EINVAL; -} - -/* - * Do ACL endian conversion. - */ -STATIC void -xfs_acl_get_endian( - xfs_acl_t *aclp) -{ - xfs_acl_entry_t *ace, *end; - - INT_SET(aclp->acl_cnt, ARCH_CONVERT, aclp->acl_cnt); - end = &aclp->acl_entry[0]+aclp->acl_cnt; - for (ace = &aclp->acl_entry[0]; ace < end; ace++) { - INT_SET(ace->ae_tag, ARCH_CONVERT, ace->ae_tag); - INT_SET(ace->ae_id, ARCH_CONVERT, ace->ae_id); - INT_SET(ace->ae_perm, ARCH_CONVERT, ace->ae_perm); - } -} - -/* - * Get the ACL from the EA and do endian conversion. - */ -STATIC void -xfs_acl_get_attr( - bhv_vnode_t *vp, - xfs_acl_t *aclp, - int kind, - int flags, - int *error) -{ - int len = sizeof(xfs_acl_t); - - ASSERT((flags & ATTR_KERNOVAL) ? (aclp == NULL) : 1); - flags |= ATTR_ROOT; - *error = xfs_attr_get(xfs_vtoi(vp), - kind == _ACL_TYPE_ACCESS ? - SGI_ACL_FILE : SGI_ACL_DEFAULT, - (char *)aclp, &len, flags); - if (*error || (flags & ATTR_KERNOVAL)) - return; - xfs_acl_get_endian(aclp); -} - -/* - * Set the EA with the ACL and do endian conversion. - */ -STATIC void -xfs_acl_set_attr( - bhv_vnode_t *vp, - xfs_acl_t *aclp, - int kind, - int *error) -{ - xfs_acl_entry_t *ace, *newace, *end; - xfs_acl_t *newacl; - int len; - - if (!(_ACL_ALLOC(newacl))) { - *error = ENOMEM; - return; - } - - len = sizeof(xfs_acl_t) - - (sizeof(xfs_acl_entry_t) * (XFS_ACL_MAX_ENTRIES - aclp->acl_cnt)); - end = &aclp->acl_entry[0]+aclp->acl_cnt; - for (ace = &aclp->acl_entry[0], newace = &newacl->acl_entry[0]; - ace < end; - ace++, newace++) { - INT_SET(newace->ae_tag, ARCH_CONVERT, ace->ae_tag); - INT_SET(newace->ae_id, ARCH_CONVERT, ace->ae_id); - INT_SET(newace->ae_perm, ARCH_CONVERT, ace->ae_perm); - } - INT_SET(newacl->acl_cnt, ARCH_CONVERT, aclp->acl_cnt); - *error = xfs_attr_set(xfs_vtoi(vp), - kind == _ACL_TYPE_ACCESS ? - SGI_ACL_FILE: SGI_ACL_DEFAULT, - (char *)newacl, len, ATTR_ROOT); - _ACL_FREE(newacl); -} - -int -xfs_acl_vtoacl( - bhv_vnode_t *vp, - xfs_acl_t *access_acl, - xfs_acl_t *default_acl) -{ - int error = 0; - - if (access_acl) { - /* - * Get the Access ACL and the mode. If either cannot - * be obtained for some reason, invalidate the access ACL. - */ - xfs_acl_get_attr(vp, access_acl, _ACL_TYPE_ACCESS, 0, &error); - if (error) - access_acl->acl_cnt = XFS_ACL_NOT_PRESENT; - else /* We have a good ACL and the file mode, synchronize. */ - xfs_acl_sync_mode(xfs_vtoi(vp)->i_d.di_mode, access_acl); - } - - if (default_acl) { - xfs_acl_get_attr(vp, default_acl, _ACL_TYPE_DEFAULT, 0, &error); - if (error) - default_acl->acl_cnt = XFS_ACL_NOT_PRESENT; - } - return error; -} - -/* - * This function retrieves the parent directory's acl, processes it - * and lets the child inherit the acl(s) that it should. - */ -int -xfs_acl_inherit( - bhv_vnode_t *vp, - mode_t mode, - xfs_acl_t *pdaclp) -{ - xfs_acl_t *cacl; - int error = 0; - int basicperms = 0; - - /* - * If the parent does not have a default ACL, or it's an - * invalid ACL, we're done. - */ - if (!vp) - return 0; - if (!pdaclp || xfs_acl_invalid(pdaclp)) - return 0; - - /* - * Copy the default ACL of the containing directory to - * the access ACL of the new file and use the mode that - * was passed in to set up the correct initial values for - * the u::,g::[m::], and o:: entries. This is what makes - * umask() "work" with ACL's. - */ - - if (!(_ACL_ALLOC(cacl))) - return ENOMEM; - - memcpy(cacl, pdaclp, sizeof(xfs_acl_t)); - xfs_acl_filter_mode(mode, cacl); - error = xfs_acl_setmode(vp, cacl, &basicperms); - if (error) - goto out_error; - - /* - * Set the Default and Access ACL on the file. The mode is already - * set on the file, so we don't need to worry about that. - * - * If the new file is a directory, its default ACL is a copy of - * the containing directory's default ACL. - */ - if (S_ISDIR(vp->i_mode)) - xfs_acl_set_attr(vp, pdaclp, _ACL_TYPE_DEFAULT, &error); - if (!error && !basicperms) - xfs_acl_set_attr(vp, cacl, _ACL_TYPE_ACCESS, &error); -out_error: - _ACL_FREE(cacl); - return error; -} - -/* - * Set up the correct mode on the file based on the supplied ACL. This - * makes sure that the mode on the file reflects the state of the - * u::,g::[m::], and o:: entries in the ACL. Since the mode is where - * the ACL is going to get the permissions for these entries, we must - * synchronize the mode whenever we set the ACL on a file. - */ -STATIC int -xfs_acl_setmode( - bhv_vnode_t *vp, - xfs_acl_t *acl, - int *basicperms) -{ - bhv_vattr_t va; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - int i, nomask = 1; - - *basicperms = 1; - - if (acl->acl_cnt == XFS_ACL_NOT_PRESENT) - return 0; - - /* - * Copy the u::, g::, o::, and m:: bits from the ACL into the - * mode. The m:: bits take precedence over the g:: bits. - */ - va.va_mask = XFS_AT_MODE; - va.va_mode = xfs_vtoi(vp)->i_d.di_mode; - va.va_mode &= ~(S_IRWXU|S_IRWXG|S_IRWXO); - ap = acl->acl_entry; - for (i = 0; i < acl->acl_cnt; ++i) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - va.va_mode |= ap->ae_perm << 6; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: /* more than just standard modes */ - nomask = 0; - va.va_mode |= ap->ae_perm << 3; - *basicperms = 0; - break; - case ACL_OTHER: - va.va_mode |= ap->ae_perm; - break; - default: /* more than just standard modes */ - *basicperms = 0; - break; - } - ap++; - } - - /* Set the group bits from ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - va.va_mode |= gap->ae_perm << 3; - - return xfs_setattr(xfs_vtoi(vp), &va, 0, sys_cred); -} - -/* - * The permissions for the special ACL entries (u::, g::[m::], o::) are - * actually stored in the file mode (if there is both a group and a mask, - * the group is stored in the ACL entry and the mask is stored on the file). - * This allows the mode to remain automatically in sync with the ACL without - * the need for a call-back to the ACL system at every point where the mode - * could change. This function takes the permissions from the specified mode - * and places it in the supplied ACL. - * - * This implementation draws its validity from the fact that, when the ACL - * was assigned, the mode was copied from the ACL. - * If the mode did not change, therefore, the mode remains exactly what was - * taken from the special ACL entries at assignment. - * If a subsequent chmod() was done, the POSIX spec says that the change in - * mode must cause an update to the ACL seen at user level and used for - * access checks. Before and after a mode change, therefore, the file mode - * most accurately reflects what the special ACL entries should permit/deny. - * - * CAVEAT: If someone sets the SGI_ACL_FILE attribute directly, - * the existing mode bits will override whatever is in the - * ACL. Similarly, if there is a pre-existing ACL that was - * never in sync with its mode (owing to a bug in 6.5 and - * before), it will now magically (or mystically) be - * synchronized. This could cause slight astonishment, but - * it is better than inconsistent permissions. - * - * The supplied ACL is a template that may contain any combination - * of special entries. These are treated as place holders when we fill - * out the ACL. This routine does not add or remove special entries, it - * simply unites each special entry with its associated set of permissions. - */ -STATIC void -xfs_acl_sync_mode( - mode_t mode, - xfs_acl_t *acl) -{ - int i, nomask = 1; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - - /* - * Set ACL entries. POSIX1003.1eD16 requires that the MASK - * be set instead of the GROUP entry, if there is a MASK. - */ - for (ap = acl->acl_entry, i = 0; i < acl->acl_cnt; ap++, i++) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - ap->ae_perm = (mode >> 6) & 0x7; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: - nomask = 0; - ap->ae_perm = (mode >> 3) & 0x7; - break; - case ACL_OTHER: - ap->ae_perm = mode & 0x7; - break; - default: - break; - } - } - /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm = (mode >> 3) & 0x7; -} - -/* - * When inheriting an Access ACL from a directory Default ACL, - * the ACL bits are set to the intersection of the ACL default - * permission bits and the file permission bits in mode. If there - * are no permission bits on the file then we must not give them - * the ACL. This is what what makes umask() work with ACLs. - */ -STATIC void -xfs_acl_filter_mode( - mode_t mode, - xfs_acl_t *acl) -{ - int i, nomask = 1; - xfs_acl_entry_t *ap; - xfs_acl_entry_t *gap = NULL; - - /* - * Set ACL entries. POSIX1003.1eD16 requires that the MASK - * be merged with GROUP entry, if there is a MASK. - */ - for (ap = acl->acl_entry, i = 0; i < acl->acl_cnt; ap++, i++) { - switch (ap->ae_tag) { - case ACL_USER_OBJ: - ap->ae_perm &= (mode >> 6) & 0x7; - break; - case ACL_GROUP_OBJ: - gap = ap; - break; - case ACL_MASK: - nomask = 0; - ap->ae_perm &= (mode >> 3) & 0x7; - break; - case ACL_OTHER: - ap->ae_perm &= mode & 0x7; - break; - default: - break; - } - } - /* Set the ACL_GROUP_OBJ if there's no ACL_MASK */ - if (gap && nomask) - gap->ae_perm &= (mode >> 3) & 0x7; -} Index: linux-2.6-xfs/fs/xfs/Makefile =================================================================== --- linux-2.6-xfs.orig/fs/xfs/Makefile 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/Makefile 2008-06-27 16:56:52.000000000 +0200 @@ -29,7 +29,7 @@ obj-$(CONFIG_XFS_QUOTA) += quota/ obj-$(CONFIG_XFS_DMAPI) += dmapi/ xfs-$(CONFIG_XFS_RT) += xfs_rtalloc.o -xfs-$(CONFIG_XFS_POSIX_ACL) += xfs_acl.o +xfs-$(CONFIG_XFS_POSIX_ACL) += $(XFS_LINUX)/xfs_acl.o xfs-$(CONFIG_PROC_FS) += $(XFS_LINUX)/xfs_stats.o xfs-$(CONFIG_SYSCTL) += $(XFS_LINUX)/xfs_sysctl.o xfs-$(CONFIG_COMPAT) += $(XFS_LINUX)/xfs_ioctl32.o Index: linux-2.6-xfs/fs/xfs/xfs_inode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.c 2008-06-27 16:56:52.000000000 +0200 @@ -816,6 +816,7 @@ xfs_iread( ip->i_mount = mp; atomic_set(&ip->i_iocount, 0); spin_lock_init(&ip->i_flags_lock); + xfs_inode_init_acls(ip); /* * Get pointer's to the on-disk inode and the buffer containing it. @@ -2668,6 +2669,8 @@ xfs_idestroy( } xfs_inode_item_destroy(ip); } + + xfs_inode_clear_acls(ip); kmem_zone_free(xfs_inode_zone, ip); } Index: linux-2.6-xfs/fs/xfs/xfs_inode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_inode.h 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_inode.h 2008-06-27 16:56:52.000000000 +0200 @@ -18,6 +18,7 @@ #ifndef __XFS_INODE_H__ #define __XFS_INODE_H__ +struct posix_acl; struct xfs_dinode; struct xfs_dinode_core; @@ -239,6 +240,11 @@ typedef struct xfs_inode { xfs_fsize_t i_size; /* in-memory size */ xfs_fsize_t i_new_size; /* size when write completes */ atomic_t i_iocount; /* outstanding I/O count */ + +#ifdef CONFIG_XFS_POSIX_ACL + struct posix_acl *i_acl; + struct posix_acl *i_default_acl; +#endif /* Trace buffers per inode. */ #ifdef XFS_INODE_TRACE struct ktrace *i_trace; /* general inode trace */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-06-27 16:56:52.000000000 +0200 @@ -29,70 +29,6 @@ #include -/* - * ACL handling. Should eventually be moved into xfs_acl.c - */ - -static int -xfs_decode_acl(const char *name) -{ - if (strcmp(name, "posix_acl_access") == 0) - return _ACL_TYPE_ACCESS; - else if (strcmp(name, "posix_acl_default") == 0) - return _ACL_TYPE_DEFAULT; - return -EINVAL; -} - -/* - * Get system extended attributes which at the moment only - * includes Posix ACLs. - */ -static int -xfs_xattr_system_get(struct inode *inode, const char *name, - void *buffer, size_t size) -{ - int acl; - - acl = xfs_decode_acl(name); - if (acl < 0) - return acl; - - return xfs_acl_vget(inode, buffer, size, acl); -} - -static int -xfs_xattr_system_set(struct inode *inode, const char *name, - const void *value, size_t size, int flags) -{ - int error, acl; - - acl = xfs_decode_acl(name); - if (acl < 0) - return acl; - if (flags & XATTR_CREATE) - return -EINVAL; - - if (!value) - return xfs_acl_vremove(inode, acl); - - error = xfs_acl_vset(inode, (void *)value, size, acl); - if (!error) - vn_revalidate(inode); - return error; -} - -static struct xattr_handler xfs_xattr_system_handler = { - .prefix = XATTR_SYSTEM_PREFIX, - .get = xfs_xattr_system_get, - .set = xfs_xattr_system_set, -}; - - -/* - * Real xattr handling. The only difference between the namespaces is - * a flag passed to the low-level attr code. - */ - static int __xfs_xattr_get(struct inode *inode, const char *name, void *value, size_t size, int xflags) @@ -202,7 +138,9 @@ struct xattr_handler *xfs_xattr_handlers &xfs_xattr_user_handler, &xfs_xattr_trusted_handler, &xfs_xattr_security_handler, +#ifdef CONFIG_XFS_POSIX_ACL &xfs_xattr_system_handler, +#endif NULL }; @@ -313,7 +251,7 @@ xfs_vn_listxattr(struct dentry *dentry, /* * Then add the two synthetic ACL attributes. */ - if (xfs_acl_vhasacl_access(inode)) { + if (posix_acl_access_exists(inode)) { error = list_one_attr(POSIX_ACL_XATTR_ACCESS, strlen(POSIX_ACL_XATTR_ACCESS) + 1, data, size, &context.count); @@ -321,7 +259,7 @@ xfs_vn_listxattr(struct dentry *dentry, return error; } - if (xfs_acl_vhasacl_default(inode)) { + if (posix_acl_default_exists(inode)) { error = list_one_attr(POSIX_ACL_XATTR_DEFAULT, strlen(POSIX_ACL_XATTR_DEFAULT) + 1, data, size, &context.count); Index: linux-2.6-xfs/fs/xfs/Kconfig =================================================================== --- linux-2.6-xfs.orig/fs/xfs/Kconfig 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/Kconfig 2008-06-27 16:56:52.000000000 +0200 @@ -51,6 +51,7 @@ config XFS_DMAPI config XFS_POSIX_ACL bool "XFS POSIX ACL support" depends on XFS_FS + select FS_POSIX_ACL help POSIX Access Control Lists (ACLs) support permissions for users and groups beyond the owner/group/world scheme. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_super.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-06-27 16:56:52.000000000 +0200 @@ -43,7 +43,6 @@ #include "xfs_itable.h" #include "xfs_fsops.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_utils.h" @@ -1998,18 +1997,8 @@ xfs_init_zones(void) if (!xfs_ili_zone) goto out_destroy_inode_zone; -#ifdef CONFIG_XFS_POSIX_ACL - xfs_acl_zone = kmem_zone_init(sizeof(xfs_acl_t), "xfs_acl"); - if (!xfs_acl_zone) - goto out_destroy_ili_zone; -#endif - return 0; -#ifdef CONFIG_XFS_POSIX_ACL - out_destroy_ili_zone: -#endif - kmem_zone_destroy(xfs_ili_zone); out_destroy_inode_zone: kmem_zone_destroy(xfs_inode_zone); out_destroy_efi_zone: @@ -2045,9 +2034,6 @@ xfs_init_zones(void) STATIC void xfs_destroy_zones(void) { -#ifdef CONFIG_XFS_POSIX_ACL - kmem_zone_destroy(xfs_acl_zone); -#endif kmem_zone_destroy(xfs_ili_zone); kmem_zone_destroy(xfs_inode_zone); kmem_zone_destroy(xfs_efi_zone); Index: linux-2.6-xfs/fs/xfs/xfs_attr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_attr.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_attr.c 2008-06-27 16:56:52.000000000 +0200 @@ -45,7 +45,6 @@ #include "xfs_error.h" #include "xfs_quota.h" #include "xfs_trans_space.h" -#include "xfs_acl.h" #include "xfs_rw.h" #include "xfs_vnodeops.h" Index: linux-2.6-xfs/fs/xfs/xfs_iomap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_iomap.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_iomap.c 2008-06-27 16:56:52.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/xfs_rw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_rw.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_rw.c 2008-06-27 16:56:52.000000000 +0200 @@ -41,7 +41,6 @@ #include "xfs_ialloc.h" #include "xfs_attr.h" #include "xfs_bmap.h" -#include "xfs_acl.h" #include "xfs_error.h" #include "xfs_buf_item.h" #include "xfs_rw.h" Index: linux-2.6-xfs/fs/xfs/xfs_vfsops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vfsops.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vfsops.c 2008-06-27 16:56:52.000000000 +0200 @@ -47,7 +47,6 @@ #include "xfs_log_priv.h" #include "xfs_dir2_trace.h" #include "xfs_extfree_item.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_clnt.h" #include "xfs_mru_cache.h" Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-06-27 16:56:52.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_itable.h" #include "xfs_bmap.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_attr_leaf.h" #include "xfs_inode_item.h" Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-27 16:56:52.000000000 +0200 @@ -40,7 +40,6 @@ #include "xfs_itable.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_bmap.h" #include "xfs_buf_item.h" Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_lrw.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_lrw.c 2008-06-27 16:56:52.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_inode_item.h" #include "xfs_buf_item.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_dquot.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_dquot.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_dquot.c 2008-06-27 16:56:52.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_dquot_item.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_dquot_item.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_dquot_item.c 2008-06-27 16:56:52.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_error.h" #include "xfs_itable.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_priv.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c 2008-06-27 16:56:52.000000000 +0200 @@ -43,7 +43,6 @@ #include "xfs_error.h" #include "xfs_bmap.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_space.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_bhv.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_bhv.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_bhv.c 2008-06-27 16:56:52.000000000 +0200 @@ -43,7 +43,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_qm.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_stats.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_stats.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_stats.c 2008-06-27 16:56:52.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_qm.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-27 16:56:52.000000000 +0200 @@ -45,7 +45,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_utils.h" Index: linux-2.6-xfs/fs/xfs/quota/xfs_trans_dquot.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_trans_dquot.c 2008-06-27 15:15:46.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/quota/xfs_trans_dquot.c 2008-06-27 16:56:52.000000000 +0200 @@ -42,7 +42,6 @@ #include "xfs_rtalloc.h" #include "xfs_error.h" #include "xfs_rw.h" -#include "xfs_acl.h" #include "xfs_attr.h" #include "xfs_buf_item.h" #include "xfs_trans_priv.h" From owner-xfs@oss.sgi.com Fri Jun 27 08:38:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 08:38: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 m5RFcbxm027811 for ; Fri, 27 Jun 2008 08:38:37 -0700 X-ASG-Debug-ID: 1214581177-4d6003a50000-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 9C5BF293A56 for ; Fri, 27 Jun 2008 08:39:37 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id LbVCcTEDRgAQC4I7 for ; Fri, 27 Jun 2008 08:39:37 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5RFdSNW031445 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Jun 2008 17:39:28 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5RFdSRK031442 for xfs@oss.sgi.com; Fri, 27 Jun 2008 17:39:28 +0200 Date: Fri, 27 Jun 2008 17:39:28 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: rfc: kill ino64 mount option Subject: rfc: kill ino64 mount option Message-ID: <20080627153928.GA31384@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: 1214581178 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.54495 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: 16627 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 Does anyone have objections to kill the ino64 mount option? It's purely a debug tool to force inode numbers outside of the range representable in 32bits and is quite invasive for something that could easily be debugged by just having a large enough filesystem.. From owner-xfs@oss.sgi.com Fri Jun 27 08:45:03 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 08:45:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64 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 m5RFj3Xg028871 for ; Fri, 27 Jun 2008 08:45:03 -0700 X-ASG-Debug-ID: 1214581562-4d6403ce0000-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 2628D293AE4 for ; Fri, 27 Jun 2008 08:46:02 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id upWt4Z8L9wavgdha for ; Fri, 27 Jun 2008 08:46:02 -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 m5RFjrNW031768 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Jun 2008 17:45:53 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5RFjr8i031766 for xfs@oss.sgi.com; Fri, 27 Jun 2008 17:45:53 +0200 Date: Fri, 27 Jun 2008 17:45:53 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/3] split out xfs value-add from xfs_setattr Subject: [PATCH 1/3] split out xfs value-add from xfs_setattr Message-ID: <20080627154553.GA31476@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: 1214581564 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.54495 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: 16628 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 xfs_setattr currently doesn't just handle the attributes set through ->setattr but also addition XFS-specific attributes: project id, inode flags and extent size hint. Having these in a single function makes it more complicated and forces to have us a bhv_vattr intermediate structure eating up stackspace. This patch adds a new xfs_ioctl_setattr helper for the XFS ioctls that set these attributes and remove the code to set them through xfs_setattr. Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-15 16:41:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-15 16:42:18.000000000 +0200 @@ -47,6 +47,8 @@ #include "xfs_dfrag.h" #include "xfs_fsops.h" #include "xfs_vnodeops.h" +#include "xfs_quota.h" +#include "xfs_inode_item.h" #include #include @@ -875,6 +877,297 @@ xfs_ioc_fsgetxattr( return 0; } +STATIC void +xfs_set_diflags( + struct xfs_inode *ip, + unsigned int xflags) +{ + unsigned int di_flags; + + /* can't set PREALLOC this way, just preserve it */ + di_flags = (ip->i_d.di_flags & XFS_DIFLAG_PREALLOC); + if (xflags & XFS_XFLAG_IMMUTABLE) + di_flags |= XFS_DIFLAG_IMMUTABLE; + if (xflags & XFS_XFLAG_APPEND) + di_flags |= XFS_DIFLAG_APPEND; + if (xflags & XFS_XFLAG_SYNC) + di_flags |= XFS_DIFLAG_SYNC; + if (xflags & XFS_XFLAG_NOATIME) + di_flags |= XFS_DIFLAG_NOATIME; + if (xflags & XFS_XFLAG_NODUMP) + di_flags |= XFS_DIFLAG_NODUMP; + if (xflags & XFS_XFLAG_PROJINHERIT) + di_flags |= XFS_DIFLAG_PROJINHERIT; + if (xflags & XFS_XFLAG_NODEFRAG) + di_flags |= XFS_DIFLAG_NODEFRAG; + if (xflags & XFS_XFLAG_FILESTREAM) + di_flags |= XFS_DIFLAG_FILESTREAM; + if ((ip->i_d.di_mode & S_IFMT) == S_IFDIR) { + if (xflags & XFS_XFLAG_RTINHERIT) + di_flags |= XFS_DIFLAG_RTINHERIT; + if (xflags & XFS_XFLAG_NOSYMLINKS) + di_flags |= XFS_DIFLAG_NOSYMLINKS; + if (xflags & XFS_XFLAG_EXTSZINHERIT) + di_flags |= XFS_DIFLAG_EXTSZINHERIT; + } else if ((ip->i_d.di_mode & S_IFMT) == S_IFREG) { + if (xflags & XFS_XFLAG_REALTIME) + di_flags |= XFS_DIFLAG_REALTIME; + if (xflags & XFS_XFLAG_EXTSIZE) + di_flags |= XFS_DIFLAG_EXTSIZE; + } + + ip->i_d.di_flags = di_flags; +} + + +#define FSX_PROJID 1 +#define FSX_EXTSIZE 2 +#define FSX_XFLAGS 4 +#define FSX_NONBLOCK 8 + +STATIC int +xfs_ioctl_setattr( + xfs_inode_t *ip, + struct fsxattr *fa, + int mask) +{ + struct xfs_mount *mp = ip->i_mount; + struct xfs_trans *tp; + unsigned int lock_flags = 0; + struct xfs_dquot *udqp = NULL, *gdqp = NULL; + struct xfs_dquot *olddquot = NULL; + int code; + + xfs_itrace_entry(ip); + + if (mp->m_flags & XFS_MOUNT_RDONLY) + return XFS_ERROR(EROFS); + if (XFS_FORCED_SHUTDOWN(mp)) + return XFS_ERROR(EIO); + + /* + * If disk quotas is on, we make sure that the dquots do exist on disk, + * before we start any other transactions. Trying to do this later + * is messy. We don't care to take a readlock to look at the ids + * in inode here, because we can't hold it across the trans_reserve. + * If the IDs do change before we take the ilock, we're covered + * because the i_*dquot fields will get updated anyway. + */ + if (XFS_IS_QUOTA_ON(mp) && (mask & FSX_PROJID)) { + code = XFS_QM_DQVOPALLOC(mp, ip, ip->i_d.di_uid, + ip->i_d.di_gid, fa->fsx_projid, + XFS_QMOPT_PQUOTA, &udqp, &gdqp); + if (code) + return code; + } + + /* + * For the other attributes, we acquire the inode lock and + * first do an error checking pass. + */ + tp = xfs_trans_alloc(mp, XFS_TRANS_SETATTR_NOT_SIZE); + code = xfs_trans_reserve(tp, 0, XFS_ICHANGE_LOG_RES(mp), 0, 0, 0); + if (code) + goto error_return; + + lock_flags = XFS_ILOCK_EXCL; + xfs_ilock(ip, lock_flags); + + /* + * CAP_FOWNER overrides the following restrictions: + * + * The user ID of the calling process must be equal + * to the file owner ID, except in cases where the + * CAP_FSETID capability is applicable. + */ + if (current->fsuid != ip->i_d.di_uid && !capable(CAP_FOWNER)) { + code = XFS_ERROR(EPERM); + goto error_return; + } + + /* + * Do a quota reservation only if projid is actually going to change. + */ + if (mask & FSX_PROJID) { + if (XFS_IS_PQUOTA_ON(mp) && + ip->i_d.di_projid != fa->fsx_projid) { + ASSERT(tp); + code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp, + capable(CAP_FOWNER) ? + XFS_QMOPT_FORCE_RES : 0); + if (code) /* out of quota */ + goto error_return; + } + } + + if (mask & FSX_EXTSIZE) { + /* + * Can't change extent size if any extents are allocated. + */ + if (ip->i_d.di_nextents && + ((ip->i_d.di_extsize << mp->m_sb.sb_blocklog) != + fa->fsx_extsize)) { + code = XFS_ERROR(EINVAL); /* EFBIG? */ + goto error_return; + } + + /* + * Extent size must be a multiple of the appropriate block + * size, if set at all. + */ + if (fa->fsx_extsize != 0) { + xfs_extlen_t size; + + if (XFS_IS_REALTIME_INODE(ip) || + ((mask & FSX_XFLAGS) && + (fa->fsx_xflags & XFS_XFLAG_REALTIME))) { + size = mp->m_sb.sb_rextsize << + mp->m_sb.sb_blocklog; + } else { + size = mp->m_sb.sb_blocksize; + } + + if (fa->fsx_extsize % size) { + code = XFS_ERROR(EINVAL); + goto error_return; + } + } + } + + + if (mask & FSX_XFLAGS) { + /* + * Can't change realtime flag if any extents are allocated. + */ + if ((ip->i_d.di_nextents || ip->i_delayed_blks) && + (XFS_IS_REALTIME_INODE(ip)) != + (fa->fsx_xflags & XFS_XFLAG_REALTIME)) { + code = XFS_ERROR(EINVAL); /* EFBIG? */ + goto error_return; + } + + /* + * If realtime flag is set then must have realtime data. + */ + if ((fa->fsx_xflags & XFS_XFLAG_REALTIME)) { + if ((mp->m_sb.sb_rblocks == 0) || + (mp->m_sb.sb_rextsize == 0) || + (ip->i_d.di_extsize % mp->m_sb.sb_rextsize)) { + code = XFS_ERROR(EINVAL); + goto error_return; + } + } + + /* + * Can't modify an immutable/append-only file unless + * we have appropriate permission. + */ + if ((ip->i_d.di_flags & + (XFS_DIFLAG_IMMUTABLE|XFS_DIFLAG_APPEND) || + (fa->fsx_xflags & + (XFS_XFLAG_IMMUTABLE | XFS_XFLAG_APPEND))) && + !capable(CAP_LINUX_IMMUTABLE)) { + code = XFS_ERROR(EPERM); + goto error_return; + } + } + + xfs_trans_ijoin(tp, ip, lock_flags); + xfs_trans_ihold(tp, ip); + + /* + * Change file ownership. Must be the owner or privileged. + * If the system was configured with the "restricted_chown" + * option, the owner is not permitted to give away the file, + * and can change the group id only to a group of which he + * or she is a member. + */ + if (mask & FSX_PROJID) { + /* + * CAP_FSETID overrides the following restrictions: + * + * The set-user-ID and set-group-ID bits of a file will be + * cleared upon successful return from chown() + */ + if ((ip->i_d.di_mode & (S_ISUID|S_ISGID)) && + !capable(CAP_FSETID)) + ip->i_d.di_mode &= ~(S_ISUID|S_ISGID); + + /* + * Change the ownerships and register quota modifications + * in the transaction. + */ + if (ip->i_d.di_projid != fa->fsx_projid) { + if (XFS_IS_PQUOTA_ON(mp)) { + olddquot = XFS_QM_DQVOPCHOWN(mp, tp, ip, + &ip->i_gdquot, gdqp); + } + ip->i_d.di_projid = fa->fsx_projid; + + /* + * We may have to rev the inode as well as + * the superblock version number since projids didn't + * exist before DINODE_VERSION_2 and SB_VERSION_NLINK. + */ + if (ip->i_d.di_version == XFS_DINODE_VERSION_1) + xfs_bump_ino_vers2(tp, ip); + } + + } + + if (mask & FSX_EXTSIZE) + ip->i_d.di_extsize = fa->fsx_extsize >> mp->m_sb.sb_blocklog; + if (mask & FSX_XFLAGS) + xfs_set_diflags(ip, fa->fsx_xflags); + + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); + xfs_ichgtime(ip, XFS_ICHGTIME_CHG); + + XFS_STATS_INC(xs_ig_attrchg); + + /* + * If this is a synchronous mount, make sure that the + * transaction goes to disk before returning to the user. + * This is slightly sub-optimal in that truncates require + * two sync transactions instead of one for wsync filesystems. + * One for the truncate and one for the timestamps since we + * don't want to change the timestamps unless we're sure the + * truncate worked. Truncates are less than 1% of the laddis + * mix so this probably isn't worth the trouble to optimize. + */ + if (mp->m_flags & XFS_MOUNT_WSYNC) + xfs_trans_set_sync(tp); + code = xfs_trans_commit(tp, 0); + xfs_iunlock(ip, lock_flags); + + /* + * Release any dquot(s) the inode had kept before chown. + */ + XFS_QM_DQRELE(mp, olddquot); + XFS_QM_DQRELE(mp, udqp); + XFS_QM_DQRELE(mp, gdqp); + + if (code) + return code; + + if (DM_EVENT_ENABLED(ip, DM_EVENT_ATTRIBUTE)) { + XFS_SEND_NAMESP(mp, DM_EVENT_ATTRIBUTE, ip, DM_RIGHT_NULL, + NULL, DM_RIGHT_NULL, NULL, NULL, 0, 0, + (mask & FSX_NONBLOCK) ? DM_FLAGS_NDELAY : 0); + } + + vn_revalidate(XFS_ITOV(ip)); /* update flags */ + return 0; + + error_return: + XFS_QM_DQRELE(mp, udqp); + XFS_QM_DQRELE(mp, gdqp); + xfs_trans_cancel(tp, 0); + if (lock_flags) + xfs_iunlock(ip, lock_flags); + return code; +} + STATIC int xfs_ioc_fssetxattr( xfs_inode_t *ip, @@ -882,31 +1175,16 @@ xfs_ioc_fssetxattr( void __user *arg) { struct fsxattr fa; - struct bhv_vattr *vattr; - int error; - int attr_flags; + unsigned int mask; if (copy_from_user(&fa, arg, sizeof(fa))) return -EFAULT; - vattr = kmalloc(sizeof(*vattr), GFP_KERNEL); - if (unlikely(!vattr)) - return -ENOMEM; - - attr_flags = 0; + mask = FSX_XFLAGS | FSX_EXTSIZE | FSX_PROJID; if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) - attr_flags |= ATTR_NONBLOCK; + mask |= FSX_NONBLOCK; - vattr->va_mask = XFS_AT_XFLAGS | XFS_AT_EXTSIZE | XFS_AT_PROJID; - vattr->va_xflags = fa.fsx_xflags; - vattr->va_extsize = fa.fsx_extsize; - vattr->va_projid = fa.fsx_projid; - - error = -xfs_setattr(ip, vattr, attr_flags, NULL); - if (!error) - vn_revalidate(XFS_ITOV(ip)); /* update flags */ - kfree(vattr); - return 0; + return -xfs_ioctl_setattr(ip, &fa, mask); } STATIC int @@ -928,10 +1206,9 @@ xfs_ioc_setxflags( struct file *filp, void __user *arg) { - struct bhv_vattr *vattr; + struct fsxattr fa; unsigned int flags; - int attr_flags; - int error; + unsigned int mask; if (copy_from_user(&flags, arg, sizeof(flags))) return -EFAULT; @@ -941,22 +1218,12 @@ xfs_ioc_setxflags( FS_SYNC_FL)) return -EOPNOTSUPP; - vattr = kmalloc(sizeof(*vattr), GFP_KERNEL); - if (unlikely(!vattr)) - return -ENOMEM; - - attr_flags = 0; + mask = FSX_XFLAGS; if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) - attr_flags |= ATTR_NONBLOCK; + mask |= FSX_NONBLOCK; + fa.fsx_xflags = xfs_merge_ioc_xflags(flags, xfs_ip2xflags(ip)); - vattr->va_mask = XFS_AT_XFLAGS; - vattr->va_xflags = xfs_merge_ioc_xflags(flags, xfs_ip2xflags(ip)); - - error = -xfs_setattr(ip, vattr, attr_flags, NULL); - if (likely(!error)) - vn_revalidate(XFS_ITOV(ip)); /* update flags */ - kfree(vattr); - return error; + return -xfs_ioctl_setattr(ip, &fa, mask); } STATIC int Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2008-06-15 17:32:14.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2008-06-15 17:35:44.000000000 +0200 @@ -117,26 +117,11 @@ typedef struct bhv_vattr { #define XFS_AT_ACL 0x00080000 #define XFS_AT_CAP 0x00100000 #define XFS_AT_INF 0x00200000 -#define XFS_AT_XFLAGS 0x00400000 -#define XFS_AT_EXTSIZE 0x00800000 #define XFS_AT_NEXTENTS 0x01000000 #define XFS_AT_ANEXTENTS 0x02000000 -#define XFS_AT_PROJID 0x04000000 #define XFS_AT_SIZE_NOPERM 0x08000000 #define XFS_AT_GENCOUNT 0x10000000 -#define XFS_AT_ALL (XFS_AT_TYPE|XFS_AT_MODE|XFS_AT_UID|XFS_AT_GID|\ - XFS_AT_FSID|XFS_AT_NODEID|XFS_AT_NLINK|XFS_AT_SIZE|\ - XFS_AT_ATIME|XFS_AT_MTIME|XFS_AT_CTIME|XFS_AT_RDEV|\ - XFS_AT_BLKSIZE|XFS_AT_NBLOCKS|XFS_AT_VCODE|XFS_AT_MAC|\ - XFS_AT_ACL|XFS_AT_CAP|XFS_AT_INF|XFS_AT_XFLAGS|XFS_AT_EXTSIZE|\ - XFS_AT_NEXTENTS|XFS_AT_ANEXTENTS|XFS_AT_PROJID|XFS_AT_GENCOUNT) - -#define XFS_AT_STAT (XFS_AT_TYPE|XFS_AT_MODE|XFS_AT_UID|XFS_AT_GID|\ - XFS_AT_FSID|XFS_AT_NODEID|XFS_AT_NLINK|XFS_AT_SIZE|\ - XFS_AT_ATIME|XFS_AT_MTIME|XFS_AT_CTIME|XFS_AT_RDEV|\ - XFS_AT_BLKSIZE|XFS_AT_NBLOCKS|XFS_AT_PROJID) - #define XFS_AT_TIMES (XFS_AT_ATIME|XFS_AT_MTIME|XFS_AT_CTIME) #define XFS_AT_UPDTIMES (XFS_AT_UPDATIME|XFS_AT_UPDMTIME|XFS_AT_UPDCTIME) Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-06-15 17:32:42.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-06-15 17:39:09.000000000 +0200 @@ -94,7 +94,6 @@ xfs_setattr( uid_t uid=0, iuid=0; gid_t gid=0, igid=0; int timeflags = 0; - xfs_prid_t projid=0, iprojid=0; struct xfs_dquot *udqp, *gdqp, *olddquot1, *olddquot2; int file_owner; int need_iolock = 1; @@ -139,8 +138,7 @@ xfs_setattr( * If the IDs do change before we take the ilock, we're covered * because the i_*dquot fields will get updated anyway. */ - if (XFS_IS_QUOTA_ON(mp) && - (mask & (XFS_AT_UID|XFS_AT_GID|XFS_AT_PROJID))) { + if (XFS_IS_QUOTA_ON(mp) && (mask & (XFS_AT_UID|XFS_AT_GID))) { uint qflags = 0; if ((mask & XFS_AT_UID) && XFS_IS_UQUOTA_ON(mp)) { @@ -155,12 +153,7 @@ xfs_setattr( } else { gid = ip->i_d.di_gid; } - if ((mask & XFS_AT_PROJID) && XFS_IS_PQUOTA_ON(mp)) { - projid = vap->va_projid; - qflags |= XFS_QMOPT_PQUOTA; - } else { - projid = ip->i_d.di_projid; - } + /* * We take a reference when we initialize udqp and gdqp, * so it is important that we never blindly double trip on @@ -168,8 +161,8 @@ xfs_setattr( */ ASSERT(udqp == NULL); ASSERT(gdqp == NULL); - code = XFS_QM_DQVOPALLOC(mp, ip, uid, gid, projid, qflags, - &udqp, &gdqp); + code = XFS_QM_DQVOPALLOC(mp, ip, uid, gid, ip->i_d.di_projid, + qflags, &udqp, &gdqp); if (code) return code; } @@ -219,9 +212,7 @@ xfs_setattr( * Only the owner or users with CAP_FOWNER * capability may do these things. */ - if (mask & - (XFS_AT_MODE|XFS_AT_XFLAGS|XFS_AT_EXTSIZE|XFS_AT_UID| - XFS_AT_GID|XFS_AT_PROJID)) { + if (mask & (XFS_AT_MODE|XFS_AT_UID|XFS_AT_GID)) { /* * CAP_FOWNER overrides the following restrictions: * @@ -270,7 +261,7 @@ xfs_setattr( * and can change the group id only to a group of which he * or she is a member. */ - if (mask & (XFS_AT_UID|XFS_AT_GID|XFS_AT_PROJID)) { + if (mask & (XFS_AT_UID|XFS_AT_GID)) { /* * These IDs could have changed since we last looked at them. * But, we're assured that if the ownership did change @@ -278,12 +269,9 @@ xfs_setattr( * would have changed also. */ iuid = ip->i_d.di_uid; - iprojid = ip->i_d.di_projid; igid = ip->i_d.di_gid; gid = (mask & XFS_AT_GID) ? vap->va_gid : igid; uid = (mask & XFS_AT_UID) ? vap->va_uid : iuid; - projid = (mask & XFS_AT_PROJID) ? (xfs_prid_t)vap->va_projid : - iprojid; /* * CAP_CHOWN overrides the following restrictions: @@ -303,11 +291,10 @@ xfs_setattr( goto error_return; } /* - * Do a quota reservation only if uid/projid/gid is actually + * Do a quota reservation only if uid/gid is actually * going to change. */ if ((XFS_IS_UQUOTA_ON(mp) && iuid != uid) || - (XFS_IS_PQUOTA_ON(mp) && iprojid != projid) || (XFS_IS_GQUOTA_ON(mp) && igid != gid)) { ASSERT(tp); code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp, @@ -361,78 +348,6 @@ xfs_setattr( } /* - * Change extent size or realtime flag. - */ - if (mask & (XFS_AT_EXTSIZE|XFS_AT_XFLAGS)) { - /* - * Can't change extent size if any extents are allocated. - */ - if (ip->i_d.di_nextents && (mask & XFS_AT_EXTSIZE) && - ((ip->i_d.di_extsize << mp->m_sb.sb_blocklog) != - vap->va_extsize) ) { - code = XFS_ERROR(EINVAL); /* EFBIG? */ - goto error_return; - } - - /* - * Can't change realtime flag if any extents are allocated. - */ - if ((ip->i_d.di_nextents || ip->i_delayed_blks) && - (mask & XFS_AT_XFLAGS) && - (XFS_IS_REALTIME_INODE(ip)) != - (vap->va_xflags & XFS_XFLAG_REALTIME)) { - code = XFS_ERROR(EINVAL); /* EFBIG? */ - goto error_return; - } - /* - * Extent size must be a multiple of the appropriate block - * size, if set at all. - */ - if ((mask & XFS_AT_EXTSIZE) && vap->va_extsize != 0) { - xfs_extlen_t size; - - if (XFS_IS_REALTIME_INODE(ip) || - ((mask & XFS_AT_XFLAGS) && - (vap->va_xflags & XFS_XFLAG_REALTIME))) { - size = mp->m_sb.sb_rextsize << - mp->m_sb.sb_blocklog; - } else { - size = mp->m_sb.sb_blocksize; - } - if (vap->va_extsize % size) { - code = XFS_ERROR(EINVAL); - goto error_return; - } - } - /* - * If realtime flag is set then must have realtime data. - */ - if ((mask & XFS_AT_XFLAGS) && - (vap->va_xflags & XFS_XFLAG_REALTIME)) { - if ((mp->m_sb.sb_rblocks == 0) || - (mp->m_sb.sb_rextsize == 0) || - (ip->i_d.di_extsize % mp->m_sb.sb_rextsize)) { - code = XFS_ERROR(EINVAL); - goto error_return; - } - } - - /* - * Can't modify an immutable/append-only file unless - * we have appropriate permission. - */ - if ((mask & XFS_AT_XFLAGS) && - (ip->i_d.di_flags & - (XFS_DIFLAG_IMMUTABLE|XFS_DIFLAG_APPEND) || - (vap->va_xflags & - (XFS_XFLAG_IMMUTABLE | XFS_XFLAG_APPEND))) && - !capable(CAP_LINUX_IMMUTABLE)) { - code = XFS_ERROR(EPERM); - goto error_return; - } - } - - /* * Now we can make the changes. Before we join the inode * to the transaction, if XFS_AT_SIZE is set then take care of * the part of the truncation that must be done without the @@ -568,7 +483,7 @@ xfs_setattr( * and can change the group id only to a group of which he * or she is a member. */ - if (mask & (XFS_AT_UID|XFS_AT_GID|XFS_AT_PROJID)) { + if (mask & (XFS_AT_UID|XFS_AT_GID)) { /* * CAP_FSETID overrides the following restrictions: * @@ -603,23 +518,6 @@ xfs_setattr( } ip->i_d.di_gid = gid; } - if (iprojid != projid) { - if (XFS_IS_PQUOTA_ON(mp)) { - ASSERT(!XFS_IS_GQUOTA_ON(mp)); - ASSERT(mask & XFS_AT_PROJID); - ASSERT(gdqp); - olddquot2 = XFS_QM_DQVOPCHOWN(mp, tp, ip, - &ip->i_gdquot, gdqp); - } - ip->i_d.di_projid = projid; - /* - * We may have to rev the inode as well as - * the superblock version number since projids didn't - * exist before DINODE_VERSION_2 and SB_VERSION_NLINK. - */ - if (ip->i_d.di_version == XFS_DINODE_VERSION_1) - xfs_bump_ino_vers2(tp, ip); - } xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); timeflags |= XFS_ICHGTIME_CHG; @@ -647,57 +545,6 @@ xfs_setattr( } /* - * Change XFS-added attributes. - */ - if (mask & (XFS_AT_EXTSIZE|XFS_AT_XFLAGS)) { - if (mask & XFS_AT_EXTSIZE) { - /* - * Converting bytes to fs blocks. - */ - ip->i_d.di_extsize = vap->va_extsize >> - mp->m_sb.sb_blocklog; - } - if (mask & XFS_AT_XFLAGS) { - uint di_flags; - - /* can't set PREALLOC this way, just preserve it */ - di_flags = (ip->i_d.di_flags & XFS_DIFLAG_PREALLOC); - if (vap->va_xflags & XFS_XFLAG_IMMUTABLE) - di_flags |= XFS_DIFLAG_IMMUTABLE; - if (vap->va_xflags & XFS_XFLAG_APPEND) - di_flags |= XFS_DIFLAG_APPEND; - if (vap->va_xflags & XFS_XFLAG_SYNC) - di_flags |= XFS_DIFLAG_SYNC; - if (vap->va_xflags & XFS_XFLAG_NOATIME) - di_flags |= XFS_DIFLAG_NOATIME; - if (vap->va_xflags & XFS_XFLAG_NODUMP) - di_flags |= XFS_DIFLAG_NODUMP; - if (vap->va_xflags & XFS_XFLAG_PROJINHERIT) - di_flags |= XFS_DIFLAG_PROJINHERIT; - if (vap->va_xflags & XFS_XFLAG_NODEFRAG) - di_flags |= XFS_DIFLAG_NODEFRAG; - if (vap->va_xflags & XFS_XFLAG_FILESTREAM) - di_flags |= XFS_DIFLAG_FILESTREAM; - if ((ip->i_d.di_mode & S_IFMT) == S_IFDIR) { - if (vap->va_xflags & XFS_XFLAG_RTINHERIT) - di_flags |= XFS_DIFLAG_RTINHERIT; - if (vap->va_xflags & XFS_XFLAG_NOSYMLINKS) - di_flags |= XFS_DIFLAG_NOSYMLINKS; - if (vap->va_xflags & XFS_XFLAG_EXTSZINHERIT) - di_flags |= XFS_DIFLAG_EXTSZINHERIT; - } else if ((ip->i_d.di_mode & S_IFMT) == S_IFREG) { - if (vap->va_xflags & XFS_XFLAG_REALTIME) - di_flags |= XFS_DIFLAG_REALTIME; - if (vap->va_xflags & XFS_XFLAG_EXTSIZE) - di_flags |= XFS_DIFLAG_EXTSIZE; - } - ip->i_d.di_flags = di_flags; - } - xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - timeflags |= XFS_ICHGTIME_CHG; - } - - /* * Change file inode change time only if XFS_AT_CTIME set * AND we have been called by a DMI function. */ From owner-xfs@oss.sgi.com Fri Jun 27 08:45:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 08:45:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5RFjBvT028942 for ; Fri, 27 Jun 2008 08:45:11 -0700 X-ASG-Debug-ID: 1214581571-5b85017c0000-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 B20DBD69CE1 for ; Fri, 27 Jun 2008 08:46:11 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id WnC2AAWPI3T7zAuF for ; Fri, 27 Jun 2008 08:46:11 -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 m5RFk2NW031814 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Jun 2008 17:46:02 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5RFk20g031812 for xfs@oss.sgi.com; Fri, 27 Jun 2008 17:46:02 +0200 Date: Fri, 27 Jun 2008 17:46:02 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 3/3] kill vn_revalidate Subject: [PATCH 3/3] kill vn_revalidate Message-ID: <20080627154602.GC31476@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: 1214581572 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.54497 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: 16630 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 These days most of the attributes in struct inode are properly kept in sync by XFS. This patch removes the need for vn_revalidate completely by: - keeping inode.i_flags uptodate after any flags are updated in xfs_ioctl_setattr - keeping i_mode, i_uid and i_gid uptodate in xfs_setattr 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-19 14:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-06-19 14:18:13.000000000 +0200 @@ -2663,7 +2663,6 @@ xfs_dm_set_fileattr( { dm_fileattr_t stat; struct iattr iattr; - int error; /* Returns negative errors to DMAPI */ @@ -2718,10 +2717,7 @@ xfs_dm_set_fileattr( iattr.ia_size = stat.fa_size; } - error = xfs_setattr(XFS_I(inode), &iattr, XFS_ATTR_DMI, NULL); - if (!error) - vn_revalidate(vn_from_inode(inode)); /* update Linux inode flags */ - return(-error); /* Return negative error to DMAPI */ + return -xfs_setattr(XFS_I(inode), &iattr, XFS_ATTR_DMI, NULL); } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_acl.c 2008-06-19 14:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c 2008-06-19 14:18:13.000000000 +0200 @@ -278,7 +278,6 @@ xfs_set_mode(struct inode *inode, mode_t iattr.ia_mode = mode; error = -xfs_setattr(XFS_I(inode), &iattr, 0, sys_cred); - inode->i_mode = mode; } return error; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-19 14:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-19 14:18:13.000000000 +0200 @@ -919,6 +919,30 @@ xfs_set_diflags( ip->i_d.di_flags = di_flags; } +STATIC void +xfs_diflags_to_linux( + struct xfs_inode *ip) +{ + struct inode *inode = XFS_ITOV(ip); + unsigned int xflags = xfs_ip2xflags(ip); + + if (xflags & XFS_XFLAG_IMMUTABLE) + inode->i_flags |= S_IMMUTABLE; + else + inode->i_flags &= ~S_IMMUTABLE; + if (xflags & XFS_XFLAG_APPEND) + inode->i_flags |= S_APPEND; + else + inode->i_flags &= ~S_APPEND; + if (xflags & XFS_XFLAG_SYNC) + inode->i_flags |= S_SYNC; + else + inode->i_flags &= ~S_SYNC; + if (xflags & XFS_XFLAG_NOATIME) + inode->i_flags |= S_NOATIME; + else + inode->i_flags &= ~S_NOATIME; +} #define FSX_PROJID 1 #define FSX_EXTSIZE 2 @@ -1117,8 +1141,10 @@ xfs_ioctl_setattr( if (mask & FSX_EXTSIZE) ip->i_d.di_extsize = fa->fsx_extsize >> mp->m_sb.sb_blocklog; - if (mask & FSX_XFLAGS) + if (mask & FSX_XFLAGS) { xfs_set_diflags(ip, fa->fsx_xflags); + xfs_diflags_to_linux(ip); + } xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); xfs_ichgtime(ip, XFS_ICHGTIME_CHG); @@ -1156,7 +1182,6 @@ xfs_ioctl_setattr( (mask & FSX_NONBLOCK) ? DM_FLAGS_NDELAY : 0); } - vn_revalidate(XFS_ITOV(ip)); /* update flags */ return 0; error_return: Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-19 14:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-19 14:18:13.000000000 +0200 @@ -624,18 +624,7 @@ xfs_vn_setattr( struct inode *inode = dentry->d_inode; int error; - if (iattr->ia_valid & ATTR_ATIME) - inode->i_atime = iattr->ia_atime; - - if (iattr->ia_valid & ATTR_MODE) { - if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID)) - inode->i_mode &= ~S_ISGID; - } - error = xfs_setattr(XFS_I(inode), iattr, 0, NULL); - if (likely(!error)) - vn_revalidate(vn_from_inode(inode)); - if (!error && (iattr->ia_valid & ATTR_MODE)) error = -xfs_acl_chmod(inode); return -error; 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-19 14:18:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2008-06-19 14:18:25.000000000 +0200 @@ -175,7 +175,6 @@ EXPORT_SYMBOL(uuid_hash64); EXPORT_SYMBOL(uuid_is_nil); EXPORT_SYMBOL(uuid_table_remove); EXPORT_SYMBOL(vn_hold); -EXPORT_SYMBOL(vn_revalidate); EXPORT_SYMBOL(xfs_alloc_buftarg); EXPORT_SYMBOL(xfs_flush_buftarg); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2008-06-19 14:17:04.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2008-06-19 14:18:13.000000000 +0200 @@ -82,56 +82,6 @@ vn_ioerror( xfs_do_force_shutdown(ip->i_mount, SHUTDOWN_DEVICE_REQ, f, l); } -/* - * Revalidate the Linux inode from the XFS inode. - * Note: i_size _not_ updated; we must hold the inode - * semaphore when doing that - callers responsibility. - */ -int -vn_revalidate( - bhv_vnode_t *vp) -{ - struct inode *inode = vn_to_inode(vp); - struct xfs_inode *ip = XFS_I(inode); - struct xfs_mount *mp = ip->i_mount; - unsigned long xflags; - - xfs_itrace_entry(ip); - - if (XFS_FORCED_SHUTDOWN(mp)) - return -EIO; - - xfs_ilock(ip, XFS_ILOCK_SHARED); - inode->i_mode = ip->i_d.di_mode; - inode->i_uid = ip->i_d.di_uid; - inode->i_gid = ip->i_d.di_gid; - inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; - inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; - inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; - inode->i_ctime.tv_nsec = ip->i_d.di_ctime.t_nsec; - - xflags = xfs_ip2xflags(ip); - if (xflags & XFS_XFLAG_IMMUTABLE) - inode->i_flags |= S_IMMUTABLE; - else - inode->i_flags &= ~S_IMMUTABLE; - if (xflags & XFS_XFLAG_APPEND) - inode->i_flags |= S_APPEND; - else - inode->i_flags &= ~S_APPEND; - if (xflags & XFS_XFLAG_SYNC) - inode->i_flags |= S_SYNC; - else - inode->i_flags &= ~S_SYNC; - if (xflags & XFS_XFLAG_NOATIME) - inode->i_flags |= S_NOATIME; - else - inode->i_flags &= ~S_NOATIME; - xfs_iunlock(ip, XFS_ILOCK_SHARED); - - xfs_iflags_clear(ip, XFS_IMODIFIED); - return 0; -} /* * Add a reference to a referenced vnode. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2008-06-19 14:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2008-06-19 14:18:13.000000000 +0200 @@ -67,7 +67,6 @@ static inline struct inode *vn_to_inode( extern void vn_init(void); -extern int vn_revalidate(bhv_vnode_t *); /* * Yeah, these don't take vnode anymore at all, all this should be Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-06-19 14:18:05.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-06-19 14:18:13.000000000 +0200 @@ -83,6 +83,7 @@ xfs_setattr( cred_t *credp) { xfs_mount_t *mp = ip->i_mount; + struct inode *inode = XFS_ITOV(ip); int mask = iattr->ia_valid; xfs_trans_t *tp; int code; @@ -446,6 +447,9 @@ xfs_setattr( ip->i_d.di_mode &= S_IFMT; ip->i_d.di_mode |= iattr->ia_mode & ~S_IFMT; + inode->i_mode &= S_IFMT; + inode->i_mode |= iattr->ia_mode & ~S_IFMT; + xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); timeflags |= XFS_ICHGTIME_CHG; } @@ -481,6 +485,7 @@ xfs_setattr( &ip->i_udquot, udqp); } ip->i_d.di_uid = uid; + inode->i_uid = uid; } if (igid != gid) { if (XFS_IS_GQUOTA_ON(mp)) { @@ -491,6 +496,7 @@ xfs_setattr( &ip->i_gdquot, gdqp); } ip->i_d.di_gid = gid; + inode->i_gid = gid; } xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); @@ -503,12 +509,14 @@ xfs_setattr( */ if (mask & (ATTR_ATIME|ATTR_MTIME)) { if (mask & ATTR_ATIME) { + inode->i_atime = iattr->ia_atime; ip->i_d.di_atime.t_sec = iattr->ia_atime.tv_sec; ip->i_d.di_atime.t_nsec = iattr->ia_atime.tv_nsec; ip->i_update_core = 1; timeflags &= ~XFS_ICHGTIME_ACC; } if (mask & ATTR_MTIME) { + inode->i_mtime = iattr->ia_mtime; ip->i_d.di_mtime.t_sec = iattr->ia_mtime.tv_sec; ip->i_d.di_mtime.t_nsec = iattr->ia_mtime.tv_nsec; timeflags &= ~XFS_ICHGTIME_MOD; @@ -524,6 +532,7 @@ xfs_setattr( */ if ((flags & XFS_ATTR_DMI) && (mask & ATTR_CTIME)) { + inode->i_ctime = iattr->ia_ctime; ip->i_d.di_ctime.t_sec = iattr->ia_ctime.tv_sec; ip->i_d.di_ctime.t_nsec = iattr->ia_ctime.tv_nsec; ip->i_update_core = 1; From owner-xfs@oss.sgi.com Fri Jun 27 08:45:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 08:45:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62, J_CHICKENPOX_64 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 m5RFj8Lf028899 for ; Fri, 27 Jun 2008 08:45:10 -0700 X-ASG-Debug-ID: 1214581566-5fe801180000-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 8647BD69CE1 for ; Fri, 27 Jun 2008 08:46:07 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id AxG7iNGFhHyiRea6 for ; Fri, 27 Jun 2008 08:46:07 -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 m5RFjvNW031786 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Fri, 27 Jun 2008 17:45:57 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5RFjveH031784 for xfs@oss.sgi.com; Fri, 27 Jun 2008 17:45:57 +0200 Date: Fri, 27 Jun 2008 17:45:57 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/3] simplify xfs_setattr Subject: [PATCH 2/3] simplify xfs_setattr Message-ID: <20080627154557.GB31476@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: 1214581568 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.54497 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: 16629 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 Now that xfs_setattr is only used for attributes set from ->setattr it can be switched to take struct iattr directly and thus simplify the implementation greatly. Also rename the ATTR_ flags to XFS_ATTR_ to not conflict with the ATTR_ flags used by the VFS. 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-15 18:10:31.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-06-15 18:25:24.000000000 +0200 @@ -2458,7 +2458,8 @@ xfs_dm_punch_hole( #endif error = xfs_change_file_space(ip, XFS_IOC_UNRESVSP, &bf, - (xfs_off_t)off, sys_cred, ATTR_DMI|ATTR_NOLOCK); + (xfs_off_t)off, sys_cred, + XFS_ATTR_DMI|XFS_ATTR_NOLOCK); /* * if punching to end of file, kill any blocks past EOF that @@ -2661,7 +2662,7 @@ xfs_dm_set_fileattr( dm_fileattr_t __user *statp) { dm_fileattr_t stat; - bhv_vattr_t vat; + struct iattr iattr; int error; /* Returns negative errors to DMAPI */ @@ -2672,52 +2673,52 @@ xfs_dm_set_fileattr( if (copy_from_user( &stat, statp, sizeof(stat))) return(-EFAULT); - vat.va_mask = 0; + iattr.ia_valid = 0; if (mask & DM_AT_MODE) { - vat.va_mask |= XFS_AT_MODE; - vat.va_mode = stat.fa_mode; + iattr.ia_valid |= ATTR_MODE; + iattr.ia_mode = stat.fa_mode; } if (mask & DM_AT_UID) { - vat.va_mask |= XFS_AT_UID; - vat.va_uid = stat.fa_uid; + iattr.ia_valid |= ATTR_UID; + iattr.ia_uid = stat.fa_uid; } if (mask & DM_AT_GID) { - vat.va_mask |= XFS_AT_GID; - vat.va_gid = stat.fa_gid; + iattr.ia_valid |= ATTR_GID; + iattr.ia_gid = stat.fa_gid; } if (mask & DM_AT_ATIME) { - vat.va_mask |= XFS_AT_ATIME; - vat.va_atime.tv_sec = stat.fa_atime; - vat.va_atime.tv_nsec = 0; + iattr.ia_valid |= ATTR_ATIME; + iattr.ia_atime.tv_sec = stat.fa_atime; + iattr.ia_atime.tv_nsec = 0; inode->i_atime.tv_sec = stat.fa_atime; } if (mask & DM_AT_MTIME) { - vat.va_mask |= XFS_AT_MTIME; - vat.va_mtime.tv_sec = stat.fa_mtime; - vat.va_mtime.tv_nsec = 0; + iattr.ia_valid |= ATTR_MTIME; + iattr.ia_mtime.tv_sec = stat.fa_mtime; + iattr.ia_mtime.tv_nsec = 0; } if (mask & DM_AT_CTIME) { - vat.va_mask |= XFS_AT_CTIME; - vat.va_ctime.tv_sec = stat.fa_ctime; - vat.va_ctime.tv_nsec = 0; + iattr.ia_valid |= ATTR_CTIME; + iattr.ia_ctime.tv_sec = stat.fa_ctime; + iattr.ia_ctime.tv_nsec = 0; } - /* DM_AT_DTIME only takes effect if DM_AT_CTIME is not specified. We - overload ctime to also act as dtime, i.e. DM_CONFIG_DTIME_OVERLOAD. - */ - + /* + * DM_AT_DTIME only takes effect if DM_AT_CTIME is not specified. We + * overload ctime to also act as dtime, i.e. DM_CONFIG_DTIME_OVERLOAD. + */ if ((mask & DM_AT_DTIME) && !(mask & DM_AT_CTIME)) { - vat.va_mask |= XFS_AT_CTIME; - vat.va_ctime.tv_sec = stat.fa_dtime; - vat.va_ctime.tv_nsec = 0; + iattr.ia_valid |= ATTR_CTIME; + iattr.ia_ctime.tv_sec = stat.fa_dtime; + iattr.ia_ctime.tv_nsec = 0; } if (mask & DM_AT_SIZE) { - vat.va_mask |= XFS_AT_SIZE; - vat.va_size = stat.fa_size; + iattr.ia_valid |= ATTR_SIZE; + iattr.ia_size = stat.fa_size; } - error = xfs_setattr(XFS_I(inode), &vat, ATTR_DMI, NULL); + error = xfs_setattr(XFS_I(inode), &iattr, XFS_ATTR_DMI, NULL); if (!error) vn_revalidate(vn_from_inode(inode)); /* update Linux inode flags */ return(-error); /* Return negative error to DMAPI */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_acl.c 2008-06-15 18:08:27.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_acl.c 2008-06-15 18:20:16.000000000 +0200 @@ -272,12 +272,12 @@ xfs_set_mode(struct inode *inode, mode_t int error = 0; if (mode != inode->i_mode) { - struct bhv_vattr va; + struct iattr iattr; - va.va_mask = XFS_AT_MODE; - va.va_mode = mode; + iattr.ia_valid = ATTR_MODE; + iattr.ia_mode = mode; - error = -xfs_setattr(XFS_I(inode), &va, 0, sys_cred); + error = -xfs_setattr(XFS_I(inode), &iattr, 0, sys_cred); inode->i_mode = mode; } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-06-15 17:50:24.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-06-15 18:25:50.000000000 +0200 @@ -607,58 +607,24 @@ xfs_vn_getattr( STATIC int xfs_vn_setattr( struct dentry *dentry, - struct iattr *attr) + struct iattr *iattr) { struct inode *inode = dentry->d_inode; - unsigned int ia_valid = attr->ia_valid; - bhv_vattr_t vattr = { 0 }; - int flags = 0; int error; - if (ia_valid & ATTR_UID) { - vattr.va_mask |= XFS_AT_UID; - vattr.va_uid = attr->ia_uid; - } - if (ia_valid & ATTR_GID) { - vattr.va_mask |= XFS_AT_GID; - vattr.va_gid = attr->ia_gid; - } - if (ia_valid & ATTR_SIZE) { - vattr.va_mask |= XFS_AT_SIZE; - vattr.va_size = attr->ia_size; - } - if (ia_valid & ATTR_ATIME) { - vattr.va_mask |= XFS_AT_ATIME; - vattr.va_atime = attr->ia_atime; - inode->i_atime = attr->ia_atime; - } - if (ia_valid & ATTR_MTIME) { - vattr.va_mask |= XFS_AT_MTIME; - vattr.va_mtime = attr->ia_mtime; - } - if (ia_valid & ATTR_CTIME) { - vattr.va_mask |= XFS_AT_CTIME; - vattr.va_ctime = attr->ia_ctime; - } - if (ia_valid & ATTR_MODE) { - vattr.va_mask |= XFS_AT_MODE; - vattr.va_mode = attr->ia_mode; + if (iattr->ia_valid & ATTR_ATIME) + inode->i_atime = iattr->ia_atime; + + if (iattr->ia_valid & ATTR_MODE) { if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID)) inode->i_mode &= ~S_ISGID; } - if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET)) - flags |= ATTR_UTIME; -#ifdef ATTR_NO_BLOCK - if ((ia_valid & ATTR_NO_BLOCK)) - flags |= ATTR_NONBLOCK; -#endif - - error = xfs_setattr(XFS_I(inode), &vattr, flags, NULL); + error = xfs_setattr(XFS_I(inode), iattr, 0, NULL); if (likely(!error)) vn_revalidate(vn_from_inode(inode)); - if (!error && (attr->ia_valid & ATTR_MODE)) + if (!error && (iattr->ia_valid & ATTR_MODE)) error = -xfs_acl_chmod(inode); return -error; } @@ -701,18 +667,18 @@ xfs_vn_fallocate( xfs_ilock(ip, XFS_IOLOCK_EXCL); error = xfs_change_file_space(ip, XFS_IOC_RESVSP, &bf, - 0, NULL, ATTR_NOLOCK); + 0, NULL, XFS_ATTR_NOLOCK); if (!error && !(mode & FALLOC_FL_KEEP_SIZE) && offset + len > i_size_read(inode)) new_size = offset + len; /* Change file size if needed */ if (new_size) { - bhv_vattr_t va; + struct iattr iattr; - va.va_mask = XFS_AT_SIZE; - va.va_size = new_size; - error = xfs_setattr(ip, &va, ATTR_NOLOCK, NULL); + iattr.ia_valid = ATTR_SIZE; + iattr.ia_size = new_size; + error = xfs_setattr(ip, &iattr, XFS_ATTR_NOLOCK, NULL); } xfs_iunlock(ip, XFS_IOLOCK_EXCL); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2008-06-15 18:01:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2008-06-15 18:24:04.000000000 +0200 @@ -19,7 +19,6 @@ #define __XFS_VNODE_H__ struct file; -struct bhv_vattr; struct xfs_iomap; struct attrlist_cursor_kern; @@ -66,69 +65,6 @@ static inline struct inode *vn_to_inode( Prevent VM access to the pages until the operation completes. */ -/* - * Vnode attributes. va_mask indicates those attributes the caller - * wants to set or extract. - */ -typedef struct bhv_vattr { - int va_mask; /* bit-mask of attributes present */ - mode_t va_mode; /* file access mode and type */ - xfs_nlink_t va_nlink; /* number of references to file */ - uid_t va_uid; /* owner user id */ - gid_t va_gid; /* owner group id */ - xfs_ino_t va_nodeid; /* file id */ - xfs_off_t va_size; /* file size in bytes */ - u_long va_blocksize; /* blocksize preferred for i/o */ - struct timespec va_atime; /* time of last access */ - struct timespec va_mtime; /* time of last modification */ - struct timespec va_ctime; /* time file changed */ - u_int va_gen; /* generation number of file */ - xfs_dev_t va_rdev; /* device the special file represents */ - __int64_t va_nblocks; /* number of blocks allocated */ - u_long va_xflags; /* random extended file flags */ - u_long va_extsize; /* file extent size */ - u_long va_nextents; /* number of extents in file */ - u_long va_anextents; /* number of attr extents in file */ - prid_t va_projid; /* project id */ -} bhv_vattr_t; - -/* - * setattr or getattr attributes - */ -#define XFS_AT_TYPE 0x00000001 -#define XFS_AT_MODE 0x00000002 -#define XFS_AT_UID 0x00000004 -#define XFS_AT_GID 0x00000008 -#define XFS_AT_FSID 0x00000010 -#define XFS_AT_NODEID 0x00000020 -#define XFS_AT_NLINK 0x00000040 -#define XFS_AT_SIZE 0x00000080 -#define XFS_AT_ATIME 0x00000100 -#define XFS_AT_MTIME 0x00000200 -#define XFS_AT_CTIME 0x00000400 -#define XFS_AT_RDEV 0x00000800 -#define XFS_AT_BLKSIZE 0x00001000 -#define XFS_AT_NBLOCKS 0x00002000 -#define XFS_AT_VCODE 0x00004000 -#define XFS_AT_MAC 0x00008000 -#define XFS_AT_UPDATIME 0x00010000 -#define XFS_AT_UPDMTIME 0x00020000 -#define XFS_AT_UPDCTIME 0x00040000 -#define XFS_AT_ACL 0x00080000 -#define XFS_AT_CAP 0x00100000 -#define XFS_AT_INF 0x00200000 -#define XFS_AT_NEXTENTS 0x01000000 -#define XFS_AT_ANEXTENTS 0x02000000 -#define XFS_AT_SIZE_NOPERM 0x08000000 -#define XFS_AT_GENCOUNT 0x10000000 - -#define XFS_AT_TIMES (XFS_AT_ATIME|XFS_AT_MTIME|XFS_AT_CTIME) - -#define XFS_AT_UPDTIMES (XFS_AT_UPDATIME|XFS_AT_UPDMTIME|XFS_AT_UPDCTIME) - -#define XFS_AT_NOSET (XFS_AT_NLINK|XFS_AT_RDEV|XFS_AT_FSID|XFS_AT_NODEID|\ - XFS_AT_TYPE|XFS_AT_BLKSIZE|XFS_AT_NBLOCKS|XFS_AT_VCODE|\ - XFS_AT_NEXTENTS|XFS_AT_ANEXTENTS|XFS_AT_GENCOUNT) extern void vn_init(void); extern int vn_revalidate(bhv_vnode_t *); @@ -199,15 +135,6 @@ static inline void vn_atime_to_time_t(bh #define VN_DIRTY(vp) mapping_tagged(vn_to_inode(vp)->i_mapping, \ PAGECACHE_TAG_DIRTY) -/* - * Flags to vop_setattr/getattr. - */ -#define ATTR_UTIME 0x01 /* non-default utime(2) request */ -#define ATTR_DMI 0x08 /* invocation from a DMI function */ -#define ATTR_LAZY 0x80 /* set/get attributes lazily */ -#define ATTR_NONBLOCK 0x100 /* return EAGAIN if operation would block */ -#define ATTR_NOLOCK 0x200 /* Don't grab any conflicting locks */ -#define ATTR_NOSIZETOK 0x400 /* Don't get the SIZE token */ /* * Tracking vnode activity. Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-06-15 17:50:24.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-06-15 18:27:04.000000000 +0200 @@ -75,19 +75,16 @@ xfs_open( return 0; } -/* - * xfs_setattr - */ int xfs_setattr( - xfs_inode_t *ip, - bhv_vattr_t *vap, + struct xfs_inode *ip, + struct iattr *iattr, int flags, cred_t *credp) { xfs_mount_t *mp = ip->i_mount; + int mask = iattr->ia_valid; xfs_trans_t *tp; - int mask; int code; uint lock_flags; uint commit_flags=0; @@ -103,30 +100,9 @@ xfs_setattr( if (mp->m_flags & XFS_MOUNT_RDONLY) return XFS_ERROR(EROFS); - /* - * Cannot set certain attributes. - */ - mask = vap->va_mask; - if (mask & XFS_AT_NOSET) { - return XFS_ERROR(EINVAL); - } - if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); - /* - * Timestamps do not need to be logged and hence do not - * need to be done within a transaction. - */ - if (mask & XFS_AT_UPDTIMES) { - ASSERT((mask & ~XFS_AT_UPDTIMES) == 0); - timeflags = ((mask & XFS_AT_UPDATIME) ? XFS_ICHGTIME_ACC : 0) | - ((mask & XFS_AT_UPDCTIME) ? XFS_ICHGTIME_CHG : 0) | - ((mask & XFS_AT_UPDMTIME) ? XFS_ICHGTIME_MOD : 0); - xfs_ichgtime(ip, timeflags); - return 0; - } - olddquot1 = olddquot2 = NULL; udqp = gdqp = NULL; @@ -138,17 +114,17 @@ xfs_setattr( * If the IDs do change before we take the ilock, we're covered * because the i_*dquot fields will get updated anyway. */ - if (XFS_IS_QUOTA_ON(mp) && (mask & (XFS_AT_UID|XFS_AT_GID))) { + if (XFS_IS_QUOTA_ON(mp) && (mask & (ATTR_UID|ATTR_GID))) { uint qflags = 0; - if ((mask & XFS_AT_UID) && XFS_IS_UQUOTA_ON(mp)) { - uid = vap->va_uid; + if ((mask & ATTR_UID) && XFS_IS_UQUOTA_ON(mp)) { + uid = iattr->ia_uid; qflags |= XFS_QMOPT_UQUOTA; } else { uid = ip->i_d.di_uid; } - if ((mask & XFS_AT_GID) && XFS_IS_GQUOTA_ON(mp)) { - gid = vap->va_gid; + if ((mask & ATTR_GID) && XFS_IS_GQUOTA_ON(mp)) { + gid = iattr->ia_gid; qflags |= XFS_QMOPT_GQUOTA; } else { gid = ip->i_d.di_gid; @@ -173,10 +149,10 @@ xfs_setattr( */ tp = NULL; lock_flags = XFS_ILOCK_EXCL; - if (flags & ATTR_NOLOCK) + if (flags & XFS_ATTR_NOLOCK) need_iolock = 0; - if (!(mask & XFS_AT_SIZE)) { - if ((mask != (XFS_AT_CTIME|XFS_AT_ATIME|XFS_AT_MTIME)) || + if (!(mask & ATTR_SIZE)) { + if ((mask != (ATTR_CTIME|ATTR_ATIME|ATTR_MTIME)) || (mp->m_flags & XFS_MOUNT_WSYNC)) { tp = xfs_trans_alloc(mp, XFS_TRANS_SETATTR_NOT_SIZE); commit_flags = 0; @@ -189,10 +165,10 @@ xfs_setattr( } } else { if (DM_EVENT_ENABLED(ip, DM_EVENT_TRUNCATE) && - !(flags & ATTR_DMI)) { + !(flags & XFS_ATTR_DMI)) { int dmflags = AT_DELAY_FLAG(flags) | DM_SEM_FLAG_WR; code = XFS_SEND_DATA(mp, DM_EVENT_TRUNCATE, ip, - vap->va_size, 0, dmflags, NULL); + iattr->ia_size, 0, dmflags, NULL); if (code) { lock_flags = 0; goto error_return; @@ -212,7 +188,7 @@ xfs_setattr( * Only the owner or users with CAP_FOWNER * capability may do these things. */ - if (mask & (XFS_AT_MODE|XFS_AT_UID|XFS_AT_GID)) { + if (mask & (ATTR_MODE|ATTR_UID|ATTR_GID)) { /* * CAP_FOWNER overrides the following restrictions: * @@ -236,21 +212,21 @@ xfs_setattr( * IDs of the calling process shall match the group owner of * the file when setting the set-group-ID bit on that file */ - if (mask & XFS_AT_MODE) { + if (mask & ATTR_MODE) { mode_t m = 0; - if ((vap->va_mode & S_ISUID) && !file_owner) + if ((iattr->ia_mode & S_ISUID) && !file_owner) m |= S_ISUID; - if ((vap->va_mode & S_ISGID) && + if ((iattr->ia_mode & S_ISGID) && !in_group_p((gid_t)ip->i_d.di_gid)) m |= S_ISGID; #if 0 /* Linux allows this, Irix doesn't. */ - if ((vap->va_mode & S_ISVTX) && !S_ISDIR(ip->i_d.di_mode)) + if ((iattr->ia_mode & S_ISVTX) && !S_ISDIR(ip->i_d.di_mode)) m |= S_ISVTX; #endif if (m && !capable(CAP_FSETID)) - vap->va_mode &= ~m; + iattr->ia_mode &= ~m; } } @@ -261,7 +237,7 @@ xfs_setattr( * and can change the group id only to a group of which he * or she is a member. */ - if (mask & (XFS_AT_UID|XFS_AT_GID)) { + if (mask & (ATTR_UID|ATTR_GID)) { /* * These IDs could have changed since we last looked at them. * But, we're assured that if the ownership did change @@ -270,8 +246,8 @@ xfs_setattr( */ iuid = ip->i_d.di_uid; igid = ip->i_d.di_gid; - gid = (mask & XFS_AT_GID) ? vap->va_gid : igid; - uid = (mask & XFS_AT_UID) ? vap->va_uid : iuid; + gid = (mask & ATTR_GID) ? iattr->ia_gid : igid; + uid = (mask & ATTR_UID) ? iattr->ia_uid : iuid; /* * CAP_CHOWN overrides the following restrictions: @@ -308,13 +284,13 @@ xfs_setattr( /* * Truncate file. Must have write permission and not be a directory. */ - if (mask & XFS_AT_SIZE) { + if (mask & ATTR_SIZE) { /* Short circuit the truncate case for zero length files */ - if ((vap->va_size == 0) && - (ip->i_size == 0) && (ip->i_d.di_nextents == 0)) { + if (iattr->ia_size == 0 && + ip->i_size == 0 && ip->i_d.di_nextents == 0) { xfs_iunlock(ip, XFS_ILOCK_EXCL); lock_flags &= ~XFS_ILOCK_EXCL; - if (mask & XFS_AT_CTIME) + if (mask & ATTR_CTIME) xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); code = 0; goto error_return; @@ -337,9 +313,9 @@ xfs_setattr( /* * Change file access or modified times. */ - if (mask & (XFS_AT_ATIME|XFS_AT_MTIME)) { + if (mask & (ATTR_ATIME|ATTR_MTIME)) { if (!file_owner) { - if ((flags & ATTR_UTIME) && + if ((mask & (ATTR_MTIME_SET|ATTR_ATIME_SET)) && !capable(CAP_FOWNER)) { code = XFS_ERROR(EPERM); goto error_return; @@ -349,23 +325,22 @@ xfs_setattr( /* * Now we can make the changes. Before we join the inode - * to the transaction, if XFS_AT_SIZE is set then take care of + * to the transaction, if ATTR_SIZE is set then take care of * the part of the truncation that must be done without the * inode lock. This needs to be done before joining the inode * to the transaction, because the inode cannot be unlocked * once it is a part of the transaction. */ - if (mask & XFS_AT_SIZE) { + if (mask & ATTR_SIZE) { code = 0; - if ((vap->va_size > ip->i_size) && - (flags & ATTR_NOSIZETOK) == 0) { + if (iattr->ia_size > ip->i_size) { /* * Do the first part of growing a file: zero any data * in the last block that is beyond the old EOF. We * need to do this before the inode is joined to the * transaction to modify the i_size. */ - code = xfs_zero_eof(ip, vap->va_size, ip->i_size); + code = xfs_zero_eof(ip, iattr->ia_size, ip->i_size); } xfs_iunlock(ip, XFS_ILOCK_EXCL); @@ -382,10 +357,10 @@ xfs_setattr( * not within the range we care about here. */ if (!code && - (ip->i_size != ip->i_d.di_size) && - (vap->va_size > ip->i_d.di_size)) { + ip->i_size != ip->i_d.di_size && + iattr->ia_size > ip->i_d.di_size) { code = xfs_flush_pages(ip, - ip->i_d.di_size, vap->va_size, + ip->i_d.di_size, iattr->ia_size, XFS_B_ASYNC, FI_NONE); } @@ -393,7 +368,7 @@ xfs_setattr( vn_iowait(ip); if (!code) - code = xfs_itruncate_data(ip, vap->va_size); + code = xfs_itruncate_data(ip, iattr->ia_size); if (code) { ASSERT(tp == NULL); lock_flags &= ~XFS_ILOCK_EXCL; @@ -422,31 +397,30 @@ xfs_setattr( /* * Truncate file. Must have write permission and not be a directory. */ - if (mask & XFS_AT_SIZE) { + if (mask & ATTR_SIZE) { /* * Only change the c/mtime if we are changing the size * or we are explicitly asked to change it. This handles * the semantic difference between truncate() and ftruncate() * as implemented in the VFS. */ - if (vap->va_size != ip->i_size || (mask & XFS_AT_CTIME)) + if (iattr->ia_size != ip->i_size || (mask & ATTR_CTIME)) timeflags |= XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG; - if (vap->va_size > ip->i_size) { - ip->i_d.di_size = vap->va_size; - ip->i_size = vap->va_size; - if (!(flags & ATTR_DMI)) + if (iattr->ia_size > ip->i_size) { + ip->i_d.di_size = iattr->ia_size; + ip->i_size = iattr->ia_size; + if (!(flags & XFS_ATTR_DMI)) xfs_ichgtime(ip, XFS_ICHGTIME_CHG); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - } else if ((vap->va_size <= ip->i_size) || - ((vap->va_size == 0) && ip->i_d.di_nextents)) { + } else if (iattr->ia_size <= ip->i_size || + (iattr->ia_size == 0 && ip->i_d.di_nextents)) { /* * signal a sync transaction unless * we're truncating an already unlinked * file on a wsync filesystem */ - code = xfs_itruncate_finish(&tp, ip, - (xfs_fsize_t)vap->va_size, + code = xfs_itruncate_finish(&tp, ip, iattr->ia_size, XFS_DATA_FORK, ((ip->i_d.di_nlink != 0 || !(mp->m_flags & XFS_MOUNT_WSYNC)) @@ -468,9 +442,9 @@ xfs_setattr( /* * Change file access modes. */ - if (mask & XFS_AT_MODE) { + if (mask & ATTR_MODE) { ip->i_d.di_mode &= S_IFMT; - ip->i_d.di_mode |= vap->va_mode & ~S_IFMT; + ip->i_d.di_mode |= iattr->ia_mode & ~S_IFMT; xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); timeflags |= XFS_ICHGTIME_CHG; @@ -483,7 +457,7 @@ xfs_setattr( * and can change the group id only to a group of which he * or she is a member. */ - if (mask & (XFS_AT_UID|XFS_AT_GID)) { + if (mask & (ATTR_UID|ATTR_GID)) { /* * CAP_FSETID overrides the following restrictions: * @@ -501,7 +475,7 @@ xfs_setattr( */ if (iuid != uid) { if (XFS_IS_UQUOTA_ON(mp)) { - ASSERT(mask & XFS_AT_UID); + ASSERT(mask & ATTR_UID); ASSERT(udqp); olddquot1 = XFS_QM_DQVOPCHOWN(mp, tp, ip, &ip->i_udquot, udqp); @@ -511,7 +485,7 @@ xfs_setattr( if (igid != gid) { if (XFS_IS_GQUOTA_ON(mp)) { ASSERT(!XFS_IS_PQUOTA_ON(mp)); - ASSERT(mask & XFS_AT_GID); + ASSERT(mask & ATTR_GID); ASSERT(gdqp); olddquot2 = XFS_QM_DQVOPCHOWN(mp, tp, ip, &ip->i_gdquot, gdqp); @@ -527,31 +501,31 @@ xfs_setattr( /* * Change file access or modified times. */ - if (mask & (XFS_AT_ATIME|XFS_AT_MTIME)) { - if (mask & XFS_AT_ATIME) { - ip->i_d.di_atime.t_sec = vap->va_atime.tv_sec; - ip->i_d.di_atime.t_nsec = vap->va_atime.tv_nsec; + if (mask & (ATTR_ATIME|ATTR_MTIME)) { + if (mask & ATTR_ATIME) { + ip->i_d.di_atime.t_sec = iattr->ia_atime.tv_sec; + ip->i_d.di_atime.t_nsec = iattr->ia_atime.tv_nsec; ip->i_update_core = 1; timeflags &= ~XFS_ICHGTIME_ACC; } - if (mask & XFS_AT_MTIME) { - ip->i_d.di_mtime.t_sec = vap->va_mtime.tv_sec; - ip->i_d.di_mtime.t_nsec = vap->va_mtime.tv_nsec; + if (mask & ATTR_MTIME) { + ip->i_d.di_mtime.t_sec = iattr->ia_mtime.tv_sec; + ip->i_d.di_mtime.t_nsec = iattr->ia_mtime.tv_nsec; timeflags &= ~XFS_ICHGTIME_MOD; timeflags |= XFS_ICHGTIME_CHG; } - if (tp && (flags & ATTR_UTIME)) + if (tp && (mask & (ATTR_MTIME_SET|ATTR_ATIME_SET))) xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); } /* - * Change file inode change time only if XFS_AT_CTIME set + * Change file inode change time only if ATTR_CTIME set * AND we have been called by a DMI function. */ - if ( (flags & ATTR_DMI) && (mask & XFS_AT_CTIME) ) { - ip->i_d.di_ctime.t_sec = vap->va_ctime.tv_sec; - ip->i_d.di_ctime.t_nsec = vap->va_ctime.tv_nsec; + if ((flags & XFS_ATTR_DMI) && (mask & ATTR_CTIME)) { + ip->i_d.di_ctime.t_sec = iattr->ia_ctime.tv_sec; + ip->i_d.di_ctime.t_nsec = iattr->ia_ctime.tv_nsec; ip->i_update_core = 1; timeflags &= ~XFS_ICHGTIME_CHG; } @@ -560,7 +534,7 @@ xfs_setattr( * Send out timestamp changes that need to be set to the * current time. Not done when called by a DMI function. */ - if (timeflags && !(flags & ATTR_DMI)) + if (timeflags && !(flags & XFS_ATTR_DMI)) xfs_ichgtime(ip, timeflags); XFS_STATS_INC(xs_ig_attrchg); @@ -598,7 +572,7 @@ xfs_setattr( } if (DM_EVENT_ENABLED(ip, DM_EVENT_ATTRIBUTE) && - !(flags & ATTR_DMI)) { + !(flags & XFS_ATTR_DMI)) { (void) XFS_SEND_NAMESP(mp, DM_EVENT_ATTRIBUTE, ip, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, NULL, NULL, 0, 0, AT_DELAY_FLAG(flags)); @@ -3050,7 +3024,7 @@ xfs_alloc_file_space( /* Generate a DMAPI event if needed. */ if (alloc_type != 0 && offset < ip->i_size && - (attr_flags&ATTR_DMI) == 0 && + (attr_flags & XFS_ATTR_DMI) == 0 && DM_EVENT_ENABLED(ip, DM_EVENT_WRITE)) { xfs_off_t end_dmi_offset; @@ -3164,7 +3138,7 @@ retry: allocatesize_fsb -= allocated_fsb; } dmapi_enospc_check: - if (error == ENOSPC && (attr_flags & ATTR_DMI) == 0 && + if (error == ENOSPC && (attr_flags & XFS_ATTR_DMI) == 0 && DM_EVENT_ENABLED(ip, DM_EVENT_NOSPACE)) { error = XFS_SEND_NAMESP(mp, DM_EVENT_NOSPACE, ip, DM_RIGHT_NULL, @@ -3311,7 +3285,7 @@ xfs_free_file_space( end_dmi_offset = offset + len; endoffset_fsb = XFS_B_TO_FSBT(mp, end_dmi_offset); - if (offset < ip->i_size && (attr_flags & ATTR_DMI) == 0 && + if (offset < ip->i_size && (attr_flags & XFS_ATTR_DMI) == 0 && DM_EVENT_ENABLED(ip, DM_EVENT_WRITE)) { if (end_dmi_offset > ip->i_size) end_dmi_offset = ip->i_size; @@ -3322,7 +3296,7 @@ xfs_free_file_space( return error; } - if (attr_flags & ATTR_NOLOCK) + if (attr_flags & XFS_ATTR_NOLOCK) need_iolock = 0; if (need_iolock) { xfs_ilock(ip, XFS_IOLOCK_EXCL); @@ -3499,7 +3473,7 @@ xfs_change_file_space( xfs_off_t startoffset; xfs_off_t llen; xfs_trans_t *tp; - bhv_vattr_t va; + struct iattr iattr; xfs_itrace_entry(ip); @@ -3573,10 +3547,10 @@ xfs_change_file_space( break; } - va.va_mask = XFS_AT_SIZE; - va.va_size = startoffset; + iattr.ia_valid = ATTR_SIZE; + iattr.ia_size = startoffset; - error = xfs_setattr(ip, &va, attr_flags, credp); + error = xfs_setattr(ip, &iattr, attr_flags, credp); if (error) return error; @@ -3606,7 +3580,7 @@ xfs_change_file_space( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); xfs_trans_ihold(tp, ip); - if ((attr_flags & ATTR_DMI) == 0) { + if ((attr_flags & XFS_ATTR_DMI) == 0) { ip->i_d.di_mode &= ~S_ISUID; /* Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2008-06-15 18:17:54.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2008-06-15 18:24:55.000000000 +0200 @@ -2,9 +2,9 @@ #define _XFS_VNODEOPS_H 1 struct attrlist_cursor_kern; -struct bhv_vattr; struct cred; struct file; +struct iattr; struct inode; struct iovec; struct kiocb; @@ -15,8 +15,12 @@ struct xfs_iomap; int xfs_open(struct xfs_inode *ip); -int xfs_setattr(struct xfs_inode *ip, struct bhv_vattr *vap, int flags, +int xfs_setattr(struct xfs_inode *ip, struct iattr *vap, int flags, struct cred *credp); +#define XFS_ATTR_DMI 0x01 /* invocation from a DMI function */ +#define XFS_ATTR_NONBLOCK 0x02 /* return EAGAIN if operation would block */ +#define XFS_ATTR_NOLOCK 0x04 /* Don't grab any conflicting locks */ + int xfs_readlink(struct xfs_inode *ip, char *link); int xfs_fsync(struct xfs_inode *ip); int xfs_release(struct xfs_inode *ip); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-15 18:27:12.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-15 18:27:53.000000000 +0200 @@ -684,9 +684,9 @@ xfs_ioc_space( return -XFS_ERROR(EFAULT); if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) - attr_flags |= ATTR_NONBLOCK; + attr_flags |= XFS_ATTR_NONBLOCK; if (ioflags & IO_INVIS) - attr_flags |= ATTR_DMI; + attr_flags |= XFS_ATTR_DMI; error = xfs_change_file_space(ip, cmd, &bf, filp->f_pos, NULL, attr_flags); Index: linux-2.6-xfs/fs/xfs/xfs_dmapi.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dmapi.h 2008-06-15 18:27:36.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_dmapi.h 2008-06-15 18:27:42.000000000 +0200 @@ -166,6 +166,6 @@ typedef enum { #define FILP_DELAY_FLAG(filp) ((filp->f_flags&(O_NDELAY|O_NONBLOCK)) ? \ DM_FLAGS_NDELAY : 0) -#define AT_DELAY_FLAG(f) ((f&ATTR_NONBLOCK) ? DM_FLAGS_NDELAY : 0) +#define AT_DELAY_FLAG(f) ((f & XFS_ATTR_NONBLOCK) ? DM_FLAGS_NDELAY : 0) #endif /* __XFS_DMAPI_H__ */ From owner-xfs@oss.sgi.com Fri Jun 27 09:10:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 09:10:16 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5RGAEhv032316 for ; Fri, 27 Jun 2008 09:10:14 -0700 X-ASG-Debug-ID: 1214583074-5f63022a0000-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 81607D68B4C; Fri, 27 Jun 2008 09:11:14 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id I3W9n45jO6aT4geM; Fri, 27 Jun 2008 09:11:14 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KCGXa-0001dW-A5; Fri, 27 Jun 2008 16:11:14 +0000 Date: Fri, 27 Jun 2008 12:11:14 -0400 From: Christoph Hellwig To: David Howells Cc: hch@infradead.org, tes@sgi.com, lachlan@sgi.com, xfs-masters@oss.sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] Fix disabled XFS POSIX ACL handling Subject: Re: [PATCH] Fix disabled XFS POSIX ACL handling Message-ID: <20080627161114.GA28296@infradead.org> References: <20080627124354.18978.72867.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080627124354.18978.72867.stgit@warthog.procyon.org.uk> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214583075 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.54499 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: 16631 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 01:43:54PM +0100, David Howells wrote: > Fix XFS POSIX ACL handling when it's not enabled. xfs_decode_acl() refers to > return types that aren't defined under those circumstances. The XFS tree already has a slightly different fix which should be in the next Linux-next tree. From owner-xfs@oss.sgi.com Fri Jun 27 11:56:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 11:56:38 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5RIuWKF017625 for ; Fri, 27 Jun 2008 11:56:34 -0700 X-ASG-Debug-ID: 1214593053-6c6800600000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp1.linux-foundation.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 357C3183D36E for ; Fri, 27 Jun 2008 11:57:33 -0700 (PDT) Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by cuda.sgi.com with ESMTP id wWTtLUHlX4dLCofb for ; Fri, 27 Jun 2008 11:57:33 -0700 (PDT) Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id m5RIvSeG018705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Jun 2008 11:57:29 -0700 Received: from akpm.corp.google.com (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id m5RIvRgI001117; Fri, 27 Jun 2008 11:57:28 -0700 Date: Fri, 27 Jun 2008 11:57:27 -0700 From: Andrew Morton To: "Takashi Sato" Cc: viro@ZenIV.linux.org.uk, linux-ext4@vger.kernel.org, xfs@oss.sgi.com, dm-devel@redhat.com, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature Message-Id: <20080627115727.149dcb2e.akpm@linux-foundation.org> In-Reply-To: <7B349EFCD35842D4ADAEB402D2BDCA4E@nsl.ad.nec.co.jp> References: <20080624160056t-sato@mail.jp.nec.com> <20080624150925.765155f0.akpm@linux-foundation.org> <7B349EFCD35842D4ADAEB402D2BDCA4E@nsl.ad.nec.co.jp> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 X-Barracuda-Connect: smtp1.linux-foundation.org[140.211.169.13] X-Barracuda-Start-Time: 1214593054 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.54506 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: 16632 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: xfs On Fri, 27 Jun 2008 20:33:58 +0900 "Takashi Sato" wrote: > >> case XFS_FSOP_GOING_FLAGS_DEFAULT: { > >> - struct super_block *sb = freeze_bdev(mp->m_super->s_bdev); > >> + struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, 0); > > > > Using NULL here is clearer and will, I expect, avoid a sparse warning. > > I checked it but I couldn't find a sparse warning in xfs_fsops.c. > Can you tell me how to use NULL? struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, NULL); :) It's much better to use NULL here rather than literal zero because the reader of this code can then say "ah-hah, we're passing in a pointer". Whereas plain old "0" could be a pointer or a scalar. We should always use NULL to represent a null pointer in the kernel. The one acceptable exception is when testing for nullness: if (ptr1) if (!ptr2) Often people will use if (ptr1 != NULL) if (ptr2 == NULL) in this case as well. (I prefer the shorter version personally, but either is OK). From owner-xfs@oss.sgi.com Fri Jun 27 17:01:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 17:01:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5S015Un002203 for ; Fri, 27 Jun 2008 17:01:06 -0700 X-ASG-Debug-ID: 1214611326-2e4802060000-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 453632966F1 for ; Fri, 27 Jun 2008 17:02:06 -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 9LT2omt8LzQwgxUy for ; Fri, 27 Jun 2008 17:02:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,718,1204464600"; d="scan'208";a="144841873" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 28 Jun 2008 09:32:04 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KCNtD-000482-5b; Sat, 28 Jun 2008 10:02:03 +1000 Date: Sat, 28 Jun 2008 10:02:03 +1000 From: Dave Chinner To: Sagar Borikar Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080628000203.GC29319@disturbed> Mail-Followup-To: Sagar Borikar , xfs@oss.sgi.com References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4864BD5D.1050202@pmc-sierra.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: 1214611327 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.54530 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: 16633 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 03:43:49PM +0530, Sagar Borikar wrote: > Dave Chinner wrote: >> Yes, but all the same pattern of corruption, so it is likely >> that it is one problem. >> >> All I can suggest is working out a reproducable test case in your >> development environment, attaching a debugger and start digging around >> in memory when the problem is hit and try to find out exactly what >> is corrupted. If you can't reproduce it or work out what is >> occurring to trigger the problem, then we're not going to be able to >> find the cause... >> > Thanks Dave > I did some experiments today with the corrupted filesystem. > setup : NAS box contains one volume /share and 10 subdirectories. > In first subdirectory sh1, I kept 512MB file. Through a script I > continuously copy this file > simultaneously from sh2 to sh10 subdirectories. > The script looks like > .... > while [ 1 ] > do > cp $1 $2 > done .... > uninterruptible sleep state continuously. Ran xfs_repair with -n option > on filesystem mounted on JBOD > Here is the output : .... > entry "iozone_68.tst" in shortform directory 67108993 references free > inode 67108995 .... > entry "iozone_68.tst" in shortform directory 100663425 references free > inode 100663427 .... > entry "iozone_68.tst" in shortform directory 301990016 references free > inode 301990019 .... > entry "iozone_68.tst" in shortform directory 335544448 references free > inode 335544451 .... > entry "iozone_68.tst" in shortform directory 402653313 references free > inode 402653318 .... And so on. There's a pattern here. Can you try to find out what part of your workload is producing these errors? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Fri Jun 27 17:04:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 17:04:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5S04MCQ002900 for ; Fri, 27 Jun 2008 17:04:22 -0700 X-ASG-Debug-ID: 1214611521-552601c50000-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 183791235C1A for ; Fri, 27 Jun 2008 17:05:22 -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 Dc5LfAsb6wHT8UzG for ; Fri, 27 Jun 2008 17:05:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,718,1204464600"; d="scan'208";a="144843058" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 28 Jun 2008 09:35:21 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KCNwK-0004Cw-TU; Sat, 28 Jun 2008 10:05:16 +1000 Date: Sat, 28 Jun 2008 10:05:16 +1000 From: Dave Chinner To: Sagar Borikar Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080628000516.GD29319@disturbed> Mail-Followup-To: Sagar Borikar , xfs@oss.sgi.com References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4864C001.2010308@pmc-sierra.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: 1214611523 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.54531 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: 16634 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 03:55:05PM +0530, Sagar Borikar wrote: > > Dave, > > I also got continuous exceptions > > > XFS internal error XFS_WANT_CORRUPTED_RETURN at line 296 of file > fs/xfs/xfs_alloc.c. Caller 0x802962c0 corrupt alloc btree. xfs_repair won't report errors in this btree; it simply rebuilds it. xfs_check will report errors in it, though. > So memory was also not available for pdflush threads to flush the data > back to disks. But when nothing to do with memory availabilty, I think. FWIW, can you send the output of xfs_growfs -n and details of the partitioning and volume config? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Fri Jun 27 17:08:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 17:08:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5S08F2c003746 for ; Fri, 27 Jun 2008 17:08:15 -0700 X-ASG-Debug-ID: 1214611755-310702480000-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 B0610296740 for ; Fri, 27 Jun 2008 17:09:16 -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 D7Hkn84drpeQrVgh for ; Fri, 27 Jun 2008 17:09:16 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,718,1204464600"; d="scan'208";a="144844065" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 28 Jun 2008 09:39:14 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KCO0A-0004I1-1s; Sat, 28 Jun 2008 10:09:14 +1000 Date: Sat, 28 Jun 2008 10:09:14 +1000 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: rfc: kill ino64 mount option Subject: Re: rfc: kill ino64 mount option Message-ID: <20080628000914.GE29319@disturbed> Mail-Followup-To: Christoph Hellwig , xfs@oss.sgi.com References: <20080627153928.GA31384@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080627153928.GA31384@lst.de> 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: 1214611756 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.54530 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: 16635 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 05:39:28PM +0200, Christoph Hellwig wrote: > Does anyone have objections to kill the ino64 mount option? It's purely > a debug tool to force inode numbers outside of the range representable > in 32bits and is quite invasive for something that could easily be > debugged by just having a large enough filesystem.. It's the "large enough fs" that is the problem. XFSQA uses small partitions for the most part, and this allows testing of 64 bit inode numbers with a standard qa config. That being said, I don't really if it goes or stays... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Fri Jun 27 17:45:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 17:45:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from 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 m5S0jc0F009050 for ; Fri, 27 Jun 2008 17:45:40 -0700 Received: from [134.15.251.1] (melb-sw-corp-251-1.corp.sgi.com [134.15.251.1]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id KAA08898; Sat, 28 Jun 2008 10:46:32 +1000 Message-ID: <486589E7.9010705@sgi.com> Date: Sat, 28 Jun 2008 10:46:31 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: rfc: kill ino64 mount option References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> In-Reply-To: <20080628000914.GE29319@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16636 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Fri, Jun 27, 2008 at 05:39:28PM +0200, Christoph Hellwig wrote: >> Does anyone have objections to kill the ino64 mount option? It's purely >> a debug tool to force inode numbers outside of the range representable >> in 32bits and is quite invasive for something that could easily be >> debugged by just having a large enough filesystem.. > > It's the "large enough fs" that is the problem. XFSQA uses > small partitions for the most part, and this allows testing > of 64 bit inode numbers with a standard qa config. > > That being said, I don't really if it goes or stays... Although ino64 has interoperability issues with 32bit apps, it does have significant performance advantages over inode32 for some storage topologies and workloads, i.e. it's generally desirable to keep inodes near their data, but with large configs inode32 can't always oblige. ino64 is not just a debug tool. We have a design proposal known as "inode32+" that essentially removes the direct mapping between inode number and disk offset. This will provide all the layout and performance benefits of ino64 without the interop issues. Until inode32+ is available, we need to keep ino64. Cheers -- Mark Goodwin markgw@sgi.com Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 ------------------------------------------------------------- From owner-xfs@oss.sgi.com Fri Jun 27 21:30:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 27 Jun 2008 21:30:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5S4UedA011704 for ; Fri, 27 Jun 2008 21:30:40 -0700 X-ASG-Debug-ID: 1214627500-09d102340000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8EA62183FF1D for ; Fri, 27 Jun 2008 21:31:40 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id wYo5rduX7A8p5Gwg for ; Fri, 27 Jun 2008 21:31:40 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 0445EAC6274; Fri, 27 Jun 2008 23:31:40 -0500 (CDT) Message-ID: <4865BEAB.4030108@sandeen.net> Date: Fri, 27 Jun 2008 23:31:39 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: rfc: kill ino64 mount option Subject: Re: rfc: kill ino64 mount option References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> <486589E7.9010705@sgi.com> In-Reply-To: <486589E7.9010705@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214627501 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.54548 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: 16637 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Mark Goodwin wrote: > > Dave Chinner wrote: >> On Fri, Jun 27, 2008 at 05:39:28PM +0200, Christoph Hellwig wrote: >>> Does anyone have objections to kill the ino64 mount option? It's purely >>> a debug tool to force inode numbers outside of the range representable >>> in 32bits and is quite invasive for something that could easily be >>> debugged by just having a large enough filesystem.. >> It's the "large enough fs" that is the problem. XFSQA uses >> small partitions for the most part, and this allows testing >> of 64 bit inode numbers with a standard qa config. >> >> That being said, I don't really if it goes or stays... > > Although ino64 has interoperability issues with 32bit apps, it does > have significant performance advantages over inode32 for some > storage topologies and workloads, i.e. it's generally desirable to > keep inodes near their data, but with large configs inode32 can't > always oblige. ino64 is not just a debug tool. You're confusing inode64, which allows inodes > 32 bits, with ino64, which forces all inodes > 32 bits. The latter debugging option is what Christoph wants to remove... Christoph, the "large enough fs" could be sparse I guess but you still need to play tricks to get enough inodes up high I think.... I was actually considering using ino64 just to see what breaks in fedora. :) I guess I'm ambivalent too, is it really that invasive? Maybe 10, 15 lines of code looks like? -Eric From owner-xfs@oss.sgi.com Sat Jun 28 08:22:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 28 Jun 2008 08:22:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5SFMDGd010812 for ; Sat, 28 Jun 2008 08:22:14 -0700 X-ASG-Debug-ID: 1214666593-627c01ed0000-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 AD4AD79707D for ; Sat, 28 Jun 2008 08:23:14 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id 2l2eyhuGMIWF0Z5S for ; Sat, 28 Jun 2008 08:23:14 -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 m5SFN4NW022568 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 28 Jun 2008 17:23:04 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5SFN4Ua022566; Sat, 28 Jun 2008 17:23:04 +0200 Date: Sat, 28 Jun 2008 17:23:03 +0200 From: Christoph Hellwig To: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: rfc: kill ino64 mount option Subject: Re: rfc: kill ino64 mount option Message-ID: <20080628152303.GA22484@lst.de> References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080628000914.GE29319@disturbed> 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: 1214666595 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.54591 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: 16638 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Sat, Jun 28, 2008 at 10:09:14AM +1000, Dave Chinner wrote: > On Fri, Jun 27, 2008 at 05:39:28PM +0200, Christoph Hellwig wrote: > > Does anyone have objections to kill the ino64 mount option? It's purely > > a debug tool to force inode numbers outside of the range representable > > in 32bits and is quite invasive for something that could easily be > > debugged by just having a large enough filesystem.. > > It's the "large enough fs" that is the problem. XFSQA uses > small partitions for the most part, and this allows testing > of 64 bit inode numbers with a standard qa config. Well, it allows showing 64bit inode numbers to userspace. All XFS internal codepathes are still using the smaller inode numbers and we only add a fixed offset to them just before the inode number is returned to userspace. From owner-xfs@oss.sgi.com Sat Jun 28 08:24:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 28 Jun 2008 08:24:50 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5SFOmBw011331 for ; Sat, 28 Jun 2008 08:24:48 -0700 X-ASG-Debug-ID: 1214666749-6f88029e0000-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 5433218472A3 for ; Sat, 28 Jun 2008 08:25:49 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id ByOnIINMZeKeIgxE for ; Sat, 28 Jun 2008 08:25:49 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m5SFPeNW022651 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 28 Jun 2008 17:25:40 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m5SFPeSK022649; Sat, 28 Jun 2008 17:25:40 +0200 Date: Sat, 28 Jun 2008 17:25:40 +0200 From: Christoph Hellwig To: Eric Sandeen Cc: markgw@sgi.com, Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: rfc: kill ino64 mount option Subject: Re: rfc: kill ino64 mount option Message-ID: <20080628152540.GB22484@lst.de> References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> <486589E7.9010705@sgi.com> <4865BEAB.4030108@sandeen.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4865BEAB.4030108@sandeen.net> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1214666750 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.54591 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: 16639 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 11:31:39PM -0500, Eric Sandeen wrote: > I guess I'm ambivalent too, is it really that invasive? Maybe 10, 15 > lines of code looks like? Currently it's implemented by adding m_inoadd surrounded by an #if XFS_BIG_INUMS. This can be cleaned up by adding a helper ala xfs_ino_t xfs_user_ino(struct xfs_mount *mp, xfs_ino_t ino); but I don't really see the point as the option seems quite useless. But if others thing the option is worth keeping around I'll do the helper instead.I'll do the helper instead. From owner-xfs@oss.sgi.com Sat Jun 28 09:46:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 28 Jun 2008 09:46:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_26 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5SGkFUX020180 for ; Sat, 28 Jun 2008 09:46:17 -0700 X-ASG-Debug-ID: 1214671636-364f00530000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta01.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 00EC129869E for ; Sat, 28 Jun 2008 09:47:16 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id BvADjiWvwg6yD1pJ for ; Sat, 28 Jun 2008 09:47:16 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 787B51890535; Sat, 28 Jun 2008 09:50:08 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta01.pmc-sierra.bc.ca (Postfix) with SMTP id 620631890534; Sat, 28 Jun 2008 09:50:08 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Sat, 28 Jun 2008 09:47:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: RE: Xfs Access to block zero exception and system crash Subject: RE: Xfs Access to block zero exception and system crash Date: Sat, 28 Jun 2008 09:47:44 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <20080628000516.GD29319@disturbed> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: AcjYsr3q6U6/B/qYQIyigWes0WoXhgAi5b8g References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> From: "Sagar Borikar" To: "Dave Chinner" Cc: X-OriginalArrivalTime: 28 Jun 2008 16:47:47.0608 (UTC) FILETIME=[B1E8C180:01C8D93E] X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1214671637 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.54597 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 m5SGkHUX020182 X-archive-position: 16640 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Sagar_Borikar@pmc-sierra.com Precedence: bulk X-list: xfs Dave, Attaching required information: > nothing to do with memory availabilty, I think. > FWIW, can you send the output of xfs_growfs -n and details > of the partitioning and volume config? [root@NAS001ee5ab9c85 ~]# xfs_growfs -n /mnt/RAIDA/vol/ meta-data=/dev/RAIDA/vol isize=256 agcount=16, agsize=1638400 blks = sectsz=512 attr=1 data = bsize=4096 blocks=26214400, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming=version 2 bsize=4096 log =internal bsize=4096 blocks=12800, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 [root@NAS001ee5ab9c85 ~]# cat /etc/fstab /dev/root / ext2 rw,noauto 0 1 proc /proc proc defaults 0 0 devpts /dev/pts devpts defaults,gid=5,mode=620 0 0 tmpfs /tmp tmpfs defaults 0 0 /dev/RAIDA/vol /mnt/RAIDA/vol xfs defaults,usrquota,grpquota 0 0 /mnt/RAIDA/vol/sh /mnt/ftp_dir/sh none rw,bind 0 0 /mnt/RAIDA/vol/.autohome/ /mnt/ftp_dir/homes none rw,bind 0 0 [root@NAS001ee5ab9c85 ~]# fdisk -l Disk /dev/scsibd: 257 MB, 257425408 bytes 8 heads, 32 sectors/track, 1964 cylinders Units = cylinders of 256 * 512 = 131072 bytes Device Boot Start End Blocks Id System /dev/scsibd1 126 286 20608 83 Linux /dev/scsibd2 287 1023 94336 83 Linux /dev/scsibd3 1149 1309 20608 83 Linux /dev/scsibd4 1310 2046 94336 83 Linux Disk /dev/md0: 251.0 GB, 251000160256 bytes 2 heads, 4 sectors/track, 61279336 cylinders Units = cylinders of 8 * 512 = 4096 bytes Disk /dev/md0 doesn't contain a valid partition table Disk /dev/dm-0: 107.3 GB, 107374182400 bytes 255 heads, 63 sectors/track, 13054 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes But still the issue is why doesn't it happen every time and less stress? I am surprised to see to let this happen immediately when the subdirectories increase more than 30. Else it decays slowly. Thanks Sagar Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sat Jun 28 12:51:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 28 Jun 2008 12:51:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5SJp8ac012389 for ; Sat, 28 Jun 2008 12:51:08 -0700 X-ASG-Debug-ID: 1214682729-73a101fc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60E6212376DB for ; Sat, 28 Jun 2008 12:52:09 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id KlLhRKRkRDFoppP7 for ; Sat, 28 Jun 2008 12:52:09 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 09C9CAC6274; Sat, 28 Jun 2008 14:52:09 -0500 (CDT) Message-ID: <48669668.4060204@sandeen.net> Date: Sat, 28 Jun 2008 14:52:08 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: markgw@sgi.com, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: rfc: kill ino64 mount option Subject: Re: rfc: kill ino64 mount option References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> <486589E7.9010705@sgi.com> <4865BEAB.4030108@sandeen.net> <20080628152540.GB22484@lst.de> In-Reply-To: <20080628152540.GB22484@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214682730 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.54608 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: 16641 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 27, 2008 at 11:31:39PM -0500, Eric Sandeen wrote: >> I guess I'm ambivalent too, is it really that invasive? Maybe 10, 15 >> lines of code looks like? > > Currently it's implemented by adding m_inoadd surrounded by an > #if XFS_BIG_INUMS. This can be cleaned up by adding a helper ala > > xfs_ino_t xfs_user_ino(struct xfs_mount *mp, xfs_ino_t ino); > > but I don't really see the point as the option seems quite useless. But > if others thing the option is worth keeping around I'll do the helper > instead. Well, to be honest i've never even enabled it :) how much does xfsqa use it? I guess I don't really care if it goes. -Eric From owner-xfs@oss.sgi.com Sat Jun 28 13:07:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 28 Jun 2008 13:07: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.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 m5SK7afJ014343 for ; Sat, 28 Jun 2008 13:07:37 -0700 X-ASG-Debug-ID: 1214683718-7d3101c80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3F5C1237BDF for ; Sat, 28 Jun 2008 13:08:38 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id iROmFbJ3qzLezsdF for ; Sat, 28 Jun 2008 13:08:38 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id DCB82AC6274; Sat, 28 Jun 2008 15:08:37 -0500 (CDT) Message-ID: <48669A45.1050104@sandeen.net> Date: Sat, 28 Jun 2008 15:08:37 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Donald Douwsma CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] re-remove xfs custom bitops Subject: Re: [PATCH] re-remove xfs custom bitops References: <480EB397.1040304@sandeen.net> <4829C360.5060500@sandeen.net> <482BF841.8050704@sgi.com> In-Reply-To: <482BF841.8050704@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1214683718 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.54610 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: 16642 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Donald Douwsma wrote: > Eric Sandeen wrote: >> Eric Sandeen wrote: >>> Once more, with feeling! >>> >>> This re-instates the reverted mod after the ppc panic of >>> Feb '08. You guys do have ppc boxes in the test farm now right? :) >>> >>> This keeps xfs_lowbit64 as it was since there aren't good >>> generic helpers there ... >>> >>> This should probably keep Dave's signed-off line, there's >>> a bit of my (userspace) testing here but no original work. >>> >>> This exact patch isn't tested but it's based on a conglomeration >>> of prior testing... >> SGI guys, any takers on this one? >> -Eric > > Sorry Eric, havent had chance to run this on all platforms yet. > I want to test it on ppc as well as the usual x86_64/ia64 combinations, > then I'll get it committed. > > Don Don, how's that all going then? :) Thanks, -Eric From owner-xfs@oss.sgi.com Sun Jun 29 14:55:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 14:56: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_26,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 m5TLtnF3024528 for ; Sun, 29 Jun 2008 14:55:51 -0700 X-ASG-Debug-ID: 1214776609-73f800f60000-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 5C5F2184E584 for ; Sun, 29 Jun 2008 14:56:50 -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 njN4bQa5qpDTfJve for ; Sun, 29 Jun 2008 14:56:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,724,1204464600"; d="scan'208";a="145959223" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 30 Jun 2008 07:26:48 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KD4t5-0007fM-RS; Mon, 30 Jun 2008 07:56:47 +1000 Date: Mon, 30 Jun 2008 07:56:47 +1000 From: Dave Chinner To: Sagar Borikar Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080629215647.GJ29319@disturbed> Mail-Followup-To: Sagar Borikar , xfs@oss.sgi.com References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> 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: 1214776611 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.54710 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: 16643 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 Sat, Jun 28, 2008 at 09:47:44AM -0700, Sagar Borikar wrote: > > FWIW, can you send the output of xfs_growfs -n and details > > of the partitioning and volume config? .... > [root@NAS001ee5ab9c85 ~]# cat /etc/fstab > /dev/root / ext2 rw,noauto 0 1 > proc /proc proc defaults 0 0 > devpts /dev/pts devpts defaults,gid=5,mode=620 0 > 0 > tmpfs /tmp tmpfs defaults 0 0 > /dev/RAIDA/vol /mnt/RAIDA/vol xfs defaults,usrquota,grpquota > 0 0 > /mnt/RAIDA/vol/sh /mnt/ftp_dir/sh none rw,bind 0 0 > /mnt/RAIDA/vol/.autohome/ /mnt/ftp_dir/homes none rw,bind > 0 0 > > [root@NAS001ee5ab9c85 ~]# fdisk -l > > Disk /dev/scsibd: 257 MB, 257425408 bytes > 8 heads, 32 sectors/track, 1964 cylinders > Units = cylinders of 256 * 512 = 131072 bytes > > Device Boot Start End Blocks Id System > /dev/scsibd1 126 286 20608 83 Linux > /dev/scsibd2 287 1023 94336 83 Linux > /dev/scsibd3 1149 1309 20608 83 Linux > /dev/scsibd4 1310 2046 94336 83 Linux I'd have to assume thats a flash based root drive, right? > Disk /dev/md0: 251.0 GB, 251000160256 bytes > 2 heads, 4 sectors/track, 61279336 cylinders > Units = cylinders of 8 * 512 = 4096 bytes > > Disk /dev/md0 doesn't contain a valid partition table > > Disk /dev/dm-0: 107.3 GB, 107374182400 bytes > 255 heads, 63 sectors/track, 13054 cylinders > Units = cylinders of 16065 * 512 = 8225280 bytes Neither of these tell me what /dev/RAIDA/vol is.... > But still the issue is why doesn't it happen every time and less stress? > > I am surprised to see to let this happen immediately when the > subdirectories increase more than 30. Else it decays slowly. So it happens when you get more than 30 entries in a directory under a certain load? That might be an extent->btree format conversion bug or vice versa. I'd suggest setting up a test based around this to try to narrow down the problem. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 29 15:01:24 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 15:01: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.4 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 m5TM1N1l025265 for ; Sun, 29 Jun 2008 15:01:23 -0700 X-ASG-Debug-ID: 1214776944-571b03ab0000-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 CCB13184E5AC for ; Sun, 29 Jun 2008 15:02:24 -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 FS48DM1lgyjFvL0m for ; Sun, 29 Jun 2008 15:02:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,724,1204464600"; d="scan'208";a="145961169" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 30 Jun 2008 07:32:22 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KD4yT-0007md-PJ; Mon, 30 Jun 2008 08:02:21 +1000 Date: Mon, 30 Jun 2008 08:02:21 +1000 From: Dave Chinner To: Niv Sardi Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] Introduce xfs_trans_bmap_add_attrfork. Subject: Re: [PATCH] Introduce xfs_trans_bmap_add_attrfork. Message-ID: <20080629220221.GK29319@disturbed> Mail-Followup-To: Niv Sardi , xfs@oss.sgi.com References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <1214196150-5427-4-git-send-email-xaiki@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214196150-5427-4-git-send-email-xaiki@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214776945 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.54710 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: 16644 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 23, 2008 at 02:42:29PM +1000, Niv Sardi wrote: > That takes a transaction and doesn't require everything to be locked > anymore. this uses the roll trans call. ..... > error2: > + if (tpp) > + tpp = &tp; That's clearly busted. if (tpp) *tpp = tp; > xfs_bmap_cancel(&flist); > error1: > ASSERT(ismrlocked(&ip->i_lock,MR_UPDATE)); > - xfs_iunlock(ip, XFS_ILOCK_EXCL); > + if (tpp) > + tpp = &tp; ditto. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 29 15:08:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 15:08:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,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 m5TM80w4026073 for ; Sun, 29 Jun 2008 15:08:00 -0700 X-ASG-Debug-ID: 1214777341-6c8e022c0000-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 67E73184E657 for ; Sun, 29 Jun 2008 15:09:01 -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 EIELMah3L0c57opM for ; Sun, 29 Jun 2008 15:09:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LFnm/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,724,1204464600"; d="scan'208";a="145964039" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 30 Jun 2008 07:39:00 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KD54t-0007vy-ED; Mon, 30 Jun 2008 08:08:59 +1000 Date: Mon, 30 Jun 2008 08:08:59 +1000 From: Dave Chinner To: Niv Sardi Cc: xfs@oss.sgi.com, Niv Sardi X-ASG-Orig-Subj: Re: [PATCH] Give a transaction to xfs_attr_set_int Subject: Re: [PATCH] Give a transaction to xfs_attr_set_int Message-ID: <20080629220859.GL29319@disturbed> Mail-Followup-To: Niv Sardi , xfs@oss.sgi.com, Niv Sardi References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <1214196150-5427-4-git-send-email-xaiki@sgi.com> <1214196150-5427-5-git-send-email-xaiki@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214196150-5427-5-git-send-email-xaiki@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1214777342 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.54710 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: 16645 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 23, 2008 at 02:42:30PM +1000, Niv Sardi wrote: > From: Niv Sardi > > We introduce xfs_trans_attr_set_int that takes a transaction pointer > as an argument (or creates one if NULL) and only finishes the > transaction if it has created it. We use xfs_attr_rolltrans to do the > tranS_dup dance. > > xfs_attr_set_int is changed to a wrapper that will only call > xfs_trans_attr_set_int with a NULL transaction. As a general comment to the entire patch set, I dislike the namespace pollution caused by changing xfs_attr_... to xfs_trans_attr... The xfs_trans_... namespace is used for stuff inside xfs_trans*[ch], not for attr code. I'd suggest making the "trans" a suffix rather than a prefix, or something similar, so that these attr functions are not easily confused with core transaction code.... BTW: > @@ -356,6 +381,8 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, > if (!error && (flags & ATTR_KERNOTIME) == 0) { > xfs_ichgtime(dp, XFS_ICHGTIME_CHG); > } > + if (tpp) > + tpp = &args.trans; That's busted too. Can you please review all the places where you return transactio pointers to the caller via a function parameterrr for this bug as you've made in at least a couple of places. > + if (tpp) > + tpp = &args.trans; Here as well. > return(error); > > out: > @@ -434,10 +467,25 @@ out: > xfs_trans_cancel(args.trans, > XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_ABORT); > xfs_iunlock(dp, XFS_ILOCK_EXCL); > + if (tpp) > + tpp = &args.trans; And again. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jun 29 16:13:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 16:14:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 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 m5TNDqj1031804 for ; Sun, 29 Jun 2008 16:13:53 -0700 X-ASG-Debug-ID: 1214781294-653c00380000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice2.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4B588D6F159 for ; Sun, 29 Jun 2008 16:14:54 -0700 (PDT) Received: from postoffice2.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id KrpGqnWRHCba23gW for ; Sun, 29 Jun 2008 16:14:54 -0700 (PDT) Received: from postoffice.aconex.com (localhost [127.0.0.1]) by postoffice2.aconex.com (Spam Firewall) with ESMTP id 7D6332B12EA; Mon, 30 Jun 2008 09:14:47 +1000 (EST) Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.3.1]) by postoffice2.aconex.com with ESMTP id 49L7m3h9QQpyp2hW; Mon, 30 Jun 2008 09:14:47 +1000 (EST) Received: from [192.168.5.24] (unknown [203.89.192.141]) by postoffice.aconex.com (Postfix) with ESMTP id 727C292C2EB; Mon, 30 Jun 2008 09:14:47 +1000 (EST) X-ASG-Orig-Subj: Re: rfc: kill ino64 mount option Subject: Re: rfc: kill ino64 mount option From: Nathan Scott To: Christoph Hellwig Cc: xfs@oss.sgi.com In-Reply-To: <20080628152303.GA22484@lst.de> References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> <20080628152303.GA22484@lst.de> Content-Type: text/plain Date: Mon, 30 Jun 2008 09:13:34 +1000 Message-Id: <1214781214.4609.1.camel@verge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1214781295 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.54715 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: 16647 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Sat, 2008-06-28 at 17:23 +0200, Christoph Hellwig wrote: > On Sat, Jun 28, 2008 at 10:09:14AM +1000, Dave Chinner wrote: > > On Fri, Jun 27, 2008 at 05:39:28PM +0200, Christoph Hellwig wrote: > > > Does anyone have objections to kill the ino64 mount option? It's purely > > > a debug tool to force inode numbers outside of the range representable > > > in 32bits and is quite invasive for something that could easily be > > > debugged by just having a large enough filesystem.. > > > > It's the "large enough fs" that is the problem. XFSQA uses > > small partitions for the most part, and this allows testing > > of 64 bit inode numbers with a standard qa config. > > Well, it allows showing 64bit inode numbers to userspace. All XFS > internal codepathes are still using the smaller inode numbers and we > only add a fixed offset to them just before the inode number is returned > to userspace. I'd vote for removing it - I've used it in the past, and it didn't do what I wanted (its not really useful for XFS testing) and the confusion it causes with inode64 is not worth it. cheers. -- Nathan From owner-xfs@oss.sgi.com Sun Jun 29 16:12:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 16:12:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE 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 m5TNCmIF031429 for ; Sun, 29 Jun 2008 16:12:49 -0700 X-ASG-Debug-ID: 1214781229-14ef03340000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6F085184E8AC for ; Sun, 29 Jun 2008 16:13:49 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id uEeFRjBwiIaq8Va4 for ; Sun, 29 Jun 2008 16:13:49 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5TND8Ur002294; Mon, 30 Jun 2008 08:13:08 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5TND8d14451; Mon, 30 Jun 2008 08:13:08 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5TND70q013040; Mon, 30 Jun 2008 08:13:07 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Mon, 30 Jun 2008 08:13:07 +0900 Message-Id: From: "Takashi Sato" To: "Andrew Morton" Cc: , , , , , , , References: <20080624160056t-sato@mail.jp.nec.com><20080624150925.765155f0.akpm@linux-foundation.org><7B349EFCD35842D4ADAEB402D2BDCA4E@nsl.ad.nec.co.jp> <20080627115727.149dcb2e.akpm@linux-foundation.org> In-Reply-To: <20080627115727.149dcb2e.akpm@linux-foundation.org> X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature Date: Mon, 30 Jun 2008 08:13:07 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193] X-Barracuda-Start-Time: 1214781230 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.54714 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: 16646 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi, >> >> case XFS_FSOP_GOING_FLAGS_DEFAULT: { >> >> - struct super_block *sb = freeze_bdev(mp->m_super->s_bdev); >> >> + struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, 0); >> > >> > Using NULL here is clearer and will, I expect, avoid a sparse warning. >> >> I checked it but I couldn't find a sparse warning in xfs_fsops.c. >> Can you tell me how to use NULL? > > struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, NULL); > > :) > > It's much better to use NULL here rather than literal zero because the > reader of this code can then say "ah-hah, we're passing in a pointer". > Whereas plain old "0" could be a pointer or a scalar. The second argument's type of freeze_bdev() is "long", not pointer as below. struct super_block *freeze_bdev(struct block_device *, long timeout_msec); So "0" is reasonable, isn't it? > We should always use NULL to represent a null pointer in the kernel. > The one acceptable exception is when testing for nullness: > > if (ptr1) > if (!ptr2) > > Often people will use > > if (ptr1 != NULL) > if (ptr2 == NULL) > > in this case as well. (I prefer the shorter version personally, but > either is OK). From owner-xfs@oss.sgi.com Sun Jun 29 17:00:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 17:00: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.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 m5U00uLQ007989 for ; Sun, 29 Jun 2008 17:00:56 -0700 X-ASG-Debug-ID: 1214784117-21ef00f70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp1.linux-foundation.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 422EC29B2A7 for ; Sun, 29 Jun 2008 17:01:57 -0700 (PDT) Received: from smtp1.linux-foundation.org (smtp1.linux-foundation.org [140.211.169.13]) by cuda.sgi.com with ESMTP id aPlNd2TlN0DqbAaK for ; Sun, 29 Jun 2008 17:01:57 -0700 (PDT) Received: from imap1.linux-foundation.org (imap1.linux-foundation.org [140.211.169.55]) by smtp1.linux-foundation.org (8.14.2/8.13.5/Debian-3ubuntu1.1) with ESMTP id m5U01rAj008800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Jun 2008 17:01:54 -0700 Received: from y.localdomain (localhost [127.0.0.1]) by imap1.linux-foundation.org (8.13.5.20060308/8.13.5/Debian-3ubuntu1.1) with SMTP id m5U01qN5012112; Sun, 29 Jun 2008 17:01:52 -0700 Date: Sun, 29 Jun 2008 17:01:52 -0700 From: Andrew Morton To: "Takashi Sato" Cc: , , , , , , , X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature Message-Id: <20080629170152.aa769918.akpm@linux-foundation.org> In-Reply-To: References: <20080624160056t-sato@mail.jp.nec.com> <20080624150925.765155f0.akpm@linux-foundation.org> <7B349EFCD35842D4ADAEB402D2BDCA4E@nsl.ad.nec.co.jp> <20080627115727.149dcb2e.akpm@linux-foundation.org> X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.5; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: lf$Revision: 1.188 $ X-Scanned-By: MIMEDefang 2.63 on 140.211.169.13 X-Barracuda-Connect: smtp1.linux-foundation.org[140.211.169.13] X-Barracuda-Start-Time: 1214784118 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.54718 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: 16648 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: xfs On Mon, 30 Jun 2008 08:13:07 +0900 "Takashi Sato" wrote: > > It's much better to use NULL here rather than literal zero because the > > reader of this code can then say "ah-hah, we're passing in a pointer". > > Whereas plain old "0" could be a pointer or a scalar. > > The second argument's type of freeze_bdev() is "long", not pointer as below. > struct super_block *freeze_bdev(struct block_device *, long timeout_msec); oh, ok, I goofed, sorry. > So "0" is reasonable, isn't it? yup. From owner-xfs@oss.sgi.com Sun Jun 29 18:44:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 18:44:12 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=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 m5U1i9ra015741 for ; Sun, 29 Jun 2008 18:44:10 -0700 X-ASG-Debug-ID: 1214790311-4e5c02430000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from qb-out-1314.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 026EE29B52A for ; Sun, 29 Jun 2008 18:45:11 -0700 (PDT) Received: from qb-out-1314.google.com (qb-out-1314.google.com [72.14.204.175]) by cuda.sgi.com with ESMTP id kZedGB2UHRnv9jVg for ; Sun, 29 Jun 2008 18:45:11 -0700 (PDT) Received: by qb-out-1314.google.com with SMTP id d2so3345459qbc.32 for ; Sun, 29 Jun 2008 18:45:10 -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:user-agent :x-accept-language:mime-version:to:subject:content-type :content-transfer-encoding:from; bh=5eqprYdrTJDiI+SvQbziD2cadGU/KFWhvrSBxTDnFI8=; b=kLWgOu9+h8nTFu1L6sCVXWgByVwDpb5MHTXsCBF1VIGqjXKT0K/MCCa0gUimZJ+Tkw wodpIhdqBdFn2UJfiwGbIGwHG+VsSyWunLB9qpoKFewid5ucV3B20GjcGHBGUJZtiVPN li6NA3v3kWpcINguv/t9jxLadwDvcclUzJyAk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:user-agent:x-accept-language:mime-version:to :subject:content-type:content-transfer-encoding:from; b=mQgy+F78xpLAOAdgr9B4TntHeE5OPMut/iL1su1CIrZpVmqz6cjhrkUrpZadU+58UJ gWpSH8jg1NvIfG3dwIXv8LY9fdLyFy6vQa1k7tDvKjjR+WqnNoo0oon1lkLKstyzihBm tB5j2gJF2Ebp096+xM2D4jkTcK/67LOHdVDXI= Received: by 10.150.197.8 with SMTP id u8mr7412320ybf.122.1214790310460; Sun, 29 Jun 2008 18:45:10 -0700 (PDT) Received: from gmail.com ( [190.177.208.253]) by mx.google.com with ESMTPS id 34sm514412yxm.9.2008.06.29.18.45.04 (version=SSLv3 cipher=RC4-MD5); Sun, 29 Jun 2008 18:45:09 -0700 (PDT) Message-ID: Date: Mon, 30 Jun 2008 02:29:40 +0000 User-Agent: Mozilla/4.7 [ja] (Macintosh; U; PPC) X-Accept-Language: en-us MIME-Version: 1.0 To: "Member Service" X-ASG-Orig-Subj: American Chinese Stocks Subject: American Chinese Stocks Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: Ruthie Ulery X-Barracuda-Connect: qb-out-1314.google.com[72.14.204.175] X-Barracuda-Start-Time: 1214790312 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5534 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.75 X-Barracuda-Spam-Status: No, SCORE=0.75 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54722 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: 16649 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: kirstenwehyr@gmail.com Precedence: bulk X-list: xfs ASIC Asiana Corporation. We like it because it’s a Chinese based Pay Pal system. Very tightly held! 21 Asian banks already in locked in. Look around the site and filings they are about to launch a Ticket Master type program. MEGA ROOM FOR GROWTH! Small announcement made of becoming a reporting issuer = Growth and HUGE potential!!! Low almost non existant volume. We have been following this one for 18 months plus. The train is about to GO! Asiana Corporation ASIC Last .07 China is Hot!! ASIC is pleased to announce that its operating subsidiary Iexpay has completed an agreement with Shanghai Jike Information Company. (Jike) "Jike provides real time air ticket data and hotel booking data in China. ASIC is pleased to announce that its operating subsidiary Iexpay has completed a set up of its IT laboratory in University of Science and Technology Beijing. The founder and CEO of Iexpay company Mr. Xu headed the entrepreneurial forum in the Beijing Zhongguancun. Zhongguancun was known as "electronics avenue", because of its connections to information technology and the preponderance of stores along a central, crowded street. Zhongguancun was given the wordy name "Beijing High-Technology Industry Development Experimental Zone". - Asiana Corp (ASIC) finalizes contracts with Shanghai Jike Information Company- - Asiana Corp (ASIC) sets up IT laboratory in University of Science and Technology Beijing- - Asiana Corp (ASIC) Signs LOI To Sell Its IEXPAY Division- - Asiana Corp (ASIC) Signs Agreement with Shanghai Bank Union- From owner-xfs@oss.sgi.com Sun Jun 29 18:50:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 18:50: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.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 m5U1oUV9016399 for ; Sun, 29 Jun 2008 18:50:31 -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 LAA17088 for ; Mon, 30 Jun 2008 11:51:31 +1000 Date: Mon, 30 Jun 2008 11:51:32 +1000 To: "xfs@oss.sgi.com" Subject: REVIEW: Fix xfs_check SEGV when encountering an unreadable block From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------emVJWnFPfvdRW8j9NxjBBH 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 X-archive-position: 16650 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 ------------emVJWnFPfvdRW8j9NxjBBH Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: Quoted-Printable xfs_check (xfs_db "check" command) internally uses a stack for I/Os it reads/writes. In the check command, there are a few places where the I/O stack is pushed, a read is issued and the read fails but does not pop the stack location back. In nested uses of this stack, the caller then accesses this un-popped block which the data pointer is "NULL" causing a SEGV. I've checked all calls to push_cur()/set_cur() to make sure all failures call pop_cur(). -- check.c | 45 +++++++++++++++++++++++---------------------- 1 file changed, 23 insertions(+), 22 deletions(-) --- a/xfsprogs/db/check.c 2008-06-30 11:46:26.000000000 +1000 +++ b/xfsprogs/db/check.c 2008-06-30 11:44:58.759289182 +1000 @@ -1991,6 +1991,7 @@ process_block_dir_v2( "%lld\n", id->ino); error++; + pop_cur(); return 0; } dir_hash_init(); @@ -2951,6 +2952,7 @@ process_leaf_dir_v1( "%lld\n", id->ino); error++; + pop_cur(); return 0; } parent =3D process_leaf_dir_v1_int(dot, dotdot, id); @@ -3322,6 +3324,7 @@ process_node_dir_v1( v =3D verbose || id->ilist; parent =3D 0; dbno =3D NULLFILEOFF; + push_cur(); while ((dbno =3D blkmap_next_off(blkmap, dbno, &t)) !=3D NULLFILEOFF) { bno =3D blkmap_get(blkmap, dbno); v2 =3D bno !=3D NULLFSBLOCK && CHECK_BLIST(bno); @@ -3337,6 +3340,7 @@ process_node_dir_v1( (__uint32_t)dbno, (xfs_dfsbno_t)bno); if (bno =3D=3D NULLFSBLOCK) continue; + pop_cur(); push_cur(); set_cur(&typtab[TYP_DIR], XFS_FSB_TO_DADDR(mp, bno), blkbb, DB_RING_IGN, NULL); @@ -3353,10 +3357,7 @@ process_node_dir_v1( #else if (INT_GET(node->hdr.info.magic, ARCH_CONVERT) =3D=3D XFS_DIR_NODE_MAG= IC) #endif - { - pop_cur(); continue; - } lino =3D process_leaf_dir_v1_int(dot, dotdot, id); if (lino) { if (parent) { @@ -3368,8 +3369,8 @@ process_node_dir_v1( } else parent =3D lino; } - pop_cur(); } + pop_cur(); return parent; } @@ -3411,8 +3412,7 @@ process_quota( perblock =3D (uint)(mp->m_sb.sb_blocksize / sizeof(*dqb)); dqid =3D 0; qbno =3D NULLFILEOFF; - while ((qbno =3D blkmap_next_off(blkmap, qbno, &t)) !=3D - NULLFILEOFF) { + while ((qbno =3D blkmap_next_off(blkmap, qbno, &t)) !=3D NULLFILEOFF) { bno =3D blkmap_get(blkmap, qbno); dqid =3D (xfs_dqid_t)qbno * perblock; cb =3D CHECK_BLIST(bno); @@ -3421,13 +3421,13 @@ process_quota( set_cur(&typtab[TYP_DQBLK], XFS_FSB_TO_DADDR(mp, bno), blkbb, DB_RING_IGN, NULL); if ((dqb =3D iocur_top->data) =3D=3D NULL) { - pop_cur(); if (scicb) dbprintf("can't read block %lld for %s quota " "inode (fsblock %lld)\n", (xfs_dfiloff_t)qbno, s, (xfs_dfsbno_t)bno); error++; + pop_cur(); continue; } for (i =3D 0; i < perblock; i++, dqid++, dqb++) { @@ -3525,12 +3525,12 @@ process_rtbitmap( set_cur(&typtab[TYP_RTBITMAP], XFS_FSB_TO_DADDR(mp, bno), blkbb, DB_RING_IGN, NULL); if ((words =3D iocur_top->data) =3D=3D NULL) { - pop_cur(); if (!sflag) dbprintf("can't read block %lld for rtbitmap " "inode\n", (xfs_dfiloff_t)bmbno); error++; + pop_cur(); continue; } for (bit =3D 0; @@ -3578,8 +3578,7 @@ process_rtsummary( int t; sumbno =3D NULLFILEOFF; - while ((sumbno =3D blkmap_next_off(blkmap, sumbno, &t)) !=3D - NULLFILEOFF) { + while ((sumbno =3D blkmap_next_off(blkmap, sumbno, &t)) !=3D NULLFILEOFF)= { bno =3D blkmap_get(blkmap, sumbno); if (bno =3D=3D NULLFSBLOCK) { if (!sflag) @@ -3598,6 +3597,7 @@ process_rtsummary( "inode\n", (xfs_dfiloff_t)sumbno); error++; + pop_cur(); continue; } memcpy((char *)sumfile + sumbno * mp->m_sb.sb_blocksize, bytes, @@ -3906,16 +3906,15 @@ scan_ag( agffreeblks =3D agflongest =3D 0; agfbtreeblks =3D -2; agicount =3D agifreecount =3D 0; - push_cur(); + push_cur(); /* 1 pushed */ set_cur(&typtab[TYP_SB], XFS_AG_DADDR(mp, agno, XFS_SB_DADDR), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if (!iocur_top->data) { dbprintf("can't read superblock for ag %u\n", agno); - pop_cur(); serious_error++; - return; + goto pop1_out; } libxfs_xlate_sb(iocur_top->data, sb, 1, XFS_SB_ALL_BITS); @@ -3945,16 +3944,14 @@ scan_ag( if (sb->sb_logstart && XFS_FSB_TO_AGNO(mp, sb->sb_logstart) =3D=3D agno) set_dbmap(agno, XFS_FSB_TO_AGBNO(mp, sb->sb_logstart), sb->sb_logblocks, DBM_LOG, agno, XFS_SB_BLOCK(mp)); - push_cur(); + push_cur(); /* 2 pushed */ set_cur(&typtab[TYP_AGF], XFS_AG_DADDR(mp, agno, XFS_AGF_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if ((agf =3D iocur_top->data) =3D=3D NULL) { dbprintf("can't read agf block for ag %u\n", agno); - pop_cur(); - pop_cur(); serious_error++; - return; + goto pop2_out; } if (INT_GET(agf->agf_magicnum, ARCH_CONVERT) !=3D XFS_AGF_MAGIC) { if (!sflag) @@ -3975,17 +3972,14 @@ scan_ag( set_dbmap(agno, INT_GET(agf->agf_length, ARCH_CONVERT), sb->sb_agblocks - INT_GET(agf->agf_length, ARCH_CONVERT), DBM_MISSING, agno, XFS_SB_BLOCK(mp)); - push_cur(); + push_cur(); /* 3 pushed */ set_cur(&typtab[TYP_AGI], XFS_AG_DADDR(mp, agno, XFS_AGI_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if ((agi =3D iocur_top->data) =3D=3D NULL) { dbprintf("can't read agi block for ag %u\n", agno); serious_error++; - pop_cur(); - pop_cur(); - pop_cur(); - return; + goto pop3_out; } if (INT_GET(agi->agi_magicnum, ARCH_CONVERT) !=3D XFS_AGI_MAGIC) { if (!sflag) @@ -4066,8 +4060,11 @@ scan_ag( error++; } } +pop3_out: pop_cur(); +pop2_out: pop_cur(); +pop1_out: pop_cur(); } @@ -4095,6 +4092,7 @@ scan_freelist( if ((agfl =3D iocur_top->data) =3D=3D NULL) { dbprintf("can't read agfl block for ag %u\n", seqno); serious_error++; + pop_cur(); return; } i =3D INT_GET(agf->agf_flfirst, ARCH_CONVERT); @@ -4144,6 +4142,7 @@ scan_lbtree( XFS_FSB_TO_AGNO(mp, root), XFS_FSB_TO_AGBNO(mp, root)); error++; + pop_cur(); return; } (*func)(iocur_top->data, nlevels - 1, type, root, id, totd, toti, nex, @@ -4169,6 +4168,7 @@ scan_sbtree( if (!sflag) dbprintf("can't read btree block %u/%u\n", seqno, root); error++; + pop_cur(); return; } (*func)(iocur_top->data, nlevels - 1, agf, root, isroot); @@ -4484,6 +4484,7 @@ scanfunc_ino( seqno, XFS_AGINO_TO_AGBNO(mp, agino)); error++; + pop_cur(); continue; } for (j =3D 0, nfree =3D 0; j < XFS_INODES_PER_CHUNK; j++) { ------------emVJWnFPfvdRW8j9NxjBBH Content-Disposition: attachment; filename=fix_check_segv.patch Content-Type: text/x-patch; name=fix_check_segv.patch Content-Transfer-Encoding: Quoted-Printable --- a/xfsprogs/db/check.c 2008-06-30 11:46:26.000000000 +1000 +++ b/xfsprogs/db/check.c 2008-06-30 11:44:58.759289182 +1000 @@ -1991,6 +1991,7 @@ process_block_dir_v2( "%lld\n", id->ino); error++; + pop_cur(); return 0; } dir_hash_init(); @@ -2951,6 +2952,7 @@ process_leaf_dir_v1( "%lld\n", id->ino); error++; + pop_cur(); return 0; } parent =3D process_leaf_dir_v1_int(dot, dotdot, id); @@ -3322,6 +3324,7 @@ process_node_dir_v1( v =3D verbose || id->ilist; parent =3D 0; dbno =3D NULLFILEOFF; + push_cur(); while ((dbno =3D blkmap_next_off(blkmap, dbno, &t)) !=3D NULLFILEOFF) { bno =3D blkmap_get(blkmap, dbno); v2 =3D bno !=3D NULLFSBLOCK && CHECK_BLIST(bno); @@ -3337,6 +3340,7 @@ process_node_dir_v1( (__uint32_t)dbno, (xfs_dfsbno_t)bno); if (bno =3D=3D NULLFSBLOCK) continue; + pop_cur(); push_cur(); set_cur(&typtab[TYP_DIR], XFS_FSB_TO_DADDR(mp, bno), blkbb, DB_RING_IGN, NULL); @@ -3353,10 +3357,7 @@ process_node_dir_v1( #else if (INT_GET(node->hdr.info.magic, ARCH_CONVERT) =3D=3D XFS_DIR_NODE_MAGI= C) #endif - { - pop_cur(); continue; - } lino =3D process_leaf_dir_v1_int(dot, dotdot, id); if (lino) { if (parent) { @@ -3368,8 +3369,8 @@ process_node_dir_v1( } else parent =3D lino; } - pop_cur(); } + pop_cur(); return parent; } =20 @@ -3411,8 +3412,7 @@ process_quota( perblock =3D (uint)(mp->m_sb.sb_blocksize / sizeof(*dqb)); dqid =3D 0; qbno =3D NULLFILEOFF; - while ((qbno =3D blkmap_next_off(blkmap, qbno, &t)) !=3D - NULLFILEOFF) { + while ((qbno =3D blkmap_next_off(blkmap, qbno, &t)) !=3D NULLFILEOFF) { bno =3D blkmap_get(blkmap, qbno); dqid =3D (xfs_dqid_t)qbno * perblock; cb =3D CHECK_BLIST(bno); @@ -3421,13 +3421,13 @@ process_quota( set_cur(&typtab[TYP_DQBLK], XFS_FSB_TO_DADDR(mp, bno), blkbb, DB_RING_IGN, NULL); if ((dqb =3D iocur_top->data) =3D=3D NULL) { - pop_cur(); if (scicb) dbprintf("can't read block %lld for %s quota " "inode (fsblock %lld)\n", (xfs_dfiloff_t)qbno, s, (xfs_dfsbno_t)bno); error++; + pop_cur(); continue; } for (i =3D 0; i < perblock; i++, dqid++, dqb++) { @@ -3525,12 +3525,12 @@ process_rtbitmap( set_cur(&typtab[TYP_RTBITMAP], XFS_FSB_TO_DADDR(mp, bno), blkbb, DB_RING_IGN, NULL); if ((words =3D iocur_top->data) =3D=3D NULL) { - pop_cur(); if (!sflag) dbprintf("can't read block %lld for rtbitmap " "inode\n", (xfs_dfiloff_t)bmbno); error++; + pop_cur(); continue; } for (bit =3D 0; @@ -3578,8 +3578,7 @@ process_rtsummary( int t; =20 sumbno =3D NULLFILEOFF; - while ((sumbno =3D blkmap_next_off(blkmap, sumbno, &t)) !=3D - NULLFILEOFF) { + while ((sumbno =3D blkmap_next_off(blkmap, sumbno, &t)) !=3D NULLFILEOFF)= { bno =3D blkmap_get(blkmap, sumbno); if (bno =3D=3D NULLFSBLOCK) { if (!sflag) @@ -3598,6 +3597,7 @@ process_rtsummary( "inode\n", (xfs_dfiloff_t)sumbno); error++; + pop_cur(); continue; } memcpy((char *)sumfile + sumbno * mp->m_sb.sb_blocksize, bytes, @@ -3906,16 +3906,15 @@ scan_ag( agffreeblks =3D agflongest =3D 0; agfbtreeblks =3D -2; agicount =3D agifreecount =3D 0; - push_cur(); + push_cur(); /* 1 pushed */ set_cur(&typtab[TYP_SB], XFS_AG_DADDR(mp, agno, XFS_SB_DADDR), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); =20 if (!iocur_top->data) { dbprintf("can't read superblock for ag %u\n", agno); - pop_cur(); serious_error++; - return; + goto pop1_out; } =20 libxfs_xlate_sb(iocur_top->data, sb, 1, XFS_SB_ALL_BITS); @@ -3945,16 +3944,14 @@ scan_ag( if (sb->sb_logstart && XFS_FSB_TO_AGNO(mp, sb->sb_logstart) =3D=3D agno) set_dbmap(agno, XFS_FSB_TO_AGBNO(mp, sb->sb_logstart), sb->sb_logblocks, DBM_LOG, agno, XFS_SB_BLOCK(mp)); - push_cur(); + push_cur(); /* 2 pushed */ set_cur(&typtab[TYP_AGF], XFS_AG_DADDR(mp, agno, XFS_AGF_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if ((agf =3D iocur_top->data) =3D=3D NULL) { dbprintf("can't read agf block for ag %u\n", agno); - pop_cur(); - pop_cur(); serious_error++; - return; + goto pop2_out; } if (INT_GET(agf->agf_magicnum, ARCH_CONVERT) !=3D XFS_AGF_MAGIC) { if (!sflag) @@ -3975,17 +3972,14 @@ scan_ag( set_dbmap(agno, INT_GET(agf->agf_length, ARCH_CONVERT), sb->sb_agblocks - INT_GET(agf->agf_length, ARCH_CONVERT), DBM_MISSING, agno, XFS_SB_BLOCK(mp)); - push_cur(); + push_cur(); /* 3 pushed */ set_cur(&typtab[TYP_AGI], XFS_AG_DADDR(mp, agno, XFS_AGI_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if ((agi =3D iocur_top->data) =3D=3D NULL) { dbprintf("can't read agi block for ag %u\n", agno); serious_error++; - pop_cur(); - pop_cur(); - pop_cur(); - return; + goto pop3_out; } if (INT_GET(agi->agi_magicnum, ARCH_CONVERT) !=3D XFS_AGI_MAGIC) { if (!sflag) @@ -4066,8 +4060,11 @@ scan_ag( error++; } } +pop3_out: pop_cur(); +pop2_out: pop_cur(); +pop1_out: pop_cur(); } =20 @@ -4095,6 +4092,7 @@ scan_freelist( if ((agfl =3D iocur_top->data) =3D=3D NULL) { dbprintf("can't read agfl block for ag %u\n", seqno); serious_error++; + pop_cur(); return; } i =3D INT_GET(agf->agf_flfirst, ARCH_CONVERT); @@ -4144,6 +4142,7 @@ scan_lbtree( XFS_FSB_TO_AGNO(mp, root), XFS_FSB_TO_AGBNO(mp, root)); error++; + pop_cur(); return; } (*func)(iocur_top->data, nlevels - 1, type, root, id, totd, toti, nex, @@ -4169,6 +4168,7 @@ scan_sbtree( if (!sflag) dbprintf("can't read btree block %u/%u\n", seqno, root); error++; + pop_cur(); return; } (*func)(iocur_top->data, nlevels - 1, agf, root, isroot); @@ -4484,6 +4484,7 @@ scanfunc_ino( seqno, XFS_AGINO_TO_AGBNO(mp, agino)); error++; + pop_cur(); continue; } for (j =3D 0, nfree =3D 0; j < XFS_INODES_PER_CHUNK; j++) { ------------emVJWnFPfvdRW8j9NxjBBH-- From owner-xfs@oss.sgi.com Sun Jun 29 20:36:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 20:37:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 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 m5U3auqT001257 for ; Sun, 29 Jun 2008 20:36:58 -0700 X-ASG-Debug-ID: 1214797078-1f7d03470000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta03.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9B03829B7ED for ; Sun, 29 Jun 2008 20:37:58 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (bby1mta03.pmc-sierra.com [216.241.235.118]) by cuda.sgi.com with ESMTP id MqF89RLH4OzD7hGH for ; Sun, 29 Jun 2008 20:37:58 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id A1AB61070587 for ; Sun, 29 Jun 2008 20:40:26 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta03.pmc-sierra.bc.ca (Postfix) with SMTP id 2F5231070591 for ; Sun, 29 Jun 2008 20:40:24 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Sun, 29 Jun 2008 20:38:29 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Sun, 29 Jun 2008 20:38:28 -0700 Message-ID: <48685510.6060603@pmc-sierra.com> Date: Mon, 30 Jun 2008 09:07:52 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> In-Reply-To: <20080629215647.GJ29319@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2008 03:38:29.0186 (UTC) FILETIME=[C2EA8A20:01C8DA62] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.6.30.31317 X-PMC-SpamCheck: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_1600_1699 0, BODY_SIZE_5000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Barracuda-Connect: bby1mta03.pmc-sierra.com[216.241.235.118] X-Barracuda-Start-Time: 1214797078 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0574 1.0000 -1.6536 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.65 X-Barracuda-Spam-Status: No, SCORE=-1.65 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54730 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: 16651 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Sat, Jun 28, 2008 at 09:47:44AM -0700, Sagar Borikar wrote: > > Device Boot Start End Blocks Id System >> /dev/scsibd1 126 286 20608 83 Linux >> /dev/scsibd2 287 1023 94336 83 Linux >> /dev/scsibd3 1149 1309 20608 83 Linux >> /dev/scsibd4 1310 2046 94336 83 Linux >> > > I'd have to assume thats a flash based root drive, right? > > That's right, >> Disk /dev/md0: 251.0 GB, 251000160256 bytes >> 2 heads, 4 sectors/track, 61279336 cylinders >> Units = cylinders of 8 * 512 = 4096 bytes >> >> Disk /dev/md0 doesn't contain a valid partition table >> >> Disk /dev/dm-0: 107.3 GB, 107374182400 bytes >> 255 heads, 63 sectors/track, 13054 cylinders >> Units = cylinders of 16065 * 512 = 8225280 bytes >> > > Neither of these tell me what /dev/RAIDA/vol is.... > It is the device node to which /mnt/RAIDA/vol is mapped to. Its a JBOD with 233 GB size. > >> But still the issue is why doesn't it happen every time and less stress? >> >> I am surprised to see to let this happen immediately when the >> subdirectories increase more than 30. Else it decays slowly. >> > > So it happens when you get more than 30 entries in a directory > under a certain load? That might be an extent->btree format > conversion bug or vice versa. I'd suggest setting up a test based > around this to try to narrow down the problem. > > Cheers, > > Dave. > Thanks for all your help. Shall keep you posted with the progress on debugging. Regards Sagar From owner-xfs@oss.sgi.com Sun Jun 29 22:46:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 22:46: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=-1.2 required=5.0 tests=AWL,BAYES_00,URIBL_BLACK 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 m5U5jxGG014624 for ; Sun, 29 Jun 2008 22:46:01 -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 PAA20693; Mon, 30 Jun 2008 15:46:55 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 1A5FA58C4C29; Mon, 30 Jun 2008 15:46:55 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 907752 - Add AC_PROG_LIBTOOL to configure file Message-Id: <20080630054655.1A5FA58C4C29@chook.melbourne.sgi.com> Date: Mon, 30 Jun 2008 15:46:55 +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: 16652 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 Date: Mon Jun 30 15:46:18 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: nathans@aconex.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31373a attr/configure.in - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/configure.in.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - Add AC_PROG_LIBTOOL From owner-xfs@oss.sgi.com Sun Jun 29 23:06:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 23:06:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5U66PC7016228 for ; Sun, 29 Jun 2008 23:06:25 -0700 X-ASG-Debug-ID: 1214806046-1a5603be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta03.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 880BA1239AB0 for ; Sun, 29 Jun 2008 23:07:27 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (bby1mta03.pmc-sierra.com [216.241.235.118]) by cuda.sgi.com with ESMTP id dXiK2ua1FRBgiFA2 for ; Sun, 29 Jun 2008 23:07:27 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 872061070598 for ; Sun, 29 Jun 2008 23:09:55 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta03.pmc-sierra.bc.ca (Postfix) with SMTP id 5C904107049A for ; Sun, 29 Jun 2008 23:09:55 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Sun, 29 Jun 2008 23:08:00 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Sun, 29 Jun 2008 23:07:59 -0700 Message-ID: <4868781B.40907@pmc-sierra.com> Date: Mon, 30 Jun 2008 11:37:23 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> In-Reply-To: <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2008 06:08:00.0112 (UTC) FILETIME=[A6013700:01C8DA77] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.6.30.54814 X-PMC-SpamCheck: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_2000_2999 0, BODY_SIZE_5000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Barracuda-Connect: bby1mta03.pmc-sierra.com[216.241.235.118] X-Barracuda-Start-Time: 1214806047 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0241 1.0000 -1.8646 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.86 X-Barracuda-Spam-Status: No, SCORE=-1.86 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.54742 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: 16653 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Sagar Borikar wrote: > Dave Chinner wrote: >> On Sat, Jun 28, 2008 at 09:47:44AM -0700, Sagar Borikar wrote: >> Device Boot Start End Blocks Id System >>> /dev/scsibd1 126 286 20608 83 Linux >>> /dev/scsibd2 287 1023 94336 83 Linux >>> /dev/scsibd3 1149 1309 20608 83 Linux >>> /dev/scsibd4 1310 2046 94336 83 Linux >>> >> >> I'd have to assume thats a flash based root drive, right? >> >> > That's right, >>> Disk /dev/md0: 251.0 GB, 251000160256 bytes >>> 2 heads, 4 sectors/track, 61279336 cylinders >>> Units = cylinders of 8 * 512 = 4096 bytes >>> >>> Disk /dev/md0 doesn't contain a valid partition table >>> >>> Disk /dev/dm-0: 107.3 GB, 107374182400 bytes >>> 255 heads, 63 sectors/track, 13054 cylinders >>> Units = cylinders of 16065 * 512 = 8225280 bytes >>> >> >> Neither of these tell me what /dev/RAIDA/vol is.... >> It is the device node to which /mnt/RAIDA/vol is mapped to. Its a >> JBOD with 233 GB size. >> >>> But still the issue is why doesn't it happen every time and less >>> stress? >>> >>> I am surprised to see to let this happen immediately when the >>> subdirectories increase more than 30. Else it decays slowly. >>> >> >> So it happens when you get more than 30 entries in a directory >> under a certain load? That might be an extent->btree format >> conversion bug or vice versa. I'd suggest setting up a test based >> around this to try to narrow down the problem. >> >> Cheers, >> >> Dave. >> > Thanks for all your help. Shall keep you posted with the progress on > debugging. > > Regards > Sagar > > Sorry if I was not clear. As I mentioned the frequency of finding bad extents is much higher when I increase simultaneous transactions to 30 ( say in 5 min ) but if I run only two copies in infinite loop, the issue crops up in 2-3 hours roughly. And all the copies plus pdflush are in uninterruptible sleep state continuously. And it is not uninterruptible sleep and waiting state ( DW ) but just uninterruptible ( D ). Thanks Sagar From owner-xfs@oss.sgi.com Sun Jun 29 23:20:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 29 Jun 2008 23:20:56 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-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 m5U6Ko5m017575 for ; Sun, 29 Jun 2008 23:20:51 -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 QAA21246; Mon, 30 Jun 2008 16:21:45 +1000 Message-ID: <48687B79.6050101@sgi.com> Date: Mon, 30 Jun 2008 16:21:45 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] fix mount option parsing in remount References: <20080518153539.GA5218@lst.de> In-Reply-To: <20080518153539.GA5218@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-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: 16654 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > 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); typo: s/support/supported/ Looking at ext3 and other XFS out of curiosity: "XFS: unknown mount option [%s].", this_char "EXT3-fs: Unrecognized mount option \"%s\" " ./smbfs/getopt.c: printk("%s: Unrecognized mount option %s\n", caller, token); Though I see for remount it is more a question of support versus recognising it or not. Ok. > + 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; > } > I'm a little confused why we call xfs_mountfs_check_barriers(mp) in 2 places. Oh okay, so you want it tested if we have barrier option and currently not-readonly or after we transition to not-readonly. And you have it around the parsing code because you don't care about what it might transition to in the current not-readonly case. I think we ideally should have a qa test for this. We have 017 but it doesn't do any barrier or illegal options. --Tim From owner-xfs@oss.sgi.com Mon Jun 30 00:09:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 00:09:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5U79Phu022769 for ; Mon, 30 Jun 2008 00:09:27 -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 RAA22221; Mon, 30 Jun 2008 17:10:22 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1161) id 4575F58C4C29; Mon, 30 Jun 2008 17:10:22 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com Cc: xfs@oss.sgi.com Subject: TAKE 907752 - Update attr to 2.4.43 Message-Id: <20080630071022.4575F58C4C29@chook.melbourne.sgi.com> Date: Mon, 30 Jun 2008 17:10:22 +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: 16655 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 Date: Mon Jun 30 17:09:50 AEST 2008 Workarea: chook.melbourne.sgi.com:/home/bnaujok/isms/xfs-cmds Inspected by: bnaujok The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/xfs-cmds/master-melb Modid: master-melb:xfs-cmds:31376a attr/VERSION - 1.73 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/VERSION.diff?r1=text&tr1=1.73&r2=text&tr2=1.72&f=h attr/doc/CHANGES - 1.89 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-cmds/attr/doc/CHANGES.diff?r1=text&tr1=1.89&r2=text&tr2=1.88&f=h - Update to 2.4.43 From owner-xfs@oss.sgi.com Mon Jun 30 00:51:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 00:51:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5U7pKDc030150 for ; Mon, 30 Jun 2008 00:51:22 -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 RAA23153 for ; Mon, 30 Jun 2008 17:52:21 +1000 Date: Mon, 30 Jun 2008 17:53:53 +1000 To: "xfs@oss.sgi.com" Subject: REVIEW: xfs_metadump improvements From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------YV3huUsCLm2zPlwEmnbw53 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 X-archive-position: 16656 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 ------------YV3huUsCLm2zPlwEmnbw53 Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: Quoted-Printable Based on what I found in xfs_check, I fixed up xfs_metadump in the same way. Also, I've increased the default maximum expected extent size for a directory, as in practice, 400 block extents for directory structures is not rare. -- --- a/xfsprogs/db/metadump.c 2008-06-30 17:51:10.000000000 +1000 +++ b/xfsprogs/db/metadump.c 2008-06-30 17:45:59.609352130 +1000 @@ -27,6 +27,8 @@ #include "sig.h" #include "xfs_metadump.h" +#define DEFAULT_MAX_EXT_SIZE 1000 + /* copy all metadata structures to/from a file */ static int metadump_f(int argc, char **argv); @@ -58,7 +60,7 @@ static xfs_ino_t cur_ino; static int show_progress =3D 0; static int stop_on_read_error =3D 0; -static int max_extent_size =3D 20; +static int max_extent_size =3D DEFAULT_MAX_EXT_SIZE; static int dont_obfuscate =3D 0; static int show_warnings =3D 0; static int progress_since_warning =3D 0; @@ -80,10 +82,10 @@ metadump_help(void) " Options:\n" " -e -- Ignore read errors and keep going\n" " -g -- Display dump progress\n" -" -m -- Specify max extent size in blocks to copy (default =3D 20=20=20 blocks)\n" +" -m -- Specify max extent size in blocks to copy (default =3D %d=20=20 blocks)\n" " -o -- Don't obfuscate names and extended attributes\n" " -w -- Show warnings of bad metadata information\n" -"\n"); +"\n", DEFAULT_MAX_EXT_SIZE); } static void @@ -186,22 +188,26 @@ scan_btree( typnm_t btype, void *arg)) { + int rval =3D 0; + push_cur(); set_cur(&typtab[btype], XFS_AGB_TO_DADDR(mp, agno, agbno), blkbb, DB_RING_IGN, NULL); if (iocur_top->data =3D=3D NULL) { print_warning("cannot read %s block %u/%u", typtab[btype].name, agno, agbno); - return !stop_on_read_error; + rval =3D !stop_on_read_error; + goto pop_out; } if (!write_buf(iocur_top)) - return 0; + goto pop_out; if (!(*func)(iocur_top->data, agno, agbno, level - 1, btype, arg)) - return 0; - + goto pop_out; + rval =3D 1; +pop_out: pop_cur(); - return 1; + return rval; } /* free space tree copy routines */ @@ -949,8 +955,10 @@ process_bmbt_reclist( if (iocur_top->data =3D=3D NULL) { print_warning("cannot read %s block %u/%u (%llu)", typtab[btype].name, agno, agbno, s); - if (stop_on_read_error) + if (stop_on_read_error) { + pop_cur(); return 0; + } } else { if (!dont_obfuscate) switch (btype) { @@ -973,8 +981,10 @@ process_bmbt_reclist( default: ; } - if (!write_buf(iocur_top)) + if (!write_buf(iocur_top)) { + pop_cur(); return 0; + } } pop_cur(); } @@ -1238,6 +1248,7 @@ copy_inode_chunk( int off; xfs_agblock_t agbno; int i; + int rval =3D 0; agino =3D be32_to_cpu(rp->ir_startino); agbno =3D XFS_AGINO_TO_AGBNO(mp, agino); @@ -1258,7 +1269,8 @@ copy_inode_chunk( DB_RING_IGN, NULL); if (iocur_top->data =3D=3D NULL) { print_warning("cannot read inode block %u/%u", agno, agbno); - return !stop_on_read_error; + rval =3D !stop_on_read_error; + goto pop_out; } /* @@ -1291,11 +1303,11 @@ copy_inode_chunk( ((off + i) << mp->m_sb.sb_inodelog)); if (!process_inode(agno, agino + i, dip)) - return 0; + goto pop_out; } skip_processing: if (!write_buf(iocur_top)) - return 0; + goto pop_out; inodes_copied +=3D XFS_INODES_PER_CHUNK; @@ -1303,10 +1315,10 @@ skip_processing: print_progress("Copied %u of %u inodes (%u of %u AGs)", inodes_copied, mp->m_sb.sb_icount, agno, mp->m_sb.sb_agcount); - + rval =3D 1; +pop_out: pop_cur(); - - return 1; + return rval; } static int @@ -1401,61 +1413,66 @@ scan_ag( { xfs_agf_t *agf; xfs_agi_t *agi; + int stack_count =3D 0; + int rval =3D 0; /* copy the superblock of the AG */ push_cur(); + stack_count++; set_cur(&typtab[TYP_SB], XFS_AG_DADDR(mp, agno, XFS_SB_DADDR), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if (!iocur_top->data) { print_warning("cannot read superblock for ag %u", agno); if (stop_on_read_error) - return 0; + goto pop_out; } else { if (!write_buf(iocur_top)) - return 0; + goto pop_out; } /* copy the AG free space btree root */ push_cur(); + stack_count++; set_cur(&typtab[TYP_AGF], XFS_AG_DADDR(mp, agno, XFS_AGF_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); agf =3D iocur_top->data; if (iocur_top->data =3D=3D NULL) { print_warning("cannot read agf block for ag %u", agno); if (stop_on_read_error) - return 0; + goto pop_out; } else { if (!write_buf(iocur_top)) - return 0; + goto pop_out; } /* copy the AG inode btree root */ push_cur(); + stack_count++; set_cur(&typtab[TYP_AGI], XFS_AG_DADDR(mp, agno, XFS_AGI_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); agi =3D iocur_top->data; if (iocur_top->data =3D=3D NULL) { print_warning("cannot read agi block for ag %u", agno); if (stop_on_read_error) - return 0; + goto pop_out; } else { if (!write_buf(iocur_top)) - return 0; + goto pop_out; } /* copy the AG free list header */ push_cur(); + stack_count++; set_cur(&typtab[TYP_AGFL], XFS_AG_DADDR(mp, agno, XFS_AGFL_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if (iocur_top->data =3D=3D NULL) { print_warning("cannot read agfl block for ag %u", agno); if (stop_on_read_error) - return 0; + goto pop_out; } else { if (!write_buf(iocur_top)) - return 0; + goto pop_out; } - pop_cur(); /* copy AG free space btrees */ if (agf) { @@ -1463,22 +1480,21 @@ scan_ag( print_progress("Copying free space trees of AG %u", agno); if (!copy_free_bno_btree(agno, agf)) - return 0; + goto pop_out; if (!copy_free_cnt_btree(agno, agf)) - return 0; + goto pop_out; } /* copy inode btrees and the inodes and their associated metadata */ if (agi) { if (!copy_inodes(agno, agi)) - return 0; + goto pop_out; } - - pop_cur(); - pop_cur(); - pop_cur(); - - return 1; + rval =3D 1; +pop_out: + while (stack_count--) + pop_cur(); + return rval; } static int @@ -1492,6 +1508,7 @@ copy_ino( xfs_dinode_t *dip; xfs_dinode_core_t tdic; int offset; + int rval =3D 0; if (ino =3D=3D 0) return 1; @@ -1515,7 +1532,8 @@ copy_ino( if (iocur_top->data =3D=3D NULL) { print_warning("cannot read %s inode %lld", typtab[itype].name, (long long)ino); - return !stop_on_read_error; + rval =3D !stop_on_read_error; + goto pop_out; } off_cur(offset << mp->m_sb.sb_inodelog, mp->m_sb.sb_inodesize); @@ -1524,7 +1542,10 @@ copy_ino( memcpy(&dip->di_core, &tdic, sizeof(xfs_dinode_core_t)); cur_ino =3D ino; - return process_inode_data(dip, itype); + rval =3D process_inode_data(dip, itype); +pop_out: + pop_cur(); + return rval; } @@ -1553,6 +1574,7 @@ copy_log(void) set_cur(&typtab[TYP_LOG], XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), mp->m_sb.sb_logblocks * blkbb, DB_RING_IGN, NULL); if (iocur_top->data =3D=3D NULL) { + pop_cur(); print_warning("cannot read log"); return !stop_on_read_error; } ------------YV3huUsCLm2zPlwEmnbw53 Content-Disposition: attachment; filename=fix_metadump.patch Content-Type: text/x-patch; name=fix_metadump.patch Content-Transfer-Encoding: Quoted-Printable --- a/xfsprogs/db/metadump.c 2008-06-30 17:51:10.000000000 +1000 +++ b/xfsprogs/db/metadump.c 2008-06-30 17:45:59.609352130 +1000 @@ -27,6 +27,8 @@ #include "sig.h" #include "xfs_metadump.h" =20 +#define DEFAULT_MAX_EXT_SIZE 1000 + /* copy all metadata structures to/from a file */ =20 static int metadump_f(int argc, char **argv); @@ -58,7 +60,7 @@ static xfs_ino_t cur_ino; =20 static int show_progress =3D 0; static int stop_on_read_error =3D 0; -static int max_extent_size =3D 20; +static int max_extent_size =3D DEFAULT_MAX_EXT_SIZE; static int dont_obfuscate =3D 0; static int show_warnings =3D 0; static int progress_since_warning =3D 0; @@ -80,10 +82,10 @@ metadump_help(void) " Options:\n" " -e -- Ignore read errors and keep going\n" " -g -- Display dump progress\n" -" -m -- Specify max extent size in blocks to copy (default =3D 20 blocks= )\n" +" -m -- Specify max extent size in blocks to copy (default =3D %d blocks= )\n" " -o -- Don't obfuscate names and extended attributes\n" " -w -- Show warnings of bad metadata information\n" -"\n"); +"\n", DEFAULT_MAX_EXT_SIZE); } =20 static void @@ -186,22 +188,26 @@ scan_btree( typnm_t btype, void *arg)) { + int rval =3D 0; + push_cur(); set_cur(&typtab[btype], XFS_AGB_TO_DADDR(mp, agno, agbno), blkbb, DB_RING_IGN, NULL); if (iocur_top->data =3D=3D NULL) { print_warning("cannot read %s block %u/%u", typtab[btype].name, agno, agbno); - return !stop_on_read_error; + rval =3D !stop_on_read_error; + goto pop_out; } if (!write_buf(iocur_top)) - return 0; + goto pop_out; =20 if (!(*func)(iocur_top->data, agno, agbno, level - 1, btype, arg)) - return 0; - + goto pop_out; + rval =3D 1; +pop_out: pop_cur(); - return 1; + return rval; } =20 /* free space tree copy routines */ @@ -949,8 +955,10 @@ process_bmbt_reclist( if (iocur_top->data =3D=3D NULL) { print_warning("cannot read %s block %u/%u (%llu)", typtab[btype].name, agno, agbno, s); - if (stop_on_read_error) + if (stop_on_read_error) { + pop_cur(); return 0; + } } else { if (!dont_obfuscate) switch (btype) { @@ -973,8 +981,10 @@ process_bmbt_reclist( =20 default: ; } - if (!write_buf(iocur_top)) + if (!write_buf(iocur_top)) { + pop_cur(); return 0; + } } pop_cur(); } @@ -1238,6 +1248,7 @@ copy_inode_chunk( int off; xfs_agblock_t agbno; int i; + int rval =3D 0; =20 agino =3D be32_to_cpu(rp->ir_startino); agbno =3D XFS_AGINO_TO_AGBNO(mp, agino); @@ -1258,7 +1269,8 @@ copy_inode_chunk( DB_RING_IGN, NULL); if (iocur_top->data =3D=3D NULL) { print_warning("cannot read inode block %u/%u", agno, agbno); - return !stop_on_read_error; + rval =3D !stop_on_read_error; + goto pop_out; } =20 /* @@ -1291,11 +1303,11 @@ copy_inode_chunk( ((off + i) << mp->m_sb.sb_inodelog)); =20 if (!process_inode(agno, agino + i, dip)) - return 0; + goto pop_out; } skip_processing: if (!write_buf(iocur_top)) - return 0; + goto pop_out; =20 inodes_copied +=3D XFS_INODES_PER_CHUNK; =20 @@ -1303,10 +1315,10 @@ skip_processing: print_progress("Copied %u of %u inodes (%u of %u AGs)", inodes_copied, mp->m_sb.sb_icount, agno, mp->m_sb.sb_agcount); - + rval =3D 1; +pop_out: pop_cur(); - - return 1; + return rval; } =20 static int @@ -1401,61 +1413,66 @@ scan_ag( { xfs_agf_t *agf; xfs_agi_t *agi; + int stack_count =3D 0; + int rval =3D 0; =20 /* copy the superblock of the AG */ push_cur(); + stack_count++; set_cur(&typtab[TYP_SB], XFS_AG_DADDR(mp, agno, XFS_SB_DADDR), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if (!iocur_top->data) { print_warning("cannot read superblock for ag %u", agno); if (stop_on_read_error) - return 0; + goto pop_out; } else { if (!write_buf(iocur_top)) - return 0; + goto pop_out; } =20 /* copy the AG free space btree root */ push_cur(); + stack_count++; set_cur(&typtab[TYP_AGF], XFS_AG_DADDR(mp, agno, XFS_AGF_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); agf =3D iocur_top->data; if (iocur_top->data =3D=3D NULL) { print_warning("cannot read agf block for ag %u", agno); if (stop_on_read_error) - return 0; + goto pop_out; } else { if (!write_buf(iocur_top)) - return 0; + goto pop_out; } =20 /* copy the AG inode btree root */ push_cur(); + stack_count++; set_cur(&typtab[TYP_AGI], XFS_AG_DADDR(mp, agno, XFS_AGI_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); agi =3D iocur_top->data; if (iocur_top->data =3D=3D NULL) { print_warning("cannot read agi block for ag %u", agno); if (stop_on_read_error) - return 0; + goto pop_out; } else { if (!write_buf(iocur_top)) - return 0; + goto pop_out; } =20 /* copy the AG free list header */ push_cur(); + stack_count++; set_cur(&typtab[TYP_AGFL], XFS_AG_DADDR(mp, agno, XFS_AGFL_DADDR(mp)), XFS_FSS_TO_BB(mp, 1), DB_RING_IGN, NULL); if (iocur_top->data =3D=3D NULL) { print_warning("cannot read agfl block for ag %u", agno); if (stop_on_read_error) - return 0; + goto pop_out; } else { if (!write_buf(iocur_top)) - return 0; + goto pop_out; } - pop_cur(); =20 /* copy AG free space btrees */ if (agf) { @@ -1463,22 +1480,21 @@ scan_ag( print_progress("Copying free space trees of AG %u", agno); if (!copy_free_bno_btree(agno, agf)) - return 0; + goto pop_out; if (!copy_free_cnt_btree(agno, agf)) - return 0; + goto pop_out; } =20 /* copy inode btrees and the inodes and their associated metadata */ if (agi) { if (!copy_inodes(agno, agi)) - return 0; + goto pop_out; } - - pop_cur(); - pop_cur(); - pop_cur(); - - return 1; + rval =3D 1; +pop_out: + while (stack_count--) + pop_cur(); + return rval; } =20 static int @@ -1492,6 +1508,7 @@ copy_ino( xfs_dinode_t *dip; xfs_dinode_core_t tdic; int offset; + int rval =3D 0; =20 if (ino =3D=3D 0) return 1; @@ -1515,7 +1532,8 @@ copy_ino( if (iocur_top->data =3D=3D NULL) { print_warning("cannot read %s inode %lld", typtab[itype].name, (long long)ino); - return !stop_on_read_error; + rval =3D !stop_on_read_error; + goto pop_out; } off_cur(offset << mp->m_sb.sb_inodelog, mp->m_sb.sb_inodesize); =20 @@ -1524,7 +1542,10 @@ copy_ino( memcpy(&dip->di_core, &tdic, sizeof(xfs_dinode_core_t)); =20 cur_ino =3D ino; - return process_inode_data(dip, itype); + rval =3D process_inode_data(dip, itype); +pop_out: + pop_cur(); + return rval; } =20 =20 @@ -1553,6 +1574,7 @@ copy_log(void) set_cur(&typtab[TYP_LOG], XFS_FSB_TO_DADDR(mp, mp->m_sb.sb_logstart), mp->m_sb.sb_logblocks * blkbb, DB_RING_IGN, NULL); if (iocur_top->data =3D=3D NULL) { + pop_cur(); print_warning("cannot read log"); return !stop_on_read_error; } ------------YV3huUsCLm2zPlwEmnbw53-- From owner-xfs@oss.sgi.com Mon Jun 30 02:01:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 02:01:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 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 m5U91FIA003187 for ; Mon, 30 Jun 2008 02:01:17 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id TAA24479; Mon, 30 Jun 2008 19:02:12 +1000 Message-ID: <4868A114.9080106@sgi.com> Date: Mon, 30 Jun 2008 19:02:12 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss Subject: Re: [PATCH] re-remove xfs custom bitops References: <480EB397.1040304@sandeen.net> <4829C360.5060500@sandeen.net> <482BF841.8050704@sgi.com> <48669A45.1050104@sandeen.net> In-Reply-To: <48669A45.1050104@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16657 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Donald Douwsma wrote: >> Eric Sandeen wrote: >>> Eric Sandeen wrote: >>>> Once more, with feeling! >>>> >>>> This re-instates the reverted mod after the ppc panic of >>>> Feb '08. You guys do have ppc boxes in the test farm now right? :) >>>> >>>> This keeps xfs_lowbit64 as it was since there aren't good >>>> generic helpers there ... >>>> >>>> This should probably keep Dave's signed-off line, there's >>>> a bit of my (userspace) testing here but no original work. >>>> >>>> This exact patch isn't tested but it's based on a conglomeration >>>> of prior testing... >>> SGI guys, any takers on this one? >>> -Eric >> Sorry Eric, havent had chance to run this on all platforms yet. >> I want to test it on ppc as well as the usual x86_64/ia64 combinations, >> then I'll get it committed. >> >> Don > > Don, how's that all going then? :) > Good question, got sidetracked with product releases. First time round I hit an Oops on xfstests/177 while running the auto group on ppc32. I dont seem to hit it running the single test, its intermittent. I also hit this oops once back in Feb running x86_64, which was around the time we pulled the last version of this cleanup out, but it may be unrelated. Looping through the auto group overnight, I'll see If I hit it again. XFS mounting filesystem hdb4 Ending clean XFS mount for filesystem: hdb4 Device hdb4 - bad inode magic/vsn daddr 23607192 #0 (magic=0) ------------[ cut here ]------------ kernel BUG at fs/xfs/support/debug.c:54! Oops: Exception in kernel mode, sig: 5 [#1] PowerMac Modules linked in: iptable_filter ip_tables ip6table_filter ip6_tables x_tables ipv6 dm_mod ide_cd_mod cdrom uninorth_agp ohci1394 agpgart sungem sungem_phy natsemi ieee1394 ehci_hcd NIP: c01955c8 LR: c01955bc CTR: c0032cc4 REGS: c3359d10 TRAP: 0700 Not tainted (2.6.25-donaldd) MSR: 00029032 CR: 24002082 XER: 00000000 TASK = da1a4660[31911] 'xfssyncd' THREAD: c3358000 GPR00: 00000001 c3359dc0 da1a4660 00000041 00000001 00000000 00000000 00000001 GPR08: 0014ff97 c0500d48 d2aea3f2 c0500d48 00190834 00000000 0242db00 0242dc14 GPR16: 0242d860 02464870 0242dc38 c0448f8c c04512c8 00000000 c0160984 c3359e88 GPR24: 00000000 00000020 c3b1d1e0 00000000 c3359e90 00000000 c056cf34 00009032 NIP [c01955c8] cmn_err+0xd4/0xec LR [c01955bc] cmn_err+0xc8/0xec Call Trace: [c3359dc0] [c01955bc] cmn_err+0xc8/0xec (unreliable) [c3359e00] [c0160844] xfs_imap_to_bp+0x1a0/0x200 [c3359e80] [c0160984] xfs_itobp+0xe0/0x18c [c3359ed0] [c0162890] xfs_iflush+0x268/0x3f4 [c3359f10] [c017f98c] xfs_finish_reclaim+0xe8/0x190 [c3359f30] [c017facc] xfs_finish_reclaim_all+0x98/0xf4 [c3359f60] [c017ded0] xfs_syncsub+0x5c/0x290 [c3359f90] [c0192820] xfs_sync_worker+0x30/0x64 [c3359fa0] [c019404c] xfssyncd+0x118/0x16c [c3359fe0] [c004a790] kthread+0x4c/0x88 [c3359ff0] [c0012f9c] kernel_thread+0x44/0x60 Instruction dump: 7c1e19ae 3d20c03a 57a0103a 39291c84 3c60c047 7c89002e 7fc5f378 3863ae70 4bea0c49 7fe00124 7fa00034 5400d97e <0f000000> 80010044 bba10034 38210040 ---[ end trace f4636d0864e8be53 ]--- From owner-xfs@oss.sgi.com Mon Jun 30 03:10:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 03:10:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5UAAbMt008060 for ; Mon, 30 Jun 2008 03:10:38 -0700 X-ASG-Debug-ID: 1214820698-326902310000-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 DD7EE29CC4F for ; Mon, 30 Jun 2008 03:11:39 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.158]) by cuda.sgi.com with ESMTP id FbsVt4UFpbgOKIQ8 for ; Mon, 30 Jun 2008 03:11:39 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id l26so696859fgb.8 for ; Mon, 30 Jun 2008 03:11:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=uCFs0HncJETdr1i7ZA01ApuZouWh2OWVr65wVsWoLhg=; b=vvG6Nh7+EeIpGcklFB0PiHlKhHv1FJpYMXPVGWOCDsZtwYghyrEX4aolmi0y/mFw/k Lf+8g9eA8doJW1XuOTUYG4yNLMUkSTBf12G1TA1W8giBxGvW85XuRC766zXBnLn0V0UY o3WFXhLBIfxFpI8OrV/qm0SkGyDwVY60Z/8uk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ESf26pqWNkPoRvAiv01mgopRQ5YkDufV805D6u5AgUF32z6ogzu7m9rlu8YJgnkoFB 8sT299ViQH5oeHwR8tobdBLjvHzAW0daUqvvNxQw/52z/EJLfTyWxeYpDKIoPiXxY9/M u6ZrKOOnra1jKw1i2UhBUJnVoz3uL6URuUpeA= Received: by 10.86.59.2 with SMTP id h2mr5951117fga.12.1214820698275; Mon, 30 Jun 2008 03:11:38 -0700 (PDT) Received: by 10.86.31.3 with HTTP; Mon, 30 Jun 2008 03:11:38 -0700 (PDT) Message-ID: <6101e8c40806300311n6798890fk14641e65d202d443@mail.gmail.com> Date: Mon, 30 Jun 2008 12:11:38 +0200 From: "Oliver Pinter" To: david@fromorbit.com X-ASG-Orig-Subj: Re: [XFS] kernel panic on halt (2.6.26-rc7) Subject: Re: [XFS] kernel panic on halt (2.6.26-rc7) Cc: "Al Viro" , "Linus Torvalds" , "Christoph Hellwig" , xfs@oss.sgi.com, linux-kernel@vger.kernel.org, "Eric Sandeen" , "Matthew Wilcox" In-Reply-To: <20080627043113.GZ29319@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6101e8c40806260532j3bed1c7k9a60c41ea297549f@mail.gmail.com> <20080627043113.GZ29319@disturbed> X-Barracuda-Connect: fg-out-1718.google.com[72.14.220.158] X-Barracuda-Start-Time: 1214820699 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.54757 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: 16658 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: oliver.pntr@gmail.com Precedence: bulk X-list: xfs On 6/27/08, Dave Chinner wrote: > On Thu, Jun 26, 2008 at 02:32:19PM +0200, Oliver Pinter wrote: >> Hi Christoph, Dave, >> >> a similar problem came out the with 2.6.26, than the was in post early >> with 2.6.25[1][2] >> >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00807.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00808.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00809.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00810.jpg >> http://students.zipernowsky.hu/~oliverp/upload/xfs_error_2.6.26/dsc00811.jpg > > http://lkml.org/lkml/2008/3/7/356 thanks > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > -- Thanks, Oliver From owner-xfs@oss.sgi.com Mon Jun 30 03:23:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 03:23:49 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from 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 m5UANkoF009198 for ; Mon, 30 Jun 2008 03:23:46 -0700 X-ASG-Debug-ID: 1214821487-1b01037b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta01.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 64D7B72CF79 for ; Mon, 30 Jun 2008 03:24:47 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id yAf1w1DxS17uAiBL for ; Mon, 30 Jun 2008 03:24:47 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 854D0189050E for ; Mon, 30 Jun 2008 03:27:45 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta01.pmc-sierra.bc.ca (Postfix) with SMTP id 7C109189050B for ; Mon, 30 Jun 2008 03:27:45 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Mon, 30 Jun 2008 03:25:21 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Mon, 30 Jun 2008 03:25:20 -0700 Message-ID: <4868B46C.9000200@pmc-sierra.com> Date: Mon, 30 Jun 2008 15:54:44 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <340C71CD25A7EB49BFA81AE8C839266701323BD8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> In-Reply-To: <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2008 10:25:21.0107 (UTC) FILETIME=[998E1230:01C8DA9B] X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1214821488 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0206 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54758 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: 16659 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Hi Dave, Sagar Borikar wrote: > Dave Chinner wrote: >> On Sat, Jun 28, 2008 at 09:47:44AM -0700, Sagar Borikar wrote: >> Device Boot Start End Blocks Id System >>> /dev/scsibd1 126 286 20608 83 Linux >>> /dev/scsibd2 287 1023 94336 83 Linux >>> /dev/scsibd3 1149 1309 20608 83 Linux >>> /dev/scsibd4 1310 2046 94336 83 Linux >>> >> >> I'd have to assume thats a flash based root drive, right? >> >> > That's right, >>> Disk /dev/md0: 251.0 GB, 251000160256 bytes >>> 2 heads, 4 sectors/track, 61279336 cylinders >>> Units = cylinders of 8 * 512 = 4096 bytes >>> >>> Disk /dev/md0 doesn't contain a valid partition table >>> >>> Disk /dev/dm-0: 107.3 GB, 107374182400 bytes >>> 255 heads, 63 sectors/track, 13054 cylinders >>> Units = cylinders of 16065 * 512 = 8225280 bytes >>> >> >> Neither of these tell me what /dev/RAIDA/vol is.... >> It is the device node to which /mnt/RAIDA/vol is mapped to. Its a >> JBOD with 233 GB size. >> >>> But still the issue is why doesn't it happen every time and less >>> stress? >>> >>> I am surprised to see to let this happen immediately when the >>> subdirectories increase more than 30. Else it decays slowly. >>> >> >> So it happens when you get more than 30 entries in a directory >> under a certain load? That might be an extent->btree format >> conversion bug or vice versa. I'd suggest setting up a test based >> around this to try to narrow down the problem. >> >> Cheers, >> >> Dave. >> > Thanks for all your help. Shall keep you posted with the progress on > debugging. > > Regards > Sagar > After running my test for 20 min, when I check the fragmentation status of file system, I observe that it is severely fragmented. [root@NAS001ee5ab9c85 ~]# xfs_db -c frag -r /dev/RAIDA/vol actual 94343, ideal 107, fragmentation factor 99.89% Do you think, this can cause the issue? Thanks Sagar From owner-xfs@oss.sgi.com Mon Jun 30 05:19:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 05:19:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53 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 m5UCJGvk021956 for ; Mon, 30 Jun 2008 05:19:16 -0700 X-ASG-Debug-ID: 1214828417-6ec6012c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 482321067620 for ; Mon, 30 Jun 2008 05:20:17 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id ePbSHhhZ47m09pdh for ; Mon, 30 Jun 2008 05:20:17 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5UCK6wg000372; Mon, 30 Jun 2008 21:20:06 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5UCK6o05714; Mon, 30 Jun 2008 21:20:06 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5UCK57V007094; Mon, 30 Jun 2008 21:20:05 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Mon, 30 Jun 2008 21:20:05 +0900 To: "akpm@linux-foundation.org" , "viro@ZenIV.linux.org.uk" Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "axboe@kernel.dk" , "mtk.manpages@googlemail.com" X-ASG-Orig-Subj: [PATCH 0/3] freeze feature ver 1.8 Subject: [PATCH 0/3] freeze feature ver 1.8 Message-Id: <20080630212005t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Mon, 30 Jun 2008 21:20:05 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1214828418 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.54766 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: 16660 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi Andrew and Alexander, I've addressed Andrew's comments in these patches. Please see my previous mail for details of changes. But only following change is different from my previous mail. I wrote: >>> +void del_freeze_timeout(struct block_device *bdev) >>> +{ >>> + if (delayed_work_pending(&bdev->bd_freeze_timeout)) >> >> Is this test needed? > > It's not necessary because cancel_delayed_work_sync checks it itself. > I will remove it. It's possible that the delayed work task (freeze_timeout()) calls del_freeze_timeout(). If the delayed work task calls cancel_delayed_work_sync() to delete itself, a deadlock will occur. So we need the test of delayed_work_pending(). Currently, ext3 in mainline Linux doesn't have the freeze feature which suspends write requests. So, we cannot take a backup which keeps the filesystem's consistency with the storage device's features (snapshot and replication) while it is mounted. In many case, a commercial filesystem (e.g. VxFS) has the freeze feature and it would be used to get the consistent backup. If Linux's standard filesytem ext3 has the freeze feature, we can do it without a commercial filesystem. So I have implemented the ioctls of the freeze feature. I think we can take the consistent backup with the following steps. 1. Freeze the filesystem with the freeze ioctl. 2. Separate the replication volume or create the snapshot with the storage device's feature. 3. Unfreeze the filesystem with the unfreeze ioctl. 4. Take the backup from the separated replication volume or the snapshot. [PATCH 1/3] Implement generic freeze feature I have modified to set the suitable error number (EOPNOTSUPP) in case the filesystem doesn't support the freeze feature. The ioctls for the generic freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, arg) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 o Unfreeze the filesystem int ioctl(int fd, int FITHAW, arg) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature It removes XFS specific ioctl interfaces and request codes for freeze feature. This patch has been supplied by David Chinner. [PATCH 3/3] Add timeout feature The timeout feature is added to freeze ioctl. And new ioctl to reset the timeout period is added. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, long *timeout_sec) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze timeout_sec: the timeout period in seconds If it's 0 or 1, the timeout isn't set. This special case of "1" is implemented to keep the compatibility with XFS applications. Return value: 0 if the operation succeeds. Otherwise, -1 o Reset the timeout period This is useful for the application to set the timeout_sec more accurately. For example, the freezer resets the timeout_sec to 10 seconds every 5 seconds. In this approach, even if the freezer causes a deadlock by accessing the frozen filesystem, it will be solved by the timeout in 10 seconds and the freezer can recognize that at the next reset of timeout_sec. int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeout_sec) fd:file descriptor of mountpoint FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period timeout_sec: new timeout period in seconds Return value: 0 if the operation succeeds. Otherwise, -1 Error number: If the filesystem has already been unfrozen, errno is set to EINVAL. Any comments are very welcome. Cheers, Takashi From owner-xfs@oss.sgi.com Mon Jun 30 05:22:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 05:22:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_53 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 m5UCMVpK022445 for ; Mon, 30 Jun 2008 05:22:31 -0700 X-ASG-Debug-ID: 1214828612-78a4010b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7187629D141 for ; Mon, 30 Jun 2008 05:23:32 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id tm2twMtUxYrjax8u for ; Mon, 30 Jun 2008 05:23:32 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate54B.nec.co.jp [10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5UCNPBQ010950; Mon, 30 Jun 2008 21:23:25 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5UCNOd03801; Mon, 30 Jun 2008 21:23:24 +0900 (JST) Received: from kuichi.jp.nec.com (kuichi.jp.nec.com [10.26.220.17]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5UCNObH007387; Mon, 30 Jun 2008 21:23:24 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Mon, 30 Jun 2008 21:23:23 +0900 To: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: [PATCH 1/3] Implement generic freeze feature Subject: [PATCH 1/3] Implement generic freeze feature Message-Id: <20080630212323t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Mon, 30 Jun 2008 21:23:23 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193] X-Barracuda-Start-Time: 1214828613 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54766 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16661 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs The ioctls for the generic freeze feature are below. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, arg) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 o Unfreeze the filesystem int ioctl(int fd, int FITHAW, arg) fd: The file descriptor of the mountpoint FITHAW: request code for unfreeze arg: Ignored Return value: 0 if the operation succeeds. Otherwise, -1 Signed-off-by: Takashi Sato Signed-off-by: Masayuki Hamaguchi --- diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/fs/buffer.c linux-2.6.26-rc7-freeze/fs/bu ffer.c --- linux-2.6.26-rc7.org/fs/buffer.c 2008-06-25 12:08:10.000000000 +0900 +++ linux-2.6.26-rc7-freeze/fs/buffer.c 2008-06-27 09:18:19.000000000 +0900 @@ -201,6 +201,21 @@ struct super_block *freeze_bdev(struct b { struct super_block *sb; + if (test_and_set_bit(BD_FREEZE_OP, &bdev->bd_state)) + return ERR_PTR(-EBUSY); + + sb = get_super(bdev); + + /* If super_block has been already frozen, return. */ + if (sb && sb->s_frozen != SB_UNFROZEN) { + drop_super(sb); + clear_bit(BD_FREEZE_OP, &bdev->bd_state); + return sb; + } + + if (sb) + drop_super(sb); + down(&bdev->bd_mount_sem); sb = get_super(bdev); if (sb && !(sb->s_flags & MS_RDONLY)) { @@ -219,6 +234,8 @@ struct super_block *freeze_bdev(struct b } sync_blockdev(bdev); + clear_bit(BD_FREEZE_OP, &bdev->bd_state); + return sb; /* thaw_bdev releases s->s_umount and bd_mount_sem */ } EXPORT_SYMBOL(freeze_bdev); @@ -230,8 +247,17 @@ EXPORT_SYMBOL(freeze_bdev); * * Unlocks the filesystem and marks it writeable again after freeze_bdev(). */ -void thaw_bdev(struct block_device *bdev, struct super_block *sb) +int thaw_bdev(struct block_device *bdev, struct super_block *sb) { + + if (test_and_set_bit(BD_FREEZE_OP, &bdev->bd_state)) + return -EBUSY; + + if (sb && sb->s_frozen == SB_UNFROZEN) { + clear_bit(BD_FREEZE_OP, &bdev->bd_state); + return 0; + } + if (sb) { BUG_ON(sb->s_bdev != bdev); @@ -244,6 +270,8 @@ void thaw_bdev(struct block_device *bdev } up(&bdev->bd_mount_sem); + clear_bit(BD_FREEZE_OP, &bdev->bd_state); + return 0; } EXPORT_SYMBOL(thaw_bdev); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/fs/ioctl.c linux-2.6.26-rc7-freeze/fs/ioc tl.c --- linux-2.6.26-rc7.org/fs/ioctl.c 2008-06-25 12:08:14.000000000 +0900 +++ linux-2.6.26-rc7-freeze/fs/ioctl.c 2008-06-25 12:00:41.000000000 +0900 @@ -13,6 +13,7 @@ #include #include #include +#include #include @@ -141,6 +142,49 @@ static int ioctl_fioasync(unsigned int f } /* + * ioctl_freeze - Freeze the filesystem. + * + * @filp: target file + * + * Call freeze_bdev() to freeze the filesystem. + */ +static int ioctl_freeze(struct file *filp) +{ + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + /* If filesystem doesn't support freeze feature, return. */ + if (sb->s_op->write_super_lockfs == NULL) + return -EOPNOTSUPP; + + /* Freeze */ + sb = freeze_bdev(sb->s_bdev); + if (IS_ERR(sb)) + return PTR_ERR(sb); + return 0; +} + +/* + * ioctl_thaw - Thaw the filesystem. + * + * @filp: target file + * + * Call thaw_bdev() to thaw the filesystem. + */ +static int ioctl_thaw(struct file *filp) +{ + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + /* Thaw */ + return thaw_bdev(sb->s_bdev, sb); +} + +/* * When you add any new common ioctls to the switches above and below * please update compat_sys_ioctl() too. * @@ -181,6 +225,15 @@ int do_vfs_ioctl(struct file *filp, unsi } else error = -ENOTTY; break; + + case FIFREEZE: + error = ioctl_freeze(filp); + break; + + case FITHAW: + error = ioctl_thaw(filp); + break; + default: if (S_ISREG(filp->f_path.dentry->d_inode->i_mode)) error = file_ioctl(filp, cmd, arg); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/include/linux/buffer_head.h linux-2.6.26- rc7-freeze/include/linux/buffer_head.h --- linux-2.6.26-rc7.org/include/linux/buffer_head.h 2008-06-25 12:08:19.000000000 +0900 +++ linux-2.6.26-rc7-freeze/include/linux/buffer_head.h 2008-06-25 12:00:45.000000000 +0900 @@ -171,7 +171,7 @@ void __wait_on_buffer(struct buffer_head wait_queue_head_t *bh_waitq_head(struct buffer_head *bh); int fsync_bdev(struct block_device *); struct super_block *freeze_bdev(struct block_device *); -void thaw_bdev(struct block_device *, struct super_block *); +int thaw_bdev(struct block_device *, struct super_block *); int fsync_super(struct super_block *); int fsync_no_super(struct block_device *); struct buffer_head *__find_get_block(struct block_device *bdev, sector_t block, diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7.org/include/linux/fs.h linux-2.6.26-rc7-freez e/include/linux/fs.h --- linux-2.6.26-rc7.org/include/linux/fs.h 2008-06-25 12:08:19.000000000 +0900 +++ linux-2.6.26-rc7-freeze/include/linux/fs.h 2008-06-30 16:40:49.000000000 +0900 @@ -223,6 +223,8 @@ extern int dir_notify_enable; #define BMAP_IOCTL 1 /* obsolete - kept for compatibility */ #define FIBMAP _IO(0x00,1) /* bmap access */ #define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */ +#define FIFREEZE _IOWR('X', 119, int) /* Freeze */ +#define FITHAW _IOWR('X', 120, int) /* Thaw */ #define FS_IOC_GETFLAGS _IOR('f', 1, long) #define FS_IOC_SETFLAGS _IOW('f', 2, long) @@ -494,6 +496,13 @@ int pagecache_write_end(struct file *, s loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata); +/* + * Bits in block_device.bd_state. + */ +enum bd_state { + BD_FREEZE_OP /* In freeze operation */ +}; + struct backing_dev_info; struct address_space { struct inode *host; /* owner: inode, block_device */ @@ -547,6 +556,9 @@ struct block_device { * care to not mess up bd_private for that case. */ unsigned long bd_private; + + /* State of the block device. (Used by freeze feature) */ + unsigned long bd_state; }; /* From owner-xfs@oss.sgi.com Mon Jun 30 05:22:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 05:22:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m5UCMoRJ022652 for ; Mon, 30 Jun 2008 05:22:50 -0700 X-ASG-Debug-ID: 1214828627-7ea600dc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E5E7912CFCCF for ; Mon, 30 Jun 2008 05:23:47 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id l2V6L01KjrOnbDj9 for ; Mon, 30 Jun 2008 05:23:47 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5UCNe9f011075; Mon, 30 Jun 2008 21:23:40 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5UCNeT10487; Mon, 30 Jun 2008 21:23:40 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5UCNenF007481; Mon, 30 Jun 2008 21:23:40 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Mon, 30 Jun 2008 21:23:39 +0900 To: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature Subject: [PATCH 2/3] Remove XFS specific ioctl interfaces for freeze feature Message-Id: <20080630212339t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Mon, 30 Jun 2008 21:23:39 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193] X-Barracuda-Start-Time: 1214828632 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.54766 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: 16662 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs It removes XFS specific ioctl interfaces and request codes for freeze feature. This patch has been supplied by David Chinner. Signed-off-by: Dave Chinner Signed-off-by: Takashi Sato --- diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-freeze/fs/xfs/linux-2.6/xfs_ioctl.c linux-2.6 .26-rc7-xfs/fs/xfs/linux-2.6/xfs_ioctl.c --- linux-2.6.26-rc7-freeze/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-25 12:00:40.000000000 +0900 +++ linux-2.6.26-rc7-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-25 12:07:19.000000000 +0900 @@ -1233,21 +1233,6 @@ xfs_ioctl( return -error; } - case XFS_IOC_FREEZE: - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; - - if (inode->i_sb->s_frozen == SB_UNFROZEN) - freeze_bdev(inode->i_sb->s_bdev); - return 0; - - case XFS_IOC_THAW: - if (!capable(CAP_SYS_ADMIN)) - return -EPERM; - if (inode->i_sb->s_frozen != SB_UNFROZEN) - thaw_bdev(inode->i_sb->s_bdev, inode->i_sb); - return 0; - case XFS_IOC_GOINGDOWN: { __uint32_t in; diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-freeze/fs/xfs/linux-2.6/xfs_ioctl32.c linux-2 .6.26-rc7-xfs/fs/xfs/linux-2.6/xfs_ioctl32.c --- linux-2.6.26-rc7-freeze/fs/xfs/linux-2.6/xfs_ioctl32.c 2008-06-25 12:00:40.000000000 +0900 +++ linux-2.6.26-rc7-xfs/fs/xfs/linux-2.6/xfs_ioctl32.c 2008-06-25 12:07:19.000000000 +0900 @@ -398,8 +398,6 @@ xfs_compat_ioctl( case XFS_IOC_FSGROWFSDATA: case XFS_IOC_FSGROWFSLOG: case XFS_IOC_FSGROWFSRT: - case XFS_IOC_FREEZE: - case XFS_IOC_THAW: case XFS_IOC_GOINGDOWN: case XFS_IOC_ERROR_INJECTION: case XFS_IOC_ERROR_CLEARALL: diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-freeze/fs/xfs/xfs_fs.h linux-2.6.26-rc7-xfs/f s/xfs/xfs_fs.h --- linux-2.6.26-rc7-freeze/fs/xfs/xfs_fs.h 2008-06-25 12:00:40.000000000 +0900 +++ linux-2.6.26-rc7-xfs/fs/xfs/xfs_fs.h 2008-06-25 12:07:19.000000000 +0900 @@ -473,8 +473,8 @@ typedef struct xfs_handle { #define XFS_IOC_ERROR_INJECTION _IOW ('X', 116, struct xfs_error_injection) #define XFS_IOC_ERROR_CLEARALL _IOW ('X', 117, struct xfs_error_injection) /* XFS_IOC_ATTRCTL_BY_HANDLE -- deprecated 118 */ -#define XFS_IOC_FREEZE _IOWR('X', 119, int) -#define XFS_IOC_THAW _IOWR('X', 120, int) +/* XFS_IOC_FREEZE -- FIFREEZE 119 */ +/* XFS_IOC_THAW -- FITHAW 120 */ #define XFS_IOC_FSSETDM_BY_HANDLE _IOW ('X', 121, struct xfs_fsop_setdm_handlereq) #define XFS_IOC_ATTRLIST_BY_HANDLE _IOW ('X', 122, struct xfs_fsop_attrlist_handlereq) #define XFS_IOC_ATTRMULTI_BY_HANDLE _IOW ('X', 123, struct xfs_fsop_attrmulti_handlereq) From owner-xfs@oss.sgi.com Mon Jun 30 05:24:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 05:24:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_24, J_CHICKENPOX_53,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 m5UCO4rn023246 for ; Mon, 30 Jun 2008 05:24:04 -0700 X-ASG-Debug-ID: 1214828703-513a01160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AF3F41852E0C for ; Mon, 30 Jun 2008 05:25:04 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id 9ISwOSUgVhc9CCRU for ; Mon, 30 Jun 2008 05:25:04 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate53F.nec.co.jp [10.7.69.162]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5UCOsPY011807; Mon, 30 Jun 2008 21:24:54 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m5UCOsG08753; Mon, 30 Jun 2008 21:24:54 +0900 (JST) Received: from saigo.jp.nec.com (saigo.jp.nec.com [10.26.220.6]) by mailsv3.nec.co.jp (8.13.8/8.13.4) with ESMTP id m5UCOrSG009536; Mon, 30 Jun 2008 21:24:53 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Mon, 30 Jun 2008 21:24:50 +0900 To: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk Cc: "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: [PATCH 3/3] Add timeout feature Subject: [PATCH 3/3] Add timeout feature Message-Id: <20080630212450t-sato@mail.jp.nec.com> Mime-Version: 1.0 X-Mailer: WeMail32[2.51] ID:1K0086 From: Takashi Sato Date: Mon, 30 Jun 2008 21:24:50 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193] X-Barracuda-Start-Time: 1214828705 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.54767 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: 16663 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs The timeout feature is added to freeze ioctl. And new ioctl to reset the timeout period is added. o Freeze the filesystem int ioctl(int fd, int FIFREEZE, long *timeout_sec) fd: The file descriptor of the mountpoint FIFREEZE: request code for the freeze timeout_sec: the timeout period in seconds If it's 0 or 1, the timeout isn't set. This special case of "1" is implemented to keep the compatibility with XFS applications. Return value: 0 if the operation succeeds. Otherwise, -1 o Reset the timeout period int ioctl(int fd, int FIFREEZE_RESET_TIMEOUT, long *timeout_sec) fd:file descriptor of mountpoint FIFREEZE_RESET_TIMEOUT: request code for reset of timeout period timeout_sec: new timeout period in seconds Return value: 0 if the operation succeeds. Otherwise, -1 Error number: If the filesystem has already been unfrozen, errno is set to EINVAL. Signed-off-by: Takashi Sato Signed-off-by: Masayuki Hamaguchi --- diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/drivers/md/dm.c linux-2.6.26-rc7-timeout/ drivers/md/dm.c --- linux-2.6.26-rc7-xfs/drivers/md/dm.c 2008-06-25 12:06:59.000000000 +0900 +++ linux-2.6.26-rc7-timeout/drivers/md/dm.c 2008-06-25 16:28:40.000000000 +0900 @@ -1407,7 +1407,7 @@ static int lock_fs(struct mapped_device WARN_ON(md->frozen_sb); - md->frozen_sb = freeze_bdev(md->suspended_bdev); + md->frozen_sb = freeze_bdev(md->suspended_bdev, 0); if (IS_ERR(md->frozen_sb)) { r = PTR_ERR(md->frozen_sb); md->frozen_sb = NULL; diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/block_dev.c linux-2.6.26-rc7-timeout/f s/block_dev.c --- linux-2.6.26-rc7-xfs/fs/block_dev.c 2008-06-25 12:07:19.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/block_dev.c 2008-06-25 16:30:49.000000000 +0900 @@ -285,6 +285,8 @@ static void init_once(struct kmem_cache INIT_LIST_HEAD(&bdev->bd_holder_list); #endif inode_init_once(&ei->vfs_inode); + /* Setup freeze timeout function. */ + INIT_DELAYED_WORK(&bdev->bd_freeze_timeout, freeze_timeout); } static inline void __bd_forget(struct inode *inode) diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/buffer.c linux-2.6.26-rc7-timeout/fs/b uffer.c --- linux-2.6.26-rc7-xfs/fs/buffer.c 2008-06-30 12:59:53.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/buffer.c 2008-06-27 10:59:55.000000000 +0900 @@ -190,14 +190,18 @@ int fsync_bdev(struct block_device *bdev /** * freeze_bdev -- lock a filesystem and force it into a consistent state - * @bdev: blockdevice to lock + * @bdev: blockdevice to lock + * @timeout_msec: timeout period * * This takes the block device bd_mount_sem to make sure no new mounts * happen on bdev until thaw_bdev() is called. * If a superblock is found on this device, we take the s_umount semaphore * on it to make sure nobody unmounts until the snapshot creation is done. + * If timeout_msec is bigger than 0, this registers the delayed work for + * timeout of the freeze feature. */ -struct super_block *freeze_bdev(struct block_device *bdev) +struct super_block *freeze_bdev(struct block_device *bdev, + unsigned int timeout_msec) { struct super_block *sb; @@ -234,6 +238,10 @@ struct super_block *freeze_bdev(struct b } sync_blockdev(bdev); + /* Setup unfreeze timer. */ + if (timeout_msec > 0) + add_freeze_timeout(bdev, timeout_msec); + clear_bit(BD_FREEZE_OP, &bdev->bd_state); return sb; /* thaw_bdev releases s->s_umount and bd_mount_sem */ @@ -258,6 +266,9 @@ int thaw_bdev(struct block_device *bdev, return 0; } + /* Delete unfreeze timer. */ + del_freeze_timeout(bdev); + if (sb) { BUG_ON(sb->s_bdev != bdev); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/ioctl.c linux-2.6.26-rc7-timeout/fs/io ctl.c --- linux-2.6.26-rc7-xfs/fs/ioctl.c 2008-06-25 12:07:20.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/ioctl.c 2008-06-27 08:49:58.000000000 +0900 @@ -145,22 +145,47 @@ static int ioctl_fioasync(unsigned int f * ioctl_freeze - Freeze the filesystem. * * @filp: target file + * @argp: timeout value(sec) * * Call freeze_bdev() to freeze the filesystem. */ -static int ioctl_freeze(struct file *filp) +static int ioctl_freeze(struct file *filp, int __user *argp) { + int timeout_sec; + unsigned int timeout_msec; struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + int error; if (!capable(CAP_SYS_ADMIN)) return -EPERM; - /* If filesystem doesn't support freeze feature, return. */ + /* If filesystem doesn't support freeze feature, return EOPNOTSUPP. */ if (sb->s_op->write_super_lockfs == NULL) return -EOPNOTSUPP; + /* If a regular file or a directory isn't specified, return EINVAL. */ + if (sb->s_bdev == NULL) + return -EINVAL; + + /* arg(sec) to tick value. */ + error = get_user(timeout_sec, argp); + if (error != 0) + return error; + + if (timeout_sec < 0 || timeout_sec > UINT_MAX/1000) + return -EINVAL; + + /* + * If 1 is specified as the timeout period it is changed into 0 + * to retain compatibility with XFS's xfs_freeze. + */ + if (timeout_sec == 1) + timeout_sec = 0; + + timeout_msec = timeout_sec * 1000; + /* Freeze */ - sb = freeze_bdev(sb->s_bdev); + sb = freeze_bdev(sb->s_bdev, timeout_msec); if (IS_ERR(sb)) return PTR_ERR(sb); return 0; @@ -180,11 +205,61 @@ static int ioctl_thaw(struct file *filp) if (!capable(CAP_SYS_ADMIN)) return -EPERM; + /* If a regular file or a directory isn't specified, return EINVAL. */ + if (sb->s_bdev == NULL) + return -EINVAL; + /* Thaw */ return thaw_bdev(sb->s_bdev, sb); } /* + * ioctl_freeze_reset_timeout - Reset timeout for freeze. + * + * @filp: target file + * @argp: timeout value(sec) + * + * Reset timeout for freeze. + */ +static int +ioctl_freeze_reset_timeout(struct file *filp, int __user *argp) +{ + int timeout_sec; + unsigned int timeout_msec; + struct super_block *sb = filp->f_path.dentry->d_inode->i_sb; + int error; + + if (!capable(CAP_SYS_ADMIN)) + return -EPERM; + + /* If a regular file or a directory isn't specified, return EINVAL. */ + if (sb->s_bdev == NULL) + return -EINVAL; + + /* arg(sec) to tick value */ + error = get_user(timeout_sec, argp); + if (error) + return error; + + if (timeout_sec <= 0 || timeout_sec > UINT_MAX/1000) + return -EINVAL; + + timeout_msec = timeout_sec * 1000; + + if (test_and_set_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state)) + return -EBUSY; + if (sb->s_frozen == SB_UNFROZEN) { + clear_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state); + return -EINVAL; + } + /* setup unfreeze timer */ + add_freeze_timeout(sb->s_bdev, timeout_msec); + clear_bit(BD_FREEZE_OP, &sb->s_bdev->bd_state); + + return 0; +} + +/* * When you add any new common ioctls to the switches above and below * please update compat_sys_ioctl() too. * @@ -227,13 +302,17 @@ int do_vfs_ioctl(struct file *filp, unsi break; case FIFREEZE: - error = ioctl_freeze(filp); + error = ioctl_freeze(filp, argp); break; case FITHAW: error = ioctl_thaw(filp); break; + case FIFREEZE_RESET_TIMEOUT: + error = ioctl_freeze_reset_timeout(filp, argp); + break; + default: if (S_ISREG(filp->f_path.dentry->d_inode->i_mode)) error = file_ioctl(filp, cmd, arg); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/super.c linux-2.6.26-rc7-timeout/fs/su per.c --- linux-2.6.26-rc7-xfs/fs/super.c 2008-06-30 16:41:48.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/super.c 2008-06-30 17:30:38.000000000 +0900 @@ -980,3 +980,60 @@ struct vfsmount *kern_mount_data(struct } EXPORT_SYMBOL_GPL(kern_mount_data); + +/* + * freeze_timeout - Thaw the filesystem. + * + * @work: work queue (delayed_work.work) + * + * Called by the delayed work when elapsing the timeout period. + * Thaw the filesystem. + */ +void freeze_timeout(struct work_struct *work) +{ + struct block_device *bd = container_of(work, + struct block_device, bd_freeze_timeout.work); + struct super_block *sb = get_super(bd); + + thaw_bdev(bd, sb); + + if (sb) + drop_super(sb); +} +EXPORT_SYMBOL_GPL(freeze_timeout); + +/* + * add_freeze_timeout - Add timeout for freeze. + * + * @bdev: block device struct + * @timeout_msec: timeout period + * + * Add the delayed work for freeze timeout to the delayed work queue. + */ +void add_freeze_timeout(struct block_device *bdev, unsigned int timeout_msec) +{ + s64 timeout_jiffies = msecs_to_jiffies(timeout_msec); + + /* Set delayed work queue */ + cancel_delayed_work_sync(&bdev->bd_freeze_timeout); + schedule_delayed_work(&bdev->bd_freeze_timeout, timeout_jiffies); +} + +/* + * del_freeze_timeout - Delete timeout for freeze. + * + * @bdev: block device struct + * + * Delete the delayed work for freeze timeout from the delayed work queue. + */ +void del_freeze_timeout(struct block_device *bdev) +{ + /* + * It's possible that the delayed work task (freeze_timeout()) calls + * del_freeze_timeout(). If the delayed work task calls + * cancel_delayed_work_sync((), the deadlock will occur. + * So we need this check (delayed_work_pending()). + */ + if (delayed_work_pending(&bdev->bd_freeze_timeout)) + cancel_delayed_work_sync(&bdev->bd_freeze_timeout); +} diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/fs/xfs/xfs_fsops.c linux-2.6.26-rc7-timeo ut/fs/xfs/xfs_fsops.c --- linux-2.6.26-rc7-xfs/fs/xfs/xfs_fsops.c 2008-06-25 12:07:19.000000000 +0900 +++ linux-2.6.26-rc7-timeout/fs/xfs/xfs_fsops.c 2008-06-25 16:30:48.000000000 +0900 @@ -619,7 +619,7 @@ xfs_fs_goingdown( { switch (inflags) { case XFS_FSOP_GOING_FLAGS_DEFAULT: { - struct super_block *sb = freeze_bdev(mp->m_super->s_bdev); + struct super_block *sb = freeze_bdev(mp->m_super->s_bdev, 0); if (sb && !IS_ERR(sb)) { xfs_force_shutdown(mp, SHUTDOWN_FORCE_UMOUNT); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/include/linux/buffer_head.h linux-2.6.26- rc7-timeout/include/linux/buffer_head.h --- linux-2.6.26-rc7-xfs/include/linux/buffer_head.h 2008-06-25 12:07:24.000000000 +0900 +++ linux-2.6.26-rc7-timeout/include/linux/buffer_head.h 2008-06-27 11:11:38.000000000 +0900 @@ -170,7 +170,8 @@ int sync_blockdev(struct block_device *b void __wait_on_buffer(struct buffer_head *); wait_queue_head_t *bh_waitq_head(struct buffer_head *bh); int fsync_bdev(struct block_device *); -struct super_block *freeze_bdev(struct block_device *); +struct super_block *freeze_bdev(struct block_device *, + unsigned int timeout_msec); int thaw_bdev(struct block_device *, struct super_block *); int fsync_super(struct super_block *); int fsync_no_super(struct block_device *); diff -uprN -X linux-2.6.26-rc7.org/Documentation/dontdiff linux-2.6.26-rc7-xfs/include/linux/fs.h linux-2.6.26-rc7-timeo ut/include/linux/fs.h --- linux-2.6.26-rc7-xfs/include/linux/fs.h 2008-06-30 16:42:11.000000000 +0900 +++ linux-2.6.26-rc7-timeout/include/linux/fs.h 2008-06-30 16:43:13.000000000 +0900 @@ -8,6 +8,7 @@ #include #include +#include /* * It's silly to have NR_OPEN bigger than NR_FILE, but you can change @@ -225,6 +226,7 @@ extern int dir_notify_enable; #define FIGETBSZ _IO(0x00,2) /* get the block size used for bmap */ #define FIFREEZE _IOWR('X', 119, int) /* Freeze */ #define FITHAW _IOWR('X', 120, int) /* Thaw */ +#define FIFREEZE_RESET_TIMEOUT _IO(0x00, 3) /* Reset freeze timeout */ #define FS_IOC_GETFLAGS _IOR('f', 1, long) #define FS_IOC_SETFLAGS _IOW('f', 2, long) @@ -559,6 +561,8 @@ struct block_device { /* State of the block device. (Used by freeze feature) */ unsigned long bd_state; + /* Delayed work for freeze */ + struct delayed_work bd_freeze_timeout; }; /* @@ -2147,5 +2151,10 @@ int proc_nr_files(struct ctl_table *tabl int get_filesystem_list(char * buf); +extern void add_freeze_timeout(struct block_device *bdev, + unsigned int timeout_msec); +extern void del_freeze_timeout(struct block_device *bdev); +extern void freeze_timeout(struct work_struct *work); + #endif /* __KERNEL__ */ #endif /* _LINUX_FS_H */ From owner-xfs@oss.sgi.com Mon Jun 30 06:53:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 06:53:52 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=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 m5UDrneO030290 for ; Mon, 30 Jun 2008 06:53:49 -0700 X-ASG-Debug-ID: 1214834091-78bc03e70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E00D72D1F0 for ; Mon, 30 Jun 2008 06:54:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id gDsNf2XSXZWfv0dr for ; Mon, 30 Jun 2008 06:54:51 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5UDsZ5V007554; Mon, 30 Jun 2008 09:54:35 -0400 Received: from pobox.fab.redhat.com (pobox.fab.redhat.com [10.33.63.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5UDsY2E003799; Mon, 30 Jun 2008 09:54:34 -0400 Received: from agk.fab.redhat.com (agk.fab.redhat.com [10.33.0.19]) by pobox.fab.redhat.com (8.13.1/8.13.1) with ESMTP id m5UDsYeo008044; Mon, 30 Jun 2008 09:54:34 -0400 Received: from agk by agk.fab.redhat.com with local (Exim 4.34) id 1KDJpx-0004Uc-Ta; Mon, 30 Jun 2008 14:54:33 +0100 Date: Mon, 30 Jun 2008 14:54:33 +0100 From: Alasdair G Kergon To: Takashi Sato Cc: "akpm@linux-foundation.org" , "viro@ZenIV.linux.org.uk" , "axboe@kernel.dk" , "mtk.manpages@googlemail.com" , "linux-kernel@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-ext4@vger.kernel.org" X-ASG-Orig-Subj: Re: [dm-devel] [PATCH 0/3] freeze feature ver 1.8 Subject: Re: [dm-devel] [PATCH 0/3] freeze feature ver 1.8 Message-ID: <20080630135433.GA22522@agk.fab.redhat.com> Mail-Followup-To: Takashi Sato , "akpm@linux-foundation.org" , "viro@ZenIV.linux.org.uk" , "axboe@kernel.dk" , "mtk.manpages@googlemail.com" , "linux-kernel@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-ext4@vger.kernel.org" References: <20080630212005t-sato@mail.jp.nec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080630212005t-sato@mail.jp.nec.com> User-Agent: Mutt/1.4.1i Organization: Red Hat UK Ltd. Registered in England and Wales, number 03798903. Registered Office: Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE. X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1214834091 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16664 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agk@redhat.com Precedence: bulk X-list: xfs On Mon, Jun 30, 2008 at 09:20:05PM +0900, Takashi Sato wrote: > Currently, ext3 in mainline Linux doesn't have the freeze feature which > suspends write requests. So, we cannot take a backup which keeps > the filesystem's consistency with the storage device's features > (snapshot and replication) while it is mounted. > In many case, a commercial filesystem (e.g. VxFS) has > the freeze feature and it would be used to get the consistent backup. > If Linux's standard filesytem ext3 has the freeze feature, we can do it > without a commercial filesystem. Is the following a fair summary? 1. Some filesystems have a freeze/thaw feature. XFS exports this to userspace directly through a couple of ioctls, but other filesystems don't. For filesystems on device-mapper block devices it is exported to userspace through the DM_DEV_SUSPEND ioctl which LVM uses. 2. There is a desire to access this feature from userspace on non-XFS filesystems without having to use device-mapper/LVM. Alasdair -- agk@redhat.com From owner-xfs@oss.sgi.com Mon Jun 30 09:17:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 09:17:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m5UGHfrl016032 for ; Mon, 30 Jun 2008 09:17:42 -0700 X-ASG-Debug-ID: 1214842722-05e502fd0000-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 B0E7929E375; Mon, 30 Jun 2008 09:18:43 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id gZkWElCO719tqdRc; Mon, 30 Jun 2008 09:18:43 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KDM5R-0001kV-T7; Mon, 30 Jun 2008 16:18:41 +0000 Date: Mon, 30 Jun 2008 12:18:41 -0400 From: Christoph Hellwig To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] fix mount option parsing in remount Subject: Re: [PATCH] fix mount option parsing in remount Message-ID: <20080630161841.GA22137@infradead.org> References: <20080518153539.GA5218@lst.de> <48687B79.6050101@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48687B79.6050101@sgi.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214842723 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.54782 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: 16665 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 30, 2008 at 04:21:45PM +1000, Timothy Shimmin wrote: > typo: s/support/supported/ > > Looking at ext3 and other XFS out of curiosity: > "XFS: unknown mount option [%s].", this_char > "EXT3-fs: Unrecognized mount option \"%s\" " > ./smbfs/getopt.c: printk("%s: Unrecognized mount option %s\n", caller, token); > Though I see for remount it is more a question of support > versus recognising it or not. Ok. I've fixed the typo. The recognized vs supported thing will get a little better once we switch to the parser table for mount, at which point we can make the message more fine-grained and report either unrecognized or unsupported. But until we need the full blown parser table I'd rather keep it simple. But once this one and my patch series to kill struct xfs_mount_args is in the full-blown switch to the table driven parser is quite easy. > I'm a little confused why we call xfs_mountfs_check_barriers(mp) in 2 places. > Oh okay, > so you want it tested if we have barrier option and > currently not-readonly or after we transition to not-readonly. > And you have it around the parsing code because you don't care about > what it might transition to in the current not-readonly case. Yes, if the filesystem is currently read-write we want to test the barriers immediately, if it's read-only we can't test it just yet but have to wait until the filesystems is remounted r/w. > I think we ideally should have a qa test for this. > We have 017 but it doesn't do any barrier or illegal options. Makes sense. I'll look into doing a QA test. 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-06-29 14:03:01.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_super.c 2008-06-30 14:42:02.000000000 +0200 @@ -66,6 +66,7 @@ #include #include #include +#include static struct quotactl_ops xfs_quotactl_operations; static struct super_operations xfs_super_operations; @@ -147,6 +148,23 @@ xfs_args_allocate( #define MNTOPT_XDSM "xdsm" /* DMI enabled (DMAPI / XDSM) */ #define MNTOPT_DMI "dmi" /* DMI enabled (DMAPI / XDSM) */ +/* + * Table driven mount option parser. + * + * Currently only used for remount, but it will be used for mount + * in the future, too. + */ +enum { + Opt_barrier, Opt_nobarrier, Opt_err +}; + +static match_table_t tokens = { + {Opt_barrier, "barrier"}, + {Opt_nobarrier, "nobarrier"}, + {Opt_err, NULL} +}; + + STATIC unsigned long suffix_strtoul(char *s, char **endp, unsigned int base) { @@ -1261,36 +1279,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 supported for remount\n", p); + return -EINVAL; } - } else if (!(mp->m_flags & XFS_MOUNT_RDONLY)) { /* rw -> ro */ + } + + /* rw/ro -> rw */ + if ((mp->m_flags & XFS_MOUNT_RDONLY) && !(*flags & MS_RDONLY)) { + mp->m_flags &= ~XFS_MOUNT_RDONLY; + if (mp->m_flags & XFS_MOUNT_BARRIER) + xfs_mountfs_check_barriers(mp); + } + + /* rw -> ro */ + if (!(mp->m_flags & XFS_MOUNT_RDONLY) && (*flags & MS_RDONLY)) { xfs_filestream_flush(mp); xfs_sync(mp, SYNC_DATA_QUIESCE); xfs_attr_quiesce(mp); mp->m_flags |= XFS_MOUNT_RDONLY; } - out_free_args: - kfree(args); - return -error; + return 0; } /* From owner-xfs@oss.sgi.com Mon Jun 30 23:00:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 23:00:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.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 m6160DCZ022565 for ; Mon, 30 Jun 2008 23:00:15 -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 QAA20387; Tue, 1 Jul 2008 16:01:11 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 09C7958C4C29; Tue, 1 Jul 2008 16:01:10 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 983924 - take back out again QUEUE_ORDERED_NONE test in check_barriers Message-Id: <20080701060111.09C7958C4C29@chook.melbourne.sgi.com> Date: Tue, 1 Jul 2008 16:01:10 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16666 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 Disable queue flag test in barrier check. md raid1 can pass down barriers, but does not set an ordered flag on the queue, so xfs does not even attempt a barrier write, and will never use barriers on these block devices. Remove the flag check and just let the barrier write test determine barrier support. A possible risk here is that if something does not set an ordered flag and also does not properly return an error on a barrier write... but if it's any consolation jbd/ext3/reiserfs never test the flag, and don't even do a test write, they just disable barriers the first time an actual journal barrier write fails. Signed-off-by: Eric Sandeen Date: Tue Jul 1 15:59:48 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31377a fs/xfs/linux-2.6/xfs_super.c - 1.433 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.433&r2=text&tr2=1.432&f=h - disable queue flag test in barrier check From owner-xfs@oss.sgi.com Mon Jun 30 23:16:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 23:16:31 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m616GQ94023741 for ; Mon, 30 Jun 2008 23:16:28 -0700 Received: from [134.14.55.78] (redback.melbourne.sgi.com [134.14.55.78]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA20753; Tue, 1 Jul 2008 16:17:14 +1000 Message-ID: <4869CCE9.1020304@sgi.com> Date: Tue, 01 Jul 2008 16:21:29 +1000 From: Lachlan McIlroy Reply-To: lachlan@sgi.com User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs-dev , xfs-oss Subject: Re: [PATCH] Fix use after free when closing log/rt devices References: <48647746.5010007@sgi.com> <20080627063219.GA25015@infradead.org> In-Reply-To: <20080627063219.GA25015@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16667 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: lachlan@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 27, 2008 at 03:14:46PM +1000, Lachlan McIlroy wrote: >> The call to xfs_free_buftarg() will free the memory used by it's argument >> so we need to save the bdev to pass to xfs_blkdev_put() >> >> Lachlan >> >> --- fs/xfs/linux-2.6/xfs_super.c_1.432 2008-06-27 14:51:17.000000000 +1000 >> +++ fs/xfs/linux-2.6/xfs_super.c 2008-06-27 14:59:26.000000000 +1000 >> @@ -781,13 +781,17 @@ STATIC void >> xfs_close_devices( >> struct xfs_mount *mp) >> { >> + struct block_device *bdev; >> + >> if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { >> + bdev = mp->m_logdev_targp->bt_bdev; >> xfs_free_buftarg(mp->m_logdev_targp); >> - xfs_blkdev_put(mp->m_logdev_targp->bt_bdev); >> + xfs_blkdev_put(bdev); >> } >> if (mp->m_rtdev_targp) { >> + bdev = mp->m_rtdev_targp->bt_bdev; >> xfs_free_buftarg(mp->m_rtdev_targp); >> - xfs_blkdev_put(mp->m_rtdev_targp->bt_bdev); >> + xfs_blkdev_put(bdev); >> } > > Looks good, alhough two local variables inside the ifs might be cleaner: > > if (mp->m_logdev_targp && mp->m_logdev_targp != mp->m_ddev_targp) { > struct block_device *logdev = mp->m_logdev_targp->bt_bdev; > > xfs_free_buftarg(mp->m_logdev_targp); > xfs_blkdev_put(logdev); > } > > ... > Thought someone might suggest that. I'll make the changes, thanks. From owner-xfs@oss.sgi.com Mon Jun 30 23:43:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 30 Jun 2008 23:43:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m616hrvE025447 for ; Mon, 30 Jun 2008 23:43:53 -0700 X-ASG-Debug-ID: 1214894695-24fa03780000-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 91B3C2A1F29 for ; Mon, 30 Jun 2008 23:44:55 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id u36qQ07IBIw59prz for ; Mon, 30 Jun 2008 23:44:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYGANexXkh5LFnmWmdsb2JhbACSYAEdm0A X-IronPort-AV: E=Sophos;i="4.27,730,1204464600"; d="scan'208";a="147193365" Received: from ppp121-44-89-230.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.89.230]) by ipmail04.adl2.internode.on.net with ESMTP; 01 Jul 2008 16:14:48 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KDZbR-0002bc-AW; Tue, 01 Jul 2008 16:44:37 +1000 Date: Tue, 1 Jul 2008 16:44:37 +1000 From: Dave Chinner To: Sagar Borikar Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080701064437.GR29319@disturbed> Mail-Followup-To: Sagar Borikar , xfs@oss.sgi.com References: <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4868B46C.9000200@pmc-sierra.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: 1214894696 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1539 1.0000 -1.0791 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.08 X-Barracuda-Spam-Status: No, SCORE=-1.08 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.54835 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: 16668 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Mon, Jun 30, 2008 at 03:54:44PM +0530, Sagar Borikar wrote: > After running my test for 20 min, when I check the fragmentation status > of file system, I observe that it > is severely fragmented. Depends on your definition of fragmentation.... > [root@NAS001ee5ab9c85 ~]# xfs_db -c frag -r /dev/RAIDA/vol > actual 94343, ideal 107, fragmentation factor 99.89% And that one is a bad one ;) Still, there are a lot of extents - ~1000 to a file - which will be stressing the btree extent format code. > Do you think, this can cause the issue? Sure - just like any other workload that generates enough extents. Like I said originally, we've fixed so many problems in this code since 2.6.18 I'd suggest that your only sane hope for us to help you track done the problem is to upgrade to a current kernel and go from there.... Cheers,, Dave. -- Dave Chinner david@fromorbit.com