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.co